Stage 1 - complete

Stage 1 of our model scenario was described in our report D1.2 as a

Simple en route air sector: aircraft of the same type on two flight paths that intersect but are vertically separated and so for whom no conflict exists. Cabin pressure loss can occur on either flight path, and the corresponding flight will make an emergency descent to FL100. No divert occurs (i.e. aircraft remains on original flight path) as no airports are included. Single risk hotspot defined by intersection of new flight path after emergency descent by aircraft from higher flight path to emergency flight level. No specific resolution rules / activities created for controllers (RAMS Plus defaults used).

The purpose of this stage was to provide us with a test ground to test that our search harness would find incident hotspots. This stage has now been completed with some rather unexpected results! As predicted, the search algorithm was able to manipulate aircraft entry times on the low level flight path to the sector to coincide with the aircraft undergoing the emergency event.

However, we have adapted the range of mutation permitted by the search algorithm from selecting an aircraft start time at random within the time span of the simulation (unrealistic but easier to verify the search as working correctly), to a slot-based mutation scheme which takes account of wake turbulence for aircraft following a given flight path. The slot-based scheme is something that directly affects the freedom of the algorithm to explore the available search space, but it is typical of the sort of restrictions necessary to make the model’s implementation more realistic and relevant to the work of safety-related ATM.

Stage 2 is now under way and is much more complex, with further issues around the resolution of the emergency aircraft. We will post more details soon!

Pre-stage 1 progress

The first part of Pre-Stage 1 is almost complete.  This stage doesn't use the SimC interfaces to RAMS Plus.  Instead, our application creates randomised traffic files and feeds these to RAMS.  We analyse the results and search looks for the worst case scenarios in terms of the conflict generated.

The scenario is extremely simple and is designed for us to test that the search algorithm is working correctly and see if we can tweak the search performance just using simple measures such as population size, mutation rates, crossover, etc.  The scenario is a simple en-route sector with two flight paths running roughly east to west and north to south.  The traffic enters and leaves at FL330 (cruise).  Obviously the point where the flight paths intersect will generate conflicts for ATCos given certain entry times into the sector.  The search is tasked with finding those times that generate the greatest number and severity of conflicts.  

As we don't impose any restrictions on the entry times, we permit aircraft to enter only seconds apart.  However, there is a 30min window, and so the search has to find a way to "clump" aircraft together so that it finds the configuration that will generate the greatest conflict.  Pre-Stage 1 is not intended to be realistic - it is only to ensure the search is working correctly.  Stages 1 - 4 gradually introduce greater levels of realism and complexity, and will dramatically increase the size of the search space.

Rather than repeatedly running a single instance of RAMS, we try to run multiple instances of it in parallel.  If you have never seen a computer pushed to its limits before, it is quite amusing to watch 100 separate instances of RAMS Plus (in non-graphic mode) each load up their variant of the same scenario before our application starts parsing the results.  Initial tests suggest that one generation (of a population of 100 individual scenarios) will take about 5 mins to complete, which should mean we can run 300-400 generations overnight although that time will increase once our scenario become more complex. 

Of course, as the screenshot shows, you shouldn't expect to keep working on the computer once you launch a run!  Here you can see that the traffic information has finished writing, but we're still only on the thirtieth instance of RAMS Plus.  

Mouse pointer lag is about 40 seconds. As I'm sure they said in a film somewhere, "Clicking is futile..."

You can see the memory use start to ramp up as more instances
of RAMS are loaded up - we're up to about a third of the total here.

First success with the SIM-C API!

After a few false starts, we've finally got the SIM-C API provisionally working with RAMS Plus.  We're still getting some MODSIM bugs with the graphical version, but the non-graphical version finally updated an aircraft with a new 4D profile during a simulation today.

Massive relief to get it working!

Paper accepted for SID 2011

We're off to Toulouse as part of SID (SESAR Innovation Day) 2011.  Actually 3 days, during which we hope for plenty of networking and discussion about our project.  Got our paper accepted - you can read it here.

Google Earth Visualisation

One thing RAMS Plus doesn't do so well is give you a 3D idea of what is happening in the airspace, so we've explored using Google Earth for this.  It's relatively easy to use the flight outputs from RAMS and convert these to a series of latitude, longitude and altitude points to view in Google Earth.  You can save them as a *.kml file using a little utility called EarthPlot (though there are several others out there).  By loading up successive files of individual flights, different colours can be overlaid.

RAMS Plus selected for fast time simulation environment

The result of meetings with ISA Software Ltd have led us to select the RAMS Plus gate-to-gate simulation environment for the ASHiCS project.  Essential to our choice was their offer to let us use an API that would permit changes to air traffic during simulations.  The API was originally written to conform to National Air Space model (FAA / USA) as part of the NextGen programme.  The API is in C++ and provides a message passing infrastructure between information consumers and providers, of which RAMS Plus can act as both.

We'll post more details of how the API works with RAMS Plus in later articles.