single events towel disappeared on instrument table and towel
appeared on operation table to a complex event towel in use.
Figure 115 : Interactions MUNICH platform.5.6.4.10 MUNICH platform - conclusion
The previous sections have shown that an existing system can be reverse
engineered by applying the IoT ARM. Beginning from an existing system the
modelling of the IoT Domain Model and Information Model has been
demonstrated. With the help of these models the respective IoT Service
Descriptions have been derived and the interactions between the Resources
have been specified. The exercise did not include all the steps of the process to
derive a concrete architecture based on the IoT ARM. There was neither a
requirements analysis nor a security risk analysis undertaken. The purpose of
this exercise is to demonstrate the usage of the models in first place. Since the
functionality of the system has not changed a comprehensive requirements
analysis has been skipped. Also the security risks are seen as manageable
since the operating theatre is a well-secured and closed environment anyways.
Only the event related service makes connections to external environments, but
that was the case for the original system already and therefore no changes in
security risks are expected. Particular platforms and solutions to implement the
use case are not recommended here; technologies that would be suggested in
this document might be out-dated by the time of reading this document and
therefore obsolete.
5.6.5 Conclusions about « Reverse Mapping »
In this Section we have provided a reverse mapping of the IoT Architectural
Reference Model with several standards from the field of IoT as well as a
concrete architecture in order to provide an architectural validation, namely
whether it is possible to map existing standards to the IoT ARM. If this was not
possible, then the validity of the ARM itself would be questionable.