If there is one document that is indispensable in the design of Flight Training Devices (FSTDs) it is Arinc Report 610 (A610) published by the Flight Simulation Engineering and Maintenance Committee (FSEMC). This month we thought we would look at the document in more detail and just why it is so pivotal in the design of an FSTD.
What is it?
This remarkable document was first published over thirty six years ago, in 1986, and it defines the simulator specific functions that need to be implemented on an FSTD to turn it into a training device.
Why was the report needed?
The need for a standard was directly linked to the transition from analogue to digital aircraft systems. Up until the digitalisation of aircraft an aircraft’s systems could be simulated purely from the aircrafts wiring and system schematic diagrams backed up with observations from the aircraft. In the early 1980s systems started to appear where the functionality was defined by either digital logic (combinational or sequential; still easily simulated when the logic diagrams were available) or by software; it was with software where the problems arose.
The first response of the Training Device Manufacturers (TDMs) was to integrate and stimulate the as aircraft units, the “black boxes”, in their FSTDs. Leaving aside the cost of the units this led to problems; the main one of these being the incompatibility of simulator specific functions with the internal fault checking of the units. Take for example a Flight Management Computer (FMC) subjected to a reposition in a FSTD where its altitude and Lat/Long is changed by a large amount in milliseconds. Most FMCs identified this as an error, it just couldn’t happen in the aircraft, and shut down. Another problem was units that had limited error log memories that could only be reset in a weight on wheels condition that overflowed in the FSTD.
Hence the TDMs started to lobby the aircraft and avionics manufacturers to make adaptations so the units could be used on a FSTD. What quickly became apparent was the disconnect in language of the avionics designers to that of the simulation engineers. There was no common point of reference and each of the TDMs specified what they needed slightly differently and confused the aircraft and avionics manufacturers.
What does the report do?
Ater giving an overview of the architecture of a typical FSTD most of the report is given over to a detailed description of the simulator specific functions giving examples of how each function is used in a FSTD. This produced a document that could be supplied to an engineer at an avionics manufacturer, who might have little or no knowledge of a FSTD, to understand exactly what would be required of their design if used in a FSTD and, importantly, why.
It also had implications beyond its primary purpose. Whilst it fulfilled its main role in communicating exactly the functionality required to be supported by the aircraft units it also served to better define and standardise the functionality needed for training from an FSTD. No matter which TDM a particular FSTD is made by, the chances are that if you sit at the Instructors Operating Station (IOS) the functionalities detailed in A610 will be available at the IOS and function as defined in it.
And it worked, although there are a few exceptions, the aircraft and avionics manufacturers adopted the standard. A phrase not often heard now, but still pertinent, is “Simsoft”, one of the early adopters of A610 was Honeywell who provided their Simsoft load for the FMC which went into Boeing 757, 767 and 747 along with the Airbus A300/310 aircraft. This was loaded into the navigation database memory space (along with the navigation database) and provided access to the A610 functions.
Today compliance to A610 is normally written into the system requirements at the start of new aircraft programmes.
So is it still relevant?
Very much so. Over the years, as well as being extended to add military considerations, it has been regularly revised to keep pace with aircraft and FSTD technology developments. Among those have been the advent of Integrated Modular Avionics (IMA) architectures and data centric architectures on the aircraft together with the advent of the use of the as aircraft software on FSTDs, be that using re-hosted or re-targeted solutions.
So whilst the initial emphasis was to inform the aircraft and avionics Original Equipment Manufacturers (OEMs) what the TDMs required to use the “black boxes” in an FSTD it nowadays informs them what is required on the software loads provided. Bear in mind that on some FSTDs there is now more “as aircraft” code running on the device than code written by the TDM. Hence in fact its relevance has, if anything, increased; whilst on the early aircraft software was limited to a few discrete units carrying out specific functions, now practically every aircraft system is affected. During the definition phase of one such aircraft we recall a meeting with the hydraulics system supplier who had stated their software could be used in the FSTD without modification; this position changed once it was pointed out we needed to re-stow the Ram Air Turbine (RAT) in the air.
Conclusion
Arinc Report 610, currently at revision C, is one of the most seminal documents in the industry. Whilst we may today take for granted the ability of an FSTD IOS to allow re-position, flight freezes, change fuel loads etc without the work of the industry team that put A610 together it might have been different. Arinc 610 is available from the SAE industries website.
How can SIM OPS help?
SIM OPS have the necessary experience to assist either new TDMs or avionic suppliers on these issues. Last year we referred to it in our blog “standing-on-the-shoulders-of-giants”.