How to Minimize Cost and Risk for Developing Safety-Certifiable Systems
-
Upload
real-time-innovations-rti -
Category
Technology
-
view
933 -
download
2
description
Transcript of How to Minimize Cost and Risk for Developing Safety-Certifiable Systems
How to minimize cost and risk for developing safety-certifiable systems
Edwin de Jong, PhD
Director of Product Management and Strategy, RTI
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
More Efficient Communication Infrastructure Utilization
Vehicle LAN
Data Link
Ground StationLAN
Avionics
Net Centric GIG
TacticalBackbone
Real-Time
Ground Station
BackendWAN
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
Peer-To-Peer Plug-And-Play DataBus
OMG Data Distribution Service
Sens
or D
ata
Control App
Com
man
ds
Stat
usSensor
Sens
or D
ata
Actuator
Com
man
ds
Stat
us
Sensor
Sens
or D
ata
Display App
Sens
or D
ata
Stat
us
Data-Centric Messaging
Distributed Data Model and System State
Source(Key) Latitude Longitude Altitude
RADAR1 37.4 -122.0 500.0
UAV2 40.7 -74.0 250.0
LPD3 50.2 -0.7 0.0
Hundreds Of Applications
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
DO-178B/C
• A guideline• Used by FAA as a basis
for certification– Aircraft are “certified”– Software code
developed underDO-178 provides “certification evidence”
• Increasingly adopted for military aircraft
DO-178 Safety Levels
Level Failure Condition Typical % of avionics code
A Catastrophic(may be total loss of aircraft) 15%
B Hazardous/Severe(serious injuries) 35%
C Major(minor injuries) 30%
D Minor(inconvenience) 15%
E No effect 5%
Certification Costs
• DO-178 costs $50-$100 per ELOC
• Process objectives must be met
• All must be documented• Code must be clean
– Testable– No dead code– Deterministic
Level Process Objectives
Code Coverage
A 71 Level B and 100% of MCDC
B 69 Level C plus 100% of DC
C 62 Level D plus 100% of SC
D 26 100% of Requirements
E 0 None
Tenets Of Safety-Critical Software
• Reduce code size• Consider testability in design• Design code to be deterministic
Communication-Middleware Implications
• Specific implementation withfewer 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
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
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
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
Introducing Connext™ Micro
DDS API Subset
Transport API
Base-line configuration
Static Discovery
OS API
User Application
UDPv4 Linux
RTOSAPEX DynamicDiscovery
Queue API
Listeners
Plug-in components
Linear Queue
Keyed Queue
Discovery APIReliability
Durability & History
Other QoS
Optional APIs
Shared memory
ARINC 653
Com
pile
-tim
e op
tions
RTPS
Certifiable DDS – Core Capabilities
• Support for multiple domains
• Domain Participant Factory
– Create/delete Domain Participants
• Domain Participant– Create topics (keyed and
keyless)– Create publications– Create subscriptions– Delete contained entities
• Subscription– Polling– Notification– Read/take
• Publication– Write with or without
timestamp– Dispose– Liveliness
• Thread-safe
Memory Model
Application
Network
DD
S middlew
are
Data Cache Discovery Database
Grows as more data produced
Grows as more nodes join
Configure resource limits before creating entitiesNo memory growth
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
DDS Discovery
Peer 1 (up)
Peer 2 (down)
Hello!
Hello!
Initial peers:Peer 1Peer 2
Hello back!
DDS Discovery – Stage 2
Peer 1 (up)
Peer 2 (down)
My endpoints are …
Thanks! My endpoints are …
Discovery for Safety-Critical Systems
Unknown number of participants connectingUnknown number of remote endpoints
Know which participants are upSimple protocol
Stage 1: dynamic participant discoveryStage 2: static loading of endpoints
Quasi-static discovery
DDS Minimum Profile Features Not Supported
• Participant, Publisher, Subscriber listeners• Conditions• Set QoS after entity creation• Ignore Domain Participant, Publication,
Subscription• Coherent changes
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
Certification Evidence
• Plan for Software Aspects of Certification (PSAC)
• Software Development Plan (SDP)– Requirements standards– Design standards– Code standards
• Software Verification Plan (SVP)• Software Configuration
Management Plan (SCM)• Software Quality Assurance Plan
• Software Requirements Data• Design Description• Traceability• SQA Records• SCM Records• Software Configuration Index• Software Verification Cases and
Procedures• Software Verification Results• Software Accomplishment
Summary
Certification evidence can be re-used across programs
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
Next Steps
• Download and evaluate Connext Micro early access release– Contact your RTI representative
• Start development now using either:– Connext Micro EAR– General-purpose edition
• API and QoS Guide enables seamless migration
Just updated!
Your systems. Working as one.DownloadConnextFree TrialNOW
www.rti.com/downloads
Thank you
© 2012 RTI