[SystemSafety] New paper on MISRA C

Matthew Squair mattsquair at gmail.com
Thu Sep 13 11:56:10 CEST 2018


I think you’re incorrect in equating determinism with reliability. I also
think there are a couple of different types of safety, argument follows.

Say you have some component it has a specified behavior F which includes
that it be provided over some interval (a reliability). If loss of that
behavior can cause a loss then we can equate reliability with safety. For
example  if the engines on an aircraft don’t work the passengers swim.
Let’s denote this sort of safety S1.

OK, but let’s think about the specification again. In specifying reliable
performance of the specified behavior we didn’t (as it happens) specify
that the component should not do anything else. What happens if it does?
Call that ^F. For example if we didn’t specify that the thrust reverser on
our jet engine should not deploy in flight, what happens if it does?
Ensuring we have considered these sort of issues and precluding them if
they result in a loss is a second sort of safety. One that is concerned
with driving out the hazardous non-determinism in our specification, let’s
call it S2.

Now consider this from a system perspective where we take several
components each with specified behaviors F, and unspecified behaviors ^F
and combine them to deliver a system behavior. Obviously we can have
various interactions each of which can generate emergent and potentially
hazardous behaviors (for two components we must consider four interactions
FF,F^F,^FF and ^F^F). Now reliability would cover some of the FF scenario
(via classical budgeting techniques) but not unspecified emergent system
level behaviors ^(FF). Nor would it consider emergent system behaviors
associated with component level nondeterministic behaviors and their
interactions.

So, what does a component standard like MISRA C do? If the answer includes
that it acts to reduce non determinism then it also acts to reduce system
non deterministic behavior, which may be hazardous. So yes it would have a
place in the system safety toolbox, as it addresses S2.

On 13 September 2018 at 3:57:08 pm, Paul Sherwood (
paul.sherwood at codethink.co.uk) wrote:

> On 2018-09-12 16:05, Peter Bernard Ladkin wrote:
>
> I suggest the following characterisation is somewhat misleading:
>
> MIT and others have successfully debunked the notion that system
> safety is correlated with component reliability
>
>
> OK, I'll try to be clearer. Engineering A Safer World states, with clear
> examples and justification:
>
> "High reliability is neither necessary nor sufficient for safety."
>
> and
>
> "Accidents are complex processes involving the entire socio-technical
> system. Traditional event-chain models cannot describe this process
> adequately."
>
> and
>
> "Highly reliable software is not necessarily safe. Increasing software
> reliability will have only minimal impact on safety."
>
> AFAIK MISRA C is all about improving determinism of software, i.e.
> increasing software component reliability. As of 2018 are ws still at
> the point where we can't deliver designed-in safety without heavy
> reliance on deterministic behaviour of microcontroller-scale components?
>
> br
> Paul
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180913/d0049caa/attachment.html>


More information about the systemsafety mailing list