## 2 Background and Related Work
### Medical  
In the medical field, the architecture comprises a large variety of self-contained devices that may be required in a surgical setting. In Figure 1, an example is depicted, which represents a use case for the OR. It is based on the concept of an Hybrid Operating Room (HOR) [19], which is already a state-of-the-art application based on proprietary protocols and signal-based communication. The aim of the HOR is to enable imaging techniques during a surgery in a single OR. Therefore, the angiography system, a C-shaped device for interoperative imaging with X-ray technology (Figure 1), requests information from the Operating Room Table (OR table) (e.g., joint positions) via an external interface to move around the patient without collision. In [21], this scenario is also transferred to a service-oriented approach. The OR table can act as a service provider that can be moved in different directions, or an angiography system can provide a service that delivers X-ray images of the patient. Figure 2 depicts the service-oriented communication of an angiography system with an OR table. Here, the angiography system uses the provided interface of the OR table to determine the current position of the OR table via the service _GetPosition_ or to move the OR table into a desired position via the service _Move_. Thus, the angiography system acts as a service consumer, while the OR table represents the service provider. There also have been several efforts by different medical device manufacturers to create a platform to support the interoperability of medical devices within the OR: [PERSON] (OR1 tm), Stryker (i-SuiteTM), Getinge (TegrisTM), Olympus (EndoALPHATM), BrainLab (BrainsuiteTM) and [PERSON] (core novaTM). However, because these solutions are not based on open standards, the security measures and network protocols are proprietary. As stated in Section 1, _security by obscurity_ does not provide any relevant security value. Therefore, manufacturers cannot be accused of not securing their systems sufficiently. Rather, the cooperation of multiple manufacturers is necessary to ensure the secure and safe communication of all medical devices in the OR. Figure 1: Image guided surgery in the HOR [20]. Figure 2: Example for service provider and consumer in the HOR (right picture inspired by [22], left picture from [23]). Promising standards to enable interoperability for medical devices in the OR based on SOA have been started in the last two decades and are still ongoing:  
**Medical Device Plug and Play (MDPnP):** The MDPnP program is developing integrated clinical systems and began as an offshoot of the _operating room of the future_ at Massachusetts General Hospital. It was launched as an ORF-PnP initiative based on a symposium held back in May 2004 at CIMIT in Cambridge, MA [24]. With the MDPnP program, the ASTM F2761 Integrated Clinical Environment (ICE) standard [25] has been developed. Furthermore, with OpenICE, an open source reference implementation of this standard is available also relying on DDS (see Section 2.3) as middleware [26]. **Service-oriented Device Connectivity (SDC):** Since 2012, the German association OR-NET has been working on the ISO/IEEE 11073 family of communication standards to realize open integration in the OR of the future [27]. In contrast to other similar international aspirations, it already reached the level of a technical specification and standard [28]. The SDC standard is based on Devices Profile for Web Services (DPWS) and uses Hypertext Transfer Protocol (HTTP)/Hypertext Transfer Protocol Secure (HTTPS), Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). As it has further extensions for the medical field, it is called a Medical DPWS (MDPWS), which is described in the IEEE 11073-20702 standard [29].