Final two reports available

The ASHiCS project has now finished, and the final two reports are now available from the public reports page.

New report (E.02.05-ASHiCS-D2.2-Method Description Technical Report) available

The latest report from the ASHiCS project is now available to download from the Public Reports page.

New page detailing reports!

We are making our deliverables to EUROCONTROL publicly available for download.  Please visit the reports page above.

Stage 2 - the real work begins

Stage 2 of our model scenario increases the existing air sector to contain a variety of aircraft and flight paths. Although we are only part way through the implementation of this stage, the increase and variety of traffic has already thrown up a number of problems related to the restrictions and ability of the search to find traffic configurations of interest.

The first big change to Stage 2 was to ensure that the emergency aircraft itself would not get resolved by RAMS.  In order to do this, we created resolution candidate rules that look for the aircraft type and decide which of the pair of aircraft will be resolved.  In a case that involves the aircraft suffering emergency pressure loss, the other aircraft is always resolved, allowing the emergency aircraft to descend to FL100 without deviation.

Stage 2 prior to resolutions rules prohibiting emergency aircraft (CPLoss) from being resolved in conflicts – here we can see CPLoss is re-routed to avoid another aircraft during its emergency descent.

As mentioned in our previous post, we have implemented a slot based mutation scheme so that traffic entering the sector on a flight path can only enter after sufficient time has passed to allow wake turbulence from any previous aircraft to dissipate.  In addition to this restriction, we have also permitted several more possible intersections with other flight paths and / or the emergency aircraft.  Bear in mind that the emergency aircraft is chosen at random from a selected high level flight path and descends to FL100.  In between these levels we have a variety of small personal jets and light passenger aircraft that can intersect with one another and the emergency plane.

This huge increase in the size and complexity of the search space has given us a number of headaches!  One is that random traffic permutations are often able to "out jump" those permutations created by the search algorithm, i.e. nudging aircraft along various flight paths by a few minutes does not always result in gaining a significantly higher risk measure than an entirely new initial configuration.  This is a feature of a very large search space and we are looking at ways to solve it, including taking a very large initial seeding of scenarios, and afterwards reducing the population to a selection.  This would in effect "bootstrap" the search in a productive direction.  However, the issue of coverage is likely to remain a vexing issue, as we have no guarantee that the mutation of a particular scenario we reject in the initial seeding would not later go on to gain a high fitness during an evolutionary run.

We will post more results as we get them.

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!