Implementation Assurance

During the implementation phase, the higher level design is converted into a chip layout. The implementation process uses the tools supplied by the device vendor to match the functions that were defined in the design to the available blocks, gates, and other logic elements on the chip.

Much of the implementation process is performed by automated tools, so the assurance and safety engineers are usually not involved in any depth. The majority of assurance tasks are process verification

Use the Tailoring chart to determine which activities or analyses are required for a particular criticality classification. Activities that are not required may still be performed, if desired. Assurance activities for complex electronics implementation include:

• Problem Trend analysis
• Process Verification
• Update Risk analysis

The table below uses the Complex Electronics Classification to map the activities, and depth of each activity, against the classification. This table allows for easy tailoring of the assurance activities to the device complexity and criticality.

Problem Trend Analysis

Problem Trend Analysis identifies repetitive problems and assesses how often given problems occur. It also provides a mechanism to track progress of problem resolution. The main objective of this analysis is locating where key problems are occurring and the frequency of occurrence.

Problem Trend Analysis is more of a system-wide activity, rather than focused solely on complex electronics. As such, it should be performed by the quality assurance or systems engineer, to understand where problems are occurring. Regardless of who performs the analysis, a knowledgeable assurance engineer needs to review the problem reports that relate to the complex electronics (and the board, etc. that the chip is part of). Pay particular attention to problems that could indicate design errors in the complex electronics. Also note the number of unexplained anomalies that might relate to the device.

More detail on Problem Trend Analysis can be found in Section 8.2 of NASA Reference Publication 1358 , System Engineering "Toolbox" for Design-Oriented Engineers

Process Verification

• Verify that the design process, as defined in the project plans, was followed.
• Verify that the tools specified in the project plans are the ones that are being used. Note any discrepancies and the rationale for using a different tool.
• Verify that the configuration management system is being used as defined in the project plans.
• Verify that the device is programmed according to a defined process and that it is witnessed by appropriate personnel (usually quality assurance).
• Verify that post-layout and post-programming verifications are performed. Record any anomalies or problems using the appropriate problem reporting process.
• Assess problem reports relating to complex electronics for adequate root cause identification and appropriate corrections.

Update Analyses

Analyses performed during the requirements phase should be updated at this time.

Risk Analysis

Evaluate previous risks to identify those that no longer apply or that have changed their priority based on changes in probability or impact. Identify any new risks relevant to this phase of development and determine which require mitigation plans. Check that preventive measures and/or contingency plans exist for all identified risk items and that the risk, with mitigations in place, is acceptable for moving to the Testing phase.

Other Analyses

The other analyses, FMEA, FTA, Interface, and Traceability, do not require updates during this phase, unless there is a design change.