The # 2 mistake is…Treating CM as an “End of Process” Activity
DO-254 requires Configuration Management (CM) and control of the data not only during the service life but also during development and verification of the item. Hardware developers commonly misunderstand the intent of DO-254 as it is applied to FPGA/PLD/ASIC development programs and treat CM as an “end of process” activity. Sometimes this is done to avoid the overhead of the change control (problem reporting) process. This clearly violates the objectives and concepts associated with a DO-254 development assurance process.
The DO-254 process requires change control (and data storage) objectives to be maintained throughout the development life cycle, starting at the Planning Phase. Data utilized to satisfy a DO-254 objective, and which is then relied upon for downstream development or verification activities, must be controlled formally with proper change management. This is done to ensure that proper evidence and data control is maintained for these downstream activities and data items (requirements, design, code, tests, review results, etc.).
Data items that are identified in DO-254 as hardware control category 1 (HC1) can then only be changed after a release using a formal change process, which is facilitated through a Problem Report (PR). This formal process ensures that the impact of any changes to data items, which are crucial in establishing the design and verification of the FPGA/PLD/ASIC, is understood and agreed upon by all affected participants in the development life cycle.
The focus of DO-254 is about controlling the process, not the output. Thus, these “in process” rather than “end of process” configuration management activities are a vital part of the “development assurance” that DO-254 mandates.
If you need help understanding how to implement configuration management in your DO-254 program, this is covered in the Patmos Engineering Services “DO-254 Airborne Electronic Hardware Certification” training.