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://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:
The lab sessions have to be done on the SUN workstations, especially the parts that use the cross compilation to the ERC32 platform.
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
and to simulate the ERC32 code using the tsim
simulator. 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
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 the SUN workstations.
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::Preemptive_Scheduler
).
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, we indicate to Cheddar that we want a “RATE_MONOTONIC_PROTOCOL” preemtive scheduler. This is performed by assigning the following properties to the application processor:
processor implementation cpurm.impl properties Scheduling_Protocol => RATE_MONOTONIC_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.
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:
[...] Scheduling feasibility, Processor rma.impl.cpu_rm : 1) Feasibility test based on the processor utilization factor : [...] - In the preemptive case, with RM, the task set is schedulable because... 2) Feasibility test based on worst case task response time : [...] - 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
Before generating the code we must assign explicit priorities to the task so that underlying OS can schedule them correctly.
The Ocarina property set “ARAO” declares some constants to express
criticality levels: ARAO::Level_A
> ARAO::Level_B
> .. >
ARAO::Level_E
where “>” means “more critical then”.
Using the AADL property Cheddar_Properties::Fixed_Priority
,
assign to each one of the tasks a criticality level so that the task
set remains in conformance with a rate monotonic analysis. Example:
Cheddar_Properties::Fixed_Priority => value (ARAO::Level_C);
Verify that your model still parses.
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 on the previous question, running our application on the native SUN 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_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, 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.
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 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, you should issue: “source aadl_sun.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
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 (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_sh -p -s probe_local.aadl
Cheddar
Cheddar
provides multiple scheduling feasibility tests. In this
question, we focus on the scheduling feasibility test based on
worst case task 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 TMTC, its deadline is 500ms, update the model and recompute its scheduling. Is the system schedulable now?
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
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 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 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_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)