IPC-CFX is an electronics manufacturing industry developed standard forming the foundation/backbone of Industry 4.0 Applications.  IPC-CFX simplifies and standardizes machine to machine communication while also facilitating machine to business/business to machine solutions.

IPC-CFX can simply be described as a standard providing a purpose, working components, benefits, with several applications and sustainability.

Based on input from the Hermes group and the IPC-CFX committee, the formats are supportive and complimentary. They are not competitive formats.

There is no charge or cost for the software. The committee insisted that it be an open source product.

Post them on Message Board Questions on SDK or CFX

As with all IPC Standards, there is a small fee to cover the cost of the standard.

Visit the Join Us page and follow the instructions.

No middleware is required. One of the primary goals of the IPC Connected Factory Exchange Subcommittee when it developed CFX was to eliminate the need for middleware or other programming to enable machines to communicate with one another on a line. CFX is implemented natively within each machine and system.

No. The IPC Connected Factory Exchange Initiative Subcommittee developed standardized equipment messaging to enable any piece of equipment in a CFX line – new or legacy – to perform omnidirectional, point-to-point, request/response (command/response) communications with any other piece of equipment in the network without the need for extensive programming or messaging modification.

Yes, since CFX defines the specific data content for all fields and topics, any endpoint in the CFX network can understand the content from all other endpoints, no matter what type of equipment or software they are, nor from which vendor they originate.

Yes, CFX messages are encoded using JSON, and sent using AMQP which has the option of securing the data through encryption from source.

CFX supports broadcast messages which pass through an open-source AMQP host to any number of recipients as well as direct request and response command messages between any two specific endpoints.

No. CFX enables manufacturing facilities of any size to be able to easily implement CFX with minimal hardware requirements. If your facility has one or two servers operating on a standard 100 Mbps Ethernet network, you are CFX-ready.

JSON – or JavaScript Object Notation – is an open-standard data format that uses machine- and human-readable text to transfer data messages. The IPC Connected Factory Exchange Initiative Subcommittee selected JSON for encoding CFX messages because it is easy for people to read and write as well as for any machine to parse and generate data. CFX messages encoded with JSON can then be easily transferred and read by any device or ERP system.

AMQP was developed in 2003 by a consortium of 23 companies to facilitate the reliable processing of secure financial transactions across broad geographies. These companies include JP Morgan Chase, Bank of America, Barclays, Cisco Systems, Microsoft, Credit Suisse, Deutsche Börse, Goldman Sachs, HCL Technologies Ltd, Progress Software, IIT Software, INETCO Systems Limited, Informatica, Corporation, my-Channels, Novell, Red Hat, Software AG, Solace Systems, StormMQ, Tervela Inc., TWIST Process Innovations ltd, Vmware, and WSO2.

The IPC Connected Factory Exchange Initiative Subcommittee selected AMQP because it eases the burden of equipment manufacturers and factory-level system providers as they implement their CFX support because it eliminates most of the development effort needed to send and receive CFX messages. It also guarantees delivery of messages from one device in a CFX network to another device in the CFX network.

Some other additional highlights about AMQP:

• Provides security to prevent unwanted, uninvited, and/or malicious participants in a CFX network.
• Provides encryption to protect the information shared within a CFX network.
• Supports both publish/subscribe and request/response communication patterns, which enables CFX to use one, singular protocol.
• It is a highly evolved and standardized, advanced messaging protocol supporting a myriad of complex routing strategies and communication patterns
• Supports both unsolicited messaging and request/response pattern.
• Fully symmetrical communication (broker or device can initiate communication)
• Supports message payload of any data type or encoding. 
• Highly advanced protocol, supporting many communication patterns and routing strategies.
• Many free or near-free, open source brokers and client developer toolkits available for all major platforms (Java, .NET, C++, etc.)
• Very advanced Quality of Service mechanisms (guaranteed delivery, delivery receipts, long-lived durable message queues).
• It provides advanced security features, in excess of what other systems provide
• Highly robust and stable.
• Billions of mission critical messages can be transported via AMQP in commercial applications every day.
• Basic server can process 24,000 messages per second, which is well within the demands of a large-scale factory.

Because CFX is an out-of-the-box plug-and-play machine-to-machine standard, the time and costs associated with implementing CFX are incredibly less than those of other standards. The IPC Connected Factory Exchange Initiative Subcommittee has assessed implementation and testing time and costs for CFX compared with other machine-to-machine communications standards to provide a high-level summary of expectations for a manufacturing site.

CFX:

• Download the SDK, reading the document & become familiar with the SDK layout (1 hour)
• Integrate the SDK into the existing native machine software (3 hours)
• Link triggers form the machine software to trigger CFX messages (3 days)
• Testing: check alignment with the standard, using local AMQP host, or, www.connectedfactoryexchange.com (1 day)
• Business trips for R&D, discussion, preparation etc. None
• Business trips for deployment and testing: None
• NDA & legal issues: None
• Total cost: about 1-man week, just once, no cost for further adoption

OPC-UA, MT-Connect , MQTT-derived Interface, Others

• Discuss support specification, choose library, decide commands and messages (1 month)
• Develop machine interface support (1 - 3 months + 1 paid systems support specialist visit)
• Middleware integration (1 month + 1 paid systems support specialist visit)
• Testing (1 month + 1 or 2 paid systems support specialist visits)
• NDA & legal issues: Potential license agreement if aligning to middleware
• Total cost: about 4 months + 2 paid systems support specialist visits, with about half this as a repeated costs on a per-customer basis

SEMI/JARA Standard:

•  Discuss support specification, decide commands and messages (2 months)
• Develop machine interface support (2 - 3 months + 1 paid systems support specialist visit)
• Middleware integration (3 months + 1 paid systems support specialist visit)
• Testing (2 months + 2 paid systems support specialist visit)
• NDA & legal issues: 2 weeks needed for NDA
• Total cost: about 8 months + 4 paid systems support specialist visits, all costs repeated for each customer

No, it is not. IPC-HERMES-9852, developed by The Hermes Initiative and approved by IPC as a joint standard, is the replacement for the SMEMA standard.

In comparing the SEMI ELS standard with IPC-HERMES-9852:

• IPC-HERMES-9852 is a full replacement of the SMEMA standard and was developed to be an easily integrated drop-in replacement. With IPC-HERMES-9852, data are passed along a shop floor as a digital twin, with clear board statuses communicated to and from each piece of equipment. The SEMI ELS standard uses an archaic approach to board handling, which results in hardware costs and software problems.
• IPC-HERMES-9852 and IPC CFX, used together, provide a clear cut between vertical and horizontal tasks, making these standards together far more powerful than SEMI ELS.
• IPC-HERMES-9852 provides full line coverage, whereas SEMI ELS misses coverage for many parts of a factory line.
• IPC-HERMES-9852 is an open standard developed by The Hermes Initiative. Any equipment vendor can participate in the process. SEMI ELS participation takes place behind closed doors, and participants must sign an NDA. The Hermes Initiative has more than 60 manufacturer members participating, whereas SEMI ELS has a third of that amount.

SECS-GEM transmits message in a binary format between devices and a host control system, or server, which communicates decisions back to the machines, which is why the IPC Connected Factory Exchange Initiative Subcommittee decided this standard is not an Industry 4.0 solution.

CFX, however, is a single-source Industry 4.0 system because it transmits messages between machines and between machines and EPR systems and enables direct interaction between those machines and systems, without having to route through another system. This is the basis for smart factories, IIoT and Industry 4.0.

Because SECS-GEM’s origins date to the 1980s, it can be complicated for today’s software developers to work with and can require the need to purchase commercial toolkits to support development efforts. CFX utilizes open, standardized, off-the-shelf file formats JSON and AMQP, which are very common data formats that are very familiar to software programmers. SECS messages are proprietary, binary structures and cannot be decoded using off-the-shelf tools such as with JSON or XML.

Because of CFX messages are encoded with JSON and transmitted with AMQP, data can be read and understood by any device on any shop floor as well as by any ERP system, and the data are transmitted in a secure fashion.

SECS-GEM does not provide security capabilities and requires an isolated network in a facility to prevent intrusion.

The Hermes Standard (IPC-HERMES-9852) is a replacement of the IPC SMEMA standard, including new smart functions that provide automated changeover for mixed production without the need for additional hardware, such as scanners, at each machine. Data exchanged with Hermes is limited to real-time information, such as standard program name, panel width and height and unique panel ID. IPC-HERMES-9852 is simple to deploy, uses standard connections (TCP/IP) and enables the user to avoid the use of complex SECS-GEM management in a factory line.

The CFX standard is complementary to The Hermes Standard (IPC-HERMES-9852). The Hermes Standard, as an advanced intelligent SMEMA replacement, provides near-instant line control, passing information about production units as they pass down the line. CFX provides vertical messaging that is complementary to Hermes.

CFX and Hermes are two separate standards and protocols, which can complement one another or be used independently of one another on a factory line, based on the needs of the manufacturer. Any factory can take advantage of all the benefits of CFX without the need for Hermes, and vice-versa.

Because both standards are utilized in the electronics manufacturing industry, the IPC Connected Factory Exchange Initiative Subcommittee, which manages IPC-2591, is making efforts to work with The Hermes Initiative members to ensure the two standards complement one another for the best of industry.

OPC-UA is a machine-to-machine communication protocol for industrial automation. Because OPC-UA focuses on the communication only and not on the data architecture or machine-to-machine messaging that IPC CFX provides, it is not a replacement for IPC CFX, nor is it a plug-and-play Industry 4.0 standard for the electronics industry like CFX. OPC-UA will require middleware for any level of electronics manufacture shop floor communication.

MTConnect is a protocol designed for the exchange of data between shop floor equipment and systems used for monitoring and data analysis. MTConnect is a read-only standard. It defines the extraction of data from control devices but does not write data to a control device.

CFX differs from MTConnect because it provides a constant flow of data between pieces of equipment as well as between equipment and ERP systems to enable a fully automated shop floor. MTConnect is not a plug-and-play Industry 4.0 standard for electronics manufacture and will require middleware to implement it on a shop floor.

The simple answer CFX with a secure bridge provides the security that is needed. Though extensive measures will typically have been taken to protect the IT network against cyber-attacks from outside the network, problems are just as likely to come from within, as most production machines now can connect to the internet. Where sensitive products are being made, IT teams insist that there must be no electrical or other physical connection between the strictly managed company IT network, and what takes place on the shop-floor. For this reason, the Smart connected factory represents an impossibility. Sharing of data between machines and devices on the shop-floor is restricted to a local “OT” network which has no outside connection, and no connection to the main IT system.

Uniquely with CFX, a secure bridge may be developed and used to connect a single border-control device in between both network systems. On the IT side, there is the company-sanctioned security policy, and on the other, the connection to the factory floor, which as a default will have a complete block of any and all network activity. Nothing whatsoever can pass through the border control device, except CFX data through one port. Software on the border control device provides monitoring of all aspects of the data stream, blocking any unrecognized activity.

In the case of CFX, this is simple to achieve, as CFX is the only standard that is based on fixed data content definition, such that all data can be specifically authenticated against the standard. Both the CFX SDK and the AMQP v1.0 host software packages are open source, so the code can be scrutinized by the IT team, who can incorporate it into their own border control software, with no dependencies on third parties for the security of the network. The breakthrough that this approach represents is very significant for Smart manufacturing in sensitive operations.