TASTE Semantics

From TASTE
Revision as of 08:26, 28 April 2023 by Mperrotin (talk | contribs) (Summary of the TASTE IV-AADL mapping)
Jump to: navigation, search

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 inspired by the Specification and Description Language (SDL). There are a few differences that are explained below.

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 with no limit.
  • 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:


ClipCapIt-210128-204613.PNG

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

ClipCapIt-210128-205423.PNG

Function types have a slightly different shape:

ClipCapIt-210128-210214.PNG


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:

ClipCapIt-210607-103230.PNG


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 - https://gitrepos.estec.esa.int/taste/taste-setup/-/blob/feature_buster/misc/space-creator/default_attributes.xml

The main attributes are:

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

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

ClipCapIt-210129-164829.PNG

The list of supported languages is defined in the metamodel.

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

  • 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 example if a function is implemented in Matlab Simulink, it won't be possible to add timers to it. Typed parameters, on the other hand will be mapped to 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:

ClipCapIt-210129-174720.PNG

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).
ClipCapIt-210129-174831.PNG

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.

| class="wikitable" style="margin:auto" |+ 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 |-Interface Parameter || Parameter 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 |}