A common inquiry from applicants is whether they have to do target testing, and if so, why, and how much to do. RTCA/DO-254, along with FAA Order 8110.105A, both emphasize the expectation that the testing of custom micro-coded components should be achieved (as much as possible) on the target hardware to be installed in the aircraft system.

It is understood that observability and robustness aspects at the board level related to testing FPGAs, PLDs and ASICS (Airborne Electronic Hardware, or AEH, devices) is not practical for devices with any amount of complexity. Therefore, it is well established that analysis through simulation may be used for verification of the functional aspects of the design.  Applicants typically perform functional simulation as well as behavioral simulation for the requirements-based testing and robustness testing aspects for AEH devices.  However, the applicant must still ensure these devices perform their intended function in the actual hardware environment (i.e., aircraft system) that will be delivered to the aircraft.

Testing the target (with the integrated AEH device) should cover as much of the AEH device function as possible. The applicant should justify why or where testing on the target is not possible and document this as part of the Hardware Verification Plan and the Hardware Verification Test Procedures.  It is important to plan ahead at the conceptual design phase to ensure pin level access to safety-critical functions performed by the AEH device. Keep in mind too that Target Testing does more than just test the AEH device function. Integration testing on the actual target hardware to be provided to the aircraft validates the AEH device interfaces to/from the board circuity and also validates the models used during functional and behavioral simulation of the AEH device.

It’s good to keep a spreadsheet or some sort of mapping that lets you see which requirements are tested by which means (i.e., simulation, other analysis, target testing, ATP, etc.). This can come in handy for your test coverage analysis and to show that simulation mapped to physical test results where the testing overlapped.