Difference between revisions of "Offline Team3 Benchmark1"

Revision as of 15:57, 4 June 2016

This benchmark aims at detecting hazardous behaviours in aeronautic operations, and more specifically security procedure breaches. The data flow to be analysed results from the informations collected observing air traffic in a given area where air space is divided into several controlled or uncontrolled areas.

Category:Aerospace

Benchmark Data

The Trace Part

Trace structure

Traces are made of events with associated attributes. Events are essentially of two kinds: position-related (e.g. an aircraft is located at a given position), or communication-related (e.g. an aircraft sets its radio to a given frequency, or an aircraft asks for or receives a clearance, or an aircrafts indicates having reached a waypoint, ...). Attributes are values associated to each event instance. The following examples show attributes associated to various events:

• position (attributes: aircraft id, latitude, longitude, altitude, velocity, horizontal

velocity, vertical velocity): an aircraft with a given id is at given coordinates at the time where the event occurs;

• clear_takeoff (attributes: aircraft id): an aircraft with a given id has

received a clearance to take off at the time where the event occurs;

• set_frequency (attributes: aircraft id, frequency): an aircraft with a given

id has its radio set to a given frequency at the time where the event occurs;

• etc.

Traces are found in different files:

• 1 position file for each aircraft
• a single file for all communication-related events

The entries in these files are as follows:

Time, Event name, attribute_name_1, value_1, attribute_name_2, value_2, ..., attribute_name_n, value_n

where n is the maximum number of attributes associated to an element (in our example, 7).

Provided traces

In the example provided here, there is a single aircraft considered, hence just one file for positions (trajectory_153.csv).

Traces will differ only on the communication part; however, the position file is also needed as it intervenes in the determination that a behaviour is hazardous.

We provide different files exhibiting different behaviours:

• com_1.csv is nominal and no hazardous behaviour is detected
• com_2.csv exhibits an hazardous behaviour that must be detected
• com_3.csv exhibits an hazardous behaviour that must be detected
• com_4.csv exhibits an hazardous behaviour that must be detected

Property part

Informal description

The purpose is to detect when an aircraft violates security procedues, i.e. either takes off without a clearance (or with an expired clearance), or does not set its radio frequency so as to communicate correctly with the air traffic control.

These behaviour require the identification of several refined behaviours, some of which are deduced from positions (e.g. takeoff) and some of which are deduced from communications (e.g. clearance received), which which are then cross-combined temporally.

Formal description

Properties are organised in three levels.

The 1st level describes elementary behaviours:

• OnGround(id, h): the aircraft with ID id is on ground (i.e. at an altitude below h), i.e. an event e is detected where e.name = position, e.ID = id, and e.altitude < h
• AboveGround(id, h): the aircraft with ID id is on ground (i.e. at an altitude above h), i.e. an event e is detected where e.name = position, e.ID = id, and e.altitude > h
• FreqDiffFrom (id, f): the aircraft with ID id is not at frequence f, i.e. an event e is detected where e.name = set_frequency, e.ID = id, e.freq /= f
• ClearanceTakeOff(id): the aircraft with ID id has received a clearance for takeoff, i.e. an event e is detected where e.name = clear_takeoff and e.ID = id

The 2nd level is deduced from the previous one to represent more elaborated properties:

• TakeOff(id, H) is described as: this is the first time that property AboveGround(id, h) is satisfied after an

instant where property OnGround(id, h) was satisfied

The 3rd level is deduced from the two previous one and represents security breaches to be detected

• NoClearanceToTakeOff(id) is described as: either TakeOff(id, 15) has been detected and no ClearanceTakeOff(153) has been detected previously, or this is the first time that TakeOff(id, 15) is detected after the detection of ClearanceTakeOff(id) but at least 60 seconds have elapsed since this last detection
• NoFrequencyToTakeOff(id) is described as either one of three possibilities: (1) a wrong frequency is set after which 5 seconds elapse, during which no other frequency is set, or (2) within 5 seconds after takeoff a wrong frequency is set and the right frequency is not set before the end of these 5 seconds, or (3) no frequency has been set at until at least 5 seconds after takeoff.

Note that the airport considered in the example has an altitude of 15, which is why this value appears in the behaviours above to determine takeoff.

Demonstration Traces

Let us recall that a trace is made of two files: trajectory_153.csv describing aircraft positions, and com_n.csv (where n is a scenario number ranging from 1 to 4) describing communications.

The following results must be obtained:

• with trajectory_153.csv and com_1.csv, no hazardous behaviour must be detected
• with trajectory_153.csv and com_2.csv, only hazardous behaviour NoFrequencyToTakeOff(153) must be detected
• with trajectory_153.csv and com_3.csv, only hazardous behaviour NoClearanceToTakeOff(153) must be detected
• with trajectory_153.csv and com_4.csv, only hazardous behaviour NoFrequencyToTakeOff(153) must be detected

Clarification Requests