To view this webcast on-demand, visit http://ecast.opensystemsmedia.com/337 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.

1. How to minimize cost and risk for
developing safety-certifiable systems
Edwin de Jong, PhD
Director of Product Management and Strategy, RTI

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. More Efficient Communication Infrastructure
Utilization
Avionics
Real-Time
Vehicle LAN
Data Link
Ground Station
LAN
Ground Station Net Centric GIG
Tactical Backend
Backbone WAN

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. Peer-To-Peer Plug-And-Play DataBus
OMG Data Distribution Service
Sensor Data
Commands
Sensor Data
Control Display
Sensor Sensor Actuator
App App

6. Data-Centric Messaging
Distributed 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. Hundreds Of Applications

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. 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. DO-178 Safety Levels
Typical % of
Level 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. 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. Tenets Of Safety-Critical Software
• Reduce code size
• Consider testability in design
• Design code to be deterministic

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. 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. 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. 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. Introducing Connext™ Micro
User Application
Listeners Base-line configuration
Optional
Compile-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. 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. Memory Model
Grows as
Grows as more nodes
Application
more data join
produced
DDS middleware
Discovery
Data Cache
Database
Network
Configure resource limits before creating entities
No memory growth

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. DDS Discovery
Peer 1 (up)
Initial peers:
Peer 1 Peer 2 (down)
Peer 2

22. DDS Discovery – Stage 2
Peer 1 (up)
Peer 2 (down)

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. DDS Minimum Profile Features Not Supported
• Participant, Publisher, Subscriber listeners
• Conditions
• Set QoS after entity creation
• Ignore Domain
Participant, Publication, Subscription
• Coherent changes

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. 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
Summary
Certification evidence can be re-used across programs

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. 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. Download Your systems. Working as one.
Connext
Free Trial
NOW
www.rti.com/downloads

30. Thank you
© 2012 RTI