Difference between revisions of "Offline Team3 Benchmark1"

From CRV
Jump to: navigation, search
m
(Clarification Requests)
 
(One intermediate revision by one other user not shown)
Line 35: Line 35:
 
==== Provided traces ====
 
==== Provided traces ====
  
In the example provided here, there are two aircrafts considered, hence two file for positions (trajectory_153.csv and trajectory_747.csv).  
+
In the example provided here, there are two aircrafts considered, hence two file for positions (trajectory_153.csv and trajectory_147.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.  
 
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.  
Line 98: Line 98:
  
 
== Clarification Requests ==
 
== Clarification Requests ==
 +
 +
A few initial comments.
 +
 +
Firstly, it seems to me that each of the four com_x files represent separate 'benchmarks' in the competition terminology. Therefore, for consistency a separate page should be created for each one. The property part etc need not be replicated (reference the first benchmark).
 +
 +
Secondly, in NoFrequencyToTakeOff I am not sure what wrong and right frequencies means, these do not seem to relate to previously introduced definitions.
 +
 +
Thirdly, the idea of the demonstrator traces is to give short explanations of the behaviour without referring to external information or any formal specification. When I have looked at the properties further I can give an example of what I mean by this.
 +
 +
Finally, the rules state that there should be a single trace file. I suggest using the following script to merge the trace files into a single trace and making both the merged and unmerged versions available.
 +
 +
    #!/usr/bin/env python
 +
   
 +
    import sys
 +
   
 +
    if len(sys.argv) != 3:
 +
      print "Give the two csv files to merge"
 +
      sys.exit(0)
 +
   
 +
    one = sys.argv[1]
 +
    two = sys.argv[2]
 +
   
 +
    l1 = [line.strip().split(',') for line in open(one, 'r')]
 +
    l2 = [line.strip().split(',') for line in open(two, 'r')]
 +
   
 +
    h1 = l1[0]
 +
    h2 = l2[0]
 +
   
 +
    if cmp(h1,h2):
 +
      print "The headers should be the same"
 +
      sys.exit(0)
 +
   
 +
    print ", ".join(h1)
 +
   
 +
    l1=l1[1:]
 +
    l2=l2[1:]
 +
   
 +
    while l1 and l2:
 +
   
 +
      if float(l1[0][0]) < float(l2[0][0]):
 +
        print ", ".join(l1[0])
 +
        l1 = l1[1:]
 +
      else:
 +
        print ", ".join(l2[0])
 +
        l2 = l2[1:]
 +
   
 +
    for l in l1:
 +
      print ", ".join(l)
 +
    for l in l2:
 +
      print ", ".join(l)

Latest revision as of 16:32, 14 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 aircraft indicates having reached a waypoint, or a meteorological alert is raised...). 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;
  • wind_information (attributes: wind direction, wind speed): meteorological information is provided for wind, including its direction and speed;
  • 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 are two aircrafts considered, hence two file for positions (trajectory_153.csv and trajectory_147.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
  • com_5.csv exhibits an hazardous behaviour that must be detected


Property part

Informal description

The purpose is to detect when an aircraft violates security procedures, 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, or takes off when there is an alert for strong wind.

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
  • WindInfo(d, ws): wind has changed and now originates from direction d and has speed ws.

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
  • WindAlertRaised() is described as: this is the first time that property WindInfo(d, ws) is satisfied with ws >= 40 knots since the beginning or since this property was satisfied with ws < 40 knots
  • WindAlertLifted() is described as: this is the first time that property WindInfo(d, ws) is satisfied with ws < 40 knots since this property was satisfied with ws >= 40 knots


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(id) 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
  • TakeOffByStrongWind(id) is described by: either TakeOff(id, 15) takes place and, within 10 seconds before or after takeoff, WindAlertRaised() is satisfied, or WindAlertRaised() is followed by TakeOff(id, 15) without WindAlertLifted() taking place at least 10 seconds before 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 three files: trajectory_153.csv and trajectory_747.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 both trajectories and com_1.csv, no hazardous behaviour must be detected
  • with both trajectories and com_2.csv, only hazardous behaviour NoFrequencyToTakeOff(153) must be detected
  • with both trajectories and com_3.csv, only hazardous behaviour NoClearanceToTakeOff(153) must be detected
  • with both trajectories and com_4.csv, only hazardous behaviour NoFrequencyToTakeOff(153) must be detected
  • with both trajectories and com_5.csv, only hazardous behaviours TakeOffByStrongWind(153) and TakeOffByStrongWind(747) must be detected


Clarification Requests

A few initial comments.

Firstly, it seems to me that each of the four com_x files represent separate 'benchmarks' in the competition terminology. Therefore, for consistency a separate page should be created for each one. The property part etc need not be replicated (reference the first benchmark).

Secondly, in NoFrequencyToTakeOff I am not sure what wrong and right frequencies means, these do not seem to relate to previously introduced definitions.

Thirdly, the idea of the demonstrator traces is to give short explanations of the behaviour without referring to external information or any formal specification. When I have looked at the properties further I can give an example of what I mean by this.

Finally, the rules state that there should be a single trace file. I suggest using the following script to merge the trace files into a single trace and making both the merged and unmerged versions available.

   #!/usr/bin/env python
   
   import sys
   
   if len(sys.argv) != 3:
     print "Give the two csv files to merge"
     sys.exit(0)
   
   one = sys.argv[1]
   two = sys.argv[2]
   
   l1 = [line.strip().split(',') for line in open(one, 'r')]
   l2 = [line.strip().split(',') for line in open(two, 'r')]
   
   h1 = l1[0]
   h2 = l2[0]
   
   if cmp(h1,h2):
     print "The headers should be the same"
     sys.exit(0)
   
   print ", ".join(h1)
   
   l1=l1[1:]
   l2=l2[1:]
   
   while l1 and l2:
   
     if float(l1[0][0]) < float(l2[0][0]):
       print ", ".join(l1[0])
       l1 = l1[1:]
     else:
       print ", ".join(l2[0])
       l2 = l2[1:]
   
   for l in l1:
     print ", ".join(l)
   for l in l2:
     print ", ".join(l)