5. MARCO REFERENCIAL
5.2 Estado del arte
In the following we will show, how the elements describe in the previous section com- ply with the levels of the conceptual interoperability model presented in section 2, mapping those elements to the particular levels and providing an overview on how these assets fulfil the special requirements of each level.
This model provides different requirements for different levels of interoperability, of- fering the possibility to classify the system. However, once passing the first level of simple connection of two systems, the assets required become a matter of documenta- tion, enabling the engineer to create interoperating systems. Figure 6 provides a map- ping of the assets identified to the levels of the model. We can see that none of the as- sets (symbolized by the blue ellipses) can be mapped to one single level. Further, the assets identified offer capabilities for reaching interoperability levels above the syntac- tic interoperability. This is due to the organizational nature of the identified assets, which focus more on common understanding, intra- and inter-team communication, rather than inter-system communication. However, the levels lower than the semantic interoperability must be ensured as well, since inter-system communication including state awareness and semantic translation, requires awareness of syntactic problems. Yet these assets contribute in creating interoperating systems while taking the special requirements of the public transport domain into account due to their origin of research projects in the domain of security in public transport.
Interoperability Concepts for Security Systems in Public Transport 107
Figure 6: Mapping of Elements to the Levels of the Conceptual Interoperability Model
The orange arrows, originating the identified assets point to the included parts and their categorisation inside the levels of the conceptual interoperability model. Hereby, dashed arrows point at derivable elements, which includes elements which are not con- tained at first hand inside the identified assets, but which can be derived. The mapping shows that the identified use cases and roles of the incident ground collaboration re- search can contribute by categorizing participating systems into roles, yet offering the possibility for further state awareness modelling depending on the role and by creating a context of the actions taken, depending on the use cases. Such contexts are important for further communication, since meanings can change depending on the situation, hence enabling semantic awareness between the systems.
The concepts of operations (CONOPs) offer a description of basic situation dependant actions and plans, as well as, legal requirements and rights for the units or organiza- tions at incident ground site. Since such CONOPs therefore offer a good description of the participants during an incident, they can be used as potential metadata, hence offer- ing description of the systems involved. Furthermore, the professional terms inside the concepts of operations enable a mapping of the meaning of the terms to the terms it- self, enabling further engineering for semantic interoperability between the systems. The systems’ description including the systems’ constraints and its legal issues, offer capabilities of pragmatic interoperability enabling other systems to which border this particular system can operate and what it cannot do.
108 Sebastian Kurowski, Jan Zibuschka, Heiko Roßnagel, Wolf Engelbach
The interfaces provided, describe basic requirements to the information needed. These requirements can be used to describe the information shared through this interface, thus describing the interface itself, creating context for the information shared. Further these descriptions include agreements of both exchanging parties, creating an over- view on the states of both parties during exchange and the constraints. Therefore, this particular asset was mapped to the fifth level of the levels of conceptual interoperabil- ity model.
Field Level Security Plans (FLSP) include the description of situations this particular plan is made for. These descriptions can again be used to create context between the stakeholders described in the plan. Since such plans include basic descriptions of ac- tions of the stakeholders during incidents, they basically describe collaboration and give insights in interoperability of units and potential interoperability of the systems included. Therefore, this description of scenarios creates a context of collaboration and its included communication aiding in creating semantic interoperability. Further the procedures included give an insight on what capabilities each stakeholder is able to contribute during collaboration, hence offering the description of the system-of-system actors’ capabilities and procedures. Further such procedures imply states of the actors during collaboration, allowing establishment of dynamic interoperability by deriving these states.
Finally the sensor system ontology contributes in establishing both pragmatic and se- mantic interoperability. The ontology regards both isolated use cases for using these systems, their capabilities due to the distinction between information and data deliver- ing systems and their adaptability effort, since specialization is implied by the included is-a relation between the systems. The use cases, such as in the FLSPs, create a context of usage, illustrating the context of communication and creating semantics in commu- nication. Information on adaptability and capability of the sensor systems, contribute to pragmatic interoperability, describing the systems capabilities and the possibilities of its usage.
7 Conclusion & Outlook
We identified multiple assets able to describe systems and their interoperation in the domain of security in public transport by analysis of related research work. We were able to show the specific details of the contribution by mapping these assets to the lev- els of the conceptual interoperability model. Since none of the research projects coped with interoperability itself these assets must be seen as building blocks for interopera- bility, offering capabilities to create context between systems and between the engi- neers. Therefore, these assets fully comply with the aspects of the presented levels by offering knowledge and information preservation and exchange capabilities. However, security in public transport is a domain with many facets, including endless possibili- ties of scenarios and usable systems. Concluding we can notice that these elements offer capabilities for information and knowledge preservation on the involved systems while establishing semantics between the systems. Therefore, tools can be derived for
Interoperability Concepts for Security Systems in Public Transport 109 enabling collaboration of systems and of engineers during creation of a system-of- systems architecture. The elements do not restrict the systems’ capabilities, but allow engineering of extended collaboration up to the systems’ awareness of other systems’ states. These assets will be further combined and derived, building the basis for an in- teroperability notation language in future research.
References
COPE. 2008. Use Case Descriptions and a Human Factors Engineering Framework. Deliverable. COPE. December.
———. 2009a. Comprehensive Model of First Responder Operations & Concept of Operations. De- liverable. COPE. May.
———. 2009b. HF-based Design Inputs to COPE Technology - Conceptual and Empirical Considera- tions of Common Operational Picture. Deliverable. COPE. November.
COUNTERACT. 2009a. Public Transport Security Planning - Organisation, Countermeasures & Op- eration Guidance - Part C: Systems and Equipment - Design Strategies and Considerations. Final Report. Counteract. March.
———. 2009b. Public Transport Security Planning - Organisation, Countermeasures & Operation Guidance - Part B: Security Operations Planning - Development of Operational Concept, Field Level Security Plans, Procedures and Training. Final Report. Counteract. March.
Dantas, A., and E. Seville. “Organisational Issues in Implementing an Information Sharing Frame- work: Lessons from the Matata Flooding Events in New Zealand.”
DEMASST. 2009. Current technological solutions and relevant research. Deliverable. DEMASST. September.
———. 2010. Report on Potential Integrated Solutions. Deliverable. DEMASST. February.
Engelbach, W., S. Frings, H. Roßnagel, and J. Zibuschka. 2010. Peer-to-peer Integration of Security- oriented IT -Systems in Public Urban Transport. In Proceedings of the 5th Security Research Conference, 2010. Berlin, September.
Engelbach, W., H. Roßnagel, and S. Frings. 2010. Ein Konzept zur organisationsübergreifenden Integ- ration von IT-Systemen für die zivile Sicherheit. In Software Engineering 2010 - Workshop- band, 379-386. Bonn: Köllen Druck + Verlag GmbH, February.
Eriksson, W. 2009. System-of-Systems Demonstration & Experimentation for Mass Transport Secu- rity presented at the Workshop to discuss the scope of Call for Demonstration Project Security of Mass Transportation (Phase 2), March, Berlin. http://www.bmbf.de/pubRD/WS_MT_Eriksson.pdf.
Hollnagel, E. 2002. “Cognition as control: A pragmatic approach to the modelling of joint cognitive systems.” IEEE Transactions on Systems, Man and Cybernetics (November).
InteGRail. 2010. InteGRail - Intelligent Integration of Railway Systems. Final Report. InteGRail. April.
ISO. 2010. ISO/IEC 2382-1:1993 Information technology - Vocabulary - Part 1: Fundamental terms. June.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=7229. MODSafe. 2011. Description of the project. MODSafe. July. http://www.modsafe.eu/programm.html. MODURBAN. 2008. Functional Interfaces specification for Passenger Information System. Deliver-
able. MODURBAN. May.
———. 2009. MODURBAN Architecture, Description of alternatives, for publication. Summary. MODURBAN. May.
NewRail. 2011. SECUREMETRO - Inherently secure blast resistant and fire safe metro vehicles. July. http://securemetro.inrets.fr/.
PROTECTRAIL. 2011. PROTECTRAIL - The Railway-Industry Partnership for Integrated Security of Rail Transport. (...). July. http://protectrail.eu/.
110 Sebastian Kurowski, Jan Zibuschka, Heiko Roßnagel, Wolf Engelbach
Roßnagel, H., and O. Junker. 2010. Evaluation of a Mobile Emergency Management System: A Simu- lation Approach. In Proceedings of the 7th International Conference on Information Systems for Crisis Response and Management (ISCRAM 2010). May.
Roßnagel, H., and J. Zibuschka. 2011. Using mobile social media for emergency management: a de- sign science approach. In Proceedings of the 8th International ISCRAM Conference. Lisbon, Portugal.
Roßnagel, H., J. Zibuschka, and O. Junker. 2010. “Agent-Based Simulation for Evaluation of a Mobile Emergency Management System.” Sustainable e-Business Management: 100–114.
———. 2011. On the effectiveness of mobile service notifications for passenger egress during large public events. In Proceedings of the 8th International ISCRAM Conference. Lisbon, Portugal. Turnitsa, C.D. 2005. Extending the Levels of Conceptual Interoperability Model. In Proceedings IEEE
Summer Computer Simulation Conference. CS Press.
Wang, W.G., A. Tolk, and W.P. Wang. 2009. The Levels of Conceptual Interoperability Model: Ap- plying systems Engineering Principles to M&S. In SpringSim’09 Proceedings. San Diego, CA, USA: SCS.