Do 178c Esc San Jose 2010

aicas technology brief

DO-178C and DO-278ANew Safety Standards for

Avionics Software

Dr. James J. Hunt CEO, aicas incorporated

ESC San Jose 2010

2DO-178C and DO-278A

SC-205/WG-71Lead by RTCA and EUROCAEUpdate software standards for aviation

DO-178B/ED-12B: flight software regulationsDO-248B/ED-94B: flight software addendumDO-278/ED-109: ground support software

Open to all interested partiesOrganized in seven subgroups


SC-205 / WG-71 SubgroupsSG-1: Document IntegrationSG-2: Issues and RationaleSG-3: Tool QualificationSG-4: Model Bases Design and VerificationSG-5: Object-Oriented TechnologySG-6: Formal MethodsSG-7: Safety and CNS Related Considerations(communication, navigation, surveillance)


SG-3: Tool QualificationProvides guidance for tools used to develop and verify avionic software such as

UML code generatorModel checkerFormal analysis toolTest automation toolEmulator

Covers full tool life cycle


Tool Qualification CategoriesDO-178B/ED-12B ToolCategory & Definition

DO-178C / ED-12C ToolQualification Criteria & Definition

Development tools: tools whose output is part of airborne software and thus can introduce errors.

Criteria 1: tool whose output is part of the resulting software and could insert errors.

Verification tools: Tools that cannot introduce errors, but may fail to detect them.

Criteria 2: A tool that automates the verification process and thus could fail to detect an error, and whose output is used to justify the elimination or reduction of● verification process not automated by tool or● development process which could impact the resulting software.Criteria 3: A tool that, within the scope of its intended use, could fail to detect an error.


Tool Qualification Levels

SoftwareLevel

Criteria

1 2 3

A TQL-1 TQL-4 TQL-5

B TQL-2 TQL-4 TQL-5

C TQL-3 TQL-5 TQL-5

D TQL-4 TQL-5 TQL-5


Equivalence

DO-178B/ED-12B Tool Qualification

Type

DO-178B/ED-12B Tool Software Level

DO-178C/ED-12CTool Qualification Level

Development A 1

Development B 2

Development C 3

Development D 4

Verification All 4 or 5


Tool Reuse


SG-4: Model Based DevelopmentDescribes how models can be used

RequirementsSystemHigh levelLow level

Architectural descriptionRelated processes such as model transformation and code generationStill a work in progress


SG-5: Object-Oriented Technology

Provide a supplement to DO-178C for OOTSupplement Organization

Chapter 1: non normative backgroundChapters 2–11: additions to related to coreChapter 12: safety issues beyond core

Goes beyond pure object-oriented language features (advanced language features)Both new objectives and clarification of existing objective for OOT


Basic Concepts

Classes and ObjectMethod DispatchHierarchic EncapsulationPolymorphismFunction Passing and ClosuresTypes and Safety


Classes and ObjectsBasis of object-oriented technologyCombination of data (fields or attributes) and subprograms (methods or operations)Can be used for both design (e.g., UML) and implementation (e.g., Java or C++)Basis for inheritance and user defined types


Method DispatchStatic dispatchDynamic dispatch

Single dispatchMultidispatch

ImplementationsIndexed lookupTable search


Hierarchic Encapsulationlimiting access to object dataUsing class hierarchy to model problemBased on combination of inheritance, overloading, polymorphism, and type checking


Polymorphism

Universal polymorphismInclusion polymorphism:inheritance, subtyping, and subclassingParametric polymorphism:generics and templates

Ad hoc polymorphismOverloadingCoercion:some forms of type casting


Function Passing and ClosuresOriginally from functional programmingClosures needed for method passing

A dynamic method can not be used without a reference to its classA methods class is its closure

Being adopted by the OO community as an alternate to passing special classes


Types and SafetySubclass, subtype equivalence

Liskov's substitution principleArrays and collections

Method and class specification:design by contact

Preconditions: acceptable input valuesPostconditions: return values, including exceptions and errors, and side effectsInvariants


Liskov and RequirementsA subclass must fulfill the requirements of all its superclasses.Each method in the subclass that is also declared in a superclass should have

preconditions that are the same or weaker than the method in the superclass,postconditions that are the same or stronger than the method in the superclass, andInvariants that are not weaker.


Key Features

Inheritance and redefinitionParametric PolymorphismType conversionOverloadingExceptions and exception handlingVirtualization TechniquesDynamic memory management


Inheritance and Redefinition

Interface vs. ImplementationSingle vs. MultipleVulnerabilities

Nondeterministic dispatch timeSemantic dissonanceImplementation dissonance

ObjectivesEnsure local type consistencyInclude full class model in design


Local Type Safety

Subclasses are SubtypesSubclasses fulfill requirements of superclassesThink Liskov Substitution PrincipleUse delegation instead of inheritance for reuse

LocalWhere substitution can occurDeclared type vs. Actual type

Alternative: Exhaustive Testing


Parametric PolymorphismEnables reuse without subtypingVulnerabilities

Substitution mismatchUnverified code

ObjectivesEnsure semantic consistencyEnsure all code is covered


Type ConversionView change vs. Representation changeVulnerabilities

Data lossData corruption or exception

ObjectivesEnsure that type conversions are safe


OverloadingCan aid in program understandingVulnerabilities

unintended behavior when combined with automatic type conversionNaming dissonance

GuidanceAddress in coding standards


Exceptions and Exception Handling

Helps with program clarity by separating exceptional behavior from normal behaviorVulnerabilityfailure resulting from uncaught or improperly handled exceptionObjectiveensure that all exceptions that can be thrown are caught and properly handled,i.e., test coverage includes exceptional as well as normal control paths


Virtualization Techniques

Vulnerabilityinterpreted code is not adequately validated because it was treated as data, not codeObjectiveCertify system in layers

Certify interpreter where its input is treated as dataCertify interpreted program as code where interpreter is treated as execution platform

Applies to any data that is interpreted


Dynamic Memory Vulnerabilities1.Ambiguous references2.Fragmentation starvation3.Deallocation starvation4.Premature deallocation5.Indeterministic allocation or deallocation6.Lost update or stale reference7.Heap memory exhaustion


Dynamic Memory Safety Objectives

1.Timely Deallocation2.Fragmentation Avoidance3.Unique Allocation4.Reference Consistency5.Deterministic Execution6.Atomic Move7.Sufficient Memory


Memory Management Techniques

Technique

Objectives

Unambiguous Reference

Fragment.Avoidance

TimelyDeallocation

Reference Consistency

Determinisitc Deallocation

Atomic Move

Sufficient Memory

Object Pooling AC AC AC AC MMI N/A AC

Stack Allocation AC MMI MMI AC MMI N/A AC

Scope Allocation MMI MMI MMI AC MMI N/A AC

Manual Heap Allocation

AC ? AC AC MMI N/A AC

Garbage Collection MMI MMI MMI MMI MMI MMI ACAC = application code, MMI = memory management infrastructure, N/A = not applicable, and ? = difficult to ensure by either AC or MMI.


Certifying a Garbage CollectorNot possible for all collector

Must be deterministic; no unbound stepsMust assume maximum memory useMust consider allocation rate

Three types of realtime collectorsPaced GCSlack GCWork-based GC


Classical Garbage Collection GC can interrupt execution for long periods of time:

Problemlong, unpredictable pauses during execution


RTSJ with Classic Garbage Collection

No heap threads can interrupt garbage collector:

The application must be split into a realtime and a nonrealtime part.


Realtime Garbage CollectionPaced garbage collector

Run GC at a high priorityRuns at given interval, for given amount of timeProgrammer must provide both maximum memory use and maximum allocation rate

Slack garbage collectorRun GC at lower priority than realtime tasksRuns when processor cycles are availableProgrammer must provide both maximum memory use and

maximum allocation rate


Realtime Garbage CollectionWork based garbage collector

No GC threadGC borrows application threadNeed only determine maximum memory useNo read barriers neededLow latency


Work-Based Garbage CollectorAll Java Threads are realtime threads

GC work is performed at allocation timeGC work must be sufficient to recycle enough memory before free memory is exhaustedExecution time of all allocations must be bound


OO Languages for AviationAda

OO extensionsMultiple inheritanceHeap, stack, and static allocation

C++C with objectsPointer arithmeticHeap and static

Realtime JavaJava plus RTSJRealtime GCStatic compilation

Safety Critical JavaMinimal subsetImmortal and Scoped MemoryNo interpreter or JIT


AdaComplex object model

Multiple implementation inheritanceStatic and dynamic dispatch specified per call

Memory ManagementNo pointer arithmeticUnsafe deallocation

Good threading modelGood tooling, but not for OOT


C++Some what simpler object model

Multiple inheritanceStatic and dynamic dispatch by definition

Memory ManagementPointer arithmeticUnsafe deallocation

No threading modelPreprocessor makes tools fragile


Realtime Java TechnologyAdvantages

Strong typingType refinementReference safety(garbage collection)Standard libraryAnalyzabilityFormal Specification Language

IssuesPerformanceFootprintSchedulingPriority inversionClocks & timersHardware accessGC delays


Certification Issues

Class initializationDynamic dispatchGarbage collectionUnchecked exceptionsDynamic class loadingJust in time compilationReflectionAsynchronous transfer of control


Comparison of Languages

Development Time o o ✔ ✔ ✔Library Capabilities o o ✔ ✔ ✔

Dependability o ✔ ✔ ✔ o o ✔ ✔ ✔ o o ✔ ✔ ✔

Platform Independence o o o ✔ ✔Code Size ✔ o o o

Hard Realtime Response ✔ o ✔ ✔ ✔ o o ✔

ExtendabilityReusability

Safety

C C++ Ada .net /

C#

Java

Realtim

e Java


Advantage of Java over C and C++

Clean syntax and semantics w/o preprocessor➔ wide ranging and better tool support

Better support for separating of subtyping and reuse via limited inheritance and interfacesNo explicit pointer manipulationPointer safe deallocationSingle dispatch styleStrong, extendible type systemWith RTSJ, well defined tasking model


SG-6: Formal Methods

analysis of software (and hardware) using rigorous mathematical methods such as calculi, logic, automata, or graph theoryAlternate means of verifying avionics software

Reduce but not eliminate testingIncrease safety

Provides guidelines for using formal methods


Strengths and Weaknesses of Testing

StrengthsWell understoodMostly language independentIncludes execution environment

WeaknessesHard to cover all execution pathsHard to cover all possible parallel pathsInternal states are not visible


Why Formal Methods?Errors can not be tolerated in safety critical applications.Security is not possible without safety.System complexity is increasing dramatically.Increasingly critical decisions are being made automatically in software.Testing is not sound.


Dynamic AnalysisTestingProfiling & Monitoring

Path TracingCall tracingTime tracingBounds tracing

SimulationInstrumentation

Race detectionAssertion checkingAliasing detectionMemory analysisInvariant inference

Coverage must be determined in all cases!


Static Analysis (Formal)Type AnalysisControl Flow AnalysisData Flow AnalysisAbstract InterpretationSymbolic ExecutionModel CheckingDeductive verification


Comparison of Analysis Techniques

Static analysisAbstract domain: slow but exhaustiveConservative:due to abstractionSound:due to conservatism

Dynamic analysisConcrete execution: fast but exemplary Precise:no approximationUnsound:does not generalize

Not all static analysis techniques are formal


Type CheckingMost common formal methodAttributes used to ensure consistency

Ensure that a given variable or field is always used as intendedLimits what can be assigned to a given variable or field

Base type can be augmented with refinement typesChecking can be done modularly


Examples of Type CheckingUnit consistency@unit("meters") int a = 4;@unit("feet") int b;b = a; /* Assignment Error */Null pointer detectionInvariance checkingTool examples

Most modern compilersJavaCop


Data Flow AnalysisExtension of control flow analysisData values are propagated as wellFixed point algorithmNecessary extension for OO Languages

Method dispatch is data dependentMore precise than considering all possible subclasses at each call point


Uses of Data Flow AnalysisWorst case execution time analysisMemory use (stack, heap, etc.)Coverage and reachabilityException checkingShared object detection (race conditions)Synchronization (deadlocks)


Detecting Runtime Errors

...if (device instanceof MyDevice){ MySensor s = (MySensor) device.sensor;

int value = s.reading();

...}...


NullPointerException




...}...



ClassCastException




...}...




ClassCastException

device != null




...}...




...}...

NullPointerException ✔


ClassCastException

device != null





ClassCastException




...}...




ClassCastException values(MyDevice.sensor) contains only MySensor




...}...




ClassCastException ✔ values(MyDevice.sensor) contains only MySensor




...}...




ClassCastException ✔




...}...




ClassCastException ✔null ∉ values(MyDevice.sensor)




...}...








...}...




ClassCastException ✔




...}...


Abstract InterpretationA theory of sound approximation of the semantics of a programConcrete state and operations mapped to abstract state and operationsBased on monotonic functions over ordered sets, especially latticesCan be viewed as a partial execution of a program to gain semantic information without performing all calculations


Uses of Abstract InterpretationLivelinessRace conditionsSimultaneous accessToolsAcademic

ASTRÉE (CNRS)Airac (SNU)

CommercialCodeHawk (KT)PAG (AbsInt)PolySpace


Symbolic ExecutionAlso known as Symbolic SimulationConsiders all possible execution pathsMany possible executions of a system are considered simultaneouslyModels concrete semantics of all primitive operations (calculus)Set of values instead of concrete valueBase for other techniques


Model Checking

A variant of abstract interpretationAbstraction is a finite state machineSome aspect of program is modeled as states and transitions in state machineBoth simulation and reachability analysis can be performed on state machineError states are used to detect faults


Examples of Model CheckingModel consistency (e.g., UML models)Checking parallel executionSome runtime errors (entry into a state)Numerous toolsModel level

SPINPROSPERUppaal

Java code levelJava Pathfinder


Deductive VerificationUses formal specification language

PreconditionsPostconditionsinvariants

Checks program code against specificationBased on theorem proving, Hoare Logic, and Liskov Substitution Principle


Formal Specification LanguagesZ notation (Specification)B method (Refinement)Object Constraint Language (OCL)Java Modeling Language (JML)


Examples of Deductive Verification

Proving that a given Java method respects its post conditions given it preconditionsShowing that invariants are respectedNumerous Tools for Java (JML)

ESC/Java2 (Simplify)JACK (B-Method, Simplify, PVS, Coq)KeY (Dynamic Logic) (OCL & JML)


Which Methods to use?Depends on what is to be checked and when in the development processEach tools has its strength and weaknesses and point of applicationA combination of tools works bestChoice of programming language has an impact, e.g., Java is easier to analyze than C and C++.


ConclusionSupports a stronger role for tools.May support the use of modeling tools.DO-178C will provide more consistent treatment of OO and other nonprocedural languages.Concrete guidance for dynamics memory management and interpretation.Encourages using formal methods to improve safety.Allows using formal methods to reduce testing.


Contact Information

aicas GmbH

Haid-und-Neu-Straße 18

D-76139 Karlsruhe

+49 721 663 968 22

aicas incorporated

69 West Rock Ave.

New Haven, CT 06515 [email protected]

+1-203-676-9807 [email protected]

Do 178c Esc San Jose 2010

Documents

Transcript of Do 178c Esc San Jose 2010