![]() ![]() |
||||
|
||||
This section provides an informative overview of AADL
concepts, structure, and use. In this section
the first appearance of a term that has a specific meaning in this standard will be italicized.
An AADL specification consists of AADL global
declarations and AADL declarations. The AADL
global declarations are comprised of package specifications and property set declarations.
AADL
declarations include component types, component implementations, port group types,
and annex
libraries. AADL component type and implementation declarations model kinds of physical system
components, such as a kind of hardware processor or a software program. This standard defines
the following categories of components: data, subprogram, thread, thread group, process, memory,
bus, processor, device, and system. They form the core of the AADL
modeling vocabulary.
A component type specifies a functional interface in
terms of features, flow specifications, and
properties. It represents a specification of the component against which other components
can
operate. Implementations of the component are required to satisfy this specification.
A component implementation specifies an internal structure
in terms of subcomponents,
connections between the features of those subcomponents, flows across a sequence of
subcomponents, modes to represent operational states, and properties. Unlike many
other
languages, the AADL allows multiple implementations to be declared with the same functional
interface.
Packages provide a library-like structure for organizing
component type and component
implementation declarations into separate namespaces and combining them into a system
specification.
Components may be hierarchically decomposed into collections
or assemblies of interacting
subcomponents. A subcomponent declares a component that is contained in another component,
naming a component type and component implementation to specify an interface and
implementation for the subcomponent. Thus, component types and implementations act as
component classifiers. The hierarchy of a system instance is based upon the set of
subcomponents of the top-level system implementation. It is completed by iteratively traversing the
tree of the component classifiers specified starting at the top-level system implementation
subcomponents.
A feature describes a functional interface of a component
through which control and data may be
exchanged with other components. Features can be ports to support directional flow of control
and
data, subprograms to represent synchronous procedure calls, and requires and provides access
to
subcomponents to represent shared access to data and bus components. Required
subcomponent access specifies the need for a component to access components declared outside
the component. Provided subcomponent access specifies that a subcomponent contained in a
component is made externally accessible. Ports in an AADL specification may map to a variable
in a piece of source code, i.e., a storage location in a physical memory.
Subcomponents allow systems to be specified as a static
and tree-like containment hierarchy. The
AADL also allows components to reference subcomponents that are not contained exclusively in
the component. This allows a component to be accessed or used in more than one component. In
the AADL, data and bus components can have shared access. For example, static data items
contained in a source text software package and represented in AADL as data components may
be used by threads in different processes (whose protected address spaces may otherwise be
distinct).
Syntactically the terms component type declaration, component
implementation declaration, and
subcomponent declaration refer to specific grammar rules for each component category.
Semantically, a component may have subcomponents while it itself is a subcomponent of some
other component. The terms component and subcomponent must be interpreted semantically as a
relationship between two components that are identified by context.
Components, features, modes, connections, flows, and
subprogram calls can have properties. A
property has a name, a type and a value. Properties are used to represent attributes and other
characteristics, such as the period and deadline of threads. When properties are associated with
declarations of component types, component implementations, features, subcomponents,
connections, flows, and modes, they apply to all respective instances within a system instance.
The AADL also supports the specification of instance specific values of any unit in the containment
hierarchy of a system instance. AADL tools may record these values for use in the analysis of
the
system instance or for use in the construction of new system instances. Properties can have
mode-specific and binding-specific values.
This standard defines a set of predeclared properties
and property types. Additional properties and
property types to support new forms of system analysis can be introduced through property sets.
Property values can be associated with component types, component implementations,
subcomponents, features, connections, flows, modes, and subprogram calls. For example, a
property is used to identify the source code files associated with a software component. Another
example of the use of properties is specifying hardware memory, i.e., the number of addressable
storage units and their size.
AADL component type and component implementation declarations
can be organized into
packages. Each package provides a separate namespace for component type and implementation
declarations. A component classifier in a package is referenced externally be qualifiing
its name
with the package name. Packages can be nested and referenced externally utilizing qualified
names.
Features and flow specifications of component types may
be partially specified. Similarly,
subcomponents, connections, flows, and modes of component implementations may have
incomplete specifications. These specifications may be later refined in component type and
component implementation extensions with the completion of classifier references and property
associations. Component type extensions can also introduce additional features, flow
specifications, and properties. Such extensions can add new subcomponents, connections, flows,
modes, and properties to component implementations.
A system modeled in AADL consists of application software
mapped to an execution platform.
Data, subprograms, threads, thread groups, and processes collectively represent application
software. They are called software components. Processor, memory, bus, and device collectively
represent the execution platform. They are called execution platform components. Execution
platform components support the execution of threads, the storage of data and code, and the
communication between threads. Systems are called compositional components. They permit
software and execution platform components to be organized into hierarchical structures with well-
defined interfaces. Operating systems may be represented through properties of the execution
platform or, requiring significantly more detail, modeled as software components.
Software components model source text, virtual address
spaces, and units of concurrent
execution. Source text can be written in a programming language such as Ada 95, C, or Java,
or
domain-specific modeling languages such as Simulink, SDL, ESTEREL, LUSTRE, and UML, for
which executable code may be generated. The source text modeled by a software component
may represent a partial application program or model (e.g., they form one or more independent
compilation units as defined by the applicable programming language standard). Rules and
permissions governing the mapping between AADL specification and source text depend on the
applicable programming or modeling language standard. Predeclared component properties
identify the source text container and the mapping of AADL concepts to source text declarations
and statements. These properties also specify memory and execution times requirements and
other known characteristics of the component.
AADL data components represent static data in source
text. This data can be shared by threads
and processes; they do so by the indicating that they require access to the external data
component. Concurrent access to data is managed by the appropriate concurrency control
protocol as specified by a property. Realizations of such protocols are documented in an
appropriate implementation Annex in this standard.
Data types in the source text are modeled by the declarations:
data component type and data
component implementation. Thus, a data component classifier represents the data type of data
components, ports, and subprogram parameters.
The subprogram component models source text that is executed
sequentially. Subprograms are
callable from within threads and subprograms. Subprograms may require access to data
components.
AADL thread components model units of concurrent execution,
i.e., concurrent runtime threads of
control or threads of execution through source text (or more exactly, through binary images
produced from the compilation, linking and loading of source text). A scheduler manages the
execution of a thread. The dynamic semantics for a thread are defined in this standard using
hybrid automata. The threads can be in states such as suspended, ready, and running. State
transitions occur as a result of dispatch requests, faults, and runtime service calls. They can
also
occur if time constraints are exceeded. Error detection and recovery semantics are specified.
Dispatch semantics are given for standard dispatch protocols such as periodic, sporadic, and
aperiodic threads as well as background threads. Additional dispatch protocols may be defined.
Threads can contain subprogram and data components, and provide or require access to data
components.
AADL thread groups support structural grouping of threads
within a process. A thread group may
contain data, thread, and thread group subcomponents. A thread group may require and provide
access to data components.
AADL process components model space partitions in terms
of virtual address spaces containing
source text that forms complete programs as defined in the applicable programming language
standard. Access protection of the virtual address space is enforced at runtime if specified by
the
property Runtime_Protection.
The binary image produced by compiling and linking this source
text must execute properly when loaded into a unique virtual address space. As processes do not
represent units of concurrent execution, they must contain at least one thread. Processes can
contain thread groups, threads, and data components, and can access or share data components.
Execution platform components represent hardware and
software that is capable of scheduling
threads, of enforcing specified address space protection at runtime, of storing source text code and
data, of interfacing with an external environment, and of performing communication for application
system connections.
AADL processor components are an abstraction of hardware
and software that is responsible for
scheduling and executing threads. In other words, a processor may include functionality provided
by operating systems. Alternatively, operating systems can be modeled like application
components. Processors can contain memory and require access to buses. Processors can
support different scheduling protocols. Threads are bound to processors for scheduling and
execution.
AADL memory components model randomly accessible physical
storage such as RAM or ROM.
Memories have properties such as the number and size of addressable storage locations. Binary
images of source text are bound to memory. Memory can contain nested memory components.
Memory components require access to buses.
AADL bus components model communication channels that
can exchange control and data
between processors, memories, and devices. A bus is typically hardware that supports specific
communication protocols, possibly implemented through software. Processors, memories, and
devices communicate by accessing a shared bus. Buses can be directly connected to other
buses. Logical connections between threads that are bound to different processors transmit their
information across buses that provide the physical connection between the processors. Buses can
require access to other buses.
AADL device components model physical devices that interface
with an external environment, e.g.
sensors and actuators providing an interface between a physical plant and a control system or a
GPS system. They may exhibit complex behaviors. Devices are logically connected to application
software components and physically connected to processors. They cannot store nor execute
application software source text themselves, but may include driver software executed on a
connected processor. A device requires access to buses.
AADL systems model hierarchical compositions of software
and execution platform components. A
system may contain data, thread, thread group, process, memory, processor, bus, device, and
system subcomponents. A system may require and provide access to data and bus components.
AADL modes represent the operational states of software,
execution platform, and compositional
components in the modeled physical system. A component can have mode- specific property
values. A component can also have mode- specific configurations of different subsets of
subcomponents and connections. In other words, a mode change can change the set of active
components and connections. Mode transitions model dynamic operational behavior that
represents switching between configurations and changes in component-internal characteristics,
such as conditional execution source text sequences or operational states of a device, that are
reflected in property values. Other examples of mode-specific property values include the period or
the worst-case execution time of a thread. A change in operating mode can have the effect of
activating and deactivating threads for execution and changing the pattern of connections between
threads. A mode subclause in a component implementation specifies the mode states and mode
change behavior in terms of transitions; it specifies the events as transition triggers. Subcomponent
and connection declarations as well as property associations declare their applicability
(participation) in specific modes.
This standard defines several categories of features:
data port, event port, event data port, port
group, data subprogram, server subprogram, and subprogram parameter, and provided and
required subcomponent access. Data ports represent connection points for transfer of state data
such as sensor data. Event ports represent connection points for transfer of control through raised
events that can trigger thread dispatch or mode transition. Event data ports represent connection
points for transfer of events with data, i.e., messages that may be queued. Ports groups support
grouping of ports, such that they can be connected to other components through a single
connection. Data subprograms represent entrypoints to code sequences in source text that are
associated with a data type. Server subprograms represent connection points for synchronous
call/returns between threads; in some instances the call/return may be remote. Subprogram
parameters represent in and out parameters of a subprogram. Data component access represents
provided and required access to shared data. Bus component access represents provided and
required access to buses for processors, memory, and devices.
AADL connections specify patterns of control and data
flow between individual components at
runtime. A semantic connection can be made between two threads, between a thread and a
device or processor, or between a thread, device, or processor and a mode transition. A mode
transition is represented by a set of one or more connection declarations that follow the component
hierarchy from the ultimate connection source to the ultimate connection destination. For
example, in Figure 1 there is a connection declaration from a thread out port in Thread1 to a
containing process out port in Process3. This connection is continued with a connection
declaration within System1 from Process3s out port to Process4s in port. The connection
declaration continues within Process4 to the thread in port contained in Thread2. Collectively, this
sequence of connections defines a single semantic connection between Thread1 and Thread2.
Threads, processes, systems, and ports are shown in graphical AADL notation. For a full
description of the graphical AADL notation see Annex A.
![]() Figure 1 Example Semantic Connections
Flow specifications describe externally observable flow
of information in terms of application logic
through a component. Such logical flows may be realized through ports and connections of different
data types and a combination of data, event, and event data ports. Flow specifications represent
flow sources, i.e., flows originating from within a component, flow sinks, i.e., flows
ending within a
component, and flow paths, i.e., flows through a component from its incoming ports to its outgoing
ports.
Flows describe actual flow sequences through components
and sets of components across one or
more connections. They are declared in component implementations. Flow sequences take two
forms: flow implementation and end-to- end flow. A flow implementation describes
how a flow
specification of a component is realized in its component implementation. An end-to-end flow
specifies a flow that starts within one subcomponent and ends within another subcomponent. Flow
specifications, flow implementations, and end-to-end flows can have expected and actual values for
flow related properties, e.g., latency or rounding error accumulation.
A physical system is modeled by instantiating a system
implementation that consists of
subcomponents representing the application software and execution platform components used to
execute the application, including devices that interface with the external environment. A system
instance represents the complete component hierarchy as specified by the system classifiers
subcomponents and the subcomponents of their component classifiers down to the lowest level
defined in the architecture specification.
An AADL specification may be used in a variety of ways
by a variety of tools during a broad range
of life- cycle activities, e.g. for documentation during preliminary specification, for schedulability
or
reliability analysis during design studies and during verification, for generation of system integration
code during implementation. Note that application software components must be bound to
execution platform components - ultimately threads to processors and binary images to memory in
order for the system to be analyzable for runtime properties and the physical system to be
constructed from the AADL specification. Many uses of an AADL specification need not be fully
automated, e.g. some implementation steps may be performed by hand.
The AADL core language is extensible through property
sets, annex subclauses and annex
libraries. Annex subclauses consist of annex-specific sublanguages whose constructs can be
added to component types and component implementations. Annex libraries are declarations of
reusable annex-specific sublanguage elements that can be referenced in annex subclauses.
This section provides an informative overview of AADL
concepts, structure, and use. In this section
the first appearance of a term that has a specific meaning in this standard will be italicized.
An AADL specification consists of AADL global
declarations and AADL declarations. The AADL
global declarations are comprised of package specifications and property set declarations.
AADL
declarations include component types, component implementations, port group types,
and annex
libraries. AADL component type and implementation declarations model kinds of physical system
components, such as a kind of hardware processor or a software program. This standard defines
the following categories of components: data, subprogram, thread, thread group, process, memory,
bus, processor, device, and system. They form the core of the AADL
modeling vocabulary.
A component type specifies a functional interface in
terms of features, flow specifications, and
properties. It represents a specification of the component against which other components
can
operate. Implementations of the component are required to satisfy this specification.
A component implementation specifies an internal structure
in terms of subcomponents,
connections between the features of those subcomponents, flows across a sequence of
subcomponents, modes to represent operational states, and properties. Unlike many
other
languages, the AADL allows multiple implementations to be declared with the same functional
interface.
Packages provide a library-like structure for organizing
component type and component
implementation declarations into separate namespaces and combining them into a system
specification.
Components may be hierarchically decomposed into collections
or assemblies of interacting
subcomponents. A subcomponent declares a component that is contained in another component,
naming a component type and component implementation to specify an interface and
implementation for the subcomponent. Thus, component types and implementations act as
component classifiers. The hierarchy
of a system instance is based upon the set of subcomponents of
the top-level system implementation. It is completed by iteratively traversing the tree of the component
classifiers specified starting at the top-level system implementation subcomponents.
A feature describes a functional interface of a component
through which control and data may be
exchanged with other components. Features can be ports to support directional flow of control
and
data, subprograms to represent synchronous procedure calls, and requires and provides access
to
subcomponents to represent shared access to data and bus components. Required
subcomponent access specifies the need for a component to access components declared outside
the component. Provided subcomponent access specifies that a subcomponent contained in a
component is made externally accessible. Ports in an AADL specification may map to a variable
in a piece of source code, i.e., a storage location in a physical memory.
Subcomponents allow systems to be specified as a static
and tree-like containment hierarchy. The
AADL also allows components to reference subcomponents that are not contained exclusively in
the component. This allows a component to be accessed or used in more than one component. In
the AADL, data and bus components can have shared access. For example, static data items
contained in a source text software package and represented in AADL as data components may
be used by threads in different processes (whose protected address spaces may otherwise be
distinct).
Syntactically the terms component type declaration, component
implementation declaration, and
subcomponent declaration refer to specific grammar rules for each component category.
Semantically, a component may have subcomponents while it itself is a subcomponent of some
other component. The terms component and subcomponent must be interpreted semantically as a
relationship between two components that are identified by context.
Components, features, modes, connections, flows, and
subprogram calls can have properties. A
property has a name, a type and a value. Properties are used to represent attributes and other
characteristics, such as the period and deadline of threads. When properties are associated with
declarations of component types, component implementations, features, subcomponents,
connections, flows, and modes, they apply to all respective instances within a system instance.
The AADL also supports the specification of instance specific values of any unit in the containment
hierarchy of a system instance. AADL tools may record these values for use in the analysis of
the
system instance or for use in the construction of new system instances. Properties can have
mode-specific and binding-specific values.
This standard defines a set of predeclared properties
and property types. Additional properties and
property types to support new forms of system analysis can be introduced through property sets.
Property values can be associated with component types, component implementations,
subcomponents, features, connections, flows, modes, and subprogram calls. For example, a
property is used to identify the source code files associated with a software component. Another
example of the use of properties is specifying hardware memory, i.e., the number of addressable
storage units and their size.
AADL component type and component implementation declarations
can be organized into
packages. Each package provides a separate namespace for component type and implementation
declarations. A component classifier in a package is referenced externally be qualifiing
its name
with the package name. Packages can be nested and referenced externally utilizing qualified
names.
Features and flow specifications of component types may
be partially specified. Similarly,
subcomponents, connections, flows, and modes of component implementations may have
incomplete specifications. These specifications may be later refined in component type and
component implementation extensions with the completion of classifier references and property
associations. Component type extensions can also introduce additional features, flow
specifications, and properties. Such extensions can add new subcomponents, connections, flows,
modes, and properties to component implementations.
A system modeled in AADL consists of application software
mapped to an execution platform.
Data, subprograms, threads, thread groups, and processes collectively represent application
software. They are called software components. Processor, memory, bus, and device collectively
represent the execution platform. They are called execution platform components. Execution
platform components support the execution of threads, the storage of data and code, and the
communication between threads. Systems are called compositional components. They permit
software and execution platform components to be organized into hierarchical structures with well-
defined interfaces. Operating systems may be represented through properties of the execution
platform or, requiring significantly more detail, modeled as software components.
Software components model source text, virtual address
spaces, and units of concurrent
execution. Source text can be written in a programming language such as Ada 95, C, or Java,
or
domain-specific modeling languages such as Simulink, SDL, ESTEREL, LUSTRE, and UML, for
which executable code may be generated. The source text modeled by a software component
may represent a partial application program or model (e.g., they form one or more independent
compilation units as defined by the applicable programming language standard). Rules and
permissions governing the mapping between AADL specification and source text depend on the
applicable programming or modeling language standard. Predeclared component properties
identify the source text container and the mapping of AADL concepts to source text declarations
and statements. These properties also specify memory and execution times requirements and
other known characteristics of the component.
AADL data components represent static data in source
text. This data can be shared by threads
and processes; they do so by the indicating that they require access to the external data
component. Concurrent access to data is managed by the appropriate concurrency control
protocol as specified by a property. Realizations of such protocols are documented in an
appropriate implementation Annex in this standard.
Data types in the source text are modeled by the declarations:
data component type and data
component implementation. Thus, a data component classifier represents the data type of data
components, ports, and subprogram parameters.
The subprogram component models source text that is executed
sequentially. Subprograms are
callable from within threads and subprograms. Subprograms may require access to data
components.
AADL thread components model units of concurrent execution,
i.e., concurrent runtime threads of
control or threads of execution through source text (or more exactly, through binary images
produced from the compilation, linking and loading of source text). A scheduler manages the
execution of a thread. The dynamic semantics for a thread are defined in this standard using
hybrid automata. The threads can be in states such as suspended, ready, and running. State
transitions occur as a result of dispatch requests, faults, and runtime service calls. They can
also
occur if time constraints are exceeded. Error detection and recovery semantics are specified.
Dispatch semantics are given for standard dispatch protocols such as periodic, sporadic, and
aperiodic threads as well as background threads. Additional dispatch protocols may be defined.
Threads can contain subprogram and data components, and provide or require access to data
components.
AADL thread groups support structural grouping of threads
within a process. A thread group may
contain data, thread, and thread group subcomponents. A thread group may require and provide
access to data components.
AADL process components model space partitions in terms
of virtual address spaces containing
source text that forms complete programs as defined in the applicable programming language
standard. Access protection of the virtual address space is enforced at runtime if specified by
the
property Runtime_Protection.
The binary image produced by compiling and linking this source
text must execute properly when loaded into a unique virtual address space. As processes do not
represent units of concurrent execution, they must contain at least one thread. Processes can
contain thread groups, threads, and data components, and can access or share data components.
Execution platform components represent hardware and
software that is capable of scheduling
threads, of enforcing specified address space protection at runtime, of storing source text code and
data, of interfacing with an external environment, and of performing communication for application
system connections.
AADL processor components are an abstraction of hardware
and software that is responsible for
scheduling and executing threads. In other words, a processor may include functionality provided
by operating systems. Alternatively, operating systems can be modeled like application
components. Processors can contain memory and require access to buses. Processors can
support different scheduling protocols. Threads are bound to processors for scheduling and
execution.
AADL memory components model randomly accessible physical
storage such as RAM or ROM.
Memories have properties such as the number and size of addressable storage locations. Binary
images of source text are bound to memory. Memory can contain nested memory components.
Memory components require access to buses.
AADL bus components model communication channels that
can exchange control and data
between processors, memories, and devices. A bus is typically hardware that supports specific
communication protocols, possibly implemented through software. Processors, memories, and
devices communicate by accessing a shared bus. Buses can be directly connected to other
buses. Logical connections between threads that are bound to different processors transmit their
information across buses that provide the physical connection between the processors. Buses can
require access to other buses.
AADL device components model physical devices that interface
with an external environment, e.g.
sensors and actuators providing an interface between a physical plant and a control system or a
GPS system. They may exhibit complex behaviors. Devices are logically connected to application
software components and physically connected to processors. They cannot store nor execute
application software source text themselves, but may include driver software executed on a
connected processor. A device requires access to buses.
AADL systems model hierarchical compositions of software
and execution platform components. A
system may contain data, thread, thread group, process, memory, processor, bus, device, and
system subcomponents. A system may require and provide access to data and bus components.
AADL modes represent the operational states of software,
execution platform, and compositional
components in the modeled physical system. A component can have mode- specific property
values. A component can also have mode- specific configurations of different subsets of
subcomponents and connections. In other words, a mode change can change the set of active
components and connections. Mode transitions model dynamic operational behavior that
represents switching between configurations and changes in component-internal characteristics,
such as conditional execution source text sequences or operational states of a device, that are
reflected in property values. Other examples of mode-specific property values include the period or
the worst-case execution time of a thread. A change in operating mode can have the effect of
activating and deactivating threads for execution and changing the pattern of connections between
threads. A mode subclause in a component implementation specifies the mode states and mode
change behavior in terms of transitions; it specifies the events as transition triggers. Subcomponent
and connection declarations as well as property associations declare their applicability
(participation) in specific modes.
This standard defines several categories of features:
data port, event port, event data port, port
group, data subprogram, server subprogram, and subprogram parameter, and provided and
required subcomponent access. Data ports represent connection points for transfer of state data
such as sensor data. Event ports represent connection points for transfer of control through raised
events that can trigger thread dispatch or mode transition. Event data ports represent connection
points for transfer of events with data, i.e., messages that may be queued. Ports groups support
grouping of ports, such that they can be connected to other components through a single
connection. Data subprograms represent entrypoints to code sequences in source text that are
associated with a data type. Server subprograms represent connection points for synchronous
call/returns between threads; in some instances the call/return may be remote. Subprogram
parameters represent in and out parameters of a subprogram. Data component access represents
provided and required access to shared data. Bus component access represents provided and
required access to buses for processors, memory, and devices.
AADL connections specify patterns of control and data
flow between individual components at
runtime. A semantic connection can be made between two threads, between a thread and a
device or processor, or between a thread, device, or processor and a mode transition. A mode
transition is represented by a set of one or more connection declarations that follow the component
hierarchy from the ultimate connection source to the ultimate connection destination. For
example, in Figure 1 there is a connection declaration from a thread out port in Thread1 to a
containing process out port in Process3. This connection is continued with a connection
declaration within System1 from Process3s out port to Process4s in port. The connection
declaration continues within Process4 to the thread in port contained in Thread2. Collectively, this
sequence of connections defines a single semantic connection between Thread1 and Thread2.
Threads, processes, systems, and ports are
shown in graphical AADL notation. For a full
description of the graphical AADL notation see Annex B.
![]() Figure 1 Example Semantic Connections
Flow specifications describe externally observable flow
of information in terms of application logic
through a component. Such logical flows may be realized through ports and connections of different
data types and a combination of data, event, and event data ports. Flow specifications represent
flow sources, i.e., flows originating from within a component, flow sinks, i.e., flows
ending within a
component, and flow paths, i.e., flows through a component from its incoming ports to its outgoing
ports.
Flows describe actual flow sequences through
components and sets of components across one or
more connections. They are declared in component implementations.
Flow sequences take two
forms: flow implementation and end-to- end flow. A flow implementation describes
how a flow
specification of a component is realized in its component implementation. An end-to-end flow
specifies a flow that starts within one subcomponent and ends within another subcomponent. Flow
specifications, flow implementations, and end-to-end flows can have expected and actual values for
flow related properties, e.g., latency or rounding error accumulation.
A physical system is modeled by instantiating a system implementation that consists
of
subcomponents representing the application software and execution platform components used to
execute the application, including devices that interface with the external environment. A system
instance represents the complete component hierarchy as specified by the system classifier’s
subcomponents and the subcomponents of their component classifiers down to the lowest level
defined in the architecture specification.
An AADL specification may be used in a variety of ways
by a variety of tools during a broad range
of life- cycle activities, e.g. for documentation during preliminary specification, for schedulability
or
reliability analysis during design studies and during verification, for generation of system integration
code during implementation. Note that application software components must be bound to
execution platform components - ultimately threads to processors and binary images to memory in
order for the system to be analyzable for runtime properties and the physical system to be
constructed from the AADL specification. Many uses of an AADL specification need not be fully
automated, e.g. some implementation steps may be performed by hand.
The AADL core language is extensible through property
sets, annex subclauses and annex
libraries. Annex subclauses consist of annex-specific sublanguages whose constructs can be
added to component types and component implementations. Annex libraries are declarations of
reusable annex-specific sublanguage elements that can be referenced in annex subclauses. |
||||