[SystemSafety] Logic

[Peter Bernard Ladkin]

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  www.rvs.uni-bielefeld.de