Patent Application
20070186010
The subject invention relates generally to industrial control systems, and more particularly to systems and methods that enable communications and communications performance to extend beyond standard protocol boundaries for industrial control systems.
Industrial controllers are special-purpose computers utilized for controlling industrial processes, manufacturing equipment, and other factory automation, such as data collection or networked systems. At the core of the industrial control system, is a logic processor such as a Programmable Logic Controller (PLC) or PC-based controller. Programmable Logic Controllers for instance, are programmed by systems designers to operate manufacturing processes via user-designed logic programs or user programs. The user programs are stored in memory and generally executed by the PLC in a sequential manner although instruction jumping, looping and interrupt routines, for example, are also common. Associated with the user program are a plurality of memory elements or variables that provide dynamics to PLC operations and programs. Differences in PLCs are typically dependent on the number of Input/Output (I/O) they can process, amount of memory, number and type of instructions, and speed of the PLC central processing unit (CPU).
In recent years, there has been a growing need to integrate industrial control systems across a plurality of different types of networks and protocols while maintaining communications performance of smaller or more-proprietary systems. One problem here is that often times a desired communication interface and required communications services do not match. For code compatibility, it may be desirable to use an existing industrial protocol interface, yet there is a need for higher level services, such as gateway functions, multicast or time synchronization, which generally are not available. In many cases, either the communication service interface need to be changed to a more full featured protocol or the existing protocol need be enhanced to support the required features.
Along with communicating on a desired network, consider the situation where a PLC desires to implement connectivity via an industrial network protocol. Newer protocols such as EtherNet/IP have a rich set of application-level objects as well as complex network protocol layers. A PLC implementing EtherNet/IP connectivity will find it useful to include application layer features (application objects). However, it is desirable not to require the PLC processor to implement the entire EtherNet/IP network layer. There are several current methods in which industrial protocol support is implemented in PLCs. Existing EtherNet/IP implementations, for example, generally implement the network and application layers in the PLC itself, using the backplane between the PLC and Network Interface Module as a network hop. For older and simpler protocols, PLCs often use a dual-port or memory-map interface between the PLC and Network Interface Module to transport the actual industrial protocol packets.
In one example of a previous industrial communications protocol, a Data Highway (DH) and Data Highway Plus (DH+) protocol have been employed to enable remote communications between a given PLC module and one or more remote communications devices. These protocols are generally associated with PCCC protocols which stand for “Programmable Controller Communications Code. In some cases, these protocols have been used to control remote I/O devices operating in remote I/O racks. One example for achieving such control and communications has been to utilize what is known as a pass-thru function where remote I/O commands are sent though a DH or DH+ communications packet. In other words, a remote I/O command may be transported within a respective DH or DH+ communications command to control remote I/O functions. Although this type of communications has been successful in the past, it is noted that remote I/O protocols and the DH/DH+ protocols are related by a common industrial protocol. There is a need however to communicate between devices that employ non-related or disassociated industrial protocols.
The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
Multi-functional communications components and processes are provided that facilitate industrial control system communications across a plurality of differing network protocols. In one aspect, an industrial control communications component is provided that can reside as a separate entity or within a control system module itself. This includes the capability to encapsulate at least one industrial protocol within another industrial protocol, where the protocols are unrelated or disassociated from one another in order to facilitate communications between differing communications systems. In one specific example, a first protocol could act as a payload for one or more subsequent protocols, where the subsequent protocols are unrelated to the first protocol. In this manner, an “outside of network” device could be added to an existing network where commands to the respective device are carried across the existing network yet specified or encapsulated within existing network protocols. This also mitigates having to redesign existing protocols and systems to accommodate new or foreign industrial protocols since the new protocols can be payload-ed on top of or within an unrelated industrial protocol.
In general, differing industrial protocols are considered as at least one open industry standard protocol (e.g., Control and Information Protocol) that operates as a payload for at least one other open industry standard protocol (e.g., MODBUS), where specifications for such protocols are readily available. In another aspect, a protocol interface can be provided where application layer functionality is distributed across modules in order to mitigate communications burdens on critical control elements such as controllers. In yet another aspect, converter components can be provided that maps one type of network protocol to one or more other network protocols. The communications component can also facilitate communications by providing multiple communications stacks that process communications from divergent networks and protocols.
In one particular aspect, a communications or control component encapsulates one industrial protocol within another unrelated industrial protocol. The communication interface of the encapsulated protocol can remain similar in nature to prior interface implementations to mitigate re-design, yet provide expanded services of the encapsulating protocol which is added to existing communications infrastructure. For example, a MODBUS protocol could be encapsulated within a separate industrial Control and Information (CIP) protocol to facilitate communications between these differing network protocols.
In another aspect, network overhead for a module is mitigated by distributing network layer functionality across module boundaries. For instance, application objects that are appropriate for a programmable logic controller (PLC) are able to be implemented in the PLC. A Network Services Layer exposes network layer communication primitives to the application objects as if a network protocol stack was implemented on the PLC itself. As such, whether the stack is on the PLC or on an associated Network Interface Module, the stack is substantially transparent to the application layer which allows for sharing resources across modules without over-burdening a particular module.
In yet another aspect, a protocol converter can be provided that maps protocol differences in a substantially transparent manner. This enables communications in one protocol to be mapped to a subsequent network protocol while mitigating design changes to existing protocols. In another aspect, multi-level communications capabilities can be provided for a given module. For instance, there are several Industrial Ethernet protocols such as Ethernet/IP, MODBUS TCP and ProfiNet. Multiple communications protocol stacks can be provided to enable products that are able to communicate to these various protocols such that a single product could provide Ethernet (or other protocol) connectivity for multiple protocols.
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
Systems and methods are provided for communications across multiple networks in a substantially transparent and seamless manner. In one aspect, an industrial automation system is provided. The system includes a communications component to facilitate communications in an industrial controller network, where the communications component can include a protocol encapsulation component, a network services interface, or a protocol converter to process multiple network protocols. A controller component employs at least one network protocol to communicate with at least one other network protocol via the communications component. Also, the communications component can include multiple communications stacks to facilitate communications with the multiple network protocols.
It is noted that as used in this application, terms such as “component,” “stack,” “protocol,” “converter,” “interface,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution as applied to an automation system for industrial control. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computer. By way of illustration, both an application running on a server and the server can be components. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers, industrial controllers, and/or modules communicating therewith.
Referring initially to
In general, the encapsulation component 130 transports data by wrapping one industrial protocol within another unrelated industrial protocol. The communication interface of the encapsulated protocol can remain similar in nature to existing interface designs in order to mitigate component re-designs, yet provide expanded services of the encapsulating protocol which is added to existing communications infrastructure. For example, a MODBUS protocol could be encapsulated within a Control and Information (CIP) protocol to facilitate communications between these differing network protocols. As can be appreciated, a plurality of protocols can be employed to encapsulate a subsequent protocol or to be transported within an encapsulation protocol. For instance, CIP protocols can be encapsulated in DeviceNet or Ethernet protocols and be adapted to operate as a payload for one or more other industry protocols that are of a different or unrelated protocol from the underlying CIP protocol. In general, a payload protocol configured for an industrial protocol is an open industry protocol specifications of which are available to the public. Within the respective payload, one or more unrelated yet open industry protocols can be embedded in the payload. These unrelated protocols to the payload are then transported across a common network yet are employed to serve as a gateway for communications functions between devices that employ differing industry standard protocols. The payload architecture also promotes future communications extensibility since future industry standard protocols can be subsequently embedded or payload-ed within or on top of existing industrial communications protocols.
In another aspect, network overhead for a module can be mitigated by distributing network layer functionality across module boundaries. For example, application layer objects that are suitable for a PLC can be implemented in the PLC. The Network Services Layer 150 exposes network layer communication primitives to the application objects as if a network protocol stack was implemented on the PLC itself or in this case the communications component 130. As such, whether the stack is on the PLC or on an associated Network Interface Module, the stack is substantially transparent to the application layer which allows for sharing resources across modules without over-burdening a respective industrial control system module.
The protocol converter 160 maps protocol differences in a substantially transparent manner. This enables communications in one protocol to be mapped to a subsequent network or industrial protocol while mitigating design changes to existing protocols. In another aspect, multi-level communications capabilities can be provided for a given module. For instance, there are several Industrial Ethernet protocols such as Ethernet/IP, MODBUS TCP and ProfiNet. Multiple communications protocol stacks 170 can be provided to enable modules to communicate to these various protocols such that a single product can provide Ethernet (or other protocol) connectivity for multiple other protocols.
Before proceeding, it is noted that the system 100 can include various computer or network components such as servers, clients, communications modules, mobile computers, wireless components, Application Oriented Infrastructure (AON) type devices, application and integration servers, message brokers, and so forth which are capable of interacting across the network. Similarly, the term PLC as used herein can include functionality that can be shared across multiple components, systems, and/or networks. For example, one or more PLCs can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, I/O device, Human Machine Interface (HMI)) that communicate via the network which includes control, automation, and/or public networks. The PLC can also communicate to and control various other devices such as Input/Output modules including Analog, Digital, Programmed/Intelligent I/O modules, other programmable controllers, communications modules, and the like. The network can include public networks such as the Internet, Intranets, and automation networks such as Control and Information Protocol (CIP) networks including DeviceNet and ControlNet. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, MODBUS, Profibus, Web Services, wireless networks, serial protocols, and so forth. In addition, the network devices can include various possibilities (hardware and/or software components). These include components such as switches with virtual local area network (VLAN) capability, LANs, WANs, proxies, gateways, routers, firewalls, virtual private network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and/or other devices.
Referring now to
Turning to
In the system 400, the Application Objects 420 that are suitable for the PLC are implemented in the PLC 410. The Network Services Layer 430 exposes the network layer communication primitives to the Application Objects 420, as if the network protocol stack was implemented on the PLC itself. As such, whether a stack 440 is on the PLC or provided on an associated Network Interface Module 450, the stack is therefore substantially transparent to the application layer. The Network Services Interface 430 can be provided via an applications programming interface (API), remote procedure call, transparent inter-process communication (TIPC) or other mechanism that models the interface to the network stack without generally requiring industrial protocol communications itself to be transported over a backplane 460.
By employing data mapping processes, remote device and software tools can communicate with another devices data model, without having to understand the transport mechanism used. It is rapidly becoming a standard practice for developers to focus on the value add of the application instead of the proprietary communication mechanisms. The features shown in the component 500 can be considered offered by a CIP based device or a gateway device as web services. As illustrated, the automation device can include read coil functionality, write coil functionality, read input register functionality, a function component, an input register component, a function 5 component, a coil component, and a MODBUS component, for example.
In another aspect, a MODBUS service can be mapped to a CIP object. For instance, Read Coil'a CIP object “Read Coil” is implemented to receive a similar type of parameters that a MODBUS TCP message would have received except it is mapped to data of a CIP server such as set attribute all, or read, for example. For Read Input Register, or Input Register or Register (not shown), there are MODBUS commands provided to read a register. It is possible to present the same object or data model via CIP as was done via MODBUS. Therefore other permutations are possible in this aspect. Here both a Register object that receives input read commands, or a Read Input Register receives get attribute commands, or a generic Register object receives read or read_register service requests. Similarly, the functions of MODBUS protocol may be mapped to a generic Function Object that has service 1, service 2 and so forth, or a CIP get/set read/write that includes a function code in the respective CIP message data.
As described above, the stacks 800 may be associated with one or more other network layers. A physical layer 820 may be provided that defines the physical characteristics such as electrical properties of the network interface. A data-link layer 830 defines rules for sending information across a physical connection between systems. The stack may include a network layer 840, which may include Internet protocol (IP) and/or Internet Protocol version 6 (IPv6), which defines a protocol for opening and maintaining a path on the network. A transport layer 850 associated with the stack, may include Transmission Control Protocol (TCP) that provides a higher level of control for moving information between systems. This may include more sophisticated error handling, prioritization, and security features. A session layer 860, presentation layer 870, and application layer 880 may also be included that sit above the other layers in the stack.
Another type of processing at 930 can include distributing network layer functionality across one or more control module boundaries. For example, application layer objects that are suitable for a PLC can be implemented in the PLC or other network control module. A Network Services Layer can provide network layer communication primitives to the application objects as if a network protocol stack was implemented on the PLC or other communications module. As such, whether the stack is on the PLC or on an associated Network Interface Module, the stack is substantially transparent to the application layer which allows for sharing resources across modules. Another type of processing includes protocol conversion that maps protocol differences between network standards in a substantially transparent manner. This enables communications in one protocol to be mapped to a subsequent network or industrial protocol while mitigating design changes to existing industrial protocols.
In another conversion aspect at 930, multi-level communications processing can be provided for a given module, where multiple communications protocol stacks can be provided to enable modules to communicate to these various protocols such that a single module can provide network connectivity for multiple network protocols. After suitable protocol processing has occurred at 930, data from the processed protocols can be employed in a plurality of control applications at 940. For instance, control signals may be encapsulated or encoded in one protocol and subsequently decoded and employed over a different network protocol to control operations over a plurality of different network types and/or network components.
What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
