PROFINET family (PNEM, PNENC, PNRIO, PNDRV, PNGSDGM)
| Version | - |
|---|---|
| Published | 2024 |
| Sector | Fieldbus integration |
A family of models bringing PROFINET concepts into OPC UA: energy management, encoders, remote IO, drives and GSD-based generic modelling. These exist because PROFINET is deeply installed and the two worlds have to meet somewhere.
Where it sits in the stack
Built on the Device Information Model. Each member covers a different PROFINET device class, and PNO is the registered capability code for the family.
The types that matter
| Type | What it carries |
|---|---|
(type inventory not confirmed) | Several separate namespaces whose type inventories we have not verified. Browse the released nodesets. |
Using it on a real machine
- Identify which member appliesEnergy, encoder, remote IO, drive and GSD-based generic modelling are separate namespaces for separate device classes.
- Check the PNO capability codeA server claiming PNO is exposing PROFINET-derived structure.
- Do not expect machine semanticsThese describe devices and their parameters, not machines and their production. For production data you still need Machinery or a sector model.
What it gives you for OEE
Device-level data. The drive and energy models are the most useful for analytics: drive condition explains stoppages and energy data supports energy-per-part alongside OEE. Neither gives you state or counts.
Gotchas
- Several separate namespaces grouped on one page. Browse for each.
- Device parameters, not machine semantics. A common expectation mismatch.
- The drive and energy members are the ones most worth integrating for analytics.
Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.
See Jemba →Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.