Add Real-time Networks to the Smallest PC-based Devices

Compute platforms are achieving incredible power in very small form factors. I’ve been contemplating where we could go with industrial applications built on Raspberry Pi. Then I saw this note from Hilscher. This is the world where that company plays. Here is a complete industrial communications application on the new M.2 format for PCI Express that adds real-time communications to PC-based systems.

In just a few minutes, you can connect PC-based devices, such IPCs, HMIs and robotics, to Real-Time Ethernet and Fieldbus networks. The comprehensive package has all necessary hardware and software components, including protocol stacks, device drivers and network connectors. The M.2 card can be simply installed in new and existing devices to connect with industrial automation networks on the fly.

PCI Express M.2, briefly named M.2, is smaller than the Mini PCI Express format and was designed for very thin computing platforms like notebooks and tablets. Since its introduction, automation manufacturers of PC-based systems, such as Industrial PCs, vision systems, robotics, and human machine interfaces (HMIs), have integrated M.2 sockets into their devices for one simple reason. The tiny M.2 format allows many add-in functions to be included into their systems in very tight spaces. Now, with this Hilscher offering, M.2 cards can provide real-time automation network connectivity.

M.2 formats come in various widths, lengths, and socket keys. For this first M.2 card release, Hilscher is using the A+E key socket arrangement, as that is the PCI Express specification’s generic form factor for connectivity add-ins, such as WiFi and Bluetooth. The M.2 2230 Key A+E card, with Hilscher product name CIFX M223090AE, is part of Hilscher’s cifX family of PC Cards. cifX PC Cards are intended for easy integration of a network interface and fast time-to-market of the manufacturers’ products and features.

At the heart of the M.2 2230 card is Hilscher’s netX 90 multiprotocol communication chip. M.2 card users can choose among loadable firmware for PROFINET IO-Device, EtherNet/IP Adapter, EtherCAT Slave and OpenModbus/TCP. Available in Q4 2020 is firmware for CC-Link IE Field Basic and Ethernet POWERLINK Slave. The appropriate network connector is included with delivery. There are adapters available from third-party vendors for other key formats, if required by the application. Additional firmware options, more card and key formats, and OPC UA and MQTT functionality will be released in the future.

Other benefits of the netX 90 ASIC include its small size, low power draw, reduced heat waste and extended temperature range. These features make CIFX M223090AE the smallest multiprotocol card in the market, at 22 mm X 30 mm, and allow it to operate in conditions from -20 deg C to +70 deg C. With its low power consumption, the M.2 2230 is ideal for energy saving applications.

Choosing the Hilscher M.2 card allows users to future-proof their designs. Hilscher continuously provides new firmware for Real-Time Ethernet, traditional Fieldbus and IIoT protocols. Besides a wide range of industrial protocols, Hilscher also provides device drivers for all major operating systems used in the industrial environment, including Windows, Linux, INtime, RTX, and QNX, as well as a C Toolkit for custom device drivers.

More on Industrial Protocols and Standards

More on Industrial Protocols and Standards

John Bernadin (retired Rockwell Automation executive) posted a comment on my LinkedIn post of my blog post on Protocol Wars–Vendors versus Standards.

“From the PLC side, the Auto industry began major efforts to drive standards in the 1990’s like GM’s MAP mfg automation protocol. However, after a decade they realized that even with their leadership and size, the Big Three and their top tier suppliers couldn’t get PLC vendors to agree on a standard. So in 2000, they decided it would literally take an “Act of Congress” to get vendors to agree. Two years later, a bipartisan Congress passed the Manufacturing Enterprise Integration Act of 2002 giving NIST over $150 million to develop and drive Interoperability protocols and standards. What happened next? President Bush never approved the budget for NIST to do it because he philosophically didn’t believe that the federal government should be creating standards. Thus, 25 years later we still have nothing — because this problem is like solving world hunger or world peace. It’s too big. “

Good recap, John.

Then there were PC standards

In those days, there was a PC standard. Actually, there were a few. There was an “XT” bus that standardized PCs on what became known as the PC platform. In the late 80s, IBM thought it would get fancy and recapture some proprietary technology it lost with the XT platform. Anyone remember Microchannel?But then PCI came along driven more by chip makers, I believe, to take the backplane to another level without being vendor specific.

I actually took classes and may still have a certificate around the house having passed tests on IBM’s proprietary, or sort-of proprietary, technologies. Remember also Token Ring? Yep, that was another. The third test had something to do with finance applications on the PC.

In those days you could build cards to plug into the bus. Only Apples were locked down.

There was an “embedded” PC world dominated by VMEbus and in the mid-late 90s PCI and then CompactPCI. PLCs were generally built on a modified VME but nothing was standard.

None of these things I’m talking about were driven by government. IBM allowed its first PC bus to become an industry standard that other companies could build to–and the PC industry took off.

Allen-Bradley CompactLogix I/O

Allen-Bradley CompactLogix I/O

In the 90s the big automakers grew frustrated with what was essentially a single PLC source and tried a bunch of things. Maybe the government. Maybe they were big enough to drive a CompactPCI standard. All PLC manufacturers would build on a single CompactPCI standard. Anyone’s cards would fit in the backplane–just like the PC industry. You could load anyone’s operating system and programming software on the platform.

By driving hardware and then software to commodity, then the automakers could drive the cost dramatically down.


Since the 80s and 90s saw tremendous innovation around the standards driven PC platform, it was logical (to users) that similar innovation advances would be seen in the industrial “PC” market.

Many things were tried. Many things failed.

Trouble is–the industrial market is much smaller than the PC market. A commodity industrial market would drive incumbents to seek other markets. Innovation would dry up. Suppliers drove to protect their turf.

And innovation exploded.

We saw many things added to the PLC platform driven by competition (although reducing interoperability):

  • PC technologies–memory, processing
  • Networking
  • Integrated motion control
  • Reduced footprint
  • Innovative development studios

But, alas, if you bought Rockwell, you were stuck with Rockwell. Same with Siemens, and everyone else.

Users did reap some price concessions. Better, they reaped technology advances because the suppliers could afford to invest in new technology.

New technology cycle

Theses curves always run their cycle.

Where are we now? Is there any reason to need a standard platform PLC? Or has that technology curve been passed?

Do we need a single protocol for moving data in this brave new IoT world? Or, will suppliers build gateways that foster inter-communication–or a bus such as the ws-ISBM? And render the argument moot?