- 3.1. Developing a Simple Model
- 3.2. Representing Code Artifacts
- 3.3. Modeling Dynamic Reconfigurations
- 3.4. Modeling and Analyzing Abstract Flows
- 3.5. Developing a Conceptual Model
- 3.6. Working with Component Patterns
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4. Modeling and Analyzing Abstract Flows
One of the important capabilities of the AADL is the ability to model and analyze flow paths through a system. For example within the PBA system, it is possible to analyze the time required for a signal to travel from the interface unit, through the control system, to the throttle actuator, and result in a throttle action.
3.4.1. Specifying a Flow Model
For this section, we add flow specifications to the expanded PBA speed control system shown in Figure 3-3. We investigate a flow path (the end-to-end flow) involving a change of speed via set_speed that extends from the pilot’s interface unit to the throttle. In specifying the flow, we define each element of the flow (i.e., a flow source, flow path(s), flow sink), using on_flow as a common prefix for each flow specification name. In addition, we allocate transport latencies for each of these elements. Listing 3-14 presents an abbreviated version of the specification for the PBA speed control system that includes the requisite flow declarations.
){kind=link}
The flow source is named on_flow_src that exits the interface unit through the port set_speed. The flow proceeds through the speed_control process via the flow path on_flow_path that enters through the port set_speed and exits through the port command_data. The flow sink occurs through the data port cmd in the throttle component. Note that a flow path can go from any kind of incoming port to a port of a different kind, for example from an event port to a data port.
Each flow specification is assigned a latency value. For example, the worst case time for the new speed to emerge from the interface unit after the pilot initiates the set_point request is 5ms. The worst case transit time through the speed_control process is 20ms and the time for the throttle to initiate an action is 8ms.7
Listing 3-14. Flow Specifications for the Expanded PBA
-- flow specifications are added to type declarations for this analysis ---
device interface_unit
features
set_speed: out data port;
disengage: out event port;
control_on: out event port;
flows
on_flow_src: flow source set_speed {latency => 5 ms .. 5 ms;};
end interface_unit;
process control_ex
features
sensor_data: in data port;
command_data: out data port;
status: out data port;
disengage: in event port;
set_speed: in data port;
control_on: in event port;
flows
on_flow_path: flow path set_speed -> command_data
{latency => 10 ms .. 20 ms;};
properties
Period => 50 Ms;
end control_ex;
device actuator
features
cmd: in data port;
BA1: requires bus access Marine.Standard;
flows
on_flow_snk: flow sink cmd {latency => 8 ms .. 8 ms;};
end actuator;
3.4.2. Specifying an End-to-End Flow
The complete path, the end-to-end flow, for this example runs from the source component interface_unit through to the component throttle. This is declared in the system implementation PBA.expanded, as shown in Listing 3-15. The declaration originates at the source component and its source flow interface_unit.on_flow_src and the connection EC4. It continues through speed_control.on_flow_path, the connection DC2, and terminates at the sink throttle.on_flow_snk. In addition, we have specified a latency of 35ms for the flow. This value is drawn from the requirements for the system.
Listing 3-15. An End-to-End Flow Declaration
system implementation PBA.expanded
subcomponents
speed_sensor: device sensor.speed;
throttle: device actuator.speed;
speed_control: process control_ex.speed;
interface_unit: device interface_unit;
display_unit: device display_unit;
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;
EC5: port interface_unit.control_on->
speed_control.control_on;
DC6: port speed_control.status -> display_unit.status;
flows
on_end_to_end: end to end flow
interface_unit.on_flow_src -> EC5 ->
speed_control.on_flow_path -> DC2 ->
throttle.on_flow_snk {Latency => 35 ms .. 35 ms;};
end PBA.expanded;
3.4.3. Analyzing a Flow
At this point, we have defined a top-level end-to-end flow, assigned an expected (required) latency value to this flow, and defined latencies for each of the elements that comprise the flow. OSATE includes a flow latency analysis tool that automatically checks to see if end-to-end latency requirements are satisfied. For example, the tool will trace the path and total the latencies for the individual elements of the flow. This total is compared to the latency expected for an end-to-end flow. Figure 3-5 presents the results of this analysis for the PBA system we have specified. The total latency for the three elements of the flow at 33ms is less than the expected 35ms.
)
Figure 3-5. Top Level End-to-End Flow Analysis Results
We could have manually determined, through a separate calculation, that the cumulative latency for the end-to-end flow would not violate the 35ms latency requirement. However, for very large systems, these calculations are difficult to do manually and it is difficult to ensure that latency values are correctly connected through the elements that comprise an architecture. The automated capabilities that can be included within an AADL tool facilitate easy calculation and re-calculation of these values. Moreover, having this data integral to the architecture provides a reliable way to manage the information and ensure consistency with updates to the data and the architecture.