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