More answers on how to digitalize an OT-data infrastructure

OT data layer insights

• Data integration can help OT applications with digital transformation and integration with cloud applications.
• A unified data layer benefits OT communications with other applications and has implications for cybersecurity design.

Digitalizing the operational-technology infrastructure, the topic of a March 28Control Engineeringwebcast, “成功离你OT-dat。五大要点a infrastructure,” included questions from the audience listening live. Answers to some questions not answered during the webcast follow. The webcast is archived for a year.

Answers include information on normalizing OT data, how to create a unified data layer, digital transformation help and cybersecurity.

Webcast presenter, learning objectives get to OT data layer answers

The expert in the webcast, Darek Kominek, senior consulting manager, Matrikon, providing the extra answers below after covering the following learning objectives in the webcast:

• How Data Technology (DT) bridges the IT/OT gap and helps companies implement a unified OT data layer (UODL)

• A modern (OPC UA and MQTT-based) approach to data connectivity in new and existing systems

• Making data meaningful: why it is mandatory and how to do it

• Keeping enterprise-wide OT data secure

• Ensuring you have an edge-to-cloud connectivity solution

• Maximizing OT-data infrastructure sustainability by making it scalable and extensible.

Darek Kominek, senior consulting manager, Matrikon, providing the extra answers below after the Control Engineering webcast Five keys to successfully digitalizing your OT-data infrastructure,” Courtesy: Honeywell Matrikon, Control Engineering

How is data integration helping OT applications and digital transformation?

Question: How can normalized data using OPC-UA and or MQTT be used to align operations with key performance indicators and make those visible to MES, ERP and other manufacturing management applications?

Answer:The goal of the unified OT data layer (UODL) concept is to normalize OT data access and context in a secure, scalable, and sustainable manner so the right people and systems have timely access to all the data they need to best work individually and collectively. Standards and transports like OPC UA and message queuing telemetry transport (MQTT) respectively are examples of some of the underlying building blocks the UODL is built on. However, the UODL is an enabler or a foundational aspect of the broader business digitalization goal. So, the definition of desired KPIs at each company level and the applications and processes used to plan, drive, and measure progress toward those KPIs will rely on the normalized OT data provided by the UODL. In short, the normalized data serves as the lifeblood that enables people and applications to pursue higher IoT-era KPIs.

问:我觉得当管理说我们需要脱节d digital transformation and benefits I can quantify related to sensors, devices, controls systems and OT applications. Advice please?

A:Digital transformation is a broad topic. When talking about business digitalization, leadership often looks at how the entire company runs and impacts how the company will interact with customers, how decisions are made, and how workflows are adjusted to best meet market demand, regulatory pressures, and profitability. To succeed in realizing the benefits of digitalization, it is critical for the business side to be aligned with the status and capacity of the operations (factory up-time, production capacity, operational efficiency, product quality, etc.) Hence, a part of the digitization activity must also look at what improvements can be made on the OT side to better monitor, maintain, and produce. This is why there is a lot of focus on using machine learning, big data analytics, and AI to better utilize and run things on the OT side.

Q: When implementing digital transformation where are some challenges, and how can a unified OT data layer help?

A:While every company has its own OT data architecture characteristics, companies routinely face one or more of the following OT data infrastructure-based digitalization challenges: data source connectivity, aggregation of the data, making the data meaningful to the different entities that will need to use it in their own contexts, sharing the data across the enterprise, and being able to move the data to the cloud. Each of these challenges demands a secure, scalable, and sustainable solution to ensure an organization can work with what it already has and be able to seamlessly integrate new technologies as they get added in the future. The UODL concept is based on data technology (DT) like Matrikon Data Broker, which addresses such challenges holistically. A key characteristic of DT is that such issues are handled “under the hood,” so people can focus on putting digitalized OT asset data to work across the enterprise instead of being mired in trying to get to the underlying OT data in the first place.

Q: I work with automation of processes and want to know if any tool in OPC UA can help with viewing a historical in specific time of data? Like reports of information/data for future consulting?

A:The OPC UA standard defines how to work with historical data via the OPC UA HA (Historical Access) specification. Applications that implement OPC UA HA functionality will be able to work with historical time-series data. However, what user experience the application offers end-users will depend on what its purpose is and how the user interface was designed. For example, an OPC UA HA enabled reporting application may show you historical data representations via a trends and charts, but a pass-through application for exposing SQL time series data via OPC UA may not provide users with a GUI for working with that data.

Can the OT data layer applications integrate with cloud offerings?

Q: How does Matrikon work with Azure IoT Microsoft managed cloud services?

A: The Matrikon Data Broker (MDB) can be deployed as part of an Azure IoT Microsoft Managed Cloud Solution. MDB is available as an IoTEdge module in the Azure marketplace. As such, it can be deployed from the cloud to an edge device. Once it is on the edge device, you can deploy other IoT Edge modules (like Microsoft UA Publisher) which can read data from MDB (via OPC UA) and send that data through to Azure IoTHub and be accessed via IoT Central.

Q: Where do we start to create a robust, coherent unified OT data layer across the shop floor, the enterprise and cloud?

A:The UDOL approach to looking at OT data throughout a business is to treat disparate OT data sources holistically. The way this is built in practice is by establishing connections with all OT data infrastructure, federating it into a common unified address space, enriching the context of source data as close to the source as possible, and making that data securely available to those who need it. Where do you start? You start with what you have. For example: If you have OPC Classic infrastructure, you convert it to OPC UA or replace it if that fits your situation and federate it using a DT-like Matrikon Data Broker. If you have proprietary connectors, you use a converter to make it OPC UA based and federate that too. The data from whatever OT data sources you could bring into the UODL then becomes available for use enterprise-wide. Next, you look at who will consume the data. Is the consumer outside a firewall or DMZ? If yes, then you add a component on the other side to enable secure communications across the firewall and so on. One upside to this approach is that you can do so in a phased fashion.

How does a unified data layer change OT communications?

Q: Do I need to add/replace/do something different to get OPC UA benefits in a unified OT data layer? We already have multiple OT industrial networks.

A:This question can be answered in two steps. First, the Unified OT Data Layer (UODL) uses OPC UA as its native data modeling and communication standard, so by implementing a UODL, you have access to the benefits OPC UA has to offer. As for any changes you may need to make to your existing infrastructure: this would depend on whether your OT data infrastructure already uses OPC UA or not. For your OPC UA-enabled components, you could federate them directly into a Data Technology class application like Matrikon Data Broker and you would be ready to go. If you have OT data infrastructure that uses proprietary protocols, other open standard-based protocols, or OPC Classic, you would need to use an appropriate adapter to convert each component’s native communications to OPC UA, so you could federate (aggregate) data from that component into the UODL. As for having multiple OT networks, that would not be an issue. You could federate your data from these different networks or keep them separate – the choice would be yours and would depend on what your needs are.

Q: Can a unified OT data layer replace industrial networks in a new installation and connect to remaining traditional communications without rip and replace?

A:The purpose of the UDOL is to abstract underlying data sources and their native data formats into a single entity based on a unified address space. By doing this, a UODL reframes OT data from being a collection of individual data sources that have different security mechanisms and data contexts (often statically defined by each component vendor) into a holistic view of all the OT data in one, unified address space where users can create new views, and use them enterprise-wide without worrying about the IT/OT gap. With this high-level overview in mind, the answer to the question is not about replacing networks or components. Instead, a UODL is used to abstract a company’s heterogenous OT data infrastructure into a common representation that enables the right people access the right data, in the right format, wherever they are in the company. In other words, the UODL enhances whatever new or existing OT data infrastructure a company has.

Q: Why not just use MQTT?

A:The choice of the right transport (like MQTT) for the right environment and functionality requirements is an important consideration in the broader digitalization project scope. However, while it is important, there are many other considerations to consider for use cases where OT data will be accessed and used enterprise-wide and to the cloud. The UODL and the DT used to implement it addresses the challenge holistically – meaning it addresses a broader set of questions than ‘just’ the choice of a transport.

How does a unified data layer change cybersecurity?

Q: Does a unified OT data layer make cybersecurity more difficult, or just different? How?

A:Implementing a UODL generally improves your OT data infrastructure security across the board because your communications become OPC UA-centric (and optionally use MQTT when talking to the cloud). You can start using UA reverse connect functionality for secure cross-firewall communications between components that do not natively support OPC UA and those that are OPC UA enabled, but lack reverse connect functionality. In addition, by federating underlying OT data sources, the UODL provides a unified OT data address space, which data consumers can connect to instead of making a direct connection to the OT data sources.

Q: Can you explain more about the security measures in the system?

A:安全是一个广泛的话题,所以我我们将涉及those aspects of security directly related to accessing OT data sources and moving the data throughout the business. Security concepts that come into play here are: authentication for establishing trust between entities (both software and users) and authorization (determining who can see what and do what with it). In the case of Matrikon Data Broker DT, this is based on OPC UA security because that standard has successfully passed intense 3rd party security from industry, standards, and state organizations. As always, security of any solution is only as good as the quality of the implementation of the security standards the solution is based on and the way people use it. For this reason, MDB is not only compliant with the OPC UA standard, but it is also based and tested against best secure programming practices and the user interaction is designed around the security-first paradigm. Seeing how UODL crosses OT, IT, and cloud environments, it also incorporates IT security best practices like the use of reverse connect functionality to enable cross-firewall communications between data producers and consumers while keeping in-bound firewall ports closed. There is a lot to talk about here so I will end the answer here but encourage you to look at some of the other webcasts and papers Matrikon and the OPC Foundation (among many others) have on the topic.

Q: Please provide examples of how applications migrated to a structure with a unified OT data layer?

A:Companies often use specific UODL functionality (built using Matrikon Data Broker) depending on the OT data infrastructure challenges they face in their architectures. Some use UODL infrastructure to federate OT data source data to create a single access point, which they then use to share OT data with the business network sitting on the other side of their demilitarized zone (DMZ). Others use MDB to easily select what data they want to share to a 3rd party cloud and publish it using MQTT Publisher (an MDB extension). As a final example, some companies need to re-map data structured in one way into a different format for use by a different application. In each case, the role of the UODL is to maximize the security, ease of access, and value of the OT data – not in how the applications that consumed it operated.

– Edited by Mark T. Hoske, content manager,Control Engineering,CFE Media and Technology,mhoske@cfemedia.com.

KEYWORDS:Operational technology, unified OT data layer

CONSIDER THIS

Is OT informationintegration efforts keeping you from digital transformation benefits?

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Clickhereto start this process.