[SystemSafety] Logic

Les Chambers les at chambers.com.au
Sat Feb 22 08:45:58 CET 2014


Peter
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: http://www.controlglobal.com/articles/2006/029/.
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:
http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=58932.  I found
this article nothing short of inspiring. 
Good luck with your efforts in this area.
Cheers
Les

-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Peter Bernard Ladkin
Sent: Friday, February 21, 2014 6:47 PM
To: systemsafety at lists.techfak.uni-bielefeld.de
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
"formal
>> 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
diagrams
>> 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
now
>> 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  www.rvs.uni-bielefeld.de




_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE



More information about the systemsafety mailing list