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.
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.1
An industry-wide implementation of IPC-CFX on machines, manufacturing execution systems, and ERP systems would benefit:
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 process control by an MES can be summarized by the following list of features that must be provided on the test machines:
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.
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
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.
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.
1. Michael Ford, “How Do I Get Smart with IPC CFX? (Part 1 and Part 2),” SMT Interconnect 007, July 2019.
firstname.lastname@example.org. is senior software engineer at Optel., is CEO of Optel Software (optelco.com);