[SystemSafety] Logic

[Michael J. Pont]

My thoughts on the teaching of what I would call "formal methods" (in
response to Peter's question yesterday, and follow-up discussions).

Brief context.

My area of interest is real-time embedded systems.  I began work on my first
such system almost 30 years ago.  I've spent the intervening period in the
UK university sector and in industry (UK, Europe, further afield).  I now
spend 100% of my time in industry.  

My present organisation is usually contacted by companies when they are
having difficulty meeting safety / reliability requirements and / or when
they are about to develop a product in compliance with IEC 61508, ISO 26262,
DO-178, etc (perhaps for the first time).  The companies that I deal with
produce systems ranging from aerospace systems to household appliances.

In many cases (probably the majority of cases that I see), there is limited
evidence of "process" or documentation available from the "embedded team"
when I arrive at the company door.  Requirements documents are often *very*
basic, if they exist at all.  In many cases, this situation is inevitable
because the teams are very small (even in large organisations), and the
people involved have far too much to do.  Sometimes the main contribution
that I can make is to provide a fresh take on the problems, an extra pair of
hands - and support for a case to "the management" for additional resources.

My point with all of this is that - even if they were able to recruit some
smart new graduates with lots of experience in formal methods - this would
be unlikely to help the majority of the organisations that I see.  Before
these organisations are going to be in a position to make use of formal
techniques, they need some more basic foundations (detailed requirements
documents, linked design documents, code reviews, documented test procedures
linked to requirements, etc).  

[I accept that it can be argued that appropriate formal methods may help
with all of the above issues, but - in my view - most of the organisations
that I see aren't yet (anywhere near) ready to go this far.]  

It may - of course - be that the organisations I have closest contact with
are atypical: they are, after all, a self-selecting group.  However, while
I'm sure that there are many organisations that have mature processes in
place for the development of real-time embedded systems, I'm equally sure
that this isn't the norm.

If we assume - for the moment - that my model is correct, how do we ensure
that the situation is different in 10 years time?

If we want to "change the embedded world" through the teaching that we are
providing in universities, then I think we need to start by covering what I
would see as *core* software-engineering skills for the sector that I work
in (understanding system hazards, recording requirements, use of appropriate
software architectures, use of coding guidelines, code reviews, testing vs.
verification, etc).  On top of this, we can add formal methods - but I think
we need what I would see as the core skills first.

I appreciate that some people on this list may take a different view ...

Regards,

Michael. 

Michael J. Pont
SafeTTy Systems Ltd
www.SafeTTy.net