dependability.info

Is functionality all we need? Are we done when we have found an architecture by which all functions work? – Yes and No!

Under the aspect of safety we also have to consider the inverse view and ask, under which conditions which function will fail. If an individual component fails, it might affect the various system functions in different ways. Redundancy plays a crucial role here.

When does a function fail? [more…]Dependent on its internal requirements, it will fail if one or several of its supplying components fail. The one at the end of the functional path. And this one will fail, …

• … if itself is defective or
• … if one or several of its own suppliers fail.

---

Recursively we can track back the whole functional network, a network of suppliers and consumers of services. Each with an individual internal condition. In the simplest form this may be expressed by simple logic, Boolean logic.

The following video shows some failure cases of the system in the figure shown in post [001].. Square boxes represent the components, rectangular ones the functions.

The blocks used here incorporate basically not more than such generic Boolean conditions. If a component provides an expected output – like “energized” – it is displayed in blue. If it provides no signal, it is white. And a nominally working function is green, while a failed function shows up in red. The analysis might remind you to FMEA – we’ll come back to that later.

The clue is, that each component may interactively set to “fails”, which means it fails to deliver its own service, locally, independent of its incoming supply. As the video shows, a simple simulation of such a network will immediately unveil, which functions will be affected by which component faults – indivudual ones or also combinations.

After having clarified these basic dependencies, we will introduce the concept of failure rates in post [003].