In 2016 the FSEMC published Arinc report 446 entitled Guidance For Flight Training Device Documentation Structure, Content, and Maintenance. As with all the FSEMC reports this was compiled by industry representatives with a high level of knowledge in the topic. However we recently quoted this document as part of a Request for Proposal (RFP) we were writing on behalf of a customer, one of the responses we got back from a bidder is best summarised as “you’ve got to be joking, we can’t supply all that”.
So, is there something wrong with Arinc report 446?
The ARINC guide is divided into two main sections, Simulator Operational Documentation and Simulator Support Documentation. The operational documentation is the easier of the two for the Training Device Manufacturers (TDMs) to supply as listed in the report. There may be variations in the detail in some areas and the names. And some of the documents may be more useful than others, for example we’re not convinced on the usefulness of IOS guides, as with any application, if you need to start reading a manual to be able to use an IOS you have to question its design! But you’ll get what you need.
The difficulties come with the support documentation.
For maintenance documentation, the maintenance manual. A446 sensibly splits the requirements into;
Troubleshooting guide
Scheduled maintenance manual
First line maintenance manuals
Second line maintenance manuals
Troubleshooting guides can tend to be simplistic. The TDMs often just don’t have the experience to write these, particularly when the FSTD design is new. To be blunt, we have seen some that are basically a tick box exercise just to say they have supplied them. Scheduled maintenance should not cause significant problems to any TDM, apart from thinking of meaningful things to put into them, on a modern FSTD there is precious little scheduled/preventative maintenance needed.
The difficulties start to arise in the recommendation for the second line maintenance manuals. These are intended to give the recipient the capability to repair replaced Line Replaceable Units (LRU) off the device and frankly the days of these being supplied have long since passed. Apart from the fact that nobody is going to want to pay for them to be written, with the rise of Commercial Off The Shelf (COTS) equipment the data just isn’t available (the “right to repair” may take a while to flow down to COTS used on an FSTD).
Similarly there are difficulties when we get to the request for dimensioned mechanical drawings; here in the first instance the TDMs will not want to supply them (think of them in the same vein as source code) but notwithstanding that in a lot of instances they just don’t exist. Certainly for machined parts they will have been designed on a CAD/CAM terminal and machined directly from the digital design. Any 2D drawings are merely for record purposes and any dimensions on them purely for QA checking.
The section on Parts and Equipment Lists is realistic in its ambitions, the start of the section includes the phrase “as comprehensive as possible”. Although the request for the TDM to provide operators with full contact details of where all parts are sourced from is unlikely to be met. Indeed we have been told recently of one TDM informing a supplier that they are not permitted to deal directly with operators of the TDM’s equipment. We have also heard of operators expecting complete illustrated parts catalogues, as one receives for an aircraft, again this is not going to happen due to the costs involved.
Then there is Software documentation. We’ve covered the topics of source code delivery and product loads in previous blogs; the likelihood of having the complete set of documentation detailed in the report is just the same as getting access to source code. What is needed though is to make sure documentation is delivered that covers the operations that you are getting the ability to do. For example you need to know how to do basic things like updating the Ground Station Data (GSD) and how to manage loads on the device. If your TDM has given you the ability to change other items, such as IOS controls, you need that documentation.
So what have we learnt?
Well the first thing is that there is nothing wrong with the ARINC Report, as it says on the cover, it is a guide; not a specification. While the requirements for each category are well written not all categories are relevant to all procurements.
When we referenced it in the RFP we should not have just said comply with A446, we should have specified the documents/data required and pointed to the report to help the bidders. Looking forward, what we will do in the future is produce a matrix listing all the items detailed in A446, indicate where they are mandatory (for example a facilities requirement document) and allow the bidders to indicate which they have or where they provide the same information but in an alternate format. In fact that would be a good addition to the document itself.
Looking more widely at the documentation the TDMs supply there is for sure a wide range of methods of delivery, depth of content and compliance with A446; some are definitely better than others but, in general, you will get what you need. If we had to advise one thing though it would be to thoroughly review the documentation at the earliest possibility and raise discrepancies against them before the device warranty is over. We have seen a B737 FFS delivered with instructions on how to change the cards running the Airbus flight controls software!
How can Sim Ops help?
If you are preparing a RFP we can guide you through the whole process, in the case of documentation we can make sure you get what you need. We can also review the supplied documents and do the acceptance on your behalf.
Comments