AADL for ICE Apps and Device Interfaces

1. AADL for ICE Apps and Device Interfaces

2. AADL MOTIVATION

3. App Architecture/Component Specs Considering AADL as a standards-based modeling an analysis environment for ICE architecture and ICE app development • 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

4. AADL Abstracts Middleware AADL / MARTE App Development K-State / SAnToS Runtime Pub / Sub Thin Interface MIDAS NIST DDS

5. 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.,

6. 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

7. AADL and ICE AADL can potentially be used in a variety of ways in ICE-related efforts • 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

8. PULSE OXIMETRY SMART ALARM APP EXAMPLE

9. Example: Pulse Ox Smart Alarms Pulse Oximeter • 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%) “Smart 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 • Additional alarm functionality beyond normal device alarms that • takes into account extra context information • gives more precise/useful alarm

10. System Synopsis REMH ….provide a short textual synopsis of the app. The synopsis should name the system, describe its purpose, and summarize the system capability. ICE PO Smart Alarm App Example 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.

11. System Synopsis Clinician’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 summary of interactions between clinician and ICE components High-level view of how ICE is instantiated with particular devices High-level summary of interactions between app and other ICE components

12. System Goals Should we confirm once and for all that our strategy for buffering and calculating alarms is a good one? ICE PO Smart Alarm App Example • 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

13. USING AADL FOR ICE APPS

14. Defining an App Context The 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. Required devices App Services App Context

15. Graphical & Textual Views AADL provides both a graphical view and a textual view of models. The textual view is probably more useful for serious development.

16. App Structure An app is broken down into an app logic component and app user interface (e.g., supervisor user interface) components App UI App Logic App

17. App Structure 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. SpO2 Trend Rapid Decline Smart Alarm Logic Heart Rate Trend Supplementary Oxygen Smart Alarm Logic App Logic

18. Component Features A feature describes an interface of a component through which control and data may be provided to or required from other components.

19. Features of Component Types • port • port group • parameter • access • subprogram • subprogram group • data • bus

20. Ports & Connections AADL 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. Input data port Output event port (this component is the “provider”) The outer context can subscribe/consume this event.

21. Features – Ports in • 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 out in out Data port Event port Event data port Feature group

22. Component Categories 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. • application • data • subprogram • subprogram group • thread • thread group • process • feature group • platform • memory • device • processor • bus • virtual processor • virtual bus • composite • system • abstract

23. AADL Component Categories Our AADL-based app definitions will use (primarily) the component categories below. 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 System Process Thread group Thread Data Subprogram

24. App Structure Template We can propose a standard “template” for structuring apps App Context (App plus ICE Platform Resources, Properties capture system requirements) (AADL System) ICE Interface for Med Device (AADL System) ICE Logging Service Interface (AADL System) ICE Display Server Maybe use “extends” for different types of displays. ICE Interface for Med Device (AADL System) App (Properties capture run-time requirements on Supervisor VM, and communication requirements on Network Controller) (AADL System) App GUI (AADL Process) App Logic (AADL Process) Thread Group Thread Thread ICE External Interface EMR or other equipment (AADL System) Subprogram Group Data Data

25. Components Component Type • 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 Implementations

26. App Context Type & 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. system ICEpoSystem --may add probe connected to Pulse Oximeter device --may add output to ICE data logger --may add output to electronic health record end 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;

27. App Context Type & 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.

28. Data Modeling SpO2 is a “Percent” as defined below. Representation Range constraint Semantic interpretation via 11073 Nomenclature

29. Real-time and QoS Specification RT 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.

30. RT Threading Properties This is a “periodic” thread dispatched at a specific period (specified below) Worst-case execution time The period at which the thread is dispatched and, once the dispatch occurs, the time by which the thread should complete.

31. 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.

32. 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