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