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