The pressure tank case study is inspired by a case study presented in the Fault Tree Handbook. We use the case study as the running example throughout this wiki. In order to make the running example as simple as possible while still retaining the original idea of the system, the electronic control system of the original version is replaced by a software-based controller.

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

The following figure shows a schematic overview of the case study: The fluid contained in the tank is refilled by the pump at the tank's inlet and removed at its outlet. The pump is activated and deactivated by a software controller. The pressure sensor signals the controller when the pressure limit is reached, causing the controller to deactivate the pump. To tolerate pressure sensor faults, the controller disables the pump after 60 seconds of continuous operation as it would risk a tank rupture otherwise. For time measurements, the controller uses the hardware timer. The internal structure and assembly of all of the aforementioned components are neither modeled nor analyzed in detail; instead, only their externally observable behaviors and their interconnections are modeled so that the safety of the overall system can be analyzed.

We assume that only the four faults shown in the above figure are relevant: The first two faults concern the pressure sensor in that it no longer reports that either the pressure limit has been reached (is full) or that the tank has become empty (is empty). The third fault prevents the timer from reporting a timeout (timeout) and the fourth one results in a failure of the pump, preventing it from refilling the tank (pumping).

The hazard we are interested in is that of tank ruptures due to overpressure that might injure people standing nearby. Other hazards are also conceivable, like the tank becoming empty, which might be safety-critical for the system consuming the fluid stored in the tank, but are not considered any further. For such a small set of faults and such a simple system, it is obvious that a tank rupture can only occur when both the sensor's is full fault and the timer's timeout fault occur. Consequently, there is only one [minimal critical fault set](Safety Analysis) for the hazard that consists of precisely these two faults. For more complex systems with a wider variety of component faults, however, the minimal critical fault sets are typically not so easily deducible. Instead, [model-based safety analysis techniques](Safety Analysis) must be used to compute these critical sets both automatically and thoroughly.

Modeling and analyzing the pressure tank running example does not pose any challenges at all, neither for our approach nor any other [modeling formalisms and analysis techniques](Related Work and Tools). Instead, it is a very basic safety-critical system that is intended to be used to motivate and explain S#'s main concepts, features, and capabilities.