What Is OPA? Part 4

Show notes

Jarie and David continue the What Is OPA? series with a practical look at how the OPA specification is structured, what each part covers, and why conformance matters. They walk through the standards behind interoperability, cybersecurity, diagnostics, and orchestration in modern automation systems.

Watch on YouTube. Listen on Spotify or Apple Podcasts.

Key topics

• David explains that the Open Process Automation Forum is a consortium of vendors, end users, academics, and other industry participants building the OPA specification, often called O-PAS.
• O-PAS is described as a “standard of standards” because it adopts existing standards instead of inventing new ones when adequate standards already exist.
• The first version of OPA covered parts 1 through 5, including basic architecture, technology expectations, cybersecurity, manageability, and the OPA communications framework.
• Cybersecurity is anchored in IEC 62443, with SL2 presented as the minimum security level required for OPA components.
• Manageability is tied to diagnostics and system visibility, with Redfish and SNMP discussed as important tools for knowing what is in a system and how it is performing.
• The communications framework centers on OPC UA, including client-server and pub-sub models, with OPC UA FX mentioned as an emerging extension for I/O and configuration access.
• Version 2 adds a structured data information model built around value, timestamp, quality, plus engineering range and engineering units to avoid scaling confusion.
• David gives examples of long-standing automation problems caused by mismatched units and scaling, such as temperature ranges and 4 to 20 milliamp conversions.
• The standard also includes programming language expectations, with IEC 61131 as the familiar baseline and IEC 61499 discussed as an event-driven, state-based option.
• Physical expectations are defined too, such as network ports, RJ45 connectivity, gigabit networking, and 24 volt DC power, while avoiding over-specifying product design.
• A major future direction is application portability and orchestration, which David says is becoming table stakes and must work alongside cybersecurity and diagnostics.
• Conformance testing is required and cannot be self-certified. The forum uses third-party validation so vendors can prove claims instead of simply asserting compliance.
• Certification coverage is discussed across OPC Foundation testing, Redfish labs, and cybersecurity validation, with the forum maintaining a registry of certified companies and products.
• Jarie and David close by emphasizing that the goal is to make automation easier by standardizing the foundation, not by constraining innovation.

Timestamps

• 00:00 — Intro to part four and why the structure of OPA matters
• 01:28 — OPA as a standard of standards
• 02:26 — Version one: architecture, cybersecurity, manageability, and communications
• 03:26 — IEC 62443 and SL2 as the minimum cybersecurity baseline
• 04:23 — Manageability, diagnostics, and the role of Redfish and SNMP
• 05:48 — OPC UA as the OPA communications framework
• 06:46 — Why structured data needs timestamp and quality
• 07:44 — Engineering ranges and units prevent scaling mistakes
• 09:59 — IEC 61131 languages in the automation stack
• 10:57 — IEC 61499 and event-driven control
• 11:51 — Physical requirements like ports, RJ45, and 24 volt DC
• 14:50 — Application portability and orchestration in the next version
• 16:19 — Why conformance testing cannot be self-certified
• 17:17 — Third-party validation for interoperability claims
• 19:20 — Certification labs for OPC UA, Redfish, and cybersecurity
• 20:47 — The forum symbol, registry, and compliance claims
• 21:45 — Looking ahead to part five and what OPA means in the field

Next: What Is OPA? Part 5.