Basics of advancedsoftware systems - RealTime-at...

Basics of advanced software systemsLecture 1 – introduction to the design of critical

systems

Nicolas Navet – [email protected] 24 Feb 2012

Module overview

o Lecturer: Nicolas Navet, [email protected]

o Lectures: Wed. 9h45-12h30 from week 8 to week 21 except

week 14 (on 06/04/2012)

o Grade: Weighted average of examination and practical works (2

TPs)

o Materials: (will be) available on internal moodle and is available

from http://www.loria.fr/~nnavetfrom http://www.loria.fr/~nnavet

o Objective: “introduction to dependability, formal methods, real-

time computing, Model Driven Development” to provide

1. Basics of the design of critical systems

2. Prepare corresponding Master courses

24/02/2012N. Navet - Basics of Advanced Software Systems - Université du Luxembourg - 2

Module structure and objectives

Principles of formal methods (21UE)

o Understand when formal

methods are appropriate and what

to expect from them

o Provide first practical experience

MDE withexecutable UML (3UE)

Real-time Computing (15UE)

o Understand network

and processor scheduling

issues

o Get to know RT

o Introduction to MDE:

PIM, PSM, etc

o What is xUMLwrt UML?

xUML vs fUML

3

o Provide first practical experience

in formal verification: modeling,

specification of properties,

verification and result analysis

o Give an insight (limited) into the

theory underlying formal methods

o Get to know industrial

applications of formal methods

and existing tools

o Get to know RT

software & hardware

technologies

o Design methods of

large and complex critical

embedded systems

o Illustration on

Automotive Embedded

Systems

xUML vs fUML

o Domain modeling and

action language

o UML modeling tools

capabilities wrt xUML

N. Navet - Basics of Advanced Software systems - Université du Luxembourg

Real-time computing

1. Overview of real-time operating systems : benefits,

features, standards, hypervisors

2. Task scheduling : static cyclic vs dynamic scheduling

(EDF/FPP), multiprocessor: global vs partitioned

3. Lab. work : Configuring a multi-core automotive ECU -

partitioned / FPP & static-cyclic scheduling

4. Basics of real-time distributed systems : priority

buses, switched Ethernet networks, time-triggered

architecture

24/02/2012N. Navet - Basics of Advanced Software systems - Université du Luxembourg - 4

Formal methods

1. Introduction: motivations, from semi-formal to formal

methods, current use in industry

2. Developing models : automaton, specification of

correctness properties

3. Verification Techniques : simulation, model checking,

schedulability analysis, theorem proving, etc

4. Focus : Promela Spin for the verification of concurrent

processes

5. Lab work: modeling & verification of an electronic purse


Introduction to the design of critical Introduction to the design of critical

systems

N. Navet - Basics of Advanced Software systems - Université du Luxembourg 24/02/2012 - 6

Outline for today

1. Critical systems, dependability vs security

2. Validation & verification and their means

3. Automotive Embedded Systems and threats to their

dependabilitydependability

4. Focus on timing constraints

5. Trends in the development of safety critical systems:

safety standards, technologies and MDD


Embedded systems in our day-to-day life : some of them are critical in the

sense they are subject to dependability constraints

8

Dependability vs Security [from Laprie et al, 3]

SecurityDependability

“ability to deliver

a service that

can justifiably be

trusted ”

“absence of unauthorized access to, or

handling of, system state”

“unauthorized”

system alteration

Availability Reliability Safety Confidentiality Integrity Maintenability

Readiness for

usage

Continuity of

service

Absence of

catastrophic

consequences

Absence of

unauthorized

disclosure of

information

Absence of

improper

system

alterations

Ability to

undergo repairs

and evolutions

Types of critical systems

1. Safety-critical : failure may endanger human life, ex:

automotive, aerospace, railway signalling

2. Security-critical : failure means non-authorized

access to sensitive information, ex: medical records,

electronic transactions, security databases

3. Business-critical (quality critical): cost of failure is 3. Business-critical (quality critical): cost of failure is

very high, ex: semiconductor, financial applications,

telecommunication


Some famous failures: bug in floating-point division hardware of the Intel’s Pentium

(1994), Ariane 5 self-destruction (1996 – number conversion problem), loss of Nasa’s

Mars Climate Orbiter (1999 – mixture of pounds and kilograms), see

http://www5.in.tum.de/~huckle/bugse.html for more

Validation, Verification & Certification

• Validation: “system/component satisfies specified

requirements”

• Verification: “products of a given development

phase satisfy conditions imposed at the start” (code

correct wrt specification – does not mean spec. is

correct)correct)

• Certification is “a written guarantee that a system or

component complies with its specified requirements

and is acceptable for operational use” → certification

processes and authorities are specific to a domain,

e.g. aviation, nuclear power-plants, railway, etc


(Some) means of verification and

validation

• Simulation : execute and monitor a model of the

system

• Formal methods : formal modeling + formal verification → proof of properties of the specification

and possibly proofs of correctness of implementation

• Risk analysis : identify hazards and their causes,

quantify probability of occurring, counter-measures, quantify probability of occurring, counter-measures,

etc

• Testing : execution of a number of test cases on a

prototype

• Static analysis of the code

• Fault-injection in hardware and software


Testing, static analysis and fault-injection cannot take place early in the design cycle

Methods complement each other – none alone is sufficient

Defects should be detected as early

as possible

• Cost of change (time + money) is much higher in the

late phases of the development cycle

Costs

of

change

Re

qu

irem

en

ts

De

sign

De

velo

pm

en

t

Testin

g

De

plo

ym

en

t

From Boehm


• Formal methods allow to reduce defects introduced

in the early phases and reduce testing efforts

afterwards

Time

change

Re

qu

irem

en

ts

De

sign

De

velo

pm

en

t

Testin

g

De

plo

ym

en

t

2


Automotive Embedded SystemsThreats to their dependability

2

Electronics is the driving force of innovation

in automotive

– 90% of new functions use software

– Electronics: 40% of total costs

Many new functions are safety critical:

brake assist, cruise control, lane keeping,

dynamic lights, etc

Picture from [10]

Strong costs and time-to-market constraints !

– Electronics: 40% of total costs

– Huge complexity: 70 ECUs, 2500 signals,

>6 comm. protocols, multi-layered run-time

environment (AUTOSAR), multi-source

software, multi-core CPUs, number of

variants, etc

BMW 7 Series networking architecture [11]

� ZGW = central

gateway

� 4 CAN buses

� 1 FlexRay Bus

� 1 MOST bus� 1 MOST bus

� Several LIN Buses

(not shown here)

� 1 Ethernet bus

� Wireless

Optimizing the use of resources is an

industrial requirement

Why ? • Complexity of the architectures

• Hardware costs / weight, space, consumption, etc

• Need for incremental design

• Industrial risk and time to master new technologies

• Performances (sometimes):

ex1: one 60% loaded CAN network may be more efficient ex1: one 60% loaded CAN network may be more efficient

that two 40% networks interconnected by a gateway

ex2: cost of communication in distributed functions

• Limits of current technologies (CPU frequency w/o fan)

Needed : configuration and verification algorithms

with performance guarantees

Main impediments to safety : complexity!

Technologies: numerous, complex and not

explicit. conceived for critical systems

– e.g.: more than 150 specification documents

(textual) for Autosar, no two implementations

can behave identically!

Size of the system!

– Number of functional domains, buses, gateways,

ECUs, size of code, tasks, wiring, number of

variants, etcAutosar Basic Software

variants, etc

Design process

– Most developments are not done in-house :

less control on externalized developments

– Carry-over / Vehicle Family Management : need to

share/re-use architecture and sub-systems between

several brands/models with different requirements [2]

– Optimized solutions for each component / function

does not lead to a global optimal [2]Wiring harness

Picture from [11]

3


Focus on the timing constraints

3

Several hundreds of timing constraints –

example of an end-to –end constraints

Constraint :

brake light on < 50ms

Stimulus Response

Figure from [12]

Verification of the timing constraintsPersonal view / experiences

« Worst-case » deterministic analysis

system level

« correctness by construct »

and optimal synthesis

Probabilistic performance & safety

assessment - system level

bursts of errors

Single transmission errors

Interarrival times

Mostly

ahead

of us!

Simulation tools (SBFI)

200919971995

« Smart » monitoring tools

« Worst-case » deterministic analysis (sub-system)

Probabilistic analysis (sub-system)

system level

COTS tools

Why timing constraints may not be

respected occasionally?

Lack of precise specification : hard to identify

the right timing requirements for each function

Lack of traceability : from the architects to the suppliers

Flaws in the verification:

– Knowledge of the system and its environment is incomplete:

• What is done by the suppliers?

• Implementation choices really matter and standards do

not say everything

MiddlewareComm.

task5ms

2

Waiting queue:

- FIFO

- Highest Priority not say everything

• Environmental issues: EMI, α-particles, heat, etc

• Traffic is not always well characterized and/or well modeled

e.g. aperiodic traffic ?! see [5]

– Testing /simulation alone is not enough

– Analysis is not enough too:

• Analytic models, especially complex ones, can be wrong

(remember “ CAN analysis refuted, revisited, etc” [6] ?!)

• They are often much simplified abstraction of reality

and might become optimistic: neglect FIFOs, hardware limitations

1

2 - Highest Priority

First

- OEM specific

CAN Controller

buffer Tx

CAN Bus

9 6 8

Illustration: Worst-Case Response Times on a CAN

bus - Frame waiting queues are HPF, except ECU1 where queue is

FIFO, the OEM does not know or verification software cannot

handle it

Analysis Setup:

- Typical body network with 15 ECUs

generated by NETCARbench

- WCRT computed with NETCAR-Analyzer

Many high-priority frames are delayed here because

a single ECU (out of 15) has a FIFO queue …

Evolution in the development of 4


Evolution in the development of

safety critical software - Safety standards

- Design process

- Technologies, computing platforms

4

Safety standards and certification processes

cannot be ignored

IEC61226

IEC60880

…

ISO 26262DO 178 / DO 254

EN 50126/28/29

Airbus: 1/3 of the design costs of an airplane due to certification !

ISO 26262DO 178 / DO 254

IEC 61508

ECSS / CNES

Model Based Design for dependable system development

no more hand-coded programs ?! Requirements

Design Verification

code generation

Scade

Simulation

Verification

DesignVerifyer State machine to C

certified transformation tool

C to binary

Compiler

Certification

Kit

End-to-end design flows with proven outcomes at each step

MBD: domain-specific models and tools

must be dealt with

requirements

sysML?

Some open issues: semantic interoperability,

pivotal language? local versus global verification

Technology : from domain specific to cross-

industry solutionsToday :

- Avionics: IEEE1553, AFDX, TTP, ARINC 653, ..

- Automotive: CAN, FlexRay, Autosar, Lin, ..

- Power plants: Alstom Alspa, Siemens Teleperm, ..

Tomorrow :

- Convergence of safety standards

[Thomesse05]

- Computing platforms: cross-industry solutionS with profile per

application domain and scalable dependability : e.g., switched

Ethernet, virtualization, etc

- Architecture patterns with specific dependability capabilities

Calcu lateur

N °1

Sw itch

Sw itch

Sw itch

Sw itch

Sw itch

Sw itch

Sw itch

Sw itch

Calcu lateur

N °i

What is needed now: achieving affordable

dependability

1. A large body of standards, development processes,

tools, and know-how is available for the design of

critical systems

2. Formal methods are now sufficiently mature to handle

industrial problems – needed: reduce the costs by industrial problems – needed: reduce the costs by

automatization & integration within standard

development environments

3. Simpler systems are more amenable to verification!


5


References

5

References [1] N. Navet, F. Simonot-Lion, editors, The Automotive Embedded Systems Handbook, Industrial Information Technology series, CRC Press / Taylor and Francis, ISBN 978-0849380266, December 2008.

[2] P. Wallin, Axelsson, A Case Study of Issues Related to Automotive E/E System Architecture Development, IEEE International Conference and Workshop on the Engineering of Computer Based Systems, 2008.

[3] A. Avizienis, J.C. Laprie, B. Randell, “Dependability and its threat: a taxonomy", IFIP Congress Topical Sessions 2004.

[4] A. Ireland, slides of the course “Distributed Systems Programming - formal Methods for Distributed Systems”, 2011. Available on the web

[5] D. Khan, N. Navet, B. Bavoux, J. Migge, “Aperiodic Traffic in Response Time Analyses with Adjustable Safety Level“, IEEE ETFA2009, Mallorca, Spain, September 22-26, 2009.

[6] R. Davis, A. Burn, R. Bril, and J. Lukkien, “Controller Area Network (CAN) schedulability analysis: Refuted, revisited and revised”, Real-Time Systems,


schedulability analysis: Refuted, revisited and revised”, Real-Time Systems, vol. 35, pp. 239–272, 2007.

[7] M. D. Natale, “Evaluating message transmission times in Controller Area Networks without buffer preemption”, in 8th Brazilian Workshop on Real-Time Systems, 2006.

[8] C. Braun, L. Havet, N. Navet, "NETCARBENCH: a benchmark for techniques and tools used in the design of automotive communication systems", Proc IFAC FeT 2007, Toulouse, France, November 7-9, 2007.

[10] P. Leteinturier, “Next Generation Powertrain Microcontrollers”, International Automotive Electronics Congress, November 2007.

[11] H. Kellerman, G. Nemeth, J. Kostelezky, K. Barbehön, F. El-Dwaik, L. Hochmuth, “BMW 7 Series architecture”, ATZextra, November 2008.

[12] AUTOSAR, “Specification of Timing Extensions”, Release 4.0 Rev 2, 2010.

Basics of advancedsoftware systems - RealTime-at...

Documents

Transcript of Basics of advancedsoftware systems - RealTime-at...