Etienne Borde (etienne.borde@telecom-paristech.fr) Lasnier Gilles (gilles.lasnier@telecom-paristech.fr) Bechir Zalila (zalila@enst.fr) Jerome Hugues (hugues@enst.fr)
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:
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:
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.
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.
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.
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.
AADLAADL 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.
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.
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.
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.
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?
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.
AADLAADL 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.
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:
Data section presents the different types handled by this
system;
Subprograms section lists available subprogram provided by
the system developer;
Subprogram Wrappers section contains for each thread a
wrapper that is the only subprogram called by the thread and that
calls all the subprograms the thread should call.
Threads section reserves execution threads that will
execute the system;
Processes, Processor and System sections
describe the deployment information of the system.
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.
Complete the file probe.aadl as follows:
GNC and TMTC threads is similar to the
explaining comments.
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
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.
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:
No_IO restriction can be corrected by using the
Output package instead of the Ada.Text_IO package.
No_Float restriction can be corrected by using fixed points
type instead of float numbers.
The user code violated the No_IO and No_Float
restrictions. Why do we want to enforce these restrictions ?
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.
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.
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
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)