Lab: `AADL' (Architecture Analysis & Design Language)

Etienne Borde (etienne.borde@telecom-paristech.fr) Lasnier Gilles (gilles.lasnier@telecom-paristech.fr) Bechir Zalila (zalila@enst.fr) Jerome Hugues (hugues@enst.fr)


Next: , Previous: (dir), Up: (dir)

Global Introduction

The goal of these lab sessions is to present the SAE AADL (Architecture Analysis & Design Language), presented in http://www.aadl.info; and to use it to describe, validate, deploy and then run a Distributed Real-Time and Embedded system.

During these lab sessions, you will use the Ocarina tool set (http://www.openaadl.org/ocarina.html) to process the models, build the source code of the distributed application and link it with the application code.

Here is the list of available lab sessions:


Next: , Previous: Top, Up: Top

1 The Working Environment

To activate binary versions of tools used in the lab, execute th following command:

$source /infres/s3/borde/Install/env

This command must be re-executed each time you open a new ssh session.

The source archives of the lab sessions are available at these links:

1.1 Verify ocarina is properly installed

To verify if ocarina is properly installed, type in a shell:

ocarina -V

If ocarina is properly installed, you should read something like this:

Ocarina 2.0w (Working Copy from r5752)
Build date: Wednesday 10 October 2012, 01:19:17
Copyright (c) 2003-2009 Telecom ParisTech, 2010-2012 ESA & ISAE

If ocarina is not properly installed, you can download a binary version here.

1.2 Verify gnat is properly installed

To verify if gnatmake is properly installed, type in a shell:

gnatmake --version

If gnatmake is properly installed, you should read something like this:

GNATMAKE GPL 2008 (20080521)
Copyright (C) 1995-2008, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Also chack that gnat for ERC32 is properly installed by typing:

which erc32-elf-gnatmake

If gnatmake for ERC32 is properly installed, you should read the path of the binary file.

Also chack that the ERC32 simulator “tsim” is properly installed by typing:

which tsim-erc32

If tsim is properly installed, you should read the path of the binary file.

WARNING: If gnatmake for ERC32, or tsim, is not properly installed, a binary verion of these software is available here and here.

1.3 Reset environement variables

If (and only if!) you had to reinstall one of the software mentionned above, fill in the aadl_lab.env (available here) file and “source” it:

     source aadl_lab.env

Note that this has to be done each time you open a new session on the console.

1.4 AADL editors (syntax highlighting)

To help your edition of AADL models, we provide you with an AADL mode for emacs: download the aadl emacs mode and save it in a directory of your choice (refered as $DIR in the remainder of this paragraph). Edit file $HOME_DIR/.emacs (create it if it does not exist yet) to add the following code in the file:

(load "$DIR/aadl-mode.el")

Indeed, the parenthesis are necessary. To check the opreation succeeded, relaunch emacs and open one of the .aadl files provided in the labs archives.

You can also use the eclipse-based environement calle osate, available here.


Next: , Previous: The Working Environment, Up: Top

2 Lab1 Building a concurrent application with AADL


Next: , Up: Lab1 Building a concurrent application with <code>AADL</code>

2.1 Introduction

AADL is well-suited language to describe Distributed Real-Time and Embedded systems. It allows one to fully describe both the software and hardware elements of the system, to perform analysis of the system prior to code generation. In this lab, we review these different steps using Ocarina.

During this lab, you will use Ocarina to describe a simple and generate code for a monolithic concurrent application . You will then generate the corresponding code and check it is compliant with the Ravenscar profile defined in the Real-Time annex of Ada 2005 along with complementary restrictions for High-Integrity systems (see http://www.adaic.org/standards/05aarm/html/AA-TOC.html).

Once you've checked the source code is compatible with your requirements, you will run it on native and embedded platforms.

The slides of the AADL lesson are available here.

The sources of this lab session are available here. To extract the archive of the lab:

     tar -xf aadl_lab1.tar.gz

Refer to The Working Environment to see how the working environment should be set.


Next: , Previous: Introduction 1, Up: Lab1 Building and Analyzing a concurrent application with <code>AADL</code>

2.2 Completing the Case Study

The application we are dealing with is called RMA (Rate Monotonic Analysis). It illustrates a concurrent application that contains two periodic threads (Task1 and Task2). Each one of the threads calls a subprogram that displays a message indicating which thread is running.

2.2.1 Question 1

Complete the thread properties in the AADL model (rma.aadl). so that task 1 and 2 have the following properties:

Verify that your AADL model parses with Ocarina. To do this, invoke the command given bellow on the aadl file of the RMA example. The command invokes the Ocarina parser (option -p) on the rma.aadl file and includes the necessary AADL files (option -f) that contains predefined property sets.

     ocarina -p -f rma.aadl 

If a parsing error has been detected, a message will be displayed.

What is the main criticism one can have about the definition of the tasks execution time as it is given in the AADL model? Propose a solution to this problem.

2.3.2 Question 2

Add a third task Task3 (calling a subprogram Hello_Spg_3) to the RMA application and modify the properties of the task set as follows:

Verify that your model still parses.

Represent the tree of instances of the root system (the system that is not contained in another component). Make sure that Task 3 is part of the instance tree of your AADL model. The following figure illustrates the expected result, where P1, P2 and P3 are subcomponents of the root system.

Instance tree example


Previous: Completing the Case Study, Up: Lab1 Building and Analyzing a concurrent application with <code>AADL</code>

2.4 Code Generation

2.4.1 Question 3

Complete the body of the Ada package Hello so that each of the 3 subprograms consumes CPU during the maximum compute execution time of its calling task. You should use the utilities provided by the package Computations for this purpose.

Generate, and compile the application:

     ocarina -f -g polyorb_hi_ada -b rma.aadl

The "-b" option of ocarina tells it to compile the generated code using the proper compiler according to the execution platform specified in the application AADL model.

Run your application:

     ./rma_impl/node_a/node_a

Note that Ocarina warned you about the usage of an incompatible scheduling protocol. The one to use is: POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL. With this scheduling protocol, you have to set task priorities, using property: Deployment::Priority.

According to the displayed messages verify that the scheduling of the task is NOT done with respect to their priority.

What can we conclude on the capability of our code generator to produce code for a standard unix platform, when it comes to the respect of the AADL semantics?

2.4.2 Question 4

As seen on the previous question, running our application on the native platform does not give us a the correct scheduling. To get a correct scheduling according to the assigned priorities, we will simulate our application on a real-time OS (ORK) running on an embedded platform (ERC32).

First of all, modify the platform of the AADL model from “NATIVE” to “ERC32_ORK” in the processor AADL component cpurm. This allows the code generator to select the correct property values which are platform dependant.

After verifying that your application still passes using ocarina, generate code and compile your application using the GNAT for LEON Ada compiler:

     ocarina -g polyorb_hi_ada -b -f rma.aadl

Note that we execute exactly the same command as the previous question. But since we modified the execution platform on the AADL model, Ocarina will invoke the compiler corresponding to the chosen platform, which is GNAT for ERC32 in our case.

Run your application by invoking the tsim-erc32 simulator on the created executable. You must type “go” on the tsim-erc32 prompt to start the execution.

     tsim-erc32 ./rma_impl/node_a/node_a
     
      TSIM/LEON SPARC simulator, version 1.1 (evaluation version)
     
       [...]
     
     serial port A on stdin/stdout
     allocated 4096 K RAM memory
     allocated 2048 K ROM memory
     section: .text at 0x2000000, size 59520 bytes
     section: .data at 0x200e880, size 5020 bytes
     tsim> go
     resuming at 0x02000000
     [ 0.00] Hello! This is task ONE
     [ 0.38] Goodbye! This was task ONE
     [ 0.38] Hello! This is task TWO
     [ 0.78] Goodbye! This was task TWO
     [ 0.78] Hello! This is task THREE
     [ 1.00] Hello! This is task ONE
     [ 1.38] Goodbye! This was task ONE
     [ 1.88] Hello! This is task TWO
     [ 2.00] Hello! This is task ONE
     [ 2.38] Goodbye! This was task ONE
     [ 2.68] Goodbye! This was task TWO
     [ 2.94] Goodbye! This was task THREE
     
     [...]

Verify that the task set is correctly scheduled. Conclude on the nature of operating systems our code generation assumes the application will be deployed on.


Previous: Lab1 Building a concurrent application with <code>AADL</code>, Up: Top

3 Lab2 Building DRE with the AADL


Next: , Up: Lab2 Building DRE with the <code>AADL</code>

3.1 Introduction

AADL is well-suited language to describe Distributed Real-Time and Embedded systems. It allows one to fully describe both the software and hardware elements of the system, to perform analysis on the system prior to code generation. In this lab, we review these different steps using Ocarina.

During this lab, you will use Ocarina and Cheddar to describe your system and validate its scheduling. You will then generate the corresponding code and check it is compliant with the Ravenscar profile defined in the Real-Time annex of Ada 2005 along with complementary restrictions for High-Integrity systems (see http://www.adaic.org/standards/05aarm/html/AA-TOC.html).

Once you've checked the source code is compatible with your requirements, you will run it on native and embedded target.

The slides of the AADL lesson are available here.

The source code for this lab is in the following archive aadl_lab2.tar.gz. To decompress it, issue

     tar -xf aadl_lab2.tar.gz

In the following, you should issue: “$source /infres/s3/borde/Install/env” in each terminal you open.


Next: , Previous: Scheduling analysis with Cheddar, Up: Lab2 Building DRE with the <code>AADL</code>

3.2 Case Study

In this case study, we consider the following scenario:

“A probe has been launched and is on its orbit. It periodically monitors its position and stores it locally.”

The system developer retained the following solution:

“The GNC thread periodically computes its position and stores it in an internal data POS. Its period is 1000ms, its compute execution time (CET) is within the [0..400] ms range, its deadline is 1000ms. A TMTC thread periodically updates periodically this data based on other information. Its period is 100ms, its CET is within the [0..50] ms range, its deadline is 500ms. The GNC thread is more critical than the TMTC thread.”

The fact that GNC is more critical than TMTC must prevent the update of the data by TMTC unless GNC has finished its computations. This can be performed by assigning a greater priority to the GNC thread and to schedule the task set using a “Highest priority first” scheduler (see the priorities section of the processor component).

Open probe.aadl. Here is a short overview of this file:

This model is incomplete: it lists the threads, and provide a local deployment view of the system.

The first part of this lab is to build a local application corresponding to the probe example, verify its schedulability and test it on a native and embedded platform.

3.2.1 Question 1

Complete the file probe.aadl as follows:

NOTE: As specified by the comments of GNC_Thread_Wrapper.Impl, the thread reads the value of the shared data after doing its computations. This is to verify that the priorities have been respected and the data has not been altered by TMTC.

The scenario describing the local case is probe_local.aadl. Verify that the completed model parses using Ocarina:

     ocarina -p -f probe.aadl


Next: , Previous: Case Study, Up: Lab2 Building DRE with the <code>AADL</code>

3.3 Compiling the application

We may now proceed to code generation. The AADL model defines the skeleton for the runtime entities. Ocarina is called to generate code in the probe_sample_1/gnc_tmtc_pos directory.

The generated code relies on the PolyORB-HI framework to provide the basic features required by the application. Generated code uses this framework to instantiate the runtime entities defined in the AADL model. We generate Ada code.

Generated code is bound to user code to build the final application. To be compliant with High-Integrity standards, including the Ravenscar profile, the makefile relies on compiler to enforce restrictions. These are defined in the GNAT's project file ${OCRINA_prefix}/include/ocarina/runtime/polyorb-hi/polyorb_hi.gpr and the GNAT configuration file ${OCRINA_prefix}/include/ocarina/runtime/polyorb-hi/gnat.adc. see /infres/s3/borde/Install/env (or aadl_lab.env) file for the definition of OCARINA_prefix.

3.3.1 Question 2

Generate the code and compile it:

     ocarina -g polyorb_hi_ada -b -f probe.aadl

Some of the restrictions are violated by the user-provided code in the package Probe. Correct them.

Note:

The user code violated the No_IO and No_Float restrictions. Why do we want to enforce these restrictions ?

3.3.2 Question 3

Run your application on the host workstation and verify that the properties are not respected by the scheduler.

Modify the execution platform of the processor component into ERC32_ORK and re-run your example. Verify that the properties are respected.


Previous: Compiling the application, Up: Lab2 Building DRE with the <code>AADL</code>

3.4 Adding Ground Control

First of all, restore the execution platform of your application into Native.

We want to use the case study presented in the previous exercises, and extend it adding a new entity. The previous case study is extended with the following:

“An Earth Ground Control is set up and receives the information read by the probe.”

The system developer retained the following solution:

“After reading the value, the GNC thread sends asynchronously this data to the GC thread that will receive it. This thread is sporadic, activated by incoming data. This threads logs all incoming data.”.

Note: Ocarina retained the following approach to describe distribution:

“A distributed deployment is enforced by declaring two separate processes, with a Deployment::Location property declaring the IP address used by the each node of the system. Distribution is embodied by two tasks communicating on distant processes”

The extra AADL declarations are added in the file probe_extended.aadl.

3.4.1 Question 4

Complete the properties of the Ground_Thread thread.

Modify the Read subprogram so that it has an out parameter of type POS_Internal_Type called Read_Value. Modify the interface of the GNC thread and its wrapper subprogram consequently.

Modify the Ada implementation of the Read subprogram to match its new signature and behavior.

Add a call to the Send_Spg to the GNC_Thread_Wrapper.Impl thread and connect it the the Read subprogram.

The communication between the two nodes is performed using BSD_Socket. This is expressed in AADL using the bus component. Add a subcomponent of type Ethernet_Bus to the global system and connect it the the processor (using required access feature).

Finally, add an instance of the Ground_Proc.Impl to the global system and connect it to the other process and bind it to the processor. Do not for get to assign a port number to the added instance (12000 for example).

Verify that your model still parses.

     ocarina -p -f probe.aadl probe_extended.aadl

3.4.2 Question 5

Compile and execute this model on the host work station:

     ocarina -g polyorb_hi_ada -b -f probe.aadl probe_extended.aadl
     
     ./probe_sample_1/gc/gc
     ./probe_sample_1/gnc_tmtc_pos/gnc_tmtc_pos (in a different terminal)