Standards and evidence
plcopen treats a matching name, verified software semantics, hardware validation, and formal approval as four different claim strengths. This page shows how to move from a public function-block entry point to specifications, boundaries, and auditable evidence.
Claim ladder
| Level | What it can prove | What it cannot imply by itself |
|---|---|---|
| Interface inventory | A function block and its pins exist | Clause-level behavior |
| Semantic matrix | Inputs, states, errors, and boundaries have a contract | Real drive, clock, or safety-device behavior |
| Automated gate | Named source and scenarios pass on stated platforms | Unexecuted paths, field reliability, or certification |
| Hardware evidence | Measurements hold for a named bench and configuration | Other devices, deployments, or long-term support |
| Formal approval | A responsible organization made the stated declaration | Product capability outside that declaration |
A function-block count, coverage number, or one green CI run therefore cannot stand in for PLCopen approval.
Entry map
| Question | Start here |
|---|---|
| What is the current public conformance position? | Project compliance |
| What inputs and outputs does a function block expose? | Function-block reference |
| Where does core capability differ from Beckhoff? | The parity matrix below |
| Is a limitation registered? | Known boundaries |
| What does a particular CI gate prove? | The CI gate matrix below |
| Is an ST language feature closed? | ST runtime |
Reading a standards question
- Use the function-block reference to locate the Part, name, and pins.
- Open the matching semantic matrix for state-machine, boundary, error, and explicit-exclusion behavior.
- Check the known-boundaries registry so a deliberate difference is not mistaken for an omission.
- Check the CI gate matrix to see which tests actually exercise the contract.
- If the conclusion depends on a fieldbus, drive, safety chain, or certification, stop at the software-evidence boundary.
Canonical sources
- The full PLCopen conformance audit is the cross-Part entry point for claims and certification boundaries.
- The PLCopen / Beckhoff core-capability parity matrix records implemented, partial, and excluded verdicts by capability.
- The CI gate matrix records workflow triggers, proof scope, and release role.
- The generated I/O declarations provide auditable machine-interface evidence.
Specification text, detailed matrices, and machine declarations remain authoritative in the repository. This page supplies only a stable reading path.