## 5 Conclusions and Future Work  
The presented medical approaches currently are based on SDC networks in the OR. Nevertheless, today, there only exist demonstrators [65] for SDC connected devices. Although we focused on SOA features, there are some measures which are not directly restricted to SOA networks, e.g., the context plausibility check. Therefore, also, current OR integration software could apply these measures as they integrate different devices with a central integration platform. Thus, it is also possible to create a context of the whole OR and analyze the different device states as well as the payload.  
In vehicles, the SOA paradigm is currently being introduced, making SOA IDS functionality increasingly relevant. The paper includes initial contributions toward an IDS based on SOME/IP and DDS protocol patterns. Compared to signal-based vehicle communication, IDS features for SOAs can no longer be derived exclusively based on the statically defined communication specification. Furthermore, an analysis of normal behavior during the runtime should also be performed to extract specific communication patterns. Context information should also be taken into account, for example, whether a specific function (e.g., ACC) is active, since the context has an impact on the corresponding communication behavior.  
We do not focus on improving algorithms for IDSs such as the related works mentioned earlier but motivate a technology-independent and cross-domain architecture for IDSs. Moreover, our approach focuses more on the relationships between different services through their pattern type and overall context. The prototype presented in Section 4 also shows that security for the HOR can already be improved with the measures demonstrated.  
Based on our presented assumptions, a prototypical implementation in Section 4 and proof of concept needs to be extended. One approach is to implement the presented OR use case within a simulated network based on available SDC libraries, such as OpenSDC [66]. In addition, more devices and examples need to be implemented for the remaining patterns.  
As we discussed only the detection of intrusions, it needs to be evaluated which measures should be applied. Being very conservative and accepting false positives to detect all true positives leads to a reduced availability of systems and might be even worse than the actual attack. In addition, too many false alarms can lead to alarm fatigue, causing important alarms to be missed, as [PERSON] et al. [67] estimate that 72 to 99% are already false alarms. Thus, false alarms have to be considered, e.g., by the work of [PERSON] et al. [53] to be reduced in real applications.  
Transferred to the automotive domain, a prototypical implementation should also be carried out here to examine the patterns more closely. An important object of future investigation is the extraction of IDS features based on the normal SOA network behavior by using different techniques (e.g., Artificial Intelligence (AI)-based). One possible way to achieve the complete coverage of an entire system might be the use of a digital twin [68] of the devices including their SOA communication behavior, which is becoming increasingly important in the automotive domain.  
Conceptualization, A.P., M.R. and D.G.; software, A.P.; writing--original draft preparation, A.P., M.R. and D.G.; writing--review and editing, A.P., M.R., D.G. and E.S.; Supervision, E.S. All authors have read and agreed to the published version of the manuscript.  
This research was funded by KIT-Publication Fund of the Karlsruhe Institute of Technology grant number 2447.  
We acknowledge support by the KIT-Publication Fund of the Karlsruhe Institute of Technology.  
The authors declare no conflict of interest.