This page gives a comprehensive description of the semantics behind the TASTE meta-model.
THIS PAGE IS WORK IN PROGRESS
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.
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:
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:
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 - 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.
The list of supported languages is defined in the metamodel.
A function can have optional context parameters. There are two kinds of such parameters:
- typed parameters with a value
Context parameters are linked to the inmplementation 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:
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).
When an interface has parameters, they are specified with a number of attributes:
- the parameter name
- the parameter type (ASN.1 data type)
- the parameter encoding rule (Native, uPER or ACN)
- the parameter 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 bewteen function 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