3. Architecture Analysis & Design Language Summary
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 Process3’s out port to Process4’s 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.
graphic
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.
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 Process3’s out port to Process4’s 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.
graphic
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.