Code Generation for ARINC653

From AadlWiki

Jump to: navigation, search

This is possible to generate code from AADL that will be deployed on ARINC653 systems. AADL tools are currently able to generate code that targets DeOS or VxWorks653. The generated code corresponds to the runtime code, the one that supports the execution of subprograms. Subprograms are supposed to be written in C but could be generated from functional models such as SCADE or Simulink.

The code generator produces:

  • The ARINC653 module configuration file (XML file) that configures the underlying ARINC653 module with the scheduling, health monitoring and communication policy (connection between queuing and sampling ports)
  • Partitions code (C code) that creates partitions resources (ARINC653 processes, mutexes, semaphores, communication ports)

We illustrate the code generation process through two examples:

  • The ADIRU example which is a model that represents an Air Data Inertial Reference Unit from the BOEING 777. It has been preliminary done to for safety analysis. More information can be found in this presentation
  • The Roll Control example that is a model made from scratch to show how to integrate SCADE code on top of the code generated from AADL

In the following sections, we present the modeling patterns for code generation (how to structure/design your model so that it can be processed by the code generator) and detail each example.

Contents

Modeling Patterns

The modeling patterns define how to structure your model in order to generate code. In order to be processed by the code generator, your model has to use these modelings patterns. These patterns define how to use AADL components and their properties to be used by the code generators.

Representing ARINC653 concepts

The ARINC653 concepts are defined in the AADL ARINC653 annex. When designing your model, make sure you are using the patterns defined in this annex. See the official SAE page to get the annex


Properties

There are the list of required properties to include in the model. Users should also refer to the list of properties in the ARINC653 annex document.

List of useful AADL properties
Property Name Component Type Description
Period virtual Processor Partition Period
ARINC653::Partition_Identifier virtual Processor partition identifier in the XML file
ARINC653::Partition_Name virtual processor direct mapping of the partition
ARINC653::Module_Schedule processor schedule of all partitions
ARINC653::HM_Error_ID_Levels processor list of health monitoring errors
ARINC653::HM_Error_ID_Actions processor list of health monitoring actions to take
Source_Name virtual processor name of the binary to load as a partition
ARINC653::Sampling_Refresh_Period data port time at which the data is refreshed on a sampling port. impact the partition code and the module configuration.
Data_Model::Data_Representation data how the data is represented/specified
Data_Size data size of a data being used. Impact the XML and partition code to configure the size of a sampling/queuing port
Type_Source_Name data direct mapping of the AADL type into a the related programming language type
Source_Name subprogram name of the function that implements this subprogram
Source_Language subprogram language that implements the subprogram (C or SCADE)
Period thread period of a thread - impact the generation of the partition code
Dispatch_Protocol thread nature of the thread (periodic or sporadic)
Priority thread priority of the thread (impact the generation of the partition time)
Compute_Execution_Time thread execution time of the thread. The upper value is used to specify how much time is allocated to the thread
Memory_Size memory size of a memory segment (in bytes)

ADIRU example

Description

The ADIRU example specific an Air Data Inertial Reference Unit using AADL. It has been first designed to analyze the system from a safety perspective. A second version of the model was used with code generators so that people can simulate it. The model with the functional code is available on the AADLib github area.


Graphical Representation of the ADIRU model
Graphical Representation of the ADIRU model

Generating Code

The code can be generated from the AADL model using Ocarina. If you are using OSATE, the code can be generated by using the OSATE/Ocarina bridge. To have more information about how to install Ocarina or the OSATE/Ocarina bridge, please read the respective user manual of each tool.

FIXME: add video with walkthrough the model

Integrating Generated Code

Once you have generated code, you need to integrate it in the DeOS or VxWorks653 environments. The main step is to create projects for each partition, the ARINC653 module and then, integrate the generated artifacts into the development environment. This integration requires low efforts and is done pretty easily. For the module file, it consists mostly in copying the generated configuration file into the workbench. For the partitions code, it consists in copying the generated C code into the partitions directory. The following videos provides guidance of how to proceed with DeOS or VxWorks.

FIXME: add video with walkthrough the model

Roll Control Example

Description

This example was designed to show how to integrate SCADE model (functional models) within an AADL model from a modeling and code generation perspective. The following picture shows the SCADE system to be mapped.

Graphical Representation of the SCADE Roll Control Example
Graphical Representation of the SCADE Roll Control Example

FIXME: add video with walkthrough the SCADE model


We then integrate this SCADE functional model within an AADL model. The AADL model is composed of four partitions:

  • panel: simulates the onOff and joystick inputs
  • sensors: simulates the sensors inputs (left/right yaw)
  • rollControl: executes the SCADE code
  • display: display the left or right warning

For each partition, we introduce one thread that execute one subprogram. The subprogram for the panel, sensors and display are regular C subprograms while the while from RollControl is the one generated from the SCADE model. The following picture show the AADL model.

Graphical Representation of the AADL Roll Control Example
Graphical Representation of the AADL Roll Control Example


FIXME: add video with walkthrough the AADL model

SCADE/AADL mapping

From a pure modeling perspective, a SCADE model is mapped into an AADL subprograms. The Source_Name property on each subprogram parameter specifies the mapping with the SCADE parameters. The following picture shows the SCADE model. For example, in the following example, it means that the AADL parameter joystick is mapped into the joystickCmd input from the SCADE model. in parameters are mapped into SCADE inputs while out parameters are mapped into SCADE outputs.

The source_name property of the subprogram component specifies the name of the corresponding SCADE block. The Source_Language property specifies the source code of the subprogram, which is SCADE. The Source_Text property is optional and if specified, corresponds to the file that contains the generated SCADE code.

subprogram scade_roll_control
features
	joystick : in parameter roll_control::types::real {source_name => "joystickCmd";};
	onoff    : in parameter roll_control::types::bool{source_name => "onOffPressed";};
	left_adverse_yaw : in parameter roll_control::types::real{source_name => "leftAdverseYaw";};
	right_adverse_yaw : in parameter roll_control::types::real{source_name => "rightAdverseYaw";};
	left_warning : out parameter roll_control::types::bool{source_name => "leftWarning";};
	right_warning : out parameter roll_control::types::bool{source_name => "rightWarning";};
	roll_rate : out parameter roll_control::types::real{source_name => "rollRate";};
properties
   --
   -- Name of the SCADE operator
   --
   source_name => "RollControl_RollControl";
   source_language => (SCADE); 
   Source_Text => ("RollControlRollControl.c");
   Code_Size  => 2 Kbyte;
   Data_Size  => 2 Kbyte;	
end scade_roll_control;

Generating Code

To generate the code with SCADE, you select the KCG code generator with no integration. Then, the generated code will be directly copied into the directory that contains the roll-control partition code.

The AADL code can be generated using Ocarina and the OSATE/Ocarina bridge. The OSATE/Ocarina bridge is included in the regular OSATE release. You still need to install Ocarina on your system. The generated code will then contain the ARINC653 module configuration file (XML file) and the partitions code. The partitions code is C code that creates partitions resources (tasks, ports, etc.) to execute the functional code.

Integrating Generated Code

As for the previous example, integrated the generated code does not require too much effort. The generated ARINC653 module configuration file is copied in the development environment and the generated partitions code is also copied into each partitions source code directory. The code generated from the SCADE model is also copied into the roll-control partition directory. The following two videos shows how to integrate the code with DeOS and VxWorks653.


FIXME: put video

Verifying Correct Integration of the SCADE model

To verify that the integration of the SCADE model is done correctly, we verify that we have the same output when executing the generated implementation than when simulating the model. For that, we simulate and execute the SCADE model with the same inputs:

  • joystick value at 5.0
  • onOff button at true (1)
  • leftYaw at 500
  • rightYaw at -200

When using these inputs, the left warning is set to true while the right warning is then set to false at simulation. Setting the same values during execution gives the same behavior, showing that the integration is correctly done.

Information

Personal tools