Presentation on theme: "IEEE Application Profile - Common Network Services - UML adaptation"— Presentation transcript:
1 IEEE 11073 20401 Application Profile - Common Network Services - UML adaptation Vivek Kamath, Jan Wittenber,
2 IEEE 11073-20401 Project (PAR) Scope: Within the framework of IEEE standards, this standard will define a common, transport neutral set of networking services that will enable plug-and-play interoperability of medical devices. This project shall not address quality of service over RF wireless network connections.
3 Define common set of networking services Transport Neutral Scope Summary:Define common set of networking servicesTransport NeutralEnable plug-and-playFor medical devices
4 Aspects of CNSDescribes topological framework to standardize network semantics for networked medical devicesEnables profiling of clinical scenarios from communication perspective.Defines Transport Independent System Layer (TISL) as a standard interface to upper layers
6 Clinical Scenarios - ENV 13735 Annex E 2.1 Communication RequirementsEmergency Situation – One of the main scenarios is alarm (2.1.1)Plug and Play - the device communication must start immediately after device connection without anyfurther user intervention. That implies e.g. automatic device recognition, identification, and initialization ofcommunication.Safety and reliability of communication and network - connection of a new device must not influencethe communication of other devices connected earlierUnique device identificationNormal patient nursing condition in ICU, non emergency situations (2.2)Same as above
7 Application Scenarios ENV 13735 Annex E 3 Communication RequirementsData Logger ( 3.1)Graphic parameter data volumes can require high bandwidth‘Loose’ device time stamp synchronization, in the order of 0.01 second, is required.Real Time Data Display (3.2)Latency of data between amplifier output and display on screen must be less than 0.2 seconds to be invisiblefor user.Patient Alarm Monitoring (3.3)The communication of alarm related information must be expedited, in order to be processed prior toother data, and must be reliable.Display Device must be able to detect when a Data Agent is removed. Ideally it should be able to distinguish between an intentional disconnection and unintentional disconnection.The latency of occurrence of alarm and signaling to user must be less than 0.25 seconds.
8 Application Scenarios Communication RequirementsRemote Control (3.4)In a remote control system, the communication must fulfill a higher level of reliability, because of a higherrisk for the patient. This includes the needs for comprehensive message validation, data verification, message retries, and notification of communication system failures. This implies the need for system managementfunctionality.A mechanism to send control data to the data agent and acknowledge receipt is required. In some casesmanual control of the device should be precluded.Patient Viewing Interoperability (3.5)There must be some level of control such that a remote user (i.e. outside the care unit) cannot change thesettings established by a nurse at the bedside.Harmonization of communication methods for RF telemetry systems would be required in order to supportinteroperable telemetry systems.Bandwidth management may become a big issue.The issue of managing multiple associations between a Data Agent and multiple Data Loggers or Data Dis -play needs attention.
9 ScenarioCommunication RequirementsPatient Monitoring Interoperability (3.6)Communication over different hospital LANs and maybe even on the Internet.Ordering of physiological data is important.Latency from Data Agent to Remote Monitoring Device must be controlled and specified. Generally, thisshould be less than one second to be acceptable.Maintenance and Configuration Support (3.8)Physical connect/disconnect sensing for devices.System management protocolIntrabed Symmetric Data Exchange between DCC and BCC (4.1)Interbed Symmetric Data Exchange over an "Interbed Network“ (4.2)Symmetry in communication between device (DCC) and BCCSymmetry in data propagation in through the BCC - from device (DCC) through BCC to Application Systemand vice versaPropagation of a containment tree of a remote device to the receiver (DCC)
10 Link Profile <type> Transport Stack ViewNote: this slide is adapted from the UML F&OUML F&O.ethernet11073“upper layers”Wi-FiCellular DataWi-Max802.310/100/1000BT802.11RFGPRSEDGE1xRTT4G /LTE802.16IPRTPTCPUDPSCTPIrLAPIRIrLMPTinyTPRS-232IP Support Services11073 config service11073 assoc serviceDHCPDNSNet. capacity serviceLDAPNTPRadiusLocation servicesPresence servicesSNMP802.1xNATUSBBlueToothPHDCMDPcurrentshort termpoint to point linkspossible futureIP centric linksetherclass drvprofileMICSWMTSZigBeeLink Profile<type>Link Profile <type>TISL <type>
11 Provides uniform interface to upper layers Has following services TISLProvides uniform interface to upper layersHas following servicesDiscovery of services and devicesConnectivityProvisioningSecurityQuality Of Service (QoS)
15 TISL connectivity primitives continued TISL_connectivity_sendTISL_connectivity_receiveTISL_connectivity_uninitPreferred transport based on underlying layer support.
16 TISL – Discovery of services and devices primitives TISL_discovery_initTISL_discovery_get_providersTISL_discovery_set_providerTISL_discovery_set_service_callbackTISL_discovery_set_device_callbackTISL_discovery_startTISL_discovery_cancelTISL_discovery_uninitPreferred provider SSDP
17 TISL provisioning primitives TISL_provisioning_initTISL_provisioning_get_providersTISL_provisioning_set_providerTISL_provisioning_add_itemTISL_provisioning_remove_itemTISL_provisioning_get_itemTISL_provisioning_uninitPreferred provider based on type of transport – can be DHCP, directory or some other mechanism
19 CNS UML modeling MDC CNS - UML The following set of diagrams show initial mapping/transformation of previous UML, as follows:MDC CNS - UMLTopological Framework and Overview.Application ProfilingTISL Profiling – Link-level Profile topologyTILS Profiling – PrimitivesHeuristics Profiles
20 MDC - UML- Topological Framework and Overview (F&O) The “CNS Framework” mapped to UML. The constructs at left are “Profile” [compositions], and the ones at top to the right, are ‘use cases’ (of composite Profiles); the lower set are MDS-level, and the upper set are composites. The initial’ exemplar Profiles are at lower left, e.g. Monitor, Infusor, and Ventilator in the Critical-Acute Care [Unit] scopes.
21 MDC CNS - UML- Application Profiling APPLication-level CNS Profiling characterizes the key semantics relative to the x73 “harmonization” definitions (see Wiki for Harmonization Framework documents).
22 MDC CNS - UML- TISL/Link-level component mapping topology Link-level Profiles are typed and related to a normalized set of TISL Primitives.
24 MDC CNS - UML- Heuristic Profiles This diagram will be used to overlay particular Profiles for heuristic purposes, generally trying to select Profile components to show typical variations in the highlighted topological scope. Link-level notations are productions of “[w][P/L]AN”, e.g. PAN, LAN, P/LAN, wPAN, wP/LAN, and wLAN. See shaded areas on the following diagram (F&O) for key heuristics, highlighting key variations.MgrAgent[s]AgentP/LAN[w]PLANwPAN_jw2a