OT/IT integration: connecting the production floor to IT
Gabriela Gic-Grusza
OT/IT integration connects operational technology – SCADA, PLC and DCS control systems – with information technology such as ERP, cloud platforms and analytics, providing real-time data visibility from the shop floor to management. Based on the Purdue Model, it enables industrial data to flow securely between process control and business decision-making.
For decades, these two domains were built and maintained separately, with different priorities, protocols and equipment lifecycles. This guide explains what OT/IT integration is, how the Purdue Model and ISA-95 frame it, which architecture patterns and protocols enable it, what security questions it raises, how it works in manufacturing practice, and where an industrial data platform can provide the underlying foundation.
What is OT/IT integration?
OT/IT integration is the connection of information technology systems (ERP, databases, cloud platforms, analytics applications) with operational technology systems (SCADA, PLC, DCS, RTU, HMI, sensors) so that control and business data can flow between the shop floor and the enterprise.
Operational technology (OT) includes the hardware and software that directly monitor and control physical processes – from a single PLC to a large-scale DCS. Information technology (IT) is the data-processing layer: networks, servers, cloud platforms, ERP, CRM and BI applications, and cybersecurity. Historically, these two worlds developed in isolation: OT focused on process continuity and safety, while IT focused on processing and exchanging information.
The terms “IT/OT integration” and “IT/OT convergence” are often used interchangeably in the literature. In engineering practice, convergence describes the broader, long-term trend of bringing the two domains closer together – organizationally, technologically and in terms of skills – whereas integration refers to the specific mechanisms used to connect systems and exchange data. The framework that structures this connection is ISA-95, which defines enterprise-control system integration, together with the layered Purdue Model derived from it.
Where the data platform fits? In this architecture, an industrial data platform such as Smart RDM can act as a layer between distributed OT and IT data sources and operational, reporting and analytics applications. It connects existing systems, normalizes and contextualizes their data, and makes it available in a controlled way. Importantly, the platform does not replace PLCs, DCS, SCADA, HMI, SIS, MES, ERP systems or historians – it operates above them and works with them.
IT vs OT: key differences
The most important distinction is that IT is data-oriented, while OT is oriented around the physical process – and almost all other differences follow from this.
In IT, confidentiality is typically the primary concern (the CIA triad: Confidentiality, Integrity, Availability). In OT, the order is reversed (the AIC triad: Availability, Integrity, Confidentiality) – the plant must keep running because stopping a pump or compressor has direct physical consequences. This inversion of priorities affects everything from update cycles and latency tolerance to protocol selection and restart policies.
| Dimension | IT | OT |
| Primary priority | Confidentiality (CIA triad) | Availability (AIC triad) + safety |
| Orientation | Data, information | Physical process, control |
| Equipment lifecycle | 3-5 years | 15-20 years or more |
| Update cycle | Frequent (months) | Infrequent, tied to plant shutdowns |
| Protocols | TCP/IP, HTTP, databases | Modbus, PROFINET, EtherNet/IP, OPC UA |
| Impact of failure | Data loss/leakage | Process shutdown, risk to people and the environment |
| Timing requirements | Flexible | Deterministic, strict real-time constraints |
| Typical devices | Servers, workstations, cloud platforms | PLC, DCS, RTU, HMI, sensors, actuators |
| Organizational ownership | IT, applications, data teams | Production, automation, maintenance, engineering |
These differences are not obstacles to be eliminated; they are design constraints. A well-designed OT/IT integration respects OT requirements such as determinism, availability, long equipment lifecycles and safety instead of imposing the pace and assumptions of the IT world.
Why OT/IT convergence matters
OT/IT integration matters because it makes process data available to the enterprise decision-making layer, replacing scattered logs, spreadsheets and delayed reports with a consistent, up-to-date operational view.
Operationally, connecting shop-floor data with analytics and planning systems enables a wide range of use cases: real-time production monitoring, predictive maintenance support, manufacturing analytics, and consistent production data management. The table below summarizes typical benefits qualitatively, as capabilities rather than promises of value.
| Benefit | Mechanism | Condition | Example metric |
| Real-time visibility | Automated OT -> MES/BI data flow | Consistent timestamps and identifiers | Data publication latency |
| Less manual reporting | Integration of source systems with reporting | Data validation and completeness | Report preparation time |
| Better diagnostics | Combining alarms, trends and events | Device history and context | Mean time to diagnose |
| More accurate planning | Linking execution with the plan | Stable L3 <-> L4 data contract | Plan-to-actual variance |
| Better auditability | Versioning, lineage, roles | Record of changes and sources | Share of data with an audit trail |
| Faster use-case deployment | One data layer for multiple consumers | Governance and a shared semantic model | Time to launch a new use case |
In Poland, the regulatory context is now a real driver rather than background. The amendment to the Act on the National Cybersecurity System implementing the NIS2 Directive entered into force on 3 April 2026 (Journal of Laws 2026, item 252). It expands the range of entities subject to the requirements and introduces a distinction between essential and important entities [1]. At EU level, these requirements originate from Directive (EU) 2022/2555 (NIS 2), which requires organizations to implement cybersecurity risk-management measures [4]. For an industrial company, this means that well-governed OT/IT integration is part of compliance, not something that comes after it.
Where Smart RDM can help? A platform such as Smart RDM can reduce the number of point-to-point integrations, standardize names, units, timestamps and quality statuses, and create a shared information layer for monitoring, reporting, analytics and workflows. This does not automatically guarantee higher OEE, reduced downtime or energy savings: outcomes also depend on measurement quality, process organization, the data model, and how users act on the information.
One point that is obvious to an OT engineer is worth stating clearly: integration is not inherently “better” than separation. Some installations legitimately require a high degree of isolation. Integration is an architectural choice that brings specific capabilities as well as specific obligations.
The Purdue model and ISA-95 architecture
The Purdue model is a reference architecture that structures industrial systems from the physical process up to business planning and defines the boundary between OT and IT. However, it is important to distinguish precisely between the formal content of the standard and practical extensions.
ISA-95, published internationally as IEC 62264 “Enterprise-control system integration,” formally defines Levels 0 through 4 and describes the interface between manufacturing operations (Level 3) and business systems (Level 4). Two widely used terms are not part of the formal standard. Level 3.5 is a practical name for the industrial DMZ, while Level 5 is an extension used in diagrams to represent the corporate network and external services. A system name does not determine its level either – a historian, SCADA system or MES should be classified according to the function it performs.
| Level | Status | Function | Typical examples |
| Level 5 | Practical extension | Corporate network / external services | Enterprise WAN, internet-facing services, multi-site |
| Level 4 | Formal ISA-95 | Business planning and logistics | ERP, finance, planning, supply chain |
| Level 3.5 | Practical extension (industrial DMZ) | IT/OT buffer zone | Reverse proxy, jump host, replicas, controlled remote access |
| Level 3 | Formal ISA-95 | Manufacturing operations management | MES/MOM, execution, quality, scheduling |
| Level 2 | Formal ISA-95 | Supervisory monitoring and control | PLC, DCS, HMI |
| Level 1 | Formal ISA-95 | Sensing and actuation | Sensors, drives, valves, transmitters |
| Level 0 | Formal ISA-95 | Physical process | Material, energy, motion, reactions |
Purdue Model and industrial DMZ – ISA-95 formally covers Levels 0–4; Level 3.5 (industrial DMZ) and Level 5 are practical extensions.
The industrial DMZ (Level 3.5) is critical here: it is an intermediary zone in which traffic between IT and OT is deliberately controlled through mechanisms such as reverse proxies, jump hosts, replicas and controlled remote access, rather than being allowed to pass directly. The Purdue Model is not a rigid prescription; cloud and edge architectures change its shape, and NIST notes that modern smart manufacturing systems can be less strictly hierarchical. Even so, it remains a common language for discussing trust boundaries and data flows.
Integration architecture patterns
OT/IT integration is implemented using several recurring patterns – from edge gateways and integration platforms to unified namespace architectures and data lakes – and the right pattern depends on scale, timing requirements and data maturity.
Historically, the starting point was point-to-point connectivity. This approach does not scale: the number of connections grows rapidly, and maintenance turns into a web of dependencies. Modern patterns replace it with an intermediary layer.
| Pattern | How it works | Typical use |
| Edge gateway / middleware | Protocol translation at the source, buffering (store-and-forward), initial processing | Connecting legacy OT devices to the IT layer |
| Integration platform / iPaaS | API-driven integration, often cloud-based | Integrating multiple systems and sites |
| Unified Namespace (UNS) | Governed, event-driven pattern for publishing states and events (often MQTT/Sparkplug) – not a broker in itself | Environments requiring a consistent, current view of data |
| Data lake / cloud historian | Collection of raw and contextualized data | Historical analytics and model training |
| Controlled unidirectional transfer (data diode) | Physically enforces one-way data flow | Where risk assessment rules out a return channel |
| Point-to-point (legacy) | Direct links between systems | Legacy pattern that does not scale |
Data flow in OT/IT integration – from sensors and controllers through an edge gateway and unified namespace to the historian, data platform, and business systems.
Choosing a pattern is not a once-and-for-all decision – in practice, architectures are often hybrid. An edge gateway and a unified namespace are not mutually exclusive: the gateway translates and buffers data at the source, while the broker makes it available downstream in a consistent form. Key selection criteria include scale, timing constraints, latency tolerance, and whether data is consumed as a stream or queried on demand.
A separate and often underestimated issue is data contextualization. A raw sensor reading has limited value in the IT layer until it is enriched with metadata: what it represents, which asset it comes from, what unit it uses, and when it was recorded. Adding this context through an information model and an ISA-95-aligned asset hierarchy is what separates simply moving data from integration that can support analytics. In brownfield environments, the intermediary layer often takes responsibility for standardizing and enriching the data.
Unified Namespace is an increasingly important pattern, and it is worth defining precisely: it is a governed pattern for publishing industrial states and events, often implemented using MQTT and profiles such as Sparkplug – it is not simply a broker. Its effectiveness comes not from the broker itself, but from disciplined topic naming, object modeling, ownership and change control. “UNS without governance” usually recreates the data chaos it was intended to eliminate.
It is also important to distinguish three roles that are often confused. A protocol gateway translates protocols and formats. An edge gateway can additionally buffer, filter, aggregate and compute locally. A data diode is a security mechanism – a unidirectional gateway – not a standard feature of every gateway.
A historian and a data lake are not the same thing either. A historian is optimized for high-volume time-series data with timestamps, sample quality and compression; a data lake or lakehouse supports a much broader range of data, including files, documents, MES/ERP data and datasets for AI/ML. In mature architectures, they usually coexist rather than replace each other.
| Property | Historian | Data lake / lakehouse |
| Primary data type | Time series, alarms, process events | Multi-source structured and unstructured data |
| Optimization | Fast signal write/read, trending | Flexible analytics, AI/ML, domain datasets |
| Architectural role | Specialized process-data store | Broader data and analytics layer |
| Does it replace the other? | No | No |
Where Smart RDM fits in the architecture? A platform such as Smart RDM is best positioned as an integration, contextualization, data and application layer above devices and control systems. It can use connectors, edge gateways, OPC UA, MQTT, APIs, databases and historians, and then provide standardized information to dashboards, reports, alarms, workflows and analytics applications. This positioning allows the solution to evolve without interfering with the responsibilities of control systems or suggesting that a single platform can replace the entire OT/IT stack.
| Layer or need | Potential role of Smart RDM | Responsibility boundary |
| Data acquisition | Connectors to approved OT, IIoT and IT sources; controlled ingestion | Does not replace controllers, the industrial network or safety functions |
| Normalization | Standardizing names, types, units, timestamps and quality statuses | Does not physically correct an incorrect measurement |
| Contextualization | Linking data to plant, area, line, asset, product and work order | Requires agreed owners and a data model |
| Data access | Dashboards, reports, alarms, workflows, APIs | Access scope is governed by RBAC and the security architecture |
| History and analytics | Storing/consuming historical data and preparing datasets | Does not always replace a specialized historian or lakehouse |
| Scaling | Reusing models, templates, rules and interfaces | Requires governance, versioning and change management |
Industrial protocols for OT/IT
Industrial protocols are the layer that makes data exchange between OT devices and IT systems possible in the first place – and their diversity is one of the main integration challenges.
In practice, OPC UA serves as a key interoperability standard between IT and OT: it is platform-independent, carries data together with its information model, and is well suited to crossing the control-to-enterprise boundary. MQTT is a lightweight publish/subscribe protocol widely used in IIoT and unified namespace architectures. Alongside them are protocols that are more natively industrial and tied to specific control ecosystems.
| Protocol | Characteristics | Typical environment |
| OPC UA | Platform-independent interoperability with an information model | IT/OT interoperability, control-to-enterprise gateway |
| MQTT | Lightweight publish/subscribe message transport (payload-agnostic) | IIoT, unified namespace |
| Sparkplug | Profile for MQTT in OT (session state, payload structure) | UNS deployments requiring a shared contract |
| Modbus | Simple register-based protocol; Modbus Security adds TLS and X.509v3 | Legacy devices, simple meters and controllers |
| PROFINET | Industrial Ethernet (real-time), with evolving security mechanisms | Siemens ecosystem |
| EtherNet/IP | CIP-based Industrial Ethernet; CIP Security available | Rockwell / Allen-Bradley ecosystem |
| WirelessHART / ISA100.11a (IEC 62734) | Wireless industrial mesh networks | Telemetry, distributed process sensors |
It is important to separate these roles precisely because the control layer, interoperability and message transport are easy to confuse: OPC UA provides interoperability, an address space and information models; MQTT provides lightweight message transport; and Sparkplug is a profile that adds session state and payload structure on top of MQTT. In real-world integration, it is rare to deal with only one protocol.
OT/IT integration security
OT/IT integration expands the attack surface because it connects control systems that were once isolated with IT networks and the internet. Security is therefore a prerequisite for success, not an add-on. This section provides an overview; a full discussion is available in the dedicated OT security material.
The risk is not theoretical. A notice issued by the Polish Government Plenipotentiary for Cybersecurity highlighted a growing number of attacks on industrial control systems (ICS/OT) that were directly accessible from the internet, some of which had a real impact on physical systems [2]. A broader picture is provided by CERT Polska’s 2024 annual report, which recorded more than 600,000 reports, over 100,000 handled incidents, and 147 ransomware incidents, an 8% year-on-year decrease [3].
A characteristic challenge in OT environments is that many legacy devices cannot be updated or patched easily, while security tools designed for IT may not be suitable for real-time operational constraints. Architectural controls therefore remain fundamental: network segmentation, a dedicated DMZ, restricted and controlled remote access, and zero-trust principles adapted to OT limitations. The starting point is asset visibility using passive methods, because active scanning can disrupt controllers, together with anomaly detection tuned for OT. Third-party remote access requires particular attention: it should be enabled on demand, sessions should be recorded, VPN access should be restricted to specified addresses, and least-privilege principles should apply [2].
At the framework level, industrial automation and control system security is addressed by the ISA/IEC 62443 series, including zones and conduits, security levels, and the allocation of responsibilities among asset owners, integrators, service providers and product suppliers. It is complemented by NIST SP 800-82 (Guide to OT Security) – Rev. 3 remains the final version, while a pre-draft call for comments for Rev. 4 opened in January 2026, so it is not yet a normative draft [5] – and by the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover).
The role of Smart RDM in secure integration. A data platform can support controlled read-only data flows, roles and permissions (RBAC), complete activity auditing, data validation, and access through approved interfaces. [SR-verified] It does not replace network segmentation, OT firewalls, IAM, secure remote access, network monitoring or risk assessment aligned with ISA/IEC 62443 and NIST SP 800-82. Positioned this way, the platform remains a consumer of approved data rather than becoming a new path from IT into OT data sources.
Edge computing in OT/IT integration
Edge computing moves data processing closer to the source – onto the shop floor – reducing latency, saving bandwidth and enabling local analytics where the cloud would be too slow or unreliable.
In OT/IT integration, the edge layer acts as a bridge: protocol translation, store-and-forward buffering and initial stream processing take place there. Containerized applications, including local model inference, are increasingly deployed on edge devices. The edge layer does not replace the cloud; it complements it by handling tasks that need to run close to the process and within IIoT timing constraints.
Deployment models: on-premises, cloud and hybrid
Where the integration and data layer runs – on-premises, in the cloud or in a hybrid model – is an architectural decision, not a vendor advantage, and should follow the requirements of the process.
An on-premises model is appropriate where local processing, infrastructure control, limited external exposure or low latency are critical. A cloud model supports centralization across multiple sites, flexible scaling and shared services. A hybrid model keeps data acquisition, buffering and availability-dependent functions close to the process, while cross-site, multi-plant and analytics services are delivered centrally or in the cloud. The choice depends on availability, data sovereignty and retention, latency, connectivity, the operating model, regulatory requirements and OT risk assessment.
| Model | Best fit when… | Key requirements and constraints |
| On-premises | Data and services must remain in the customer infrastructure; local availability and low latency are required | The customer is responsible for infrastructure, updates, backup, monitoring and scaling |
| Cloud | Multi-site centralization, rapid scaling and shared services are required | Secure connectivity, identity control, a plan for connectivity loss, regulatory compliance |
| Hybrid | Operational functions must run locally, while central services handle reporting and analytics | Clear responsibility split, synchronization, store-and-forward, consistent governance |
Smart RDM’s modular architecture can be deployed on-premises, in the cloud or in a hybrid model, with access control and full activity auditing across distributed environments. [SR-verified]
How to implement OT/IT integration
OT/IT integration is best implemented in stages – from inventory and alignment, through architecture selection, to individual end-to-end capabilities that are tested before moving on – rather than as one “everything at once” project.
A sensible sequence begins with understanding the current state: which OT and IT systems are involved, which protocols and data are in use, and where the trust boundaries lie, with the Purdue Model providing a useful reference. The next step is to agree on the target architecture and choose a pattern appropriate to the scale and timing requirements. Only then should implementation proceed incrementally: one capability, deployment, end-to-end test, then the next.
The biggest challenges are rarely purely technical: the cultural divide between IT and OT teams, legacy systems, protocol incompatibilities and strict real-time requirements all play a role. Governance questions should be resolved in parallel: who owns each data stream, who is responsible for its quality and continuity, how names and units are defined, and where responsibility boundaries lie. Before the first interface is built, a short readiness baseline helps: an inventory of sources and owners; classification of each flow as read-only, controlled write or bidirectional; a map of zones and conduits; timing, authentication and retention rules; a data quality model; and an agreed change-management procedure.
How Smart RDM can support the roadmap? The platform can be used from pilot through scaling, but the scope should match the organization’s maturity. The safest approach is to begin with a limited use case, verify data quality, communication directions and ownership of the model, and only then expand the number of sources, objects and consumers.
| Client decision stage | Question to resolve | Potential Smart RDM support |
| Use case and scope | What decision or process should the integration support? | Workshop on sources, consumers, KPIs and the minimum pilot scope |
| Inventory | Which systems, data points and dependencies are involved? | Catalog of sources, connectors, data points and owners |
| Integration | How can data be acquired without disrupting the process? | Controlled connectors and a preferred read-only flow |
| Data model | How should meaning, units and hierarchy be standardized? | Normalization and contextualization in the plant and asset model |
| Data access | Who needs the information and in what form? | Dashboards, reports, alarms, workflows and APIs with access control |
| Operationalization | Who maintains the service and how are changes handled? | Roles, logging, versioning, monitoring and auditing |
| Scaling | How can the solution be extended to additional lines and plants? | Templates, repeatable models, rules and multi-asset management |
OT/IT integration in manufacturing
In manufacturing, OT/IT integration primarily means connecting the control layer (SCADA, PLC) with the execution and planning layers (MES, ERP), enabling real-time production monitoring.
At plant level, MES (Level 3 of the Purdue Model) acts as the bridge between production execution and planning, while data from sensors and controllers – collected, contextualized and made available upstream – feeds both current production monitoring and related domains such as energy management. A shared, integrated data layer is what makes an individual shop-floor reading useful once it reaches the decision-making layer in a consistent form.
Integrated data can serve as a common input for several use cases that remain distinct disciplines: manufacturing analytics, predictive maintenance, energy management, quality, OEE and digital twins. In this article, they are only brief pointers to dedicated materials; a platform such as Smart RDM can provide the shared input layer, while the detailed methods and models belong in separate guides.
Vendor landscape
The market for solutions supporting OT/IT integration is diverse, spanning OT cybersecurity providers, IIoT platforms, edge hardware, connectivity providers, system integrators and data platforms. The overview below provides neutral market context without evaluation or ranking.
| Organization | Category | Neutral description of role |
| Palo Alto Networks | Cybersecurity | Security and IT/OT convergence perspective |
| TXOne Networks | OT security | Protection of OT devices and networks with a focus on continuity |
| PTC (ThingWorx) | IIoT platform | IIoT platform for industrial applications |
| Advantech | Industrial edge | Edge gateways and computers, protocol gateways, edge AI |
| Interstates | Systems integrator | Integration of automation, OT and manufacturing systems |
| emnify | IoT connectivity | Global cellular connectivity for IoT devices |
| Wind River | Edge software | Software and virtualization for the intelligent edge |
| Smart RDM | Industrial data and AI platform | Publicly described platform connecting OT, IIoT, IT and AI |
How Smart RDM differs from other categories. Smart RDM is not a PLC manufacturer, an edge-device vendor, an OT firewall provider, a connectivity operator or a consulting company. It is an industrial data platform that operates above existing sources and infrastructure, working with automation systems, historians, MES, ERP, edge gateways and security tools to connect, contextualize and make data available. This distinction avoids comparing fundamentally different categories.
FAQ
What is OT and IT integration?
It is the connection of operational technology systems (SCADA, PLC, DCS, sensors) with information technology systems (ERP, cloud platforms, analytics), enabling data exchange between the shop floor and the business layer.
What does IT/OT mean?
IT is information technology – data processing, networks, cloud platforms and business applications. OT is operational technology – hardware and software that control physical processes. IT/OT refers to connecting the two domains.
How do OT, ICS and SCADA differ?
OT is the broadest term; ICS, or industrial control systems, are a subset of OT; SCADA is a type of ICS used for supervisory control and data acquisition.
How does IT differ from OT?
IT is oriented around data and services, while OT is oriented around the physical process and safety/availability because failures can have physical consequences.
What is the Purdue Model?
It is a hierarchical reference model for industrial layers; ISA-95 formally covers Levels 0-4, while Level 3.5 (DMZ) and Level 5 are practical extensions.
What is ISA-95?
It is a series of standards for enterprise-control system integration, also published as IEC 62264.
How do OPC UA and MQTT differ?
OPC UA provides interoperability and information models; MQTT provides lightweight publish/subscribe transport. They are complementary, not interchangeable.
What is a Unified Namespace?
It is a governed pattern for publishing states and events, often based on MQTT and Sparkplug – not simply a broker.
How can IT and OT be integrated securely?
Through segmentation, zones and conduits, an industrial DMZ, least privilege, identity controls, monitoring and change management, aligned with ISA/IEC 62443 and NIST SP 800-82.
A practical next step
An organization planning to integrate OT with IT can begin with a focused architecture workshop covering data sources, consumers, communication directions, quality requirements, the deployment model and success criteria. Smart RDM can support this stage and a pilot on a single line, installation or group of assets before the solution is scaled further.
Sources
- [1] Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws 2026, item 252), implementing the NIS2 Directive; entered into force on 3 April 2026. https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252
- [2] Notice of the Polish Government Plenipotentiary for Cybersecurity on attacks against industrial control systems, Ministry of Digital Affairs / gov.pl (2025). https://www.gov.pl/web/cyfryzacja/komunikat-pelnomocnika-rzadu-do-spraw-cyberbezpieczenstwa-ws-atakow-na-przemyslowe-systemy-sterowania3
- [3] CERT Polska, “The Security Landscape of the Polish Internet 2024” (published 3 April 2025). https://cert.pl/uploads/docs/Raport_CP_2024.pdf
- [4] Directive (EU) 2022/2555 (NIS 2), 14 December 2022 (OJ EU L 333, 27 December 2022, p. 80). https://eur-lex.europa.eu/eli/dir/2022/2555
- [5] NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (28 September 2023, final version); Rev. 4 – pre-draft call for comments opened on 22 January 2026. https://csrc.nist.gov/pubs/sp/800/82/r3/final
- [6] NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (26 February 2024). https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- [7] ISA/IEC 62443, Security for industrial automation and control systems (series). https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
- [8] IEC 62264 (ISA-95), Enterprise-control system integration – Part 1. https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- [SR] Public Smart RDM materials (deployment models, access control and auditing, source integration, multi-site scaling): https://smartrdm.com/ ; https://smartrdm.com/blog/overcoming-data-integration-and-analysis-challenges-in-manufacturing/ ; https://smartrdm.com/pi-data-integrator/
Light mode