[SystemSafety] Program Specification
Olwen Morgan
olwen at phaedsys.com
Sun Nov 22 14:33:52 CET 2020
On 21/11/2020 22:08, Brian Randell wrote:
> ... <snip> ...
>
> So systems always come in threes - the given system, its environmental
> system, and the judgemental system. (The environment in some
> situations is also the judgmental system.) At any given moment the
> judgemental system can in principle determine whether or not a failure
> has occurred in an identified system. Different judgemental systems,
> or the same judgemental system at different times, may reach different
> judgements - and of course may themselves be judged by some other
> judgemental system as having failed.
...<snip>...
AFAI can see, common software engineering analysis and design practices
actually make reliability modelling more difficult. It starts with the
system context diagram, which typically shows the boundary of the
software system but not that of the hardware on which it runs. When
doing context diagrams for embedded control systems, I have for some
years now shown both hardware and software boundaries with the software
boundary lying in the interior (in the topological sense) of the
hardware boundary. Inputs arrive at the hardware boundary whence they
are communicated to the software boundary. The reverse process happens
for outputs. My reason for doing this in particularly critical systems
is that, in order to do sensible reliability simulations, one has to
distinguish those parts of a system that are *capable of independent
and/or correlated* failure. If one abstracts away from that information
in the first system design artefact, it is hardly surprising if
subsequent reliability modelling is made unnecessarily difficult.
The situation is even worse as one progresses through design from the
architecture to the detailed design levels. System components are, in my
experience, often chosen without much regard to considerations of
independence of failure. By the time you're down at the software unit
level, tracing reliability backwards through the design artefacts is,
quite literally, a confounded tangle. We really need software design
methods that *require* identification of independent and correlated
failure modes *before* allocation of functions to subsystems. At the
moment, semi-formal methods, whether structured or OO, are not serving
us well in designing for reliability. Unfortunately, formal methods,
with their higher degree of abstraction, can actually be *worse* than
semi-formal methods in this respect.
What can be said at all can be said clearly. On that whence we have
abstracted, we must remain silent. (Pace Ludwig Wittgenstein)
Olwen
More information about the systemsafety
mailing list