How to Minimize Cost and Risk for Developing Safety-Certifiable Systems


Published on

To view this webcast on-demand, visit

How to Minimize Cost and Risk for Developing Safety-Certifiable Systems
Designing modern avionics systems, for manned as well as unmanned aircraft, requires a challenging and unique integration of safety-critical components, including processors, operating systems, communication media and application software. The requirement to meet RTCA DO-178 Level A or other safety certification criteria makes designs for these systems even more demanding.

In this webinar, learn how the use of one common integration platform in your designs lowers development and certification costs and reduces overall project risk. We will discuss testability of distributed systems, how to avoid sources of non-determinism, design alternatives to reliable communication and more.

As an innovator of safety-certifiable communications software based on the world's leading implementation of the OMG Data Distribution Service (DDS), we are working with dozens of teams developing safety-critical distributed systems. Our position renders a unique perspective spanning very different designs that we will share with you during the webinar. The intended audience includes architects and chief engineers for safety-critical 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
  • DDS Discovery:Process by which domain participants find out about each otherEach participant maintains database on other participants and their entitiesHappens automatically behind the scenes“anonymous publish-subscribe” When using Dynamic DiscoveryParticipants refresh their presence or are aged outQoS changes propagated to remote participantsTwo stages of discovery. First is participant discovery. Participants periodically announce their presence using RTPS DATA messageContains participant GUID, transport locators, QoSInitially sent to all participants in “initial peers” list, then sent periodically to all discovered participants Sent using best-effort
  • How to Minimize Cost and Risk for Developing Safety-Certifiable Systems

    1. 1. How to minimize cost and risk fordeveloping safety-certifiable systemsEdwin de Jong, PhDDirector of Product Management and Strategy, RTI
    2. 2. Next-Generation Unmanned Aircraft Systems (UAS’s)• Network of – Self-coordinating Unmanned Aerial Vehicles (UAVs) – Multiple Ground Control Stations (GCS’s) – Manned aircraft, space systems, ground troops• Multiple and changing mission objectives• Vision challenge: – Make data and capabilities of UAVs and GCS’s accessible to every relevant participant
    3. 3. More Efficient Communication Infrastructure Utilization Avionics Real-Time Vehicle LAN Data Link Ground Station LANGround Station Net Centric GIG Tactical Backend Backbone WAN
    4. 4. Baseline Capabilities for UAS Communication Platform• Open standards based – Commonality and interoperability• True peer-to-peer architecture – No single point of failure or vulnerability• Portable to any communication media – RF, optical links, high-speed interconnects• Available for heterogeneous environments – Embedded, low-power, small foot-print, RTOS, ARINC 653 – Mainstream OS’s (Windows, Linux) and CPUs (Intel)• Certifiable component (DO-178B/C) – Integration of UAVs into civil airspace
    5. 5. Peer-To-Peer Plug-And-Play DataBus OMG Data Distribution Service Sensor Data Commands Sensor Data Control DisplaySensor Sensor Actuator App App
    6. 6. Data-Centric MessagingDistributed Data Model and System State Source Latitude Longitude Altitude (Key) RADAR1 37.4 -122.0 500.0 UAV2 40.7 -74.0 250.0 LPD3 50.2 -0.7 0.0
    7. 7. Hundreds Of Applications
    8. 8. Integration In Constrained Environments• Integration of resource-constrained OT systems with IT systems – Stringent SWaP requirements – Limited primary storage (8MB RAM) – Limited secondary storage (32MB flash) – Embedded low-power single-core CPU – Lack of operating system• Safety certification – In avionics, medical systems – Certification cost drives system design
    9. 9. DO-178B/C• A guideline• Used by FAA as a basis for certification – Aircraft are “certified” – Software code developed under DO-178 provides “certification evidence”• Increasingly adopted for military aircraft
    10. 10. DO-178 Safety Levels Typical % ofLevel Failure Condition avionics code Catastrophic A 15% (may be total loss of aircraft) Hazardous/Severe B 35% (serious injuries) Major C 30% (minor injuries) Minor D 15% (inconvenience) E No effect 5%
    11. 11. Certification Costs• DO-178 costs $50-$100 Level Process Code Coverage Objectives per ELOC• Process objectives must A 71 Level B and 100% of MCDC be met Level C plus 100% of B 69• All must be documented DC Level D plus 100%• Code must be clean C 62 of SC – Testable D 26 100% of Requirements – No dead code E 0 None – Deterministic
    12. 12. Tenets Of Safety-Critical Software• Reduce code size• Consider testability in design• Design code to be deterministic
    13. 13. Communication-Middleware Implications• Specific implementation with fewer capabilities – Reduced ELOC• Predictable – No dynamic memory allocation – System must be preconfigured• Limited size of distributed system – Suiting most avionics systems – Larger size system integration through bridge
    14. 14. Reducing Middleware Size• Use efficient data structures – Optimized for smaller-scale systems – Simpler data structures allow middleware to remain small even as new functionality is added• Balance capabilities versus size – Only include capabilities relevant in safety-critical systems – Focus on core capabilities
    15. 15. Towards Safety-Certifiable DDS• Scalable implementation to accommodate resource constrained environments – Small memory footprint (~200KB library) – Low CPU load (< 10% at 30Hz)• Designed to be certifiable component – Minimal lines of code (~20K ELOC) – Targeting DO-178C Level A• Following OMG DDS specification – Wire protocol RTPS compatible – Seamless integration with other DDS implementations – Subset of standard DDS API
    16. 16. Prototype• Foundation for DO-178B/C Level A certifiable middleware – Few lines of code (21K ELOC) – Small footprint (160 KB on x86)• Passed initial assessment by Verocel – Code is deterministic – Code is testable – Conforms to coding styles – Uses robustness checks and logging messages
    17. 17. Introducing Connext™ Micro User Application Listeners Base-line configuration OptionalCompile-time options DDS API Subset APIs Reliability Transport API OS API Queue API Discovery API Durability & History RTPS Other QoS Static UDPv4 Linux Linear Queue Discovery Dynamic APEX RTOS Keyed Queue Discovery Shared ARINC 653 memory Plug-in components
    18. 18. Certifiable DDS – Core Capabilities• Support for multiple • Subscription domains – Polling• Domain Participant – Notification Factory – Read/take – Create/delete Domain • Publication Participants – Write with or without• Domain Participant timestamp – Create topics (keyed and – Dispose keyless) – Liveliness – Create publications • Thread-safe – Create subscriptions – Delete contained entities
    19. 19. Memory Model Grows asGrows as more nodes Applicationmore data joinproduced DDS middleware Discovery Data Cache Database Network Configure resource limits before creating entities No memory growth
    20. 20. Quality of Service (QoS) Support• Communication protocols – Best effort – Reliable with periodic and piggyback heartbeats• Optional durability – Last value kept in-memory by publisher• Send/receive cache resource configuration• Publication and subscription deadline• Ownership and strength
    21. 21. DDS Discovery Peer 1 (up)Initial peers:Peer 1 Peer 2 (down)Peer 2
    22. 22. DDS Discovery – Stage 2 Peer 1 (up) Peer 2 (down)
    23. 23. Discovery for Safety-Critical Systems Unknown number of participants connecting Unknown number of remote endpoints Know which participants are up Simple protocol Quasi-static discovery Stage 1: dynamic participant discovery Stage 2: static loading of endpoints
    24. 24. DDS Minimum Profile Features Not Supported• Participant, Publisher, Subscriber listeners• Conditions• Set QoS after entity creation• Ignore Domain Participant, Publication, Subscription• Coherent changes
    25. 25. DDS QoS Not Supported• Keep all history• User Data, Topic Data, Group Data• Presentation• Partition• Lifespan• Destination Order• Reader/Writer Data Lifecycle• QoS configuration using XML files
    26. 26. Certification Evidence • Plan for Software Aspects of • Software Requirements Data Certification (PSAC) • Design Description • Software Development Plan (SDP) • Traceability – Requirements standards • SQA Records – Design standards – Code standards • SCM Records • Software Verification Plan (SVP) • Software Configuration Index • Software Configuration • Software Verification Cases and Management Plan (SCM) Procedures • Software Quality Assurance Plan • Software Verification Results • Software Accomplishment SummaryCertification evidence can be re-used across programs
    27. 27. Summary• Connext Micro designed for safety-critical applications – Standards compliant – Small footprint• Code provides foundation for DO-178 certifiable middleware – Minimal lines of code – Deterministic• Certification evidence is reusable
    28. 28. Next Steps• Download and evaluate Connext Micro early access release Just updated! – Contact your RTI representative• Start development now using either: – Connext Micro EAR – General-purpose edition• API and QoS Guide enables seamless migration
    29. 29. Download Your systems. Working as one.ConnextFree TrialNOW
    30. 30. Thank you © 2012 RTI