ASHiCS - Automating the Search for Hazards in Complex Systems
Providing the groundwork for a future, fully-automated hazard discovery process.
Thursday, 2 May 2013
Final two reports available
The ASHiCS project has now finished, and the final two reports are now available from the public reports page.
Wednesday, 7 November 2012
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.
Wednesday, 27 June 2012
New page detailing reports!
We are making our deliverables to EUROCONTROL publicly available for download. Please visit the reports page above.
Friday, 8 June 2012
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.
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.
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.
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.
Tuesday, 1 May 2012
Stage 1 - complete
Stage 1 of our model scenario was described in our report D1.2 as a
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!
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!
Monday, 30 January 2012
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.
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.
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.
Mouse pointer lag is about 40 seconds. As I'm sure they said in a film somewhere, "Clicking is futile..."
Saturday, 10 December 2011
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!
Massive relief to get it working!
Subscribe to:
Posts (Atom)