Engineering change order

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Engineering change order" – news · newspapers · books · scholar · JSTOR (June 2012) (Learn how and when to remove this message)

An engineering change order (ECO), also called an engineering change notice (ECN), engineering change (EC), or engineering release notice(ERN), is an artifact used to implement changes to components or end products. The ECO is utilized to control and coordinate changes to product designs that evolve over time.

The need for an engineering change may be triggered by a number of events and varies by industry. Typical engineering change categories are:

• Product Evolution - a change resulting in applying an existing part to a new application and maintaining backwards compatibility
• Cost Reduction - a change resulting in lower overall cost to produce or maintain
• Product Performance - a change that improves the capabilities of the item
• Safety - a change required to enhance the safety to those using or interacting with the item

An ECO is defined as "[A] document approved by the design activity that describes and authorizes the implementation of an engineering change to the product and its approved configuration documentation".^[1]

In product development the need for change is caused by:

• Correction of a design error that doesn't become evident until testing and modeling, or customer use reveals it.
• A change in the customers' requirements necessitating the redesign of part of the product
• A change in material or manufacturing method. This can be caused by a lack of material availability, a change in vendor, or to compensate for a design error.

An ECO must contain at least this information:^[2]

• Identification of what needs to be changed. This should include the part number and name of the component and reference to the drawings that show the component in detail or assembly.
• Reason(s) for the change.
• Description of the change. This includes a drawing of the component before and after the change. Generally, these drawings are only of the detail affected by the change.
• List of documents and departments affected by the change. The most important part of making a change is to see that all pertinent groups are notified and all documents updated.
• Approval of the change. As with the detail and assembly drawings, the changes must be approved only by those individuals that are authorized to approve such a document. Typically, a number of individuals approve changes related to their own speciality with a final overall approval from management.
• Instruction about when to introduce the change—immediately (scrapping current inventory), during the next production run, or at some other milestone.^[3]

In chip design, ECO is the process of inserting a logic change directly into the netlist after it has already been processed by an automatic tool. Before the chip masks are made, ECOs are usually done to save time, by avoiding the need for full ASIC logic synthesis, technology mapping, place, route, layout extraction, and timing verification. EDA tools are often built with incremental modes of operation to facilitate this type of ECO.

After masks have been made, ECOs may be done to save money. If a change can be implemented by modifying only a few of the layers (typically metal) then the cost is much less than it would be if the design was re-built from scratch. This is because starting the process from the beginning will almost always require new photomasks for all layers, and each of the 20 or so masks in a modern semiconductor fabrication process is quite expensive. A change implemented by modifying only a few layers is typically called a metal-mask ECO or a post-mask ECO. Designers often sprinkle a design with unused logic gates, and EDA tools have specialized commands, to make this process easier.

One of the most common ECOs in ASIC design is the gate-level netlist ECO. In this flow, engineers manually (and often tediously) hand-edit the gate-level netlist, instead of re-running logic synthesis. The netlist files have to be searched for the logic affected by the change, the files need to be edited to implement the changes up and down the hierarchy, and the changes need to be tracked and verified to make sure exactly what needs to change gets changed and nothing more. This is a very time and resource-intensive process that is easily subject to errors. Therefore formal equivalence checking is normally used after ECOs to ensure the revised implementation matches the revised specification.

With time-to-market pressures and rising mask costs in the semiconductor industry, several electronic design automation (EDA) companies are beginning to bring more automation into the ECO implementation process. Most popular place and route products have some level of built-in ECO routing to help with implementing physical-level ECOs. Cadence Design Systems has recently announced a product called conformal ECO designer, that automates the creation of Functional ECOs, usually the most tedious process in implementing an ECO. It uses formal equivalence checking and logic synthesis techniques to produce a gate-level ECO netlist based on the changed RTL. Synopsys in the past had a product called ECO compiler that is now defunct. Synopsys now has primetime-ECO for dealing with ECOs.^[4] Tweaker-F1 & Tweaker-T1 have also come into the limelight in the recent DAC-2012 for their ECO algorithms.^[5]

The telecommunications industry has a formal process that takes elements of the ECO and other considerations and combines them into the "product change notice" (PCN). After telecommunications products have been generally available and/or in service for a period of time, it often becomes necessary for suppliers to introduce changes to those products. As a result of implementing these changes – regardless of who performs the actual work – the telecommunications carriers are significantly impacted with respect to labor and resources, etc. Thus, it is imperative that changes to these products are accurately reported and tracked through completion, according to the needs and requirements of the carriers.

The term "product change" includes changes to hardware, software, and firmware that occur over the entire life of a product. Product changes include those considered reportable and non-reportable. These changes may be applied by a supplier, a customer, or a contractor retained by the customer, depending on negotiated agreements. Fundamentally, the customer's goal is to ensure there is a process by which there is accurate and efficient tracking and reporting of changes to products.

Changes are considered reportable when they affect the performance or life span of a product. Such changes include any that affect the form, fit, function, or the product technical specification (i.e., documentation) of the product. The desire for supplier or customer traceability may result in a reportable change.

The entire PCN process is documented in GR-209, Issue 6, Generic Requirements for Product Change Notices (PCNs).