[SystemSafety] Component Reliability and System Safety

[Peter Bernard Ladkin]

On 2018-09-14 15:52 , Paul Sherwood wrote:
> On 2018-09-14 08:03, Peter Bernard Ladkin wrote:
> <snip>
>>>> [Paul Sherwood, I think] Why is MISRA C still considered relevant to system safety in 2018?
>>
>> (Banal question? Banal answer!)
> 
> I'm sorry you consider my question banal. 

Do recall I also described my answer as banal, so I can hardly have meant it perjoratively.

Here are two more answers, framed in such a way as to allow them not to seem banal:

a. SW meeting dependable conditions of some sort will necessarily have non-local properties, as well
as non-syntactic properties. That alone entails coding standards if you are going to do it right.

b. Anyone who wants to maintain SW beyond the involvement of the programmer who wrote it needs to
have the program written according to some coding standard.

Thirty years ago, I was looking at SW (actually, pseudocode which they called "specifications")
developed for a certain class of systems at a major telecommunications-system manufacturer. 90% of
it was boilerplate, all there for a reason.

And checking such standards by surveying the code can be onerous. At around the same time, a company
with which I was associated was checking code from a major aerospace manufacturer for adherence to
the manufacturer's code standard, using a Sun Workstation. The first half took a few hours, and the
second half suddenly slowed down five to ten times and took a day longer. The company called up Sun.
"Er, well, after 12MB our virtual-memory processing is indirect and SW/FW-based." According to what
Sun suggested, this company was the first to use more than 12MB of virtual memory in an application.
Those were the days.

Coding standards ipso facto aren't a panacea. They also have to be pertinent to the task.

To compound a perceived indiscretion further, I suggest it is also banal to ask why component
reliability is important for dependable systems. I would go further - it is important for any system
which is not deliberately built to subvert the purposes of the client.

You want the saddle on your bicycle to stay at the same height and always firmly "point" forward.
You want the handlebars to be, and to stay, parallel to the front wheel axle at all times. You want
the tires to be inflated properly (or you should). You want the back wheel to exert a force on the
ground parallel to the surface when you push the pedals, and you want the force with which you push
the pedals to correspond to that surface force. You want the brakes to work whenever you pull the
brake levers. Most of what you want from your bicycle is "component reliability". Why on earth would
anyone doubt that it is important?

A question. What important safety properties of a bicycle are *not* reducible to component reliability?

I mentioned your comment to an eminent friend (who has had
> to deal with the human fallout from multiple accidents) and he said "There are no banal questions
> about safety. Anyone asking questions and interested in safety is to be applauded."

Really? Questions have an audience. It makes a lot of sense to discuss the reasons for coding
standards with first- or second-semester computer science students who have never written a serious
program used by others, just as it makes a lot of sense to discuss the following questions with
children:

Why does a bicycle have brakes?
Why do you look to see if traffic is coming before you cross the road?
Why is there a rule to drive on a fixed half of a road?
Why are there speed limits on roads with mixed traffic and crossing traffic?
Why are there speed limits on roads with limited forward visibility?

However, when prefaced with "dear fellow safety professionals", one might consider them banal.

Similarly, those who have never flown an airplane may wonder why checklists are used for
configuration for key phases of flight such as landing. Once you have flown an airplane and learned
a little of what happens to others who fly, it becomes banal.

>> Because many people use C for
>> programming small embedded systems and
>> adhering to MISRA C coding guidelines enables the use of static
>> analysis tools which go some way
>> (but not all the way) to showing that the code does what you have said
>> you want it to do.
> 
> Those people could **just** use static analysis tools, and get the same benefit. 

Not so in general. Static analysis tools geared towards a specific coding standard are usually far
more effective than those which are not. Consider SPARK and SCADE. Also consider the project
mentioned above which exercised the Sun HW. The aerospace manufacturer paid (lots) for bespoke
analysis. There was a reason for that.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180917/92122807/attachment.sig>