Modeling and Analysis with the AADL: The Basics
This chapter is from the book
This chapter is from the book
This chapter is from the book
While reading the first part of this chapter, you may want to use an AADL development tool to create the specifications and conduct the analyses described. OSATE supports all of the modeling and analyses discussed in this chapter.
3.1. Developing a Simple Model
In this section, we present a step-by-step development and analysis of an AADL model. Specifically, we model a control system that provides a single dimension of speed control and demonstrate some of the analyses that can be conducted on this architectural model. The speed control functionality is part of a powerboat autopilot (PBA) system that is detailed in Appendix A. While specialized to a powerboat, this model exemplifies the use of the AADL for similar control applications such as aeronautical, automotive, or land vehicle speed control systems.
The approach we use is introductory, demonstrating the use of some of the core elements and capabilities of the AADL. We do not include many of the broader engineering capabilities of the language. For example, we do not address packages, prototypes, or component extensions in developing this simple model. These are discussed later in this chapter. Instead, we proceed through the generation of a basic declarative model and its instance and show a scheduling analysis of the system instance. During your reading of this section, you may want to reference Part II for details on specific AADL elements or analyses used in the example.
Initially we create a high-level system representation using AADL system, process, and device components. Building on this initial representation, we detail the runtime composition of all of the elements; allocate software to hardware resources; and assign values to properties of elements to a level that is required for analysis and for the creation of an instance of the system. In these steps, we assume that requirements are sufficiently detailed to provide a sound basis for the architectural design decisions and trade-offs illustrated in the example. In addition, while we reference specific architectural development and design approaches that put the various steps into a broader context, we do not advocate one approach over another.
3.1.1. Defining Components for a Model
A first step is to define the components that comprise the system and place their specification in packages. The process of defining and capturing components is similar to identifying objects in an object-oriented methodology. It is important to realize that components may include abstract encapsulations of functionality as well as representations of tangible things in the system and its environment. The definition of components is generally an iterative and incremental process, in that the first set of components may not represent a complete set and some components may need to be modified, decomposed, or merged with others.
First, we review the description of the speed controller for the PBA and define a simplified speed control model. In this model, we include a pilot interface unit for input of relevant PBA information, a speed sensor that sends speed data to the PBA, the PBA controller, and a throttle actuator that responds to PBA commands.
For each of the components identified, we develop type definitions, specifically defining the component’s name, runtime category, and interfaces. Since we are initially developing a high-level (conceptual) model, we limit the component categories to system, process, and device.
The initial set of components is shown in Table 3-1, where both the AADL text and corresponding graphical representations are included. For this example, the textual specifications of all of the components required for the model are contained in a single package and no references to classifiers outside the package are required. Thus, a package name is not needed when referencing classifiers. For the graphical representations, the implementation relationship is shown explicitly. Note that the icon for an implementation has a bold border when compared to the border of its corresponding type icon.
Table 3-1. Component Type and Implementations for the Speed Control Example
)
The speed sensor, pilot interface, and throttle actuator are modeled as devices and the PBA control functions are represented as a process. We use the devices category for components that are interfaces to the external environment that we do not expect to decompose extensively (e.g., a device can only have a bus as a subcomponent).
Devices in AADL can represent abstractions of complex components that may contain an embedded processor and software. With a device component, you represent only those characteristics necessary for analysis and an unambiguous representation of a component. For example, in modeling a handheld GPS receiver, we may only be interested in the fact that position data is available at a communication port. The fact that the GPS receiver has an embedded processor, memory, touch screen user interface, and associated software is not required for analysis or modeling of the system. Alternatively, a device can represent relatively simple external components, such as a speed sensor, whose only output is a series of pulses whose frequency is proportional to the speed being sensed. If you require a complex interface to the external environment, you can use a system component. In this case, you can detail its composition and as needed include an uncomplicated device subcomponent to represent the interface to the environment.
The use of a process component for the control functions reflects the decision that the core control processing of the PBA is to be implemented in software. The software runtime components will be contained within an implementation of this process type. The implementation declarations in Table 3-1 do not include any details. As the design progresses, we will add to these declarations (i.e., adding subcomponents and properties as appropriate).
The interfaces for the PBA components are port features declared within a component type and are reflected in each implementation of that type. For example, the type sensor outputs a value of the speed via a data port sensor_data. The pilot interface type interface provides a value for the set speed via a data port set_speed and generates a signal to disengage the speed control via an event port disengage.
Notice that we have used explicit as well as abbreviated naming for the ports and other elements of the model (e.g., command_data and cmd for the command data at input and output ports). The specificity of names is up to you, provided they comply with AADL naming constraints for identifiers (e.g., the initial character cannot be a numeral). Note that naming is case insensitive and Control is the same name as control.
In the PBA example, we have chosen to assign specific runtime component categories to each of the components (e.g., the speed sensor is a device). However, in real-world development as a design matures, the definition of these components may change (e.g., a component that computes the PBA speed control laws may initially be represented as a system and later modified to a process or thread). Using the approach we outline here, these changes are done manually within the AADL model (i.e., changing a system declaration to a process category declaration). An alternative approach is to use the generic abstract component category (i.e., not defining a specific runtime essence). Then later in the development, converting this abstract category into a specific runtime category employing the AADL extends capability (e.g., converting an abstract component to a thread). We have chosen to use the former approach to simplify the presentation and focus on decisions and issues related to representations of the system as concrete runtime components. A discussion of the use of the abstract component category is provided in Section 3.5.
For each of the component types we define a single implementation. These declarations are partial, in that we omit substantial details needed for a complete specification of the architecture. For example, we do not define the type of data that is associated with the ports. We will address these omissions as required in later steps. However, we can conduct a number of analyses for our simple example without including many of these details.
3.1.2. Developing a Top-Level Model
In the next step, we integrate the individual component implementations into a system by declaring subcomponents instances and their connections. We do this by defining an enclosing system type and implementation as shown in Listing 3-1, where we define a system type Complete and its implementation Complete.PBA_speed_control. There is nothing special about our choice of naming for this enclosing system. Another naming scheme, such as a type of PBA and an implementation of PBA.speed, would work as well.
Within the implementation, we declare four subcomponents. The three device subcomponents represent the speed sensor, throttle, and the pilot interface unit. The process subcomponent speed_control represents the software that provides the speed control for the PBA. Notice that there are no external interfaces for the system type Complete. All of the interactions among the system’s subcomponents are internal to the implementation Complete.PBA_speed_control, with the devices that comprise the system providing the interfaces to the external environment (e.g., sensors determining speed information from the vehicle).
Within the implementation, we define connections for each of the ports of the subcomponents. For example, connection DC2 is the data connection between the command_data port on the process speed_control and the cmd data port on the device throttle. Each of the connections is labeled in the graphical representation shown in Listing 3-1 by the nature of the connection.1 For example, connection EC4 between the event port disengage on the interface_unit device and the event port disengage on the speed_control process is labeled as <<Event>>. It is our choice to match most of the port names. It is not required that connected ports have the same name. However, they must have matching data classifiers if specified (they are omitted in this initial representation).
Listing 3-1. Subcomponents of the Complete PBA System
system Complete
end Complete;
system implementation Complete.PBA_speed_control
subcomponents
speed_sensor: device sensor.speed;
throttle: device actuator.speed;
speed_control: process control.speed;
interface_unit: device interface.pilot;
connections
DC1: port speed_sensor.sensor_data ->
speed_control.sensor_data;
DC2: port speed_control.command_data -> throttle.cmd;
DC3: port interface_unit.set_speed ->
speed_control.set_speed;
EC4: port interface_unit.disengage ->
speed_control.disengage;
end Complete.PBA_speed_control;
)
Depending upon your development environment the graphical portrayals may differ from those shown in Listing 3-1. For example, within OSATE you cannot display the containment explicitly. Rather, the internal structure of an implementation is presented in a separate diagram that can be accessed hierarchically through the graphical icon representing the implementation Complete.PBA_speed_control.
3.1.3. Detailing the Control Software
At this point, we begin to detail the composition of the process speed_control. This involves decisions relating to partitioning the functionality and responsibilities required of the PBA system to provide speed control. Since we have treated the speed control as an autonomous capability, we have implicitly assumed that there are no interactions between the directional or other elements of the PBA and the speed control system. This may not be the case in advanced control systems. In addition, for the purposes of this example, we partition the functions of the speed control process into two subcomponents. The first is a thread that receives input from speed sensor; scales and filters that data; and delivers the processed data to the second thread. The second is a thread that executes the PBA speed control laws and outputs commands to the throttle actuator. Again, this simplification may not be adequate for a realistic speed control system (e.g., the control laws may involve extensive computations that for efficiency must be separated into multiple threads or may involve complex mode switches that are triggered by various speed or directional conditions)2.
Since the interfaces for the two threads are different, we define a type and implementation for each, as shown in Listing 3-2. We have used property associations to assign execution characteristics to the threads. Each is a periodic thread (assigned using the Dispatch Protocol property association) with a period of 50ms (assigned using the Period property association).
The assignment of periodic execution and the values for the period of the threads reflect design decisions. Generally, these are based upon the input of application domain and/or control engineers. The assignments we use here are not necessarily optimal but are chosen to provide specific values to enable analysis of system performance. They do not reflect the values for any specific control system.
Listing 3-2. PBA Control Threads Declarations
thread read_data
features
sensor_data: in data port;
proc_data: out data port;
properties
Dispatch_Protocol => Periodic;
Period => 50 ms;
end read_data;
thread implementation read_data.speed
end read_data.speed;
thread control_laws
features
proc_data: in data port;
cmd: out data port;
disengage: in event port;
set_speed: in data port;
properties
Dispatch_Protocol => Periodic;
Period => 50 ms;
end Control_laws;
thread implementation control_laws.speed
end control_laws.speed;
We detail the declaration of the process implementation control.speed that is presented in Table 3-1 to include the two thread subcomponents and their interactions (connections), as shown in Listing 3-3. There are five connections declared. Four of these connect ports on the boundary of the process with ports on the threads (i.e., DC1, DC3, DC4, and EC1). The fifth connects the out data port proc_data on the thread scale_speed_data to the in data port proc_data on the thread speed_control_laws.
Listing 3-3. The Process Implementation control.speed
process implementation control.speed
subcomponents
scale_speed_data: thread read_data.speed;
speed_control_laws: thread control_laws.speed;
connections
DC1: port sensor_data -> scale_speed_data.sensor_data;
DC2: port scale_speed_data.proc_data ->
speed_control_laws.proc_data;
DC3: port speed_control_laws.cmd -> command_data;
EC1: port disengage -> speed_control_laws.disengage;
DC4: port set_speed -> speed_control_laws.set_speed;
end control.speed;
)
3.1.4. Adding Hardware Components
At this point, we have defined the software components of the speed control system. We now define the execution hardware required to support the software. In modeling the hardware and binding the control software to that hardware, we can analyze the execution timing and scheduling aspects of the system.
In Listing 3-4, we define a processor, memory, and bus. The processor will execute the PBA control code (threads) and the memory will store the executable code (process) for the system. In addition, we have declared that the processor type Real_Time and the memory type RAM require access to an instance of the bus implementation Marine.Standard. This bus will provide the physical pathway for the system. We will add properties to these declarations later in the modeling process.
Listing 3-4. Execution Platform Declarations
processor Real_Time
features
BA1: requires bus access Marine.Standard;
end Real_Time;
processor implementation Real_Time.one_GHz
end Real_Time.one_GHz;
memory RAM
features
BA1: requires bus access Marine.Standard;
end RAM;
memory implementation RAM.Standard
end RAM.Standard;
bus Marine
end Marine;
bus implementation Marine.Standard
end Marine.Standard;
3.1.5. Declaring Physical Connections
To continue the integration of the system, we add instances of the required execution platform components into the system implementation Complete.PBA_speed_control by declaring subcomponents for the implementation. In addition, we declare that these components are attached to the bus. This is done by connecting the requires interfaces on the processor and memory components to the bus component.
Since the PBA control software executing on the processor must receive data from the sensors and pilot interface unit as well as send commands to the throttle actuator, we declare that these sensing and actuator devices are connected to the bus as well. To do this, we add requires bus access declarations in the type declarations for these three devices and connect them to the bus. The updated declarations for the three devices are shown in Listing 3-5 and the graphical representation of the system with the declaration of the physical (bus access) connections is shown in Listing 3-6.
Listing 3-5. Updated Device Declarations
device interface
features
set_speed: out data port;
disengage: out event port;
BA1: requires bus access Marine.Standard;
end interface;
device sensor
features
sensor_data: out data port;
BA1: requires bus access Marine.Standard;
end sensor;
device actuator
features
cmd: in data port;
BA1: requires bus access Marine.Standard;
end actuator;
In Listing 3-6, we have defined a processor RT_1GHz 3, bus Standard_Marine_Bus, and memory Stand_Memory as subcomponents. In addition, we have declared the connections for the bus Standard_Marine_Bus to the requires bus access features of each of the physical components (e.g., from Standard_Marine_Bus to RT_GHz.BA1 and to the requires bus access feature on the processor RT_1GHz.BA1). The requires access features and the bus access connections are shown in the graphical representation in the lower portion of Listing 3-6.
Listing 3-6. Integrated Software and Hardware System
system implementation Complete.PBA_speed_control
subcomponents
speed_sensor: device sensor.speed;
throttle: device actuator.speed;
speed_control: process control.speed;
interface_unit: device interface.pilot;
RT_1GHz: processor Real_Time.one_GHz;
Standard_Marine_Bus: bus Marine.Standard;
Stand_Memory: memory RAM.Standard;
connections
DC1: port speed_sensor.sensor_data ->
speed_control.sensor_data;
DC2: port speed_control.command_data -> throttle.cmd;
DC3: port interface_unit.set_speed ->
speed_control.set_speed;
EC4: port interface_unit.disengage ->
speed_control.disengage;
BAC1: bus access Standard_Marine_Bus <-> speed_sensor.BA1;
BAC2: bus access Standard_Marine_Bus <-> RT_1GHz.BA1;
BAC3: bus access Standard_Marine_Bus <-> throttle.BA1;
BAC4: bus access Standard_Marine_Bus <-> interface_unit.BA1;
BAC5: bus access Standard_Marine_Bus <-> Stand_Memory.BA1;
end Complete.PBA_speed_control;
)
3.1.6. Binding Software to Hardware
In addition to specifying the physical connections, we bind software components to the appropriate physical hardware using contained property associations, as shown in Listing 3-7. These property associations are added to the system implementation declaration Complete.PBA_speed_control. The first two declarations allow the threads speed_control_laws and scale_speed_data to be bound to the processor rt_mhz500. The reference part of the property association identifies the specific processor instance rt_mhz500 and the applies to identifies the specific thread in the hierarchy (e.g., applies to speed_control.scale_speed_data identifies the thread scale_speed_data that is located in the process speed_control). In this notation, a period separates the elements in the hierarchy.
We could have specified a specific binding using the Actual_Processor_Binding property. However, the Allowed_Processor_Binding property permits scheduling tools to assign the threads to processors. For example, the resourced allocation and scheduling analysis plug-in that is available in the OSATE environment 4 binds threads to processors taking into consideration the threads’ period, deadline, and execution time; processor(s) speed and scheduling policies; and the constraints imposed by the actual and allowed binding properties 5. Specifically, if only allowed processor bindings are defined (i.e., the Allowed_Processor_Binding property), the plug-in schedules the thread onto processors and reports back the actual thread to processor bindings and the resulting processor utilizations. If actual processor bindings are defined (i.e., the Actual_Processor_Binding property) the plug-in reports processor utilization based upon those bindings; allocates threads to processors; and runs a scheduling analysis to determine whether the bindings are acceptable.
The third entry in Listing 3-7, binds the code and data within the process speed_control to the memory component Standard_Memory. We chose to use the actual rather than the allowed memory binding property, since there is only one memory component in the system and, while an additional processor might be added, we do not anticipate additional memory components to be added.
Listing 3-7. Binding Property Associations
properties
Allowed_Processor_Binding => (reference(RT_1GHz))
applies to speed_control.speed_control_laws;
Allowed_Processor_Binding => (reference(RT_1GHz))
applies to speed_control.scale_speed_data;
Actual_Memory_Binding => (reference(Stand_Memory))
applies to speed_control;
3.1.7. Conducting Scheduling Analyses
Having defined the threads and established their allowed bindings to processors, we can begin to assess processor loading and analyze the schedulability of the system.
Before we proceed with a scheduling analysis, we define the requisite execution characteristics for the threads as they relate to the capabilities of the processors to which they may be bound. We specify this information through properties of the threads and processors. In this case, there is only one processor with an execution speed of 1GHz, as shown in Listing 3-8. Both threads are declared as Periodic with a period of 50ms. The default value in the AADL standard for the Deadline is the value of the Period. This value can be overridden by assigning a value to the Deadline using a property association. The execution time of the read_data thread ranges from 1 millisecond (ms) to 2 milliseconds (ms), whereas the control_laws thread’s execution time ranges from 3ms to 5ms (as assigned using the Compute_Execution_Time property associations). These execution times are relative to the processor Real_Time.one_GHz declared in the model 6.
Execution time estimates for the threads can be based upon timing measurements from prototype code or historical data for similar systems (e.g., systems with the same or comparable processors). By conducting the analysis early in the development process, you can get quantitative predictions of a system’s performance. This information can be updated and re-evaluated as the design progresses. These early and continuing predictions can help to avoid last minute problems during code implementation and system integration (e.g., during testing when deadlines are not met because the processor loading exceeds the capability of the processor).
Listing 3-8. Updated Declarations for Analysis
thread read_data
features
sensor_data: in data port;
proc_data: out data port;
properties
Dispatch_Protocol => Periodic;
Compute_Execution_Time => 1 ms .. 2 ms;
Period => 50 ms;
end read_data;
thread control_laws
features
proc_data: in data port;
cmd: out data port;
disengage: in event port;
set_speed: in data port;
properties
Dispatch_Protocol => Periodic;
Compute_Execution_Time => 3 ms .. 5 ms;
Period => 50 ms;
end Control_laws;
At this point, we have defined a declarative model for a simple speed control system including all of the components, properties, and bindings to describing a deployment configuration. From the top-level system implementation of this declarative model you create a system instance model and analyze it with the OSATE scheduler and scheduling analysis plug-in.
In Figure 3-1, we show the results of that analysis. It shows that the two threads in the system only use 14% of the processor capabilities. The worst case execution time for the two threads is 7ms, which is 14% of their 50 millisecond period.
)
Figure 3-1. Processor Capacities of the Speed Control System Instance
Notice the information provided by the plug-in, including the actual binding for the threads determined by the plug-in (as shown in the cropped output of Figure 3-2).
)
Figure 3-2. Bindings from the OSATE Scheduler and Scheduling Analysis Plug-in
3.1.8. Summary
At this point, we have developed a basic architectural model of the PBA speed control system. In so doing, we have demonstrated some of the core capabilities of the AADL. For this relatively simple model, we analyzed the execution environment and made predictions of schedulability of the system. In subsequent sections, we describe additional capabilities of the AADL and discuss alternative modeling approaches that can be applied in this simple example.