Representative End User Clients
Representative Automation Clients
Representative Software Clients
Industrial automation professionals are more than accustomed to constraints associated with the variety of means by which suppliers attempt to maintain a proprietary hold on customers and keep competitors at bay. While not an exhaustive list, in my career these mechanisms have ranged from the type of analog I/O signals employed in process automation (prior to establishment of the 4-20mA standard) to PLC programming languages, industrial network protocols, and beyond.
Programming Languages and Network Protocols as Legacy Examples
Yes, ladder logic is a standard language in the USA for PLC programming, but differing vendor implementations resulted in inability to port programs from one PLC to another and engineers specializing in programming a specific vendor’s controllers. Likewise with non-interoperable automation networks and protocols, even in the era of network stacks based on IEEE 802.3 standard Ethernet. The issue here lies in the upper, value-added layers of the network protocol stacks, where networks (that usually) share the same common base technology become incompatible. These two areas, programming and networking, continue to lock customers in and keep competitors out at any given manufacturing facility.
Enter the IIoT
The push for sensor-to-cloud integration is one of the primary initial action items inherent in bringing the industrial Internet of Things to the plant floor. Like earlier requirements for software integration in service of MES, ERP, supply chain, and other applications, ability to deliver sensor, device, and asset data from the manufacturing process to cloud-based IIoT applications is emerging as a primary functional requirement.
Again many standards are available for this purpose, including REST APIs, MQTT, OPC-UA, and numerous others. As outlined in the ARC Blog Battle for the Industrial Network Edge, however, enterprise-level IIoT software platforms are extending to the network edge in pursuit of seamless sensor-to-cloud connectivity. Since each of these platforms are vendor-specific, or particular to the developer and partner network, this once again raises the spectre of proprietary environments at the heart of the industrial architecture. And, like the experience with industrial Ethernet network protocols, this potential is true in spite of the enabling technologies’ reliance on one of the most universally common standards: the Internet.
The recent alliance between GE Digital and Intel, while certainly not the only example, portends developments in this space. Intel, maker of both chips and the popular Intel IoT hardware/software OEM IoT platform, intends to first install Predix in its own fabs for evaluation and then ultimately embed it in its OEM IoT platform offering. In the words of a GE Digital executive: “We want to embed Predix on every single Intel device, so that as they sell those devices, they’re selling Predix, and the customer just has to activate it,”
A further developing scenario is that the platforms provide not only sensor-to-cloud integration, but also a potential execution environment for edge applications developed by a variety of prospective developers. This will result in the need to not only interface to the vendor-specific platform for integration purposes, but ultimately also for application execution. These are core functions within the industrial internet architecture that bear close management and attention by all involved.
Programming Languages and Network Protocols as Legacy Examples
Yes, ladder logic is a standard language in the USA for PLC programming, but differing vendor implementations resulted in inability to port programs from one PLC to another and engineers specializing in programming a specific vendor’s controllers. Likewise with non-interoperable automation networks and protocols, even in the era of network stacks based on IEEE 802.3 standard Ethernet. The issue here lies in the upper, value-added layers of the network protocol stacks, where networks (that usually) share the same common base technology become incompatible. These two areas, programming and networking, continue to lock customers in and keep competitors out at any given manufacturing facility.
Enter the IIoT
The push for sensor-to-cloud integration is one of the primary initial action items inherent in bringing the industrial Internet of Things to the plant floor. Like earlier requirements for software integration in service of MES, ERP, supply chain, and other applications, ability to deliver sensor, device, and asset data from the manufacturing process to cloud-based IIoT applications is emerging as a primary functional requirement.
Again many standards are available for this purpose, including REST APIs, MQTT, OPC-UA, and numerous others. As outlined in the ARC Blog Battle for the Industrial Network Edge, however, enterprise-level IIoT software platforms are extending to the network edge in pursuit of seamless sensor-to-cloud connectivity. Since each of these platforms are vendor-specific, or particular to the developer and partner network, this once again raises the spectre of proprietary environments at the heart of the industrial architecture. And, like the experience with industrial Ethernet network protocols, this potential is true in spite of the enabling technologies’ reliance on one of the most universally common standards: the Internet.
The recent alliance between GE Digital and Intel, while certainly not the only example, portends developments in this space. Intel, maker of both chips and the popular Intel IoT hardware/software OEM IoT platform, intends to first install Predix in its own fabs for evaluation and then ultimately embed it in its OEM IoT platform offering. In the words of a GE Digital executive: “We want to embed Predix on every single Intel device, so that as they sell those devices, they’re selling Predix, and the customer just has to activate it,”
A further developing scenario is that the platforms provide not only sensor-to-cloud integration, but also a potential execution environment for edge applications developed by a variety of prospective developers. This will result in the need to not only interface to the vendor-specific platform for integration purposes, but ultimately also for application execution. These are core functions within the industrial internet architecture that bear close management and attention by all involved.