You are on page 1of 32

ARINC653 annex

Overview
Julien Delange <delange@enst.fr>
Laurent Pautet <pautet@enst.fr>

Outline
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

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 readers

AADL

system requirements

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
Intra-partition
communication

Inter-partition
communication

Partitions

Kernel/Module

Adress
spaces

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.threads
subcomponents
thr_sender : thread
network_sender;
thr_receiver : thread
network_receiver;
end netif_driver.threads;
system implementation arinc653system
Subcomponents
netif : device network_device.threads
{Implemented_As =>
netif_driver.threads;};
module : processor arinc653module;
properties
Actual_Processor_Binding =>
(reference (module))
applies to netif;
end arinc653system;

Driver
tasks
lo
the ke cated in
rnel

abstract netif_driver.partition
subcomponents
partition : process part_driver;
end netif_driver.partition;

system implementation arinc653system2


Subcomponents
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;
s

is

ask ions
t
s
er artit
v
i
r
D
in p
d
e
olat

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 generator
Generate code for each partition
Configure the underlying operating systems
Handle services of the first part of ARINC653 standard
AADL models

Code for
partition 1

Code for
partition 2

Code for
partition N

XML configuration file generator

Module

configuration

Describe system requirements (scheduling, )


Required services for each module/partition (ports)
Standard

compliance

Configuration file compliant with ARINC653 DTD


Configuration file for
module 1

AADL models
Configuration file for
module N

MBE development process for ARINC653


AADL models

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
OS-specific
Deployment 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

You might also like