Abstract:
Various embodiments of the invention provide for secure data communication in industrial process control architectures that employ a network of sensors and actuators. In various embodiments, data is secured by a secure serial transmission system that detects and authenticates IO-Link devices that are equipped with secure transceivers circuits, thereby, ensuring that non-trusted or non-qualified hardware is prevented from connecting to a network and potentially compromising system behavior.

Description:
CROSS REFERENCE TO RELATED PATENT APPLICATIONS 
       [0001]    This application claims priority to U.S. Provisional Patent Application No. 61/896,553, titled “Systems and Methods to Secure Industrial Sensors and Actuators,” filed Oct. 28, 2013, by Samer A. Haija, Subbayya Chowdary Yanamadala, and Hal Kurkowski, which application is hereby incorporated herein by reference in its entirety. 
     
    
     BACKGROUND 
       [0002]    A. Technical Field 
         [0003]    The present invention relates to data communication networked control systems and, more particularly, to systems, devices, and methods of securing data transmission in industrial process control architectures. 
         [0004]    B. Background of the Invention 
         [0005]    Industrial network system integrators are tasked with ensuring that networked devices in the factory automation business properly communicate with each other so that they can perform complex functions without introducing unwanted downtime. However, industrial process control architectures oftentimes comprise PLCs from a particular vendor, wherein the PLCs have certain proprietary IO interfaces unique to that vendor, and sensors and actuators from another provider, who uses a different proprietary interface. 
         [0006]    Programmable logic controller (PLC) manufacturers and system integrators are primarily concerned with maintaining safety, transparency, and functionality. Sensor manufacturers share these goals, but in addition are often concerned about preventing unauthorized copying of their products and maintaining their reputation. 
         [0007]    One approach that system integrators take to ensure interoperability is to employ devices with universal, standardized, network-independent interfaces, such that devices can communicate with each other over standardized communication protocols. 
         [0008]    One such standardized communication protocol, which is incorporated herein by reference and will not be described in detail, is IO-Link. IO-Link is a communication protocol that is increasingly employed in process control systems as a fieldbus-independent standard for industrial point-to-point serial processing between a master and a device, for example, to remotely monitor and control smart sensors and actuators. Constant bi-directional communication and access to device-specific information enables remote parameter control and monitoring of networked devices. Data are accessed and exchanged with a standard protocol, standardized cabling (typically with unshielded, three-conductor sensor cables that simplify wiring), and standardized connectors. Increased integration and utilization of sensor and actuator information allows the system to detect and alleviate incidents in a process faster and more effectively. Thus, a high level of productivity and transparency can be maintained in automation facilities and other networks. Backward compatibility with conventional 24 V DI/DO devices adds to the attractiveness of IO-Link to system integrators. 
         [0009]    However, IO-Link, like other traditional systems, provides no mechanism for authentication. A sensor or actuator device is typically connected to a host via a powered cable; the host interrogates the device in order to determine how to communicate with and drive the device. Due to fairly simple, handshake-type communication present in existing networks that lack authentication mechanisms and other security features, nothing prevents a sensor or actuator from falsely signaling compatibility with any other device or exhibiting a different behavior during operation than is expected. 
         [0010]    What is needed are tools for system designers to overcome the above-described limitations. 
       SUMMARY OF THE INVENTION 
       [0011]    The disclosed systems and methods enable secure data communication in a network of sensors and actuators by using a secure serial transmission system. Various embodiments of the invention provide security at an individual sensor or actuator level by facilitating authentication of IO-Link devices using secure sensor transceivers circuits. In some embodiments, functions and components are embedded within the same die or on a separate die in a package. 
         [0012]    Various embodiments integrate a secure authentication feature with an IO-Link device transceiver and a master transceiver so as to enable encryption of the transceiver path depending on a level of authentication. 
         [0013]    In certain embodiments, the presence of a device that comprises an IO-Link secure transceiver is detected by sending an authorization request from an I/O-Link secure master transceiver to the device and validating a response prior to enabling transmission via a secure communication channel. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    Reference will be made to embodiments of the invention, examples of which may be illustrated in the accompanying figures. These figures are intended to be illustrative, not limiting. Although the invention is generally described in the context of these embodiments, it should be understood that this is not intended to limit the scope of the invention to these particular embodiments. 
           [0015]      FIG. 1  is a prior art bi-directional communication system utilizing a standard IO-Link interface. 
           [0016]      FIG. 2  is an exemplary block diagram of an IO-Link system architecture utilizing IO-Link device authentication, according to various embodiments of the invention. 
           [0017]      FIG. 3  is an exemplary functional block diagram of a secure transceiver utilizing IO-Link device authentication, according to various embodiments of the invention. 
           [0018]      FIG. 4  is a flowchart of an exemplary process for IO-Link device authentication according to various embodiments of the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0019]    In the following description, for the purpose of explanation, specific details are set forth in order to provide an understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these details. One skilled in the art will recognize that embodiments of the present invention, described below, may be performed in a variety of ways and using a variety of means. Those skilled in the art will also recognize that additional modifications, applications, and embodiments are within the scope thereof, as are additional fields in which the invention may provide utility. Accordingly, the embodiments described below are illustrative of specific embodiments of the invention and are meant to avoid obscuring the invention. 
         [0020]    Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, characteristic, or function described in connection with the embodiment is included in at least one embodiment of the invention. The appearance of the phrase “in one embodiment,” “in an embodiment,” or the like in various places in the specification are not necessarily referring to the same embodiment. 
         [0021]    Furthermore, connections between components or between method steps in the figures are not restricted to connections that are affected directly. Instead, connections illustrated in the figures between components or method steps may be modified or otherwise changed through the addition thereto of intermediary components or method steps, without departing from the teachings of the present invention. 
         [0022]    In this document industry and industrial mean manufacturing and other automation industry. The terms “IO-Link secure master transceiver,” “IO-Link master transceiver,” and “master transceiver” are used interchangeably. 
         [0023]      FIG. 1  is a prior art bi-directional communication system utilizing a standard IO-Link interface. System  100  comprises communication module  102 , sensor  104 ,  106 , cable  120 - 122 . Communication module  102  comprises microcontroller  110  and transceiver  111 - 114 . Microcontroller  110 ,  132 ,  142  includes a processor that processes data and stores it in a memory (not shown). In operation, microcontroller  110  communicates with sensor  104 ,  106  via transceiver  111 - 114  of communication module  102  and cable  120 - 122 , while microcontroller  132 ,  142  communicates with communication module  102  via transceiver  130  and  140  to control sensor elements  134  and  144 , respectively. Microcontroller  110  sends sensor data to a PLC (not shown). Communications module  102  communicates sensor information provided by sensor  104 ,  106  to the PLC. Sensor elements  134 ,  144  are typically remote sensors that measure a physical property, such as temperature, and generate a voltage that is representative of the temperature. 
         [0024]    However, non-trusted or non-qualified devices may freely connect to the network and potentially compromise the behavior of system  100 . Therefore, it would be desirable to prevent potential issues by ensuring that only authorized hardware is permitted to couple to and operate with any given process control architecture. 
         [0025]      FIG. 2  is an exemplary block diagram of an IO-Link system architecture utilizing IO-Link device authentication, according to various embodiments of the invention. Architecture  200  is a communications system comprising programmable logic controller (PLC) module  202 , communications module  210 ,  220 , and IO-Link device  232 ,  252 . Architecture  200  is typically part of an automated industrial process control network that operates at a 24 V level to exchange digital or analog signals, such as commands between PLC module  202  and IO-Link device  232 ,  252 . 
         [0026]    As shown in  FIG. 2 , PLC module  202  comprises PLC compute node  204  and PLC  206 . PLC compute node  204  may be a centrally located programmable controller that is coupled to control a network of one or more PLCs  206 . PLC compute node  204  may be networked in a LAN or WAN and be configured to set and modify parameters of IO-Link device  232 ,  252 . 
         [0027]    PLC  206  comprises multiple I/O paths that handle a plurality of analog and/or digital communication modules  210 ,  220 . PLC  206  may be implemented into a system backplane bus board (e.g., a serial bus) with decentralized peripheral buses that are used for intercommunication and/or to transfer power. PLC  206  may provide power to communications module  210 ,  220  and/or be isolated from communications modules  210 ,  220 , for example, by optocouplers. 
         [0028]    Communications module  210 ,  220  is an IO-Link that facilitates ease of connectivity of IO-Link device  232 ,  252 . In the example in  FIG. 2 , communication module  210  is a master unit that comprises microcontroller  212  and IO-Link master transceiver  214 - 218 . Communications module  210 ,  220  is coupled to IO-Link device  232 ,  252  via cable  222 ,  224 , which bi-directionally routes data to appropriate destinations. Data includes configuration data (e.g., device settings, hardware configuration), process data (e.g., measurement values, command signals, diagnostic data), specific information regarding the device (e.g., manufacturer model number, technical descriptions), and other data (e.g., industrial security functions) that aids the system integrator. Microcontroller  212  is a generic or a proprietary ASIC comprising memory (not shown) to store data that is transmitted over the serial link comprising IO-Link device  232 ,  252 . 
         [0029]    Cable  222 - 224  represents a secure communication channel between communications module  210  and IO-Link device  232 ,  252 . However, this is not intended as a limitation. Communication may occur over any suitable wired or wireless communication network, including Wi-Fi, etc. In one embodiment, cable  222 ,  224  is a standardized three-conductor cable with high, low, and ground wires that forms a serial link in which each IO-Link device  232 ,  252  represents a node. 
         [0030]    IO-Link secure master transceiver  214 - 218  is a transceiver configured to transmit data to and receive data from communications module  210 . In one embodiment, master transceiver  214 - 218  has multiple output ports to communicate with multiple IO-Link devices  232 ,  252  in a point-to-point configuration, i.e., each port is coupled to one IO-Link device  232 ,  252 . In one embodiment, master transceiver  214 - 218  operates in a multi-drop system configuration and allows for one or more unauthenticated devices to co-exist with authenticated devices within system  200 . IO-Link devices  232 ,  252  to connect to its ports, which may be analog or digital. Master transceiver  214 - 218  may be implemented as a single device or embedded into a control module, such as a control cabinet. 
         [0031]    In one embodiment, master transceiver  214 - 218  comprises components that perform security and network processing functions in order to provide inspection of incoming data and establish and maintain secure communication between multiple IO-Link device  232 ,  252  and PLC  206 . In one embodiment, IO-Link device  232 ,  252  comprises memory to store security-related information, such as a private key that serves as a device identifier, while IO-Link master  214 - 218  comprises memory to store a public key. Additionally, system  200  may employ a known or custom security protocol. In one embodiment, cryptographic algorithms may be combined with the protocol to ensure the integrity of the communication between IO-Link master  214 - 218  and IO-Link device  232 ,  252 . 
         [0032]    IO-Link device  232 ,  252  typically is an individual IO-Link instrument, such as a sensor, actuator, or RFID reader that is used, for example, for point-to-point communication between an automation unit and PLC module  202 . IO-Link device  232 ,  252  may have a unique address and may be independently powered and optically isolated. As shown in  FIG. 2 , IO-Link device  232  comprises IO-Link transceiver  234 , microcontroller  236 , and sensor element  238 , while device  252  comprises IO-Link transceiver  254 , micro controller  256 , and actuator node  258 . IO-Link device  232 ,  252  may further comprise a signal converter, such as an ADC (not shown), coupled to respective element  238 ,  258 . 
         [0033]    Sensor element  238  may include pressure switches, temperature sensors, motion sensors, flow sensors, and the like used in the management of industrial processes. Actuator element  258  is, for example, an electromagnetically activated device (e.g., a motor switch or a solenoid valve) that acts upon a control or instruction command received from master transceiver  218 . Actuator  258  may operate on digital or analog signals. 
         [0034]    In operation, microcontroller  212  is in communication with IO-Link device  232 ,  252  and, for example, a host device or controller (not shown) that controls the operations of an industrial process through a control program and/or a human operator. The host device or controller receives status information (e.g., error status) and adjusts device settings (e.g., resets). 
         [0035]    Communications module  210 ,  220  controls IO-Link device  232 ,  252  in a master/slave configuration by controlling data flow from and to IO-Link device  232 ,  252 . Communications module  210 ,  220  may be implemented as a card that is configured to couple, via PLC module  202 , to the host device or controller. In one embodiment, communications module  210 ,  220  directly communicates with a communications network (e.g., Ethernet) or user interface. 
         [0036]    In one embodiment, IO-Link secure master transceiver  214 - 218  establishes a secure connection between PLC module  202  and multiple IO-Link devices  232 ,  252  through which PLC module  202  can initiate communication and securely exchange data with IO-Link device  232 ,  252 . Once master transceiver  214 - 218  detects a connection to IO-Link device  232 ,  252  (e.g., at start-up), transceiver  214 - 218  sends an authorization request, IO-Link device  232 ,  252  commences transmission of a secret that is embedded in security transceiver  234 ,  254 . Upon successful authentication, IO-Link device  232 ,  252  initiates data transmission upon detecting a specified event, such as a sensed value exceeding a predetermined threshold level or an error warning. If authenticity cannot be verified, for example, because the secret or encrypted digital response signal cannot be deciphered, master transceiver  214 - 218  rejects the data transmitted from device  232 ,  252 . 
         [0037]    In one embodiment, IO-Link secure master transceiver  214 - 218  stores settings of IO-Link device  232 ,  252 , such as a transmission rate that is selected based on a known length of the serial link. In one embodiment, IO-Link secure master transceiver  214 - 218  provides signal conversion functions between communication module  210  and IO-Link device  232 ,  252 . 
         [0038]    IO-Link secure transceiver  234 ,  254  routes signals, such as control commands, to sensor elements  238  and actuator element  258 , for example in order to effectuate physical action, and retrieves response signals from element  238 ,  258 . Secure transceivers  214 ,  218 ,  234 ,  254  will be described in more detail with respect to  FIG. 3 . 
         [0039]    One skilled in the art will appreciate that system  200  may comprise additional components necessary for converting, processing, and securing data, such as logic devices, interface devices, power sources, DC/DC converters, memory, and optocouplers known in the art. 
         [0040]      FIG. 3  is an exemplary functional block diagram of a secure transceiver utilizing IO-Link device authentication, according to various embodiments of the invention. Secure transceiver  330  comprises security module  310  and IO-Link transceiver  320 . Secure transceiver  330  may be coupled to a communications module, a host controller, or directly to a computer. It is understood that secure transceiver  330  may include a number of additional interfaces, such an interface to an external network (not shown). 
         [0041]    In one embodiment, security module  310  is any device configured to process and secure otherwise unsecured digital data. However, this is not intended as a limitation, as certain security functions may be handled by other processors, for example, in devices embedded into transceiver  320 . In one embodiment, security module  310  comprises memory that holds, for example, a cryptographic key that is used to encrypt a message or decrypt a secret message. 
         [0042]    In one embodiment, security module  310  is implemented into transceiver  320 . In another embodiment, security module  310  is provided as a standalone module. 
         [0043]    In operation, security module  310  increases security by applying a security operation to data provided to or received from transceiver  320 . Security operations include encryption/decryption or authentication of data using public or private keys and other security protocols. 
         [0044]    In one embodiment, in order to facilitate a secure communication, secure transceiver  330  receives via port  306  a message with an authorization request, for example from a master transceiver (not shown), and responds to the request, via the same port  306 , by transmitting a secret embedded within security module  310 , such as a digital signature and/or certificate, to the master transceiver that shares the same secret. 
         [0045]    In one embodiment, secure transceiver  330  receives, via port  306 , secure data from a sensor (not shown) and inspects the secret in order to authenticate the source of the data and, thus, the validity of the communication. This may be accomplished, for example, by performing a decryption on the secure data by comparing the secret to a secret stored in security module  310  in order to produce an appropriate match. If the authentication procedure fails, the data is deemed invalid and subsequent communication is rejected. 
         [0046]      FIG. 4  is a flowchart of an exemplary process for IO-Link device authentication according to various embodiments of the invention. The process for authentication begins at step  402  by detecting the presence of an actuator device or a sensor device that is connected, for example via a cable, to a communications module. 
         [0047]    At step  404 , an authorization request is sent, for example, from the communications module to a sensor. 
         [0048]    At step  406 , a response signal is received, for example, by the communications module from the sensor. In one embodiment, the response signal is converted prior to processing and a security protocol is applied to the response signal. 
         [0049]    At step  408 , the response signal is used to validate the actuator or sensor. In one embodiment, the communications module determines whether the actuator or sensor is compatible with one or more devices. 
         [0050]    At step  410 , if it is detected that the response signal is valid, then at step  412  transmission via a communication channel is enabled, for example, by the communications module. 
         [0051]    If at step  410  it is detected that the response signal is deemed invalid, then at step  414  communication is disabled. 
         [0052]    Finally, the process resumes with step  402 . 
         [0053]    It will be appreciated by those skilled in the art that fewer or additional steps may be incorporated with the steps illustrated herein without departing from the scope of the invention. No particular order is implied by the arrangement of blocks within the flowchart or the description herein. 
         [0054]    It will be further appreciated that the preceding examples and embodiments are exemplary and are for the purposes of clarity and understanding and not limiting to the scope of the present invention. It is intended that all permutations, enhancements, equivalents, combinations, and improvements thereto that are apparent to those skilled in the art, upon a reading of the specification and a study of the drawings, are included within the scope of the present invention. It is therefore intended that the claims include all such modifications, permutations, and equivalents as fall within the true spirit and scope of the present invention.