Page 31

Industrial Ethernet Book 105

Technology long before the internet was developed. At the edge, things like sensors, circuits, relays, and meters are attached to industrial control systems used to operate equipment and machines. These sensors translate what’s physically happening in the world (temperature, light, vibration, sound, motion, flow rate, and so on) into an electrical signal like voltage or current. The voltage or current is then interpreted by a controller, which monitors and controls physical equipment and machines. Sensors typically have little or no intelligence. They are designed to merely observe and report. They can’t speak in the digital bits and bytes, the ones and zeros that information technology and internet devices understand and use to communicate. They also lack the physical connections and logical interfaces to communicate on the industrial internet of things (IIoT). They do not have a built- in Ethernet jack or a wireless interface. They don’t understand the languages the internet uses, like JSON, RESTful APIs, and JavaScript. They don’t run an operating system or have a built-in TCP/IP stack or web server. And sensors have little or no built-in computing power, so providing edge computing at the sensor level to filter volumes of data before forwarding to the cloud is impossible. So right now the internet and the industrial things we want to connect to it aren’t communicating. What can we do? One option is to simply wait for highly intelligent, connected sensors to become available to the marketplace. But those sensors are years away from being cost effective. Moreover, sensors installed today or even decades ago are still performing their tasks. They’re just not connected to the IIoT, so the data they generate is siloed and inaccessible to IT systems for further analysis. In Lee’s factory, EPIC controller technology takes on the task of communicating with IT systems and the internet. Located at the edge and connected to sensors and devices through its I/O, the EPIC can speak the languages computer networks understand. The Big Data problem Across the globe a massive installed base of things exists today, generating useful data that the IIoT wants to access and consume. In oil and gas applications, a typical oilfield has up to 30,000 sensors installed. Factories and plants across the world have billions of sensors. Each sensor is capable of generating huge amounts of data from the physical world. Some IIoT applications could potentially generate terabytes of data per second. These are volumes of data the digital world has never seen before. This is the Big Data problem. Moving that much data onto existing network and internet infrastructures for cloudbased analytics and centralized management will clog networks, vastly increasing network and internet latency. For many industrial IoT applications, that is not acceptable, because real-time control and monitoring are mandatory. For the industrial internet of things to reach critical mass, intelligence must be pushed to the network edge, where the physical world meets the digital world. Computing systems at the network edge must have the capability to collect, filter, and process data generated at the source, before it’s transmitted up to the IIoT. And at the same time these edge computing systems must be able to complete the local real-time process control and automation tasks of traditional industrial applications. The Big Data problem can be at least partly solved by edge systems which have the computing power to sift and process data before sending it into network and internet infrastructure. The IIoT architecture problem A third problem revolves around how today’s IIoT architecture works. Let’s take a look at its complexity and explore a possible path forward. For a cloud-based server to capture data from an analog sensor today, the sensor’s data must be translated using a series of software and hardware tools. First, the sensor is physically wired to a device such as a PLC (programmable logic controller). While modern PLCs do provide basic analog-to-digital conversion of sensor signals, PLCs were not designed to interface with the IIoT. PLC hardware, software, and programming languages were designed for repetitive, application-specific tasks like process control and discrete automation. They typically use proprietary protocols and languages for communication and programming, and do not include information security standards like encryption and authentication. PLCs were originally designed as standalone systems. The protocols they use are seldom internet compliant and are designed for point-to-point communication instead of the point-to-multipoint communication architecture found in the IIoT ecosystem. If systems that communicate using internetcompliant protocols such as PCs, web servers, and databases want to communicate with a PLC, a vendor-specific and often proprietary software driver or hardware-based protocol gateway is required. OPC (Open Platform Communication) software is one solution to this communication disconnect. But OPC was originally designed around PC architecture using the Microsoft *HWFRQQHFWHG ZLWK0,&526(16 ,QGXVWULDO6ZLWFK3URIL/LQH5DFN *LJDELW3HUIRUPDQFHIRU,QGXVWULDO(WKHUQHW 5XJJHGLHG5HOLDEOH(IILFLHQW VVVLHBQNRDMRCDHMCTRSQH@K


Industrial Ethernet Book 105
To see the actual publication please follow the link above