Principles of SIM4AT

SIM4AT is a simulation platform aiming at the replacement of both the rule engine and the operator works in the project I2C. For this, it also requires to simulate the data sources for the rule engine. SIMAT is designed to test anomaly detection of a surveillance system, so the definitions of the different components and structures are kept as simple as needed in regard to this.

Thus first step is to design the information that feeds the rule engine in order to

Time 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Sc1 – – E1 – eE1 – – – – – – – – –

Sc2 E1,E2 – eE1 – – eE2 – E3 – – eE3 – E4 eE4

Sc3 E1,E2 E3 – eE2 – – E2 – eE1,eE3 E4 – eE2 – eE4

Table 4.1: Scenario Examples (a).

implement it in SIM4AT. The platform aims at simulating the behaviours of entities in order to be analysed by MAS4AT. To achieve it, we have modelled scenarios to feed the rule engine simulator with. A scenario is a representation of an entity behaviour: it is a series of events occurring from time to time. This definition provides scenarios with simple structure but able to represent complex features. Moreover, it does not take into account the meaning of the events, neither the significance of a whole scenario.

Indeed, according to the chapter 3, MAS4AT only needs the identification of the events and of the entities in order to work. The significance behind the identifications are left for the operators when they analyse a situation. Therefore, the structure of our scenarios only uses these two parameters. The table 4.1 shows three different scenarios, one by line, Sc01, Sc02 and Sc03.

The first scenario, Sc01 is a very simple one where only one event, E1, happens at time step 03, before it disappears, eE1 with e for end, at time step 05. During the rest of the time, nothing else happens.

The second scenario, Sc02, is a little more complex because several events takes place into it, and sometimes at the same time, like the events E1 and E2 at the first step. Finally, the third scenario sees several appearances and disappearances of several events overlapping.

For example, the event E1 appears at time step 01 and disappears at time step 09 while the event E2 appears at step 07 and disappears at step 12.

In SIM4AT, the events and the scenarios are randomly created by the appropriate component, the scenarios generator. The duration of one time step is left to the user appreciation according to the domain. The events are also randomly generated, according to their definition in section 3.3.1.

It can be useful to feed the system with known scenarios in order to test specific cases in a specific context, or to serve as proof of concept. Regarding this need, SIM4AT can take user-generated scenarios using the same structure. The only need is for the user to identify the different events that are in its scenario.

For example, the table 4.2 shows two scenarios that are an adaptation of direct observation in maritime surveillance. In these scenarios:

3 The event E1 represents a stop in open sea.

3 The event E2 represents an engine failure.

Time 01 02 03 04 05 06 07 08 09 10

Ship1 – – E1,2 – – eE2 eE1 – – –

Ship2 E1,3 – eE3 – – – E4 – – –

Table 4.2: Scenario Examples (b).

3 The event E3 represents a proximity with an unknown ship.

3 The event E4 represents the disappearance of the radar track of a ship.

3 The interval between two time step is of 30 minutes.

Concerning the ship ship1, the scenario indicates a stop in open sea, apparently for engine failure. When the engine failure is fixed, the ship can start again and continue its journey. This also shows the data fusion of the real system: the radar coverage indicates that the ship has stopped and the information from the captaincy indicates the engine failure.

The second scenario is a little more complex, involving at least two ships: the one that run the scenario and an unknown one illustrated by the event E3 at time 01. Indeed, the ship ship2 stops in open sea and the radar coverage indicates a proximity with an unknown ship. After an hour, the unknown ship starts again and rolls away from ship2, which is represented by the end of the event E3 at time 03. Finally, two hours later, at time 07, the ship ship2 disappears from the radar. This scenario represents the scuttling of a ship after her occupants have been taken hostage.

Once the scenarios are created, either by a random generation or given by one user, they are processed through the rule engine simulator. Its running is simple: it reads the scenarios step by step and sends every encountered events and end of events to the detection system, MAS4AT in our case.

MAS4AT then processes the eventually received events and updates its representation of each entity. It means that for each entity, the corresponding function allowing to compute the Entity Behaviour Value (EBV) is updated –see chapter 3. When an EBV exceeds the alert threshold, MAS4AT then sends an alert to the operator simulator.

Parallel to the rule engine and MAS4AT, the operator simulator is also able to read the scenarios of each entity and to compute their EBV. The operator simulator knows the real values of the events created and so the EBV it computes is also the "real one", meaning the one towards which the parameter-agents should converge to be correct.

Finally the operator simulator can compare them with what is coming from MAS4AT. If an alert is sent from MAS4AT, the operator simulator takes a look into the EBV of the related entity. If this value does not indicate an alert, a feedback is sent back to MAS4AT. On the contrary, when no alert is sent and the value computed by the operator simulator indicates one, a feedback is sent to MAS4AT.

Figure 4.7: Architecture of SIM4AT.