ARINC 434-2 - FSTD Life Cycle Support

FLIGHT SIMULATION TRAINING DEVICE
(FSTD) – LIFE CYCLE SUPPORT
ARINC REPORT 434-2
PUBLISHED: October 16, 2019
Prepared by the FSEMC

Published by
SAE ITC
16701 Melford Blvd., Suite 120, Bowie, Maryland 20715 USA
DISCLAIMER
THIS DOCUMENT IS BASED ON MATERIAL SUBMITTED BY VARIOUS PARTICIPANTS

DURING THE DRAFTING PROCESS. NEITHER AEEC, AMC, FSEMC NOR SAE ITC HAS
MADE ANY DETERMINATION WHETHER THESE MATERIALS COULD BE SUBJECT TO
VALID CLAIMS OF PATENT, COPYRIGHT OR OTHER PROPRIETARY RIGHTS BY THIRD
PARTIES, AND NO REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, IS
MADE IN THIS REGARD.
ARINC INDUSTRY ACTIVITIES USES REASONABLE EFFORTS TO DEVELOP AND

MAINTAIN THESE DOCUMENTS. HOWEVER, NO CERTIFICATION OR WARRANTY IS
MADE AS TO THE TECHNICAL ACCURACY OR SUFFICIENCY OF THE DOCUMENTS,
THE ADEQUACY, MERCHANTABILITY, FITNESS FOR INTENDED PURPOSE OR
SAFETY OF ANY PRODUCTS, COMPONENTS, OR SYSTEMS DESIGNED, TESTED,
RATED, INSTALLED OR OPERATED IN ACCORDANCE WITH ANY ASPECT OF THIS
DOCUMENT OR THE ABSENCE OF RISK OR HAZARD ASSOCIATED WITH SUCH
PRODUCTS, COMPONENTS, OR SYSTEMS. THE USER OF THIS DOCUMENT
ACKNOWLEDGES THAT IT SHALL BE SOLELY RESPONSIBLE FOR ANY LOSS, CLAIM
OR DAMAGE THAT IT MAY INCUR IN CONNECTION WITH ITS USE OF OR RELIANCE
ON THIS DOCUMENT, AND SHALL HOLD AEEC, AMC, FSEMC, SAE ITC, AND ANY
PARTY THAT PARTICIPATED IN THE DRAFTING OF THE DOCUMENT HARMLESS
AGAINST ANY CLAIM ARISING FROM ITS USE OF THE STANDARD.
THE USE IN THIS DOCUMENT OF ANY TERM, SUCH AS SHALL OR MUST, IS NOT
INTENDED TO AFFECT THE STATUS OF THIS DOCUMENT AS A VOLUNTARY
STANDARD OR IN ANY WAY TO MODIFY THE ABOVE DISCLAIMER. NOTHING HEREIN
SHALL BE DEEMED TO REQUIRE ANY PROVIDER OF EQUIPMENT TO INCORPORATE
ANY ELEMENT OF THIS STANDARD IN ITS PRODUCT. HOWEVER, VENDORS WHICH
REPRESENT THAT THEIR PRODUCTS ARE COMPLIANT WITH THIS STANDARD SHALL
BE DEEMED ALSO TO HAVE REPRESENTED THAT THEIR PRODUCTS CONTAIN OR
CONFORM TO THE FEATURES THAT ARE DESCRIBED AS MUST OR SHALL IN THE
STANDARD.
ANY USE OF OR RELIANCE ON THIS DOCUMENT SHALL CONSTITUTE AN

ACCEPTANCE THEREOF “AS IS” AND BE SUBJECT TO THIS DISCLAIMER.
This document is published information as defined by 15 CFR Section 734.7 of the Export Administration Regulations (EAR). As publicly available technology under 15 CFR 74.3(b)(3), it is not
subject to the EAR and does not have an ECCN. It may be exported without an export license.
©2019 BY
SAE INDUSTRY TECHNOLOGIES CONSORTIA (SAE ITC)
16701 MELFORD BLVD., SUITE 120, BOWIE, MARYLAND 20715 USA
ARINC REPORT 434-2
FLIGHT SIMULATION TRAINING DEVICE (FSTD) – LIFE CYCLE SUPPORT
Published: October 16, 2019
Prepared by the Flight Simulator Engineering and Maintenance Committee

Adopted by the FSEMC Steering Committee
Adoption Date Published Date
Report 434 April 3, 2001 May 15, 2001
Supplements to this ARINC Standard
Report 434-1 November 23, 2005 January 20, 2006
Report 434-2 July 15, 2019 October 16, 2019
A summary of the changes introduced by each supplement is included at the end of this document.
FOREWORD
The AEEC, SAE ITC, and ARINC Standards
ARINC Industry Activities, an SAE ITC program, organizes aviation industry committees
and participates in related industry activities that benefit aviation at large by providing
technical leadership and guidance. These activities directly support aviation industry
goals: promote safety, efficiency, regularity, and cost-effectiveness in aircraft operations.
ARINC Industry Activities organizes and provides the secretariat for international aviation
organizations (AEEC, AMC, FSEMC) which coordinate the work of aviation industry
technical professionals and lead the development of technical standards for airborne
electronic equipment, aircraft maintenance equipment and practices, and flight simulator
equipment used in commercial, military, and business aviation. The AEEC, AMC, and
FSEMC develop consensus-based, voluntary standards that are published by SAE ITC
and are known as ARINC Standards. The use of ARINC Standards results in substantial
technical and economic benefit to the aviation industry.
There are three classes of ARINC Standards:
a) ARINC Characteristics – Define the form, fit, function, and interfaces of avionics
and other airline electronic equipment. ARINC Characteristics indicate to
prospective manufacturers of airline electronic equipment the considered and
coordinated opinion of the airline technical community concerning the requisites of
new equipment including standardized physical and electrical characteristics to
foster interchangeability and competition.
b) ARINC Specifications – Are principally used to define either the physical

packaging or mounting of avionics equipment, data communication standards, or
a high-level computer language.
c) ARINC Reports – Provide guidelines or general information found by the airlines

to be good practices, often related to avionics maintenance and support.
The release of an ARINC Standard does not obligate any organization to purchase
equipment so described, nor does it establish or indicate recognition or the existence of
an operational requirement for such equipment, nor does it constitute endorsement of any
manufacturer’s product designed or built to meet the ARINC Standard.
In order to facilitate the continuous product improvement of this ARINC Standard, two
items are included in the back of this document:
An Errata Report solicits any corrections to existing text or diagrams that may be
included in a future Supplement to this ARINC Standard.
An ARINC IA Project Initiation/Modification (APIM) form solicits any proposals for

the addition of technical material to this ARINC Standard.
ii
ARINC REPORT 434
TABLE OF CONTENTS
1.0 INTRODUCTION ......................................................................................................... 1

1.1 Purpose and Goals...................................................................................................... 1
1.2 Scope .................................................................................................................... 1
1.3 Definitions ................................................................................................................... 1
1.4 Related Documents ..................................................................................................... 2
2.0 COMMUNICATION ..................................................................................................... 3
2.1 Introduction ................................................................................................................. 3
2.1.1 Customer and Supplier Points of Contact ............................................................... 3
2.2 Customer Fault Reporting ........................................................................................... 4
2.3 Suppliers to Customers ............................................................................................... 6
2.4 Customers to Suppliers ............................................................................................... 7
2.5 Customer to Customer ................................................................................................ 7
2.6 Knowledge Database .................................................................................................. 7
3.0 PROCUREMENT AND INITIAL SERVICE OF A NEW FLIGHT SIMULATION
TRAINING DEVICE ..................................................................................................... 8
3.1 Aircraft Contracts......................................................................................................... 8
3.1.1 Procurement of a Used FSTD ................................................................................. 8
3.2 Specification ................................................................................................................ 9
3.2.1 Contract ................................................................................................................ 10
3.3 Site Survey/Facility Requirements ............................................................................. 10
3.4 FSTD Design and Build ............................................................................................. 10
3.4.1 Safety .................................................................................................................. 10
3.4.2 Freeze Dates ........................................................................................................ 10
3.4.3 Technology ........................................................................................................... 10
3.4.4 Maintainability ....................................................................................................... 10
3.4.5 Documentation ..................................................................................................... 11
3.4.6 Parts .................................................................................................................. 11
3.4.7 Improvements and Enhancements ....................................................................... 11
3.4.8 Design Reviews .................................................................................................... 11
3.4.9 Environmental Considerations .............................................................................. 11
3.5 Initial Spares ............................................................................................................. 11
3.5.1 Ongoing Spares.................................................................................................... 11
3.6 In-Plant Acceptance .................................................................................................. 12
3.6.1 Simulation Fidelity and Crew Training Acceptance ............................................... 12
3.7 Site Installation .......................................................................................................... 13
3.8 Site Acceptance ........................................................................................................ 13
3.9 Initial Regulatory Qualification ................................................................................... 13
3.10 Ready for Training ..................................................................................................... 14
3.11 Contractual Availability Demonstration ...................................................................... 14
3.11.1 Availability ............................................................................................................ 14
3.11.2 Availability Calculation .......................................................................................... 14
3.12 Field Service Representative ..................................................................................... 15
4.0 DOCUMENTATION................................................................................................... 16
4.1 Initial Documentation Delivered by Manufacturer ...................................................... 16
4.2 Documentation Revisions .......................................................................................... 17
5.0 TECHNICAL AND INSTRUCTOR TRAINING ........................................................... 18
5.1 Technical Staff Training ............................................................................................. 18
5.2 FSTD Crew Instructor Training .................................................................................. 18
6.0 CONFIGURATION MANAGEMENT .......................................................................... 19
iii
ARINC Report 434 – Page iv
ARINC REPORT 434

TABLE OF CONTENTS
6.1 Introduction ............................................................................................................... 19

6.1.1 Simulator Specific Software and Database Management...................................... 19
6.2 Configuration Control Guidelines – Initial Acceptance ............................................... 19
6.3 Configuration Control Guidelines – RFT .................................................................... 19
6.4 Configuration Control Guidelines – Post RFT ............................................................ 19
6.5 Compatibility.............................................................................................................. 20
6.6 Tracking Changes in the Modeled Aircraft ................................................................. 20
7.0 SCHEDULED MAINTENANCE ................................................................................. 21
7.1 Preventive Maintenance ............................................................................................ 21
7.2 Other Scheduled Maintenance Activities ................................................................... 21
7.2.1 Backups................................................................................................................ 21
7.2.2 QTG .................................................................................................................. 22
7.3 Aging Components Issues......................................................................................... 22
7.3.1 Areas of Consideration: ........................................................................................ 22
7.3.1.1 Electrolytic Capacitors...................................................................................... 22
7.3.1.2 Erasable Programable Read Only Memory (EPROM) ...................................... 23
7.3.1.3 Battery Backup Random Access Memory (BBRAM) ........................................ 23
7.3.1.4 Electrical Wiring ............................................................................................... 23
7.3.1.5 Hydraulic Components ..................................................................................... 23
7.3.1.6 Motion Base ..................................................................................................... 23
7.3.1.7 Accessway and Maintenance Platforms ........................................................... 23
7.3.1.8 Batteries........................................................................................................... 23
7.4 Emergency Preparedness Recovery ......................................................................... 23
8.0 UNSCHEDULED MAINTENANCE ............................................................................ 25
8.1 General .................................................................................................................. 25
8.2 Troubleshooting ........................................................................................................ 25
8.2.1 Diagnostic Tools ................................................................................................... 25
8.2.2 Documenting the Solution ..................................................................................... 25
8.2.3 Feedback to Training ............................................................................................ 26
8.3 Deferred Maintenance ............................................................................................... 26
9.0 SPARES AND CONSUMABLES MANAGEMENT ..................................................... 27
9.1 General .................................................................................................................. 27
9.2 Initial Spares ............................................................................................................. 27
9.2.1 Spares Philosophy ................................................................................................ 27
9.2.1.1 Logistics ........................................................................................................... 28
9.2.1.2 Repair Capabilities “On-Site” or Nearby ........................................................... 28
9.2.1.3 LRU in Aircraft Stores ...................................................................................... 28
9.2.1.4 Use of Simulated Parts .................................................................................... 28
9.2.1.5 Warranty Conditions and Duration ................................................................... 28
9.2.1.6 Consignment Spares........................................................................................ 28
9.2.1.7 Potential AOG Items ........................................................................................ 28
9.3 Repair .................................................................................................................. 28
9.4 Last Time Buy ........................................................................................................... 29
9.5 Component Level Repair Versus LRU Repair ........................................................... 29
10.0 OBSOLESCENCE MANAGEMENT .......................................................................... 30
10.1 Obsolescence, Notification, and Minimizing Cost ...................................................... 30
10.1.1 Purpose and Goals ............................................................................................... 30
10.1.2 Background .......................................................................................................... 31
iv
ARINC REPORT 434
TABLE OF CONTENTS
10.2 Obsolescence Resolution .......................................................................................... 31

10.2.1 Obsolescence Identification .................................................................................. 31
10.2.2 Resolution Options ............................................................................................... 31
11.0 FSTD IMPROVEMENTS ........................................................................................... 33
11.1 General .................................................................................................................. 33
11.2 New Equipment or Systems ...................................................................................... 33
11.2.1 Obsolescence or Lack of a Trained Technician Pool ............................................ 33
11.2.2 Higher Qualification Level ..................................................................................... 33
11.2.3 Lack of Reliability .................................................................................................. 34
11.2.4 Improve Maintainability Through Improved Efficiency ........................................... 34
11.3 Relocation ................................................................................................................. 34
11.4 Change of Regulatory Approval Level ....................................................................... 34
11.4.1 Upgrade................................................................................................................ 34
11.4.2 Downgrade ........................................................................................................... 35
11.5 New Visual Data Base ............................................................................................... 35
12.0 HIBERNATION/RELOCATION/DECOMMISSIONING .............................................. 36
12.1 Hibernation ................................................................................................................ 36
12.1.1 Areas of Consideration ......................................................................................... 36
12.2 Detailed Breakdown of Considerations ...................................................................... 37
12.2.1 Obtaining Baseline Data (QTG or Maintenance-Only Data) .................................. 37
12.2.2 Open Discrepancy Resolution .............................................................................. 37
12.2.3 Hardware Inventory .............................................................................................. 37
12.2.4 Documentation ..................................................................................................... 37
12.2.5 Maintaining Software Configuration Control .......................................................... 37
12.2.6 Data Backup (Including Non-Volatile Random Access Memory (NVRAM)
Boot Data for Host or Satellite Processors) ........................................................... 37
12.2.7 Procedure Development and Validation ................................................................ 37
12.2.8 Security ................................................................................................................ 38
12.3 Subsystem Special Considerations ........................................................................... 38
12.3.1 Host Computer Complex....................................................................................... 38
12.3.2 Visual System ....................................................................................................... 38
12.3.3 Linkage ................................................................................................................. 38
12.3.4 Motion .................................................................................................................. 38
12.3.5 Controls ................................................................................................................ 38
12.3.6 Hydraulic Power Unit ............................................................................................ 39
12.3.7 Power Supplies ..................................................................................................... 39
12.4 Facilities .................................................................................................................. 39
12.5 Return to Service....................................................................................................... 39
12.5.1 Visual Inspection .................................................................................................. 40
12.5.2 Hardware Inventory and Spare Parts Availability .................................................. 40
12.5.3 Records Review and Documentation .................................................................... 40
12.5.4 Software ............................................................................................................... 40
12.5.5 Computer Equipment and Settings ....................................................................... 40
12.5.6 Facilities ............................................................................................................... 40
12.5.7 Power Supplies and Linkage ................................................................................ 40
12.5.8 Hydraulic Power Unit ............................................................................................ 40
12.5.9 Motion and Controls.............................................................................................. 41
12.5.10 Visual System ....................................................................................................... 41
12.5.11 Host Computer Complex....................................................................................... 41
12.5.12 Preventative Maintenance .................................................................................... 41
12.5.13 Verifying Baseline Data (ATMs and QTGs) ........................................................... 41
v
ARINC Report 434 – Page vi
ARINC REPORT 434

TABLE OF CONTENTS
12.6 Relocation ................................................................................................................. 41

12.7 Decommissioning ...................................................................................................... 42
12.8 Environmental Consideration .................................................................................... 42
13.0 SOFTWARE QUALITY .............................................................................................. 43
13.1 General .................................................................................................................. 43
13.2 Establishment of Software Quality ............................................................................. 43
14.0 QUALITY ASSURANCE ............................................................................................ 44
14.1 Introduction ............................................................................................................... 44
14.2 FSTD Health Metrics ................................................................................................. 44
14.3 FSTD Maintenance Cost Metrics ............................................................................... 46
14.4 Combining FSTD Health and Cost Metrics ................................................................ 46
ATTACHMENTS
ATTACHMENT 1 REPRESENTATIVE PREVENTIVE MAINTENANCE ACTIONS ................ 48
ATTACHMENT 2 PREVENTATIVE MAINTENANCE LOG .................................................... 54
ATTACHMENT 3 REQUIRED GROUNDING CHECKS FOR FULL FLIGHT SIMULATORS.. 55
APPENDICES
APPENDIX A ACRONYM LIST ........................................................................................ 60
APPENDIX B EXAMPLE VISUAL MODEL ACCEPTANCE CHECKLIST ......................... 62
vi
ARINC REPORT 434 – Page 1
1.0 INTRODUCTION
1.0 INTRODUCTION
1.1 Purpose and Goals
The purpose of ARINC Report 434 is to provide practical recommendations, based
on the collective experience of the Flight Simulation Training Device (FSTD)
community, for improving operational reliability and maintainability throughout the
life cycle of a training device. It is hoped that formulating industry guidelines will lead
to mutually defined (customer and supplier) goals for FSTD reliability,
maintainability, and overall life-cycle cost management.
Particular emphasis is provided on recommendations for procurement, preventive
maintenance, improved troubleshooting of problems, increased device reliability,
decision making guidelines for upgrading a training device, and better
communication methods between customers and suppliers of FSTDs. It is
recommended that contracts for the supply of FSTDs include a reference to this
document.
Furthermore, the intent of this document is to provide a collection of maintenance
best practices. While it is not intended to be used directly as a contractual
document, it could be useful in considering contractual requirements for an FSTD
purchase.
1.2 Scope
This document will address measures pertaining to and directly associated with the
maintainability and reliability of FSTDs throughout their entire life cycle, from initial
specification and design to de-commissioning. Although the primary emphasis of
this document is on full flight simulators (with motion and visual systems), it should
be applicable in part or total to all FSTDs.
1.3 Definitions
Reliability: The ability of an FSTD to perform consistently with full functionality and
without interruption over a specified period of time.
Maintainability: The ease of keeping an FSTD consistently available for its
prescribed use. Maintainability has three components: scheduled maintenance,
unscheduled maintenance, and device improvements. Examples of each are:
Scheduled Maintenance
• Preventive maintenance
• Navigation data base updates
• Lesson plans
• Qualification test guide for recurring activity and support
Unscheduled Maintenance
• Interruptions to ongoing training
• Failure
o Addressed immediately
o Deferred
1.0 INTRODUCTION
• Discrepancy
o Addressed immediately
o Deferred
Device Improvements
• Device improvements to reduce maintenance time and/or costs
• Device improvements to increase reliability
• Device improvements to reduce dependence on an obsolete component or
system
• Changes to maintain currency of the FSTD with the aircraft it simulates
• Changes mandated by regulatory authorities
• Changes to add or improve device functionality and/or training capabilities
1.4 Related Documents
The latest version of the referenced documents applies.
ARINC Report 432: Training Requirements for Flight Training Equipment Support
Personnel
ARINC Report 433: Standard Measurements for Flight Simulator Quality
ARINC Report 436: Guidelines for Electronic Qualification Test Guide
ARINC Report 437: Guidelines for Training Facilities
ARINC Report 438: Guidance for Acceptance of Flight Simulation Training Devices
ARINC Report 440: Guidelines for the Provisioning and Support of Training
Equipment Data
ARINC Report 441: Guidelines for the Supply of Binary Format Software for
Training Purposes
ARINC Report 442: Guidelines for the Supply of Source Code/Electronic Block
Diagrams for Training Purposes
ARINC Report 445: Guidance for Configuration and Control of Loadable Software
Parts in Flight Simulation Training Devices
ARINC Report 446: Guidance for Flight Training Device Documentation Structure,
Content, and Maintenance
ARINC Specification 450: Flight Simulator Design and Performance Data
Requirements
Additional related documents are:
ARINC Report 662: Strategies to Address Electronic Component Obsolescence in
Commercial Aircraft
2.0 COMMUNICATION
2.0 COMMUNICATION
2.1 Introduction
This section presents a model for customer-supplier communication based on the
initial relationship between the Training Device Manufacturer (TDM) and the original
customer. It is recommended that a similar model for communication be used with
each “supplier” involved over the life cycle of the FSTD. If third party companies are
employed later in the life cycle to incorporate FSTD improvements, a similar model
should be followed there as well.
Over the life cycle of an FSTD, there are a number of different entities that fulfill the
role of a supplier including:
• The aircraft manufacturer, who supplies data, technical information,
software, and parts, both software and hardware.
• The TDM who designs, builds, and integrates the overall FSTD.
• The visual system manufacturer (if applicable).
• Suppliers of aircraft and simulated instruments, avionics, aircraft parts, and
hardware.
2.1.1 Customer and Supplier Points of Contact
Two-way communications documented and with identified persons as the main
focus point are the key to the success of a project and should be emphasized
throughout the life cycle of a simulator. To achieve this goal, the supplier should
assign a single point of contact who will be actively involved from contract award
and work with the Marketing Representative. Typically, in most of the TDM
organizations, a Project Management Representative (PMR) would fulfill this role.
To ensure a seamless transition once the project is complete, the PMR should also
work from the beginning, in close relationship with the Customer Support
Representative (CSR).
The customer should provide a primary and a secondary point of contact to interface
with the suppliers’ representative. Over the course of the FSTD project, a number of
meetings are normally held between the customer and the TDM. In some cases,
other parties are also involved depending on the type and complexity of the project.
Depending on the complexity of the project and the maturity of the FSTD, some of
these meetings may not be required or may be combined. Typical meetings include:
• Project Kick-Off Meeting – This meeting allows the customer team and the
TDM project team to meet and exchange contact information. Initial
questions are answered and any needed clarifications are provided.
Schedules and expectations are discussed and agreed.
• Preliminary Design Review – The TDM presents initial hardware and
software design concepts and approaches, and seeks customer
concurrence. Current progress is reviewed, and any open issues are
discussed and resolved. Initial discussions regarding logistics functions such
as installation, training, and documentation are held.
• Critical Design Review – The TDM presents the matured designs for review.
The initial discussions held in the Preliminary Design Review are
progressed. Again, current progress is reviewed, and any open issues are
discussed and resolved.
2.0 COMMUNICATION
• Project Review Meeting – The TDM and customer should hold regular
review meetings to follow up on all important project issues. These can be
scheduled as appropriate.
These meetings can be held in any number of ways, face-to-face, WebEx,
teleconferences, or any other suitable format. Other meetings can be included if
necessary, such as Test Readiness Reviews. As well, during the course of the
FSTD testing, it would be expected that further meetings are held. The purpose of
these meetings is to ensure that the customer and TDM communicate well,
understand each other’s positions and obligations, and that expectations of both
parties are well managed. Only documented communication between the customer
and supplier are considered binding.
Following Ready for Training (RFT), at an agreed appropriate point in time if the
project is to be handed-over to Customer Support, the CSR should then fulfill this
single point of contact role. All project information should be transferred to Customer
Support, including contract obligations, project history, previous communication, and
outstanding issues. The customer should be advised of this point of contact change
as it becomes effective.
Effective information exchanges require common data elements to be shared
between customer and supplier databases, so that at any given time they contain
current information. The databases can reside in multiple locations, but should be
accessible to both the customer and the supplier at any time, and should reflect the
latest status. The most effective and common vehicles for satisfying these
requirements are online databases accessible via the Internet. Both suppliers and
customers should be encouraged to make effective use of these tools.
The databases may contain:
• Minutes of all supplier/customer meetings.
• All deficiency/snag reports, including those corrected by the customer.
• All communication by email or letters regarding the project.
• The communications should be capable of being sorted by person, date, and
subject.
• Deliverable documentation.
2.2 Customer Fault Reporting
Customers are encouraged to provide notification to suppliers as early as possible
concerning any important customer support issues (e.g., parts, software faults,
personnel).
The supplier should acknowledge receipt of the fault and provide feedback and
guidance back to the customer in a timely manner.
2.0 COMMUNICATION
The following table recommends the data elements to be provided by both customer
and supplier:
Table 2-1 – Definitions for Customer Fault Reporting
Field Name Description Customers Suppliers
Unique Number Assigned to each report by the
Tracking Number X X
supplier
Date Report Submitted X
Aircraft on Ground (AOG)
Causes frequent training interruptions
Impact to training Urgent X
Able to work around
Not Urgent
The customer should be specific about when the
Fix Needed-By Date X
problem must be fixed
Includes:
Specific aircraft type including variant – e.g.,

B767-300, A350, etc.
Device Type X X
Full Flight Simulator (FFS), Push to Talk (PTT),
Cockpit Procedures Trainer (CPT), Computer Based
Training (CBT), etc.
Device ID, i.e., Supplier’s ID
Originator Name Person’s name submitting report X
Contact Name Person to contact X
Contact Phone X
Contact email X
Company X
Site Address X
Address to return
X*
repaired equipment to
Name of person to
return repaired
X*
equipment to if different
from contact (recipient)
Fault Type Hardware/Software/Other X
Item that failed (e.g., software package, autopilot,
Description X*
documentation, discrepancy)
PN and Revision X*
SN X*
Used On Next Higher Assy, if available X*
Hours in Use X*
This is the all-important field – a complete, detailed
description of the fault, including a description of the
situation/condition under which it occurred is
essential. If the problem is software, attach or
provide hardcopies of Instructor Operating Station
Fault Description (IOS) screens to capture aircraft configurations, X
status, and geographic locations. Provide fault or
diagnostic report hardcopies or softcopies as
available. Provide any relevant log files or data or
memory dumps.
2.0 COMMUNICATION
Field Name Description Customers Suppliers

In some cases, time history recordings including
useful parameters in an agreed format may ease
support.
The description of the issue may include a summary

of the expected behavior and the observed
discrepancies in order to ease investigation.
Disposition X
Assigned to Person problem assigned to. Provides accountability. X
Contact Phone X
Contact email X
Offer Date Date solution is to be provided by the supplier. X
In Work
Status X
Shipping details
Brief description of action taken to fix problem,
Corrective action X
including parts replaced where applicable.
Date the problem was fixed or parts returned to
Date Corrected X
customer.
* If applicable
Proper resolution of a reported fault requires complete and comprehensive
information to be provided by the customer to the supplier. Particular attention
should be given to the fault description, including as much detail as possible.
COMMENTARY
The customer should include information on post RFT improvements
not performed by the TDM.
The customer should be able to log into a supplier’s system using a tracking number
to ascertain the current status.
In the event of No Fault Found (NFF) or Cannot Duplicate (CND), the supplier
should contact the customer to agree on an appropriate course of action.
2.3 Suppliers to Customers
Suppliers should provide sufficient information and status reporting to enable their
customers to maintain and support their in-service FSTD throughout its life cycle.
Such information and reporting may include:
• Service bulletins, service letters, and customer advisories.
• Fleet specific software corrections.
• Notices of software and utility updates.
• Available FSTD improvements.
• Spares and repair status.
• Technical query status.
• Discrepancy status.
• Feedback and recommendations based on submitted information per
Section 2.4.
2.0 COMMUNICATION
2.4 Customers to Suppliers

Customers should create a report that is based upon Section 3.0 of ARINC Report
433: Standard Measurements for Flight Simulator Quality as well as Section 14.0 of
this document. This should be accomplished at a time interval that is mutually
agreed upon between the customer and supplier.
Each FSTD, and if applicable, each visual system, should be assigned a unique
identifier.
Customers should notify suppliers of any and all FSTD status changes (e.g., sale,
FSTD improvements or major updates, decommissioning, or site relocation). In the
case of sale, this may be mandatory due to the issues of data transfer and software
license issuance.
2.5 Customer to Customer
Ongoing engineering and maintenance communication (e.g., tips) should be
facilitated using online forums or other media.
2.6 Knowledge Database
This concept provides the FSTD community (customers and suppliers) with the
ability to share knowledge.
Some examples of information contained in the knowledge database may include:
• Resolving defects
• Obsolescence issues
• Users’ tips, etc.
The value of this data base is directly proportional to the willingness of all of the
community to share such information.
3.0 PROCUREMENT AND INITIAL SERVICE OF A NEW FLIGHT SIMULATION TRAINING DEVICE
3.0 PROCUREMENT AND INITIAL SERVICE OF A NEW FLIGHT SIMULATION TRAINING

DEVICE
3.1 Aircraft Contracts
In cases of negotiation and procurement of a new or additional aircraft type to the
operator’s fleet, it is important for the FSTD organization to have input into the
aircraft procurement process. Ideally, the aircraft contract should include the
procurement of sufficient aircraft parts, data, and licenses that will be required for
the manufacture and operation of the operator’s FSTDs. The procurement should
include the following documents as part of its specification:
ARINC Report 440: Guidelines for the Provisioning and Support of Training
Equipment Data
ARINC Report 441: Guidelines for the Supply of Binary Format Software for
Training Purposes
ARINC Report 442: Guidelines for the Supply of Source Code/Electronic Block
Diagrams for Training Purposes
ARINC Specification 450: Flight Simulator Design and Performance Data
Requirements
The customer should make certain that the data license will be applicable to all
FSTDs, both firm and options, and also for any lower level devices as may be
required. It is important to establish the priority of simulator parts, how red label
parts are going to be updated, and that the aircraft manufacturer should provide
flexibility in the approach taken to the simulation of various systems.
In some cases, the aircraft manufacturer provides software or systems that perform
the simulation or modeling of some or all of the components of the aircraft. In this
case, the aircraft manufacturer takes on part of the role of the TDM. The
responsibilities and obligations that would have been the TDM’s for that software or
those systems now become the responsibility and obligation of the aircraft
manufacturer. Throughout this document, where it reads TDM, the term TDM would
also include aircraft manufacturer wherever such software and systems are part of
the FSTD.
3.1.1 Procurement of a Used FSTD
This report generally deals with the procurement of a new FSTD from an FSTD
Original Equipment Manufacturer (OEM). In some cases, operators may purchase
used FSTDs from third parties, typically other operators. There are a few
considerations that a buyer of a used FSTD will need to consider:
• Does the third-party seller have the legal right to sell that FSTD to the
prospective purchaser and convey the licenses and data to the purchaser?
There will likely be some licenses that the seller cannot convey.
• For the licenses and data that are not transferable, the prospective
purchaser will have to make separate agreements with the license and data
holders to transfer those licenses. This likely will require new licenses and
may involve license transfer fees or costs.
• The FSTD OEM likely has no obligation to support the FSTD once the third
party sells it. Any terms of an agreement between the OEM FSTD
manufacturer and the original owner may expire or become null and void
once the FSTD is sold. New support from the FSTD OEM may require a new
support agreement be negotiated and may involve extra costs.
• Support from the FSTD OEM may be limited depending on the state of the
device when it is sold. If there are many unauthorized or undocumented
changes, then the OEM’s ability to support the FSTD may be limited.
• Transfer of documentation and sources, to the extent applicable, may also
be subject to separate licensing agreements with other parties.
• In the time between the FSTD OEM has delivered the FSTD initially and the
time it is sold to a new operator, it is possible that changes have been made
to the FSTD. There are more considerations for these:
o Changes may have been made that were not documented or were
insufficiently documented. It will be the new buyer’s problem to
determine if there are any such cases and how they should be resolved.
o Changes may have been made by third parties under contract to the
previous owner(s). It is possible that the licenses and data for these
changes require additional licensing to be transferred.
If an operator plans to purchase a used device, this report can act as a guideline or
aide-memoire for all the aspects of the purchase. Although it deals with the
purchase of a new FSTD, each of the sections provides information on what a
prospective buyer should consider in purchasing a used FSTD. For example, the
Documentation section discusses what documentation a customer should expect to
get when buying a new FSTD. The buyer of a used FSTD should be asking the
seller to provide that same set of documentation as part of the sale. If that
documentation package is not complete, the buyer should make himself aware of
the deficiencies and determine what might need to be done about them.
3.2 Specification
The Customer’s Request for Proposal (RFP) establishes the type of FSTD(s)
needed, the regulatory authority qualification level of the trainer needed, the location
the device will be operating in, the type of aircraft to be modeled, existing FSTD
FSTDs at the final location, and any additional requirements the customer may
have. The RFP can be as detailed as appropriate to the customer’s requirements.
The TDM will generate a Technical Specification based on the customer’s RFP.
The earliest opportunity to impact the long-term maintainability and reliability of an
FSTD is during the technical specification generation. This document should be
carefully reviewed and agreed upon by the TDM and customer at the earliest
possible date, before the contract for the FSTD is executed. It should detail all
expectations of the design, build, and acceptance, as well as demonstrate all
aspects of quality, maintainability, logistic elements, long term support, and
reliability. It is recommended that the technical specifications include the
requirements of this report as well as:
• ARINC Report 432: Training Requirements for Flight Training Equipment
Support Personnel
• ARINC Report 433: Standard Measurements for Flight Simulation Quality
• ARINC Specification 450: Flight Simulator Design and Performance Data
Requirements
Any of the items discussed in the balance of Section 3.0 that are of importance to
the customer should be documented in the purchase agreement or specification.
The specification should describe all software development and support utilities
required to support the FSTD throughout its life cycle.
3.2.1 Contract
The contract or purchase agreement should address the long-term support
relationship between the TDM and the customer. Care should be taken to clearly
specify the committed support period, warranties, tools and test equipment,
diagnostics utilities, self-reporting of errors, maintenance workstation,
documentation, training, spares, availability, maintainability demonstrations, and all
other support issues, including software support warranties and licenses.
For more information refer to ARINC Specification 450: Flight Simulator Design
and Performance Data Requirements.
3.3 Site Survey/Facility Requirements
For survey and training device facility requirements refer to ARINC Report 437:
Guidelines for Training Facilities.
3.4 FSTD Design and Build
When designing and building an FSTD, a variety of issues should be considered.
3.4.1 Safety
All equipment should comply with local regulatory safety requirements associated
with the area in which the FSTD will be installed. In addition, the manufacturer
should take into consideration ergonomic human engineering issues. Warning and
caution stickers should be appropriately placed and easily visible. Use of hazardous
material should be kept to an absolute minimum. When used, appropriate
identification and handling procedures should be provided in the system
documentation.
3.4.2 Freeze Dates
These are dates on the FSTD design, build, and acceptance schedule that identify
when specific events are to be achieved or when design baselines are to be frozen.
Customer changes initiated beyond the applicable freeze dates may compromise
proper acceptance, and thereby impact long-term maintainability and reliability.
3.4.3 Technology
Availability of technology is a primary consideration in the design and build of an
FSTD. Due to the long lead time associated with the build and the rate at which
technology becomes obsolete, the design phase must consider the balance
between proven reliability of current technology and the potential advantages of new
technology. This is a critical factor in the long-term maintainability of the FSTD.
3.4.4 Maintainability
The FSTD should be designed and built taking ease of maintenance in
consideration. Access to all components that need to be maintained or may need to
be replaced should be considered. Diagnostic tools, either hardware or software,
that allow the maintenance team to find and resolve faults quickly are important.
See Section 1.3 for more details.
3.4.5 Documentation
The documentation should to accurately reflect the hardware and software build of
the FSTD and should be provided on delivery.
For more information, reference ARINC Report 446: Guidance for Flight Training
Device Documentation Structure, Content, and Maintenance. See Section 4.0 for
more details.
3.4.6 Parts
Whenever possible, commonality between parts should be considered during the
design of the FSTD. This should help reduce the number of spares required to
support the FSTD. Special application parts should be limited and kept to an
absolute minimum. Interchangeability with current inventory and delivered FSTDs
should also be considered when building a new FSTD.
3.4.7 Improvements and Enhancements
During the life cycle of an FSTD, the requirements for improvements and
enhancements come from various categories. The ease with which these changes
can be made are directly affected by the initial design of the FSTD. Equipment
cabinets should be designed with extra space for future expansions. Current
systems should be designed in a modular format for ease of removal and
replacement. Cable runs and break-out panels should be designed with additional
room for expansion. Input/output chassis should be designed with spare channels
and expandability. Computer systems should be designed with spare memory and
spare computational time.
3.4.8 Design Reviews
The customer should hold initial and ongoing design reviews, starting immediately
after the contract is signed. It may be beneficial to have a customer representative
on site during the software development and hardware/software integration phase of
the build, possibly even participating as a team member in the overall FSTD build.
3.4.9 Environmental Considerations
The design should also address appropriate environmental considerations
associated with the FSTD throughout its life cycle, including:
• Compliance with all applicable standards and regulations.
• Sourcing of materials, including environmental considerations such as types
and numbers of parts, power consumption, cooling requirements, packaging,
reduction of pollutants, etc.
• Operational considerations, including power consumption, consumable
products, use of hazardous materials, waste disposal, reuse of obsolete
products and materials, etc.
3.5 Initial Spares
See Section 9.0.
3.5.1 Ongoing Spares
See Section 9.0.
3.6 In-Plant Acceptance

In-Plant Acceptance (IPA), or Factory Acceptance Testing (FAT), is the initial testing
of the FSTD performed at the FSTD’s facility.
A careful review and correlation between the Acceptance Test Manuals (ATM) and
the technical specification should be conducted by the customer prior to start of
acceptance. The ATMs may require updates based on this review prior to the start
of IPA.
Prior to the start of IPA, the status of the FSTD should be reviewed to ensure that it
is ready for testing. The customer and the TDM should review and agree on the
process for performing the testing, including the recording of any deficiencies
discovered. A configuration control process for the FSTD while it is under test
should also be agreed upon.
For more information, reference ARINC Report 438: Guidance for Acceptance of
Flight Simulation Training Devices.
Due to operational requirements, in-plant acceptance may often be shortened or not
fully completed. This practice should be discouraged, and sufficient time (based on
past experience) needs to be scheduled so that a full and thorough in-plant
acceptance is accomplished. Failure to do so can have long-term effects from both
the customer and TDM point of view. Time should be allocated during in-plant
acceptance, and if possible, after the end of in-plant acceptance, in order to allow
the TDM to investigate and correct identified deficiencies while the FSTD is still in
plant.
In most FSTD procurements, there seems to be significant pressure to compromise
the amount of engineering and maintenance-related acceptance testing that is done.
In-plant acceptance is the best opportunity to discover problems and initiate
corrective action. Many solutions that might be possible at an TDM facility will
become far more difficult and costly once the FSTD is on-site due to lack of
engineering or fabrication resources. One method to overcome this problem is to
assign customer personnel to the build and integration phase of the project, so that
engineering acceptance can be performed on an incremental basis. A secondary
benefit of doing this is that it is an excellent training opportunity for the customer.
COMMENTARY
Acceptance duration should take in account the maturity of the
aircraft type baseline.
3.6.1 Simulation Fidelity and Crew Training Acceptance
The in-plant acceptance should consist of the following, as a minimum:
• Full system tests using the applicable system ATMs.
• Qualification Test Guide (QTG) checks for both manual and automatic QTG
cases.
• QTG repeatability.
• Any special utilities, tooling, etc., required to run a QTG.
• Instructor Operating Station (IOS) pages, functionality, and help.
• Malfunction checkout for description versus effect.
• Tests for aircraft and/or engine type conversions (if applicable).
• Operational training checks, where the simulator is used as it will be after

RFT for a defined period. This will verify simulator reliability and many other
systems that are not always part of the official acceptance.
3.7 Site Installation
The installation is a critical milestone in the acquisition of an FSTD. The customer
should play an active role in the installation whenever possible, and this should be
an integral part of the acceptance process. The opportunity to work hand-in-hand
with the manufacturer is an invaluable opportunity, including practical knowledge
that the customer will gain. This is also a prime opportunity for the engineering and
maintenance staff to see how the FSTD is assembled, and to become familiar with
the many procedures for both hardware and software that they might not encounter
during routine FSTD use.
Current FSTD designs may incorporate internal computer networks to interconnect
the various components of the device. Operators may plan to connect the FSTD to
their local network, their company intranet, or to the Internet. This should be done
with caution. At a minimum, the FSTD internal networks should not be connected to
any external networks. The FSTD should only be connected to an external network
through a single gateway, which could be another Personal Computer (PC), a
router, or any type of device that can provide isolation and protection against
malicious software attacks. It can be very useful to set up the FSTD so the TDM can
obtain remote access to the FSTD. This can help allow for rapid resolution of
problems, remote diagnostics, simple on-line updates and other features. The
customer has to carefully monitor how this is connected to maintain a proper level of
cybersecurity.
3.8 Site Acceptance
In-Field Acceptance (IFA), On-Site Acceptance (OSA), or Site Acceptance Testing
(SAT), is generally the final testing of the FSTD performed at the customer’s facility.
After successful completion of this testing, the FSTD undergoes Regulatory
Qualification.
Site acceptance provides similar opportunities to those documented in Sections 3.6
and 3.7, both during the crew training and technical/maintenance portions of this
activity. If a thorough in-plant acceptance has been conducted, the customer can
use the site acceptance time to focus more on operational issues than on testing,
and to assess the FSTD’s reliability in a real training environment.
Special attention should be given to any items that could not be completed during
in-plant acceptance, to the resolution of any outstanding deficiencies, and to any
system that interfaces with the customer’s facility. Special tools and test equipment
should be checked during this phase.
3.9 Initial Regulatory Qualification
It is important that a complete baseline be established of the initial approved
hardware and software configuration, and that the customer knows how it was
completed, where it is stored, etc. It is recommended that the customer document

and archive all critical load information, including, but not limited to:
• Accepted qualification load.
• Full system backup.
• Sub-systems unique software and firmware backup (e.g., visual, controls,
motion, sound, etc.).
• Master QTG.
• ATMs, including control and motion maintenance plots.
COMMENTARY
Although the TDM will support the initial qualification, it is the
customer who has the responsibility of presenting the FSTD to the
regulatory agency for qualification. The customer must be familiar
with the qualification process and the operation of the device. The
customer should be prepared to answer the authorities’ questions or
be capable of getting answers.
3.10 Ready for Training
Following RFT, it is recommended that time be allocated in the FSTD schedule for
the following activities:
• Professional instructor training (running of all training profiles).
• Line qualified instructor training.
• Technical staff familiarization.
• Discrepancies/snag (manufacturer) clearance.
3.11 Contractual Availability Demonstration
3.11.1 Availability
It should be demonstrated that the availability of the FSTD meets all contractual
requirements. This assumes that normal preventive maintenance procedures are
adhered to, and that an adequate supply of spare parts is available at the
customer’s site, as recommended by the supplier.
3.11.2 Availability Calculation
Simulator availability should be calculated using ARINC Report 433: Standard
Measurements for Flight Simulation Quality.
The contractual availability figure should not be impacted by:
• Failures that do not prevent the completion of training, based upon
regulatory requirements.
• Failures caused by human errors.
• Failures caused by incorrect or neglected maintenance procedures, (e.g.,
lack of correct preventive maintenance).
• Failures caused by input power and/or environmental conditions exceeding
the FSTD specification.
• Failures of peripheral equipment not directly affecting the training program.
• Failures of original aircraft equipment and/or instruments for which the

supplier has no design control.
• Inherent design limitations of visual system (if other than the visual system of
the flight simulator supplier).
COMMENTARY
Multiple failures of a single component or system, even if they do not
cause overall availability to fall below the specified level, should be
grounds for investigation.
3.12 Field Service Representative
FSTD support agreements may include the provision for a Field Service
Representative (FSR) to support the customer following RFT for a predetermined
amount of time. The support supplied by an FSR should be clearly defined in the
contractual phase of the relationship and should be determined by the customer’s
needs for technical and training support.
4.0 DOCUMENTATION
4.0 DOCUMENTATION
4.1 Initial Documentation Delivered by Manufacturer
Documentation should be provided in accordance with ARINC Report 446:
Guidance for Flight Training Device Documentation Structure, Content, and
Maintenance.
The customers prefer that Commercial Off The Shelf (COTS) tools are used to
provide documentation. The tools, including revision level, should be made available
so that they are able to update the documentation as needed.
As an aid to enhance the supplier’s documentation, supplier personnel should use
the customer’s supplied documentation during the device integration and testing
phase.
The supplier should provide and integrate all additional documentation used to
support device installation (e.g., engineering notes, set-up procedures, etc.).
The customer should verify all documentation, including test and performance
evaluation, which needs to be carried out by a mutually agreed-to date. The
supplier, along with the customer, should ensure the operational functionality of all
utilities provided using an ATM.
FSTD manufacturers are encouraged to obtain and provide below information to the
FSTD user when working with third party suppliers. This information will prove
useful over the lifecycle of the FSTD.
Where possible, third party information should include:
• Schematics to a level that allows component-level repair.
• Illustrated Parts Breakdown.
• Maintenance Manual, including calibration and alignment procedures.
• Identification of special tools and test equipment.
For third party suppliers, FSTD customers prefer that all documentation be included
to the same level as supplied by the prime supplier. All exceptions to this should be
clearly stated. Documentation that is unavailable should be clearly identified at the
earliest possible time, so as to allow the customer and supplier to consider other
alternatives.
Documentation should be easy to access, search, annotate, update, and should
include revision control. Documentation accuracy should be ensured by all parties.
Master copies of all electronic documentation should be provided. Electronic
documentation should be implemented on a separate computer with linkage to the
host computer. Electronic documentation should be available in a stand-alone mode
that can be copied to multiple devices for ease in FSTD maintenance. This
documentation should be linked to fault detection and correlation utilities.
The documentation should allow accurate fault isolation and repair of time-critical
maintenance tasks (e.g., training day interrupts), as well as provide information for
the repair of components to the appropriate level during non-training periods.
Finally, customers should provide feedback to suppliers via supplier provided
surveys. In cases where the documentation may be found to be incorrect, the
supplier should include a mechanism to encourage feedback. The supplier should
acknowledge receipt of the feedback and provide correction.
4.0 DOCUMENTATION
FSTD warranty periods should also include the documentation. It should be possible
to generate valid discrepancy reports for deficient or missing documentation.
4.2 Documentation Revisions
Maintaining accurate documentation is an ongoing process throughout the life of the
equipment.
1. Initial Acquisition: The documentation should be compared to the equipment
as delivered. Building facilities’ interfaces, such as wall power, air
conditioning, water, and drains should be included in the documentation.
2. Ongoing support: When a discrepancy in the documentation is found, it
should be corrected as soon as possible.
3. Changes to documentation due to local modifications/improvements: These
changes should be identified and integrated into the original documentation
in such a way as to make the reader aware that the document has been
changed.
COMMENTARY
A separate volume of troubleshooting notes and maintenance
information could be cross-referenced to the documentation. This will
aid in understanding the trends of problems that are being corrected
on the equipment. This may be an informal publication.
5.0 TECHNICAL AND INSTRUCTOR TRAINING
5.0 TECHNICAL AND INSTRUCTOR TRAINING

5.1 Technical Staff Training
Training should be defined in accordance with the guidance provided in ARINC
Report 432: Training Requirements for Flight Training Equipment Support
Personnel.
5.2 FSTD Crew Instructor Training
To ensure proper operation, crew instructor training should be deemed as important
as technical training. The TDM should supply an initial instructor manual in
electronic format Areas of training should include:
• Reporting FSTD faults on an Electronic Discrepancy Log or a Hard Copy
Discrepancy Log (if not provided by the customer).
• Interpretation of FSTD Minimum Equipment List (MEL) (if not provided by the
customer).
• Training session quality (see ARINC Report 433, Section 3.1).
• Operation of all features of the instructor station, including normal operation,
malfunctions (with full description of the intended effects of the malfunctions
and any associated delays and triggers), etc.
• Lesson plan creation and editing.
• Safety features and procedures.
6.0 CONFIGURATION MANAGEMENT

6.1 Introduction
If required by the customer, configuration control should be established to document
each and every change that is made to the hardware and software of an FSTD.
When implemented, it will allow correlation between changes made and any
negative effects caused by those changes. Proper configuration control will allow
recovery back to a known baseline.
Configuration control should begin at customer acceptance, and then be maintained
for the life of the FSTD.
6.1.1 Simulator Specific Software and Database Management
The sections below are general descriptions and guidance that an airline or operator
should consider throughout the lifetime of a FSTD.
In the case of software and databases, more in-depth guidance is provided in
ARINC Report 445: Guidance for Configuration and Control of Loadable Software
Parts in Flight Simulation Training Devices.
6.2 Configuration Control Guidelines – Initial Acceptance
The supplier and customer, prior to the start of acceptance, should define and agree
to configuration control guidelines to be used throughout acceptance.
The supplier should provide a configuration tool for hardware and software.
Prior to a working software load becoming an acceptance load, it should be tested
by the supplier, and offered to the customer with an explanation of all the changes
made.
COMMENTARY
Hardware or software changes made during acceptance may require
retesting of certain systems (ATMs/QTGs).
6.3 Configuration Control Guidelines – RFT
The supplier and customer should produce a configuration audit listing in electronic
format for all parts (e.g., software, firmware, and hardware), including revision
levels, serial numbers, and hours in service. The supplier should also provide a
comprehensive listing of the aircraft manufacturer’s data package, including the
revision level used in the FSTD.
The customer prefers that COTS tools be used to provide the configuration audit
listing. These tools should be provided to update the configuration audit listing. The
supplier should also provide all of the tools and utilities required to maintain
configuration control following RFT.
As a result of regulatory approval, the acceptance load becomes the current training
load.
6.4 Configuration Control Guidelines – Post RFT
The customer should document all modifications to software, hardware, and
firmware, with a description of the changes, and their impact to the FSTD.
Configuration control should include all software, firmware, and hardware required
to run, maintain, and upgrade the simulator. There should also be configuration
control for satellite computers or PCs.
The customer should establish a configuration control coordinator. Before any work
is performed on an FSTD, the person performing the work should communicate with
the configuration control coordinator.
Certain types of changes to an FSTD require notification and/or advanced approval
of regulatory authorities.
COMMENTARY
Caution should be taken to ensure the supplier personnel follow the
customer’s configuration control policies during site acceptance and
post-RFT discrepancy.
6.5 Compatibility
The supplier should provide compatibility documentation to the customer, identifying
revision level configuration at RFT, including backward and forward compatibility for
firmware and hardware with respect to PN and revision status.
6.6 Tracking Changes in the Modeled Aircraft
During an FSTD’s life, it may be necessary to modify aircraft equipment or simulated
aircraft systems (Section 11.0). Modifications to an FSTD due to cockpit equipment
and/or aircraft systems changes should be considered when:
• The aircraft (specific tail number) that the FSTD is modeled after is modified.
• A significant percentage of the aircraft fleet simulated has been modified.
• As required by regulatory authorities.
• As specifically requested by the FSTD user.
In some organizations, tracking of aircraft configuration can be facilitated by
establishing methods of communication between aircraft engineering and FSTD
engineering.
Changes to aircraft data packages are communicated to aircraft operators by the
aircraft OEM. These updates should also be communicated to the FSTD
engineering department. Third party FSTD operators should establish methods of
communication with aircraft manufacturers, or their customer’s aircraft engineering
departments. In many cases, there is not a regulatory requirement to modify FSTD
performance to reflect these changes.
Some modifications of this type could impact the maintainability and reliability of the
FSTD. The decision must be made whether to utilize aircraft equipment, or FSTD-
only equipment. Advantages and disadvantages exist in both cases, and the
operator’s choice will depend on their specific circumstances. Spare part availability
should also be considered.
Any introduction of changes should be coordinated with the training department of
the customer, including the timing of the change. Additionally, appropriate
notification to instructors with updated instructions should be provided.
7.0 SCHEDULED MAINTENANCE

7.1 Preventive Maintenance
Preventive maintenance is required to minimize in-training faults and subsequent
lost training time.
Preventive maintenance includes actions taken at specified frequencies to test and
check FSTD sub-systems, FSTD performance, and the replacement of
consumables to ensure optimum performance and availability.
Preventive maintenance is initially derived from the aircraft OEM data package,
which provides suggested maintenance activities necessary at defined frequencies.
An example is contained in Attachment 1.
Preventive maintenance should also consider:
• Updates to operating systems, virus protection, etc.
• Running FSTD diagnostics and reviewing results, which check the cause of
any displayed error messages (Section 8.2). It may be helpful to archive
these results.
• Running sections of the ATM to ensure that FSTD performance remains
within specification.
• Time should be set-aside during preventive maintenance for checking the
performance of spare Line Replaceable Units (LRU) to ensure that they
perform within specification. Records of the date and results should be
recorded.
The results from preventive maintenance should be compared to previous results in
order to analyze trends.
The recording of all preventive maintenance activities is essential. An example of a
Preventive Maintenance Log is contained in Attachment 4. All faults should be
recorded on a fault reporting form similar to the one shown in Attachment 2.
Alternately, the recording of these activities can be performed in an electronic or
computer-based system.
Preventive maintenance reviews should be performed frequently and compared to
FSTD performance metrics (ARINC 433), OEM data updates, data collected from
fault report forms (derived from corrective maintenance), and maintenance data.
The preventive maintenance schedules should be constantly reviewed to anticipate
and rectify potential FSTD failures by decreasing intervals between defined
scheduled tasks or adding maintenance tasks to the schedule. An ongoing review
and updates to preventive maintenance tasks should lead to improved FSTD
availability.
7.2 Other Scheduled Maintenance Activities
7.2.1 Backups
An archiving strategy should be employed to provide for a regular and consistent of
backing up the system, including any changes. This can be on separate physical
disks, servers, or other types of storage. Depending on the type of storage, backup
schemes may vary. These backups are intended to minimize the risk of lost
simulator training time. Any devices that are part of the FSTD that have their own
unique data or software storage should also be included in the backup process.
Additionally, the following types of backups should be kept:

• Permanent archive of initial acceptance and qualification load(s).
• Archive after every periodic regulatory review.
• Arrangements should be made to store backups at a remote location outside
the facility.
COMMENTARY
Recommendations include:
1. Disk-to-Disk Backup: This backup should be performed every 2
weeks, or when significant changes have been made to the simulator
configuration.
2. Full Backup: This backup should be performed quarterly onto another
media. To ensure that the backup is problem free, it is strongly
suggested that Full Backups be restored onto a spare drive for
testing. Once restored, the host computer should be rebooted and
trained on, using the restored disk.
3. In order for suppliers to provide support in the unlikely event of a disk
crash, it is recommended that customers send a copy of their Full
Backups on a bi-annual basis. In the event of a disk crash, this will
allow the supplier to restore disks on an in-house system, thus
greatly improving support.
Note: Tape backups require special care. Therefore, it is advisable
to re-tension the tape annually to prevent oxide coating from
sticking to back of tape, (rewind tape full forward and back) at
a minimum of once a year.
7.2.2 QTG
Regulatory authorities require that QTG tests are run periodically. By including them
in the customer’s preventive maintenance system, it ensures they are done on a
regular basis, and any problems that are discovered are corrected quickly. This
ensures that the operator remains in compliance with regulatory requirements, and it
greatly eases periodic recurrent evaluations.
ARINC Report 436: Guidelines for Electronic Qualification Test Guide, contains
additional information.
7.3 Aging Components Issues
The purpose of this section is to give guidance to FSTD operators relating to the
effects of long-term aging of components and subsystems in FSTDs (15 years). In
general, this section will deal with components that degrade with time regardless of
use.
7.3.1 Areas of Consideration:
7.3.1.1 Electrolytic Capacitors
These devices are used throughout the FSTD, mostly in power supplies. In most
cases, an electrolytic capacitor is a life-limiting device. While time is a big factor for
electrolytic capacitors, heat is the most detrimental factor in the life of these
components.
7.3.1.2 Erasable Programable Read Only Memory (EPROM)

There have been reports of Erasable Programable Read Only Memory (EPROM)
having a life limit of less than fifteen years. Customers are advised that having the
contents of all EPROMs, and the equipment to burn new EPROMs will be helpful in
maintaining older equipment.
7.3.1.3 Battery Backup Random Access Memory (BBRAM)
These devices have a battery inside the device and several manufacturers claim up
to 15 years design life. To be safe, however, customers are advised to replace the
devices before they reach their design life, and to always keep backups of the data
contained in them.
7.3.1.4 Electrical Wiring
There are many different types of wire used in the manufacturing and modification of
an FSTD. Solid conductor wire should never be used in areas where the wiring must
be disturbed when replacing components. Over a period of 15 years, the insulation
on wires can severely degrade. Ozone level, hydraulic fluid contamination, improper
routing, improper strain relief, and mechanical abrasions are factors that will hasten
the degradation of simulator wiring.
7.3.1.5 Hydraulic Components
Hoses, seals, and boots will almost all have to be replaced before reaching the
15-year period. They are included because of the time life limit associated with any
rubber components.
7.3.1.6 Motion Base
The motion base attachment hardware should be continually checked throughout
the life of an FSTD. In addition, proper inspection of the facility floor structure after
many years in service should be accomplished.
7.3.1.7 Accessway and Maintenance Platforms
These components are often manufactured out of aluminum and welded to make
the structure. Due to vibration and time, customers are advised to inspect for signs
of fatigue cracking.
7.3.1.8 Batteries
Batteries are used in many FSTD systems, ranging from PC system clock batteries,
Uninterruptible Power Supply (UPS) systems, and FSTD emergency systems.
These batteries should be regularly checked and replaced as required.
COMMENTARY
Aging components should be kept in mind when preparing preventive
maintenance schedules.
7.4 Emergency Preparedness Recovery
The ability to recover from an emergency or disaster will depend greatly on
emergency preparedness. Facility preparedness must follow national and local
regulations as well as organizational policies. Each organization should compile
their emergency procedures and include notification information.
An emergency may be as large as an earthquake that destroys a facility, or as small

as a fire that destroys a computer’s backplane. Measures should be taken in order
to resume training after such an event.
Software considerations:
• Software backups should be accomplished as specified in Section 7.2.1 for
minor emergencies such as hardware failures or human errors. A software
backup schedule should become part of the preventive maintenance
program. A minimum of quarterly and annual backups should be made.
Hardware considerations:
• While it is not feasible to maintain spares to rebuild an entire FSTD, recovery
should be kept in mind when deciding on levels of spares.
• Sources of replacement hardware should be identified, with periodic checks
to assess the manufacturers’ ability to supply the required equipment.
• As equipment becomes obsolete, emergency recovery may become a
consideration when deciding on updates.
• STD’s should be equipped with operational fire detections/suppression
systems. It may be desirable to integrate the FSTD’s fire protection system
with the facility’s fire protection system. In this way, the FSTD may be safely
powered down as the result of a building fire alarm, and the building fire
alarm will be alerted to a fire in the FSTD. The FSTD’s air conditioning
system should be shut off when a fire is detected.
Facility considerations:
• Emergency preparedness should be considered during the facility’s design.
See ARINC Report 437: Guidelines for Training Facility for more detailed
information.
8.0 UNSCHEDULED MAINTENANCE

8.1 General
Unscheduled maintenance occurs when actions are taken to rectify a fault on an
FSTD following an “in-training failure” or a fault found during preventive
maintenance, which will directly impact FSTD availability. Unscheduled
maintenance activities can result in replacement or repair of line replaceable units,
replacement of consumables, system reset, software reloads, or temporary repair of
components until a scheduled maintenance activity can take place.
COMMENTARY
In practical terms, most faults are resolved by maintenance
technicians relatively quickly without resorting to any formal tools or
procedures.
However, in some cases, a fault can be difficult to diagnose, and the
repair is not obvious. In these cases, once the initial attempts are
exhausted, a formal process should come into play and should be
managed and documented. The repair of these kinds of faults can
extend over multiple shifts, and even multiple days. The process
should eliminate rechecking the same item more than once and
should call for a methodical approach to resolving the problem. The
intent is to bring the device back into service as quickly as possible.
When a fault renders the FSTD unsuitable for training and cannot be
resolved locally, an AOG should be declared.
8.2 Troubleshooting
When a fault is detected, the intent is to understand the fault and to confirm it. Then
troubleshooting is required to isolate the fault.
8.2.1 Diagnostic Tools
Diagnostic tools should be integrated into an FSTD and may include:
• An online diagnostic that will detect and log failures to the LRU level.
• The ability to record failure symptoms.
• The capability to be re-started in maintenance (offline) mode for
troubleshooting.
• Electronic Fault Isolation guides that allow point and click signal tracing.
• Cross-references to associated documentation.
• Non-Volatile Continuous Snapshot Monitoring (Real-Time Fault Trap).
• Memory traps and memory dumps triggered by a defined event.
The diagnostics should not report good units as bad, nor should they report bad
units as good.
As an option, an offline diagnostic should be available that will diagnose the LRU
cause of failure to the component level.
8.2.2 Documenting the Solution
It is essential that the fault and the solution are fully documented as defined in
Section 6.0. This will provide valuable data for trend analysis and for saving time in
the future when tracing an identical fault. Part numbers/serial numbers of failed
LRU’s should be recorded so that history on an individual LRU can be built up.
8.2.3 Feedback to Training
Faults which occur on a frequent basis, or faults of a particularly difficult nature,
should be highlighted and recorded for training purposes. This will help the whole
maintenance team to be familiar with specific faults, and aid in the training of new
team members.
A means should be provided to allow the instructor to trap and electronically record
the conditions under which a repetitive or a Cannot Duplicate (CND) fault occurs.
This will help collect data which will allow the maintenance staff to eventually
duplicate the problem and resolve it.
8.3 Deferred Maintenance
When a fault does not impact training, a suitable work around exists, or training can
continue with the FSTD being used in a limited capacity, then a fault can be
deferred and repaired during an assigned maintenance period.
It is essential that deferred faults are recorded clearly in a deferred defect log, which
should be clearly accessible to training crews as well as the technical staff. Training
crews should be made aware of or sign off on the defects prior to any training taking
place, to ensure that any change in FSTD performance is fully understood.
9.0 SPARES AND CONSUMABLES MANAGEMENT

9.1 General
FSTD operators prefer multiple part sources. A minimum of two-part sources is
preferred. Customers should be given all required information, in order to deal
directly with the supplier of individual parts.
Wherever practical, the supplier should strive to provide commonality with current
and previous products.
Mean Time Between Failure (MTBF), Mean Time To Repair (MTTR), and
Turnaround Time (TAT) information should be provided at the LRU level.
The Recommended Spares List (RSL) should include the impact of component
failures on FSTD operations:
Level A = Unsuitable for Training
Level B = May Impact Training
Level C = No Impact on Training
Suppliers should endeavor to secure support for at least 15 years for all parts used
in an FSTD.
COMMENTARY
There are commercial products available that can assist in
determining sparing levels. Failure data should be fed back to the
FSTD TDM on a regular basis such that the TDM can improve the
accuracy of the MTBF data.
9.2 Initial Spares
FSTDs may be purchased with a specific set of spares (repairables) and
consumables (expendables) included. The TDM will normally provide a list of
recommended critical spares. The management of these items involves tracking of
consumable issue rates and component MTBF and MTTR.
In order to provide the best availability, it is necessary to hold spares and
consumables in inventory. This is a balancing act between budgetary constraints
and FSTD availability. As the FSTD develops its reliability and availability history,
the customer will need to study the best mix of spares, and the quantity of spares
needed. By reviewing the rate of consumables, it may be discovered that there are
not enough of some parts on hand and perhaps too many of another. Likewise,
there may be some spares that have never been drawn out of inventory (which
indicates a highly reliable component), or spares that are seldom in inventory
because they are always being drawn out to return the FSTD to service. Over time,
the customer can make informed decisions on “re-balancing” the inventory to
improve FSTD availability. This should also lead to a more accurate and lower
inventory budget.
9.2.1 Spares Philosophy
The following should be reviewed when determining the spares levels.
9.2.1.1 Logistics
Direct support from the TDM needs to be considered, including support
arrangements such as local spares stocks, repair capability, and local transport and
customs issues.
9.2.1.2 Repair Capabilities “On-Site” or Nearby
If the user has an established Component Repair (CPR) facility, in-house or nearby,
sparing levels may be reduced.
9.2.1.3 LRU in Aircraft Stores
If the FSTD incorporates aircraft equipment, it may be possible to draw on aircraft
spares from the associated airline or aircraft manufacturer. If not, it may be
necessary to include critical aircraft parts as spares. Alternately, it may be possible
to use rental pools.
9.2.1.4 Use of Simulated Parts
Another option may be the use of simulated aircraft parts. However, it is important to
get all documentation and the required equipment to repair these devices.
COMMENTARY
Simulated aircraft hardware may have a lower MTBF than the aircraft
and should be considered when establishing sparing levels. Also,
these parts may become obsolete faster than actual aircraft parts.
9.2.1.5 Warranty Conditions and Duration
Generally, this would still require the need for spares based on the previous
concerns. However, it could preclude the need for a fully functional CPR group.
Again, the distance to the manufacturer and turn-around time for repaired parts
needs to be reviewed.
9.2.1.6 Consignment Spares
The manufacturer may offer consignment spares, which is a package of spares
provided by the TDM at no cost. However, at the end of a specified period of time
the TDM will offer various options for continued support, such as rent, depot,
purchase, or return. One advantage of consignment spares is the ability to acquire
actual in-service failure data (MTBF) prior to a purchase commitment, which should
determine accurate sparing levels before defining the requirements for the final
purchase.
9.2.1.7 Potential AOG Items
Coordination should take place to ensure adequate spares of major components
whose failure could cause the FSTD to be unusable (Level A criticality). These are
typically all of the primary flight instruments, power supplies, host computer circuit
cards, motion and control loading pumps and motors, etc.
9.3 Repair
Suppliers should provide the information required to support the repair of equipment
by the customer when desired and practical (Section 4.0).
9.4 Last Time Buy

The supplier should advise customers when a component or system goes out of
production, in sufficient time for them to make a last time purchase decision.
9.5 Component Level Repair Versus LRU Repair
Overall sparing levels and spared items need to take into consideration the repair
philosophy of the individual organization maintaining the FSTD. If the philosophy is
to replace LRUs and return them to the supplier for repair, there is little need to
stock Shop Replaceable Units (SRUs) or piece parts.
10.0 OBSOLESCENCE MANAGEMENT

10.1 Obsolescence, Notification, and Minimizing Cost
10.1.1 Purpose and Goals
The purpose of this section is to establish guidelines that should be observed during
the initial design, production, and maintenance of FSTDs, and to present strategies
to minimize the costs and impacts associated with component and knowledge
obsolescence.
For more information on obsolescence refer to ARINC Report 662: Strategies to
Address Electronic Component Obsolescence in Commercial Aircraft. ARINC
Report 662 establishes guidelines that should be observed during initial design,
production and maintenance of avionics LRUs, and to present short-term strategies
to minimize costs and impacts associated with decreasing availability of electronic
components.
When available, suppliers should provide customers notifications of obsolescence at
the earliest possible date.
Software is also a component of an FSTD that may be subject to obsolescence.
Software may need updating in order to make a modification or to run an updated
platform. Software may also require updating to manage cybersecurity. The tools
and utilities required to manage the software may also become obsolete, particularly
if they are COTS products.
Customers should take particular care when using simulated avionics to see that all
software and utilities required to maintain and modify them are available over the full
life cycle of the FSTD.
Normally, support for software is provided over the life cycle of the FSTD by the
TDM. In the event that support is no longer available, the operator is left with few
options.
In these circumstances, it may be possible to obtain, or escrow, the software
sources from the software source provider or originator at the time of contract
signature. The best solution is to buy an FSTD from a reliable and established
supplier who should be able to provide a full range of software support services over
the life of the FSTD.
The FSTD industry can no longer assume long-term availability of original parts or
replacements. There is a need to design, produce, and support components that
may have short life cycles.
The goals are to:
• Provide guidelines for designs that will be tolerant of component
obsolescence.
• Identify cost-effective methods for resolving component obsolescence
issues.
• Recommend the use of standardized components for all FSTD parts.
• Facilitate global information exchange, e.g., obsolescence solutions,
databases, etc., between customers and other customers, customers and
suppliers, etc.
• Establish maintenance operation and support processes to address

obsolescence.
10.1.2 Background
The importance of replacement parts in the FSTD Industry has grown steadily over
the last few years. Devices were previously designed with little regard for long-term
life expectancies because components were typically large, discrete, and
replacements (Form/Fit/Function (FFF)) were easy to fabricate. Improved
components that result from better design tools and better manufacturing
techniques, have led to increased performance and have typically decreased the
costs of the original equipment.
Although it is easy to see this with respect to electronic components, it is applying
more and more to all systems (mechanical, hydraulic, and pneumatic) in an FSTD
because of their use of electronics, and their application of lessons learned in the
electronics industry.
One current side effect, however, is that parts’ life cycles are sometimes so short
that FSTDs are fielded with obsolete parts. Since the cost of an FSTD is still a
significant capital investment, a need remains for them to have long lifetimes.
Therefore, parts in the FSTDs must be designed with high regard for obsolescence.
Note that terms typical of electronics parts are used in the following sub-sections,
but the principal ones are intended to apply to all FSTD parts.
10.2 Obsolescence Resolution
10.2.1 Obsolescence Identification
A component obsolescence problem is typically identified when a component
manufacturer provides notification of product discontinuance, the item will no longer
be repaired by the TDM, or the part is unavailable when needed. This can also
apply to software parts such as Operating Systems. Proactive steps that FSTD
suppliers and maintenance organizations can take include:
• Have policies and procedures in place to respond to a notice of parts
discontinuance.
• Make agreements with suppliers to provide early warning of supply
discontinuance or disruption.
• Join with other users of similar components to share information, analyses,
excess supply, or other benefits (e.g., FSEMC, STACK International).
• Periodically review parts lists to pro-actively address parts discontinuance.
10.2.2 Resolution Options
Resolution options to address obsolescence include:
Alternate Source: Qualify alternate source for the same part:
• Other users
• Decommissioned FSTDs
• Secondhand market
• Reengineering companies
Substitution: Identify a functional replacement for the obsolete part:

• Alternate Part: use of a similar but not identical component that satisfies the
original application. This may include the original supplier’s next model that
is backward compatible.
• Aftermarket Suppliers: use of suppliers that specialize in manufacturing or
distribution of parts that the original manufacturer has ceased to provide.
• Emulation and Reverse Engineering: the process of developing form, fit, and
functional replacements for obsolete parts using available technical data.
Last Time Buy (LTB): This is the purchase of as many parts as your organization
predicts will be needed:
• As a bridge buy until redesign or alternate solutions can be implemented.
• For the life of the system being manufactured or supported.
In any case, inventories from last time and bridge buys should be managed to
prevent unplanned shortages.
Update or Redesign of the product: When use of an alternate or substitute part is
not feasible, redesign of the next higher assembly may be required. In the case of a
software system, an update may be required to newer version of the software. If an
update or redesign is initiated, all potential short-life parts, hardware, and software,
should be designed out of the product at that time.
11.0 FSTD IMPROVEMENTS

11.1 General
During the life span of an FSTD, there can be many reasons for adding
improvements.
11.2 New Equipment or Systems
As the fleet of aircraft that the FSTD is supporting matures, and new equipment and
systems are added to the fleet (e.g., Traffic Collision Avoidance System (TCAS),
Aircraft Communications Addressing and Reporting System (ACARS), Enhanced
Ground Proximity Warning System (EGPWS)), the need to add these systems to the
FSTD becomes imperative.
There are three ways to approach adding new systems to an FSTD. The first is to
attempt to utilize the current host computer and Input/Output (I/O).
Second, if there is insufficient computing power, it may be possible to add a satellite
PC that will take a transfer block from the host and then drive the new system from
it. The problem with this approach is the inability to anticipate the number of future
additions (PCs), or to underestimate the amount of computing power needed.
Third, it may be necessary to evaluate the expected longevity of the fleet and the
FSTD, and then to decide if it makes economic sense to update the host to a more
modern robust system with plenty of computer power. When satellite computers are
added, additional care must be given to troubleshooting and configuration control
implications. Software obsolescence (Section 10.2.2) may also make this step
desirable or appropriate.
11.2.1 Obsolescence or Lack of a Trained Technician Pool
As an FSTD ages several support phenomena begin to develop. First, if the TDM is
still in business, they may have moved on to newer technologies, making it less
likely that they will be able to provide support to the FSTD indefinitely.
Secondly, as the technology improves and the work force ages and retires, the
younger technician is less likely to understand the older technology. If the problem is
a lack of trained technicians, then the user may be able to send their staff to the
TDM for training; train the staff “in-house” with the more seasoned technicians
performing the training; or investigate the possibility of updating the technology, so
that more qualified technicians will be able to work on it. Things to consider are the
teaching ability of the older staff, the company’s retention of those being trained,
and the longevity of the FSTD.
11.2.2 Higher Qualification Level
The time may come to try and receive more training credits from an FSTD than it is
currently qualified for. For example, an FSTD that is currently qualified at a Level “B”
may require it to be qualified at Level “C.” After investigation, it may be determined
that the current equipment is incapable of supporting the new requirements and
would require an improvement to the FSTD as well as the aircraft data package.
Note that an update in qualification level may also require an update to the current
qualification baseline.
11.2.3 Lack of Reliability

It may be possible that the FSTD manufacturer is still in business, the technology
may remain supportable, and the trained technician pool is still quite large.
However, the reliability of the FSTD is so poor that the crews encounter a higher
than normal interruption rate and therefore experience a higher level of negative
training. As a result, it then becomes beneficial to upgrade the FSTD. In cases of
unreliable components, the TDM may already have addressed these issues and can
save the user time and money.
11.2.4 Improve Maintainability Through Improved Efficiency
As the fleet of simulators grows over time, the mix of manufacturers, host types,
control loading and motion types, I/O, etc., will inevitably vary. Since this will happen
gradually, the older FSTDs start to fall into Section 11.2 and 11.2.1. Then the effects
of the lack of “efficiencies of scales” usually begins to show.
It is possible to have multiple FSTDs built by various manufacturers which represent
one aircraft type. This adversely affects the technician pool in at least two ways.
First, the technicians must be familiar with multiple technologies and secondly, the
technician pool may be larger than necessary in order to support multiple systems.
One way to improve these two areas, maintainability and efficiency, is to modify the
multiple systems into one system (e.g., changing different host computers into one
host). This should improve both the maintainability and the efficiency. This also has
the potential added benefit of improving reliability.
11.3 Relocation
The relocation of an FSTD may be considered as a form of modification. It is
extremely doubtful that an FSTD can be relocated without physical modifications to
the hydraulic plumbing, main power supply, and cable routing to suit the new
location. In addition, access to the simulator will most likely need to be redesigned
for the new location.
Relocation is a good time to consider making other modifications or FSTD capability
enhancements that would normally require lengthy downtime of the FSTD.
However, the customer may want to weigh the effects of the extended schedule.
Performing modification(s) at the same time could save money as well as down
time.
11.4 Change of Regulatory Approval Level
11.4.1 Upgrade
Upgrades are typically performed so that the customer can get more training credits
from the FSTD. This can in turn off-load training from other FSTDs.
Upgrades from a regulatory point of view require certain minimums to be met. First,
there is the need to ensure that the ownership of an aircraft manufacturer’s data
package will support the upgrade (e.g., the need to turn an FSTD into a full flight
FSTD). The customer needs to ensure that the license that was purchased for the
FSTD will support the upgraded status. Although the various regulatory agencies
around the world are attempting to harmonize their regulations regarding
qualification levels, at present there are still differences.
After verifying the data package, the next step is to determine if the device in
question can satisfy the tighter tolerances placed on it with a higher level of
qualification. Depending on the country of origin, the user will have to check the
governing authority. If there are tighter tolerances, it will be necessary to make
changes, adjustments, and/or modifications in order to get the device ready to meet
the new tolerance limits. At many levels of qualification, there will be a series of
qualification tests, both objective and subjective, that the device will need to pass.
11.4.2 Downgrade
The rationale for downgrading may at first seem detrimental to an operation. While
it is certainly possible to use a Level “C” or “D” FSTD as an FSTD (e.g., Level 4), the
customer may at some point wish to limit the regulatory exposure. For example,
there may be two FSTDs, but due to a reduction in the number of aircraft in the fleet,
the customer may find that it only has enough training to support one. Downgrading
one FSTD to an FSTD should reduce labor costs and regulatory risks. The
downgrade on an FSTD to a Level 4 FSTD no longer requires the visual and motion
to be powered, and there is no longer a need to perform QTGs for the simulator.
The only requirement remaining is to maintain the Level 4 qualification with the
regulatory authority. The regulatory agencies documentation should provide the
details for the downgrade process.
11.5 New Visual Data Base
Proper acceptance of a new visual data base can reduce life cycle cost. An example
procedure and checklist are shown in Appendix B.
12.0 HIBERNATION/RELOCATION/DECOMMISSIONING
12.1 Hibernation
The purpose of this section is to give guidance to FSTD operators relating to the
shutdown of a flight simulator for an extended period. This process assumes that
the operator intends to keep the device qualified with their regulatory authority. The
national regulatory agencies documentation should be consulted to verify how long
a device can be out of service in this manner. Their documentation should provide
the details for the hibernation and re-instatement process. While the detailed
procedures for hibernating different types of FSTDs will vary greatly, the overall
areas of consideration should be relatively common.
Additionally, a consultation with the device’s TDM could be beneficial prior to,
during, and after hibernation.
Whether in situ or offsite, hibernation will need several steps to promote a
successful outcome.
12.1.1 Areas of Consideration
The following areas need to be considered when hibernating a Full Flight Simulator.
Hibernating an FSTD or lesser device should consider a subset of the items below.
• Obtaining baseline data (QTG or Maintenance-only data)
• Open discrepancy resolution
• Hardware inventory
• Maintaining hardware configuration control
• Maintaining software configuration control
• Data backup (including NVRAM boot data for host and/or satellite
processors)
• Procedure Development
o Shutdown process
o During hibernation process (i.e., restart, ensuring currency, and
repeating the shutdown process)
o Part removal process
o Wake up process
o Maintenance testing process
o Regulatory testing process
• Security
• Subsystem considerations
o Host computer complex
o Visual system
o Linkage
o Motion
o Controls
o Hydraulic power unit
o Power supplies
o Facilities
12.2 Detailed Breakdown of Considerations

12.2.1 Obtaining Baseline Data (QTG or Maintenance-Only Data)
It is important to know exactly what state the FSTD is in before hibernation. When
the FSTD is return to service, the use of this data (whether attempting to rectify an
old problem or one due to extended shutdown) will likely prove valuable.
12.2.2 Open Discrepancy Resolution
Ideally, all open maintenance discrepancies should be rectified prior to shut down. If
this is not practical, documenting the discrepancies is imperative due to the reasons
stated in Section 12.2.1.
12.2.3 Hardware Inventory
This is one of the more challenging areas to address, but one of the most important.
With extended periods of shutdown, the need for an organization to “borrow” a part
to repair other devices will inevitably arise. While it is tempting to initiate a policy that
no parts will be taken from a hibernating device, the pressure to do so may be too
great in a time of need. The best way in either case is to define a policy that all
hardware should be identified by part number and serial number, such that an as-
stored record can be defined.
12.2.4 Documentation
All documentation delivered with the simulator including European Data Format
(EDF), COTS vendor information, and system diagrams should be recorded, and
kept in a safe environment for the duration of the hibernation period. Limiting access
to the documentation should be considered as a method to keep the documents
intact.
12.2.5 Maintaining Software Configuration Control
Complying with Data Backup should eliminate any software configuration control
problems. However, if the device utilizes a common load to other devices, it is
possible that load changes may occur without being tested on the hibernating
device.
12.2.6 Data Backup (Including Non-Volatile Random Access Memory (NVRAM) Boot Data
for Host or Satellite Processors)
Full backups of all software loads should be taken prior to hibernation. Storage of
software backups should be maintained in at least two separate facilities.
12.2.7 Procedure Development and Validation
• Initial shutdown process
• Recurrent shutdown process
• While hibernating process
• Part removal process
• Wake up process
• Maintenance testing process
• Regulatory testing process
12.2.8 Security
Access to the flight compartment should be restricted to help avoid unauthorized
removal of parts and control movement. The easiest method to accomplish this is to
leave the access way up with the emergency battery disconnected.
Tamper indicating tape should be used on cabinets to help determine if any
unauthorized parts or changes have been made. The use of an Infra-Red (IR)
marker can also be helpful in determining removed or swapped components.
12.3 Subsystem Special Considerations
12.3.1 Host Computer Complex
• Backup battery types and part numbers for each battery type and location on
each circuit board should be documented.
• Full backups should be made.
• NVRAM boot information may be lost depending on shutdown time. The
wake-up process should include information necessary to reinitialize all
NVRAM stored info.
• All computer settings such as Basic Input Output System (BIOS) and
configuration settings should be fully recorded such that any failures due to
batteries being discharged can be recovered.
12.3.2 Visual System
Depending on the hibernation period, leaving the vacuum on may be safest. If this is
not completed, coordination of the mirror Mylar replacement on startup should be
planned.
12.3.3 Linkage
All batteries should be removed from their associated assemblies and stored
separately.
12.3.4 Motion
Some digital motion systems store the configuration and tuning data on BBRAM.
Verifying that this data is backed up is advised.
12.3.5 Controls
• Some digital control loading systems store the configuration and tuning data
on BBRAM. Verifying that this data is backed up is advised.
• Friction Plots should be run on the controls in a force loop to record any
mechanical friction.
• Primary and secondary controls that are attached to hydraulically operated
force jacks should be positioned such that the jack ram is fully retracted
within the jack body. The controls should be retained in this position using tie
wraps or other suitable restraint to ensure stability throughout the hibernation
period.
• Accumulators should be checked for proper charge, and depending on the
expected hibernation period, they should be bled down in a controlled
manner and capped.
12.3.6 Hydraulic Power Unit

• Hydraulic filters should be replaced before shutting the device down. Some
hydraulic power units have differential pressure sensors across filter
elements that shut the system down if the system “thinks” the filter is
clogged. Cold oil with marginal filter elements will sometimes keep the
system from starting enough to heat the oil. The wake-up procedure should
include a section detailing how to bypass these sensors if necessary to
warm the oil.
• The oil level should be topped to minimize air space. Using a desiccant
breather well before shutdown should remove moisture from the airspace. A
visually indicating desiccant breather is a good way to ensure that moisture
is not being introduced during shutdown. Obviously, this will be worthless if it
is not part of the “While Hibernating Process” to check it.
• With chilled water cooling. Some kidney cooling circuits are designed so that
the oil pressure in the cooler is slightly higher than the chilled water
pressure. The reason for this is that if there is a leak in the heat exchanger,
less water will be introduced to the Hydraulic Power Unit (HPU) oil. This
makes it important to disengage the cooling water supply and returns during
wake-up process. If there has been a very small leak in the heat exchanger,
it may have gone unnoticed until the cooling oil pressure becomes lower
than the water. The water-cooling circuit must be thoroughly drained and
dried in order to ensure that there is no water entrapped.
• All inlets/outlets should be capped.
• All shut-off valves should be manually turned to the closed position.
• Refrigerant should be discharged from water chiller cooling circuits, if
applicable.
• Magnetic traps should be inspected and cleaned before shutdown.
• The accumulator should be checked for the proper charge, and depending
on the expected hibernation period, bled down in a controlled manner and
capped.
12.3.7 Power Supplies
Power supplies should be measured for level and ripple. Extended shutdown may
cause weak filter capacitors to fail when powered up.
12.4 Facilities
Facility considerations should be taken into account as defined in ARINC
Report 437.
12.5 Return to Service
The purpose of this section is to give guidance to FSTD operators relating to return
to service after hibernation.
One key element of hibernation is to develop and verify the waking-up process
(Section 12.2.7). If verification is properly done, the operator should know that
problems encountered during the real waking-up process are most likely due to the
time in hibernation, undocumented changes during hibernation, or damage incurred
during the physical relocation of the device.
If available and applicable, the use of the TDM’s documentation for maintenance
and commissioning should be used.
12.5.1 Visual Inspection
Prior to commencing post hibernation, a visual inspection of the device should take
place and any additional actions recorded. If tamper indicating methods were used
during hibernation, their status should be inspected.
12.5.2 Hardware Inventory and Spare Parts Availability
Due to a long period of hibernation, there may be component mortality, especially
with Performance Data Bases (PCB), power supplies and hydraulic components.
Any additional spare parts should be made available to enable the equipment to be
brought back into service in a timely manner.
The process to allow for the documented removal of parts from the device should be
reviewed and any removed items replaced.
The “as stored” records should be reviewed against the hardware fitted to ensure
that the device is in a known configured state.
12.5.3 Records Review and Documentation
Review of pre-hibernation notes for the device should be carried out and any
recommended actions.
All documentation should be made available and accessible.
12.5.4 Software
All software backups should be made available.
12.5.5 Computer Equipment and Settings
Each device should be powered up independently for a period of 24 hours. After this
time, the status should be reviewed.
Each device should be reviewed for BIOS and configuration settings. Rectification of
any faults should be carried out.
12.5.6 Facilities
All facilities disabled or disconnected during Hibernation should be taken into
account. For more information on facilities consideration, see ARINC Report 437.
12.5.7 Power Supplies and Linkage
• Power supplies can be especially problematic when left unused for lengthy
periods. See Sections 7.3 and 12.3.7.
• Simulator diagnostics should be reviewed. Failed components should be
identified, and any failed components replaced or rectified.
12.5.8 Hydraulic Power Unit
The recommendations of this section will vary greatly depending on how the device
was placed into hibernation.
• All accumulators need to be checked and serviced. If the hibernation period
has been lengthy, the bladders should be replaced.
• If the re-commissioning is due to relocation, check for proper pump rotation.
• System cooling should be re-commissioned in accordance with the vendor

maintenance manual.
• Tank oil should be circulated via the HPU cooling pump for a period of 24
hours.
• Analysis of the oil should be carried out.
• All filter elements should be replaced.
• The flushing procedure in accordance with the maintenance manual should
be carried out.
• A second analysis of the oil should be carried out.
12.5.9 Motion and Controls
• Bladders should be replaced with new items. Accumulators should be
recharged in accordance with the maintenance manual.
• Re-commission Motion System in accordance with TDM documentation.
• Restraints holding controls in the retracted position should be removed.
• Accumulator and alleviator bladders should be replaced in accordance with
the maintenance manual.
• Accumulator and alleviators should be recharged in accordance with the
maintenance manual.
• The control loading system should be set up in accordance with supplier
documentation.
12.5.10 Visual System
• Mylar Mirror should be replaced if not kept under positive pressure during
hibernation.
• BPS screen should be cleaned in accordance with maintenance manuals.
• Preventative maintenance activities and set up procedures for projectors
should be carried out in accordance with the maintenance manual.
12.5.11 Host Computer Complex
• Diagnostic checks should be carried out and problems rectified with the host
network.
• All Central Processing Unit (CPU) BIOS settings should be verified with the
pre-hibernation settings. If the host processor clocks are off, these will have
to reset to their original values.
12.5.12 Preventative Maintenance
All maintenance activities (annual, bi-annual, monthly, weekly and daily) defined in
the maintenance manual should be performed.
12.5.13 Verifying Baseline Data (ATMs and QTGs)
• All ATM tests should be run and compared to the pre-relocation or pre-
hibernation base lines.
• All Qualification Test Guide tests should be run.
12.6 Relocation
See Section 11.3.
12.7 Decommissioning
At the end of an FSTD’s life cycle, a business decision may be made to remove it
from service and officially decommission it.
To remove an FSTD from service, the regulatory agency should be notified of this
decision in writing. After a reasonable period of time, verification must be made that
the device is no longer listed on the regulatory agencies’ list of active devices. Once
a device has been decommissioned, it will be necessary to meet the most recent
regulatory requirements, in order to return it to service.
12.8 Environmental Consideration
After the decommissioning of an FSTD, the device and all related equipment must
be discarded in accordance with local environmental regulations. Hydraulic fluid
must be properly disposed of, as well as any contaminated components and
consumables. Most FSTDs will contain materials that are now considered
hazardous, such as capacitors, batteries, friction clutch assemblies, cathode ray
tubes, etc. Insulating materials in the cockpit and other support equipment may
contain asbestos. Organizations that specialize in the identification of hazardous
materials and their removal should be consulted to ensure proper disposal.
13.0 SOFTWARE QUALITY
13.0 SOFTWARE QUALITY

13.1 General
For the purpose of this section, software source refers to any code, software,
firmware, or other programmable logic used in the design, maintenance and support
of any FSTD.
13.2 Establishment of Software Quality
Establishment of software quality starts with the technical specification and the
procurement process. Software and its documentation should be procured from the
vendor in compliance with ARINC Report 446: Guidance for Flight Training Device
Documentation Structure, Content, and Maintenance. Software quality standards
should be reinforced in any preliminary design reviews held with the FSTD
manufacturer. More information on procurement is contained in Section 3.0.
Whenever practical, coding standards set by the FSTD manufacturer should be
used when modifying existing source code. All modifications to code should also
include a comment block showing the name of the individual performing the
modification. More information on Simulator Modifications is contained in
Section 11.0.
Each source module should have a header that defines its governing
documentation, function, purpose, and revisions. Each source module section
and/or equation should have a header that defines its function and purpose.
Within each source module, comments should be provided referencing the system
design documentation and program design documentation, for each section of the
module. Where source does not provide for commenting (e.g., Programmable Array
Logic (PAL), firmware), the program design documentation should provide the
necessary connection to design documentation.
Data structures should be well defined either in the source or in the programming
documentation.
All variables or constants, and elements of data structures should have meaningful
labels and descriptions based on the English language. Label names should contain
enough characters to make meaningful label descriptors, subject to the limitations of
the compiler and other utilities using the labels. “Spare” or “temp” labels should not
be used.
Unless the processor has time or memory limitations, the governing coding principle
will be clarity and functionality. Use of subroutines or functions, as a method of
organization or structure, will be encouraged.
Properly enforced, these standards will result in a system providing:
• Code that can be traced back to its governing system design documentation
and programming design documentation.
• Code that will be readable with minimum time spent reverse engineering its
purpose and implementation.
• Modifications to code that are documented within the source, including
identification of the individual making the change.
14.0 QUALITY ASSURANCE

14.1 Introduction
Historically, the “health” of an FSTD has been measured in terms of availability, or
percentage of time that a particular training device is available for training use. As
presented in ARINC Report 433, this metric is calculated by the ratio of available
time minus downtime to available time, and typically results in a number that ranges
from 98% to 100%. Individual variations between training devices are often more a
function of the availability of a particular spare part than of the overall health or
quality of the device. Thus, while availability is one measure of simulator health,
there is a desire in the industry to determine a method that more closely represents
the overall health/quality of a training device from the perspective of the end user.
The method presented in Section 14.2 is one possible method for filling this need.
Another measure of simulator health is the cost of keeping it in service. Most
simulators experience a typical bathtub curve – such as that you might associate
with a personal automobile. In the early years, there are some expenses associated
with items that were not quite right at assembly, but these are typically covered by
warranties. There are also costs associated with training of personnel, establishing
a spare parts inventory, etc. This is followed by a quiet period lasting probably less
than ten years, after which the cost of maintenance again rises. A method for
standardizing the cost of maintenance is presented in Section 14.3.
When the metrics of Sections 14.2 and 14.3 are used together, a methodology can
be formed to help guide lifecycle business decisions regarding decisions such as
adjusting sparing levels, replacing obsolete systems, components, or perhaps
retiring a training device. This is presented in Section 14.0.
14.2 FSTD Health Metrics
A number of individual factors impact the overall health or quality of an FSTD.
Maintaining a health metric history may also be an effective part of a FSTD quality
assurance program (Note that a quality assurance program needs to be compliant
with existing and evolving Regulatory Requirements).
STD health can be calculated numerically using the following approach:
Training Device Health, TDH, can be defined as follows:
TDH = M1 + M2 + M3 + M4 + M5 …
Where:
M1, M2, M3, M4, M5, … are a series of individual metrics representing the ‘health’
of the training device in particular areas and are weighted according to the
importance of each particular element. The intent would be that for a perfect
simulator, the sum of these individual metrics would be 100 points. Typical metrics
might include, for example:
• Reliability 0 – 20 (uninterrupted customer periods)
• Open Log Gripes 0 – 10 (customer write-ups)
• Open Maintenance Cards 0 – 10 (deferred maintenance write-ups)
• Support Manpower, SMEs 0 – 25 (engineering & maintenance manpower)
• Deferred Projects 0 – 15 (data updates, aircraft changes, …)
• Pilot Quality Rating 0 – 20 (cust. Quality rating from ARINC 433)
Please note that these are meant to be representative only, both in terms of the
metrics chosen and the value given to each.
TDH would be calculated on a monthly basis for each individual training device and
plotted versus time. It is recommended that the plots show individual training
devices rather than groups of training devices because averaging an improving
training device and a deteriorating training device might appear as steady average
performance, losing important insight into trend data on training device health.
The specific metrics chosen, and individual weights assigned will likely vary from
training center to training center, based on local priorities. The following list
suggests a number of individual metrics that might be considered in building this
health index:
• Reliability – percentage of uninterrupted customer periods
• Availability – percentage of “up” time
• Lost training time – based on customer feedback, the total impact of
interruptions and downtimes on the training mission
• On time departure – percentage of periods where the training device is ready
at the scheduled start time
• Open log gripes – possibly rated by priority or severity of the individual log
gripes and/or how long it takes to resolve new write-ups
• Open maintenance cards – possibly rated by severity
• Deferred projects – typically user requests
• Pilot quality rating
• QTGs requiring rework – percentage of tests that fail the first time when
rerun annually
• Engineering manpower – this might be only a cost metric, but in some cases,
it could also be a health metric
• Maintenance manpower – this might be only a cost metric, but in some
cases, it could also be a health metric
• Obsolescence issues
• Availability of spares – spares holdings locally, turn time of remote spares
• LRU repair costs and lead times
• Number of configuration deviations from aircraft tail number
• Currency of approval (are a number of items under grandfather rights)
COMMENTARY
If an individual metric is judged as being particularly important, it may
be helpful to set up the formula with this metric as a multiplier. For
example, if uninterrupted customer periods are determined to be a
key parameter, the health metric equation could be stated as:
TDH = [M1 + M2 + M3 + M4 + M5 …] x R
Where, as above, the sum of the individual M’s would be 100 for a
perfect training device.
14.3 FSTD Maintenance Cost Metrics

A measure of FSTD maintenance costs can be obtained by totaling the individual
costs associated with the following:
• Unscheduled maintenance activities (manpower and lost training time)
• Scheduled maintenance activities (manpower and consumables)
o Parts costs
o Spares
o Aging (use and shelf life)
o Obsolescence
o Consumable parts
• Parts repair costs (vendor and/or in-house)
• Cost of regulatory mandated changes/updates
• Documentation (cost of keeping it up to date)
• Technical staff skill level (training costs – both initial and recurring)
14.4 Combining FSTD Health and Cost Metrics
The real power of the health and cost metrics is realized when they are used
together. Observing trends on the performance of individual training devices over
time and/or relative to average indices for a training center may provide a lead
indicator of problems; focus on root causes, and information to support a business
plan regarding changes to the allocation of resources (manpower, upgrades,
additional spares, etc.).
Recording the health and cost metric for a number of related training devices (for
example, all of the full flight simulators in a training center) on a monthly basis and
plotting the results together on a single chart, will facilitate early detection of training
devices that are increasing in the cost required to maintain a certain quality level,
especially in comparison to other devices at the same facility. This will also allow
early detection of devices that show a reduction of quality at a steady level of cost.
The most serious scenario is a device that is showing increased costs while health
is in fact dropping.
Recording this health information over a period of years, for a number of devices,
will provide a tool that can help guide and justify the business case for reallocation
of maintenance resources.
A typical plot, for a single training device, is shown below.
Chart Showing Plot of Wellness and Unscheduled

Maintenance Costs
100
Wellness % & Cost $K
80
60 Wellness Index %
40 Unscheduled Costs $K
20
0
May
Aug
Nov
Sep
Mar
Dec
Feb
Oct
Jan
Jun
Apr
Jul
Month
Figure 14-1 – A Typical Plot for a Single Training Device

ATTACHMENT 1
REPRESENTATIVE PREVENTIVE MAINTENANCE ACTIONS
ATTACHMENT 1 REPRESENTATIVE PREVENTIVE MAINTENANCE ACTIONS
Interval
System Task
Days Months Years
1 7 14 1 3 6 1 2 3 4 5 8 10
Air Conditioning and Inspect the flexible hose •
Equipment Cooling between the air conditioner
and flight compartment for
damage or excessive wear,
especially at the point
where the hose contacts
the floor.
Inspect the cooling fan •

filters on the visual and
electrical cabinets.
Inspect the air conditioner •

intake filter. Inspect water
drain, hoses, and fittings.
Perform a functional check •

of the air flow detection
system.
Control Loading Drain the control loading oil •

collector bottles.
Inspect the control loading •

system accumulators.
Inspect the control loading •

system.
Perform control loading •

tuning.
Replace the stabilizer trim •

control loading unit filter.
Crew Accessway Inspect, clean and lubricate •

the counterweight spring
assemblies.
Test the safety interlock •

and STOP button.
Lubricate the access way
pivot hubs.
ATTACHMENT 1
Interval
System Task
Days Months Years
1 7 14 1 3 6 1 2 3 4 5 8 10
Check the fluid level of the •
battery cells and verify the
Float Voltage on the
emergency power pack.
Electrical Power Electromagnetic •
Compatibility (EMC)
maintenance check.
Electrical Power Inspect the UPS and •

battery cabinet in the
computer room.
Inspect grounding. •
Check the current sensors •

in the power cabinet.
Check the voltage •

transducers in the power
cabinet.
Test the Ground Fault •

Interrupter (GFI) circuit
breaker for the service
outlets.
Replace the lead acid •

batteries in the UPS and
battery cabinet in the
computer room.
Change the programmable •

logic control backup
battery.
Host Computer and Create host computer

Peripherals software backups on an as-
required basis. If software
changes are frequent,
perform regular backups.
Clean and service the

printers based on the
number of pages printed.
Clean the host computer •

system tape drive head
using a cleaning cartridge.
ATTACHMENT 1
Interval
System Task
Days Months Years
1 7 14 1 3 6 1 2 3 4 5 8 10
Delete unnecessary files •

from the hard drive(s).
Clean the inside of the •

computers (i.e., fans and
heat sinks).
Hydraulic Power Check the oil temperature. •
Check the hydraulic power •

supply pump discharge and
cooling system filters.
Hydraulic Power Visually inspect the •

hydraulic fluid.
Clean the water strainer. •
Inspect the hydraulic hoses •

and piping.
Obtain hydraulic fluid •

samples for Particle Count
and Water Analysis tests.
Obtain hydraulic fluid •

samples for Chemical
Analysis tests.
Clean the magnetic trap •

and starter panel. Lubricate
motor bearings and check
the switches and gauges.
Replace the air breather •

filter on the hydraulic power
supply oil tank.
Instructor Station Clean and service the

video tape recorder based
on operating time.
Lubricate the •
instructor/observer seats
and seat tracks.
ATTACHMENT 1
Interval
System Task
Days Months Years
1 7 14 1 3 6 1 2 3 4 5 8 10
Service the seat assembly •
brake cable.
Motion Drain the motion oil •

collector bottles.
Inspect the motion system •

accumulators.
Inspect the servoactuators •

and distribution manifolds
for evidence of damage or
hydraulic fluid leakage.
Motion Lubricate the upper and •

lower bearings.
Check-tighten the motion •

system bolts to specified
torque.
Overhaul the motion •

system actuators.
Safety Check the power supplies •

on the fire detection
system.
Test the operation of the •

emergency lighting system.
Check the air sampling •

pipework on the fire
detection system.
Check the pressure of the •

fire suppression cylinders.
Test the emergency shutoff •
switches.
Check the operation of the •

motion warning lights.
Test the operation of the •

emergency lighting system.
ATTACHMENT 1
Interval
System Task
Days Months Years
1 7 14 1 3 6 1 2 3 4 5 8 10
Inspect the fire suppression •
hose assemblies.
Inspect the fire suppression •

system for agent leakage
•
Inspect the fire suppression
cylinders.
Test the fire suppression •

system.
Clean and test the thermal •

detectors.
Perform pipe integrity •

smoke testing on the fire
detection system.
Clean the sampling points •

on the fire detection
system.
Safety Flush the air sampling pipe •

network on the fire
detection system.
Change the batteries on •

the fire suppression
system.
Check the batteries on the •

UPS located in chassis.
Pressure test the hose •

assemblies on the fire
suppression system.
Visually inspect the fire •

suppression cylinders.
Weigh the fire suppression •

cylinders.
Simulated Oxygen Inspect the simulated •

System oxygen system filters.
ATTACHMENT 1
Interval
System Task
Days Months Years
1 7 14 1 3 6 1 2 3 4 5 8 10
Smoke Generating Check the fluid level in the •
Equipment reservoir and top-up if
necessary.
Check the sight glass on •

the manifold, drain fluid if
level is high.
Drain accumulated fog fluid •

residue in the smoke
generating system.
Clean the smoke generator •

based on operating time.
Check the pump tube for •

signs of deterioration.
Visual Perform a static focus and •

position touchup
calibration.
Perform a static focus and •

convergence touchup
calibration.
•
Perform a static and
dynamic focus, and
Geometry, and
Convergence calibration.
Visual Perform an Intensity
calibration.
Run Image Generator (IG) •

diagnostics software.
Inspect the air filters and •

fans on the Projector Head
Units (PHUs).
Clean the static eliminator •

points and replace the
filter.
Refurbish the IG power •

supply.
Miscellaneous Run Morning Readiness •

Utility.
ATTACHMENT 2
PREVENTIVE MAINTENANCE LOG
ATTACHMENT 2 PREVENTATIVE MAINTENANCE LOG
Preventive Maintenance Log

Contract no.: __________________ Sheet no. ____
Simulator type: __________________
Date Task Name Approved Notes

ATTACHMENT 3
REQUIRED GROUNDING CHECKS FOR FULL FLIGHT SIMULATORS
ATTACHMENT 3 REQUIRED GROUNDING CHECKS FOR FULL FLIGHT SIMULATORS

3.1 Definitions
• W1 = Chassis Ground (safety ground)
• W2 = Power and Signal Isolated Returns
• DC = Direct Current
• AC = Alternating Current
• GROUND is a term that is used in many instances where what is really
meant is either a DC or AC power return.
3.2 ATM Grounding Checks, Evolution, and Background
Over the years, the ATM grounding checks have uncovered a number of annoying
side effects that disappeared when the grounding problems were corrected. The
method for actually performing the grounding checks has evolved from a very
tedious time-consuming approach to an incremental approach that should be short
and easy. This assumes that the design and manufacturing sections are working
cooperatively.
3.3 Grounding Check Objectives
• The primary objective of the grounding checks is to provide a quick test
which verifies that the grounding design has been successfully implemented
on an FSTD. Ideally, the W1 and W2 bus should be isolated until the star
points strap is connected.
• Provide a review of unavoidable ground loops in an FSTD so that informed
decisions can be made on the potential effect of signal coupling on
performance as well as on modifications. Aircraft instruments are an
example of unavoidable W1 and W2 connections.
• Provide adequate documentation to aid in avoiding ground loops when
adding new electronics hardware to an FSTD.
3.4 FSTD Vendor Responsibilities
All of the following items are to be provided prior to the actual grounding checks. Be
aware that all items can be determined to be independent of the actual FSTD build
process.
1. Overall Grounding and Power Distribution Design.
a. It is an understood requirement that the design can be correctly
implemented and verified via direct testing.
2. Grounding and Power Distribution Design by Cabinet or Flight Compartment
Section.
3. List of all components, instruments, black boxes, cabinets, etc. which have
W1-W2 (see definitions) connected internally.
a. Organize the lists into the following separate groups and identify the
location of each component, in particular if it is in the flight compartment.
b. Aircraft Parts
i. OEM vendor components
ii. STD vendor components
ATTACHMENT 3
Provide a brief explanation of why the connection exists (design consideration) for
TDM vendor components and FSTD vendor components listed above.
Identify milestone stages in the flight compartment build process where W1-W2
isolation checks are to be performed.
Agree to the proposition that any other connection between W1-W2 is probably the
result of a fabrication error.
3.5 Customer Action Reviews
1. Review lists presented in FSTD Vendor Responsibilities and agree on
acceptable W1-W2 connections. This ideally should be the same ones
provided in the original list.
2. Negotiate the phase in the fabrication (build) process where the grounding
check is to be made.
3. Witness or review the actual grounding check test results and take
appropriate action – either sign off on it or initiate a snag.
3.6 A Reasonable Hardware Fabrication/Integration Process
Section 3.8.2 outlines some Grounding Design Rules which help to ensure that the
grounding verification tests can be easily performed.
Section 3.8.2 provides some ideal fabrication guidelines which complement the
design rules. Practical constraints always result in the actual fabrication process
deviating somewhat from the ideal. Many of the problems are created during one or
more of the following phases:
• The flight compartment integration process
• Integration (cabling) of other subsystem cabinets to the flight compartment.
• Modifications to correct problems or the addition of new components
resulting from the FSTD debug effort.
3.7 Grounding Test Results Checklist
1. Review Items under FSTD Vendor Responsibility.
2. Sign off sheet of W1-W2 isolation checks for subsystem cabinets. The
cabinet isolation checks are to be performed and signed off by the site
inspector when the cabinet is delivered to the site. See Section 3.8.3 for a
representative list of cabinets.
3. Flight Compartment Build Checks. Possible milestone stages for flight
compartment W1-W2 isolation checks.
a. After all internal power/ground wiring and cabinets are installed (no
external cabling installed).
b. After all internal wiring is completed but no external cabling installed.
c. All internal wiring modifications or additions to the flight compartment
should be logged and validated as separate items (as required).
4. Training Device Hardware Integration Check is the primary check of W1-W2
isolation and it is also the check that will be made during the on-site
acceptance phase.
ATTACHMENT 3
a. Install all external cabinets and flight compartment W1 and W2

connections to the main power cabinet bus bars. Check that W1-W2 is
still isolated.
b. Install all cabling from flight compartment to external cabinets. W1-W2
should remain isolated.
c. Install items from vendor list and W1-W2 strap in the main power
cabinet.
5. Special Spot Checks: These checks must be satisfied at all stages of the
system hardware integration phase.
a. Remove W1 cable from the Control and Motion cabinet. Motion/Controls
Cabinet W1-W2 bus bars “must be isolated.”
b. Remove the following W1 connections in main power cabinet
i. W1-W2 strap
ii. Flight compartment W1 cable
iii. Motion Base W1
iv. Other W1’s (TBD)
W1-W2 in main power cabinet and all other cabinets except the flight compartment
are now isolated.
Note: An alternative method to accepting all of the uninstalled items
in the vendor list is to provid adequate documentation that
affirms that the workaround method is equivalent (e.g.,
removing a subset of inter-cabinet cables).
3.8 Section 1: Required Grounding Checks
3.8.1 Grounding System Design Rules
1. Each subsystem should have separate W1-W2 bus bars.
2. The “star” points for the W1-W2 grounds should be localized in a main power
cabinet.
3. All components in the system should be installed such that W1-W2 grounds
are isolated.
4. The “safety” connection between W1-W2 should only be made by a ground
strap between star points in the main power cabinet.
3.8.2 Ideal Fabrication Guidelines
An “ideal” fabrication process should include the following characteristics:
1. The items listed in number 3 of Section 3.7, Grounding Test Results
Checklist will not be installed until the last steps of the training device
hardware integration phase are complete.
2. Each subsystem should be fabricated as follows:
a. W1-W2 have isolated bus bars
b. Continuity meter with buzzer or light between W1-W2 bus bars. An
indication on the continuity meter should indicate a ground wiring
inconsistency.
c. At the completion of the subsystem fabrication W1-W2 should still be
separated.
ATTACHMENT 3
d. Each subsystem cabinet should have W1-W2 isolation checks performed

and verified before being delivered to the integration site.
3. Subsystem integration would be carried out with W1 and W2 in the main
power cabinet isolated from each other. Once again, a meter between the
two during the integration phase will warn of incorrect wiring.
3.8.3 Sample List of Training Device Cabinets
• Main/Master Power cabinet
• Interface Cabinets
• Aircraft Avionics Cabinet
• Flight Compartment Cabinets/Sections
• Motion and Control Loading Cabinet
• Audio and Sound Cabinet
• Main Computer Complex Cabinet
• Instructor Station Cabinet
• Motion Base
• Hydraulic Power Unit Cabinet
• 400 Hz Power Generation Device
The actual list for a particular device will be defined from the Grounding System
Design Document.
3.9 Section 2: Grounding Checks Historical Background
A strong interest in improving grounding checks was developed following extensive
troubleshooting on several simulators delivered in the early 1980s. Some of the
results of this investigation were as follows:
• The overall grounding design was sound and when implemented correctly
gave acceptable results.
• Some intra-cabinet grounding implementation improvements that could be
made with minor modifications were noted.
• A number of wiring and assembly errors during manufacturing defeated
some grounding design objectives.
• After correcting the manufacturing errors, the ambient noise on signal lines
dropped from >200 mv to <50 mv. The problems also disappeared; however,
its disappearance was probably the result of a combination of changes.
3.10 Power Distribution/Grounding Evaluation Metrics
Even an ideal power distribution and grounding design can be rendered less than
effective if it is implemented poorly. The items listed here are noteworthy for
evaluating the implementation of a power distribution.
• Good DC power/return distribution implementation within a cabinet from a
power supply via separate cable(s) for each chassis.
• Power supply status.
• Power and ground distribution for each chassis should be provided via a
distribution bus on the back-plane.
ATTACHMENT 3
• Do not place washers between any of between power/return cables or bus

bars. These should always be terminal-to-terminal connections.
APPENDIX A
ACRONYM LIST
APPENDIX A ACRONYM LIST

AC Alternating Current
ACARS Aircraft Communications Addressing and Reporting System
AOG Aircraft on Ground
ATM Acceptance Test Manual
BBRAM Battery Backup Random Access Memory
BIOS Basic Input Output System
CBT Computer Based Training
CL Center Lights
CND Cannot Duplicate
COTS Commercial Off The Shelf
CPR Component Repair
CPU Central Processing Unit
CPT Cockpit Procedures Trainer
CSR Customer Support Representative
DC Direct Current
DTG Distance to Go
EDF European Data Format
EGPWS Enhanced Ground Proximity Warning System
EMC Electromagnetic Current
EPROM Erasable Programable Read Only Memory
FAT Factory Acceptance Testing
FFS Form/Fit/Function
FFS Full Flight Simulator
FMC Flight Management Computer
FSR Field Service Representative
FSTD Flight Simulation Training Device
GFI Ground Fault Interrupter
GPS Global Positioning System
HPU Hydraulic Power Unit
IFA In-Field Acceptance
I/O Input/Output
IOS Instructor Operating Station
IPA In-Plant Acceptance
IR Infra-Red
LAHSO Land and Hold Short Operations
LOD Level of Detail
LRU Line Replaceable Unit
LTB Last Time Buy
MEL Minimum Equipment List
APPENDIX A
ACRONYM LIST
MTBF Mean Time Between Failure

MTTR Mean Time To Repair
NDB Navigation Data Base
NFF No Fault Found
NVRAM Non-Volatile Random Access Memory
OEM Original Equipment Manufacturer
OSA On-Site Acceptance
PAL Programmable Array Logic
PC Personal Computer
PCB Performance Data Bases
PTT Push To Talk
PMR Project Management Representative
PN Part Number
QTG Qualification Test Guide
RFP Request for Proposal
RFT Ready for Training
RSL Recommended Spares List
SAT Site Acceptance Testing
SFL Sequencing Flashing Light
SID Standard Instrument Departure
SME Subject Matter Expert
SMGCS Surface Movement Guidance and Control Systems
SN Serial Number
SRU Shop Replaceable Unit
STAR Standard Terminal Arrival Route
TAT Turnaround Time
TCAS Traffic Collision Avoidance System
TDH Training Device Health
TDM Training Device Manufacturer
TDZ Top Dead Zero
UPS Uninterruptible Power Supply
APPENDIX B
EXAMPLE VISUAL MODEL ACCEPTANCE CHECKLIST
APPENDIX B EXAMPLE VISUAL MODEL ACCEPTANCE CHECKLIST
THIS PAGE INTENTIONALLY LEFT BLANK.

Visual Model Acceptance Checklist Month Year – Revision X
TCSM Owner: Center Manager
Approver: Quality Manager
Airport name: (Tenerife South, Reina Sofía) IG type: (Vital 8+) Model ident / version: (canary_islands.ldb)
ICAO code: GCTS code: TFS Summer model Scope of assessment : (new build)
Item Checked against Comments Accepted By, date

(reference documents) (yes, no)

Runway 1A/B (runway number) Repeat for multiple runways
Orientation Data Base Supplier charts, Headings for both rwys 1 deg error in excess.
(length, width, true heading, threshold Host info Probably not a visual issue but related to mag var
positions and elevation – GPS info on the host.
compliance)
Profile Data Base Supplier charts, There seems to be several invisible obstacles
(elevations along length) Chief Instructor comments (humps?) along both runways, totally unsuitable for
(occultation on compound slopes) training.
APPENDIX B
(HAT check)
Features Chief Instructor comments OK
(shoulders, disp thresholds, stopways,
turning circles, taxiway intersections)
Lighting – both approaches Data Base Supplier charts SFL (Sequencing Flashing Lights) should not exist.
(edge, approach, TDZ, CL, coding, In rwy 26. OK in rwy 08.
end lights, VLA) CL (Center Lights) seem to be too dim even at
(spacing, color, position, lobe width, highest brightness in both runways.
directionality)
(switch assignments)
Surface textures Chief Instructor comments OK.
(material, texture, color)
(skid marks)

Markings, signage – (type, position, Data Base Supplier charts, OK
color) Chief Instructor comments
(numbers, piano keys, TDZ, taxi lines,
DTG, LAHSO)

Contaminations Chief Instructor comments OK

(wet, snow, ice, patchy ice, damp) –
recheck lights
Twilight /night check Chief Instructor comments OK
Lo vis check Chief Instructor comments OK
Taxiways and ramp/apron areas Repeat as necessary
Orientation Data Base Supplier charts, OK
(length, width, heading, threshold Host info,
APPENDIX B
positions and elevation – GPS
compliance)
Profile Data Base Supplier charts, OK
(elevations along length) Chief Instructor comments
(occultation on compound slopes)
(slopes reasonable, HAT check)
Features Data Base Supplier charts, OK
(shoulders, turning circles, taxiway Chief Instructor comments
intersections)
Lighting Data Base Supplier charts, OK
(edge, CL, coded lights, SMGCS, wig Chief Instructor comments
wags)
(spacing, color, position, lobe width,
directionality)
Surface textures Chief Instructor comments OK
(material, texture, color)
Markings, signage Chief Instructor comments OK


(type, position, color) (taxi lines, edge
lines, chevrons, SMGCS, LAHSO,
stop bars, holding points)
(ident, instruction, info signs)
(wet, snow, ice, patchy ice, damp)
recheck lights
Twilight/night check Chief Instructor comments OK
APPENDIX B
Ramp lighting (floods)
Lo vis check Chief Instructor comments OK
Parking
Buildings Chief Instructor comments Terminal have 2 fingers missing
(type, size, orientation, position)
Jetways, parking stands Chief Instructor comments Gate reposition F4 or F5 requested. Missing stand
(Size, type, position) markings (see jpg attachment).
(parking guidance – AGNIS etc.)
Stand markings/numbering Chief Instructor comments OK
(type, color)
Lighting Chief Instructor comments OK
(parking aids, obst lights, airport
beacon)

Ramp trash
Quantity, quality
Twilight/night check Chief Instructor comments OK
Contaminations check Chief Instructor comments OK
Traffic

Ground traffic routes – suitability and Not available

correct operation
Air traffic – check up/down/left and Not available
right operation
TCAS correlation Chief Instructor comments OK
General
Subjective review Chief Instructor comments OK
LOD management Chief Instructor comments OK
APPENDIX B
Special effects Chief Instructor comments OK
(eg., light halos in fog, etc.)
Terrain Check on all approaches, SIDs, STARs, close and
short range
Orientation Chief Instructor comments OK
(position of features)
Profile Chief Instructor comments OK
(EGPWS compliance)
Features Chief Instructor comments OK
(urban, forest, rivers, coastlines)
(color/texture checks)
3D occultation checks Chief Instructor comments OK
Cloud clipping on 3D features
Twilight/night scene check Chief Instructor comments OK
Environmental and cultural lighting
(color, position, lobe width,
directionality)
(light fade in/out at range)


(snow) – recheck lights
Weather effects – impact on model Chief Instructor comments OK
Cloud clipping on 3D features
Lo vis check
LOD management Chief Instructor comments OK
Host integration
Ground/air traffic control N/A
APPENDIX B
TCAS Chief Instructor comments
EGPWS/GPS alignment N/A
Repositions Some reposition availability still pending
FMC/NDB alignment Chief Instructor comments OK
Final comments:
Unserviceable issues that makes the model not suitable for training:
• Unexpected invisible obstacles on both runways.
• Lighting not correct.
Comments for improvement:

• Terminal stands missing markings and fingers.
• Atlantic Ocean palette color selected too dark.
• Terminal should be modelled with aircrafts in parking and gate position.
AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7435
SUPPLEMENT 1
TO
ARINC REPORT 434
SYNTHETIC TRAINING DEVICE (STD) – LIFE CYCLE SUPPORT
Published: January 20, 2006
Prepared by the Airlines Electronic Engineering Committee
Adopted by the Airlines Electronic Engineering Committee: November 23, 2005

SUPPLEMENT 1 TO ARINC REPORT 434 – Page a
A. PURPOSE OF THIS DOCUMENT

This supplement is a complete rework of ARINC Report 434.
B. ORGANIZATION OF THIS SUPPLEMENT

This document, printed on goldenrod paper, serves to introduce Supplement 1 to
ARINC Report 434.
C. CHANGES TO ARINC REPORT 434 INTRODUCED BY THIS SUPPLEMENT

The document title has been revised from Flight Simulator Customer Support to
Synthetic Training Device (STD) – Life Cycle Support.
Supplement 1 is a complete rework of ARINC Report 434. The previous material has
been retained and new material on life cycle support has been added. The document
has been revised in its entirety.
SAE INDUSTRY TECHNOLOGIES CONSORTIA (SAE ITC)
16701 Melford Blvd., Suite 120
Bowie, Maryland 20715 USA
SUPPLEMENT 2
TO
ARINC REPORT 434
FLIGHT SIMULATION TRAINING DEVICE (FSTD) – LIFE CYCLE SUPPORT
Published: October 16, 2019
Prepared by the FSEMC
Adopted by the FSEMC Steering Committee: July 15, 2019

SUPPLEMENT 2 TO ARINC REPORT 434 – Page a
A. PURPOSE OF THIS DOCUMENT

This supplement updates the standard to provide guidance on current and future
requirements, operations, procedures, and contractual considerations.
B. ORGANIZATION OF THIS SUPPLEMENT
The entirety of ARINC Report 434 has largely been reorganized and modified from
its previous version. In all instances, the material found in Supplement 2 should be
used for any future reference. Changes to text are not highlighted or noted.
Section C below highlights the major technical changes.
C. CHANGES TO ARINC REPORT 434 INTRODUCED BY THIS SUPPLEMENT
This section presents a listing of the major technical changes to the document
introduced by this supplement. Each major change is identified by the section
number and the title as it will appear in the complete document. Where necessary, a
brief description of the change is included.
All Sections
Terminology changed to meet current and future usage.
Synthetic Training Device (STD) is now Flight Simulation Training Device (FSTD)
2.2.1 Customer and Supplier Points of Contact
Material added specifying that constant communication is critical to meeting the
needs of both parties.
3.1 Aircraft Contracts
Material added to highlight the need to consider the training department’s need for
OEM aircraft manufacturer’s data and models.
3.1.1 Procurement of a Used FSTD
Material added to highlight the need to identify any licensing encumbrances,
transferable data and models, and specific OEM and TDM support. Special care
should be taken with regards to data, software, and documentation (including
changes and upgrades).
3.6 In-Plant Acceptance
Material added to stress the need for the FSTD purchaser to identify problems with
data, software, or the Acceptance Test Manuals before leaving the TDM’s facility.
3.7 Site installation
Material added to illustrate the need to “firewall” FSTDs from outside networks.
3.12 Field Service Representative
Material added to specify when and how much TDM support is expected by the
FSTD purchaser and documented in the contractual phase added to highlight.
10.1.1 Purpose and Goals
Material added to provide guidance on hardware and software obsolescence.
APPENDIX A – GLOSSARY
Terms added, deleted, or modified as needed.
ARINC Standard – Errata Report
1. Document Title
(Insert the number, supplement level, date of publication, and title of the document with the error)
2. Reference
Page Number: Section Number: Date of Submission:
3. Error
(Reproduce the material in error, as it appears in the standard.)
4. Recommended Correction
(Reproduce the correction as it would appear in the corrected version of the material.)
5. Reason for Correction (Optional)

(State why the correction is necessary.)
6. Submitter (Optional)
(Name, organization, contact information, e.g., phone, email address.)
Please return comments to [email protected]
Note: Items 2-5 may be repeated for additional errata. All recommendations will be evaluated by the staff. Any
substantive changes will require submission to the relevant subcommittee for incorporation into a subsequent
Supplement.
[To be completed by IA Staff ]
Errata Report Identifier: Engineer Assigned:
Review Status:
ARINC Standard Errata Form

June 2014
ARINC IA Project Initiation/Modification (APIM)
Name of proposed project APIM #: _____
Name for proposed project.
Suggested Subcommittee assignment
Identify an existing group that has the expertise to successfully complete the
project. If no such group is known to exist, a recommendation to form a new
group may be made.
Project Scope
Describe the scope of the project clearly and concisely. The scope should
describe “what” will be done, i.e., the technical boundaries of the project.
Example: “This project will standardize a protocol for the control of printers.
The protocol will be independent of the underlying data stream or page
description language but will be usable by all classes of printers.”
Project Benefit
Describe the purpose and benefit of the project. This section should describe
“why” the project should be done. Describe how the new standard will improve
competition among vendors, giving airlines freedom of choice. This section
provides justification for the allocation of both IA and airline resources.
Example: “Currently each class of printers implements its own proprietary
protocol for the transfer of a print job. In order to provide access to the cockpit
printer from several different avionics sources, a single protocol is needed. The
protocol will permit automatic determination of printer type and configuration to
provide for growth and product differentiation.”
Airlines supporting effort
Name, airline, and contact information for proposed chairman, lead airline, list
of airlines expressing interest in working on the project (supporting airlines), and
list of airlines expressing interest but unable to support (sponsoring airlines). It
is important for airline support to be gained prior to submittal. Other
organizations, such as airframe manufacturers, avionics vendors, etc. supporting
the effort should also be listed.
Issues to be worked
Describe the major issues to be addressed by the proposed ARINC standard.
Recommended Coordination with other groups
Draft documents may have impact on the work of groups other than the
originating group. The APIM writer or, subsequently, The Committee may
identify other groups which must be given the opportunity to review and comment
upon mature draft documents.
Projects/programs supported by work
If the timetable for this work is driven by a new airplane type, major avionics
overhaul, regulatory mandate, etc., that information should be placed in this
section. This information is a key factor in assessing the priority of this proposed
task against all other tasks competing for subcommittee meeting time and other
resources.
Timetable for projects/programs
Identify when the new ARINC standard is needed (month/year).
Documents to be produced and date of expected result
The name and number (if already assigned) of the proposed ARINC standard to
be either newly produced or modified.
Comments
Anything else deemed useful to the committees for prioritization of this work.
Meetings
The following table identifies the number of meetings and proposed meeting days
needed to produce the documents described above.
Activity Mtgs Mtg-Days

Document a # of mtgs # of mtg days
Document b # of mtgs # of mtg days
For IA Staff use

Date Received: IA Staff Assigned:
Potential impact:
(A. Safety B. Regulatory C. New aircraft/system D. Other)
Forward to committee(s) (AEEC, AMC, FSEMC): Date Forward:
Committee resolution:
(0 Withdrawn 1 Authorized 2 Deferred 3 More detail needed 4 Rejected)
Assigned Priority: Date of Resolution:
A. – High (execute first) B. – Normal (may be deferred for A.)
Assigned to SC/WG:

ARINC 434-2 - FSTD Life Cycle Support

Uploaded by

Copyright:

Available Formats

ARINC 434-2 - FSTD Life Cycle Support

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ARINC 434-2 - FSTD Life Cycle Support

Uploaded by

Copyright:

Available Formats

FLIGHT SIMULATION TRAINING DEVICE

(FSTD) – LIFE CYCLE SUPPORT

ARINC REPORT 434-2

PUBLISHED: October 16, 2019

Prepared by the FSEMC

THIS DOCUMENT IS BASED ON MATERIAL SUBMITTED BY VARIOUS PARTICIPANTS

ARINC INDUSTRY ACTIVITIES USES REASONABLE EFFORTS TO DEVELOP AND

ANY USE OF OR RELIANCE ON THIS DOCUMENT SHALL CONSTITUTE AN

ARINC REPORT 434-2

FLIGHT SIMULATION TRAINING DEVICE (FSTD) – LIFE CYCLE SUPPORT

Published: October 16, 2019

Prepared by the Flight Simulator Engineering and Maintenance Committee

The AEEC, SAE ITC, and ARINC Standards

There are three classes of ARINC Standards:

b) ARINC Specifications – Are principally used to define either the physical

c) ARINC Reports – Provide guidelines or general information found by the airlines

An ARINC IA Project Initiation/Modification (APIM) form solicits any proposals for

1.0 INTRODUCTION ......................................................................................................... 1

ARINC REPORT 434

6.1 Introduction ............................................................................................................... 19

10.2 Obsolescence Resolution .......................................................................................... 31

ARINC REPORT 434

12.6 Relocation ................................................................................................................. 41

Specific aircraft type including variant – e.g.,

Field Name Description Customers Suppliers

The description of the issue may include a summary

2.4 Customers to Suppliers

3.0 PROCUREMENT AND INITIAL SERVICE OF A NEW FLIGHT SIMULATION TRAINING

3.6 In-Plant Acceptance

• Operational training checks, where the simulator is used as it will be after

completed, where it is stored, etc. It is recommended that the customer document

• Failures of original aircraft equipment and/or instruments for which the

5.0 TECHNICAL AND INSTRUCTOR TRAINING

5.0 TECHNICAL AND INSTRUCTOR TRAINING

6.0 CONFIGURATION MANAGEMENT

6.0 CONFIGURATION MANAGEMENT

6.0 CONFIGURATION MANAGEMENT

7.0 SCHEDULED MAINTENANCE

7.0 SCHEDULED MAINTENANCE

7.0 SCHEDULED MAINTENANCE

Additionally, the following types of backups should be kept:

7.0 SCHEDULED MAINTENANCE

7.3.1.2 Erasable Programable Read Only Memory (EPROM)

7.0 SCHEDULED MAINTENANCE

An emergency may be as large as an earthquake that destroys a facility, or as small

8.0 UNSCHEDULED MAINTENANCE

8.0 UNSCHEDULED MAINTENANCE

8.0 UNSCHEDULED MAINTENANCE

9.0 SPARES AND CONSUMABLES MANAGEMENT

9.0 SPARES AND CONSUMABLES MANAGEMENT

9.0 SPARES AND CONSUMABLES MANAGEMENT

9.0 SPARES AND CONSUMABLES MANAGEMENT

9.4 Last Time Buy

10.0 OBSOLESCENCE MANAGEMENT

10.0 OBSOLESCENCE MANAGEMENT

10.0 OBSOLESCENCE MANAGEMENT

• Establish maintenance operation and support processes to address

10.0 OBSOLESCENCE MANAGEMENT

Substitution: Identify a functional replacement for the obsolete part:

11.0 FSTD IMPROVEMENTS