14  Layered System Architectures

(1)   Layering of system architectures is supported in AADL in several ways:

·         Hierarchical containment of components;

·         Layered use of threads for processing and services;

·         Layered virtual machine abstraction of the execution platform.

(2)   The hierarchical containment of components is the result of modeling a system as a component architecture and decomposing its capabilities hierarchically. This is supported by the abstract component category as well as the software components, the hardware components, and the system components. Interaction between components at different levels of the system hierarchy is managed and controlled by the component features.  Connections between the components must follow the component hierarchy.

(3)   Threads and devices represent active components in a system.  Threads and devices interact with other threads and devices through directional flow of events and data, representing a pipeline architecture pattern.  Threads also may call on services of other threads through subprogram service calls.  These thread services often are organized into service layers in that threads of one layer call on services of the same or lower layer, but not higher layers.  Multi-tiered e-business architectures are examples of this architecture pattern.  Threads and related components of different service layer can be organized into separate packages and access to packages can be restricted by convention to follow the layering hierarchy.  Packages or components such as threads can be attributed with a Service_Layer property that can be used by a design rule checker to enforce such layering.

(4)   Execution platform components virtual processor and virtual bus can represent virtual machine abstractions.  For example, a virtual processor may represent a language runtime system such as the Ada runtime system, which is responsible for scheduling the execution of Ada tasks. This runtime system may be implemented on top of another virtual processor, namely a real-time operating system.  Virtual processors and processors provide the runtime service calls described in Runtime Support in Section 5.4, and Section 8.3, as well as services declared explicitly as part of the features of a (virtual) processor type.  Similarly, a virtual bus may represent a protocol that is implemented in terms of a lower level protocol. 

(5)   AADL can be used to represent this system layering as follows: The implementation of an execution platform component can be described by system components.  For example, a processor that represents hardware and an operating system can be described by an application software system to represent the operating system and a lower level execution platform system that includes a lower-level processor abstraction.  Similarly, the internal implementation of a device, e.g., a digital camera, can be described as a system that consists of image processing and transfer software as well as processors, internal memory, and USB bus interface, and CCD sensors as devices.  A map data base may be a highly abstracted memory component type, whose implementation consists of database software and data components that represent the database content together with physical disks as lower-level memory components and a processor that acts as dedicated database server. 

(6)   System implementations can be associated with their respective processor, virtual processor, memory, bus, virtual bus, and device types and implementations through the Implemented_As property, which takes classifiers as its value. 

(7)   In the case of processors, virtual processors, and devices, these system implementations can be used as plug-replaceable patterns for the original platform components, when an instance model is created. The pattern is called plug-replaceable because the system component implementing the execution platform element implements the interface defined by the execution platform element type. 

(8)   In the case of a virtual bus or bus a connection bound to a bus or virtual bus is interpreted during model instantiation as rerouting the connection from its source to a source feature in the  system implementation of the bus or virtual bus, and a second connection from a predeclared destination feature to the destination of the original connection.  For example, the system implementation realizing a virtual bus may consist of a sender thread with a predeclared source port and a receiver thread with a predeclared destination port.  Alternatively, the connection can be mapped into Send_Output and Receive_Input service calls (see Runtime Support in Section 8.3) to reflect an API-based functional service architecture.

(9)   In the case of a memory component, read and write accesses to data components that are bound to a memory component can be mapped into read and write accesses to data components in the system implementation of the memory abstraction, or interpreted as retrieve and store service calls to the subprogram access features of the system component.