Jérôme Hugues (hugues@enst.fr) Bechir Zalila (zalila@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 toolset (http://ocarina.enst.fr/) to process the
models, build the source code of the distributed application and link it with
the application code.
Complementary tools will help you to analyze your system:
Cheddar: (http://beru.univ-brest.fr/~singhoff/cheddar)
relies on Ocarina to provide schedulability analysis of AADL
models. During the lab sessions, you will use a light, text-mode version of
the Cheddar analyzer called cheddar-analyzer Here is the list of available lab sessions:
The source archives of the lab sessions are available at these links:
Each of the lab sessions contains a first part that has to be done on the SUN
workstations and a second part that has to be done on a LINUX machine because
the tsim LEON processor simulator is available only for LINUX.
The following sections explain how to set correctly the environment on both platforms.
The SUN workstations will be used to test code generation on native platforms
and to run distributed applications using PolyORB-HI. To set
correctly all the environment variables and be able to use Ocarina and Cheddar,
you must extract the archive corresponding to the current lab session and
“source” the environment file corresponding to the SUN workstations. For
example, for lab 1:
gtar zxvf aadl_lab1.tar.gz
cd aadl_lab1
source aadl_sun.env
XURI is the LINUX machine hosting the tsim LEON processor
simulator and the GNAT-for-LEON compiler.
To log on xuri:
ssh aadl_lab@xuri.enst.fr
aadl_lab@xuri.enst.fr's password: <The password will be provided during the lab session>
To copy your aadl modified files to xuri, you must first create a directory
having the same name as you in order to not override other student files.
Assuming that your name is Michel Dupont, that your ENST login is
dupont and that the modified AADL files are in the aadl_lab1 of
your ENST home directory:
[aadl_lab@xuri ]$ mkdir michel.dupont
[aadl_lab@xuri ]$ cd michel.dupont
[aadl_lab@xuri ]$ scp -r dupont@esmeralda.enst.fr:aadl_lab1/ ./
dupont@esmeralda.enst.fr's password: <Your ENST password>
You must then set correctly the environment variables on xuri to
be able to use the several tools. For example, for lab 1:
[aadl_lab@xuri ]$ cd aadl_lab1
[aadl_lab@xuri ]$ source aadl_xuri.env
AADL
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 and Cheddar to describe a simple monolithic concurrent application 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 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:
gtar zxvf aadl_lab1.tar.gz
Refer to The Working Environment to see how the working environment should be set on both SUN workstation the LINUX machine.
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 ocarina_sh with the -p
option on the scenario file of the RMA example. The command invokes the Ocarina
parser on the rma.aadl file and includes
the additions additional necessary AADL files that contains the Cheddar analyzer
properties (Cheddar_Properties::Fixed_Priority) and the platform
characteristics (ARAO::Level_A)
ocarina_sh -p -s rma_scenario.aadl
A successful parsing corresponds to the dumping of all the AADL parsed source code. If a parsing error has been detected, a message will be displayed.
To simulate a rate monotonic analysis with Cheddar, we assign priorities to the different tasks with respect to their periods and we indicate to Cheddar that we want a “Highest Priority First” preemtive scheduler. This is performed by assigning the following properties to the application processor:
processor implementation cpurm.impl
properties
Scheduling_Protocol => Posix_1003_Highest_Priority_First_Protocol;
Cheddar_Properties::Preemptive_Scheduler => true;
end cpurm.impl;
Verify that the system is schedulable. To do this, Invoke the command
ocarina_sh with the -c option
on the scenario file of the RMA example. The command will invoke the cheddar_analyzer command on the rma.aadl file and includes the additional necessary
AADL files that contains the Cheddar analyzer properties
(Cheddar_Properties::Fixed_Priority) and the platform
characteristics (ARAO::Level_A):
ocarina_sh -c -s rma_scenario.aadl
The schedulability analysis output is a very verbose text that describes the characteristics of the task set and indicates whether it is schedulable or not.
[...]
- All task deadlines will be met : the task set is schedulable.
[...]
Modify the compute execution time of Task 2 so that the system becomes not schedulable. Analyze the output of cheddar_analyzer
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.
Is the new task set schedulable? If no, which task misses its deadline according to the Cheddar analyzer output?
Reduce the compute execution time of this task so that the task set will be schedulable
We will now generate Ada code corresponding to the task set seen at the
previous question. Each of the AADL subprograms is implemented by an Ada
subprogram in the package Hello (files hello.ad?).
Complete the body of the 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 on the SUN workstation:
ocarina_sh -b -s rma_scenario.aadl
The "-b" option of ocarina_sh 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
According to the displayed messages verify that the scheduling of the task is not done with respect to their priority.
As seen ion the previous question, running our application on the native SUN platform does not give us a RMS scheduling. To get an RMS scheduling, we will simulate our application on a real-time OS (ORK) running on an embedded platform (LEON).
First of all, modify the platform of the AADL model from “NATIVE” to “LEON”
in the processor AADL component cpurm. This allows the code
generator to select the correct property set ARAO which is platform
dependant.
After verifying that your application still pases using ocarina. Copy the whole aadl_lab1 directory to xuri as specified in The Working Environment.
Set the environment variables:
[aadl_lab@xuri ]$ source aadl_xuri.env
Generate code and compile your application using the GNAT for LEON Ada compiler:
[aadl_lab@xuri ]$ ocarina_sh -b -s rma_scenario.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.
Run your application by invoking the tsim-leon simulateor on the created executable. You must type “go” on the tsim-leon promt to start the execution.
[aadl_lab@xuri ]$ tsim-leon ./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, in 1 bank(s)
allocated 2048 K ROM memory
icache: 4 kbytes, 16 bytes/line
dcache: 4 kbytes, 16 bytes/line
./rma_impl/node_a/node_a does not seem to be a SPARC object file
tsim> go
[...]
Verify that the task set is correctly scheduled.
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
gtar zxvf aadl_lab2.tar.gz
In the following, and depending on your working machine (SUN workstation or
the XURI machine), you should issue: “source aadl_sun.env” or
“source aadl_xuri.env” in each terminal.
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
CET is within the [0..600] ms range, its deadline is 1000ms. A
TMTC thread periodically updates periodically this data
based on other infomations. Its period is 100ms, its CET is within the [0..50]
ms range, its deadline is 100ms. 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.
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_sh -p -s probe_local.aadl
CheddarCheddar provides multiple scheduling feasibility tests. In this
question, we focus on the feasibility test based on the processor utilization
factor and the end to end response time.
Using Ocarina, test whether the system is schedulable or not:
ocarina_sh -c -s probe_local.aadl
What can we conclude? Which task misses its deadline?
The system architect has a good news, he made a too pessimistic hypothesis on the GNC, its WCET is 400ms, update the model and recompute its scheduling. Is the system schedulable ?
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.
Generate the code and compile it:
ocarina_sh -b -s probe_local.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 SUN workstation and verify that the properties are not respected by the scheduler.
Modify the execution platform of the processor component into LEON and run your
examlpe on XURI. 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 ARAO::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 perfomed 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_sh -p -s probe_dist.aadl
Compile and execute this model on the SUN work station:
ocarina_sh -b -s probe_dist.aadl
./probe_sample_1/gc/gc
./probe_sample_1/gnc_tmtc_pos/gnc_tmtc_pos (in a different terminal)