Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

From: Les Chambers < >
Date: Tue, 1 Mar 2016 20:46:04 +1000


Peter

PBL:First, standards don't mandate. They purport to describe the state of the art.

Les: Refer EN 50128 Table A.16 - Modelling Referenced by clause 13 (D.5, Item 2. Finite state machines (highly recommended for SILs 1 - 4))

Les: Close but no cigar. At least this helps the client decide to mandate the practice given it is highly recommended by a standards body (with some gumption).

PBL: Standards are mostly concerned to describe checks and balances and things to ensure which best practice has shown necessary.

Les: Not true. Many life-cycle standards are highly prescriptive describing activities and deliverables. Document standards take it to the next level describing what should go in each paragraph of a document.

PBL:I don't know anyone who does that kind of visual pattern recognition using a state machine.

Les: What you're talking about here is deriving meaning from a transducer signal. Once the meaning is derived (eg a human has entered protected space) this would be fed to a state machine that would change the mode of operation of the machine (e.g. a transition to the shutdown state). Further, state engines are useful in all kinds of contexts, not just control systems modelling. Anywhere memory is required. For example is the subject moving to the left or to the right or away or toward. Figuring this out would require memory from the last scan and the scan before that and the scan before that. A great app for state engines.

PBL:That might be why Fagan inspections are such a good idea.

Les: If a software mess gets as far as Fagan inspection it's too late. You cannot inspect quality into software. Mandating state engines is a proactive measure that almost always assures the quality of software before it gets anywhere near an inspector. Further, the modern automobile has millions of lines of code. Do you honestly believe that even a minute subset of that code is inspected in any way shape or form. It's too expensive and it's not done.

PBL: People developing the highest quality software are keen on assuring determinism and like to use the word "unambiguous",

Les: I spent a decade of my career working with the state engine on a daily basis in chemical processing reactor control. I never heard the word unambiguous uttered. It was not in our vocabulary. We didn't need to consider it. What we were doing was deterministic by design. There were no useless debates about an ambiguity or the lack of. For this reason we are able to spend more time concentrating on our work which was highly deterministic and highly safe.

Les: going back to your comment: "standards don't mandate." This is a transparently untrue statement for a communications protocol standard, which if not followed to the letter will destroy interoperability of systems. My point is that this discipline must also be applied to well known and highly effective development models and practices to the point where they can be validated. It's 2016 and we are still sweating the small stuff - arguing the point over ambiguity, when we should be solidifying the basis on which we build systems so we can deal more effectively with the massive problems of largeness that we all face.  

Les

-----Original Message-----
From: systemsafety
[mailto:systemsafety-bounces_at_xxxxxx Peter Bernard Ladkin
Sent: Monday, February 29, 2016 4:43 PM
To: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

On 2016-02-28 23:53 , Les Chambers wrote:
> I look forward to the day when standards bodies screw up the courage
> to mandate the state engine as the core modelling technique in control
systems.

First, standards don't mandate. They purport to describe the state of the art.

Second, people who are writing/modifying the international software safety standards are not keen on telling people how to design and build software. They mostly come from companies which have their own software development processes and nobody wants to be told to scrap what they are doing and do something different, especially when that suggestion comes from a competitor. Standards are mostly concerned to describe checks and balances and things to ensure which best practice has shown necessary.

Third, although state machines have been prominent in the most widely-used development techniques (I use the word "technique" loosely) such as SA-RT, modern control systems have aspects which cannot effectively be modelled as transducers. For one example, communications (most control systems nowadays are distributed in some sense). For another example, the requirement for industrial robots that, when they are operating, no human shall enter the protected space is realised today by artificial-vision sensors rather than by building a metal cage with an interlock on the door. I don't know anyone who does that kind of visual pattern recognition using a state machine.

> Without these two fundamental approaches I and many people like me
> would have a huge problem understanding our own code two weeks after
> we wrote it

That might be why Fagan inspections are such a good idea.

> When will these standards wonks understand that pussyfooting around
> using terms like "unambiguous graphical representation" is unhelpful,
> creating a massive ambiguity in the standard itself which,

I think you'll find out that that is coming rather than going. People developing the highest quality software are keen on assuring determinism and like to use the word "unambiguous", I think for good reason. And almost everybody uses graphical representations somewhere during SW development (the Lustre graphics in SCADE, for example). Why, there is even a YouTube video explaining to people about Mealy&Moore machines .... and unsurprisingly it uses what we are calling unambiguous graphical representations. https://www.youtube.com/watch?v=S352lyPZP00

PBL
Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany Je suis Charlie Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue Mar 01 2016 - 11:46:36 CET

This archive was generated by hypermail 2.3.0 : Fri Apr 19 2019 - 12:17:07 CEST