Isolette Example Safety Critical Software SAnToS Laboratory - - PowerPoint PPT Presentation
AADL Isolette Example Safety Critical Software SAnToS Laboratory Kansas State University John Hatcliff, Brian Larson Obje ject ctive ives s Understand how the functional architecture of the Isolette example from the FAA
Safety Critical Software SAnToS Laboratory Kansas State University John Hatcliff, Brian Larson
Understand how the functional architecture of
Become comfortable with using various AADL tools to
“The purpose of the Isolette Thermostat is to maintain the air temperature of an Isolette within a desired range. It senses the Current Temperature of the Isolette and turns the Heat Source on and
The Isolate example will be used as the primary running example in our lectures.
package isolette public with Base_Types,iso_variables; … end isolette;
Name of a package that will hold both component types and implementations for the Isolette.
Packages are used to organize component interface specifications (component types) and their blueprints (component implementations) into libraries.
This package will “import” from
basic AADL types and for variables/types used throughout the Isolette example.
system isolette end isolette; system implementation isolette.single_sensor subcomponents … connections … end isolette.single_sensor;
To describe the top-level structure of the Isolette device, we use the AADL System component category
Define the component type named isolette using a system component. In this case, we have no features on our component interface because we are defining a “wrapper” for the entire system.
system isolette end isolette; system implementation isolette.single_sensor subcomponents … connections … end isolette.single_sensor;
To describe the top-level structure of the Isolette device, we use the AADL System component category
Define a component implementation impl for the component type isolette. A component implementation specifies properties/structure (but usually not the complete details) of a components
the implementation construct to specify the subcomponents of the isolette and the connections (communication) between them.
system implementation isolette.single_sensor subcomponents thermostat : system thermostat_single_sensor.impl; temperature_sensor : device Devices::temperature_sensor.impl; heat_source : device Devices::heat_source.impl;
connections … end isolette.single_sensor
In the system implementation, we can define subcomponents corresponding to the subcomponent identified in the Isolette conceptual architecture from the FAA REMH.
Name each of the subcomponents and associate each with a component category and implementation (declared elsewhere).
Note: we don’t have a subcomponent for “Air” because air is an entity of the environment (not an entity of the system to be implemented). We can, if we choose, also model the environment with AADL. This will be addressed elsewhere.
device temperature_sensor features air : in data port Iso_Variables::current_temperature current_temperature : out data port Iso_Variables::current_temperature end temperature_sensor; device implementation temperature_sensor.impl end temperature_sensor.impl;
Some components in our models will represent hardware whose details we may choose not to specify (in which case, we leave the implementation empty).
We leave the implementation of a component unspecified by using an empty body.
device temperature_sensor features … current_temperature :
end temperature_sensor;
Component interfaces (types) have features that capture capabilities and means of interaction made available to other components (“clients” of the component type being declared).
Declare a port name, category (“out” , “data”), and type for the data that will be communicated on that port.
Note: we use the “device” category to model the Temperature Sensor component.
system thermostat_th features current_temperature : in data port iso_variables::current_temperature; heat_control : out data port iso_variables::on_off; lower_desired_temperature : in data port iso_variables::lower_desired_temperature; upper_desired_temperature : in data port iso_variables::upper_desired_temperature; lower_alarm_temperature : in data port iso_variables::lower_alarm_temperature; upper_alarm_temperature : in data port iso_variables::upper_alarm_temperature; regulator_status : out data port iso_variables::status; monitor_status : out data port iso_variables::status; display_temperature : out data port iso_variables::measured_temperature_range; alarm : out data port iso_variables::on_off; end thermostat_th;
The Thermostat component has a number of ports to capture its communication potential.
We will see later that related ports (e.g., all the ports capturing operator settings) can be bundled together in an AADL Feature Group – which is a useful abstraction mechanism.
As our modeling effort unfolds, we maintain a package containing data types defined specifically for the Isolette system.
package isolette public with Base_Types, iso_variables; … end isolette; isolette.aadl
package iso_variables public with Base_Types, Data_Model; …
data lower_desired_range properties Data_Model::Real_Range => 97.0 .. 99.0; Data_Model::Measurement_Unit => "Fahrenheit"; end lower_desired_range;
data measured_temperature_range properties Data_Model::Real_Range => 68 .. 105; Data_Model::Measurement_Unit => "Fahrenheit"; end measured_temperature_range; … end iso_variables;
iso_variables.aadl
As our modeling effort unfolds, we maintain a package containing data types defined specifically for the Isolette system.
data current_temperature properties Data_Model::Real_Range => 68.0 .. 105.0; Data_Model::Measurement_Unit => "Fahrenheit"; end current_temperature;
(excerpt from iso_variables.aadl)
system thermostat_th features current_temperature : in data port Iso_variables::current_temperature; heat_control : out data port Iso_variables::on_off; lower_desired_temperature : in data port Iso_variables::lower_desired_temperature; upper_desired_temperature : in data port Iso_variables::upper_desired_temperature; lower_alarm_temperature : in data port Iso_variables::lower_alarm_temperature; upper_alarm_temperature : in data port Iso_variables::upper_alarm_temperature; regulator_status : out data port Iso_variables::status; monitor_status : out data port Iso_variables::status; display_temperature : out data port Iso_variables::display_temperature_range; alarm : out data port Iso_variables::on_off; end thermostat_th; Declaration of the display_temperature_range type used in the port declaration above.
system implementation isolette.impl subcomponents … connections ct : port temperature_sensor.current_temperature -> thermostat.current_temperature; hc : port thermostat.heat_control -> heat_source.heat_control; ldt : port operator_interface.lower_desired_temperature
udt : port operator_interface.upper_desired_temperature
lat : port operator_interface.lower_alarm_temperature -> thermostat.lower_alarm_temperature; uat : port operator_interface.upper_alarm_temperature -> thermostat.upper_alarm_temperature; rs : port thermostat.regulator_status -> operator_interface.regulator_status; ms : port thermostat.monitor_status -> operator_interface.monitor_status; dt : port thermostat.display_temperature -> operator_interface.display_temperature; al : port thermostat.alarm -> operator_interface.alarm; end isolette.impl;
In the system implementation, we can define connections representing the communication between each of the subcomponents
A connection relates the port of one component to the port of another, representing the communication between the two components via the specified ports. The ports must be “compatible” (e.g., with respect to port types). E.g., “ct” names the port communication for Current Temperature.
We can continue in this manner to specify
In the following slides, we will illustrate
The FAA REMH decomposes the Isolette into a Regulate Temperature function that actually implements the controls of the system and a Monitor Temperature function that implements a safety system that will generate an alarm when certain error conditions arise.
Decomposing the Thermostat into Regulate Temperature and Monitor Temperature functions.
system implementation thermostat_th.impl subcomponents regulate_temperature : process regulate_temperature_mt.impl; monitor_temperature : process monitor_temperature_mt.impl; connections … end thermostat_th.impl
The component implementation for the thermostat reveals the decomposition.
The Thermostat implementation reveals a decomposition to components representing the Regulate Temperature and Monitor Temperature functions.
Consider the description of the Regulate Temperature function from the FAA REMH. We will proceed to illustrate how the components, external communication, and internal communication are modeled.
process regulate_temperature_mt features upper_desired_temperature : in data port Iso_variables::upper_desired_temperature; lower_desired_temperature : in data port Iso_variables::lower_desired_temperature; regulator_status : out data port Iso_variables::status; displayed_temp : out data port Iso_variables::display_temperature_range; current_temperature : in data port Iso_variables::display_temperature_range; heat_control : out data port Iso_variables::on_off; end regulate_temperature_mt;
We will now consider the modeling of the Regulate Temperature function
Declare a port for each type of external communication (for each data flow to/from the module) Use an AADL process component category to indicate that the address space of Regulate Temperature is separate from that of Monitor Temperature.
process implementation regulate_temperature.impl subcomponents manage_regulator_interface : thread manage_regulator_interface_mri.impl; manage_heat_source : thread manage_heat_source_mhs.impl; manage_regulator_mode : thread manage_regulator_mode_mrm.impl; connections … end regulate_temperature.impl;
The internal function and data flows for Regulate Temperature specified in the FAA REMH are reflected in the component implementation
Declare a thread for each of the three functions of the Regulate Temperature component.
process implementation regulate_temperature_mt.impl subcomponents manage_regulator_interface : thread manage_regulator_interface_mri.impl; manage_heat_source : thread manage_heat_source_mhs.impl; manage_regulator_mode : thread manage_regulator_mode_mrm.impl; connections rudt : port upper_desired_temperature -> manage_regulator_interface.upper_desired_temp; rldt : port lower_desired_temperature -> manage_regulator_interface.lower_desired_temp; mudt : port upper_desired_temperature -> manage_heat_source.upper_desired_temperature; mldt : port lower_desired_temperature -> manage_heat_source.lower_desired_temperature; rrs : port manage_regulator_interface.regulator_status -> regulator_status; rdt : port manage_regulator_interface.displayed_temp -> displayed_temp; rcti : port current_temperature -> manage_regulator_interface.current_temperature; rcth : port current_temperature -> manage_heat_source.current_temperature; rhc : port manage_heat_source.heat_control -> heat_control; rdr : port manage_regulator_interface.desired_range
rrmh : port manage_regulator_mode.regulator_mode
rrmi : port manage_regulator_mode.regulator_mode
rctm : port current_temperature -> manage_regulator_mode.current_temperature; rif : port manage_regulator_interface.interface_failure
end regulate_temperature_mt.impl;
The internal function and data flows for Regulate Temperature specified in the FAA REMH are reflected in the component implementation
Note: The two desired temperature arcs in the subsystem are broken out into upper/lower values (so we end up with 14 connections compared to 12 arcs in the original diagram.
thread manage_heat_source_mhs features heat_control : out data port Iso_Variables::on_off current_temperature : in data port Iso_Variables::current_temperature lower_desired_temperature : in data port Iso_Variables::lower_desired_temperature upper_desired_temperature : in data port Iso_Variables::upper_desired_temperature regulator_mode : in data port Iso_Variables::regulator_mode end manage_heat_source_mhs; thread implementation manage_heat_source_mhs.impl end manage_heat_source_mhs.impl;
The Manage Heat Source function turns the heating element on/off based on the current temperature and the desired temperature range.
Note: we do not describe the details of the component at this point in development.
thread manage_regulator_interface_mri features regulator_status : out data port Iso_Variables::status lower_desired_temp : in data port Iso_Variables::lower_desired_temperature upper_desired_temp : in data port Iso_Variables::upper_desired_temperature current_temperature : in data port Iso_Variables::current_temperature displayed_temp : out data port Iso_Variables::measured_temperature_range regulator_mode : in data port Iso_Variables::regulator_mode interface_failure : out data port Base_Types::Boolean end manage_regulator_interface_mri; thread implementation manage_regulator_interface_mri.impl end manage_regulator_interface_mri.impl;
The Manage Regulator Interface function implements the interaction with the
thread manage_regulator_mode_mrm features regulator_mode : out data port Iso_Variables::regulator_mode current_temperature : in data port Iso_Variables::current_temperature interface_failure : in data port Base_Types::Boolean internal_failure : in data port Base_Types::Boolean end manage_regulator_mode_mrm; thread implementation manage_regulator_mode_mrm.impl end manage_regulator_mode_mrm.impl;
The Manage Regulator Mode function determines the operating mode (Normal, Failure) of the Regulate Temperature function
Note: we add a notion of interface failure (not specified in the REMH) to the notion of internal failure
A separate package of data types is maintained for modeling data values communicated between Isolette components. Data types are defined using AADL data components.
package iso_variables public with Base_Types, Data_Model; …
data lower_desired_range properties Data_Model::Real_Range => 97.0 .. 99.0; Data_Model::Measurement_Unit => "Fahrenheit"; end lower_desired_range;
data display_temperature_range properties Data_Model::Real_Range => 68.0 .. 105.0; Data_Model::Measurement_Unit => "Fahrenheit"; end display_temperature_range; … end iso_variables;
iso_variables.aadl
The name lower_desired_range can be used as a type in other sections of the AADL Isolette model. We can use properties defined in the AADL Data Model to specify range constraints and units.
AADL is a natural vehicle for formalizing architectural
Applying AADL to the Isolette system, we are able to
Components
Interfaces Implementations (nested component structures)
Communication between components
In subsequent lectures, we will explore additional topics:
Using BLESS to define component behaviors and behavioral
constraints on components
Using the AADL Error Annex to model sources and propagation of
errors within the Isolette.
Starting from the incomplete AADL model in the files
Give component types and implementations for the
Add data definitions corresponding to four definitions of
lower_alarm_temp upper_alarm_temp alarm_range monitor_mode
Give all the AADL definitions necessary to model the
Make sure your models are syntactically correct by
The material in this lecture is based on…
The Isolette example used in the FAA DOT/FAA/AR-08/32,
Requirements Engineering Management Handbook. David L. Lempia & Steven P. Miller.
Various AADL tutorials available on the AADL website.
Thanks to Brian Larson for constructing the AADL model