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

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://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:

Here is the list of available lab sessions:


Next: , Previous: Top, Up: Top

1 The Working Environment

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.

1.1 The SUN workstations

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


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

2 Lab1 Building and Analyzing a concurrent application with AADL


Next: , Up: Lab1 Building and Analyzing 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 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.


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 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.


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

2.3 Analyze Schedulability

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;

2.3.1 Question 2

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

2.3.2 Question 3

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


Previous: Analyze Schedulability, Up: Lab1 Building and Analyzing a concurrent application with <code>AADL</code>

2.4 Code Generation

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”.

2.4.1 Question 4

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?).

2.4.2 Question 5

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.

2.4.3 Question 6

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.


Previous: Lab1 Building and Analyzing 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

     gtar zxvf aadl_lab2.tar.gz

In the following, you should issue: “source aadl_sun.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 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:

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_sh -p -s probe_local.aadl


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

3.3 Scheduling analysis with Cheddar

Cheddar provides multiple scheduling feasibility tests. In this question, we focus on the scheduling feasibility test based on worst case task response time.

3.3.1 Question 2

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?

3.3.2 Question 3

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?


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

3.4 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.

3.4.1 Question 4

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:

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

3.4.2 Question 5

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.


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

3.5 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 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.

3.5.1 Question 6

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

3.5.2 Question 7

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)