Part one of this Blog looked at the parts that make up the physical flight deck of a Flight Simulation Training Device (FSTD) and discussed the virtues and limitations of simulated parts. This week we look at the most emotive of the topics in the debate and try to put the arguments in perspective.
What parts are we talking about?
Back in the day we used to refer to these as the “Black Boxes”, a term still popular in the media. These were the discrete units fitted in the avionics bays of the aircraft and used to control different systems.
Simulate, stimulate, re-host/re-target or Grey Box
So what are the options available to the Training Device Manufacturers (TDMs) when they come to simulate these?
Simulate (model in software) – this is where the TDM’s write their own software to simulate the LRUs. This gives the TDM full control of the functionality and the interfaces and of course, any future updates!
Unfortunately with the increase in complexity of modern systems and the increasing difficulty of obtaining data, this methodology is not now viable for anything but the most simple of systems or if you can obtain the data to do so.
Stimulate – use the as-aircraft hardware. On the face of it this would seem the easiest option, just plonk the Line Replaceable Unit (LRU) in the simulator, wire it up and everything will be fine; unfortunately as with many things in life it is not always that easy. First issue can be the sheer number of signals and the different data bus types; this adds to the complexity of the device and adds hardware to drive these. The LRUs can also have stringent environmental issues, such as cooling, that need to be provided; for some LRUs this is further complicated by having to be within a limited distance of flight deck components forcing them to be installed onboard the FSTD (for example Head-up Guidance System (HGS) image generators).
Having solved these issues comes the most difficult issue, that of simulator-specific functions such as re-positions, flight freeze and position slews; although the LRU manufacturers have been encouraged to support these some LRUs just do not support them (see our blog “a hommage to Arinc report 610“ for a description of Arinc 610). That said some of the LRU manufacturers did, in the past, provide the industry with specific LRU software, so-called “SimSoft” but that has now been passed by.
Also, although now largely overtaken by Operational Program Configuration (OPC) files, there is also the question of pin-selected options where certain options are enabled by grounding certain pins or combinations of pins on the LRU connector.
Then there is the financial issue, not only are the LRUs expensive to buy in the first place but there is also the cost of providing the interfacing to them. Plus, unless you are an airline, the question of spares comes in. Holding millions of dollars worth of aircraft LRUs is just not an option for independent training centres.
All that said, there are still advocates for the reasons that updating is the same as an aircraft and there is no question that it will function as an aircraft. Although should an update involve the aircraft unit expecting a new signal not provided by the TDM, there will still be software to be modified on the FSTD to provide it.
Re-hosting and Re-targeting
Both of these solutions involve taking the software from the as aircraft unit and running on the FSTD outside of the original as aircraft hardware. We have seen the terms used interchangeably in some places, but they are very different in their implementation. The data required for these has been defined in two Arinc reports (Arinc 441 and Arinc 442, where the terms Unmodified Binary Format Software and Modified Binary Format Software are used).
Re-host - the as aircraft operational code, as compiled, is run on the FSTD on different hardware that replicates the environment of the aircraft hardware.
Re-target - the as aircraft source code compiled to run on a different chipset.
Note, the use of either of these solutions does not alleviate the need to implement Arinc 610 functionality in the code; for a rehost implementation this has to be done by the Original Equipment Manufacturer (OEM) whereas for a re-target solution it could possibly be done by the TDM (although not a trivial task).
There are some top-quality FSTDs in service that utilise these methodologies, indeed if this approach had not been adopted in the early 1990s when the first Integrated Modular Avionics (IMA) based aircraft were being developed it is hard to see how cost-effective FSTDs could have been produced.
So, re-hosting or retargeting looks like the obvious approach, the others can be forgotten? Not quite. Both approaches rely on a high degree of assistance from the OEMs, some have had to set up departments for this purpose. And, crucially, the re-target solution relies on the TDM being given access to the OEM’s Intellectual Property (IP); something they are reluctant, or sometimes forbidden by export control limitations to do.
Then with re-target there is the question of the compiler, can it be guaranteed to provide the same result as that for the as aircraft unit?
This term started appearing when the OEMs (avionic and aircraft manufacturers) started providing their own solutions At first these were delivered as bespoke hardware that the TDMs had to integrate into the FSTD. Most of these have now evolved into software packages that are implemented on the FSTD by the TDM. This, along with OEM-supplied aircraft simulation packages (a topic for another blog) has allowed TDMs that are newcomers to the market to offer devices more easily.
Most of these are developments of simulations used on the OEM's own test rigs and stations and offer reliable simulations.
So what’s the answer?
Two English sayings immediately spring to mind; “you pays your money and you takes your chance” and “horses for courses”. Oh and of course a third, “Hobson’s choice”.
You pays your money and you takes your chance - where it is possible that the TDM can offer a choice of solution it simply becomes a matter of costs vs benefits. But, make sure you test devices with both solutions before you spin the coin and make your choice.
Horses for courses - some systems are better simulated by one solution over the others. We can assure you that the TDMs will have spent many months during a new aircraft programme to find what they think is the best solution.
Hobson’s choice - unfortunately, whatever your preference, you will probably be left with no choice nowadays. Increasingly it is the OEMs that are making the choices and will only offer to support their chosen solution. However before criticising them be aware of the constraints they are under with export controls and IP considerations. But it does bring to mind a fourth English saying, that being “like it or lump it”.
There is disquiet in some quarters that the imposition by the OEMs of their own solutions is stifling innovation, the point has merit. However the OEMs might justifiably counter that the important things are to have a solution that supports the training needs and is affordable. Next time you are at FSEMC remember this blog when the topic, as it normally does, surfaces.
How can Sim Ops Help?
At Sim Ops we can help you ensure that at the point of purchase this complex issue is addressed contractually. As with most things, it is important to look at the pros and cons during the RFP process.