TASTE Semantics

Introduction

This page gives a comprehensive description of the semantics behind the TASTE meta-model.

THIS PAGE IS WORK IN PROGRESS

Interface View

The interface view in TASTE captures the model of the system logical architecture, independently from a software implementation.

In the most abstract way, a system modeled with TASTE contains functions that exchange messages with other functions through interfaces.

The semantics of the interface view is largely derived from the Specification and Description Language (SDL) communication view. There are a few differences that are explained below (for example properties allowing to specify the implementation language of a building block).

The AADL language (AADL v2.2) is used as an intermediate textual format for the Interface View.

Function

There are several forms of functions in TASTE :

• functions that represent an active component of the system (e.g. a state machine or a control law), something that can communicate with surrounding functions.
• nesting functions, that allow to structure the system in a hierarchical way (grouping by context, or for better readability). Nesting is recursive.
• function types, which contain a generic behavior and that can be instantiated
• function instances

Graphically, terminal functions have this simple shape including the name of the function:

While nesting function generally appear like this (depending on the tool) - showing a mini-view of the function content.

Function types have a slightly different shape:

Semantics

A normal function in TASTE is a terminal level entity. It has a behavior that can be triggered through a set of provided interfaces:

All provided interfaces of a function have visibility and control access on the function's internal data (or state).

With one exception, the interfaces of a function are mutually exclusive, and run to completion: it is not possible to execute concurrently two interfaces of a function, as they share the function state.

The exception to this rule is the unprotected interface, which is executed immediately, possibly concurrently with other interfaces.

The attributes (or properties) of the functions are defined in the taste metamodel (see the subsequent chapters documenting the AADL Metamodel of TASTE).

The main attributes are:

• the function name
• optionally, if the function is an instance, the corresponding type
• a flag to indicate if the function is a type

There can be one or more implementations of a function. Each implementation has a name and an implementation language.

In Space Creator, the list of attributes is obtained by double-clicking on a function.

The list of supported languages for the implementations is defined in the metamodel.

A function can have optional context parameters. There are two kinds of such parameters:

• timers (not available for all implementation languages: e.g. simulink does not support timers)
• typed parameters with a value

Context parameters are linked to the implementation language of the functions and are available only for a subset of these supported languages. For C, SDL, and Ada they are generated as constants. For Simulink implementations, the context parameters are translated into Simulink tuneable parameters.

When a function type has context parameters, the value can be overwritten in instances of this type. This allows the function type to define a behavior that is parameterized by some values, and to have instance that give the actual values.

Provided and Required interfaces

A provided interface is a service offered by a function. It can be

• periodic, in which case it does not take any parameter and is used to execute the cyclic activities of the system
• sporadic (or asynchronous) and optionally carry a parameter.
• synchronous, with or without mutual exclusion, and with any number of in and out parameters.

protected interfaces are synchronous, but prevent concurrent execution with other interfaces of the same function. The caller will be blocked until the lock is released by the previous user.

Synchronous interfaces are like function calls in C or Ada. The call is immediate and blocking.

The graphical representation of interfaces is the following:

These are the attributes of provided interfaces:

• Cyclic interfaces have a period (in milliseconds)
• Sporadic interface instead have a minimum inter-arrival time (WCET) in milliseconds
• the queue size: how many messages can be stored when execution is delayed
• worst-case execution time (depending on the target).

An interface can optionally have parameters (similar to parameters of a function in a programming language)

Each parameter has:

• a name
• a corresponding data type (specified with the ASN.1 language)
• an encoding protocol (Native, uPER or ACN)
• a direction (in or out)

The encoding protocol refers to how the parameter will be encoded in memory before it is sent:

• native means just a memory dump, no pre-processing (it should be the default for the exchange of data between functions residing on the same physical node)
• uPER is an ASN.1 compact binary encoding rule that will produce a very small memory footprint of data
• ACN allows user to define the number of bits and their position for each data

AADL Metamodel

(Section written by Pierre Dissaux)

Applicable Document

[AADL] AADL standard: SAE AS-5506C (AADL v2.2)

Summary

This chapter describes the structure of the data model that is used by the TASTE graphical editors, and the AADL serialization mapping that ensures a seamless workflow along the whole TASTE tool-chain.

The TASTE modeling process requires the system to be described by four well delimited Views:

- The Data View exhibits all the data types that are used by the system and that have to be encoded at implementation level to ensure proper communication between functional components. The Data View is natively expressed in ASN.1 and its structure is automatically translated into a simplified corresponding AADL model for further use of the data types in the graphical editors. This document does not describe the Data View meta model.

- The Interface View (IV) defines the logical functions and their interactions within the system. All the data types referenced in the Interface View must be defined in the Data View. The Interface View can be designed thanks to the Space Creator front-end (or the TASTE-IV graphical editor for older systems) and serialized textually in a constrained subset of AADL.

- The Deployment View (DV) shows how the logical functions of the system are implemented on the target hardware. All the functions referenced in the Deployment View must be defined in the Interface View. The Deployment View can be designed thanks to the Space Creator front-end or using the TASTE-DV graphical editor and serialized textually in a constrained subset of AADL. The Deployment View reuses predefined hardware component descriptors that are available within an AADL library (HW Library).

- The Concurrency View (CV) is the result of an automatic model transformation whose inputs are the AADL serialization of the IV and DV and the output is a new AADL model including a multi-threading architecture complying with the Ravenscar Computation Model (RCM). There is currently no dedicated graphical editor; however any standard AADL graphical viewer can be used if necessary. Note that only a few real-time attributes can be manually modified in a Concurrency View.

The information contained in this document is related to the

The next two sections describe the meta-model as well as the AADL serialization rules for the Interface View and the Deployment View.

Note that this document is not a TASTE user or reference manual. It is assumed that the reader has an appropriate knowledge about the TASTE methodology and modeling concepts as well as the AADL language.

TASTE Interface View

A TASTE Interface View represents a software application composed of a set of system-level functions (TASTE Functions) connected together through functional interfaces.

The communication paradigm that is used is client-server subprogram call which denotes a control flow associated with optional data flows. Interfaces on the server side are TASTE Provided Interface (PI) whereas interfaces on the client side are TASTE Required Interfaces (RI).

TASTE Provided Interfaces trigger execution of operations which internal procedural behavior is specified at the TASTE level either by an SDL automaton or a link to source code files. In addition, the trigger condition of TASTE Provided Interfaces is specified by user-defined attributes associated to services of the TASTE Run Time.

TASTE Provided Interfaces may declare parameters (TASTE Parameters) whose data type is declared in the TASTE Data View.

In addition, state variables (TASTE Context Parameters) may be declared to express constant data that can be shared inside TASTE Functions. TASTE Context Parameters are instances of data types declared in the TASTE Data View.

Finally, TASTE Functions may be organized with a recursive composition hierarchy. According to Object-Oriented principles, a TASTE Function behaves like a singleton, i.e. it represents at the same time a classifier and its unique instance. However, it is also possible to define Function Types and Function Instances that respectively represent classifiers and their instances.

The usual way to handle TASTE Interface View models is through their AADL 2.2 representation (SAE AS 5506C). The AADL subset that is used for this purpose is described by a set of mapping rules that are presented below.

Note that only these precise AADL patterns are currently supported by the TASTE editors. For instance, the property values must be located at the specified location although alternate syntax might be valid AADL wise.

Standard TASTE Interface View Property set

A dedicated AADL property set has been defined to support specific TASTE semantics on top of standard AADL one. This property set is shared with all the other AADL tools of the TASTE toolchain. Only those properties that are meaningful for TASTE Interface Views are shown below:

This property set is made of two files located in the TASTE AADL Property Sets.

One of this file contains user defined properties that are dynamically added. They are declared in the TASTE_IV_Properties.aadl file. Only properties of type aadlboolean, aadlstring, aadlinteger, aadlreal and enumeration can be defined. These user-defined properties makes the tool extensible and open to external contributions and project-specific meta-data.

Interface view in AADL

The top level construct of a TASTE Interface View is represented by an AADL package with the fixed name of interfaceview::IV and an AADL System component named interfaceview. A minimalistic IV model looks like the following:

---------------------------------------------------
-- AADL2.2
-- TASTE type interfaceview
--
-- generated code: do not edit
---------------------------------------------------
PACKAGE interfaceview::IV
PUBLIC
WITH Taste;
WITH DataView;
WITH TASTE_IV_Properties;
SYSTEM interfaceview 
 
PROPERTIES
  Taste::dataView => ("DataView");
  Taste::dataViewPath => ("TASTE-Dataview.aadl");
  END interfaceview;
 
SYSTEM IMPLEMENTATION interfaceview.others
END interfaceview.others;
 
PROPERTIES
  Taste::dataView => ("DataView");
  Taste::dataViewPath => ("TASTE-Dataview.aadl");
  Taste::coordinates => "0 0 297000 210000";
  Taste::version => "2.2";
END interfaceview::IV;

Comment:

In the file header, “-- AADL2.2” specifies the version of the AADL standard that must be used to parse the file..

Function in AADL

A TASTE Function is represented by an AADL sub-Package (to avoid name conflicts) containing an AADL System with a user defined name, and a corresponding System subcomponent within the parent System. The top level parent System is the Interface View itself. A minimalistic terminal IV Function with no interfaces and no context parameters looks like the following:

PACKAGE interfaceview::IV::Function1
PUBLIC
 
WITH Taste;
WITH TASTE_IV_Properties;

SYSTEM Function1
PROPERTIES
  Source_Language => (C);
  Taste::Active_Interfaces => any;
END Function1;

SYSTEM IMPLEMENTATION Function1.others
END Function1.others;

END interfaceview::IV::Function1;

The AADL System component inside which the Function has been created (either the Interface View or another Function) is then enriched by a corresponding Subcomponent subclause, as shown as follows:

SYSTEM IMPLEMENTATION interfaceview.others
SUBCOMPONENTS
  Function1 : SYSTEM interfaceview::IV::Function1::Function1.others {
  Taste::coordinates => "115404 66438 155803 89795";
};
END interfaceview.others;

Comments

1. For upwards compatibility reasons with older versions of the TASTE-AADL mapping, the same TASTE Function name (“Function1” in the example above) must be used for the AADL Package name, the AADL System component name and the AADL System subcomponent name. This constraint should have to be removed in the future.

2. Distinction between resp. plain TASTE Functions (singletons), TASTE Function Types (classes) and TASTE Function Instances (objects) is obtained thanks to AADL Properties: resp. none, is_Component_Type and is_Instance_Of. This implementation has been done for upwards compatibility reasons only. Indeed, a smarter solution would consist in simply using the implicit AADL constructs (Components and Subcomponents) to represent classes and objects.

Provided Interface in AADL

A TASTE Provided Interface (PI) in a TASTE Function is represented by an AADL Subprogram component associated with a Provides Subprogram Access feature in the System component representing the Function. To allow a PI and a RI to share the same name, the AADL name of the Subprogram is the PI name prefixed by PI_.

A parameter less PI looks like the following:

SUBPROGRAM PI_PI1
END PI_PI1;

SUBPROGRAM IMPLEMENTATION PI_PI1.others
PROPERTIES
  Compute_Execution_Time => 0 ms .. 10 ms;
END PI_PI1.others;

SYSTEM Function1
FEATURES
  PI_PI1 : PROVIDES SUBPROGRAM ACCESS interfaceview::IV::Function1::PI_PI1.others {
   Taste::coordinates => "115404 69594";
   Taste::RCMoperationKind => cyclic;
   Taste::RCMperiod => 100 ms;
   Taste::Deadline => 100 ms;
   Taste::InterfaceName => "PI1";
  };
PROPERTIES
  Source_Language => (C);
  Taste::Active_Interfaces => enabled;
END Function1;

Comments

Some of the TASTE specific Properties, such as resp. RCMPeriod, Deadline or Associated_Queue_Size could be replaced with their corresponding standard AADL Property, i.e. resp. Period, Deadline and Queue_Size.

Required interface in AADL

A TASTE Required Interface (RI) in a TASTE Function is represented by an AADL Subprogram component associated with a Requires Subprogram Access feature in the System component representing the Function. To allow a PI and a RI to share the same name, the AADL name of the Subprogram is the RI name prefixed by RI_.

A parameter less RI looks like the following:

SUBPROGRAM RI_RI1
END RI_RI1;

SUBPROGRAM IMPLEMENTATION RI_RI1.others
END RI_RI1.others;

SYSTEM Function1
FEATURES
  RI_RI1 : REQUIRES SUBPROGRAM ACCESS interfaceview::IV::Function1::RI_RI1.others {
   Taste::coordinates => "148542 66438";
   Taste::RCMoperationKind => any;
   Taste::InterfaceName => "RI1";
   Taste::labelInheritance => "true";
  };
PROPERTIES
  Source_Language => (C);
  Taste::Active_Interfaces => enabled;
END Function1;

Interface Parameter in AADL

A TASTE Parameter in a TASTE Provided or Required Interface is represented by an AADL Parameter feature within the Subprogram component representing the PI or RI. The name of the Parameter is user defined.

A PI (or RI) with Parameters looks like the following:

SUBPROGRAM PI_PI1
FEATURES
  Param1 : IN PARAMETER DataView::MyInteger {
   Taste::encoding => NATIVE;
  };
  Param2 : OUT PARAMETER DataView::MyInteger {
   Taste::encoding => NATIVE;
  };
END PI_PI1;

Context Parameter in AADL

A TASTE Context Parameter in a TASTE Function is represented by an AADL Data subcomponent within the System component representing the Function. The name of the Context Parameter is user defined. A Function with a Context Parameter looks like the following:

SYSTEM IMPLEMENTATION Function1.others
SUBCOMPONENTS
  StateVar1 : DATA DataView::MyInteger {
   Taste::FS_Default_Value => "100";
  };
END Function1.others;

Connection in AADL

A TASTE Connection between a RI and a PI that expresses a call of the corresponding Operation or between two PIs or two RIs that expresses a delegation along the Function hierarchy is represented by an AADL Subprogram Access connection within the encompassing System component representing the Interface View or the parent Function.

A Connection between a RI and a PI at the top level of the Interface View looks like the following:

SYSTEM IMPLEMENTATION interfaceview.others
SUBCOMPONENTS
  Function1 : SYSTEM interfaceview::IV::Function1::Function1.others {
   Taste::coordinates => " 113668 65333 154067 88690 ";
  };
  Function2 : SYSTEM interfaceview::IV::Function2::Function2.others {
   Taste::coordinates => " 171698 65176 203576 88532 ";
  };
CONNECTIONS
  Function1_PI1_Function2_RI1 : SUBPROGRAM ACCESS Function1.PI_PI1 -> Function2.RI_RI1 {
   Taste::coordinates => " 154067 69752 162882 69752 162882 69910 171698 69910 ";
  };
END interfaceview.others;

Connection group in AADL

Connection groups simplify the visualization of the model. They are provided by the graphical editors but carry no semantics, and therefore are skipped during the AADL serialization process when using Space Creator. The former TASTE editors contained a serialization using the AADL Feature group synax, but since this approach is deprecated and not used in new models, it is not documented here.

Comments in AADL

TASTE offers two kinds of comments: textual descriptions that are associated with most of the entities, and graphical notes that can be added on the diagram and attached to the Interface View or Functions. Both are represented by formatted AADL comments. A textual description comment is inserted before the corresponding feature or subcomponent subclause, whereas a graphical note is inserted at the beginning of the corresponding Package.

A textual description for a Function at the top level of the Interface View looks like the following:

SYSTEM IMPLEMENTATION interfaceview.others
SUBCOMPONENTS
  -- [ interfaceview::IV::interfaceview.others.Function1 - text
  --this is a textual description
  --]

  Function1 : SYSTEM interfaceview::IV::Function1::Function1.others {
   Taste::coordinates => " 141287 65333 155218 88690";
  };
END interfaceview.others;

A graphical note for the same Function looks as follows:

PACKAGE interfaceview::IV::Function1
  -- { interfaceview::IV::Function1 - 144036 70099 147871 74039
  --this is a graphical note
  --}
PUBLIC
-- …
END interfaceview::IV::Function1;

Summary of the TASTE IV-AADL mapping

The following table provides a summary of the mapping that is used to serialize TASTE IV models in AADL.

Summary of the IV AADL mapping

IV	AADL
Interface View	Package + System composition
Function, Function Type, Function Instance	Package + System comp. + System subcomp.
Provided Interface	Subprogram + Provides Spg Access feature
Required Interface	Subprogram + Requires Spg Access feature
Context Parameter	Data subcomponent
Connection	Subprogram Access Connection
Textual description	Comment at the feature or subcomp. level
Graphical note	Comment at the Package level

TASTE Deployment View

The TASTE Deployment View model provides a description of the hardware execution platform and of the way the software Functions are allocated.

As opposed to the Interface View model, most of its components are defined as instances of classifiers that are pre-declared within a library (HWLibrary). This library only contains the subset of AADL hardware components and corresponding AADL Property Sets that are recognized by the downstream part of the TASTE tool-chain, and especially by the Ocarina code generator and the various supported middleware. It is not in the scope of this document to provide details about the modeling choices that have been taken to represent these hardware elements. Please refer to the documentation of HW Library for this purpose. In particular, the AADL representation of multicore Processors is specific to this library and the Deployment View model does not make a difference between single core and multicore Processors.

The Deployment View model needs access to the Interface View model so that Functions can be allocated to Processors and inter-nodes logical Connections can be allocated to Buses. A Deployment View model is composed of network nodes (at least one) connected by buses. Each node represents a Processor Board that contains at least one Processor and optional Bus Drivers. Bus Drivers may be connected to Buses when needed. Each Processor executes software that resides inside Partitions (at least one).

A set of additional entities and attributes have been added to the original Deployment View model constructs to support Time and Space Partition (TSP) architectures. Time partitioning is defined by additional scheduling attributes within the Processor whereas space partitioning requires the definition of memory segments associated with each Partition. Additional information such as the criticality level of each Partition can be also specified. Note that use of TSP features with multicore Processors has not been validated yet.

AADL Serialization (overview)

The usual way to handle TASTE DV models is through their AADL 2.2 representation (SAE AS 5506C). The AADL subset that is used for this purpose is described by a set of mapping rules that are presented below. Note that only these precise AADL patterns are currently supported by the TASTE editors. For instance, the property values must be located at the specified location although alternate syntax might be valid AADL wise.

Standard DV Property set

As for the interface view, a dedicated TASTE AADL Property Set has been defined to support specific TASTE semantics on top of standard AADL one. This property set is shared with all the other AADL tools of the TASTE toolchain.

Deployment view in AADL

The top level construct of a TASTE Deployment View is represented by an AADL package with the fixed name of deploymentview::DV and an AADL System component named deploymentview.

A minimalistic DV model looks like the following:

---------------------------------------------------
-- AADL2.2
-- TASTE type deploymentview
--
-- generated code: do not edit
---------------------------------------------------
PACKAGE deploymentview::DV
PUBLIC
WITH Taste;
WITH TASTE_DV_Properties;
WITH interfaceview::IV;
SYSTEM deploymentview
END deploymentview;

SYSTEM IMPLEMENTATION deploymentview.others
SUBCOMPONENTS
 interfaceview : SYSTEM interfaceview::IV::interfaceview.others;
END deploymentview.others;

PROPERTIES
 Taste::coordinates => "0 0 297000 210000";
 Taste::version => "2.2";
 Taste::interfaceView => "docIV.aadl";
 Taste::HWLibraries => ("NewLibHWTaste");
END deploymentview::DV;

Comment 1. In the file header, “-- AADL2.2” specifies the version of the AADL standard that must be used to parse the file..

Processor Board in AADL

A TASTE Processor Board is represented in AADL as a dedicated Package containing locally defined components as well as, at the top level Package, a System component and a corresponding subcomponent inside the deploymentview System implementation.

An empty Processor Board would look as follows:

PACKAGE deploymentview::DV::GR_XC3S_1500_rtems
PUBLIC
-- locally defined components (Partitions) or extended ones (Drivers)
END deploymentview::DV::GR_XC3S_1500_rtems;
-- …
PACKAGE deploymentview::DV
PUBLIC
WITH deploymentview::DV::GR_XC3S_1500_rtems;
WITH Taste;
-- …
SYSTEM GR_XC3S_1500_rtems
END GR_XC3S_1500_rtems;
SYSTEM IMPLEMENTATION GR_XC3S_1500_rtems.others
SUBCOMPONENTS
-- instances of components defined in the above package
END GR_XC3S_1500_rtems.others;
SYSTEM deploymentview
END deploymentview;
SYSTEM IMPLEMENTATION deploymentview.others
SUBCOMPONENTS
GR_XC3S_1500_rtems : SYSTEM GR_XC3S_1500_rtems.others {
Taste::coordinates => "76603 109957 147520 131388";
};
-- …
END deploymentview.others;
END deploymentview::DV;

Comments

1. The dedicated Package is used to define or redefine the components that are part of the board and that may be locally customized, such as the AADL Devices representing the Bus Drivers and the AADL Systems representing the allocated Functions of the Interface View.

2. Processor Boards may be assembled in the DV editor, or better directly instantiated from the HWLibrary. The latter option ensures that the set of components that compose the board (Processor and Drivers) are consistent.

3. In case of Time and Space Partition (TSP) architecture, Processor Boards also contain AADL Virtual Processors (time partitioning) and AADL Memories (space partitioning). However, these subcomponents are not graphically represented by dedicated entities in the DV diagram. Please refer to the dedicated section for further details about TSP models.

Processor in AADL

Processors are defined inside the HWLibrary under a form that complies with the requirements of the Ocarina code generator and the PolyORB runtime middleware. No details about the internal representation of a Processor are available while editing a Deployment View model. This is especially the case for multicore Processors that cannot be distinguished from single core ones at DV level.

The AADL representation of a Processor in a DV model is thus very simple:

PACKAGE deploymentview::DV
PUBLIC
WITH Processors::SPARC;
WITH Taste;
-- …
SYSTEM IMPLEMENTATION GR_XC3S_1500_rtems.others
SUBCOMPONENTS
LEON_Core : PROCESSOR Processors::SPARC::LEON2 {
Taste::coordinates => "83695 112100 140428 120673";
};
-- …
END GR_XC3S_1500_rtems.others;
-- …
END deploymentview::DV;

In case of a Time and Space Partition architecture, the Processor holds the top level scheduler that defines the major frame and the slots allocated to each Partition. Please refer to section 4.3.6 for further details about AADL representation of TSP architectures:

PACKAGE deploymentview::DV
PUBLIC
WITH ocarina_processors_leon;
WITH Taste;
WITH ARINC653;
-- …
SYSTEM IMPLEMENTATION TSPNode.others
SUBCOMPONENTS
proc1 : PROCESSOR ocarina_processors_leon::leon3.AIR {
Taste::coordinates => "97211 57510 151760 98958";
};
-- …
PROPERTIES
ARINC653::Module_Major_Frame => 3000 ms APPLIES TO proc1;
ARINC653::Module_Schedule => (
[ Partition => reference(part1_VP);
Duration => 1500 ms;
Periodic_Processing_Start => False; ],
[ Partition => reference(part2_VP);
Duration => 1500 ms;
Periodic_Processing_Start => False; ]
) APPLIES TO proc1;
END TSPNode.others;
-- …
END deploymentview::DV;

Comments

1. Each used Package of the HWLibrary must be made visible independently with a WITH

statement.

2. The most natural approach to manage multi-core Processors, that would have been fully compliant with the current version of the AADL standard (v2.2) and recent work on scheduling analysis for this kind of architecture, would have been to represent each individual core by a Processor. It would have made no change for single core Processors and would have shown as may Processors as cores in side the Processor Board in case of a multi-core architecture. However, the team in charge of the development of the HWLibrary made another choice for the AADL representation of multi-core Processors. With this approach, whatever it is single or multi core architecture, it remains represented by a single Processor inside the Processor Board and its internal structure is not managed at the TASTE DV level. A consequence is that in case of use of TSP configuration, the provided scheduling data (major frame and time slots) will apply in a same way to all cores.

Partition in AADL

Partitions are represented by AADL Process components. Process component type and implementation are defined in the dedicated Package associated with each Processor Board, whereas the Process subcomponent is instantiated inside the System implementation representing the Processor Board inside the main Package. By default, a single Partition is added to each Processor Board. In case of TSP architecture, other Partitions may be added manually and more complete information will be required for the AADL serialization.

The AADL representation for a single Partition (default case) is as follows:

PACKAGE deploymentview::DV::GR_XC3S_1500_rtems
PUBLIC
-- …
PROCESS LEON2_partition
END LEON2_partition;
PROCESS IMPLEMENTATION LEON2_partition.others
END LEON2_partition.others;
-- …
END deploymentview::DV::GR_XC3S_1500_rtems;
-- …
PACKAGE deploymentview::DV
PUBLIC
WITH deploymentview::DV::GR_XC3S_1500_rtems;
WITH Processors::SPARC;
WITH Deployment;
WITH Taste;
-- …
SYSTEM IMPLEMENTATION GR_XC3S_1500_rtems.others
SUBCOMPONENTS
LEON_Core : PROCESSOR Processors::SPARC::LEON2 {
Taste::coordinates => "83695 112100 140428 120673";
};
LEON2_partition : PROCESS
deploymentview::DV::GR_XC3S_1500_rtems::LEON2_partition.others {
Taste::coordinates => "89368 113815 134755 119816";
Deployment::Port_Number => 0;
};
-- …
PROPERTIES
Actual_Processor_Binding => (reference (LEON_Core)) APPLIES TO LEON2_partition;
-- …
END GR_XC3S_1500_rtems.others;
-- …
END deploymentview::DV;

In case of a Time and Space Partition configuration, the AADL description is updated as follows. It introduces a set of additional components that are not explicitly represented in the TASTE model (Memory, Virtual Processor) and a list of properties whose value can be edited in the existing entities. The AADL representation for TSP systems follows the recommendations of the standard AADL annex for ARINC 653 (document SAE AS5506/1A).

In practice, an AADL Virtual Processor is created for each Partition and the corresponding AADL Process is bound to it instead of to the AADL Processor. The Virtual Processors are themselves bound to the Processor. In addition, the memory structure is represented by AADL Memory components and each AADL Process is bound to a dedicated memory segment to ensure space partitioning.

PACKAGE deploymentview::DV::TSPNode
PUBLIC
WITH Taste;
WITH Deployment;
WITH ARINC653;
PROCESS part1
END part1;
PROCESS IMPLEMENTATION part1.others
END part1.others;
VIRTUAL PROCESSOR part1_VP
PROPERTIES
Deployment::Execution_Platform => AIR;
ARINC653::Partition_Identifier => 0;
END part1_VP;
VIRTUAL PROCESSOR IMPLEMENTATION part1_VP.others
END part1_VP.others;
PROCESS part2
END part2;
PROCESS IMPLEMENTATION part2.others
END part2.others;
VIRTUAL PROCESSOR part2_VP
PROPERTIES
Deployment::Execution_Platform => AIR;
ARINC653::Partition_Identifier => 1;
END part2_VP;
VIRTUAL PROCESSOR IMPLEMENTATION part2_VP.others
END part2_VP.others;
MEMORY main_memory
END main_memory;
MEMORY IMPLEMENTATION main_memory.others
SUBCOMPONENTS
part1_Segment : MEMORY partition_memory.others {
Base_Address => 16#100000#;
Memory_Size => 16#100#;
Byte_Count => 16#100#;
};
part2_Segment : MEMORY partition_memory.others {
Base_Address => 16#600000#;
Memory_Size => 16#100#;
Byte_Count => 16#100#;
};
END main_memory.others;
MEMORY partition_memory
END partition_memory;
MEMORY IMPLEMENTATION partition_memory.others
END partition_memory.others;
END deploymentview::DV::TSPNode;
-- …
PACKAGE deploymentview::DV
PUBLIC
WITH ocarina_processors_leon;
WITH deploymentview::DV::TSPNode;
WITH Taste;
WITH Deployment;
WITH ARINC653;
-- …
SYSTEM IMPLEMENTATION TSPNode.others
SUBCOMPONENTS
part1 : PROCESS deploymentview::DV::TSPNode::part1.others {
Taste::coordinates => "102666 65800 146305 81887";
Deployment::Port_Number => 0;
};
part1_VP : VIRTUAL PROCESSOR deploymentview::DV::TSPNode::part1_VP.others {
Scheduling_Protocol => (Posix_1003_Highest_Priority_First_Protocol);
ARINC653::DAL => LEVEL_A;
};
part2 : PROCESS deploymentview::DV::TSPNode::part2.others {
Taste::coordinates => "102517 83305 146926 97005";
Deployment::Port_Number => 0;
};
part2_VP : VIRTUAL PROCESSOR deploymentview::DV::TSPNode::part2_VP.others {
Scheduling_Protocol => (Posix_1003_Highest_Priority_First_Protocol);
ARINC653::DAL => LEVEL_A;
};
proc1 : PROCESSOR ocarina_processors_leon::leon3.AIR {
Taste::coordinates => "97211 57510 151760 98958";
};
main_memory : MEMORY deploymentview::DV::TSPNode::main_memory.others;
PROPERTIES
Actual_Processor_Binding => (reference (proc1)) APPLIES TO part1_VP;
Actual_Processor_Binding => (reference (part1_VP)) APPLIES TO part1;
Actual_Memory_Binding => (reference (main_memory.part1_Segment)) APPLIES TO part1;
Actual_Processor_Binding => (reference (proc1)) APPLIES TO part2_VP;
Actual_Processor_Binding => (reference (part2_VP)) APPLIES TO part2;
Actual_Memory_Binding => (reference (main_memory.part2_Segment)) APPLIES TO part2;
ARINC653::Module_Major_Frame => 3000 ms APPLIES TO proc1;
ARINC653::Module_Schedule => (
[ Partition => reference(part1_VP);
Duration => 1500 ms;
Periodic_Processing_Start => False; ],
[ Partition => reference(part2_VP);
Duration => 1500 ms;
Periodic_Processing_Start => False; ]
) APPLIES TO proc1;
END TSPNode.others;
-- …
END deploymentview::DV;

Comments

1. AADL Virtual Processors and Memories that are used for the implementation of TSP do not correspond to a graphic entity (box) in the TASTE DV diagram. Instead, the required information can be edited inside the various dialog boxes associated with the existing TASTE entities.

2. Without TSP, the AADL Process is directly bound to the AADL Processor whereas with TSP, the AADL Processes are each of them bound to an AADL Virtual Processor that are all of them bound to the Processor.

3. Without TSP, we don’t care about memory whereas with TSP, each AADL Process is bound to a memory segment represented by an AADL Memory subcomponent of another AADL Memory representing the main memory of the Processor Board.

Bus in AADL

Buses are defined inside the HWLibrary under a form that complies with the requirements of the Ocarina code generator and the PolyORB runtime middleware. Processor Boards can access Buses thanks to dedicated Bus Drivers (see next section).

PACKAGE deploymentview::DV
PUBLIC
WITH Buses::UART;
WITH Taste;
WITH interfaceview::IV;
-- …
SYSTEM IMPLEMENTATION deploymentview.others
SUBCOMPONENTS
UART_impl : BUS Buses::UART::UART.impl {
Taste::coordinates => "127511 86323 153234 95476";
};
interfaceview : SYSTEM interfaceview::IV::interfaceview.others;
-- …
PROPERTIES
Actual_Connection_Binding => (reference (UART_impl))
APPLIES TO interfaceview.F2_PI_exec_F1_RI_exec;
END deploymentview.others;
--…
END deploymentview::DV;

Comments

1. In case two IV Functions are logically connected together and are deployed onto two different Processors in the DV model, the corresponding IV Connection must be bound to a Bus in the DV.

Bus Driver in AADL

Bus Drivers represent the piece of software that implements the communication protocol between remote Functions connected via a Bus. Bus Drivers are defined inside the HWLibrary under a form that complies with the requirements of the Ocarina code generator and the PolyORB runtime middleware.

The definition of a Bus Driver in AADL is done in two steps. Firstly, the HWLibrary component is extended within the AADL Package dedicated to the corresponding Processor Board. This extension is used to add local graphical properties for the connectors. Secondly, this extended component is instantiated inside the AADL System Implementation representing the Processor Board within the main deployment::DV Package and the corresponding Requires Bus Access features of the Bus Driver and the Processor Board are connected together.

PACKAGE deploymentview::DV::Node1
PUBLIC
WITH Buses::UART;
WITH RTEMS5_UART;
WITH Taste;
WITH Deployment;
-- …
DEVICE RTEMS5_APBUART_impl
EXTENDS RTEMS5_UART::RTEMS5_APBUART
FEATURES
Interface1 : REFINED TO REQUIRES BUS ACCESS Buses::UART::UART.impl {
Taste::coordinates => "116780 73265";
};
PROPERTIES
Taste::Interface_Coordinates => "127511 90742" APPLIES TO Interface1;
Deployment::Help => "Write your ASN.1 configuration here";
Deployment::Config => "OCARINA_INCLUDE_PATH/ocarina/runtime/
polyorb-hi-c/src/drivers/configuration/serial.asn";
Deployment::Version => "0.1beta";
END RTEMS5_APBUART_impl;
DEVICE IMPLEMENTATION RTEMS5_APBUART_impl.others
EXTENDS RTEMS5_UART::RTEMS5_APBUART.impl
END RTEMS5_APBUART_impl.others;
-- …
END deploymentview::DV::Node1;
-- …
PACKAGE deploymentview::DV
PUBLIC
WITH deploymentview::DV::Node1;
WITH Processors::x86;
WITH Buses::UART;
WITH Taste;
SYSTEM Node1
FEATURES
RTEMS5_APBUART_impl_UART_impl : REQUIRES BUS ACCESS Buses::UART::UART.impl;
END Node1;
SYSTEM IMPLEMENTATION Node1.others
SUBCOMPONENTS
-- …
Generic_x86 : PROCESSOR Processors::x86::Generic_x86 {
Taste::coordinates => "104091 49679 127574 67385";
};
RTEMS5_APBUART_impl : DEVICE deploymentview::DV::Node1::RTEMS5_APBUART_impl.others {
Taste::coordinates => "109363 68332 122303 73265";
};
PROPERTIES
-- …
Actual_Processor_Binding => (reference (Generic_x86)) APPLIES TO RTEMS5_APBUART_impl;
END Node1.others;
-- …
END deploymentview::DV;

Comments

1. While using a Processor Board component of the HW Library, a set of predefined Bus Drivers is provided.

2. Bus Drivers are bound to the Processor of the Processor Board.

4.3.9. Bus Connection in AADL

On a DV diagram, Bus Connections go directly from a Bus Driver connector to a Bus connector. In the corresponding AADL representation, there are two connections: one between the Bus Driver connector and the corresponding invisible connector of the encompassing Processor Board, and another between the Processor Board connector and the Bus component (no connector feature required).

PACKAGE deploymentview::DV
PUBLIC
WITH deploymentview::DV::Node1;
WITH Buses::UART;
WITH Taste;
SYSTEM Node1
FEATURES
RTEMS5_APBUART_impl_UART_impl : REQUIRES BUS ACCESS Buses::UART::UART.impl;
END Node1;
SYSTEM IMPLEMENTATION Node1.others
SUBCOMPONENTS
-- …
RTEMS5_APBUART_impl : DEVICE deploymentview::DV::Node1::RTEMS5_APBUART_impl.others {
Taste::coordinates => "109363 68332 122303 73265";
CONNECTIONS
RTEMS5_APBUART_impl_UART_impl_Interface1 : BUS ACCESS
RTEMS5_APBUART_impl_UART_impl -> RTEMS5_APBUART_impl.Interface1;
-- …
END Node1.others;
-- …
SYSTEM IMPLEMENTATION deploymentview.others
Node1 : SYSTEM Node1.others {
Taste::coordinates => "101156 47343 130509 74329";
};
UART_impl : BUS Buses::UART::UART.impl {
Taste::coordinates => "127511 86323 153234 95476";
};
-- …
CONNECTIONS
Connection1 : BUS ACCESS UART_impl -> Node1.RTEMS5_APBUART_impl_UART_impl {
Taste::coordinates => "116780 73265 116780 90742 127511 90742";
};
-- …
END deploymentview.others;
-- …
END deployment::DV;

Comments

1. AADL Requires Bus Access features are added to each Processor Board that is connected to Buses. These features are not shown in DV diagrams where Bus Drivers are directly connected to Buses.

FunctionDV in AADL

FunctionDV components are proxies of IV Functions within the DV model. They appear in the bind list of each Partition. In the AADL representation, an AADL System associated with each used IV Function is instantiated within the AADL System Implementation describing the Processor Board. A dedicated property is then used to bind this AADL System to the AADL Process representing the Partition.

PACKAGE deploymentview::DV
PUBLIC
WITH interfaceview::IV::F1;
WITH deploymentview::DV::Node1;
WITH Taste;
WITH Deployment;
-- …
SYSTEM IMPLEMENTATION Node1.others
SUBCOMPONENTS
IV_F1 : SYSTEM interfaceview::IV::F1::F1.others {
Taste::FunctionName => "F1";
};
Partition0 : PROCESS deploymentview::DV::Node1::Partition0.others {
Taste::coordinates => "105492 53208 124279 64545";
Deployment::Port_Number => 0;
};
-- …
PROPERTIES
Taste::APLC_Binding => (reference (Partition0)) APPLIES TO IV_F1;
-- …
END Node1.others;
-- …
END deploymentview::DV;

Comments

1. The standard AADL property Actual_Function_Binding could be used instead of the specific Taste::APLC_Binding one.

Summary of the TASTE DV-AADL mapping

The following table provides a summary of the mapping that is used to serialize TASTE DV models in AADL. Note that management of textual descriptions and graphical notes in the DV is similar to what is described for the IV.

Summary of the DV-AADL Mapping

DV	AADL
Deployment View	Package + System
Processor Board	Package + System + Memory + Virtual Proc.
Processor	Processor
Partition	Process
Bus	Bus
Bus Driver	Device
Bus Connection	Bus Access Connection
FunctionDV	System
Textual description	Comment at the feature or subcomp. level
Graphical note	Comment at the Package level