POSTER 2016, PRAGUE MAY 24 1

Time Synchronization of Vital Signs in an InterconnectedOperating Room using Devices of Different

Manufacturers

Marian OHLIGS1

1Section Medical Technology, Clinic for Anesthesiology, Uniklinik RWTH Aachen, Pauwelstrasse 30, 52074 Aachen,Germany

mohligs@ukaachen.de

Abstract. In order to meet the growing number of medicaldevices, without having to switch to proprietary integratedsystems in operating rooms, an open standard for network-ing medical devices is being developed within the researchproject OR.NET. With intent to reduce costs, the OR.NET ar-chitecture is built on top of standard network componentsand protocols. In order to reduce the demand of real-timesubnetworks, this paper analyzes the possibilities of synchro-nizing vital signs. The vital signs are communicated usingthe OR.NET architecture. Deadline problems are solved bybypassing Carrier Sense Multiple Access/Collision Detec-tion. Furthermore, the research describes opportunities inthe case of the exchange and synchronizing of vital signs withtime dependence, using software-based methods.

The results point to significant hardware and software de-pendencies. Nevertheless, they show which restrictions andadditions must be taken into account for the application it-self to have an evaluable risk in a medical context.

Keywordsreal-time, synchronization, OR.NET, surgery, OpenSurgical Communication Protocol, network prioritiza-tion, Precision Time Protocol

1. IntroductionIn recent years, the number of medical devices in op-

erating rooms has massively scaled up. Unfortunately, mostof the devices operate without interconnection or the use ofproprietary standards. This forces new innovative devices tooperate on their own and often using individual concepts fordevice operation.

The OR.NET research project aims to develop man-ufacturer independent standards for device interconnec-tion combined with strategies for Man-Machine-Interaction(MMI) and safety concepts. Therefore, the developed archi-tecture allows a manufacturer independent interconnection

using cost-effective standard components without the needto use real-time connections. In order to match real-time cri-teria, e.g. controlling milling robots or tracking systems, adedicated real-time network can be used [1].

Fig. 1. Current operating room situation [2].

To reduce the demand of real-time communication dur-ing the process of exchanging and synchronizing standardvital signs, a software-based method was developed. Themethod is based on the PTPdaemon (PTPd) which itselfuses the IEEE 1588 for synchronizing system clocks [3].As protocol, the Open Surgical Communication Protocol(OSCP) is used which is currently developed in the OR.NETproject. The OSCP takes care of information accuracy in-side operating room networks. For validation of the exten-sion to the OSCP protocol an Electrocardiography- (ECG)and Photoplethysmograph- (PPG) signal will be used to an-alyze synchronism. Furthermore, this work focuses on theanalysis of VLAN and prioritization techniques, hence thevalidity of the OSCP protocol itself has been already ap-proved [4]. These three major procedures are introduced inthe following. The ECG and PPG signals as well as the aimto synchronize the vital signs with a difference of less thanone microsecond, have been chosen in context of multimodalpain/stress analysis [5].

2 M. OHLIGS, TIME SYNCHRONIZATION OF VITAL SIGNS IN AN INTERCONNECTED OPERATING ROOM

Open Surgical Communication Protocol

The OSCP is an upcoming standard for the secure ex-change of medical information. It is based on the DeviceProfile for Web Services (DPWS) standard [6], which en-sures that each device is able to communicate using standardweb-services. In order to provide hot plug & play as wellas device interoperability, the devices are able to exchangetheir Medical Data Information Base (MDIB). Finally, datasuch as vital signs and alarms can be exchanged using sim-ple get/set operations. Furthermore, it should be mentionedthat the OSCP forces no master device, eliminating the sin-gle point of failure problem [5].

Packet Prioritization

Methods for prioritizing Internet Protocol (IP) -packetsare described in the IEEE 802.1Q. More precisely, the stan-dard defines two sub-standards, which differ mainly in theISO/OSI layer. In order to archive maximum control in stan-dard Ethernet communication, the already established IEEE802.1Q/p technique is chosen which injects priority infor-mation on data link layer level featured by an IEEE 802.3Tagged MAC Frame [7]. Another advantage is the fasterevaluation time inside the network switches or routers whichcan dispense with the extraction of one layer [8].

Precision Time Protocol daemon

The Precision Time Protocol daemon (PTPd) is an im-plementation of the IEEE 1588 Protocol. Featuring a puresoftware architecture without the need for special hardware,the daemon was developed by two engineer students of CaseWestern Reserve University.

Fig. 2. Diagram of the PTPd clock servo based on [3].

In summary the block diagram in Figure 2 shows thePTPd’s clock servo. Master-to-slave and slave-to-master de-lay are calculated evaluating the information of synchroniza-tion packets which are sent in an fixed interval. This piecesof information are passed according to the diagram into threefilters. The Low-Pass Infinte Impulse Response (LP IIR)Filter stabilizes the controller when the network topology is

changed. High frequency noise inside the delay differenceswill be canceled by a Low-Pass Finite Impulse Response (LPFIR) Filter. Finally the PI-controller corrects the clock’s timeand rate [3].

Timing in Operating Systems

Common Linux or Windows operating systems have atleast two separated levels of authority: user space and ker-nel space. Triggering a syscall, the context can be switchedbetween both levels. When a network packet is receivedon the network interface card (NIC) without Direct MemoryAccess- (DMA) controller, normally an interrupt reactivatesthe kernel task which subsequently copys the packet into abuffer. Later on the corresponding user space task is able tofetch the packet using the specific syscall [9]. This leads todelays which are heavily based on the system workload andarchitecture. In fact, the time is already tagged by the ker-nel, but subsequently dropped. The PTPd implementationis shipped with the possibility to use this information whenactivated in the driver [3].

Furthermore, Linux provides the algorithm with pos-sibilities to directly modify the system time and rate whenadministrator privileges are in place. This functionality wasadded to the Windows implementation of PTPd. Unfortu-nately, the implementation is partially imprecise regardingtiming analysis. Running a master daemon, which needsprecise packet arrival time information, could be archivedby including WinPcap driver [10]. Besides that, Windowsprohibits modifications of the High Precision Event Timer,which forced the implementation to deal with the normalwindows timer. In tests the timing jitters of 15 microsecondsprevented the PTPd from functioning.

2. Materials and MethodsFor measurement of the patient-monitor signal duration

of PPG and ECG, a pcDuino board is selected. Equippedwith self-manufactured hardware for emitting simulatedECG and PPG signals, the board has enough power to trig-ger a signal, receive the patient-monitor response and de-tect the artifact after extracting the protocol specific packet.As patient-monitor the Philips MP70 (Philips, Einthoven,Netherlands) and a Dreager Infinity (Draeger, Luebeck, Ger-many) have been chosen to ensure interconnectivity betweendevices from different manufacturers. Next, all of the de-vices in Table 1 were selected with the exception of thepcDuino to investigate hardware and software impact ontime synchronization. As network infrastructure, the SwitchGS-1224 and the Router 1780EW-3G (LANCOM, Aachen,Germany) were selected. A standard Intel Core i7 PC(Dell, Round Rock, USA) with activated High PerformanceEvent Timer (HPET) was used to synchronize the timestamptagged vital signs, additionally acting as PTPd master.

POSTER 2016, PRAGUE MAY 24 3

Device Processor Ethernet

pcDuino 1GHz ARM Cortex-A7 2-core 10/100MBit

Raspberry Pi 1 700Mhz ARMv6 10/100MBit

Raspberry Pi 2 900Mhz ARM Cortex-A7 4-core 10/100MBit

AN2580-9B70 1Ghz Intel Cedarview-M N2600 1000MBit

Beaglebone Black 1Ghz ARM Cortex-A8 10/100MBit

Tab. 1. Chosen devices for measuring time synchronization.

Central part of the described scenario is the connectorsoftware architecture. Featuring precise timestamping, theprogram has to communicate with the proprietary patient-monitors. Moreover, it must convert all data into the OSCPand should auto detect vital artifacts inside the reliably ex-tracted patient-monitor data. Without critically influenc-ing the receiving and converting, the connector has to savethese results as well as additional diagnostic time measure-ments. For better comparability between tests on Windowsand Linux platforms, coding was done in C++11, featur-ing common functions for time measurements and thread-ing. Of course these functions are implemented differently inthe linked runtime libraries, but the major part of the sourcecan be used regardless of the underlying operating system.The system independent design, which also includes a cleardefined code style guideline, should aid in the reduction offailures if the code is adjusted quickly. Furthermore, newC++11 features enables the author to make use of smartpointers, remaining fast but secure. Additional features areunrestricted unions for optimized memory usage in queueswith C++ standard library objects.

OSCPpatientmonitor

recvthread

OSCthread

unique pointershared pointer

exchange object

VSI

VSIVSI

VSIVSI

VSI queue

Fig. 3. Basic overview of the connector architecture.

Figure 3 shows a basic overview of the connector ar-chitecture, with proprietary data arriving from the patient-monitor being converted to the OSCP. On Linux systems ar-rival time is tagged directly in kernel space. The receive-thread handles all patient-monitor packet handling and ex-traction. Notable vital information is converted into smallVital Sign Information (VSI) segments. Theses segmentsare just linked into an exchange queue, to avoid memory

allocation delay jitter. Then, VSIs are pulled by the OSC-thread. Finally, the OSC-thread uses an implementation ofthe OSCP, the OSCLib (SURGITAIX, Aachen, Germany).A Queue pattern was chosen to avoid locking methods. Inany case a thread has to wait when the queue is full or empty.Consequently, the corresponding thread triggers a resched-ule to reduce load when possible.

Benchmarking is done by netio and by compiling theLinux kernel. Netio is a tiny network benchmarking tooldeveloped by Kai Uwe Rommel which exchanges a hugenumber of packets of differing sizes to measure the actualthroughput [11]. The Test also disclosed, that a Raspberry Piis not able to reach the declared 100MBit, which ostensiblyrelies on the PIs network interface internally connected viaUSB. For generating massive unsteady workload on CPU,memory and filesystem, a Linux kernel is compiled with pa-rameter -g for parallelization.

Prioritization is done by using the 802.1p standard. Alldevices are updated with drivers enabling support for IEEE802.3 tagged MAC Frames.

However, if possible, all systems are configured to useits high performance timer. The time offsets are calculatedautomatically and saved after finishing the measurement. InFigure 4, 5, 6 and 7 the quantity of the master-to-slave offsetwere plotted. The results of Figure 8 and 9 are calculated byEquation 1 and 2. dn is the master-to-slave delay and tn thetime measured for initializing the simulation of one signal. ddeclares the median of the master-to-slave delay subtractedby the signal initialization duration.

d =

{d(n+1

2 ) − t(n+12 ) n odd

12 (dn

2+ d(n

2 +1))− 12 (tn

2+ t(n

2 +1)) n even.(1)

y(x) = dx − d (2)

3. ResultsThe first test was done by analyzing the synchroniza-

tion precision of the PTPd. Figure 4 shows the differ-ence between time synchronization based on kernel spacetagged timestamps versus user space tagged ones. Un-derstandably, when increasing CPU workload, delay wors-ened. A kernel space tagged synchronization had a maxi-mum delay of xmax=0,022ms, which increased under heavyCPU load up to xmax=0,160ms. In contrast, the user spacesynchronization has a maximum size without CPU load ofxmax=3,99ms. One microsecond of synchronization differ-ence should be archived. As a consequence, in the followingall measurements are done with kernel spaced synchroniza-tion.

4 M. OHLIGS, TIME SYNCHRONIZATION OF VITAL SIGNS IN AN INTERCONNECTED OPERATING ROOM

100 150 200 250 300 3500

0.5

1

1.5

1

time [s]

mas

ter-

to-s

lave

offs

et[m

s] kernel spaceuser space

Fig. 4. Time synchronization with kernel vs. users space taggedtimestamps.

Although relevant CPU workload impact can be pre-vented by using kernel timestamps, this does not apply inthe case of heavy network load. Interestingly, that problemcannot be solved by prioritizing the synchronization packetsas seen in Figure 5. Another result, presented in Figure 5,shows no impact of network contention, when one single de-vice is running a network benchmark with one device and aprioritized time synchronization with another one, using thesame network and NIC.

0 20 40 60 80 1000

2

4

6

8

1

time [s]

mas

ter-

to-s

lave

offs

et[m

s] with prioritization

without prioritization

different recipients

Fig. 5. Master-to-slave offset with and without prioritizing timesynchronization packets while benchmarking the net-work. The third line is measured when time synchro-nization and benchmarking is done form one device totwo different ones.

Another aspect is the hardware dependence and thelong-time reliability of time synchronization. Therefore,many device combinations were tested in this study. Oneresult was a minor influence on synchronization precisionwhen using different speed of hard disc drives. Furthermore,a long-time measurement of an Intel Atom (N2600) and aRaspberry Pi shows a sudden worsening after two hours. Bycontrast with the Intel Atom the Raspberry Pi is steady buthas some irregular distortions as seen in Figure 6.

Analyzing the connector architecture exposes a signifi-cant problem when transmitting the information over OSCP.

5 10 150

1

2

3

4

1

time [103s]

mas

ter-

to-s

lave

offs

et[m

s] Dual-Core Atom

Raspberry Pi

Fig. 6. Master-to-slave delay over a long period of time.

As shown in Figure 7, the time which was used by theOSCLib to convert and send 200 double values in one steptakes more than 30 ms. By adding further receivers, the de-lay time nearby doubles in size. Nevertheless, the libraryshows irregular peaks. In comparison the receive routineonly requires 2ms (Draeger Infinity) or 7ms (Philips MP70)extracting a message filled with more then 2000 double val-ues.

0 500 1,000 1,500 2,0000

100

200

300

array interval [1]

send

ing

time

[ms]

Fig. 7. Time delay of the OSCLib to convert and send 200 dou-ble values with OSCP.

The signal generator was programmed as standaloneArduino program, which was triggered in a fixed loopinginterval. Two further problems were discovered when mea-suring different isolated parts. The initialization time of thestandalone program had a jitter up to 8ms. Therefore, thedelay time was tagged additionally. Furthermore, the NICof the pcDuino showed delays twice the level compared toa Beaglebone Black when answering simple ping packets aswell as sudden 8ms delays which could not be found on aBeaglebone Black.

Keeping this in mind, the offset of a simulated sig-nal measured and processed by the patient-monitor untilreceived by the connector was measured. Therefore, anECG signal is generated in a fixed period of time andauto-detected by the connector. Subtracting the addition-ally tagged initialization time of the Arduino simulation pro-

POSTER 2016, PRAGUE MAY 24 5

gram, the result for the Draeger Infinity was logged, asshown in Figure 8. (Philips MP70, Figure 9)

0 20 40 60 80 100

−10

−5

0

5

0

time [5s]

Var

ianc

eof

the

med

ian

[ms]

Fig. 8. Variance of the median calculated from the duration ofECG signal generation up to the point of auto detectionusing the Draeger Infinity as patient-monitor device

0 50 100 150 200 250

−1000

0

1000

0

time [5s]

Var

ianc

eof

the

med

ian

[ms]

Fig. 9. Variance of the median calculated from the duration ofECG signal generation up to the point of auto detectionusing the Philips MP70 as patient-monitor device

4. DiscussionStarting with the last presented results, measuring the

Draeger Infinity patient-monitor ECG signal timing, sud-den peaks of 9 to 10ms were detected, shown in Figure 8.These peaks are caused by the pcDuino NIC as detected ina test measuring the duration of simple ping packets. Com-bined with the problem that the embedded system has un-predictable test initializing times, future tests should be doneusing another board with a more steady packet receiving de-lay and an operating system or testing program which is ableto simulate a signal in less than one millisecond.

Transmission delays when receiving, extracting andconverting the vital signs, revealed no critical delays exceptthe fact, that additional receivers will harmfully slow downnetwork connection. It is only possible to exchange a limited

number of real-time streams. It should be mentioned that theOSCLib used to convert vital signs streams into OSCP is indevelopment state. Nevertheless, scaling problems shouldbe addressed by using multicasts. This feature is not imple-mented in the OSCLib version used in this work.

The third sub-problem is the time synchronization.Evaluation indicates that the synchronization can be donethrough standard Ethernet but furthermore demonstratesstrange delays when transferring packets, as well as con-siderable dropouts on some systems after a longer period oftime. The total dropouts show the necessity of testing allhardware devices individually. Furthermore, power savingfeatures should be studied in more detail. Interestingly, thedelays caused by the network benchmark only occur whenbenchmark and time synchronization in a prioritized virtualsubnetwork are using the same master and slave device. Byusing, different NICs and networks this may lead to the pointthat an internal network buffer be used for all subnetworksaddressing the same endpoint device. Another indicator forthe presumption is a steady delay of all prioritized packetsin the order of 8ms during the benchmark. A solution couldresult in a kernel driver which handles entire time synchro-nization and performs filtering and responding to packets inits own network directly. Another possibility in favor of val-idation is to use a real-time subsystem like xenomai [12].Nevertheless, all solutions can assume a real-time Ethernetprotocol like Ethernet Powerlink (EPL). However, this canlead to a single cable solution when only using the real-timelayer for time synchronization, having a maximum of asyn-chronous data slots for regular OSCP messages.

5. ConclusionFinally, the author concludes that it is basically possi-

ble to synchronize vital signs, featuring a precision of 1msover standard Ethernet. As an outlook, two cases should bementioned here:

The first use-case is to display the information from dif-fering devices synchronously on a central workstation. Onthe one hand the vital signs have to be transmitted with min-imal time delay, on the other hand this case does not requirea synchronization precision less than one second.

In the second use-case the information is used for deci-sion support systems which use data from different medicaldevices. This would require a high synchronization preci-sion, for example in ECG and PPG based heart rate vari-ability analysis for pain/stress detection [13]. Nevertheless,the need for minimal delay is less critical, compared to firstuse-case.

In future, it will become possible to eliminate networkimpact, using a specific kernel module for time synchroniza-tion. Then, the adoption and synchronization of vital signsgenerated by different medical devices may be realized with-out the help of a real-time layer.

6 M. OHLIGS, TIME SYNCHRONIZATION OF VITAL SIGNS IN AN INTERCONNECTED OPERATING ROOM

AcknowledgementsThe work in this paper was derived from the results of

the author’s master thesis and was supervised by Prof. Dr.-Ing. Dr. med Steffen Leonhardt, Chair of Medical Informa-tion Technology of the RWTH Aachen University.

The author would like to thank Priv.-Doz. Dr. med.Michael Czaplik and Dr.-Ing. Marcus Koeny for their scien-tific input in this study.

This work is part of the OR.NET project, which isfunded by the German Federal Ministry of Education andResearch (BMBF).

References[1] PFEIFFER, J., DINGIER, M., DIETZ, C., LUETH, T.C., Require-

ments and architecture design for open real-time communication inthe operating room, 2015 IEEE International Conference on Roboticsand Biomimetics (ROBIO), IEEE, 2015 pp. 458–463.

[2] KONY, M., BENZKO, J., CZAPLIK, M., MARSCHOLLEK, B.,WALTER, M., ROSSAINT, R., RADERMACHER, K., LEON-HARDT, S., The smart operating room: smartor, Distributed Net-works: Intelligence, Security, and Applications, 2013, p. 289.

[3] CORRELL, K., BARENDT, N., BRANICKY, M., Design consider-ations for software only implementations of the ieee 1588 precisiontime protocol, Conference on IEEE, vol. 1588, 2005 pp. 11–15.

[4] KASPARICK, M., SCHLICHTING, S., GOLATOWSKI, F., TIM-MERMANN, D., New IEEE 11073 standards for interoperable, net-worked point-of-care medical devices, Engineering in Medicine andBiology Society (EMBC), 2015 37th Annual International Conferenceof the IEEE, IEEE, 2015 pp. 1721–1724.

[5] KONY, M., Entscheidungsunterstutzungssysteme fur denanasthesiologischen Arbeitsplatz der Zukunft auf Basis vernet-zter Medizingerate, Shaker Verlag, Aachen, 2015.

[6] ANDERSEN, B., ULRICH, H., KOCK, A.K., WRAGE, J.H., IN-GENERF, J., Semantic interoperability in the OR. NET project onnetworking of medical devices and information systems? A re-quirements analysis, Biomedical and Health Informatics (BHI), 2014IEEE-EMBS International Conference on, IEEE, 2014 pp. 428–431.

[7] FOLLOWS, J., STRAETEN, D., Application-Driven Networking:Class of Service in IP, Ethernet and ATM Networks, IBM Corpora-tion, 1999.

[8] POSTEL, J., et al., Rfc 791: Internet protocol, 1981.[9] TANENBAUM, A.S., Moderne Betriebssysteme, Pearson Deutsch-

land GmbH, 2009.[10] LU, X., SUN, W., LI, H., Design and research based on winpcap net-

work protocol analysis system, Computer, Mechatronics, Control andElectronic Engineering (CMCE), 2010 International Conference on,vol. 1, IEEE, 2010 pp. 486–488.

[11] ROMMEL, K.U., Netio-network benchmark, version 1.26,http://www.ars.de/ars/ars.nsf/docs/netio, 2012, [Online; zuletztbesucht 23.03.2015].

[12] BROWN, J.H., MARTIN, B., How fast is fast enough? Choosingbetween Xenomai and Linux for real-time applications, proc. of the12th Real-Time Linux Workshop, 2010 pp. 1–17.

[13] KONY, M., YU, X., CZAPLIK, M., Computing the Analgesia Noci-ception Index Based in PPG Signal Analysis, POSTER 2013 / CzechTechnical University, Prague, 2013 .

About Authors. . .Marian OHLIGS was

born in Aachen, Germanyand received the B.Sc. fromRWTH Aachen University,Aachen, Germany in 2013.Initially specializing in Com-puter Engineering, he changedto the field of BiomedicalEngineering in which heearned is Master’s degree.He is currently a researchassociate and Ph.D. student at

the Section Medical Technology, Clinic for Anesthesiologyat Uniklinik RWTH Aachen. His primary fields of researchare decision support, telemedical methods, and networkedsystems in anesthesiology.