Even before coronavirus disrupted everything, SESAR Deployment wasn’t exactly accelerating in a way that suggested digitalisation of ATM, as envisaged for example in the Airspace Architecture Study, was going to be realised any time soon. Whilst the European Court of Auditors recognised the importance of EU support for SESAR deployment they also listed a number of concerns – suggesting the regulatory approach wasn’t quite right.
In this blog, Think Technical Director, Paul Ravenhill, sets out a market and risk based strategy for managing the process of taking SESAR solutions from R&D to Deployment.
Industrialisation in context
The industrialisation phase gets its name from the European Operational Concept Validation Methodology (E-OCVM), a document first published in 2005 by EUROCONTROL, with much help from our very own Conor Mullan. E-OCVM helps researchers manage the R&D lifecycle – and in particular how validation evidence increases through the lifecycle. This is important – the level of validation and evidence at each stage only supports a decision to move or not to the next phase. You can’t jump phases – you don’t have the evidence.
The current version, Edition 3 has 8 life cycle phases, ranging from V0 to V7 as illustrated below:
Figure 1: The E-OCVM Concept Lifecycle Model (E-OCVM V3)
It is important to realise that E-OCVM was developed using EU R&D money as a research tool – it describes the activities required to validate concepts and assess maturity within R&D programmes with a focus on V1 to V3. In this regard E-OCVM is very successful – it is the cornerstone of the approach adopted by the SESAR Joint Undertaking for maturing SESAR Solutions.
However, E-OCVM is not fully articulated for the life cycle phases beyond R&D, it does not describe V4 and V5 in detail, and it does not describe the maturity assessment for transitioning to these phases. To understand the industrialisation phase we need to look elsewhere.
Defining Industrialisation
One way of defining industrialisation phase is to consider the maturity gates on either side. Take a look at the Figure 2. At the end of V3 it is more than likely that the SESAR solution will have been demonstrated using a prototype – that may have been developed by a manufacturer or maybe a software based simulation developed by researchers. For V5, we need sufficient products to create a competitive market and potentially, but not always standards and other material to support regulatory approval of the implementation.
Figure 2: Current Process for V3-V4-V5
So, in order to go from V3 to V5 what do we need?
Most importantly we need more than one manufacturer to take the potentially substantial risk of investing in product development. This may include developing new hardware and updating productions lines or writing safety critical software. Way back, when I worked for Racal Research, I helped developed a prototype modem for a multichannel satellite communications system. It was the size of a very large suitcase. Once we validated that the design met the performance standards, the production engineers at Racal Avionics took over and produced a version the size of a briefcase that became the MCS6000.
The modern equivalent is the size of a shoebox. That process costs money. Real money. Racal partnered with Honeywell to develop the product – spurned on by market assessments suggesting that ATS and passenger communications would grow exponentially (and this was before the take-off of mobile phones) leading to every wide-body aircraft getting equipped in the next few years. In fact, I remember this time as a “race to market” with Rockwell Collins. The passenger benefits were not really realised – do you remember being asked for $10 per minute to make transatlantic phone calls in the early 1990’s? The ATS benefits were however real. SATCOM enabled FANS which led to huge airline cost savings on transatlantic routes.
The Honeywell-Racal team were confident of designing the right product because standards existed. Most important was the Inmarsat Aeronautical System Definition Manual but there was also material from AEEC, RTCA and EUROCAE. This range of documents, standards and specifications is essential if you want to build interoperable avionics – in theory an airline can pull out a system box from one manufacturer and plug in someone else’s. Developing these standards was in the aviation industry’s best interests. As the work progressed, we found things and lodged change requests with Inmarsat – and went to standardisation meetings to propose changes. These were always lively meetings, particularly if you had got to the point when changing pins on the ARINC600 connector was going to cost your company money.
When I eventually moved on, in 1994, and joined the ground ATM systems community I was in for a shock. The concept of airworthiness that drives avionics development didn’t (and really still doesn’t) have a ground equivalent. Try googling groundworthiness! Air Navigation Service Providers were taking the industrialisation risk by developing their own specifications for systems and contracting a supplier to build against them – some even built their own systems. Ground systems were not interoperable in the way avionics were – and today ground-ground interoperability is still largely defined by the legacy interface standards of these systems such as OLDI and ASTERIX.
Ten years of SESAR have led to a different ideas on what the market should look like. ANSPs want to buy products that implement SESAR solutions – the expectation is that manufacturers will take the risk and develop new products – but for a very small market. There are a lot more aeroplanes than there are ANSPs. In Europe there may only be one new Flight Data Processor commissioned a year.
Reducing risk and cost
So, if we want manufacturers to take the plunge, we need to reduce the risk and cost of them doing so. And we want a market for products that is competitive enough to keep prices down. We don’t want to create monopolies. Industrialisation is for the Industry! What the ATM community at large can do is squeeze the industrialisation phase so that it is better supported by V3 and V4 as we illustrate in Figure 3:
Figure 3: Proposed Process for V3-V4-V5
The first thing is to reduce the industrialisation risk by extending V3 through a larger role for Very Large Demonstrators within the SESAR R&D Programme. VLDs are great – they create interest and demonstrate capability. But they can, if properly funded and managed, do more. VLDs need to build evidence of performance improvement both locally and at network level. VLDs need to help build consensus across the industry of the necessary level of deployment and be supported by detailed market assessments (not just high level CBAs). This is necessary for manufacturers to decide if they are ready to invest. A lot is said about maturity assessment at the end of V3, but actually it is the simplest maturity gate of all – you can only truly claim to have passed a V3 maturity gate if multiple manufacturers take on the industrialisation risk. It is not for the R&D community to say a solution is mature – all they can do is publish the evidence and let the market decide.
The challenging maturity assessment gate is actually at the end of V4. This is when customers vote by buying the product. The first purchaser of a safety critical system is taking a risk – that the product can be integrated with the existing systems in order to deliver the defined service. Regulators expect evidence – through the process of safety assurance and conformity assessment – that the integration is successful. This regulatory compliance is not cheap – but it does become less costly the more it is done and the more lessons learnt are shared.
For many products, the market does work for the V4 maturity gate – but these tend to be products to support airport ATS such as A-SMGCS and taxiway lights where there is a substantially more dynamic market. For the en-route market we need something different. In SESAR Deployment terminology solutions requiring synchronised deployment need a bit of a push. And if the AAS is going to be realised, synchronised deployment of game-changing solutions is going to be needed. A lot.
An idea we first mooted in 2016, when auditing the SESAR programme, is to fund pilot deployments from multiple suppliers with additional objectives to support standardisation and regulatory approval activities along with obligations to disseminate the lessons learnt. This is not an R&D activity, it cannot be funded under the EU Horizon 2020 rules, but it can be funded with Connecting Europe Facility (CEF) funds. Pilot deployments of this nature, managed by the successor to the SESAR Deployment Manager, will generate the real evidence to support mandated deployment – which includes things like the manufacturers ability to supply sufficient products to meet the mandate. Things that can just not be known during V3.
Managing the process
On Figures 2 and 3 we have indicated the current and proposed regulatory decision points. Contents of the Pilot Common Project were proposed using the current process. Solutions at V3, largely untested by the manufactures’ willingness to industrialise, were selected for synchronised deployment. The results as the European Court of Auditors were not completely satisfactory. With hindsight that is not a big surprise – R&D managers were put in an impossible position. It was like asking parents of new-borns to decide if their children will be scientists or artists before they can even walk. Of course, they know that little Ella’s going to be the next Einstein and Frank is going to outshine Frida Khalo. Of course they do.
Our recommendation is simple – using the evidence at V3 and from expanded VLDs to make decisions in principle to move to deployment. Work collaboratively as industry through V4 to build up additional evidence and in particular through pilot deployments – but only make a binding mandatory decision to deploy when all the evidence is in.
We are confident that this sort of approach can banish talk of the V4 gap, and lead to the SESAR Partnership approach to deployment that was always envisaged.
Author: Paul Ravenhill, Technical Director
Recent Comments