CFX: Building the Foundation for Industry 4.0

Estimated reading time: 6 minutes

Starting at productronica 2017, and then on to IPC APEX EXPO 2018, SMT Hybrid Packaging 2018, and What’s New in Electronics (WNIE) Live 2018, IPC showcased the Connected Factory Exchange (CFX) initiative in action. The CFX Showcase provided a technical demonstration operating in real time with standardized machine data delivered from participating exhibitors through the cloud and onto visitors’ cellphones. What’s more interesting is that each showcase was supported by more than 25 vendors who have stepped up to create the world’s first conversion of a showfloor into a digital factory shop-floor.

In this interview, Dave Bergman, VP for international relations at IPC, discusses the latest developments with IPC’s CFX standard, including key highlights, impact in the electronics assembly industry, and what’s next.

Stephen Las Marias: David, give us a brief overview of CFX. What is it and what are the expected benefits?

Dave Bergman: CFX is a messaging format that provides the foundation for smart factory. At its base level, several IPC standards committees IPC have created a messaging concept in which each individual machine or part of the manufacturing line can be broken down into its smallest steps; those steps, while they probably have an internal machine code, include a goal to have that machine code or software communicate out in a common language. If I’m trying to speak English and you’re trying to speak Spanish, and there’s no interpreter, we’re going to struggle. The objective of CFX is to provide the interface in the machine-to-machine communication. It’s a standardized messaging format for electronic manufacturing and beyond.

The aim of CFX is to make it easier for companies to create smart factories, and smart factories refers to anything from manufacturing software running a plant and being able to communicate with the line, but also the machines talking to one another. There has been for some time a vision of manufacturing lines being self-correcting. Self-correction can only take place if your machines can speak to each other, and CFX is intended to help that.

Las Marias: Apart from smarter factories, what else is driving the need for CFX?

Bergman: There are several factors. One of the factors is an increased drive to efficiency, to increase productivity. If you have a smart factory, you can have your staff work in other areas while your machines are solving some of their own problems. What’s also driving it is the need for flexibility. For example, if I’m an EMS company or an assembly manufacturer, and I want to have a piece of equipment from vendor A, and a different vendor for my second piece of equipment, I’ll have a variety of suppliers. I want a way for all of them to communicate easily. If I want to bring in a new piece of equipment, I want to reduce the time that it takes me to have that piece of equipment integrated into my manufacturing environment.

Right now, much of the software interfaces that need to be added to have your new equipment work in the manufacturing line takes a lot of custom coding. The very fact that so many equipment manufacturers are willing to work together, it’s because their customers are driving and say, “We need this flexibility. We recognize the industry is going to be faced with different equipment from different manufacturers speaking different languages. We need a common language.” That’s what’s driving the demand for CFX.

Las Marias: What are the technical challenges, if any, in adopting CFX?

Bergman: This is an interesting question. Adoption, not to adopt. At some point in time, if I have 20 pieces of equipment, and six of them speak CFX and 14 of them don’t, that’s a problem that must be dealt with in some fashion if I’m expecting to see all the benefits of CFX. I think that would be true in any standard that you’re putting in place. I don’t see that that is an overwhelming barrier to implementation.

There will be some startup related issues as people are bringing things in. There are legacy machines that people will have to go back and work on CFX for some of their legacy machines.

Our vision is that if CFX becomes widely adopted as we expect, new machines that are going to be out on the marketplace will already have CFX built into them. So for legacy equipment, there will be some conversion time to bring those things into use. Other than that, I don’t see major technical challenges. CFX is intended to be a feature-rich standard.

Smart factories that do in-depth analytics as to what’s going on in the manufacturing environment requires a lot of data. That data can be collected in all the steps from all the devices, as everything has connectivity, and bandwidth and storage is getting cheaper and cheaper. That is not a significant barrier, but there are certain pieces of equipment out there, and conveyors are one example, where they don’t have a lot of memory storage. They are simple and can only take messages of a certain size because that’s all that was required of them. Whether that would change in the future or not, I don’t know, but in its current configuration, there are certain devices that struggle to push the messages that CFX might send. We have been talking with the Hermes standard group to find ways that CFX and Hermes can work together to solve that particular issue.

Any time you’re trying to implement something new, you’re going to bump into individual challenges that need solutions; this is one that’s been identified, and we think we have solutions for it.

Las Marias: During the CFX demo at IPC APEX EXPO 2018, I was able to talk to some of the manufacturers who participated. They were saying that Hermes is for the machine-to- machine connectivity whereas the CFX is for the messaging format for these machines, which is why I don’t think they’re competing, in a way.

Bergman: They serve different purposes. We have been discussing this for some time because both standards are industry-driven standards. They’re intended for somewhat different purposes, though there are portions that overlap. When IPC and the SMEMA Council merged in the late 1990s, we had a series of standards, and the SMEMA Council created IPC-SMEMA-9851, which was the connectivity of machines for line control. So that one manufacturer’s piece of equipment can tell the next one that something is coming. Simple messages like, “I’m sending a board. It’s coming down the line. Be ready to receive.” The other one says, "Okay, I got it. It's coming."

In those cases, a lot of it was hard-wired. The Hermes standard was intended to change that to software to make it easier for modification. Again, it was still intended for line control, not for factory control. Hermes doesn’t pull information out of the manufacturing line for any kind of analysis. It’s intended to control the manufacturing line. That’s an excellent purpose, and because of that focus, Hermes messages are very light or small, which is a benefit because now the Hermes standard can be used with a conveyor. If the messages are small, the conveyors can handle the message size and do their job. We are looking to create messaging within CFX to take advantage of that capability of Hermes.

To read the full article, which appeared in the October 2018 issue of SMT007 Magazine, click here.