My Training Device Manufacturer Just Closed. How Do I Keep My FSTD Functioning?

Editor’s Note: The Journal of Civil Aviation Training (CAT) magazine presents Guest Commentary on important issues facing the community. The opinions expressed are the author’s own.

This commentary is offered by Mark Dransfield, co-founder of Sim Ops and independent Flight Simulation Training Device (FSTD) regulatory consultant, specialising in the evaluation and qualification of FSTDs in accordance with the latest regulatory frameworks. He is involved in industry rulemaking activities within the regulatory agencies concerned with flight crew training, including EASA with whom he is registered as an independent FSTD SME. Previously Mark was Director Regulatory Affairs for TRU Simulation & Training and held various positions at Rediffusion, Hughes Rediffusion, Thomson/Thales Training & Simulation, and Mechtronix. He is a recipient of the Halldale CAT magazine Aviation Pioneer award and the FSEMC Edwin A. Link Award for his service to the flight simulation industry.

Reprinted by permission of Sim Ops (https://www.sim-ops.com/).

Times are hard in our industry and it looks like not all Training Device Manufacturers (TDM) are going to stay the course. What happens to long-term support of your Flight Simulation Training Device (FSTD) when the TDM goes out of business?

There are three big concerns that you will need to consider: your ability to update the FSTD software (for which you need source code), the ability to maintain and update the Master Qualification Test Guide (MQTG), and the availability of spare parts.

1. Updating the FSTD Source Code

To be clear, by source code we mean the software needed to implement changes to the simulation of the aircraft performance, systems, the environment and the cueing systems. Not that many years ago nearly all commercial aviation FSTDs were delivered with the source code; indeed, it was in some cases the only location where a complete load existed. However, now all the TDMs restrict or deny operators access to source code, protecting their intellectual property as well as that of the aircraft and avionics OEMs, thus limiting the degree of change or customisation an operator can make without reference to the TDM.

Why the change? Back in the day, the TDM used to produce the complete simulation, perhaps using a few stimulated as-aircraft line replacement units (LRU). But in the 1990s, with the advent of more advanced aircraft types, that changed. First, we had the move toward re-hosting or re-targeting of the software in these LRUs and the subsequent integrated modular avionics (IMA) hosted loadable software aircraft parts (LSAP). This was closely followed by the intrusion of export controls associated with dual-use technologies, first manifesting itself with controls on electronic engine control (EEC) systems. Finally, the aircraft manufacturers, for various motives, restricted the contents of the aircraft systems and performance model data packages they previously licenced to the TDMs, instead replacing this data with their own, obligatory simulations provided in executable form only. That is to say that even if the TDMs wanted to provide full source code they cannot, as in many cases they do not have access to it themselves.

We then have the issue that the world has moved to an era of intellectual property (IP) and intellectual property rights (IPR) protection. Add in the more nationalistic pose taken by some governments, the corporate ownership of some of the TDMs, and again this has resulted in further restrictions on the TDM’s ability to deliver source code.

That all said, it was also extremely galling for the TDMs when they saw small third-party companies come along and update an FSTD that they had previously manufactured and sold, at very low margins in many cases, thus denying them winning the more lucrative updates revenue; if the TDMs could prevent this they obviously did. Restricting source code availability was and is, not unreasonably, one way of achieving this.

Need solutions to your current set of problems? Join WATS 2021 (World Aviation Training Summit) LIVE in Orlando, Florida on June 15-16 2021 as we move 'Forward Together'. The world's largest gathering of aviation training professionals serving airlines, regulators, training providers and the training industry, designed by and for aviation professionals.  Find out more

Will I be able to get source code if I want to? Yes and no. Some of the code on a modern FSTD is simply not in the TDM’s gift to provide or give access to, or more accurately to sell you. If you are requesting the source code during the procurement phase of a new FSTD you will have some leverage but requesting it after the delivery is going to be a much harder discussion.

The TDM will probably offer to place the source code in escrow, whereby the source code is held by a trusted third party (the escrow agent) and only released should certain predefined conditions be met (eg, the TDM withdraws support or goes out of business); even this is not a total guarantee.

They have given me access to source code so I am OK, right? Well, maybe. Having the source code is only one step along the path to self sufficiency; there are a number of other items to put in place.

There will be a number of tools, developed by the TDM and third-party purchased, that you will require in order to create and build a new load. Items such as the compiler (assuming your TDM uses a commercial off the shelf (COTS) compiler) can be purchased but some of the tools are developed by the TDM. For example, on the latest data-centric aircraft the TDMs have developed tools that read in the aircraft OEM interface control document (ICD) data to automatically populate the FSTD variable databases whenever aircraft standard or blockpoint updates are released from the aircraft or avionics OEMs. To be really sure of self sufficiency you will need the source code for these tools in case of future changes to the aircraft data formats, not an unheard-of event.

You will also need to be careful to ensure you receive all the TDM software and you are able to change it. With the use of modern high-level languages, the TDMs have naturally taken advantage and produced software reliant on pre-compiled libraries when compiling the full simulation load.

And finally, you will need to ensure you have access to the appropriate engineering capabilities, both personnel and facilities, to use the source code and tools.

Escrow Considerations. Just because you have negotiated an escrow agreement, that is not necessarily full protection. As we have seen, the TDMs will not be able to, or be permitted to, place all the source code in escrow. Particularly for LRUs that are re-targeted they are usually not permitted to distribute the code they receive from the LRU OEMs. As an operator you will need to ensure you have agreements in place with the LRU OEMs in order to permit this; spoiler alert: they may not be inclined to grant this, and it certainly won’t be free.

Now assuming that all the obstacles in getting all the elements you or your selected software developer will need have been identified, including finding a reliable escrow agent, you now need to make sure there is a robust software build and control process in place. As most people in our industry will attest, an FSTD is rarely perfect at Ready For Training (RFT); there are normally Discrepancies Reports (DRs) outstanding. As each of these DRs are corrected the associated software changes will need to be uploaded to the escrow agent for safekeeping; bear in mind that some of these DRs may linger on long past the warranty period so updating escrow becomes an ongoing process that needs to be managed rather than put off, hoping it will never be needed.

2. MQTG Maintenance

Whilst some of the TDMs deliver tools that allow operators the ability to run Qualification Test Guide (QTG) tests and the ability to create and modify the MQTG, others do not. If your FSTD is from a TDM that has not delivered to you the full ability to manage your MQTG (including the validation resource data) you may have serious problems should the TDM not be there. Every time the FSTD is re-qualified there is the risk that your authority may ask for a change (eg, new tests to encompass new training regulations). Every time you replace hardware such as a speaker or projector or cueing hardware you may need to re-master relevant objective tests. If there are any aircraft standard updates or you add a thrust rating or other aircraft enhancement then you may need to re-master. And if you were to relocate the device you would certainly need to re-master. Remember, under all jurisdictions we know, the responsibility for the QTG rests with the operator in any case.

So what do you need? Normally there are two elements required: the software tools that manage the QTG resource data, the QTG scripts and supplementary data that creates the MQTG, be that a physical document or an electronic eQTG. The second element being the database holding your device's particular information.

Need solutions to your current set of problems? Join WATS 2021 (World Aviation Training Summit) LIVE in Orlando, Florida on June 15-16 2021 as we move 'Forward Together'. The world's largest gathering of aviation training professionals serving airlines, regulators, training providers and the training industry, designed by and for aviation professionals.  Find out more

3. Spare Parts Availability

First the good news: the increased use of COTS components in recent years, whilst having their own problems by way of obsolescence, will be your friend should the TDM stop supporting you. Unfortunately that is probably where the good news stops.

The parts that will cause most problems as time goes by are those designed and manufactured by the TDM. This will be exacerbated by the probable absence of detailed drawings within the data package received from the TDM when the FSTD was delivered. Whereas at one time a full drawing package would have been delivered with FSTDs the practice in modern times has been to only deliver assembly-level drawings, insufficient to manufacture parts (deliberately so). Sadly, even if you are lucky enough to have a “full” drawing package, it will probably be insufficient to give to an alternate manufacturer of parts, with the advent of computer-aided design (CAD), many machined parts are manufactured from the models, the drawings only have dimensions for inspection purposes.

But machined parts should not be a major problem; even without a drawing a reasonably resourceful technician should be able to find a solution. The big problem will be electronic parts including printed circuit boards (PCBs). There are companies who are very good at repairing parts with minimal information but there is a limit to what can be repaired; a burnt card will need to be replaced. Here again, even with the detailed drawings your troubles are not over. PCB manufacturers asked to just produce a few PCBs will not be keen to do so. They have to buy chips in large quantities so if a PCB has any non-standard chips they will have to charge you for the whole batch. Then there is the machine set-up time to consider; while it takes just a couple of minutes to make a PCB it takes several hours to set-up the machine to make a particular board. So unless you can find other operators who are willing to join in on a joint buy of a batch the price will be very high, an order of magnitude higher than you might have paid while the TDM was in production.

If the problems of getting the drawings, designs, and persuading someone to make the parts were not enough to give you nightmares you will then have to confront the problem of firmware. The TDMs have taken advantage of programmable components within their designs, including field-programmable gate arrays (FPGA) and single-board computers (SBC). Unless you can get access to the TDM’s firmware and its source code, even the boards you get made will be just objets d’art without the firmware.

So, what can you do?

The first thing is to approach your TDM with a list of the data you need for ongoing support.

For the source code issue we have seen that escrow is, frankly, unlikely to work. The chances of getting access to the source out of escrow after RFT, it being complete, up-to-date and being able to use it are minimal. That isn’t to say you shouldn’t make all efforts to obtain the code. But make sure that, prior to the TDM finally closing the door, you ensure that either your engineers or a nominated third party has confirmed the source code and all offline tools and utilities are complete and that you are able to compile a new load (that runs!).

For the QTG tools and database we would normally encourage all operators to take control of their own MQTG at all times. But if you suspect the TDM is in trouble it becomes imperative to make sure you get both tools and databases from them.

For spare parts, again, request the drawings (not forgetting firmware); also ask for the CAD models and Interface Control Documents (ICD) for electronic devices. Review your spares holdings with respect to historical usage and see if you can do a last-time buy. Then make contact with other operators of the same FSTD technology you are trying to support.

Of course some people may well give up trying to support their devices, selling them on or breaking them up for spares, and such opportunities will release spare parts onto the after-market, so keep your eyes and ears open.