Patent Application
20070076724
The subject invention relates generally to industrial control systems, and more particularly to systems and methods that provide a unified addressing space in an industrial protocol to enable communications across networks with a singular addressing mode.
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. One popular network that is now common in industrial environments is Ethernet. This network is often applied at medium or higher levels of a business network where components such as bridges, routers or other types of modules supply connectivity and communications to lower control networks in the factory. Due to the limited number of Internet Protocol (IP) addresses in the Ethernet IPV4 protocol, most industrial Ethernet interfaces only support a single IP address and use some other means to address interfaces within the industrial system. This usually requires a client system to support multiple addressing modes to select a single device, interface or object which adds complexity and cost to the overall system.
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.
A flat and singular address space is integrated with an industrial control protocol to facilitate communications in an industrial automation environment. In one example of such address space, IPV6 or other singular address space is adapted for industrial control addressing. This enables mapping of individual objects, interfaces and devices to a unique IPV6 address, for example. Using this technique of a single addressing mode, the large IPV6 addressing space (or other global addressing space) can be used to address each object in the industrial system. Thus, in one example, an Ethernet interface card can respond to each object within its scope and contain the routing information to enable a message to reach the object generally using only the IPV6 address.
Each of the respective addresses can be mapped using a Domain Name Service (DNS) server to a user assigned name in order that each object can be addressed by a user assigned name. These names can be arranged into a hierarchy that corresponds to the user's problem or physical domain, for example. In one aspect, the DNS server or other directory service can map hierarchical names to an IPV6 address (or other global addressing scheme) and the industrial Ethernet interface would map the IPV6 address to an individual object in the industrial automation system. Each object could have multiple addresses, one to indicate its physical location and another to indicate its function in the logical description of the user's problem.
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 communicating with control objects according to a singular and unified address space. In this manner, control objects can be addressed according to a single protocol which mitigates configuration and design complexities of communicating through multiple network devices supporting multiple address spaces. In one aspect, an industrial communications system is provided. The system includes a global address protocol that can be employed to communicate with local or remote networks. An industrial protocol is adapted to interface with the global address protocol, where a network component communicates with one or more control components via the industrial protocol and in accordance with an address supplied by the global address protocol. In one example, the global address protocol can include an IPV6 protocol.
It is noted that as used in this application, terms such as “component,” “protocol,” “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 singular address space 130 can be integrated with an industrial control protocol to facilitate communications in the system 100. In one example of such address space, IPV6 (e.g., Ethernet) is adapted for industrial control addressing. This enables mapping of individual control objects 110, networks 140 and devices 120 to a unique IPV6 address. Using this single addressing mode, the large, flat IPV6 addressing space can be used to address each control object 110 in the industrial system 100. An interface card at 120 can respond to each control object 110 within its scope and contain the routing information to enable a message to reach the object generally using only the global address supplied by the space 130. It is to be appreciated, that substantially any higher level global network protocol that allows addresses to be migrated and resolve lower level control objects is considered within the scope provided herein.
Generally, each of the respective addresses 130 can be mapped using the discovery component 150 (e.g., a Domain Name Service (DNS) server) to a user assigned name in order that each object 110 can be addressed by a user assigned name. These names can be arranged into a hierarchy that corresponds to the user's problem or physical domain, for example. In one aspect, the DNS server or discovery component 150 can map hierarchical names to an address 130 and the industrial interface 120 can map the address to an individual object 110 in the industrial automation system 100. It is noted that each control object 110 can have multiple addresses, one to indicate its physical location and another to indicate its function in a logical description of the user's factory or environment.
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, and so forth which are capable of interacting across the networks 140. Similarly, the term PLC or controller as used herein can include functionality that can be shared across multiple components, systems, and/or networks. For example, one or more PLCs at 120 can communicate and cooperate with various network devices across the networks 140. 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 or controller/communication module 120 can also communicate to and control various other devices or control objects 110 such as Input/Output modules including Analog, Digital, Programmed/Intelligent I/O modules, other programmable controllers, communications modules, software components, and the like. 100221 The networks in the system 100 can include public networks such as the Internet, Intranets, and automation networks such as Common Industrial Protocol (CIP) networks including DeviceNet and ControlNet. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, 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
As noted above, IPV6 protocol or other singular addressing mode can be employed as the protocol for the global address space 210. Lower level devices at the control layers 230 can be located and communicated with by assigning such devices addresses from the global address space. In one specific example, a control message may be generated using IPV6 protocol where the message originates from Europe. The message is designated and addressed to a controller operating on a control layer 230 in the U.S. The controller may be operating on a Common Industrial Protocol (CIP) Network or a device network, yet be assigned an absolute address from the global address space 210. Thus, the remote message originating from Europe sends a control message to the device on the factory network as if the device were operating in the global address space. As can be appreciated, a plurality of communications and messages can be provided from local and/or remote networking sources. To continue the example, a discovery component (not shown) such as a DNS can be employed to provide logical naming conventions for control layer devices or components 230 to be determined from the global address space.
Turning to
It is noted that IPv6 addresses can be assigned to specific objects within a CIP protocol, for example. The IPv6 addresses can be assigned to particular control functions beyond CIP protocols and can be assigned to any type of entity or construct in the control system, e.g., tags (named data), routines, entities that are associated with a plant or enterprise model, and so forth. When assigning IPv6 addresses to objects within devices, there are different models that can be employed. These can include where a device has a single instance of a CIP (or other) protocol stack, with a single application addressing space. Multiple IPv6 addresses could be managed at a level above the industrial protocol stack, and the protocol stack would not need to have knowledge of that detail. There could also be an overall directory mechanism that would allow the discovery of which IPv6 address corresponds to which entity. When the IP address was obtained, normal protocol mechanisms can be employed to access the entity.
In another example, each IP address can refer to a “device within a device” (from the CIP perspective, for example). Also, each IP address could refer to a separate CIP device model and CIP addressing space within a single physical device. The CIP (or other protocol) addressing model can be modified to natively support using IP addresses and DNS names to refer to specific objects, if desired. In yet another addressing example, at 340 for other industrial networks, devices connected to the “other” network 340 can be native IPv6 devices, with an IPv6 stack. This can include having a router between an Ethernet network, for example, and the “other” network 340. Another approach is to make the “other” network 340 appear as though it is an IPv6 network to IPv6 devices. This can include having a gateway or translation function between the IPv6 and other devices. Thus, IPv6 router devices can be employed between the Ethernet and “other” networks and/or also a gateway device can be employed that can seamlessly connect an IPv6 network with a non-IPv6 industrial network (making it appear as IPv6).
Referring to
Referring now to
The controller services 510 through 530 can also employ an open interface standard such as a Web Service Description Language (WSDL) illustrated at 560 through 568 in order to provide interactions with the controller services. In general, a WSDL file or interface is an XML document that describes a set of SOAP messages and how the messages are exchanged. In other words, WSDL 560-564 is to SOAP what Interface Description Language (IDL) is to CORBA or COM. Since WSDL is in XML format, it is readable and editable but in most cases, it is generated and consumed by software. WSDL specifies what a request message contains and how the response message will be formatted in unambiguous notation. As an example, an I/O service can specify how inputs are to be requested from the service and how outputs can be sent to the service in the form of a response. In another aspect, inputs can be requested from an input service, wherein the response is a confirmation that the inputs were received. Outputs can be sent to an output service in the form of a request, wherein the response from the service is that the outputs were received. As can be appreciated, the controller services can be executed at various network layers in a control system where such layers are addressable via the global and singular addressing schemes describe above.
The system 500 can also include a discovery component 570, wherein the controller services 510-530 can be published and determined. In one aspect, a Universal Discovery Description and Integration (UDDI) can be provided at 570 that serves as a type of logical “phone” directory (e.g., “yellow pages,” “white pages,” “green pages”) describing Web services. A UDDI directory entry is an XML file that describes a controller system and the services it offers. There are generally three parts to an entry in the UDDI directory. The “white pages” describe the component offering the service: name, address, and so forth. The “yellow pages” include industrial categories based on standard taxonomies such as the North American Industry Classification System and Standard Industrial Classifications. The “green pages” describe the interface to the service in enough detail for users to write an application to employ the Web service. The manner services are defined is through a UDDI document called a Type Model or tModel. In many cases, the tModel contains a WSDL file that describes a SOAP interface to an XML Web service, but the tModel is generally flexible enough to describe almost any kind of service. The UDDI directory also includes several options to search for the services to build remote applications. For example, searches can be performed for providers of a service in a specified geographic location or for an entity of a specified type. The UDDI directory can then supply information, contacts, links, and technical data to enable determinations of which services to employ in a control process. The discovery component 570 can be employed with a global addressing scheme such as Ethernet IPV6 for example to locate lower level control elements such as the controller service 510-530.
At 610, one or more controller service types and protocols are defined in accordance with open standards. As noted above, this can include Ethernet IPV6 protocols that communicate across industrial networks. Other protocols can include XML based protocols for interacting with the service. The service types can be defined as a processing service, a logic service, an input and/or an output service, and a controller information service, for example. As can be appreciated a plurality of control and communications objects can be defined. At 614, interfaces are defined in accordance with global or singular address space. For example, this can include interfaces that describe how control requests and responses are processed by the control objects and how addresses are transported across networks.
It is noted that other publicly available standards/protocols/services may be employed. For example an enterprise service may be defined that coordinates different portions of a business or control process (e.g., batch, quality, ERP) throughout various portions of an organization. To facilitate consistent batch quality, for example, a service can be defined and offered which follows an international standard for modular batch automation, such as defined by standard (S88, S95), which also defines models and terminology for identifying equipment capability and procedures for producing batches. These procedures and capabilities can be defined and offered by an associated service. These standards specify the information flow between enterprise and manufacturing control. Thus, remote services can be offered that are modeled on these international standards and operate to coordinate control processes from the plant floor throughout the businesses that employ the control processes.
Proceeding to 622, service data is defined that describes data consumed by and produced by a respective service object. In general, XML can be employed to define the data but other type data including industrial control data can also be exchanged with the service. At 624, access modes can be defined for a service. This can include defining whether a service or object is polled for data results, the service broadcasts data after processing has been achieved, and/or the service is configured in a request and reply mode to exchange data in response to a specific request to the service.
At 628, controller services or objects are located. As noted above, this can include polling a UDDI directory to determine the service and respective interfaces. At 632, after a controller object has been located across global address space, data is exchanged with the service to affect operations of a control process (e.g., automatically exchanging I/O data with I/O service to automatically perform remote processing service). At 636, results are retrieved from a respective service or control object in accordance with the access modes defined at 624. For example, a processing service may poll a status service at periodic intervals to retrieve plant floor status information that is aggregated from a plurality of network devices. At 640, one or more control actions may be performed based upon the results retrieved from 636. For example, an I/O service may energize an output device based upon a processing result received from a processing service.
In general, IPV6 is a new version of the Internet Protocol, designed as the successor to IP version 4 (IPv4) [RFC-791]. IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by adding a “scope” field to multicast addresses. And a new type of address called an “anycast address” is defined, used to send a packet to any one of a group of nodes. Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header. Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. A new capability is added to enable the labeling of packets belonging to particular traffic “flows” for which the sender requests special handling, such as non-default quality of service or “real-time” service. Other extensions are provided to support authentication, data integrity, and (optional) data confidentiality.
A frame format for the packets 700 includes IPv6 packets that are transmitted in standard Ethernet frames. The Ethernet header contains the Destination and Source Ethernet addresses and the Ethernet type code, which contains the value 86DD hexadecimal. The data field contains the IPv6 header followed by the payload, and possibly padding octets to meet the minimum frame size for the Ethernet link. An interface identifier [AARCH] for an Ethernet interface is based on an EUI-64 identifier [EUI64] derived from the interface's built-in 48-bit IEEE 802 address. The EUI-64 can be formed as follows.
The EUI of the Ethernet address (the first three octets) becomes the company_id of the EUI-64 (the first three octets). The fourth and fifth octets of the EUI are set to the fixed value FFFE hexadecimal. The last three octets of the Ethernet address become the last three octets of the EUI-64. The Interface Identifier is then formed from the EUI-64 by complementing the “Universal/Local” (U/L) bit, which is the next-to-lowest order bit of the first octet of the EUI-64. Complementing this bit will generally change a 0 value to a 1, since an interface's built-in address is expected to be from a universally administered address space and have a globally unique value.
A universally administered IEEE 802 address or an EUI-64 is signified by a 0 in a U/L bit position, while a globally unique IPv6 Interface Identifier is signified by a 1 in the corresponding position. For example, the Interface Identifier for an Ethernet interface whose built-in address is, in hexadecimal, is 34-56-78-9A-BC-DE would be 36-56-78-FF-FE-9A-BC-DE. A different MAC address set manually or by software should not be used to derive the Interface Identifier. If such a MAC address is used, its global uniqueness property should be reflected in the value of the U/L bit. An IPv6 address prefix used for stateless network auto-configuration [ACONF] of an Ethernet interface has a length of 64 bits.
With respect to multicast address mapping 830, an IPv6 packet with a multicast destination address DST, consisting of the sixteen octets DST[1] through DST[16], is transmitted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST. In general, there may be some differences with older version of Ethernet. The following are possible functional differences between older versions such as an Address Token, which was a node's 48-bit MAC address, is replaced with the Interface Identifier, which is 64 bits in length and based on the EUI-64 format [EUI64]. An IEEE-defined mapping exists from 48-bit MAC addresses to EUI-64 form. A prefix used for stateless auto-configuration is 64 bits long rather than 80. The link-local prefix is shortened to 64 bits.
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.
