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

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

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

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

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

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.

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

More Related Content

Viewers also liked (6)

Similar to 2008-10-09 - Bits and Chips Conference - Embedded Systemen Architecture patterns (20)

More from Jaap van Ekris (20)

Recently uploaded (20)

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

Editor's Notes