Towards Location Management for future Industrial Networks
Markus Rentschler Philip Henzler Balluff GmbH Hochschule der Medien Stuttgart Schurwaldstraße 9 Nobelstraße 10 73765 Neuhausen a.d.F., Germany 70569 Stuttgart, Germany [email protected] [email protected]
Abstract the precise geographic location of a thing will be critical for clear identification and addressing of devices [8]. In the context of the 4 th industrial revolution, the knowledge and management of the precise topological In traditional plant operation procedures, Location and geographical location of industrial equipment is a Management is very often achieved manually by growing necessity. However, a holistic concept for maintaining information databases or simply lists of the topology and location management in process- and equipment items and their location information in some factory automation networks down to the field level is yet coordinate system that is defined for the given local unknown. In this work, existing network and location installation. These approaches however are not able to management mechanisms are surveyed for suitability in provide automation support for location management industrial automation networks. Special attention is given tasks, which would be very helpful to increase efficiency to the inclusion of the non-TCP/IP protocol IO-Link to in plant operation and close the “engineering tool gaps” integrate sensors and actuators on the field level into a between the plant planning and its lifecycle phases. holistic network management concept. Since the proposed AutomationML [9] is a typical approach dealing with this solution is based on established standards, it can be easy challenge. integrated it into existing implementations. A proper location management support must therefore be designed in a unified or standardized manner, 1. Introduction consisting of both a technical methodology and a management process to provide the ability to precisely In process- and factory automation, the ability to identify and locate connected devices within an industrial precisely locate and manage installed equipment on all automation plant. levels of the automation pyramid (see figure 1) is mandatory for the plant operator, especially for the following use cases:
• Safety / Emergency [1] • Authentication policies based on Location [2] • Troubleshooting Tasks [3] • Regular Maintenance Tasks • Asset Management
Additionally, initiatives like SOCRADES [4], IMC- AESOP [5], Industry 4.0 [6] or Internet of Things (IoT) [7] promote cross-layer service oriented architectures Figure 1: Geographic deployment within industrial plants (SOA) for cyber physical systems (CPS). These concepts are considered to play a major role in the next, the 4 th , In the telecommunications world, location-based industrial revolution and have in common that networked services such as emergency services, IP telephony and virtual resources might be shared and geographically others are already well established [10]. Numerous deployed, both which is usually unknown to the end applications used in the Internet today benefit from application that uses these resources. But still when sharing location information. These location based location is not important for running the application, it services (LBS) [11] include mapping/navigation may become very important in the case of maintenance applications, 'friend finders' on cell phones and especially and troubleshooting, when physical access is required. IP-Geolocation [12]. All these applications have the Therefore in an Internet of Things, the information about common need for knowledge about geographic location information of its target, which can be a device, human, define any protocols or data formats on the resource or any other entity. This problem is usually implementation level. solved by a suitable network protocol support to gather, transfer and store the required location information. The known mechanisms usually rely on TCP/IP capabilities of the networked devices. Since in industrial networks the devices on the field level, such as sensors and actuators, are often not TCP/IP capable, suitable means have to be defined to include them into a holistic industrial network and location management. Figure 2: GEOPRIV basic architecture [RFC 3693]
Thus, this work has in fact to deal with three closely The GEOPRIVs logical system architecture is depicted in interrelated problems. First is the requirement for Fig. 2. GEOPRIV also introduced the following geographic location management. This is addressed by a terminology, which will be adapted in this work: survey on known mechanisms and their ability for Target : The entity whose location is desired by the industrial network management with a focus on location Location Recipient. In many cases the Target will be the management. Second, this is put into the context of the human "user" of a Device or an object such as a vehicle or suitability for future decentralized organized CPS. Third, shipping container to which the Device is attached. In the integration of non-TCP/IP devices on the field level many instances the Target will be the Device itself. into TCP/IP-based network management must be solved. Device : The technical device whereby the location is tracked as a proxy for the location of a Target. The paper is structured as follows: In chapter 2 an Location Generator (LG) : The entity that initially overview on already existing location management determines or gathers the location of the Target and approaches in the telecommunications world is given. creates Location Objects describing that location. LGs Chapter 3 outlines location management requirements for publish Location Objects to Location Servers. The industrial plants and networks in the context of CPS. In manner in which the Location Generator learns of chapter 4, proposals for industrial network and location Location Information is outside the scope of GEOPRIV. management approaches down to the non-TCP/IP field Location Objects (LO) : An LO is an object level are derived. Chapter 5 summarizes and gives an conveying location information and possibly privacy outlook to future work. rules. Location Server (LS) : The LS is an element that 2. Related Work receives publications of Location Objects from Location Generators and may receive subscriptions from Location 2.1. Top-Level Concepts Recipients. Various organizations have worked on solutions to Location Recipient (LR) : The LR is an element that solve localization management requirements for different receives notifications of Location Objects from Location application fields. Starting with RFC 3693 in February Servers. The LR may render these LOs to a user or 2004[13], the IETF working group GEOPRIV automaton in some fashion. (“ GEO graphic Location/ PRIV acy”) is producing Using Protocol: A specific network protocol that documents which address this subject. The urgent need of carries location objects. a geographical localization concept was stated in RFC 3693 as follows: 2.2. Realization Concepts “Location-based services, navigation applications, The following location oriented concepts and protocols emergency services, management of equipment in the were defined in subsequent RFCs by the IETF’s field, and other location-dependent services need GEOPRIV working group: geographic location information about a target (such as a • URI (Uniform Resource Identifier) was published in user, resource or other entity). There is a need to securely January 2005 in RFC 3986 [14] to specify a data gather and transfer location information for location format for identification of an abstract or physical services.”[13]. resource. Based on this, RFC 5870 [15] defines: “A RFC3693 also identified the basic requirements that 'geo' URI identifies a physical location in a two- or there must be no delay in network traffic due to additional three-dimensional coordinate reference system in a GEOPRIV packets and that the system has to be compact, simple, human-readable, and protocol- operational inside of buildings. independent way. The default coordinate reference GEOPRIV describes in RFC3693 a top-level concept system used is the World Geodetic System 1984 of what is required for a secure transfer of geographical (WGS-84).” localisation data within a network. It does however not • LIS (Location Information Server) "uses knowledge of the access network and its physical topology to generate and serve location information to Devices". configuration, status or detailed diagnostics). This This RFC describes the process of a target to information is for each IO-Link device described discover the right LIS using DHCP and DNS (via in an attached IO device description file (IODD), HTTP/HTTPS). This concept was published in which can be easily read and processed by the user September 2010 in RFC 5986 [16]. and application tools. An asynchronous Event • HELD (“HTTP Enabled Location Delivery”) is an facility allows alarms or informational messages to extension on Hypertext Transfer Protocol (HTTP) be delivered to the user as they occur without that retrieves information from a server by value or querying. IO-Link was developed by the IO-Link reference and was published in September 2010 in consortium under the head of the PNO and has RFC 5985 [17]. first been published in 2006 [20]. In 2010 it was integrated into the PLC standard IEC 61131-9 as The following concepts and protocols for topology and “Single-drop digital communication interface for location discovery were defined by other standardization small sensors and actuators” (SDCI) [21]. bodies: • LLDP is a protocol that gathers information about Elements of all the concepts described above have the its direct neighbour stations in a network. The potential for adoption in an industrial network and decentralized collected information can then be location management approach, mainly for the reasons retrieved by a central management station for that they fulfill most of the requirements, are standardized topological display. This standard was first and already widely deployed in the field. The otherwise released as IEEE 802.1AB in May 2005 [18]. promising concept of OPC-UA [22], which was • LLDP-MED is an extension on LLDP and was specifically designed for “Industry 4.0” and would be a specifically developed to better support IP good replacement for SNMP, unfortunately does not yet telephony and emergency services such as E9-1-1 sufficiently address the discussed requirements. [5]. LLDP-MED defines a transport mechanism for LOs between two directly attached nodes and a 2.3. Location Identifier Concepts SNMP MIB for configuration and retrieval of this The basic approaches to define a Location Identifier decentralized held location and other device format are as follows: information. It was published by ITU-T TR41.4 in Location-by-Value (LbyV) is represented by an direct April 2006 [19]. coordinate within a given absolute coordination system, • IO-Link is an increasingly deployed non-TCP/IP such as the civic address system, UTM, WGS84 and serial communication protocol designed to others. communicate with both analogue and digital Location-by-Reference (LbyR) is represented by a sensors and actuators on the field level. It supports indirect coordinate that is related to a direct coordinate, in star and tree topology cabling structures based on an absolute coordinate system. the long established unshielded 3-wire sensor and actuator cable and connector material. The following examples highlight the difference: Transmission rates of 4.8 kBit/s (COM1), 38.4 kBit/s (COM2) and 230.4 kBit/s (COM3) are LbyV : A civic Address in Germany is: “Balluff possible. The standard 2 bytes of process data per GmbH, Schurwaldstrasse 9, 73765 Neuhausen a.d.F., cycle result in a transmission time of 400 µs Germany”, whereas “Balluff GmbH“ is institution, between IO-Link master and device in COM3 “Schurwaldstrasse 9” is street location/ground parcel, mode. For larger frame types with up to 32 bytes “73765” is postal code, “Neuhausen a.d.F.” is town and length, the cycle times become correspondingly “Germany” is country. lower. It must be noted that IO-Link is not a LbyR: “Meeting room 20 is on the second floor in fieldbus, but a serial point-to-point communication Building 5 at Schurwaldstrasse 9, 73765 Neuhausen protocol. Besides the capability for transport of a.d.F.”. Here a specific room in a building is targeted, cyclic process data, IO-Link consists of protocol where both have no explicit civic address. We use a point mechanisms that are very similar to SNMP: of reference and then describe the way to the target Indexed Service Data Units (ISDUs) allow the user position. in a request-response-fashion to retrieve detailed information about the device or set parameter values on the IO-Link device for configuration purposes. Some data elements are standardized within the protocol (e.g. versions, type, serial numbers, location tag) and open extensibility allows device manufacturers to define any necessary additional data elements (e.g. Figure 3: “Location Configuration Identifier” (LCI) [RFC 6225] Besides the civic address data format [23] and ELIN • Saving the geographical position data paired with the (Emergency Location Identification Number) according device ID on a central LIS. to TIA-TSB-146[24], a range of Location Coordination • Saving the data on the peripheral device itself. Identifier (LCI) formats have been defined, such as the Both scenarios have their specifics and are URI according to RFC 2141, where DHCPv4 LCI advantageous to be used in combination (Fig. 4). This according to RFC 6225 [25] is coordinate based (Fig. 3). way allows seamless migration from traditional hierarchical automation to decentralized CPS 3. Industrial Location Management architectures. In any case must the stored location information be retrievable by central network The need for industrial network operation to know management systems through suitable transport about the physical location of the devices in the network mechanisms. is obvious. Network management and asset management with accurate documentation is a premise for professional administration of such networks. This applies both to permanently mounted wired devices and -as mobility grows- especially for wired and wireless mobile devices that operate in the observed network. From this, the following basic requirements evolve: 1) Methods to determine the physical location of an industrial device. 2) Definition of data formats for the location information (2D / 3D / human readable / processable). 3) Store this physical location. 4) Deploy the physical locations in the network. 5) Present the information to the network administrator or operator. These requirements will be discussed in the following subchapters.
3.1. Location Determination Several techniques exist or are currently researched to determine the geographical position of an object: Human Navigation approaches can determine a position manually using i.e. using a sextant or a map to find out the location data and then enter them manually into the target. The Global Positioning System (GPS) is based on satellites. The signal is highly affected by obstructions and works best with “clear view of the sky in all directions” [26]. Thus it is not suitable to be used inside of buildings. Wireless Triangulation uses at least three exact known neighbor positions to determine a targets’s position. Distances are calculated based on received signal strength [27]. These kind of technology might be a suitable approach for mobile wireless devices in an industrial network. Location determination techniques however are not in the scope of this work, but have to be supported by an industrial network and location management solution by providing a defined interface for transfer of the location information.
3.2. Location Information Storage Figure 4: Hybrid LIS concept for CPS Two strategies to store the location information of an individual device can be utilized: 3.3. Location Information Display For industrial location management, both directions of For visualization geographical locations in an exchange of location information must be feasible and in industrial context, the following strategies can be utilized: case of conflicting information there must be a For two-dimensional (2D) geographic location, tools like mechanism in place to decide which one to use. Google Maps ® might be feasible, whereas some 3D-CAD For better usability, location information storage in the or Virtual-Reality-Software is required for navigating LLDP-MED-MIB should be capable of holding both inside of plants, buildings or even installation cabinets. LbyV and LbyR value simultaneously. This requires some Both scenarios have their specifics and are most likely standardization work on the location data format to be to be used in combination. A usability concept needs to be used, which is not in the scope of this work. designed on how to switch between the two views (Fig 5). It is desirable to have an instance in the LLDP-MIBs local port table that reflects the properties of the local agent, often called the “CPU interface”. We propose to enhance the LLDP-MIB with a variable called “lldpLocInterfaceNumber”, which contains the index to identify the local interface entry.
4.2. IO-Link Fieldbus Gateways For devices in the field level, IO-Link [20][21] is of specific interest because it incorporates SNMP-like mechanisms for non-TCP/IP-devices and already defines an information item called “tag location” as a container for location data. For the operation of IO-Link devices Figure 5: Visualization example of an automation network with PLCs via a fieldbus, gateways between the two worlds are utilized to transfer the process data. Modern 4. Proposed Solution fieldbuses are mostly based on the Ethernet technology (Fig. 6). The Link Layer Discovery Protocol (LLDP, IEEE- 802.1AB) was designed for topology discovery and its enhancement to LLDP-MED (LLDP Media Endpoint Devices, ANSI/TIA-1057) defines location and other management information for end devices. LLDP sends its device information to direct neighbours like switches, which store them in their MIB-tables. A central network management system (NMS) is able to retrieve this information via SNMP and put the data from various MIB’s together to compute the physical network topology. If additionally the location information via LLDP-MED is available, the physical network topology representation can be enhanced. A geographical map can be overlayed and displayed in a virtual-reality manner or the information can be used to generate a representation of relative positions and distances. The available location information formats provided likely fit most use cases. For these reasons and because of its already wide deployment in industrial network devices, LLDP and LLDP-MED form a suitable basis for a holistic industrial location management approach.
4.1. LLDP-MED Enhancement The following shortcomings of LLDP-MED need to be addressed: • No specific support for location management of infrastructure devices is currently specified. Figure 6: Ethernet/IO-Link Sensor Topology • Exchange of location information only from infrastructure device to end devices, not into the From the network management viewpoint, IO-Link other direction. devices can be operated from a TCP/IP-based system by the implementation of proxy agents (Fig. 7) in the gateway devices that have interfaces to both worlds. Two possible solutions to make non-TCP/IP devices The local tables in lldp, lldpXMED and the new visible and even accessible for SNMP-based network lldpXIOL MIB contain configuration information per IO- management will be discussed in the following Link master port. The gateways’ role resembles to a subchapters. LLDP infrastructure device as it provides information on connected IO-Link devices to the network. The entries 4.3. LLDP Proxy Agent for the IO-Link ports should reflect the type IO-Link and On the TCP/IP-Gateways, IO-Link devices can be its properties as good as possible. However, no LLDP included via “artificially” created corresponding entries in frames are sent or received on these IO-Link interfaces, the LLDP-MIB local and remote tables. only on the Ethernet interfaces of the gateway device. The tables of the lldpXIOL Extension MIB must cover the IO-link device specific parameters that an IO-Link device supports and which cannot be mapped to existing lldp or lldpXMED objects.
TABLE II. IO-LINK DEVICE TO MIB-OBJECT MAPPING
Length IO-Link Parameter MIB-Object [octets] RevisionID 2 lldpXIOLRemRevisionID VendorID 3 lldpXIOLRemVendorID ProcessDataIn 3 - 32 lldpXIOLRemProcessDataIn ProcessDataOut 3 - 32 lldpXIOLRemProcessDataOut DeviceID 2 lldpXIOLRemDeviceID FunctionID 2 lldpXIOLRemFunctionID Vendor Text max. 64 lldpXMedRemMfgName lldpRemSysName, Product Name max. 64 lldpXMedRemModelName Product ID max. 64 lldpXMedRemAssetID Product Text max. 64 lldpRemSysDesc Serial Number max. 16 lldpXMedRemSerialNum Figure 7: Basic Concept of LLDP/IO-Link Gateway Hardware Revision max. 64 lldpXMedRemHardwareRev Firmware Revision max. 64 lldpXMedRemFirmwareRev To achieve this, a systematic mapping from IO-Link to Application Specific lldpXMedRemLocationSubtype / 16 - 32 SNMP and LLDP has to be defined. The mapping of IO- (tag location) lldpXMedRemLocationInfo Link parameters to SNMP-MIB-Objects is quite easy, Error Count 2 lldpXIOLRemErrorCount because the general concepts of describing, accessing and Device Status 1 lldpXIOLRemDeviceStatus Detailed Device storing data are very similar in the two protocols. Both lldpXIOLRemDetailedDeviceStatus Status max. 64 SNMP and IO-Link manage structured data. In SNMP Offset Time 2 lldpXIOLRemOffsetTime this structure is defined with SMI, a subset of ASN.1. In Profile Parameter max. 64 lldpXIOLRemProfileParameter IO-Link this is done with XML based documents and corresponding XML schema definitions, called IODD. As As of table I, the length of the tag-location parameter equivalent to SNMP SET and GET, IO-Link implements matches the length of the coordinate based LCI data Read and Write on-request objects. format (16 octets) and ELIN (30 octets). The civic address In table I and II, the IO-Link parameters are taken from LCI format with up to 255 octets can not be used here. Table B.7 in [28] and mapped to existing LLDP-MIB But as the civic address is not intended to be machine definitions whenever possible. In cases where no suitable processed, this won’t dramatically limit the use cases. mapping can be found, a MIB object in a new IO-Link-
MIB should be defined, which could be realized as an IO- Since IO-Link is a point-to-point protocol, only a Link-device specific LLDP-Extension MIB (lldpXIOL). single IO-Link device instance for each master port must TABLE I. IO-LINK MASTER TO MIB-OBJECT MAPPING be supported and every connected IO-Link device can be accessed directly from the master. But since so called IO- Length IO-Link Parameter MIB-Object Link Hubs may provide interfaces to a number of simple [octets] binary sensor and actuators, these should also be i.e. “IOL 1” max. 255 lldpLocPortId represented in the remote tables via a single entry for each i.e. “IO-Link Port 1” max. 255 lldpLocPortDesc binary endpoint to reflect the true topology. RevisionID 2 lldpXIOLLocRevisionID
VendorID 3 lldpXIOLLocVendorID DeviceID 2 lldpXIOLLocDeviceID For both lldpXMedPortCapSupported and lldpXMedRemCapSupported, the IO-Link proxy agent Mapping V_ApplicationSpecifictTag should indicate the bits “location” (2) and “inventory” (5).
Figure 10: XSD/ASN.1 Translation
5. Summary
Figure 8: Basic Concepts of SNMP/IO-Link Gateways There is an obvious lack of a unified method to geographically locate, manage and display networked Instead of transferring the raw IO-Link parameter data equipment in industrial installations from management to to the level of NMS and translating them there, the IO- field level that is capable for future “Industry 4.0”-like Link specific MIB could also be implemented within the CPS topologies. SNMP agent on the master device (Fig.8b). The agent Three closely interrelated problem areas were analyzed then maps SNMP-requests to IO-Link requests or internal and the solution proposed is based on the existing functions to access or modify data. As the original IO-link mechanisms SNMP, LLDP-MED and IO-Link, because parameter name is coded into the MIB-Objects name, this they are suitable and well established standards. Many internal mapping might also be done automatically by manufacturers already implement these protocols in a parsing the name for the parameters and using it for wide range of devices. internal access. This depends on the vendors internal The key to smarter manufacturing is deep integration interface implementation. of every available information and making them accessible to both process control and infrastructure management systems. Both may greatly benefit from the [10] Daniele Quercia, Neal Lathia, Francesco Calabrese, Giusy other systems knowledge. Utilizing the network Di Lorenzo, Jon Crowcroft; Recommending Social Events management protocol SNMP in the industrial automation from Mobile Phone Location Data; ICDM 2010 control domain can provide access to valuable [11] Jochen Schiller, Agnes Voisard; Location based services; information with low effort. Elsevier Science 2004 [12] V. N. Padmanabhan and L. Subramanian; An investigation The implementation of Industrial Ethernet Gateways of geographic mapping techniques for Internet hosts; Proc. incorporating LLDP and SNMP proxy agents towards ACM SIGCOMM, August 2001 non-TCP/IP based connectivity protocols like IO-Link [13] RFC 3693: Geopriv Requirements , February 2004 can make this field level world accessible via standard [14] RFC 3986: Uniform Resource Identifier (URI): Generic SNMP-based network management systems. A proposal Syntax ; January 2005 for the mapping of IO-Link parameters to the standard [15] RFC 5870: A Uniform Resource Identifier for Geographic LLDP- and LLDP-MED-MIB parameters has been made. Locations ('geo' URI) ; 2010 Additionally, IODD-based approaches were proposed on [16] LIS; IEC 62264: Enterprise-control system integration how to interface the IO-link protocol to SNMP via a IO- [17] RFC 5985: HTTP-Enabled Location Delivery (HELD) ; Link-Device-MIB, where an IODD-based parameter September 2010. interpretation can be achieved on the application level in [18] IEEE: IEEE 802.1AB-2005 - IEEE Standard for Local either the NMS (Fig. 8a) or the IO-Link master devices and metropolitan area networks Station and Media Access (Fig 8b). Control Connectivity Discovery; 2005 [19] ANSI/TIA-1057: Link Layer Discovery Protocol for The protocols discussed provide data container for Media Endpoint Devices; TR41.4, April 2006 location identifiers, but do not define the location [20] IO-Link-consortium: http://www.io-link.org identifier formats. This definition is still future [21] IEC 61131-9: Programmable controllers – Part 9: Single- standardization work and will play an important role, drop digital communication interface for small sensors since they should be compatible to the displaying and actuators (SDCI) applications that are intended to be used. For two- [22] OPC Foundation, “OPC Unified Architecture dimensional geographic location purposes, tools like Specification: Parts 1–13”, 2014, Available: Google Maps ® might be feasible, whereas some 3D-CAD http://www.opcfoundation.org/ or Virtual-Reality-Software is required for navigating [23] RCF 5139: Revised Civic Location Format for Presence inside of plants, buildings or even installation cabinets. Information Data Format Location Object (PIDF-LO); Adaptability to concepts like AutomationML [9] should February 2008 also be achieved. [24] TIA-TSB-146: IP Telephony Support for Emergency Calling Service; March 2003. [25] RFC 6225: Dynamic Host Configuration Protocol Options References for Coordinate-Based Location Configuration Information , July 2011. [1] NENA TID 07-501; Network Interfaces for E9-1-1 and [26] Dept. of Defense, Washington, D.C.; Global Positioning Emerging Technologies ; September 2002 System Standard Positioning Service Performance [2] Jörg Abendroth, Nicolai Kuntze, and Andreas U. Schmidt; Standard ; 4th Edition, 2008, Trust for Location-based Authorisation; WCNC 2008, Las (http://www.gps.gov/technical/ps/2008-SPS-performance- Vegas, USA. standard.pdf) [3] Markus Rentschler; Faulty Device Replacment for [27] Ali H. Sayed, Nabil R. Yousef; Wireless Location; Wiley Industrial Networks ; INDIN 2012, Beijing, China, 2012 & Sons, NY, 2003 [4] “Service Oriented Architecture For Devices” [28] “IO-Link Interface and System Specification”, Version 1.1 (SOCRADES); Homepage: http://www.socrades.eu November 2010 [5] Next generation of SCADA/DCS systems targeting Process [29] http://www.itu.int/en/ITU-T/asn1/Pages/XML-encoding- Control Applications ; http://www.imc-aesop.eu rules-(XER)-for-ASN-1.aspx [6] Industry 4.0 ; http://www.bmbf.de/en/19955.php [30] Yoon-Jung Oh et.al.; “Interaction Translation Methods for [7] “Internet of Things”; XML/SNMP Gateway”; 13th IFIP/IEEE International https://en.wikipedia.org/wiki/Internet_of_Things Workshop on Distributed Systems: Operations and [8] Open Geospatial Consortium; Management, 2002 OGC Abstract Specification" ; available at http://www.opengeospatial.org/standards/as [9] Rainer Drath; Datenaustausch in der Anlagenplanung mit AutomationML ; Springer 2010