Appendix G Profiles and Extensions
Informative
(1) Profiling of the AADL standard is supported through project-specific changes to the predeclared AADL_Project property set and through project-specific constraints that are checked by tools.
(2) A project is allowed to add consistency rules to constrain the architecture that can be processed. Such constraints must be documented, including the motivation, rationale, implications. An example constraint is that a subclause, such as subcomponents, must be specified with none to indicate that no elements exist. Another example constraint is that all communication between processes must be through port connections. An AADL model that is constrained through such consistency rules is still considered to be a legal AADL model.
(3) The reasons for such constraints are to restrict the system to be modeled, e.g., High integrity systems, or specific architectures such as ARINC653, or to reflect inability to provide support for all possible execution semantics in the runtime system.
(4) A profile may also include extensions to AADL, such as additional properties that are defined in a property set. For example, support for the ARINC 653 architecture may include partition-specific properties and health monitoring specific properties.
(5) Profiles can be turned into a standardized set of guidelines, for example, the effort to define guidelines for modeling ARINC653 architectures in AADL.
(6) A minimal AADL core subset is defined to support the following restrictions:
(7) No modes, no user defined property sets, no runtime protection of virtual address spaces, single processor, no virtual processor, no virtual bus, queue depth 1, no remote subprogram calls, no sporadic, background, hybrid, timed threads.
Annex Document A Code Generation
This annex document is available as a separate document.
Annex Document B Data Modeling
This annex document is available as a separate document.
Normative
This annex document is available as a separate document.
Annex Document D Behavior Model
Normative
This annex document is available as a separate document.
Normative
This annex document will contain small sublanguage annex extensions. Candidates are: Data set support; Equivalence and Signature Matching rules, Configuration constraint support; Mode transition and dispatch trigger condition support.
(1) This annex is to provide support for defining sets of property associations and allowing them to be associated with a model. A data set is a named collection of contained property associations that all have a common root for their applies to paths. Such named data sets can be defined as elements of a DataSet annex library and can be referenced in DataSet annex subclauses.
(2) The purpose of this annex is to provide the ability to annotate elements of an AADL model with data that is expressed as property associations. For example, we can define a dataset that represents estimated execution time of threads and subprograms, a second dataset that represents benchmark execution time of threads and subprogram, and a third dataset that represents measured execution time of actual code. Different sets of information can be kept in separate datasets, e.g., security related information may be kept separate from timing information. Different datasets can be associated with the same model, e.g., various combinations of timing-related datasets and security-related datasets can be associated with the system implementation that represents the root of a system.
NOTE: Model-related data may already exist in a user-defined format. In that case the data does not have to be converted into an AADL property association representation. Instead the modeler can associate the name of a file that contains such data through a user-defined property.
Syntax
dataset_annex_library ::=
defining_dataset_identifier applies to unique_component_implementation_reference
properties
{ contained_property_association }+
end dataset_identifier ;
dataset_annex_subclause ::=
with unique_dataset_reference { , unique_dataset_reference }* ;
unique_dataset_reference ::= unique_package_name :: dataset_identifier
NOTE: The Unique_component_implementation_reference and contained_property_association syntax rules are those defined in the AADL core language standard.
Naming Rules
(N1) The defining identifier of a dataset must be unique within the same annex library declaration. In other words, an AADL package can contain only one data set annex library and each dataset annex library has its own name space.
(N2) The dataset reference must name a dataset that is defined in a dataset annex library. The dataset annex library is uniquely identified by the AADL package it is contained in.
(N3) The root of the applies to path of the contained property associations is the component implementation referenced in the applies to statement of the dataset definition.
Legality Rules
(L1) The dataset annex subclause must be declared as one of the annex subclauses of a component implementation extension of the component implementation identified as the root in the applies to of the dataset.