ARINC653 annexOverview

Julien Delange Laurent Pautet

2Outline

Presentation

Modeling guidelines

Current status

Toolset

Conclusion

Outline

Presentation

Modeling guidelines

Current status

Toolset

Conclusion

ARINC653 standard

Avionics standard Central part of the IMA concept Standardized API to build avionics systems

Partitioned architecture Each partition is independent Resources isolation across partitions

Time and space isolation Each partition has a time frame to execute its threads Partitions own an address space to store its code and data

ARINC653 standard parts

First part: required services Base services: process managements, types, etc. Communications services (intra and inter-partitions) Deployment strategies

Second part: extended services File-system, extended sampling ports, etc.

Goal of the ARINC653 annex

Modeling guidelines Represent ARINC653 architectures Specify architecture requirements (time & space isolation, )

Dedicated property set Standard property set is not sufficient Introduce new properties to describe these architectures

Various applications Validation/verification of models Automatic implementation of partitioned architectures

State of the ARINC653 annex

Included services First part of ARINC653 (required services) Second part (optional services) not included

More an annex to model partitioned system Give freedom to model other partitioned systems Modeling guidelines to express time and space isolation

Interests of modeling ARINC653 architectures with AADL

Validation Validate time and space isolation Verify safety requirements (fault handling, ) Check scheduling enforcement

Automatic implementation/prototyping Configuration generation Code generation Benefits of automatic code generation (cf. Ocarina)

Outline

Presentation

Modeling guidelines

Current status

Toolset

Conclusion

ARINC653 Module/partitioned kernel mapping

Partitioned system requirements Partitioned kernels enforces partitions time isolation It provides few runtime services

AADL modeling Processor component Contains partitions runtime (virtual processor) Dedicated property set for partitions scheduling

(time slots and their allocation)

Partition mapping

Partitioned system requirements A partition is independent Data isolation with separated adress spaces (space isolation) Partitions have their own runtime (scheduler and so on)

AADL modeling Process component: dedicated address space Virtual processor component: partition runtime Memory component: location of partitions adress space Each process is bound to a virtual processor Each process is bound to a memory component

Process/task mapping

Partitioned system requirements A process is executed inside a partition Scheduling requirements (period, priority, ) Runtime requirements (stack size, )

AADL modeling Thread component, contained in the process component Standard property to specify task requirements

Inter-partition communication

Partitioned system requirements Communications across partitions Comunication pattern:1 to N Sampling ports: a memory space updated at a given rate Queuing ports: values queued by writers,

unqueued by readersAADL modeling

AADL ports on process components Sampling ports: data ports Queuing ports: event data ports Dedicated property set to model specific requirements

Intra-partition communication

Partitioned system requirements Communications inside partitions (avoid message passing!) Blackboard: read/write a value Buffer: queued values

AADL modeling AADL ports on threads components Blackboard: data port Buffer: event data port Dedicated property set to model specific requirements

Intra-partition synchronization

Partitioned system requirements Synchronization across tasks Events: send/wait an specific event Semaphores: counting semaphores

AADL modeling Events: event data port on thread components Semaphores: shared variable across thread components Dedicated property set to model specific requirements

Health Monitoring

Partitioned system requirements A fault can be recovered Potential fault and recovering actions must be listed Module/partition/process associates an action to each

potential fault

AADL modeling Specific properties (ARINC653::HM_Errors, HM_Actions) Associate these properties on processor,

virtual processor or thread components Use the error model annex

Memory requirements

Partitioned system requirements Physical memory divided into multiple adress spaces Each adress space has specific properties

AADL modeling Model the main memory and its adress space,

describing ahierarchy of memory components Dedicated properties to specify memory requirements

Graphical example

Partitions

Adress spacesKernel/Module

Inter-partition communicationIntra-partition communication

Outline

Presentation

Modeling guidelines

Current status

Further improvements

Toolset

Conclusion

Device drivers modeling

ARINC653 standard not clear Drivers are located in module or partitions ?

Use the AADL device component Model device requirements

Associate with its runtime level Bind to Processor or Virtual Processor Model where the device should run (kernel or partition)

Specify implementation concerns Use the Implemented_As property Implementation as a partition or multiple thread

Device drivers, example

abstract netif_driver.threadssubcomponents

thr_sender : thread network_sender;

thr_receiver : thread network_receiver;

end netif_driver.threads;

abstract netif_driver.partitionsubcomponents

partition : process part_driver;end netif_driver.partition;

system implementation arinc653systemSubcomponents netif : device network_device.threads {Implemented_As => netif_driver.threads;}; module : processor arinc653module;properties Actual_Processor_Binding =>

(reference (module)) applies to netif;end arinc653system;

system implementation arinc653system2Subcomponents netif : device network_device.threads {Implemented_As => netif_driver.partition;}; module : processor arinc653module;properties Actual_Processor_Binding =>

(reference (module.partition)) applies to netif;end arinc653system2;

Drivers ta

sks

isolated i

n partitio

nsDriver tasks located in the kernel

Outline

Presentation

Modeling guidelines

Current status

Toolset

Conclusion

Informal ballot

Main concepts are now stable Time and space isolation Communication services Dedicated property set

Further updates published elsewhere Revision of the error modeling annex Examples from research and industrial projects

Ongoing work

Update of the Error Model Annex Map ARINC653 Health Monitoring errors Provide better analysis Lead by Peter Feiler

Technical report for ARINC653 modeling examples Contribution of industrial and research partners More easy to update and modify

Outline

Presentation

Modeling guidelines

Current status

Further improvements

Toolset

Conclusion

Integration with Ocarina

Annex integration Available with the non-standard property sets

Automatic validation of ARINC653 architectures Validation step before implementation efforts Limited to requirements of the standard

Automatic generation of code/configuration Generate ARINC653-compliant C code Tested with the POK runtime, a BSD-licensed ARINC653 OS Generate ARINC653 XML configuration files from AADL

Validation using REAL

Requirements Enforcement Analysis Language (REAL) Check models requirements using dedicated theorems Available as an annex language, implemented in

Ocarina

Validate ARINC653 architectures Validate memory requirements Validate scheduling (major time frame compliance)

ARINC653-compliant code generator

ARINC653 code generatorGenerate code for each partitionConfigure the underlying operating systemsHandle services of the first part of ARINC653 standard

AADL models

Code for partition 1 Code for

partition 2Code for

partition N

XML configuration file generator

Module configurationDescribe system requirements (scheduling, )

Required services for each module/partition (ports)

Standard complianceConfiguration file compliant with ARINC653 DTD

AADL models

Configuration file for module 1

Configuration file for module N

MBE development process for ARINC653

Complete process Full MBE method Avoid manual errors Enforce model properties

Standard compliance C code compliant with

the ARINC653 standard Configuration compliance

with system requirements

Validation and code generation

XML configuration files

ARINC653 C code

AADL models

OS-specificDeployment tools

Configuration code

Compilation

Binary

Outline

Presentation

Modeling guidelines

Current status

Further improvements

Toolset

Conclusion

Conclusion

Modeling guidelines relevant for ARINC653 systems Map main requirements and properties Make it flexible to model other partitioned architectures

Current Status Core of the annex in informal ballot Health Monitoring modeling continues with

the revision of the Error Model Annex Updated examples will be published in a technical report

Dedicated toolset makes the use of AADL interesting Dedicated analysis tools for validation (scheduling, etc.) Automatic configuration and code generation

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32