AADL for ICE Apps and Device Interfaces
AADL MOTIVATION
App Architecture/Component Specs
Architecture Analysis & Design Language – an SAE standard http://standards.sae.org/as5506a/
The AADL is designed for specification, analysis, and automated integration of real-time, performance critical, distributed computer systems
AADL specification language focus Components (representing threads, processors, devices) Interfaces/Ports and connections between them Extensible property language for adding meta-data
It enables analysis of system designs prior to development and supports a model-based, model-driven development approach
The AADL is adaptable by design, providing flexibility via Extensible standard language (annexes) Project-specific properties
We believe that AADL can nicely map down to different pub/sub middleware frameworks being using by Quantum partners
Considering AADL as a standards-based modeling an analysis environment for ICE architecture and ICE app development
AADL Abstracts Middleware
App Development
Runtime Pub / Sub Thin Interface
AADL / MARTEAADL / MARTE
K-State / SAnToS
K-State / SAnToS
AADL Users and Voting Members
Airbus Axlog Boeing Dassault Aviation EADS Eaton European Space
Agency Ford Lockheed Martin
General Dynamics Raytheon Rockwell Collins Toyota NIST NATO Aviation ..etc., etc.,
Example AADL Use: SAVI System Architecture Virtual Integration (SAVI)
program Boeing, Airbus, Lockheed Martin, BAE Systems, Rockwell
Collins, GE Aviation, FAA, DoD, SEI, Honeywell, Goodrich, United Technologies, and NASA
Principles Define a precise system architecture -- machine-analyzable,
single architectural model annotated with precise notation Use “integrate then build'' design approach where important
interactions are specified and interfaces are designed, and integration verified before the internals of components are built)
ICE / UL 2800 may find a similar approach useful since much of ICE has not been fully implemented
Provide implementations that are compliant with the architecture.
https://wiki.sei.cmu.edu/aadl/index.php/Projects_and_Initiatives#AVSI_SAVI
AADL and ICE Can be used to precisely define ICE architecture, interfaces,
meta-data in source language independent manner Standards writing efforts Use in 3rd party certification to aid in assessing compliance of
vendor submissions to architecture Vendor development tools
Generate interface code directly from architecture “Single source of truth” around which to organize requirements,
testing, meta-data, etc.
Can be used to define device interfaces (might be the basis of ICE IDL)
Can be used to define component-based apps (next generation of MDCF component-based app development)
Libraries of certified components
AADL can potentially be used in a variety of ways in ICE-related efforts
PULSE OXIMETRY SMART ALARM APP EXAMPLE
Example: Pulse Ox Smart Alarms
Common device used to measure Blood oxygen saturation (SpO2) %
(respiratory health) Pulse rate
Typically have built in alarms, e.g., to alert when SpO2 falls below a certain bound (e.g., 85%)
Pulse Oximeter
“Smart Alarm”
Additional alarm functionality beyond normal device alarms that
takes into account extra context information
gives more precise/useful alarm
Our example: make an app to implement two smart alarms
Look for rapid declines in SpO2
Auto-adjust SpO2 lower alarm bound level when patients are on supplementary oxygen
System Synopsis
This Integrated Clinical Environment (ICE) Pulse Oximetry Monitoring app provides Medical Device Data System (MDDS) displays of pulse oximetry device data, trend data for device readings, control of pulse oximeter device alarm settings, and derived alarms.
The derived alarms enhance the functionality of conventional pulse oximeters by supporting more precise alarming for SpO2 readings when a patient is on supplementary oxygen and by detecting rapid declines in SpO2 that do not necessarily fall below the SpO2 lower limit alarm provided by pulse oximeters.
….provide a short textual synopsis of the app. The synopsis should name the system, describe its purpose, and summarize the system capability.
REMHREMH
ICE PO Smart Alarm App Example
System SynopsisClinician’s view of the system – SpO2 Smart Alarm App (accompanied by text walk-though) – high-level view of how app interacts with context
High-level view of how ICE is instantiated with particular devices
High-level view of how ICE is instantiated with particular devices
High-level summary of interactions between app and other ICE components
High-level summary of interactions between app and other ICE components
High-level summary of interactions between clinician and ICE components
High-level summary of interactions between clinician and ICE components
System Goals
G1–warn clinician if patients using supplementary oxygen have low blood oxygenation
G2–warn clinician if patient’s blood oxygenation decreases rapidly
G3–warn if blood oxygenation measurement is unreliable G4–display recent blood oxygenation measurements G5–display recent heart rate measurements G6–display current heart rate G7–display current blood oxygenation measurement G8–display parameters used to determine alarms G9–allow entry of parameters used to determine alarms G10–warn clinician if device detects fast or slow heart
rate, by forwarding native alarms from the pulse oximeter device
G11–warn clinician if device detects low SpO2 by forwarding native alarms from the pulse oximeter device
ICE PO Smart Alarm App Example
Should we confirm once and for all that our strategy for buffering and calculating alarms is a good one?
USING AADL FOR ICE APPS
Defining an App ContextThe top-level of an AADL-based app description identifies that ICE components that an app will interact with (e.g., devices, ICE services) and precisely defines the interface of the app with these components.
App ContextApp Context
AppApp
Required devicesRequired devices
ServicesServices
Graphical & Textual ViewsAADL provides both a graphical view and a textual view of models. The textual view is probably more useful for serious development.
App Structure
AppApp
An app is broken down into an app logic component and app user interface (e.g., supervisor user interface) components
App LogicApp LogicApp UIApp UI
App Structure
App LogicApp
Logic
The definition of an app’s logic may be broken down into many (potentially nested) components – usually corresponding to the primary threads or computational units within an app.
Heart Rate TrendHeart Rate Trend
SpO2 TrendSpO2 TrendRapid DeclineSmart Alarm Logic
Rapid DeclineSmart Alarm Logic
Supplementary Oxygen Smart Alarm Logic
Supplementary Oxygen Smart Alarm Logic
Component Features
A feature describes an interface of a component through which control and data may be provided to or required from other components.
Features of Component Types
port port group parameter access
subprogram subprogram group data bus
Ports & ConnectionsAADL components can have ports – these represent interfacing points with the context. Connections between ports on different components represent communication pathways (e.g., pub/sub relationships) provided by underlying middleware.
Output event port (this component is the “provider”)
Output event port (this component is the “provider”)
The outer context can subscribe/consume this event.
The outer context can subscribe/consume this event.
Input data portInput data port
Features – Ports Ports – interaction points of a component to model directional transfer of data and control. Ports are declared as features in component types.
• Data port: non-queued data
• Event port: queued signals
• Event data port: queued messages
Feature group – aggregation of ports (and other features) into single connection point
Connections – connect ports in the direction of data/control flow; uni- or bi-directional
Data port
out
in
in out
Event port
Event data port
Feature group
Component Categories
application data subprogram subprogram group thread thread group process feature group
platform memory device processor bus virtual processor virtual bus
composite system abstract
Up to this point we have just been thinking of components as “boxes”, but AADL provides a collection of component categories representing common hardware & software elements.
AADL Component Categories
System – hierarchical organization of components
Process – protected address space
Thread group – logical organization of threads
Thread – a schedulable unit of concurrent execution
Data – potentially sharable data
Subprogram – callable unit of sequential code
Process
Thread
Data
Subprogram
Thread group
System
Our AADL-based app definitions will use (primarily) the component categories below.
App Structure Template
App Context (App plus ICE Platform Resources, Properties capture system requirements) (AADL System)
App (Properties capture run-time requirements on Supervisor VM,and communication requirements on Network Controller) (AADL System)
ICE Display Server
Thread Thread Thread Group
Subprogram Group
ICE Interface forMed Device
(AADL System)
ICE Logging Service Interface
(AADL System)
ICE External InterfaceEMR or other equipment(AADL System)
ICE Interface forMed Device
(AADL System)
Maybe use “extends” for different types
of displays.
Data Data
App Logic (AADL Process)
App GUI (AADL Process)
We can propose a standard “template” for structuring apps
Components AADL components are
separated into component type and component implementation
Similar in spirit to Ada packages Component type defines the
interface --- everything visible from the outside
Component implementation determines behavior or internal structure
Behavior (code), or Network of nested components
Inclusion polymorphism – a component type may have multiple implementations
Component Type
Component Implementations
App Context Type & Imp
system ICEpoSystem --may add probe connected to Pulse Oximeter device --may add output to ICE data logger --may add output to electronic health recordend ICEpoSystem;
system implementation ICEpoSystem.imp subcomponents po : device ICEpoInterface.imp; app : system ICEpoAppProcess.imp; screen : device ICE_Display::Screen; --ICE display touch screen piezo : device ICE_Display::Speaker; --audible ICE alarm connections …end ICEpoSystem.imp;
Example: Top-level (app context) is a component of category system. Its type defines no features. Its implementation is a network of subcomponents + connections.
App Context Type & ImpExample: Top-level (app context) is a component of category system. Its type defines no features. Its implementation is a network of subcomponents + connections.
Data Modeling
RepresentationRepresentation
Range constraintRange constraint
Semantic interpretation via 11073 Nomenclature
Semantic interpretation via 11073 Nomenclature
SpO2 is a “Percent” as defined below.SpO2 is a “Percent” as defined below.
Real-time and QoS SpecificationRT and QoS information is specified using the AADL property mechanism. The property mechanism is extensible, but AADL’s standard property libraries include almost all of the properties that we believe that we will need.
RT Threading Properties
This is a “periodic” thread dispatched at a specific period (specified below)
This is a “periodic” thread dispatched at a specific period (specified below)
Worst-case execution timeWorst-case execution time
The period at which the thread is dispatched and, once the dispatch occurs, the time by which the thread should complete.
The period at which the thread is dispatched and, once the dispatch occurs, the time by which the thread should complete.
RT Port Properties
Specifies the rate of which values will change on this data port. If this were an event port, it would specify the rate at which events are published.
Specifies the rate of which values will change on this data port. If this were an event port, it would specify the rate at which events are published.
AADL Dispatch Protocol Kinds
Periodic: Every period triggered by the dispatcher of the runtime system
Aperiodic: Triggered by the arrival of events, event data, subprogram calls
Sporadic: Triggered by the arrival of events, event data, subprogram calls with a minimum time difference of the specified period between dispatches
Timed: Triggered by the arrival of events, event data, subprogram calls with a timeout at the specified period.
Hybrid: Triggered by the arrival of events, event data, subprogram calls, as well as every period triggered by the dispatcher.
Background: May not respond to events or clocks…we will only use the two dispatch modes indicated above
Top Related