Lights-out manufacturing mandates a standard communication protocol.

Electronics assemblers often assume an MES solution is all they need to gain complete control of all processes and traceability for SMT, manual assembly, box build, test, and rework processes. But even if an MES solution provides interfaces to a wide range of equipment, the plant needs to purchase interface options for the equipment. Often, the investment is so large, they choose not to do it. A vendor’s proprietary interface to control and collect data from their machine in real-time can cost up to $5,000/machine. For a plant with 50 machines that need such interfaces, that is a significant investment that often exceeds the cost of the entire MES solution.

For companies that develop and sell MES, developing proprietary machine interfaces is a major resource, cost and time expense. Doing so involves constant updates and attempts to work with companies that often perceive MES vendors as competitors and are not willing to share interface information and data. Electronics manufacturers evaluate machines more and more on the type of communication interface they provide and their additional cost, and often buy machines from vendors that do not charge extra for communication interfaces. A standard interface always has been needed. Attempts to create one failed because of shortsighted interests of equipment vendors and a misunderstanding of the benefits to be gained from a standard interface.

To continue reading, please log in or register using the link in the upper right corner of the page.

{!guest}

The IPC-CFX standard aims to provide interconnection between equipment and systems and to simplify and lower the cost of Industry 4.0 implementations. It is not our goal to introduce the IPC-CFX standard here. For a good overview of the standard and possible applications, see Ford.¹

An industry-wide implementation of IPC-CFX on machines, manufacturing execution systems, and ERP systems would benefit:

• Electronics manufacturers, for whom it would simplify and reduce the cost of Factory 4.0 integration projects. Companies could select equipment based on its process capabilities and not worry about how it will integrate with other equipment and systems. Replacing equipment in the future will be seamless.
• Equipment vendors, whose customers will demand all equipment is CFX-compliant. The work presented here is the result of a major automotive electronics manufacturer demanding CFX interfaces from its test equipment suppliers. Equipment vendors will not be able to sell unless they provide CFX interfaces.
• MES vendors, which can focus on developing advanced production scheduling and control features, instead of resource-draining proprietary interfaces.

Here, we describe the role and real-life applications of IPC-CFX for control of test processes.

IPC-CFX Applications for Test Process Control

As of this writing, IPC-CFX has not been widely adopted. Outside of a small number of select vendors and multivendor demos at trade shows, very few real-life applications have been implemented. Not many pieces of equipment support CFX on a level needed for real production and Industry 4.0 integration. Here, we discuss integration between test machines and an MES for real-life process control applications. We will use our experience developing CFX-based integration among MES, ICT and AOI to discuss two scenarios:

• The test machine does not support CFX. A CFX adapter middleware is needed to translate messages from machine (formatted in machine native interface) to CFX and from CFX to the machine. Although this provides a standard interface for the MES, especially useful when a company has its own MES, it still requires an interface on the machine side and the development of the CFX adapter.
• The test machine supports CFX. The machines communicate directly to the MES using CFX.

The test process control by an MES can be summarized by the following list of features that must be provided on the test machines:

• Send details of the active recipe when a recipe is activated.
• Receive requests to activate recipes.
• Indicate whether the requested recipe was activated.
• Send the panel barcode when one is scanned.
• Wait for permission before running a test.
• Receive an indication of whether permission is granted.
• Display error messages to the user.
• Indicate when the test is completed.
• Provide the test results in machine-readable format.
• Indicate when the panel has left the machine.

The first case, when the test machine does not support CFX, is more complicated. We will describe a real application for MES-based process control of an ICT. We will use the case when the test machine requests permission to perform the test from the MES.

Routing enforcement is a fundamental feature of an MES. A machine can perform an operation only if the MES verifies the correct recipe is loaded and the PCB is supposed to be at that operation; i.e., none of the preceding enforced operations has been skipped, and no defects are still open. The overall system architecture is summarized in TABLE 1 and illustrated in FIGURE 1.

Table 1. System Components

Figure 1. System architecture.

Communication between the test machine and the MES proceeds as follows:

Whenever a recipe is activated on the machine, the machine informs the CFX adapter. The CFX adapter relays this information to the MES. The MES stores this information and uses it later for route validation.

When the machine scans a panel/PCB barcode, it sends it to the CFX adapter and waits for permission to continue.

The CFX adapter sends messages to the MES to announce a panel has arrived in the machine and to request permission to run via route validation.
The MES uses information in its data store, including knowledge of the active recipe on the machine, which was announced earlier, to determine whether the panel is ready to be tested. It returns a message indicating the result to the CFX adapter. If the validation failed because the wrong recipe is currently active at the machine, the MES will also send a message to request the correct recipe be activated. The CFX adapter informs the machine the validation failed and requests a specific recipe be activated if the MES requested it.

If the route validation failed, the machine takes appropriate actions to inform the operator and prevent the test from occurring.

If the MES requests a new recipe, the machine attempts to activate that recipe. It informs the CFX adapter whether it can activate the requested recipe. The CFX adapter relays the result of activating the recipe to the MES.

If the machine successfully activates the recipe, the CFX adapter also sends a message to the MES requesting route validation. When it receives a response, it informs the machine whether it may proceed.

If the route validation failed, the machine takes appropriate actions to inform the operator and prevent the test from occurring. At this point, the panel must be removed from the machine.

If the route validation succeeded, the machine begins its test. Meanwhile, the CFX adapter informs the MES the test is starting.

When the test completes, the machine informs the CFX adapter. The CFX adapter then reads the test results from the machine (e.g., from XML files or a database) and sends them to the MES. It also informs the MES the test has completed.

The CFX adapter requests confirmation from the MES that the test results have been received and are acceptable. The MES gives its response. The CFX adapter informs the machine of the result.

At this point, the CFX adapter informs the MES the panel is leaving the machine.

CFX Messages Implemented

• CFX.Production.RecipeActivated
• CFX.Production.UnitsArrived
• CFX.InformationSystem.UnitValidation.ValidateUnitsRequest (Validation Types: UnitRouteValidation, UnitStatusValidation, and UnitTraceValidation)
• CFX.InformationSystem.UnitValidation.ValidateUnitsResponse
• CFX.Production.ActivateRecipeRequest
• CFX.Production.ActivateRecipeResponse
• CFX.Production.WorkStarted
• CFX.Production.WorkStageStarted
• CFX.Production.TestAndInspection.UnitsTested (ICT) or CFX.Production.TestAndInspection.UnitsInspected (AOI)
• CFX.Production.WorkStageCompleted
• CFX.Production.WorkCompleted
• CFX.Production.UnitsDeparted

FIGURE 2 shows the primary message sequence. All features summarized above for the full control of the test process are implemented in a similar way. If the machine supports CFX, as was the case with an AOI vendor, the CFX adapter is not needed, and the machine itself sends CFX messages to the MES via the AMQP broker.

Figure 2. Sequence diagram for requesting permission to test.

Conclusions

Historically, electronics manufacturing has not been successful in achieving and sustaining a standard communication protocol between machine and software systems. For lights-out electronics manufacturing without operators, it is absolutely necessary. The IPC-CFX standard is needed for machine-to-machine and machine-to-software systems communication. Most vendors and customers still don’t know what to do with CFX. The success of its implementation for Factory 4.0 integration will depend on the level of pressure the largest manufacturers apply toward equipment vendors to provide CFX support. We are witnessing the beginning of such demand, and we hope that will intensify soon. All factors in factory automation: companies, vendors and software providers will benefit from a wide and successful CFX adoption and implementation.

More specifically, we expect the process (routing) control in the future will be performed by equipment itself through machine-
to-machine communication, provided by CFX.

We need support from equipment vendors to achieve that goal.

References

1. Michael Ford, “How Do I Get Smart with IPC CFX? (Part 1 and Part 2),” SMT Interconnect 007, July 2019.

Ranko Vujosevic, Ph.D., is CEO of Optel Software (optelco.com); ranko@optelco.com. Matthew Fischer is senior software engineer at Optel.

Register now for PCB West, the leading conference and exhibition for the printed circuit board industry! Coming this September to the Santa Clara Convention Center. pcbwest.com