Internet Area Working Group C. Westphal Internet-Draft K. Makhijani Intended status: Informational Futurewei, USA Expires: 8 January 2023 K. Dev Munster Technological University, Ireland L. Foschini University of Bologna, Italy 7 July 2022 OCN Use Cases for Industry control Networks draft-wmdf-ocn-use-cases-00 Abstract This document present industrial networking use cases for Operations and Control Networks (OCN). It is a companion document to the OCN reference model and the OCN problem statement and requirements document. This document compiles a list of potential use cases where new industrial networking protocols could be beneficial. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 January 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Westphal, et al. Expires 8 January 2023 [Page 1] Internet-Draft OCN Use Cases July 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Background and Framework . . . . . . . . . . . . . . . . . . 4 4. Industrial Use Cases . . . . . . . . . . . . . . . . . . . . 6 4.1. Protocol Convergence . . . . . . . . . . . . . . . . . . 6 4.2. Self-Configuration of Industrial Networks . . . . . . . . 7 4.3. 5G Private Networks . . . . . . . . . . . . . . . . . . . 8 4.4. IIoT . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Large Volume Application . . . . . . . . . . . . . . . . 9 4.6. Remote Control . . . . . . . . . . . . . . . . . . . . . 10 4.7. Determinism . . . . . . . . . . . . . . . . . . . . . . . 10 4.8. Industry 5.0 . . . . . . . . . . . . . . . . . . . . . . 11 4.9. Virtual PLC . . . . . . . . . . . . . . . . . . . . . . . 11 4.10. Simplification of OT/IT Integration . . . . . . . . . . . 12 4.11. Smart Contract . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document present the OCN Industrial Use Cases. OCN stands for Operations and Control Networks. It is believed that current network protocols are not flexible enough to allow deployment in industrial networks. Industrial networks have a specific set of requirements and existing solutions and technologies. It is however expected that the deployment of 5G and of solutions to extend the WAN into distributed and potentially remote or hard to reach locations would dramatically alter the way these networks are deployed, managed and operated. In particular, it is expected that these networks would interconnect a wider range of networks potentially at a global scale; would interface and peer with a wider number of potential networks, including the global Internet; and would coalesce around a unified set of protocols, both to commoditize and reduce the cost of the industrial network infrastructure, and to offer interconnection with a wider set of networks over these unified protocols. Westphal, et al. Expires 8 January 2023 [Page 2] Internet-Draft OCN Use Cases July 2022 In this document, we first give a quick background on OCN and industrial networks, and then present use cases where new industrial network protocols would potentially bring new features and new services. These use cases could potentially be solved with current technology, or are active areas of investigation. However we believe that eventually, some unified set of protocols would be useful that supports these use cases. While we make no proposal for such protocol, we believe it would be of value to the community to seek to design such protocols. 2. Conventions and Definitions We provide some definitions and acronyms that are relevant to this document: Industrial Control Network: Industrial control networks are the interconnection of equipment used to operate, control, or monitor machines in the industry environment. It involves different levels of communications between field bus devices, digital controllers, and software applications. Industry Automation: Mechanisms that enable the machine to machine communication by use of technologies that enable automatic control and operation of industrial devices and processes leading to minimizing human intervention. Control Loop: Control loops are part of process control systems in with desired process response is provided as an input to the controller, which performs the corresponding action (using actuators) and reads the output values. Since no error correction is performed, these are called open control loops. Feedback Control Loop: Feedback control loop is a system in which the output of a control system is continuously measured and compared to the input reference value. The controller uses any deviation from the input value to adjust the output value for the desired response. Since there is a feedback of error signal to the input, these are called closed control loops. Programmable logic controllers (PLC): Industrial computers/servers to control manufacturing processes such as assembly lines. Supervisory Control and Data Acquisition (SCADA): Software System to control industrial processes and collect and manage data. Distributed Control Systems (DCS): Systems of sensors and Westphal, et al. Expires 8 January 2023 [Page 3] Internet-Draft OCN Use Cases July 2022 controllers that are distributed throughout a plant. Fieldbus Devices: A device which is installed on the field (e.g., solar farm, energy grid, autonomous vehicle). Operational Technology field devices include valves, transmitters, switches, actuators, etc. Operations and Control Networks (OCN): A network that supports all the capabilities necessary to accomplish a process or control command execution on actuators for the desired effect prescribed by the controllers based on continuous inputs from the sensory data and application requests. 3. Background and Framework Traditional communication networks facilitate the data communication between multiple devices and peripherals. With the evolution of devices and systems such as Internet of Things (IoT) and cyber- physical system (CPS), the characteristics of a network has undergone great changes. In order to accommodate IoT and CPS, Industrial Communication Networks were introduced that could handle data integrity and real-time control for large installations in harsh environments. The purpose of these networks is to connect sensors (devices that monitor some parameter at a site), actuators (devices that perform an action in the physical world), controllers and other elements that require some specific network services. In Industrial applications, these networks include ControlNet, Modbus, DeviceNet, Ethernet, Profinet and so on. They form a connection among PCs, controllers, and field devices which is difficult to do with traditional communication networks. Industrial Ethernet is used extensively which is part of industrial automation, but with the advent of 5G and mMTC, it is expected that industrial networks would expand to a global reach. This creates new constraints to meet the real-time operational needs. These networks to support increasingly large number of devices with a wide range of standards and policies. Furthermore, the factory system should offer solutions with great reliability, efficiency, and fast or even deterministic response times. The OCN problem statement we consider stems from [OCN-PS]. We consider here industrial systems and networks, and they have a wide range of applications. As a consequence, they operate in a wide range of conditions as well, which poses a challenge to operate and manage these networks. The level of required connectivity will vary between devices within a network, and between the applications of the Westphal, et al. Expires 8 January 2023 [Page 4] Internet-Draft OCN Use Cases July 2022 network within an industry. A manufacturing plant may have remotely controlled robots that perform assembly of a product, which have a much lower latency requirement than, say, a solar farm. For Industry control systems, there are different types of end-points and different types of traffic in between. Some data traffic essentially convey instructions that need to be delivered within a specific time to perform a task at a machine or equipment. Some may have more elastic latency requirements. Some interactions between two end-points may be atomic, while some may require to convey some contect, or to maintain some state either within the network or at one or both of the end-points. The end-points in such systems can be either a controlling entity, sensors or actuators. Sensors and actuators are assumed to not perform decision making tasks. The controller has those responsibilities. The packets delivered from the controller are the actionable instructions to actuating device. They may fit into a single packet, or be part of a data stream. Many IoT application would have smaller packets, and therefore require consideration of packet overhead. Some other applications may require stream, for instance in case of videosurveillance of industrial operations. We briefly recall the main components of the OCN framework (for more details, see [OCN-RM]). An OCN is a network used to connect three basic types of functional devices - actuators, sensors and controllers. They are well-known in the industry control systems (ICS) and are generalized to include all kinds of OCN scenarios. The sensors and the actuators are associated with physical, logical, or digital entities that can be observed, monitored, or caused to move or change. An OCN connects field devices, with the controllers and associates them for the exchange of data to trigger and monitor changes to achieve desired effect. The OCN connects these elements to support the services that enable the deployment of an industrial network, including providing some guarantees for certain type of services, some reliability, or some security. Indeed, an industrial application may have strict latency requirements, for instance to control remotely the operation of some machinery. It may also have some reliability requirement, as any down time may impact the bottom line of the industrial application it supports; and it should be robust to some attempts to disrupt the production from adversary entities. Privacy may be a requirement as well. Westphal, et al. Expires 8 January 2023 [Page 5] Internet-Draft OCN Use Cases July 2022 The OCN framework is not limited to industrial networks. Smart Grid or Self-Driving Cars for instance could be areas of application. Any network that supports sensors, actuators and controllers is a target for deployment of such network. We focus here on the use cases in the industrial/manufacturing sector, as it is expected that most machine-to-machine deployments would occur in the near future. 4. Industrial Use Cases This section lists some of the Use Cases we anticipate for OCN. This list is not exhaustive, and some of the use cases may be supported using current technologies. We believe however that the superset of these use cases would provide basis for establishing a set of requirements for OCNs in the future. This list is open for discussion. 4.1. Protocol Convergence Currently, a hodgepodge of protocols are used in Industrial networks. We mentioned ControlNet, Modbus, DeviceNet, Ethernet, Profinet above. It is detrimental to the industry to have many protocols that cannot easily interoperate and have different support for different services. To reach a critical mass and to decrease the unitary cost of a device through economies of scale, we believe there is a need to unify these protocols into one common protocol. We need a glue to connect these different networks together, similary to the way that the Internet became successful once a common narrow waist was defined and provided. One special case is that of the field bus convergence protocol. Field bus are typically serial devices with limited range. A complex automated industrial system has typically a hierarchical structure, denoted distributed control system (DCS). The top of the hierarchy for production management is connected to a control level of Programmable Logic Controllers (PLCs). This is typically done via Ethernet. The Fieldbus then links the PLCs to the control level of the components, namely sensors, actuators, switches, etc. The fieldbus is therefore time-critical. Fieldbuses are currently deployed over Industrial Ethernet, that is the use of Ethernet in an industrial environment that supports determinism and real-time control. Protocols for Industrial Ethernet include EtherCAT, EtherNet/IP, PROFINET, POWERLINK, SERCOS III, CC-Link IE, Modbus TCP, CANopen, MQQT, etc. Most of these protocols are at layer 2. Translating Westphal, et al. Expires 8 January 2023 [Page 6] Internet-Draft OCN Use Cases July 2022 protocols to interoperate as well as to extend the range beyond the LAN would require new layer 3 protocols to connect the sensors, actuators and controllers in a more universal manner. In the OCN reference model, this use case connects sensor points (SPs), actuation points (APs) and controller points (CPs) using a unified OCN communication interface, to support delivery of OCN message of multiple types (in-time, on-time, bounded latency, periodic, etc.) as required by the underlying protocol that the OCN is emulating and/or replacing. 4.2. Self-Configuration of Industrial Networks Adding new device in a distributed network, where the facilities have a large footprint, needs to be supported in the OCN. Bootstrapping is a significant use case for a network that orchestrate and coordinates between a large number of sensors, actuators and controllers. Further, an OCN is a potentially large collection of devices that may be constrained in some way. This means that the configuration of new field devices needs to be done in a scalable manner yet without burdening the devices with too many omputational steps (say, crypto computations), large exchange of data (say, firmware uploads) or other similar considerations. The deployment of such a network requires that the devices may be added to the network in a simple model, or removed from the network, or updated or modified, in a scalable manner. The OCN protocol need to support some form of authentication for new devices, or to have the ability to filter the data from devices (including field devices) so as to remove unwanted packets or to refuse transmission of data from unknown devices. The data from the devices can be equipped with some authentication tokens or certificates that can be verified in the OCN. Some of this use case may be covered in the IETF IoTOPS, that deals with networked devices with a limited user interface and deployed in large numbers. This could apply to some controllers, actuators and sensors in an OCN. However, the indutrial networks have specific requirements to be considered here. Westphal, et al. Expires 8 January 2023 [Page 7] Internet-Draft OCN Use Cases July 2022 This pertains to the bootstrapping of an OCN, where the number of Actuation Points (APs), Sensor Points (SPs) and controller points (CPs) is potentially large and cannot be configured manually. Some of the message types to be supported include asynchronous messages and periodic message for pushing firmware updates or checking the liveliness of a field device (AP, SP or CP). 4.3. 5G Private Networks One key aspect of 5G is to enable massive machine-to-machine (massive Machine-Type Communication - mMTC) over 5G private network or 5G campus networks. This allows a large number of devices in distributed domains to connect together into a single industrial network. Private network can connect devices that could not be reached beforehand with a combination of wireless connectivity, WAN connectivity, and cloud connectivity. This allows to connecting devices at a much larger scale than current wifi deployments, for instance. In the extreme, the whole industrial network could be connected into one single network domain where all the devices are reachable. Once consequence of a uniform network deployment would be to deploy networks - and devices within that network- using a single standard technology, rather than every industry creating their own idiosyncratic solution. The OCN interface in this use case has a much larger footprint, which requires care to support certain types of OCN messages (in particular in-time or bounded latency messages) due to the potential physical distance between the CP and the APs/SPs. 4.4. IIoT One specific case of industrial OCN is that of connecting IoT devices. The sensors and to some extent, the actuators, may have limited networking capability, due to for instance power constraints (due to battery-powered, or solar power devices). Constrained devices in an industrial OCN require specific considerations. If the bandwidth of the link that connect to the devices is limited, the OCN protocol to exchange data should be designed carefully to minimize the overhead tax of the protocols. Westphal, et al. Expires 8 January 2023 [Page 8] Internet-Draft OCN Use Cases July 2022 Minimizing the protocol overhead may require to use flexible addressing scheme so that devices in a bandwidth constrained environment use shorter addresses than devices with plenty of bandwidth available. Similarly, devices that transmit small amount of data should also be careful to not use very long pacekt headers. Of course, such addressing scheme still needs to provide some reachability throughout the OCN domain, and potentially globally. The protocol overhead in OCN should be such that it operates in an efficient regime. The OCN communication interface should therefore take into account the limits and constraints of the APs and SPs. 4.5. Large Volume Application The opposite side of the coin of the previous use case is that of industrial networks that carry extremely large volume of applications. For instance, some processes may require to extract a lot of information for continuous quality control. This could be composed of some data from sensors, some measurement data, some video stream extracted from a monitoring camera where product defects can be identified using image processing. Other use case that generate large volume application would be the creation of a virtual environment that replicate off-site the conditions of the industrial facility, so that an operator can observe - or even participate within - that environment. Such an AR/ VR use case would require a large amount of data to be transmitted from the industrial facility to the location of the operator. Many pieces of equipment in an industrial environment also require continuous telemetry to monitor the functioning of the industrial facility, and potentially to identify conditions that may lead to failure ahead of time. This also requires the transmition of a continuos stream of data that could encompass many different dimensions, as well as the data processing functions to identify the signature of a potential failure (or whatever other use is applied to this data). OCN therefore may require to transmit large amount of volumetric data. Techniques to support the transmission of large volume of data (in particular, proper transport protocols) are required to support this use case. Westphal, et al. Expires 8 January 2023 [Page 9] Internet-Draft OCN Use Cases July 2022 4.6. Remote Control More and more industrial applications rely on controlling machinery from afar. Among the reasons for this use is to consolidate the control of several facilities into one location; to control facilities that are in hazardous or sterile environment. For instance oil extraction, refineries, mining industries are highly dangerous industries. We envision the deployment of networks for the remote control of the equipment in such environment to ensure safer procedures. Remote control tools and robots can conduct the tasks that are risky for human beings. The OCN network to support this use case would need to meet some stringent availability requirements, as well as some latency (corresponding to the eventual industrial application). Remote control is also a use case for vehicular network and remote driving, described in [OCN-remote-driving]. With respect to the reference model, this entails support of bounded latency, in-time, on-time message types as well as support of reliability requirements on the OCN network itself. 4.7. Determinism Industrial applications often have requirements that cannot be provided by best-effort networks. As a result, some specialized protocols have been designed to provide performance guarantees beyond best-effort (BE). IEEE 802.1 Time-Sensitive Networking (TSN) builds on top of Ethernet to provide reserved shares of bandwidth in a sub-network. However, there is a need to extend beyond Ethernet and still provide these same stringent guarantees across wider interconnected domains. [DetNet-TSN] extend this service to DetNet IP domains. For the case of IIoT, [I-D.irtf-coinrg-use-cases] suggests leveraging in-network computation. The idea is that by bringing computation closer to the end devices, more stringent delay requirements can be achieved. However, this requires re-architecting the network to support computations within the network. OCN requires stringent time constraints in many industrial applications. The operations of an actuator need to be executed with fine grained time accuracy. The OCN may extend beyond a domain of limited scope. THe controller may be in a different site, for practical or for safety reasons, or due to virtualization objectives (see the vPLC use case for instance). Westphal, et al. Expires 8 January 2023 [Page 10] Internet-Draft OCN Use Cases July 2022 In the reference model, this is captured by the in-time, on-time and bounded latency message types to be supported by an OCN. 4.8. Industry 5.0 Industry 5.0 is defined as the next phase of industrial production, after Industry 1.0 (the Industrial revolution of the 1800s with steam power), 2.0 (the adoption of electricy and of division of labor in the early 1900s), 3.0 (the appearance of electronics in production environment in the 1970s), 4.0 (smart manufacturing, in the 2000s). Industry 5.0 supports mass personalization of the production output. In this framework, collaborative robots (cobots) also communicate with humans to enable personalizable autonomous manufacturing. To achieve this, the production requires to be integrated with variations from product to product. These changes need to be shared with the production line so as to integrate them within the product. The production line is the actuator, the controllers store the specificity of each produced item (say, a medical device that is specific to its user) and each specifications need to be shared across the OCN to each of the steps of the production line. This use case requires APs to be dynamically configured and potentially updated between producing consecutive items, and support for bounded-latency message type would reduce the downtime and increase the productivity of the Industry 5.0 production facility. 4.9. Virtual PLC Many current industrial applications run over Programmable Logic Controlers (PLCs). These are the basic building blocks of automation, and control sensors and actuators on factory floors. PLCs are everywhere, and perform trasks such as motion control for robots, or smart manufacturing automoation. There is a wide range of traditional PLCs, depending on size, type and function. Size range from nano (with less than 15 I/O points) to large (with over 512 I/O). As automation grows and becomes more dynamic, factory floors will need more and more PLCs with better performance, more flexibility and more I/Os. For this purpose, it is suggested to virtualize the PLCs and to leverage the benefits (in terms of elasticity and scale) of virtualization for PLCs. Westphal, et al. Expires 8 January 2023 [Page 11] Internet-Draft OCN Use Cases July 2022 [PLC] defines virtualized PLCs as follows: "Virtualized PLC is a hardware-agnostic abstraction of the control unit and memory functions of a PLC. It is hardware- independent and still needs an interface to communicate with the I/O modules." There are related trends to virtualized PLCs, such as the virtualization of HMI, SCADA MES, and other OT equipment, with the purpose of using general purpose hardware in a scalable manner; and to integrate higher lever functions that require more processing power. The benefits of virtual PLCs are many: it allows to leverage more sophisticated compute and storage and virtualization technologies. It integrates multiple PLCs operations on one platform, removing some superfulous movement of data; it allows for tighter application integration; it allows to leverage better edge support; and it frees up some physical space on the factory floor as the control units could be remote. Some instantiation of virtual PLC would require bettern network support. The virtual PLC can be separated from the hardware, using some abstracted interface. The Control Unit can be then placed across an OCN network, provided that it supports this placement away from the actuator. The network needs to preserve the zone security and safety of operations, and to support timeliness of the delivery as required by the application of the PLC (the control unit and its related actuator). For this use case, the network would provide a common interface between the device and the vPLC, as well as a unified converged fabric for all types of end-point. The OCN between the vPLC and the APs/SPs needs to support in-time, on-time, periodic, synchronous message types. 4.10. Simplification of OT/IT Integration Industrial networks have multiple devices in a specific location, where changes are relatively rare. Many of them are wired devices from a network point of view, where direct process control loops are the more important aspect. Security is often achieved by separation, and in particular by separating the OT infrastructure from the IT. The control loops oftern require deterministic network behavior. Westphal, et al. Expires 8 January 2023 [Page 12] Internet-Draft OCN Use Cases July 2022 This creates some challenges, in particular to deal with the heterogeneity of industry protocols. There are more than 100 protocols, where the controller sits behind one protocol and control devices; stateful gateways are often required to translate in between protocols. This also hinders automation: the network is "engineered" to support a set of devices, and makes changes in the scale challenging. One use case of OCN would be to simplify the integration of OT and IT and to allow to run industrial (process control) technologies over IP. There are structural differences in addressing between IP and industrial protocols. IP offers a fixed number of bytes that identify a node. Industrial protocols in different process control zones have different address spaces. They typically don't have a network layer, but are scoped within a LAN. Protocol format conversions are possible and may happen on the fly: devices of one protocol often connect to controller of other protocols. To enable a unified and simplied industrial network, we would need a comon network format that is friendly to both OT and IT applications. This needs to take into account that typical actuator and sensor data is often small, and could require either header compression or a flexible address structure. A network layer would need to be defined, especially as it pertains to extending this use case to support virtualization of the controllers (vPLC, as in the previous use case). 4.11. Smart Contract Devices in an OCN may need to support some operations that are specified by the controller under the form of a smart contract. For instance, some tasks may need to be specified by the controller as a function to be deployed in the field devices under the proper contract terms. The OCN needs to support mechanisms to propagate such smart contract (which may be programs or instruction sets, or just some authenticated information to share between the devices) and to validate them throughout the OCN network. This may relate to the configuration use case as well, since the contract may be to set up the device, for instance by specifying the credentials required for authentication and trust, and by setting up what type of function it will support. Westphal, et al. Expires 8 January 2023 [Page 13] Internet-Draft OCN Use Cases July 2022 Smart contracts may require as well some abstractions to be validated, either within the OCN or at the edge of the OCN, and either in a distributed manner or within a specified control point. 5. Security Considerations OCN may have security implications to discuss in subsequent documents. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [I-D.irtf-coinrg-use-cases] Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., Foy, X. D., Griffin, D., and M. Rio, "Use Cases for In-Network Computing", Work in Progress, Internet-Draft, draft-irtf- coinrg-use-cases-02, 7 March 2022, . 7.2. Informative References [DetNet-TSN] Varga, B., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, 8 June 2021, . [OCN-PS] "Problem Statement and Requirements for the Operation and Control Networks (OCNs)", n.d., . [OCN-remote-driving] Dong, L., Li, R., and J. Hong, "Use Case of Remote Driving and its Network Requirements", Work in Progress, Internet- Draft, draft-dong-remote-driving-usecase-00, 27 June 2022, . [OCN-RM] "Operations and Control Networks - Reference Model and Taxonomy", n.d., . Westphal, et al. Expires 8 January 2023 [Page 14] Internet-Draft OCN Use Cases July 2022 [PLC] Makhijani, K. and L. Dong, "Virtualization of PLC in Industrial Networks - Problem Statement", Work in Progress, Internet-Draft, draft-km-iotops-iiot-frwk-02, 5 March 2022, . Acknowledgments TODO acknowledge. Authors' Addresses Cedric Westphal Futurewei, USA Email: cedric.westphal@futurewei.com Kiran Makhijani Futurewei, USA Email: kiran.ietf@gmail.com Kapal Dev Munster Technological University, Ireland Email: kapal.dev@ieee.org Luca Foschini University of Bologna, Italy Email: Luca.Foschini@unibo.it Westphal, et al. Expires 8 January 2023 [Page 15]