2008-11-12 - Oslo Maritime and Energy Conference - Embedded Systems, asset or liability?


Published on

Keynote about the value of systematic thinking of software quality and systems architecture is in developing complex integrated embedded systems.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Jaap van Ekris, Veiligheidskritische systemen, Det Norske Veritas
    Fouten kosten veel mensenlevens
  • The level of complexity of these systems is what we are heading to, but can we manage this
  • Sitting duck in a war situation
  • Some people ask why I only will fly with handluggage: this is why!
    Core problem: too much focus on the details of getting a cart to move, without thinking about the big picture
    Logistics involved have proven to be too complex to be understood by any expert on the planet
  • Virtual bulkheads….
  • JAAP
  • JAAP
    Let op: Meet/a en Meet/b zijn gesynced: tijd moet hetzelfde zijn !
  • JAAP
    Hier herken je al bepaalde rollen, en kwaliteitsnoodzaak:
    Gesloten autonome lussen bij wegkanten
    Complexe (manuele) operaties vanuit verkeersleidingsstation
  • JAAP
  • 2008-11-12 - Oslo Maritime and Energy Conference - Embedded Systems, asset or liability?

    1. 1. Embedded software, asset or liability? The need for software architecture in the embedded software industry Jaap van Ekris Senior Advisor ICT Risk and Reliability 12 November 2008
    2. 2. © DNVDet Norske Veritas Slide 2 Jaap van EkrisJaap van Ekris
    3. 3. © DNVDet Norske Veritas Agenda  The risks of a lack of system architecture  What is a system architecture anyway?  Drivers of a system architecture  System Architecture in practice
    4. 4. © DNVDet Norske Veritas Increasing power…  Mechanical controls  Electromechanical controls  PLC Controller
    5. 5. © DNVDet Norske Veritas The need for integrated systems…  A ship going about 100 KM/hour  Every move being controlled by 800 PLC’s  Having 28 physical screens on the bridge to control them How fast can a captain react to a real emergency?
    6. 6. © DNVDet Norske Veritas 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?
    7. 7. © DNVDet Norske Veritas Integrated systems also raise the stakes  Airbus 340, in approach to Heathrow  Software error calculated fuel level incorrectly, cascading into: - Both main controlls went blank, “Please wait ...”. - Plane turned right when instructed to turn left. - Plane descended at 9 degrees when instructed to descend at 3 degrees.  Landed safely due to an excellent pilot
    8. 8. © DNVDet Norske Veritas Raising the stakes  USS Yorktown  Retrofit of new control system  Lost during maneuvers: - Bridge control, - damage control, - Propulsion, - Power to the weapons array, - Navigation due to a single “0” being entered  Officials statement: “it just had to be rebooted”, which took almost 3 hours Rumor has it, it had to be towed back to its Norfolk base
    9. 9. © DNVDet Norske Veritas Raising the stakes even further…  Baggage handling Denver Airport  Supplier had 90% marketshare  Initial acquisition $230 million  5 KM conveyors, 35 KM track, 3500 carts, 4000 KM wiring, 300 PC’s, 92 PLC’s  Newest software development methods used Real-time logistical nightmare (T5 on a daily basis) System abandoned after 12 years of “improvement” Total damages: $1,5 billion
    10. 10. © DNVDet Norske Veritas © 2006 CIBIT 10 Lack of software architecture…
    11. 11. © DNVDet Norske Veritas Lessons learned  “The overall system design should be reviewed for further causes of system failure”  "They rushed this stuff on the ship, there was no real prototype, and then they tried to make things work as they went along. Installing a control system on a warship and resolving problems as the project progresses is a costly and naive process”  “Formalizing the architecture would have helped some to identify problems with the design, and take decisions about them early, instead of reacting to those problems after they were uncovered in testing, and it was a lot harder to solve them, because of multiple dependencies and dependencies”
    12. 12. © DNVDet Norske Veritas One would expect  Ons single flaw may not bring down the entire system  Compartmentalisation, but then in the software world  Design up front adressing the most critical needs, instead of band-aid solutions applied later on
    13. 13. © DNVDet Norske Veritas Physical View Development ViewProcess View Logical View What is system architecture? Scenarios
    14. 14. © DNVDet Norske Veritas Slide 1428 January 2015 But also... J2EE eManifest extension RoadPlanning extension Transit extension ... extension Core dep dep dep dep dep dep dep eManifest RoadPlanning Transit ... Data ConversionValidation Domain Messaging Process Application Layer Platform Layer Dependent Library Layer Data Layer
    15. 15. © DNVDet Norske Veritas Quality drives 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 - …
    16. 16. © DNVDet Norske Veritas Software quality ≠ reliability  Usability of the user interface  Response speed  Tolerance to user errors  Data accuracy  See for more factors: ISO9126 Filedetectie faalt ORDetectie faalt Verwerking faalt Signalering faalt OR AND Lus faalt Detectorstat faalt Onderstation faalt Verwerking via VICNet faalt Verwerking via Partylijn faalt OR InkomendePartylijn faalt Inkomende FEP faalt TOP faalt Uitgaande FEP faalt Uitgaande Partylijn faalt AND BeeldstandOnderstation1 faalt Beeldstand Onderstation2 faalt BeeldstandOnderstation 3 faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt OR Matrixbord faalt Onderstation faalt
    17. 17. © DNVDet Norske Veritas 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
    18. 18. © DNVDet Norske Veritas 18 A low cost solution to waterbarrier control Relais (€10,00 /piece) Waterdetector (€17,50) Design documentation (Sponsored by Dommelsch Bier)
    19. 19. © DNVDet Norske Veritas Hoogtebepaling A high availability solution Aansturing Hoogtemeting Waterkering Diesels Meeta Meetb Stuura Stuurb Monitor
    20. 20. © DNVDet Norske Veritas Who talks to who in a complex system? Accuracy Usability Response time, Autonomous behaviour
    21. 21. © DNVDet Norske Veritas An action scenario Response time Reliability Resource behavior
    22. 22. © DNVDet Norske Veritas 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.
    23. 23. © DNVDet Norske Veritas Product lines
    24. 24. © DNVDet Norske Veritas Slide 2428 January 2015 What problems does architecture solve?  Reduce costs - Making the right choices first time around - Reduce OPEX by a (slightly) bigger CAPEX  Reduce risks - Reduce chances of a failing system architecture - Reduction of integration issues - Reduction of production failures/issues  Create opportunities - Gain more control over IT infrastructure (use it as a strategic advantage) - Improvement of information flow - Gain more insight and understanding over the current operation - Reduce development/operation/maintenance costs
    25. 25. © DNVDet Norske Veritas Conclusion  Not managing your system architecture eventually will get you into trouble  Managing it is a lot of work, but doable.  It will not only reduce the risks of an IT system, it can provide you with great opportunities!