2008-10-09 - Bits and Chips Conference - Embedded Systemen Architecture patterns

Trends in embedded software Jaap van Ekris (Jaap.van.Ekris@DNV.com) Sander van den Berg (Sander.van.den.Berg@DNV.com) Software quality and architecture

Jaap van Ekris Slide

Sander van den Berg

Agenda
The trend of embedded systems
The risks of these new trends
A call for improvement
Software quality
System architecture
Architectural patterns

Increasing power…
Mechanical controls
Electromechanical controls
PLC Controller

The need for integrated systems…
A ship going about 100 KM/hour
Every move being controlled by 800 PLC’s
Having 30 physical screens on the bridge to control them
How fast can a captain react to a real emergency?

Software quality ≠ reliability
Usability of the user interface
Response speed
Tolerance to user errors
Data accuracy
Filedetectie faalt OR Detectie faalt Verwerking faalt Signalering faalt OR AND Lus faalt Detectorstat faalt Onderstation faalt Verwerking via VICNet faalt Verwerking via Partylijn faalt OR Inkomende Partylijn faalt Inkomende FEP faalt TOP faalt Uitgaande FEP faalt Uitgaande Partylijn faalt AND Beeldstand Onderstation 1 faalt Beeldstand Onderstation 2 faalt Beeldstand Onderstation 3 faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt

Extended ISO 9126 - Quint

Let’s integrate (and virtualize…)
1 virtualized flight deck (“glass” cockpit concept)
80+ applications,
many safety critical,
some pure on-board entertainment
Contained in 2 (redundant) avionics bays, each with 1 Central Core
1 network layer, compromised of 4 physical service busses
Will it prove to be reliable?

Is the sky the limit ?
Baggage handling Denver Airport
Initial acquisition $230 million
5 KM conveyors, 35 KM track, 3500 carts, 4000 KM wiring, 300 PC’s, 92 PLC’s
Complete object-oriented design
Real-time logistical nightmare
System abandoned after 12 years
Damages: $1,5 billion

Repair costs… req’s design code developm. acceptance operation tests tests 200 100 50 20 10 5 1 Relative cost to fix fault Phase in which fault was detected

But also unimportant systems...
Largest platform in the world (Petrobas 36)
An “unimportant” ballastsystem
Ommission in overall architecture lead to a blind spot in pressure build-up
Actuators did not close buffers
Effects:
Platform went down
Oil-pipes damaged
Loss:
11 people died (out of 175)
Spillage: 1500 ton crude
Oil Rig: $350 million
84.000 barrels a day production

How to deal with these trends?
More attention for the quality of individual components AND the system as a whole
More attention to design and architecture

How to do this?
Cost of Quality
Work differently, more Quality Assurance, less “development “ on site
More attention to testing
Design differently
Cost of Non-Quality
The costs of having defects in the field
Repair costs of systems
Liability
Brand name
© 2006 CIBIT

Will tooling help you?
Tooling (like MDD) alone will not help you, it will not provide you with architecture
You need to think ahead
Good (non-functional) requirements are essential
A good architecture is even more important

Quality is situational dependent
Not everything is important all the time
Much priorities are context dependent
Asking people, forcing them to make choices, will get you valuable info
Be observant about “obvious” omissions, some people assume things are standard!
How to implement?
Air Traffic Control Systeem Webapplicatie voor luchtvaartmaatschappij

Architecture views (4+1)
The logical view on the function describes the function in terms of functionality towards its users.
The process view of the function describes the processes and components that compose the function, as well as their interaction, triggers and cycle times.
The physical view of the function describes the mapping of the processes/components onto hardware (modules).
The development view of the function describes the decomposition of the function into distinctive layers and sub-functions.
The scenarios describes the primary interaction between components when a function is executed.

4+1 Modelling Physical View Development View Process View Logical View Scenarios

Attributing quality

Who talks to who in a complex system? Accuracy Usability Response time, Autonomous behaviour

A manual action scenario

A manual action scenario Reliability Resource behavior Response time

Or on a mega scale Reliability, Responsetime Understandibility, clarity bridge LAN PBS30 LAN EDS DFC77 PROCONTROL
LDS
WS70
EDS WS62 WS61 WS60 87TS011 Bus Kopp. Server 20 WS 20 Server 10 WS 10 A B WS 11 WS 21 WS 23 WS 12 WS 22 Server 10 WS 40 PMS Query PC DBMS Server Server 01 WS 30 WS 41 WS 31 A B LAN PMS Prodar UNA 87TS011 Bus Kopp. KEMA PC 87TS011 Bus Kopp. Prodar ABB 87TS011 Bus Kopp. Bus Kopp. 87TS50 87TS50 Bus Kopp. 87TS50 Bus Kopp. Bus Kopp. 87TS50 87TS011 87TS011 87TS011 Bus Kopp. Bus Kopp. Bus Kopp. 87TS011 Bus Kopp. PDAS WS66 Term. 87TS011 Bus Kopp. bridge P13 Nahbus 70 BK03b-E K6CBA05 K7CRC40 87QTS03 Bus Kopp. 70 BT01 Progress 2 70 BK03b-E SK06 70 PR .. 70QTS03 Bus Kopp. 70 BT01 70 BK03b-E K6CBA04 SK06 70 BK .. TK FN bridge Prodar BK GT6 87TS011 Bus Kopp. Prodar 87TS011 Bus Kopp. Prodar CM UNA 87TS011 Bus Kopp. 70QTS03 Bus Kopp. 70 BT01 bridge bridge

HOW TO CREATE QUALITY

A low cost solution to waterbarrier control Relais ( €10,00 /piece) Waterdetector ( €17,50) Design documentation (Sponsored by Dommelsch Bier)

Quality should drive architecture
Quality should be a design parameter from the start.
Quality can change architecture fundamentally
Response-time: Hard real-time responses and QoS-networks
Reliability: Redundancy, Autonomy and Alive-polling
Security: Layering, Authentication
…

A high availability solution Hoogtebepaling Aansturing Hoogtemeting Waterkering Diesels Meet a Meet b Stuur a Stuur b Monitor

Architectural Patterns
Re-use of earlier knowledge
Not just in software architecture!
Experiences should be documented

Pattern: A decent Watchdog
Watchdog monitors:
Being alive proces
Being alive diagnostic monitoring
Conclusion: both progress and soundness are guaranteed by the watchdog

Anti-pattern: Dormant failure
You can’t see if the decider has died until you have an alarm
Solution is simple: always have the Decider report something (also a non-alarm situation)

Anti-Pattern: Livelock
If StateModel does not respond, the Watcher will never act.
Solution is simple: set a timeout on the responsetime of StateModel

Anti-pattern: simple redundancy…
Running single application multiple times does not protect you from decision logic/programming errors
This is the most commonly found cause of errors (hardware normally is pretty decent)
Solution: use different logical applications to solve the same problem

Anti-Pattern: Common Mode Failure
Shared libraries will lead to common cause failure of multiprogrammed redundant solutions
Solution: make sure that redundant components do not use the same libraries

Anti-Pattern: Weak redundancy
Most failures of two components will lead to failure of the redundant system
Solution: introduce a crosswire, linking the two chains

Reuse Proven Technology
Often products of a single company have a large number of shared components.
The different parts in each product only differ slightly
This indicates product families, constructions of re-usable parts in different configurations.

Product lines

Wrapup
Trends show
Higher level of integration
Networks of applications
Higher Risks
Our answer to these challenges :
Architectural thinking
Use of systems engineering techniques
Quality first!

2008-10-09 - Bits and Chips Conference - Embedded Systemen Architecture patterns

by Jaap van Ekris

Accessibility

Categories

Upload Details

Usage Rights

Statistics