Event model. Figure 8 - Events dispatched and consumed by the EventProcessor Interface Owing to the dynamic nature of the Train Management Systems that ON-TIME will need to interface to, the architecture will provide a middleware responsible for the col- lection, dispatch and classification of events. Every event is composed by a payload, defined in XML (using RailML or a custom rep- resentation, backed-up by a proper XSD schema) and a series of attributes that helps the infrastructure and the consumers to quickly understand the nature and the domain of the information. The classification of events allows event consumers to subscribe to specific class of events only, easing network loads and simplifying the integration patterns. An event will be composed of the following attributes: • Id: Unique Id of the Event • TypeId: Unique Id that will classify the event • SenderId: Unique Id of the sender of the message. Useful for routing and secu- rity • Version: Version number of the event • Name: Human-Readable name of the event • Timestamp: the event timestamp • XmlPayload: and XSD-backed XML fragment that does describe the event and contains information. Note: to ease extensibility, the architecture will manage events in an agnostic way. Specifically, the contents of the events will not be considered as part of the routing task, instead classified will be based purely on TypeId and Version. For a detailed data dictionary of the event model and RailML, please refer to D7.1 - Li- brary of Data and Communication Models.
Event model. The “event” entity in 4SECURail will describe a cyber-security incident, threat, vulnerability or risk, and will be used as the information unit to be shared with other organisations for intelligence purposes. This event model will therefore be flexible to admit a large variety of fields for supporting security teams to identify the different events that they might face.
Event model. This section of the data model describes the modeling of the events inside the HUMAN system. The events stored inside this part of the data model are the low frequency data and commands which are used in the system. Examples of low frequency data are the request for intervention made by the Intervention Manager, the outputs of the Short Term Reasoning Engine and of the Long Term Reasoning Engine when a deviation is detected, updates regarding advancements in the task execution, start / end of a working shift. As a disambiguation note, the modeling of the event is not intended to replicate the Message Schema used to exchange data through the Middleware nor to store all the exchanged data on the middleware. It is important to note that the events that are saved are the low frequency, meaning that data coming from the sensors are not stored in this way.
Event model. According to the [MISP data standard], an event is a simple meta structure scheme where attributes and meta-data are embedded to compose a coherent set of indicators. An event can be composed from an incident, a security analysis report or a specific threat actor analysis. The event model is therefore flexible to admit a large variety of fields for supporting security teams to identify the different events that they might face. The meaning of an event only depends of the information embedded in the event. The following sections summarise the data model used in 4SECURAIL. The information about the data model used is detailed at the MISP standard website (xxxxx://xxx.xxxx-xxxxxxxx.xxx/).
