Re: [SystemSafety] Logic

From: Michael J. Pont < >
Date: Wed, 19 Feb 2014 12:28:13 -0000


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



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed Feb 19 2014 - 13:28:26 CET

This archive was generated by hypermail 2.3.0 : Wed Feb 20 2019 - 01:17:07 CET