[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