Re: [SystemSafety] Logic

From: Les Chambers < >
Date: Sat, 22 Feb 2014 17:45:58 +1000

Q/> Could you call it a version of Controlled English? Was it ambiguous or was it unambiguous?

A/ unambiguous. The English was the operations manual. The operators basically watched things happen for most of the time. Much like an aircraft on automatic pilot. They were supervisors of automation. Every now and then some intervention might be required. For example, the system might have discharged a batch reactor to storage tanks, but it is still stuck in the discharge state, even though it is empty. Usually when a reactor was discharged it would automatically transition to a wait state, where it waits for the conditions that need to occur for it to be charged for the next batch. Why hasn't gone to the wait state? Okay, the operator looks up the English which is in a printout on the desk. He looks at the English language description of the logic around the state transition from discharge to wait and finds that the reactor weight reading (xxx kg) needs to be below a certain value and the flow reading in the discharge line needs to be zero. Say he knows that the weigh cells on the reactor are out of calibration. It actually is empty, because the discharge pump is still running and the flow in the discharge line is zero. So he manually forces the reactor into the wait state.
The English language, therefore had to be very specific, unambiguous and always up-to-date, reflecting the code. Failure to keep it up-to-date was a safety hazard, much like sending a pilot up with the wrong aircraft operations manual.
The useful thing about state engines is that, at the surface, they present a simple metaphor that most people can easily understand. As I think Steve mentioned the challenge is to achieve this with other formal methods - complex as you like under the hood, but simple when viewed from the outside. I can't emphasise enough that these methods saved my company a fortune. The story is available here: They have since partnered with ABB and, I assume, are implementing similar ideas on the ABB System 800xA.

I know I am preaching to the converted, but I find it difficult to understand why any educational institution would be debating whether or not to teach these methods. It's a no-brainer. There must be many opportunities to conduct joint research with large-scale users of control systems and control systems vendors. After all, don't we as software engineers, depend on computer scientists just as a mechanical engineers depend on the laws of physics. Unfortunately, cooperation between academia and industry is patchy. A great example of success is the Carnegie Mellon software engineering institute's work on architecture. Refer: I found this article nothing short of inspiring. Good luck with your efforts in this area. Cheers

-----Original Message-----
From: systemsafety-bounces_at_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx Peter Bernard Ladkin
Sent: Friday, February 21, 2014 6:47 PM
To: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Logic

The bit I take away from Steve's engaging tale (thank you, Steve!) is that

  1. A lot of attention was paid to the requirements and general design engineering before code was written. And that seems to have been where most (in terms of effort) of the difficulties and potential slip-ups were resolved.
  2. The specification languages used were formal (class diagrams, state charts) and the semantics was unambiguous. That is what I suggested needed to be learnt in my Logic White Paper.

I would call point 2 use of a formal method. Steve suggests it's not "in the sense ..... hotly
debated here." If not, how about a suggestion of a term for "use of formal description language with
an unambiguous semantics" that I and others can use?

On 2014-02-21 01:20 , Steve Tockey wrote:
>> I should add that what was done on these projects was not strictly
>> methods" in the sense that's being hotly debated here. We didn't use Z,
>> VDM, or any of those formal languages. We didn't use theorem provers
>> either. We used UML (and pre-UML because of project timing) class
>> and state charts mostly, but we had a carefully defined and enforced (via
>> the model inspections) single interpretation of that modeling language.

The bit I take away from Les's tale (thank you, also, Les!) is

  1. Same as above
  2. Use of cooperating FSMs as a paradigm.

On 2014-02-21 02:52 , Les Chambers wrote:

> .... All

>> projects started with something we called "English language", a clear
>> statement of the operating discipline structured such that it could be
>> easily transformed into a design models - something similar to what is
>> called Requirements State Machine Language.

Could you call it a version of Controlled English? Was it ambiguous or was it unambiguous?

>> .......
>> .....You could write any program you liked as long
>> as it implemented the plant control system as a set of cooperating finite
>> state engines.

A major engineering company which produces some of the most sophisticated and expensive engineering
artefacts around uses either Lustre or Statecharts for most of its SW projects and builds very
successful, comparatively highly reliable SW. Both Lustre and Statecharts are based on the paradigm
of communicating FSMs. With an underlying formal language expressing states and transitions. (I
already knew some of this but thank you, anonymous, for expanding on it!)

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319

The System Safety Mailing List

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Sat Feb 22 2014 - 08:46:17 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST