Modellbasierte Softwareentwicklung (Model-driven Development (MDD))

(1)

Stefan Henkler - 1

Universit ät Paderborn Software Engineering Group

Prof. Dr. Wilhelm Schäfer

Modellbasierte Softwareentwicklung

(Model-driven Development (MDD))

Wilhelm Schäfer

FG Softwaretechnik

Raum E3.356

wilhelm@uni-paderborn.de

Sprechstunde: Montags 16:00 – 17:00 Uhr

Übungen: Stefan Henkler

shenkler@uni-paderborn.de

(2)

Modellbasierte Softwareentwicklung

Stefan Henkler - 3

I.1 Accident Examples

o

Between June 1985 and January 1987 the

Therac-25 radiation machine killed (at least)

four patients due to a software error

o

On 14 September 1993 in the Airbus

A320-211 aircraft accident in Warsaw one crew

member and one of the passengers lost their

lives

o

In an aeroplane crash on 1st July 2002 near

Überlingen /Lake Constance (Bodensee) 71

people are killed

The Therac-25 Accidents

o

Therac-25 is a machine for radiation therapy

(to treat cancer) produced by AECL

o

Between June 1985 and January 1987 (at

least) six patients received severe overdoses:

§

two died shortly afterwards

§

two might have died but died because of cancer

§

the remaining two suffered of permanent

(3)

Modellbasierte Softwareentwicklung

Stefan Henkler - 5

The Therac-25 (1/2)

The Therac-25 (2/2)

Functional principle

o

“scanning magnets” are used to spread the beam and vary

the beam energy

o

Therac is a “dual-mode” machine

§

electron beams are used for surface tumours

§

X-ray for deep tumours

X-ray and electron mode

o

a tungsten target and a “beam flattener” is moved in the path

to the rotating turntable

o

the target generates the X-rays but absorbs most of the

beam energy

o

the required energy has to be increased by a factor of 100,

compared to electron mode

(4)

Modellbasierte Softwareentwicklung

Stefan Henkler - 7

Major event time line (1985)

1985

Jun

3rd: Marietta, Georgia, overdose.

Later in the month, Tim Still calls AECL and asks if overdose by

Therac-25 is possible.

Jul

26th: Hamilton, Ontario, Canada, overdose; AECL notified and

determines microswitch failure was the cause.

Sep

AECL makes changes to microswitch and notifies users of increased

safety. Independent consultant (for Hamilton Clinic) recommends

potentiometer on turntable.

Oct

Georgia patient files suit against AECL and hospital.

Nov

8th:

Letter from Canadian Radiation Protection Bureau to AECL

asking for additional hardware interlocks and software changes.

Dec

Yakima, Washington, clinic overdose.

Major event time line (1986)

1986

Attorney for Hamilton clinic requests that potentiometer be installed

on turntable.

Jan

31st: Letter to AECL from Yakima reporting overdose possibility.

Feb

24th: Letter from AECL to Yakima saying overdose was impossible

and no other incidents had occurred.

Mar

21st:

Tyler, Texas, overdose. AECL notified; claims overdose

impossible and no other accidents had occurred previously. AECL

suggests hospital might have an electrical problem.

Apr

7th:

Tyler machine put back in service after no electrical problem

could be found.

11th: Second Tyler overdose. AECL again notified. Software

problem found.

(5)

Modellbasierte Softwareentwicklung

Stefan Henkler - 9

Major event time line (cont. 1986)

1986

May

2nd: FDA (US Food and Drug Administration) declares Therac-25

defective. Asks for CAP (Corrective Action Plan) and proper

renotification of Therac-25 users.

Jun

13th: First version of CAP sent to FDA.

Jul

23rd:

FDA responds and asks for more information.

First user group meeting.

Aug

26th: AECL sends FDA additional information.

Sep

30th: FDA requests more information.

Nov

12th: AECL submits revision of CAP.

Dec

Therac-20 users notified of a software bug.

11th: FDA requests further changes to CAP.

22nd: AECL submits second revision of CAP.

Major event time line (1987-1988)

Jan

17th:

Second overdose at Yakima.

26th:

AECL sends FDA its revised test plan.

Feb

Hamilton clinic investigates first accident and concludes there was an overdose.

3rd:

AECL announces changes to Therac -25.

10th:

FDA sends notice of adverse findings to AECL declaring Therac-25 defective

under US law and asking AECL to notify customers that it should not be used for

routine therapy. Health Protection Branch of Canada does the same thing. This lasts

until August 1987.

Mar

Second user group meeting.

5th:

AECL sends third revision of CAP to FDA.

Apr

9th:

FDA responds to CAP and asks for additional information.

May

1st:

AECL sends fourth revision of CAP to FDA.

26th:

FDA approves CAP subject to final testing and safety analysis.

Jun

5th:

AECL sends final test plan and draft safety analysis to FDA.

Jul

Third user group meeting.

21st:

Fifth (and final) revision of CAP sent to FDA.

1988

Jan

29th:

Interim safety analysis report issued.

Nov

3rd:

Final safety analysis report issued.

(6)

Modellbasierte Softwareentwicklung

Stefan Henkler - 11

Lessons learned from Therac-25

accident:

o

Accidents are seldom simple

o

Accidents are often blamed to single source

o

Management inadequacies, lack of following

incident reports

o

Involvement of management, technicians, users,

and government

o

Unrealistic risk assessment

o

Overconfidence in software

o

Less-than-acceptable software-engineering

practices

A320-211 Accident in Warsaw

A high-tech

aeroplane

with special

safety

features

happens to

be too

intelligent

for the crew.

(7)

Modellbasierte Softwareentwicklung

Stefan Henkler - 13

A320-211 Accident in Warsaw

o

The aircraft was cleared for a Warsaw runway 11

approach and were told of the existence of

windshear on the approach. The Airbus' right gear

touched down 770m from the runway 11 threshold.

The left gear touched down

9 seconds later

,

1525m from the threshold.

windshear

Delayed Breaking

Only when the left gear touched the runway, automatic systems

depending on oleo strut (shock absorber) compression

unlocked the use of ground spoilers and engine thrust

reversers. The wheel brakes, depending on wheel rotation

being equivalent of circumfential speed of 72 kts began to

operate after about 4 seconds.

Seeing the approaching end of the runway and the obstacle

behind it, the pilot steered the aircraft off the runway to the right.

The aircraft left the runway at a speed of 72 kts and rolled 90m

before it hit the embankment and an LLZ aerial with the left

wing. A fire started in the left wing area and penetrated into the

passenger cabin.

(8)

Modellbasierte Softwareentwicklung

Stefan Henkler - 15

PROBABLE CAUSE:

[Ladkin1994]:

"Cause of the accident were incorrect decisions and actions

of the flight crew taken in situation when the information

about windshear at the approach to the runway was

received. Windshear was produced by the front just passing

the aerodrome; the front was accompanied by intensive

variation of wind parameters as well as by heavy rain on the

aerodrome itself.

Actions of the flight crew were also affected by design

features of the aircraft which limited the feasibility of applyi ng

available braking systems as well as by insufficient

information in the aircraft operations manual (AOM) relating

to the increase of the landing distance."

Lessons learned from the

Airbus A320-210 accident:

o

Incorrect environment assumptions can result

in a

correct

working but

not safe

system

behaviour!

o

Smart and complex systems together with not

sufficient documentation (manuals) can result

in serious crew errors (

human factor

)

(9)

Modellbasierte Softwareentwicklung

Stefan Henkler - 17

Aeroplane Crash Bodensee

July 2002

Even redundant

and correct

working safety

equipment is

not enough

when

safety

policies

and

culture

are not

appropriate.

Reconstruction

(10)

Modellbasierte Softwareentwicklung

Stefan Henkler - 19

Chain of Events (1/3)

Collision and Wreckage

Distribution

(11)

Modellbasierte Softwareentwicklung

Stefan Henkler - 21

Lessons learned ?

o

Traffic alert and Collision Avoidance System (TCAS)

works in both machines

o

Short Term Conflict Alert (STCA) was not available

at ACC Zurich due to maintenance

o

The STCA of the Upper Area Control Center warns

two minutes prior to collision, but no connection via

the direct line could be established

⇒

Even reliable working equipment does not

guarantee safety when the safety policy at the

organizational level is not sufficient (see Swiss air

traffic control: ACC Zurich)

Example: The Railcab Project

o

A system of autonomous shuttles that builds

convoys to optimize their energy consumption

(Railcab Paderborn):

System of systems

o

Hard real-time

o

Safety-critical

o

self-Optimization

o

(SFB 614)

(12)

Modellbasierte Softwareentwicklung

Stefan Henkler - 23

Video

Shuttle Coordination

Challenge: Safe Behavior

Background:

Ensure safe operation is of paramount importance

Operation must be safe also in the presence of hardware faults

State of the Art:

Testing:

Executing the system to detect safety violations.

not sufficient

Modelchecking:

(13)

Modellbasierte Softwareentwicklung

Stefan Henkler - 25

Resulting Challenges & Future

Challenges

Software is the Bottleneck

In the (recent) past, an embedded system would be either

small or simple, or the composition of

almost non-interacting

imported and assembled components. The trend is that the

number and complexity of functions will increase drastically.

Increasing

complexity

is making the present design

methodologies rapidly obsolete.

Productivity

of the order of

six (or less!) lines of embedded code per day per person is

common in HRT embedded systems.

The cost of developing a new plane (of the order of several

billions of Euros) is about

½ related to embedded software

and electronics subsystems.

[Bouyssounouse&Sifakis2005, p. 4]

Complexity of Design Flows and

Supply Chains

The electronics industry is increasingly

disaggregating: new opportunities are now opening

up for subsystem and component suppliers. These

dynamics are stressing the

interfaces

among the

supply chain players. Several

quality problems

and

time -to-market delays

can be traced to

specification

and

system integration

difficulties.

Among the most challenging supply chains to support

are the automotive and avionics chain.

(14)

Modellbasierte Softwareentwicklung

Stefan Henkler - 27

A New Software Design Paradigm

The highest ranked recommendation was to

develop a

new software design paradigm

that recognizes that uncertainty and emergent,

unanticipated behaviors are likely to be forever

present in the software- intensive systems of

the future due to their

ultra -large

,

networked

,

distributed

, and

diffuse-control natures

.

[NSF-DLS2003, Executive Summary]

Model-Based Development

A promising approach for solving these problems is

model-based development

: models can serve as a

vehicle for communicating information between

business process engineers

,

control engineers

and

computer scientists

, and can also provide an

additional basis for preimplementation validation of

requirements and quality properties as well as for

automatic generation of source code. […].

(15)

Modellbasierte Softwareentwicklung

Stefan Henkler - 29

Übungsgruppen

o

Mögliche Termine:

§

Dienstag: …