Chapter 6. Software Components
The AADL application software categories are summarized in Table 6-1. These categories are used to represent the task architecture of the application in terms of processes, thread groups, and threads. They also represent the application software artifacts such as data types, static and local data in terms of a data component, and executable code such as functions and procedures, and source code libraries, in terms of subprograms and subprogram groups.
Table 6-1. Application Software Components
In addition to the runtime semantics of each category, specific runtime and non-runtime characteristics of application software components are captured in values assigned to properties of those components. For example, information relating to the source code, code descriptions, executable code, and intermediate representations (e.g., object files) are identified by values assigned to the Source_Text property for the component and the execution time associated with a thread is defined by the value of the Compute_Execution_Time property.
Each software component is summarized in a separate section, where sample declarations are provided. Many of these are minimal. For example, some type declarations do not include any sections and some subcomponent declarations do not include classifier references. This simplicity is intended to provide a focus on the component and, while minimal and not sufficient to describe a realistic architecture, these declarations can be included within a specification as presented. This demonstrates the flexibility of the language in allowing syntactically correct partial specifications.
6.1. Thread
A thread represents an execution path through code that can execute concurrently with other threads. It is a schedulable unit that is assigned (bound) to a processor for execution. The processor schedules the thread and executes the code associated with the thread. The code of a thread executes within the address space defined by the process (see Section 6.3) that contains the thread. You can bind a thread to a virtual processor, which may represent a partition or a particular scheduler, and the thread will execute on the physical processor to which the virtual processor is bound. An AADL thread may be implemented through an operating system thread, or multiple AADL threads may be mapped as logical threads into a single operating system thread (e.g., threads that execute at the same rate). A thread may represent an active object.
A thread can be dispatched repeatedly at fixed time intervals as specified by the Period property, referred to as period-based dispatches, or it can be dispatched due to the arrival of data or events on one of the thread’s event data or event ports, referred to as port-triggered dispatches. In the latter case, a thread is dispatched immediately upon arrival of a message or event when idle, or it is redispatched once the current execution completes.
The value of the Dispatch_Protocol property defines the dispatch characteristics of a thread. The standard dispatch protocol values that have defined semantics are periodic, aperiodic, sporadic, timed, hybrid, and background.
• Periodic threads have a period-based dispatch (a repeated, fixed time interval dispatch) with the assumption that the previous execution has completed before the next dispatch.
• Aperiodic threads have a port-based dispatch, which may be queued if the thread is still executing the previous dispatch.
• Sporadic threads have a port-triggered dispatch with the additional constraint that the dispatch is delayed if the previous dispatch has occurred in a time less than the time specified by the thread period.
• Timed threads are dispatched after a given time specified by the Period property unless they are dispatched by arrival of an event or even data, effectively providing a time-out if no input arrives for a given time interval since the last dispatch.
• Hybrid threads are dispatched by an event or event data arrival as well as periodically. For periodic, timed, and hybrid threads, a value of the Period property for the thread must be declared.
• Background threads are dispatched once and execute until completion. In addition to the standard protocols, you can introduce project specific dispatch protocols by modifying the enumeration type Supported_Dispatch_Protocols that is found in the AADL_Project property set.
Regardless of their dispatch protocol, threads have well-defined runtime states that are built into their execution semantics. The actions for threads are
• Initialize for initializing the thread
• Compute for nominal execution
• Recover for recovering from a fault
• Activate to restore thread state on a mode switch where the thread becomes active (executable as part of a given mode)
• Deactivate to save thread state on a mode switch where the thread is inactive (not executable as part of a mode)
• Finalize for cleanup actions
For each of the thread actions you can specify the application code to be executed using entry point properties. You can specify a reference to source text, name a subprogram classifier, or reference a call sequence to be executed. Details of these properties can be found in Table A-9.
Threads also have a set of runtime states in which they are not performing actions. They are
• Suspended-D when a thread is active in the current mode and ready to be dispatched
• Suspended-M when a thread is inactive in the current mode and not dispatchable
• Suspended-P when the thread execution is preempted by a higher priority thread
• Suspended-B when the thread is blocked waiting for a resource locked by another thread
• Halted when the thread is stopped and requires initialization before being able to execute
6.1.1. Representation
Table 6-2 shows the graphical and associated textual representations for a thread type and implementation. Two ports have been included for sensor input sensor_data and command output cmd for the thread.
Table 6-2. A Sample Thread Implementation with One Subcomponent
You can declare a data subcomponent within the thread implementation to represent the internal state of a thread. This state persists between dispatches of the thread and is only accessed by the thread.
You can also indicate that the thread accesses a shared data component from outside the thread by declaring a requires data access feature. In this case, the data component is shared and may require concurrency control (see Section 10.2).
You can express the fact that a thread services remote procedure calls by declaring a provides subprogram access feature for the thread.
6.1.2. Properties
The AADL standard provides a variety of thread-related properties in predeclared property sets (see Section 13.2). They include thread properties such as Dispatch_Protocol for indicating the type of thread dispatch, Dispatch_Trigger to identify a subset of ports that can cause a dispatch, Priority and Criticality to indicate the importance of executing a thread over other threads, and properties related to handling of threads in a mode transition. Timing-related properties for threads include thread Period, thread Deadline and deadlines for thread initialization and finalization, normal execution, error recovery, and activation and deactivation during a mode transition, as well as best-case and worst-case execution time as a time range value. Deployment related properties provide processor binding to map threads to the processor or partition within a processor to execute on. Finally, we have properties related to memory usage such as Source_Code_Size and Source_Data_Size, as well as properties that identify pieces of source code to be executed by the thread during various stages of its lifetime. For example, the Initialize_Entrypoint property identifies the subprogram in the source code for a thread that will execute to initialize the thread.
Listing 6-1 includes sample property associations for a thread type controller where entry points and associated execution times are declared for initialization and nominal executions of the thread. For example, the Dispatch_Protocol property value specifies that the thread type controller is Periodic. Its period is 50 milliseconds, as declared with the Period property. Similarly, the execution time for the thread is a range of 5 milliseconds to 10 milliseconds, as declared with the Compute_Execution_Time property. The property association for the property Allowed_Processor_Binding_Class declares that instances of the type controller can be bound to any instance of the processor type marine_certified.
Listing 6-1. Sample Thread Properties
thread controller
properties
-- nominal execution properties
Compute_Entrypoint => "control_ep";
Compute_Execution_Time => 5 ms .. 10 ms;
Compute_Deadline => 20 ms;
Dispatch_Protocol => Periodic;
Period => 50 ms;
-- initialization execution properties
Initialize_Entrypoint => "init_control";
Initialize_Execution_Time => 2 ms .. 5 ms;
Initialize_Deadline => 10 ms;
-- binding properties
Allowed_Processor_Binding_Class => (classifier(marine_certified));
end controller;
6.1.3. Constraints
Table 6-3 summarizes the component type and implementation declarations that may be contained within a thread type or implementation declaration and identifies the components that may contain a thread. A thread must reside within a process, either as a subcomponent of a process or as a subcomponent of a thread group contained in a process. The thread or the process containing the thread must be bound to memory that is accessible by the processor that executes the code of the thread (i.e., the processor to which the thread is bound).
Table 6-3. Summary of Constraints on Thread Classifier Declarations
A thread communicates with other threads or devices through ports, through access to data components shared across multiple threads, and through calls to subprograms serviced by other threads or devices. In addition, a thread may make local calls to subprograms and have persistent local state expressed by data subcomponents. An instance of the subprogram being called may be explicitly modeled as a subcomponent and accessed via a subprogram access connection through the requires subprogram access feature.
6.2. Thread Group
Threads within a process can be organized into a hierarchy of thread groups. This may be desirable if you have a number of threads within a process. Threads within a thread group interact with other threads through the interface of their enclosing thread group. Thread groups can contain data subcomponents that may be shared between threads within the thread group and outside the thread group. Similarly, a thread group may contain subprogram and subprogram group subcomponents that may be called by threads as local calls.
6.2.1. Representations
Table 6-4 is a sample textual specification for a thread group type and implementation declaration. This thread group represents the software controlling the speed of a powerboat. At this time, only the subcomponent declarations of the control.speed component implementation are shown (e.g., connections are not included). In this representation, the control algorithms are placed into a thread group separate from a data_scaling thread that supports scaling of data and other data management.
Table 6-4. A Sample Thread Group Specification
The data subcomponent control_data represents a persistent data store for control data (e.g., control settings). As a distinct subcomponent, it is explicitly identified as a common store for the control thread group—that is, the control data is intended to be accessed by threads within the control_algorithms thread group and by the data_scaling thread. You must add requires data access features and connections to the thread group and the thread to record this data sharing.
The thread group type declaration control includes a property association that defines a Period of 50ms. This period applies to all of the periodic threads contained in the thread group, unless specifically overridden by a property association for a particular thread.
6.2.2. Properties
Properties that you declare in thread groups are typically properties that are inherited by the threads contained in a thread group, such as the period or processor binding constraints, if they do not have the appropriate property value. In other words, these property values act as default values for the subcomponents if the property is defined as inherit.
6.2.3. Constraints
Table 6-5 summarizes the legal elements within a thread group’s type and implementation declarations as well as the components that may contain a thread group. A thread group must be contained in a process, either directly or indirectly by being contained in another thread group. A thread group can contain persistent state in the form of static data, expressed by a data subcomponent. This data subcomponent may be accessible to threads and thread groups contained in the given thread group and it can be made accessible outside the thread group.
Table 6-5. Summary of Constraints on Thread Group Classifier Declarations
The features of the thread group type place a constraint on the interactions that subcomponents of the thread group can have. For example, a thread contained in a thread group can only interact with threads outside the thread group through the ports and data access features of the thread group. Similarly, threads in a thread group may make local calls to subprogram and subprogram group subcomponents in the enclosing thread group, process, or system or remote calls to provided subprogram features of another thread.
6.3. Process
An AADL process represents a protected address space that prevents other components from accessing anything inside the process and prevents threads inside a process from causing damage to other processes. In other words, it provides fault isolation for incorrect memory access faults. A process can represent the space partitioning aspect of partitioned architectures such as ARINC653. A process specification does not include an implicit thread; therefore, a complete process specification should contain at least one explicitly declared thread or thread group. This process may have source code associated that represents the executable code and data.
6.3.1. Representations
Table 6-6 contains a partial textual specification for a process and its corresponding graphical representations. The process is shown with examples of three of its allowed subcomponent categories:
1. Thread
2. Thread group
3. Data
Table 6-6. Example Representations of a Process
Two ports are shown, one as input and one as output for the process. Since processes represent protected address spaces and often are implemented as separate load images in operating systems, you will usually not provide or require access to data components through the process type—although it is syntactically allowed. Only the subcomponent declarations of the process implementation of controller.speed are shown explicitly. Other details of the specification are not included. These omissions are legal for a syntactically correct partial specification. This might be useful early in the development where you want to specify the parts your system is composed of without indicating yet how the parts interact with each other. To complete the specification, you add connections that define the interactions between subcomponents and with external components through the process ports.
The left portion of Table 6-6 shows a graphical representation for the textual specification on the right. The subcomponent structure of the process implementation controller.speed is shown within its implementation diagram, where individual subcomponents are represented as distinct icons (e.g., the thread icons for the subcomponents control_input and control_output).
6.3.2. Properties
Standard properties for processes include the specification of the runtime enforcement of memory protection, source code and binary file information, file loading times, and binding constraints. In addition, there are properties that are shared (inherited) by a process’s subcomponent threads (e.g., Period, Deadline, or Actual_Processor_Binding). If values are assigned to these properties via a property association within the process type or implementation, that value will be inherited by the subcomponents that share these properties unless overridden by those subcomponents or their classifiers.
6.3.3. Constraints
Table 6-7 summarizes the legal elements within process type and implementation declarations as well as the permitted components that may contain a process. Processes cannot be recursively contained in other processes, but must be contained in system components. Processes can have persistent state in the form of a data subcomponent. This data component can be shared between threads within the process by data access connections to those threads. Data subcomponents can be made accessible to other processes via provides data access features if the underlying operating system supports shared access to memory from multiple process address spaces.
Table 6-7. Summary of Constraints on Process Classifier Declarations
6.4. Data
You can declare data component types, data component implementations, and data subcomponents to represent data component instances. Data component types represent application data types. Data component implementations represent variants of an application data type and allow you to specify the internal structure of a data type (e.g., the fields of a record). Data component instances can take one of three forms. They can be declared as data subcomponents to represent data (e.g., a global data array with shared access or local data in a subprogram). Alternatively, they can be included in data or event data port declarations to specify the kind of data communicated through the port and accessible to the application source code in the form of a port variable or queue. Finally, they can be included as parameter declarations of subprograms. In all three cases, the type of the data is identified by referring to a data component type or to an implementation of that type.
6.4.1. Representations
Table 6-8 shows sample data type and implementation declarations with their corresponding graphical representations. There are three data types and a data implementation. The error_data.control component implementation has two data subcomponents to model elements of a data record. One is an instance of the communication error data type comm_error. The other is an instance of the processor error data type processor_error. As shown in this example, when declaring data subcomponents it is sufficient to include only a reference to a data type declaration (e.g., in the subcomponent declarations of the data implementation error_data.control).
Table 6-8. Sample Data Component Declarations
AADL support the declaration of provides subprogram features in data component types. Such a feature can be used to model a method associated with a data type or class in an object-oriented source language.
AADL supports the declaration of component arrays. When applied to data subcomponents we can model data arrays. In other words, AADL can be used as a data modeling language. However, this is not its primary role. You may already use an established data modeling language such as ASN.1 or UML. In this case, you want to map information from the data model that is relevant to the architecture into AADL data components. For that purpose the SAE AADL standards committee has developed a Data Modeling Annex Standard document [DAnnex] that defines a relevant set of properties and common basic data types.
We can declare data components with shared access by multiple threads. This data component can be shared within a process or across processes. We use a data access feature declarations to model access to such shared data components (see Section 10.2).
6.4.2. Properties
Among the standard properties for data components are those that enable the specification of source code for the data component, name of the relevant static data variable in the source code, data size, and any concurrency access protocol for shared data. For example, in Table 6-8, a size of 16 bits is assigned to the data components comm_error and processor_error using the Source_Data_Size property. This specifies the maximum size of the data represented by the data component. For shared data instances the property Concurrency_Control_Protocol defines the protocol for managing access to the shared data.
6.4.3. Constraints
Table 6-9 summarizes what data component type and data component implementation declarations can contain. It also summarizes the permitted components that may contain a data component. Notice that data components can be subcomponents, allowing the specification of data subfields. As subcomponents of a data implementation, provides subprogram accesses can be used to model methods on objects. A data component can be a subcomponent of a data component representing an element of a data record, of a thread, thread group, process, system, or abstract component representing persistent state in the form of static data, or of a subprogram representing local data.
Table 6-9. Summary of Constraints on Data Classifier Declarations
The constraints on references to data classifiers are shown in Table 6-10. Data classifiers can be referenced by features and by data subcomponent declarations. The reference can be to a data type or a data implementation. Data subcomponent declarations represent static data components whose access can be shared when placed in threads, thread groups, processes, or systems. They represent local data when placed in a subprogram.
Table 6-10. Summary of Data Classifier References
6.5. Subprogram
A subprogram represents a callable unit of sequentially executable code. Subprogram types define the signature of a subprogram. Subprograms can have parameters through which data values are passed with and returned from a subprogram call. Subprograms can have requires data access features to represent access to persistent state or model passing of parameters by reference. You use outgoing ports to model reporting of exceptions and errors.
Subprogram implementations represent the internals of a subprogram. You are not required to specify a subprogram implementation if there is no need to model the internals of a subprogram. Within a subprogram, data subcomponents represent local variables. We can also specify subprogram call sequences to other subprograms. These calls may be local (the called subprogram is executed in the same thread as that containing the call) or remote (the called subprogram is executed in a different thread than that containing the call).
Subprogram calls can be modeled in two ways. First, you can identify the subprogram to be called by referring to its subprogram classifier. In this case, the linker/loader will provide an instance of the subprogram as part of the execution image of the process. If the call is to be a remote procedure call to a subprogram in another thread, then the Actual_Subprogram_Call property is used to identify the thread and the appropriate subprogram access feature of that thread.
Second, a subprogram call can refer to an instance of a subprogram by naming subprogram subcomponents or subprogram access features. In this case, instances of subprograms are declared explicitly as subcomponents and made accessible via subprogram access features and access connections. These subprogram instances may be shared between threads and other components. Threads and other components indicate that they require access to a subprogram or provide access to a subprogram through provides and requires subprogram access features. This supports a component-based development approach, in which it is desirable to completely specify all dependencies to other components, including subprogram call dependencies.
Third, a call can identify a provides subprogram access feature of a data component type to represent method calls for operation on data. The data component being operated on by the method must be passed to the subprogram by value or by reference.
Fourth, a call can identify a requires subprogram access that is connected to a subprogram access feature of another thread to represent remote service/procedure calls.
Finally, a call can identify a provided subprogram access feature of the processor to which an application is bound by referring to the processor’s subprogram access feature, in the form processor.<subprogram_access_feature name>. This allows you to model service calls to operating system functions provided by the processor.
6.5.1. Representations
Table 6-11 includes example textual and graphical representations relating to the declaration of a subprogram that is a service (method) call for operation on data. It shows the subprogram type scale_data and the implementation declaration scale_data.sensor. The subcomponent scale_acc_data is an instance of scale_data.sensor within the data component accelerometer. The feature scale_data_access establishes the data component accelerometer provides access to an instance of the subprogram implementation scale_data.sensor. In this case, access is provided to the subcomponent scale_acc_data.
Table 6-11. Subprogram Representations
6.5.2. Properties
Standard subprogram properties include declarations relating to the source code for the subprogram such as the Source_Name, Source_Text, and Source_Language. Other properties address the memory size and binding such as Source_Code_Size, Source_Data_Size, Source_Stack_Size, Source_Heap_Size, Allowed_Memory_Binding_Class, and Allowed_Memory_Binding. In addition, there are properties relating to the calling and execution of the subprogram such as Actual_Subprogram_Call, Allowed_Subprogram_Call, Actual_Subprogram_Call_Binding, Allowed_Subprogram_Call_Binding, Subprogram_Call_Type, Compute_Execution_Time, and Compute_Deadline.
6.5.3. Constraints
Table 6-12 summarizes the permitted elements of a subprogram’s component type and implementation declarations. Subprograms can contain data subcomponents to represent local data. Subprograms cannot contain instances of other subprograms; these must be declared in threads, thread groups, processes, or systems and be made available through subprogram access features. Note that AADL does not require you to explicitly model subprogram instances. Instead, you can refer to subprogram classifiers in subprogram calls to identify the subprogram signature.
Table 6-12. Summary of Constraints on Subprogram Classifier Declarations
6.6. Subprogram Group
You can use subprogram groups to represent a collection of callable routines such as a subprogram library by declaring a subprogram group type with provides subprogram access features. Similar to subprograms, you can model software libraries by subprogram group types, leaving the job of determining the number of copies of the library to the linker/loader; or you can explicitly declare instances of such libraries through subprogram group subcomponent declarations. In subprogram calls you refer to the subprogram group type or to the subprogram group instance and then the provides subprogram access feature (e.g., filter_library.basic_acc).
6.6.1. Representations
Examples of subprogram group declarations and corresponding graphical representations are shown in Table 6-13. A subprogram group is represented graphically as an oval with a dashed border. The subprogram group type filter_library includes the provides subprogram access features: basic_acc, lowP_filter, and hiP_filter. The subprogram group implementation filter_library.BLH contains the subprogram instances: basic_filter, LowP_filter, and HiP_filter that correspond to the access features of the type filter_library. For example, the feature basic_acc provides access to an instance of the subprogram filter_library.BLH, which is the subcomponent basic_filter.
Table 6-13. Example Subprogram Group Declarations
6.6.2. Properties
The standard properties of subprogram groups are associated with the properties of subprograms. All subprogram properties that are declared as inherit can be declared within a subprogram group declaration. Those values declared in the subprogram group apply to all of the subprograms within the group unless that value is overridden by a property association elsewhere (e.g., within an individual subprogram instance).
6.6.3. Constraints
Table 6-14 summarizes the permitted elements of a subprogram group’s type and implementation declarations. You may indicate that a subprogram library uses another library by specifying a requires subprogram group access feature. You may choose to model the subprograms contained in a subprogram library by declaring them as subprogram subcomponents in the subprogram group implementation.
Table 6-14. Summary of Constraints on Subprogram Group Classifier Declarations
