Page 17

Industrial Ethernet Book 103

17 Protocols and Payloads: Cloud-based application developers expect message payloads that are easily programmatically digestible, potentially extensible for business process purposes and normalized to contain meaning for a given application domain, such as Asset Management analytics. Abstracting CIP details satisfies these expectations while exposing CIP protocol or payload formats would cause lost productivity for developers, potentially large, incremental, profit impacting unmarshalling/marshalling costs. Applications: Cloud-based applications have very broad scope and virtually no limitation to the types of functions that can be performed. Cloud-based applications can be modified and updated very rapidly (in minutes, hours) and often integrate multiple streams of information simultaneously to produce results. Communications between entities on the cloud are generally based on widely used open standards which are not industry specific and which may be replaced at any time. CIP communications, while standardized, are industry specific and slow to change. Developer Pool: Cloud developers master a variety of programming languages, ‘cloud oriented development’ and cloud architectures that are very different from those needed by CIP network application developers. Abstracting CIP details with a normalized Device Asset domain model, for example, greatly increases the pool of potential developers for CICI-based Cloud applications. In order to not compromise security of on-premise resources, CICI Gateways and CIP Devices are not exposed the internet by publicly available interfaces such as publish/subscribe broker or http web service endpoints. Device-to-Cloud and Cloud-to- Device communications are through an established CICI Gateway. For example, to support Cloud-to-Device communications, Cloud applications send messages to devices indirectly through Cloud-based egress queues to which the CICI Gateway subscribes. All communication must be performant and scalable across a variety of networks. This means that CIP must “stay home” or stay on premise where responses are timely and consistent. Any solution identified should avoid a specific implementation, but instead be described in general terms. On one hand, this document avoids recommending implementation technologies. Instead, the focus is on D2C and C2D information exchange patterns common in the solution marketplace and relevant to the design of CICI and CICI-based solutions. On the other hand, some technologies (AMQP, MQTT, JSON, etc.) are included in typical CICI architectures to illustrate how contemporary IIoT/Cloud integration are achieved and relate to information exchange patterns important to CICI. Information exchange patterns Four Information Exchange Patterns generalize the logical patterns of communication that will occur between the cloud and gateways or devices. Telemetry Telemetry is one-way, with information flowing that a device or gateway “volunteers” to a collecting service, either on a schedule or based on particular circumstances. This information represents the current or temporally aggregated state of the device or the state of its environment, like readings from sensors that are associated with it. Telemetry is initiated by the CIP Devices based on a previous configuration or runtime subscription request. Data flows from the CIP Device to the CiCi Gateway and sent to the Cloud to be available for Cloud applications. Note that security had been omitted for simplicity, but the connection to the cloud would be set up before data would begin to flow following a Telemetry Information Exchange pattern. The exchange pattern is one way, so that the CIP Device does not expect a response from the Cloud application. Inquiry With inquiries, the device or gateway solicits information about the state of the world beyond its own reach and based on its current needs. An inquiry is a singular request, but might also ask a service to supply ongoing updates about a particular information scope. A vehicle might supply a set of geo-coordinates for a route and ask for continuous traffic alert updates about particular route until it arrives at the destination. Inquiry is initiated by the CIP Device and flows through the CICI Gateway to the Cloud application via its messaging endpoint. The Cloud application receives the Inquiry message and creates a response. The Cloud app then sends the response message to the Egress queue to which the CICI Gateway is subscribed. The CICI Gateway routes the message to the correct Device. The Inquiry exchange pattern differs from Telemetry in that a response or acknowledgement from the Cloud application is expected. Of note is the use of Correlation IDs in the messaging between the CICI Gateway and the Cloud application. Correlation ID is an Enterprise Integration Design Pattern used to relate a response to the correct request in asynchronous, non-guaranteed ordered communication scenarios. Notifications Notifications are one-way, service-initiated messages that inform a device or a group of devices about some environmental state they’ll otherwise not be aware of. Wind parks will be fed weather forecast information and cities may broadcast information about air pollution, suggesting fossil-fueled systems to throttle CO2 output or a vehicle may want to show weather or news alerts or text messages to the driver. Notifications are initiated by the lineof business Cloud applications. Cloud apps send Notification messages to the egress queue to which the CICI Gateway has subscribed. The CICI Gateway then routes the notification messages to the appropriate CIP Device or group of devices. The Notification exchange pattern is the logical inverse of the Telemetry exchange pattern and, therefore, the Cloud application does not expect an acknowledgement or response from the device. Commands Commands are service-initiated instructions sent to the device. Commands can tell a device to provide information about its state, or to change the state of the device. That includes, for instance, sending a command from a smartphone app to unlock the doors of your vehicle, whereby the command first flows to an intermediating service and from there it’s routed to the vehicle’s onboard control system. Command is initiated by the line-of-business Cloud application. Command messages are sent to the Digital Twin or directly to the egress command queue to which the CICI Gateway is subscribed. The CICI Gateway sends a synchronous request to the CIP Device and relays the response to the Cloud endpoint. Command is the logical inverse of Inquiry. Therefore, the Cloud application expects a response from the Device. Once again, the Correlation ID enterprise integration pattern can be leveraged for correct message logical routing and processing of responses. Next steps This article covered new technologies that are being introduced into the industrial automation marketplace. It provides a “first pass” definition of one of the communication patterns and an example of how that communication pattern could be realized. It can be easily observed that the Common Industrial Cloud Interface work is just getting started. There is a lot of ground to be covered to completely define the remaining three communication patterns at a high level. The next steps will be to fill in more details, referencing all the technologies and standards available and keeping in mind the guiding principles enumerated. But the goal is to leverage cloud technologies to provide consumers and producers the most value throughout the entire lifecycle of devices. Stephen C. Briant, Technology Manager for Rockwell Automation and Thomas Whitehill, Remote Services Architect, Schneider Electric. 11.2017 industrial ethernet book Technology


Industrial Ethernet Book 103
To see the actual publication please follow the link above