Category: Operational Support

  • Air Navigation Services ORAT: Operational Readiness and Transition

    What is an ORAT?

    Changes bring opportunities but they also bring risks. In safety and time critical environments, these risks, if unmanaged, can have very serious consequences.

    Operational Readiness and Transition (ORAT) is a methodology that provides a framework for managing the risk that changes bring with it, be it due to changes in facilities, configuration or procedures. This methodology also aims at harnessing the opportunities that the same changes bring. ORAT is a methodology highly used in changes affecting airport operations. It can equally be applied to other changes in the aviation industry such as those affecting Air Navigation Services.

    A typical project focus is on construction delivery and completion of a static asset (cost, time and quality), operational readiness is focused on the dynamic state of a business operation, integrating all of the diverse moving parts into one, cohesive, dynamic operation.

    An ORAT is used mainly because it:

    • Ensures smooth start / transition of operations.

    • Provides controlled and managed planning, preparation and execution of operational readiness processes.

    • Integrates all stakeholders (air navigation services (management and staff), airport operations, regulation and certification, airlines, handling, etc.) 

    • Ensures buy-in and safe and efficient process

    ORAT Components

    Every project is different; however usually an ORAT will have the following elements:

    ORAT Components

    It is important to remark that each of these elements has a purpose in the ORAT process and it should be properly handled.

    Also, an ORAT will require excellent coordination between Operational, Technical and Safety/Regulatory parties.

    Human Centric Approach

    We believe that the best way of doing an ORAT is keeping in mind that Humans are always a key part, as we are the ones who are involved in every operation.

    The various ORAT sub-phases such as Concept, Procedures, Safety, Training, Shadowing have also the objective of permitting the main actors (e.g. Management, Operations, Engineering, Safety Management, Regulatory Oversight, etc.) to gain confidence in the system, therefore, increasing the acceptance of the system as a whole and increasing the chances of a successful transfer of knowledge.

    ORATs aim not only to prepare everything for operations but also to transfer essential knowledge on procedures, training and safety management as well as transition management to the staff during the process.

    INGENAV we are confident that when a big change will happen, an ORAT is a key element for a successful transition into the new operation environment.

    We base this on our knowledge and in our experience of previous projects where with the use of ORAT, successful implementations have taken place.

  • Why do we investigate?

    The no-prize answer is ‘because we have to’. The correct one is because we cannot afford not to.

    ICAO Annex 13 lays out the consolation that ‘the sole objective of the investigation of an […] incident shall be the prevention of […] incidents. It is not the purpose of this activity to apportion blame or liability’. The tangible outcome of an incident investigation is the Investigation Report housing sections on Factual Information, Analysis, and Conclusions. It only stands to reason that Factual Information has to be obtained and suitably analysed for conclusions be drawn as to WHAT actually happened, and WHY it happened. Now comes the sticky part, for the Investigator is also tasked with coming up with Safety Recommendations. I admit that, as an Incident Investigator, I have often slept uneasy over this last responsibility. I have gathered and examined written and verbal reports, I have listened to voice recordings and transcribed them, I have watched the video recordings of the occurrence or the radar screen as well as the relative keyboard inputs, I have interviewed all involved and obtained as much information as to what was happening. I have made myself familiar with all the circumstances at the time. Armed with all available data, I have absolutely no problem with reaching conclusions about causal and contributing factors. On these I am now an authority. But to make recommendations? I look back to the courses I attended, and the training seminars I endured (and lately made others endure), and note with disappointment that this ultimate ‘must do’ has, all-too-often, been very much glossed over. We make it sound as if coming up with recommendations is simply a natural follow-up to all the digging made, and these will simply fall into the lap of the deserving. The bad news is that this is far from it.

    I can put suggestions on how to right obvious shortcomings; I can also extrapolate the actual happening to include ‘what if’ scenarios and decide if the available procedures or resources carry enough resiliency. But I have, at times, felt insufficiently equipped to confidently reassure myself that I have covered all possible recommendations. Is it enough to point out that inappropriate phraseology was a contributing factor to a runway incursion? Or, that better employment of speed control could have averted an unwholesome situation? Or, that letters of agreement between sectors do not cover all eventualities? I question myself, should I spell out a recommendation that personnel attend mandatory phraseology or speed control refresher training? Or oblige the powers that be to revisit procedures? What if I overlook a recommendation which could avert another incident in the future? Should I conscientiously take responsibility for my recommendations to not adversely impact my company financially? Should I even be questioning myself about such? Uneasy is the head that wears the headset marked Incident Investigator.

    Making recommendations is an onerous responsibility. A medical doctor, having examined the patient and carried out the required tests, writes out the appropriate chemicals to be ingested to right the ailment. The Investigator prescribes appropriate remedial attention to avert a repetition of an unpleasant happening. The patient implicitly puts his trust in the good doctor and happily downs pink capsules before meals; the system trusts the recommendations to be the best cure to a malady. The recommendations being delivered, the ANSP decides if they should be implemented: whether in their entirety or in part, the method and the timing. The Investigator’s report is only testament to her findings coupled with her experience; it is the ANSP’s call to implement the corrections. The entity is answerable to its clients, its professionals, and the overseeing Authority.

    Approaching summer of 2020, we are in a shell-shocked state. We do not know what the postdiluvian world will look like. Regarding Investigator training, we have, in recent years, witnessed the progressive reduction of the instruction and practice period. One can only assume these will be decreased even further. e-TOKAI* has wonderfully enabled the reporting and investigation process to be conveniently wrapped up in a seamless package with a deliverable document rolling out at the other end. The Tool has taken out the hassle and intricacies of building a report while ensuring that all possible data is collected. Investigation reports have become more standardised, coherent and thorough. e-TOKAI sees to that. Sadly, the free-text areas can be more disappointing. Investigator training, even more limited as it might evolve, will continue to train candidates in data gathering, interviewing techniques and gaining personnel trust, but more consideration should be given to the quality of report writing.

    Writing reports is an art form. The writer has to keep the intended consumer in mind. The report culminates in the Recommendations area, and the Investigator has to ‘sell’ her recommendations in the most convincing manner. A badly structured report will not inspire a sale, and a badly written one will only alienate its audience, rendering the exercise futile.

    At the end of a report come the recommendations. Mine is to revisit the Investigator training material, give e-TOKAI its room to do what it does best, and better employ time and resources to train our professionals to construct better reports and put forward meaningful recommendations.

    We cannot afford otherwise.

    * e-TOKAI is Eurocontrol´s toolkit for air traffic management occurrence investigation.

    Renald Galea is an Air Traffic Controller with vast experience as an Incident Investigator and the use of e-TOKAI and RAT.

  • Automation and Human Centricity – Three-tier human centricity. Position paper.

    There should be little doubt or argument that the journey towards further automation in Air Traffic Control is well on its way and is set to continue. Also, there is little doubt that many of the future solutions will have, at least, some of their components based on Artificial Intelligence techniques.

    If we look at SESAR´s Level of Automation Taxonomy (LOAT) model as displayed below,  

    most modern ATC Systems are somewhere between B4/B5: High level – full automation support of information analysis and C1: Artefact-supported Decision Making.

    The end goal for most R&D projects is to arrive to D8: Full automation of action sequence execution for all ATC tasks.

    This raises a few items to consider and this is what we at Ingenav think about this:

    1. Until D8 is reached on all ATC tasks (whether it will be desirable for it to be reached is the subject of item 2), humans will be part of the system and the system will need to be Human-Centric.
    2. It is questionable whether, even if technologically possible, it would be desirable to reach D8 and have a non-human-in-the-system ATC chain.

    Developing these items, a little further we need to consider:

    1. A three-tier Human-Centric approach is necessary:

    Human-Centricity needs to be seen holistically:

    The design of an ATC system needs to be done through a human-centric approach. The result, i.e. the ATC system itself needs to be human-centric. And with the growing autonomy coming about, one shall not forget that the end-user of ATC is not the air traffic controller but the airspace user: the human who flies the aircraft. These are the three tiers – from the design, to the product itself, to its output.

    Starting from Tier 3: Human-Centric design:

    The design of an ATC system shall be led by its usability and by its interaction with the holistic system first. Rather than having a technology-led design in which the “what can be done” is defined first and the “how” is done later, human-centric design requires agile development cycles between definition – prototyping – human in the system testing – adjustments – redefinition and advancements. The design team needs to incorporate from a very early stage operational expertise that understands the business and the process and that co-lead the design. This should be the case even when the functionalities that are being developed would be in the high Ds in accordance with LOAT as these will always interact with other processes where the human is involved.

    Tier 2: Human-Centric system:

    The result of the design – i.e. the product, needs to fully integrate the human as part of the system and not its operator or the mortar which glues together the imperfections created by the other parts. A Human-Centric system understands how the human works and integrates the human´s processes into the overall system. Principles such as relevance, timeliness, prioritized and rationalized for human understanding should be key in all the interactions of a human-centric system.

    Tier 1: Human-Centric outputs:

    It may sound obvious but it is often taken for granted: an ATC system acts as an intermediate; it is a safety net and an efficiency boost to air traffic and airspace users (that is the objective of ATC!). It is airspace users who execute the instructions generated by ATC. Until further notice, aircraft will be flown by humans. The instructions provided by ATC need to keep that in mind. So far, this has been taken for granted because the human-in-the-system at the ATC level automatically made the adjustment. However, in a scenario where some of the instructions are not generated by a human, the system has to keep in mind they will be executed by one.

    It is important to insist on Human-Centricity and the human-in-the-system principle and not to see the human as an external agent who acts as an operator or a mediator, or even worse as a corrector of imperfections. It is important to take the learnings we have made in the past decades and build on them rather than to try to discard them because we believe that advanced automation will make the human somehow less important.

    Question 2: is it desirable to arrive to D8?

    The quick answer to this is that we don´t know. To date, we do not have the maturity to understand what a fully autonomous system, which in turn is an intermediate between vigilance and execution, would mean. The gap to get there is still too big and we need to narrow this gap in order to understand better the ramifications. Of the ramifications, we are able to identify to date one can include resilience, of such a system and degraded modes, interconnectiblity, responsibility, certification, the holistic concept of operations of the airspace user and societal (is it, in fact, desirable and productive from a societal perspective to try to eliminate the human from the system?).

    R&D in this area must continue and needs to be holistic and not just technology-driven. We can do a lot of things but should we apply them? By continuing R&D, the sector will mature further and whilst bridging the gap, we will also understand the opportunities and the threats that such changes would bring. If we ever reach D8, it should be an evolution and not a revolution.

    Conclusion

    Undoubtedly, work is in progress towards advanced automation in the lines of decision-making support and basic autonomous execution of tasks. Human-Centricity is primordial in the development of such tools and this human-centricity needs to be taken care of in 3-tiers: at design, at the system and at output levels. Achieving D8: full automation of task execution for all tasks making up ATC should be an R&D goal and not an operational one at this stage. The gap between the current paradigm and that one is too wide and we do not have the maturity to understand the ramifications of such a change. R&D needs to be holistic and not just technology-driven. A stepwise approach towards understanding will be necessary.

     

    PS, Ingenav is currently participating in a project with a Core European ANSP and ATC system manufacturer to introduce Decision Support Operational ATC tools using amongst other historical data and machine learning principles. In this project, a 3-tier Human-Centric approach is being applied.