How Do I Get Smart With IPC CFX? (Part 1)

Estimated reading time: 13 minutes

Enter the IPC Connected Factory Exchange (CFX)

IPC is responsible for creating consensus-based standards for the PCB assembly industry with many leading companies across the industry working together to find common, optimum specifications. The CFX committee within IPC was formed to create a solution for the challenges faced by the digitalization of factories with the creation of a true industrial internet of things (IIoT) standard covering all aspects of digital factory data content and data communication. The intent was to create a standard that is truly “plug and play” with the inclusion of all hardware and software vendors, using a single communication standard without dependencies, licensing conditions, or fees. Nor would the solution be controlled by any business entity, but rather by IPC.

To be a “plug-and-play” IIoT standard, three main criteria need to be defined. A simple analogy is the use of a mobile phone. The hardware works according to a standard, enabling handsets from many different vendors to connect seamlessly. The signal that is used to connect the handsets is a part of a defined standard network, shared by all carriers, supported on all handsets. This means that any phone can connect via a call to any other phone across the entire planet, connecting everyone together. The conversion of the spoken voice into the digital signal that is transmitted across the network is the encoding method.

Every handset needs to know the standard way to encode, and at the other end of the conversation, decode, the digitized content back into an analog voice. As in this mobile phone example, almost all standards regard themselves as complete at this point. The remaining issue is that although anyone, such as someone in the USA, can call any person in China, if the person in China does not speak English and the American does not speak Chinese, then they cannot communicate effectively at all. The definition of content, essentially the language that is used, is a critical part of the definition of a true communication standard, and is the crucial element that differentiates CFX as a true IIoT standard compared to legacy data transfer mechanisms. Even new so-called IIoT solutions that simply act as a conduit of poorly defined data from one point to another.

Being a native IoT solution brings control over the data content and availability into the hands of the machine vendor who can provide assurance of performance and compliance. Add-on IIoT solutions that simply move data into the Cloud, for instance, are based on interpretation of data from sources that are liable to change at any time and carry all the same risks of legacy systems under the guise of new technology.

CFX Transport and Encoding

Figure 1: AMQP v1.0 data transfer options.

In the case of CFX, the transport mechanism is AMQP v1.0 (Figure 1). This is a secure data transportation standard created and widely used in the finance industry for monetary transactions. Therefore, it is a very secure, globally proven and accepted, and reliable mechanism. Data messages can be encrypted where CFX is used to transfer sensitive data outside of the company domain.

AMQP v1.0 allows for two methods of communication, both of which are utilized by CFX. The first is a simple mechanism for anyone on the CFX network, referred to as an “endpoint,” to send a message to a central point, known as a “host” or “broker.” The host will then provide all of the work to distribute messages to any subscribers of the message. Thus, the endpoint creating the data does not need to care about which messages are being used or how many other endpoints need to receive the messages; further, it does not need to deal with the various confirmations required. To handle all of this would unnecessarily tax the computing power within the machine for this type of broadcast message, which could affect machine operation. Many free-of-charge hosts for AMQP v1.0 can be found on the internet that work with CFX.

In addition to the broadcast message type, there is also a requirement in manufacturing for direct point-to-point communication of very large or critical data. For example, this can be the transfer of a large 3D inspection image to another endpoint that may process the image to determine defect trends or for traceability purposes. Other applications may include closed-loop machine-to-machine analytics that drive continuous improvement of the performance of the line. AMQP v1.0 was selected for CFX as a modern, secure transportation mechanism that can support both of these modes of communication. The host may be Cloud-based, site-based, or a combination of each.

In addition to the publishing of data, each endpoint on the CFX network—such as an assembly machine—also has the ability to receive data from other machines and endpoints performing transactional events in the factory, such as material logistics. CFX is completely omnidirectional. In this way, every machine is given the opportunity to extract data from anywhere in the manufacturing environment, irrespective of the vendor, with which to improve and optimize their operation.

The JavaScript Object Notation (JSON) lightweight data-interchange format was selected as the mechanism in which to encode data into CFX messages. JSON is a modern data exchange standard widely used by many software systems, as a next generation of the older XML data exchange format.

CFX Messages and Content

The design intent of CFX is to allow it to be used for many disparate types of automated factory machines and processes, manual processes, and transactional events. Virtually all data standard attempts in the past took an approach to define content that appears logical at first glance. One considers the varied types of machines that exist and then maps out data content definitions by the type of machine, which seems reasonable. However, it resulted in undesirable outcomes in reality due to the nature of modern machines and systems in a factory.

There is entirely too much functional redundancy across machines; therefore, those standards became filled with redundant content. For example, many machines have internal transfer conveyors and work zones; stand-alone conveyors have these too, and many have barcode scanners for ID acquisition. Thus, these old approaches required re-implementation of that identical functionality or capability in myriad machines. Worse, the implementations often had different flavors for the same capability, leading to extreme difficulty in data interpretation by any data consumer that connected to those varied machines.

Finally, there was a failing beyond which the old approach could never advance, and that involves custom machines. Any approach based on machine type would require going to committee to define a custom-created machine workcell. These are quite common and relegated such systems back to custom integration. Fortunately, there is an entirely different and superior way to approach data content that suffers from none of these problems.

CFX took a novel and revolutionary approach to data content by looking at machines, not as monolithic entities but rather collections of base capabilities that could be common to many machines. But those capabilities are defined in the content standard only once, and then reused with perfect consistency. This concept of information building blocks based on the lowest level capability of a system or machine, or data topics, was created that represents individual functions and characteristics of manufacturing machines and processes. Through the combination of messages from different topics, the complete operational functionality of any machine or process—current or future—is modelled, including entirely custom machines of which there are only single examples in existence.

Figure 2: Topics as message building blocks.

In Figure 2, each topic is shown as a different color building block, assembling the relevant blocks together on the left of the diagram that match events that occur within the machine process describes the operation of each unique machine. Applications on the right side of the diagram can then decide which messages they should subscribe to based on their scope.

Page 2 of 3

• < Previous Page
• Next Page >