The S# version of the case study can be found here.

In order to analyze the case study, you must have the MiniZinc constraint solver installed. Additionally, the path to MiniZinc.exe must be added to your system's PATH environment variable.

The self-organizing production cell is an instance of the system class of self-organizing resource-flow systems for which the metamodel shown above exists. The self-organizing production cell consists of robots and carts, both of which are Agents monitored by the Observer/Controller. The carts transport workpieces, i.e., Resources, between the robots, which have several switchable tools, that is, Capabilities, that they use on the workpieces such as drills and screwdrivers. A Task requires a workpiece to be processed by a sequence of tool applications, that is, by applying the drill, insert, and tighten Capabilities. Therefore, the robots and carts are responsible for processing incoming workpieces in a given sequence of tool applications; for the case study, the processing sequence required by the Task is to drill a hole, insert a screw, then tighten the screw, and possibly additional steps such as a polishing operation. The Roles assigned to each robot indicate which tools they have to apply on the workpieces and in which order, while the inputs and outputs of the Agents indicate which carts transport the workpieces between which robots. The figure below shows a simple configuration of a production cell consisting of three robots and two carts connecting them. Robot R1, for instance, is responsible for drilling a hole into a workpiece and transferring it to cart C1 afterwards. The cart then transports the workpiece to robot R2, which inserts the screw into the previously drilled hole, and so on. Tool failures result in reconfigurations of the transportation routes and tools applied by the robots as shown below in order to ensure correct workpiece processing. The production cell is self-organizing as it can reconfigure itself to compensate for broken tools or to incorporate new tools, robots, or carts, for instance. Such reconfigurations are initiated and coordinated by an observer/controller that determines new Roles for the Agents, that is, new paths for the carts as well as the set of tools to be used by the individual robots.

Faults are classified as either tolerable or intolerable, depending on whether the system’s self-organization mechanism is able to compensate their occurrences. Tolerable faults are those faults the system can compensate, continuing correct and safe operation after a reconfiguration. Self-organization can therefore be seen as a safety mechanism that increases the system's fault tolerance in order to prevent hazards for as long as possible. Intolerable component faults that we intend to analyze are: Sensors do not detect the arrival of a workpiece, carts move to the wrong robot, and robots and carts receive no reconfiguration information due to, for instance, networking problems. Tolerable component faults, on the other hand, are broken tools, robots that can no longer switch tools, robots that are no longer working at all, and carts whose assigned paths are blocked.

Self-organization cannot cope with all faults that occur during the lifetime of a system: Intolerable faults are outside of its reach, either because their occurrences cannot be detected or there is no possible way to react to their occurrence. In particular, a fault discovery mechanism might be missing due to a deliberate design decision in order to reduce costs or because the discovery is physically impossible for some reason. Additionally, at some point, there is not enough redundancy left in the system to continue operating safely after the occurrence of a tolerable fault, in which case a reconfiguration failure occurs. In the case study, reconfiguration fails, for instance, when all tools of the same kind no longer work.

There are two hazards that are most relevant for the case study: The first once occurs when a workpiece is damaged, that is, a workpiece is processed in an incorrect order. The reconfiguration failure does not occur in any of the hazard's minimal critical fault sets, showing that the system is not designed to reduce the hazard's likelihood. The second hazard occurs when some workpiece is never finished, i.e., not processed any further. The reconfiguration failure is one of the hazard's minimal critical fault sets, as no further processing is done on any workpiece once a reconfiguration failed.

The high level of redundancy that is inherent to self-organizing systems is problematic for the efficiency of state-of-the-art model-based safety analyses techniques: The models have large state spaces both because of the high number of constituent components as well as the large number of potential faults. Additionally, the latter results in a combinatorial explosion of the possible fault sets that may lead to hazards. New heuristics are therefore required to lessen the combinatorial state space explosion problem when analyzing self-organizing systems using model checking-based safety analysis techniques. Consequently, approaches for fully automated safety analyses of self-organizing systems are still an open research question