Re: [SystemSafety] Logic

From: Peter Bernard Ladkin < >
Date: Sun, 16 Feb 2014 20:23:24 +0100

Good solid points, John. But there are some counterarguments that I need to take seriously.

On 2014-02-16 17:58 , John Knight wrote:
> ...... Research projects need software rapid prototypes to
> support investigation in areas such as AI and robotics. These are "throw-away" prototypes that
> should never make it into production and usually don't.

I don't necessarily buy that characterisation.

We have a big lab/"centre of excellence" in AI/psychology/linguistics/biology/robotics called CITEC, which has an expensive new building and a hundred or so researchers, which our degree courses feed into. CITEC is part of "it's OWL", which is an industry/academic consortium comprising a few dozen organisations from the eastern portion of our state. This consortium was set up as the first area consortium in the Federal-Government-"sponsored" strategic project "Industrie 4.0", which aims to introduce the "new robotics" into industrial processes.

"Rapid prototypes" as coders use the term does not mean the same thing as "prototypes" as industrial engineers mean it. A prototype of a roof-welding robot for a prefab building must weld roof bits together and occasionally break. A "rapid prototype" of SW built to usual SW RP standards would let it occasionally weld your hand to the building door, and then you debug. That won't fly.

There is an internal issue even within CITEC. There are lots of groups producing code, each piece of which demonstrates one tiny thing. Suppose you want to put that code together in one robot (there are only a few available). How do you get that code individually to work on one platform? How do you get two pieces of code written separately to work on the platform concurrently? Answer: you need to engineer the code to an interface specification. And you can't devise an interface specification unless you know what a specification is and how to write one. And you don't know what a specification is or how to write one unless you have some experience with a formal description language and its unambiguous semantics. I doubt you can even reliably write code conforming to an interface specification, and verify reliably that it does, unless you know something about formal descriptions and unambiguous semantics.

> I am talking about software products that are part of engineered computer systems which will subject
> others (possibly the general public) to risk. Higher education has a responsibility to prepare
> professional engineers to perform that engineering.

That works in the UK, where becoming a CEng is regarded as normal career progression for a computing specialist in industry.

But in our university and in most universities in the US it would elicit the comment that "we don't educate professional engineers". Almost no SW people in the US are PEs. In Germany, you are an engineer if you got a degree from an engineering program at a university or "Fachhochschule". Bielefeld doesn't have an engineering program. We do give engineering PhDs, but neither Bachelor's nor Master's.

> * Engineers are responsible for what they do.
> * Engineering is a profession not some amateur activity.

Both of which are true but would be deemed irrelevant in my specific case, and in many situations in the US, unless one can establish that people building hopefully-dependable SW are "Engineers" in some formal sense. Which they may well be in the UK.

The point about Altran and SPARK for me in this context is that you can't work with the innards of any of those systems (let alone build them) unless you understand the basics about formal description and unambiguous semantics.

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
systemsafety_at_xxxxxx Received on Sun Feb 16 2014 - 20:23:35 CET

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