[SystemSafety] Logic

Wed Feb 19 13:49:13 CET 2014

I fully agree. On one side with have specialists of a tiny (less than 5%) part of industry with (fundamental, vital and interesting) discussions about FM. On the other side (95%) the situation described below where even C and ADA sound "exotic".

However the fact is that if an organisation hire FM specialised, or at least "aware", engineers, it will have a chance of getting, on the medium term, two benefits :
* an FM specialist is probably a guy that knows ALSO how to do basic vital things totally forgotten or never approached in the organisation such as building specification, defining the expected properties of the product
*  an FM specialist will have a tendency to structure things so that they can be modelled, bringing at least consistency, comprehensiveness, correctness... in the general design processes

This would already be a huge step forward.

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 59 11 96 82
Bertrand.ricque at sagem.com

-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Michael J. Pont
Sent: Wednesday, February 19, 2014 1:28 PM
To: systemsafety at techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Logic

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 TechFak.Uni-Bielefeld.DE
#
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."
******
" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
#