ARINC653 toolset: Ocarina, Cheddar and POK Julien Delange <delange@enst.fr> Laurent Pautet <pautet@enst.fr> 09/11/09
Context ARINC653 systems Layered architecture Enforce isolation across partitions High-integrity, reliable and dependable Partition 1 Partition 2 Kernel Task scheduling Partition scheduling Strong requirements Hierarchical scheduling Requirements analysis and verification (memory,...) System analysis, isolation verification Certification requirements (cf. DO178B) 2 Julien Delange, Laurent Pautet
Problem and solutions ARINC653 systems Must be verified BEFORE implementation (save time, money) Careful design, error can have catastrophic consequence Must be validated against certification standards (DO178B) Our tools: Verify of the system BEFORE implementation Generate code validated requirements Ease certification (code coverage, scheduling analysis, execution traces) 3 Julien Delange, Laurent Pautet
Proposed approach Dedicated development process AADL, backbone language Verification, execution, certification «Libre» toolset Ocarina model analyzer, code generator Cheddar, scheduling simulator and analyzer POK, ARINC653-compliant runtime for the AADL Available under GPL or BSD licenses Ocarina Cheddar POK Requirements verification (ex: memory requirements) Scheduling Simulation Implementation Simulation traces Compare execution AGAINST simulation traces 4 Julien Delange, Laurent Pautet
Requirements verification Ensure requirements enforcement Memory requirements Fault tree (each potential fault will be recovered) Verify basic scheduling requirements Rely on Ocarina AADL toolsuite Model analysis REAL theorems for model validation Requirements verification (ex: memory requirements) See. Model-Based Engineering for the Development of ARINC653 Architectures», AEROTECH09 5 Julien Delange, Laurent Pautet
Scheduling simulation Verify scheduling requirements Deadlines can be met Use time isolation of ARINC653 architectures Simulate system scheduling Tasks activation time Shared resources utilization Scheduling Simulation Scheduling feasability Hierarchical scheduler handling Produce trace file XML file, can be reused later Reproduce the tasks activation diagram Simulation traces Scheduling diagram Verify graphical tasks execution 6 Julien Delange, Laurent Pautet
Automatic implementation Automatic code generation Enforce model requirements Minimal code, avoid potential overhead Implementation with POK Partitioned runtime for AADL Provides isolation across partitions Automatic instrumentation Trace system execution Output tasks activation time Generation of ARINC653-compliant code traces See «Code Generation Strategies for Partitioned Systems», RTSS08-WIP Reduce overhead Avoid traditional error Ensure requirements enforcement Verify system correctness Integration with devices and other nodes Trace equivalent to scheduling trace Potentially exploit other information (executed statements,...) 7 Julien Delange, Laurent Pautet
Compare simulation and execution Compare simulation and execution Task execution is similar Time isolation is well enforced Automatic process Driven by Can also check both execution diagrams Cheddar Scheduling Simulation Simulation traces Ocarina POK Implementation traces See «Validate, simulate and implement ARINC653 systems using the AADL», SIGAda09 Compare execution against simulation Tasks execution meets simulation? 8 Julien Delange, Laurent Pautet
Additional: ARINC653 XML generation ARINC653 OS are configured with XML files Configure module service Useful for some verification Lack of information for a complete analysis Really useful? Cannot generate the whole runtime system Generate configuration + runtime with AADL ensure requirements enforcement Ocarina ARINC653 XML deployment file Vendor-specific tools ARINC653 OS configuration 9 Julien Delange, Laurent Pautet
Going further: code coverage Code coverage? Check statement execution Verify evaluation of conditions See. statement coverage, MC/DC,... Fundamental requirement for avionics systems Requirement for DO178B certification Coverage level depends on criticality level All code MUST be covered Actually performed with code review and analysis 10 Julien Delange, Laurent Pautet
Automatic code generation Code coverage and code generation Partition 1 Partition 2 Code reflects architecture needs and requirements! Remove useless functions Avoid potential overhead Event ports Blackboards Event ports Intra-partition comm Intra-partition comm Thread management Thread management Partition 1 Partition 2 Partitions scheduler Time service Kernel Sampling ports Inter-partitions comm. 11 Julien Delange, Laurent Pautet
Going further: code coverage Coverage project Automatically analyze code coverage Deduced at system execution Goal: reach MC/DC code coverage Generation of ARINC653-compliant code Application to generated application Automatically perform coverage analysis Analyze impact of code generation from AADL Facilitate DO178B/C certification Actually, statement coverage = 95% See. Couverture: an Innovative Open Framework for Coverage Analysis of Safety Critical Applications», Ada User Journal Coverage analysis 12 Julien Delange, Laurent Pautet
Conclusion Past projects show the importance of the AADL System analysis Automatic code generation cf. ASSERT project (2007) Ongoing work open new perspectives Improved analysis tools Automatic generation and certification of layered architectures Verification of requirements enforcement at execution time cf. PARSEC, AVSI, COUVERTURE projects (2009) 13 Julien Delange, Laurent Pautet