Chapter 14. Extending the Language
AADL allows you to introduce additional properties and property types through property sets. This is useful if you need to add information to an AADL model and no appropriate predeclared or user defined property has been declared. In addition, you can introduce a new sublanguage to AADL as an annex extension. You can then use this sublanguage to define reusable annex libraries similar to collections of classifiers, and attach sublanguage expressions to classifiers through annex subclauses. You will want to use sublanguages if you need to introduce objects that can have properties. For example, the Error Model Annex has been introduced as a sublanguage standard, such that you can define faults and error states as objects and attribute them to a component and associate property values with them (e.g., probability of occurrence).
14.1. Property Sets
You define new properties, property types, and property constants in property sets. Each property set provides a separate name space. Property set names are simple identifiers (i.e., there are no nested property set names). By preceding the property name, property type name, or property constant name with the property set name followed by “::” you can uniquely reference them. You have to include the property set name even if the property, property type, or property constant is declared in the same property set. For predeclared properties, property types, and constants you may omit the property set name.
If you refer to properties, property types, or property constants in another property set, you must declare the property set as accessible using a with declaration. Similarly, you must add a package name to the with declaration if property definitions reference a classifier in that package. Finally, you have to add the property set name to the with declaration of a package if the package contains references to properties, property types, or property constants of that property set. In other words, you explicitly declare your intent to reference entities in a package or a property set by adding the package name or property set name to the with declaration of the package or property set that contains the reference.
14.1.1. Declaring Property Sets
The template for declaring a property set is shown in Figure 14-1. The property set name must be a legal AADL identifier. You can declare a property set that is initially empty, to be filled in by somebody else or later by you. The optional with import statement identifies the other property sets and packages that are referenced from within the property set. The property type, property, and property constant declarations can be included in any order. In other words, there is no requirement to place the property type declaration before the property definition declaration that references it.
Figure 14-1. A Property Set Declaration Template
Table 14-1 summarizes the declarations allowed in a property set. Each is discussed in more detail in subsequent sections.
Table 14-1. Declarations Within a Property Set
Listing 14-1 shows a property set declaration set_of_faults and includes examples of property name, property type, and property constant declarations. The property named comm_error_status is defined as a property of type aadlboolean (true or false) that applies to system and device components. A property type Speed_Range is defined as a range of real values from 0.0 mph..150.0 mph. The property constant Maximum_Faults is defined as the integer value 3.
Listing 14-1. Sample Property Set Declarations
system implementation data_processing.accelerometer_data
properties
set_of_faults::comm_error_status => true;
end data_processing.accelerometer_data;
property set set_of_faults is
-- A property definition declaration.
comm_error_status: aadlboolean applies to (system, device);
-- A example property type declaration.
Speed_Range : type range of aadlreal 0.0 .. 150.0 units (mph);
-- An example property constant declaration.
Maximum_Faults : constant aadlinteger => 3;
end set_of_faults;
14.1.2. Property Type Declarations
AADL has a set of built-in types for properties. These are shown in Table 14-2 and can be used immediately in property definitions. In addition, AADL allows you to define your own types, just as you do when defining data types in programming languages. For that purpose, you use property type declarations.
Table 14-2. Built-In AADL Property Types
With a property type declaration, you define your own property type by establishing a name and the set of legal values for a property of that type through a type definition. The template for a property type declaration is shown in the following box:
name: type <type definition>;
The entry <type definition> can be one of the built-in property types or it can be defined with one of the type constructors shown in Table 14-3. A type constructor can refer to another property by name. In this case, you must include the property set name separated by double colon (“::”) to qualify the property type, even if the referenced property type is in the same property set. Only predeclared property types can be referenced without qualifying them by property set name.
Table 14-3. AADL Property Type Constructors
In the examples shown in Listing 14-2, the property type bit_error is defined as an aadlboolean. The predefined aadlboolean property type has two legal values, true and false. The property types fault_category and fault_condition are defined as enumeration types. An enumeration property type defines a specific set of identifiers as its legal values.
Numeric type declarations can have measurement units and limits on acceptable values. For example, the type number_of_components is declared in the property set some_types as an aadlinteger that accepts values between 0 and 25. The property type metric_length_units introduces metric measurement units for length with conversion factor. Within the property set marine_measures, the Depth_Units units type is defined. It is used to define the type working_depth as a range of real values with any of the Depth_Units units. You have to qualify the reference to Depth_Units with the property set name. The property type Metric_Length is defined as real values with units defined in the property set some_types. Therefore, you have to include that property set in the with clause of marine_measures.
Listing 14-2. Sample Property Type Declarations
property set set_of_faults is
bit_error: type aadlboolean;
fault_category: type enumeration
(benign, tolerated, catastrophic);
fault_condition: type enumeration (okay, error, failed);
end set_of_faults;
property set some_types is
number_of_components: type aadlinteger 0 .. 25;
metric_length_units: type units
(meters, kilometers => meters * 1000);
end some_types;
property set marine_measures is
with some_types;
Depth_Units : type units ( feet, fathom => feet * 6,
shackle => fathom * 15 );
working_depth: type range of aadlreal
marine_measures::Depth_Units;
Metric_Length: type aadlreal some_types::metric_length_units;
end marine_measures;
14.1.3. Property Definitions
A property definition declaration allows you to define a new property by declaring a name, and by specifying a property type. The property is specified either by a type constructor or by reference to a property type by name. You indicate acceptable owners of the property through the applies to clause. You can declare the property to accept a single value or a list, whose values can be single values of the specified type or can be lists of values themselves. The templates for both single-valued and list-valued property definitions are shown in the following box.
name : [inherit] <property type> [=> <default value>]
applies to <property owner>;
name : [inherit] ( list of )+ <property type>
[=> <default values>] applies to <property owner>;
You can limit the property ownership to certain model elements (i.e., to components of specific categories by naming their AADL Meta model class), to components of specific classifiers, and to other named model elements through their AADL Meta model class, such as ports, connections, modes, or even model elements defined in Annex sublanguages (see Section 14.2). Alternatively, you can use the reserved word all to indicate that the property is acceptable to all named model elements. Note that all properties, both standard and newly defined, apply to abstract components, regardless of the applies to statement used in their definition.
The optional reserved word inherit indicates that the property can inherit a value from a component in which it is contained.
The optional default value is returned as property value if no value is explicitly assigned (see Section 13.2.3). If no default value is specified the value is undefined or the empty set in the case of a list of values.
Example property declarations within a property set set_of_property_names are shown in Listing 14-3. The property critical_unit is declared as type aadlboolean and applies to all component categories. Its property value can be inherited from the enclosing component if not assigned to a model element. The property Boat_Length is declared in terms of the property type Metric_Length defined in another property set. The property Maintainers accepts a list of string values, with a list of three values as default. The property value if a single string is assigned for the system basic_dual. The list-valued property Shared_Memory of type reference, which accepts references to memory components, is assigned a set of values in the system implementation basic_dual.impl.
Listing 14-3. Sample Property Definition Declarations
property set my_props is
with marine_measures;
critical_unit: inherit aadlboolean applies to (all);
Boat_Length: marine_measures::Metric_Length
applies to (device, system);
Maintainers: list of aadlstring => ("Peter", "John", "Dave")
applies to (all);
Shared_Memory: list of reference (memory) applies to (system);
end my_props;
package marine_lib
with my_props
system basic_dual
properties
myprops::Maintainers => ("John");
end basic_dual;
system implementation basic_dual.impl
subcomponents
mem01: memory;
mem02: memory;
mem03: memory;
properties
myprops::Shared_Memory => (reference(mem01), reference(mem03));
end basic_dual.impl;
device MotorBoat
properties
Boat_Length => 10.0 meters;
end MotorBoat;
end marine_lib;
14.1.4. Property Constant Declarations
Property constants are property values that are known by a symbolic name. You declare property constants in property sets. The name can be used wherever the value itself is permissible. Some property constants are provided in AADL standard property sets.
The basic declaration templates for single-valued and list-valued property constant declarations are shown in the following box. In the case of a list-valued constant the elements of the list can be single values or list values themselves.
name: constant <property type> => <property value>
name: constant ( list of )+ <property type> => <property values>
The <property type> is a type constructor or refers to an explicitly declared property type. If the reserved words list of are used in the declaration, the type is list valued.
Some sample declarations are shown in Listing 14-4, where, for the property set limits_set, Max_Threads is defined as an integer value of 256; Minimum_value is defined as a real value of 5.0; and Default_Fault_State is defined as a constant of the type fault_condition with the value of okay. The type fault_condition, referenced in Listing 14-4, is defined in the package set_of_faults, as shown in Listing 14-2.
Listing 14-4. Sample Property Constant Declarations
property set limits_set is
with set_of_faults, operations_set;
Max_Threads : constant aadlinteger => 256;
Minimum_value: constant aadlreal => 5.0;
Default_Fault_State: constant
set_of_faults::fault_condition => okay;
end limits_set;
14.2. Annex Sublanguages
Additions to introducing new properties into AADL, you can extend the set of language concepts by introducing sublanguages through Annexes. An Annex sublanguage can provide new categories of model elements, allow you to declare classifiers of those new model element categories, define properties that can be associated with them, and attach instances of the model elements to components. The structure of this sublanguage is specified in an annex document by defining a Meta model, whose classes are subclasses of the AADL Meta model, in particular of the classes Named Element and Classifier. The annex document also defines a textual syntax to be used in annex clauses of the textual AADL model. You use annex library statements to declare classifiers of annex categories in packages, the same way you declare component classifiers in packages. You can then reference these annex classifiers in annex subclauses that are attached to component types and implementations—similar to subcomponent declarations referencing component classifiers. Annex libraries and annex subclauses may contain references into the core AADL model elements.
The Error Model Annex standard [EAnnex] is an example of such a sublanguage. You can introduce error state machines as classifiers in annex library declarations of the Error Model. These state machines consist of error states and error transitions (similar to modes and mode transitions), error events that represent faults (similar to subcomponents), and error propagations that represent component errors that may affect components this component interacts with. The error events and error propagation can have an occurrence property to indicate the probability of a fault occurring or being propagated. You then associate an instance of this error state machine with a component by referencing the error state machine classifier in an Error Model annex subclause. By doing so, you indicate that any instance of the component type or component implementation with this error state machine has a fault behavior described by the error state machine. In the Error Model annex subclause you can specify conditions under which errors are propagated out through a specific component port. This is an example, where an expression in an annex sublanguage can refer to a model element in core AADL.
AADL can have multiple Annex sublanguages. For example, the AADL standards committee is also introducing a Behavior Annex as a standard [BAnnex]. In addition, you can introduce nonstandard sublanguages that you may use only within your project.
14.2.1. Declaring Annex Concepts in Libraries
AADL has defined a standard syntactic construct through which you introduce annex libraries. The template for an annex library declaration is shown in the following box.
annex <annex name> {** <library content> **};
Annex library declarations must be placed in packages. You can place them anywhere within the public or private section of the package. You can only declare one annex library for each sublanguage in each package. The annex name identifies the annex sublanguage and must be a legal AADL identifier. The library content is enclosed in the symbols {** and **}. It consists of the language constructs, such as classifiers that can be referenced by multiple annex subclauses. The annex sublanguage syntax can use anything other than the closing **}.
An excerpt from an SAE standard error model annex [EAnnex] library is shown in Listing 14-5. The library is declared in the package E_Models and identifies the sublanguage as Error_Model. Error_Model is the annex sublanguage name defined in the Error Model Annex standard. The excerpt establishes an error state machine model type Three_State. This error model type can be referenced in an error model annex subclause. Notice that the constructs for the error model annex are similar to the AADL language syntax and style. However, this need not be the case. Any set of textual language constructs can be included within an annex (e.g., the Object Constraint Language (OCL) or a temporal logic notation).
Listing 14-5. An Example Error Annex Library
package E_Models
public
annex Error_Model {**
error model Three_State
features
Fail_Stop : error event
{ Occurrence => poisson 10E-4 } ;
Fail_Active : error event
{ Occurrence => poisson 10E-5 } ;
No_Data, Bad_Data : in out error propagation;
Error_Free: initial error state;
Stopped, Active_Fault: error state;
end Three_State;
**};
end E_Models;
14.2.2. Using Annex Concepts in Subclauses
Annex sublanguage concepts introduced through an annex library are attached to an AADL model by using an annex subclause within a component type, component implementation, or feature group type declaration. An annex subclause must be the last section of either a component type or component implementation declaration following the properties section. A different annex subclause can be declared for each mode. A component type or component implementation may contain at most one annex subclause (per mode) for each annex sublanguage. The basic template for an annex subclause is shown in the following.
annex <annex name> {** < subclause content> **} [ <in modes> ] ;
The name of the annex name in the subclause identifies the annex sublanguage. The syntax of the subclause content can refer to items in the annex library and to basic AADL model elements.
An example annex subclause for the error model annex is shown in Listing 14-6. In this example, the error model type Three_State, defined in the annex library in package E_Models shown in Listing 14-5, is attached as the error model for the system implementation basic.control. In addition, values for the property Occurrence are assigned to error events within the error model.
Listing 14-6. Example Annex Subclause Declarations
system implementation basic.control
subcomponents
A: system sensors.speed;
B: system controller.speed;
annex Error_Model {**
model => E_Models::Three_State;
Occurrence => poisson 10E-3 applies to Fail_Stop;
Occurrence => fixed 10E-4 applies to Fail_Active;
**};
end basic.control;