Part 8: Data Access
| Document number | OPC 10000-8 |
|---|---|
| IEC designation | IEC 62541-8 |
| Colloquially | Part 8 |
| Group | Access type |
Part 8 defines the VariableTypes that turn a raw number into a process value: AnalogItemType with its range and engineering unit, the discrete item types with their state names, and the array item types. It also owns the engineering-unit code list used across the whole standard.
What it defines
A family of VariableTypes descending from DataItemType, each adding the metadata a client needs to display and scale a value correctly. AnalogItemType adds EURange, EngineeringUnits, InstrumentRange, Definition and ValuePrecision. The discrete types add state names. The array item types describe sampled arrays, images and cubes with axis information. None of this changes how you read a value; all of it changes whether the number you read means anything.
Analog items, ranges and units
EURange is the expected range of the value in engineering units and is what an HMI uses for a bar graph and what percent deadband is calculated against. InstrumentRange is the wider range the instrument can physically produce. EngineeringUnits is an EUInformation structure carrying a unit identifier drawn from UNECE Recommendation 20, plus a display name and description - so the unit is a code with a defined meaning, not free text. AnalogUnitType and AnalogUnitRangeType are the newer variants that separate having a unit from having a range.
Discrete items and state names
TwoStateDiscreteType carries TrueState and FalseState as localised text for a Boolean. MultiStateDiscreteType carries an EnumStrings array indexed by the value, so a value of 2 means the third string. MultiStateValueDiscreteType instead carries an EnumValues array of explicit value-to-text pairs, which is the type to use whenever the numeric codes are not a dense zero-based sequence. Confusing the two is the standard cause of state labels that are wrong by one.
Optionality is the practical problem
Almost every property Part 8 defines is Optional under its modelling rule. A server can expose a Variable typed as AnalogItemType with no EURange and no EngineeringUnits at all, and it is still conformant. So a client cannot rely on the metadata being present, and an integration that needs units and ranges has to either browse for them and degrade gracefully or get them written into the server's configuration during commissioning.
What it defines
| Concept | What it is |
|---|---|
| DataItemType | The root of the family, adding Definition and ValuePrecision to a data variable. Everything else in Part 8 descends from it. |
| AnalogItemType | The process-value type: EURange, EngineeringUnits, InstrumentRange. This is what a temperature or pressure tag should be. |
| EURange | A Range structure with Low and High in engineering units. Required for percent deadband to be meaningful and used by clients for scaling. |
| EngineeringUnits and EUInformation | A structure with a namespace URI, a numeric unit identifier from UNECE Recommendation 20, a display name and a description. The unit id is the authoritative field. |
| InstrumentRange | The physical range of the sensor, wider than EURange. Useful for validating a suspicious reading; not for scaling a display. |
| AnalogUnitType and AnalogUnitRangeType | Variants that carry a unit with or without a range, for values that have a unit but no meaningful span. |
| TwoStateDiscreteType | Boolean with TrueState and FalseState text. The right type for a running or stopped flag, and it saves every client writing its own labels. |
| MultiStateDiscreteType | Integer value used as an index into an EnumStrings array. Only correct when the values are a dense sequence starting at zero. |
| MultiStateValueDiscreteType | Integer value matched against an EnumValues array of explicit value-to-text pairs. The correct type for sparse or non-zero-based codes. |
| Array item types | YArrayItemType, XYArrayItemType, ImageItemType, CubeItemType and the n-dimensional variant, each carrying axis definitions so a sampled array can be plotted correctly. |
Do you need to read it?
Anyone modelling a device and anyone building a client that renders values. Modellers should pick the most specific type available rather than exposing a bare BaseDataVariableType, because every downstream tool gets scaling, units and state names for free. Client developers need this part to know what metadata to look for and how to survive its absence.
Traps that trace back to this part
- Percent deadband is calculated against EURange, so a node without EURange cannot support it. Depending on the server you get BadDeadbandFilterInvalid, or the filter is accepted and quietly does nothing - which looks identical to a tag that never changes. Use absolute deadband where the range metadata is missing.
- EngineeringUnits carries a UNECE Recommendation 20 unit identifier, and the DisplayName next to it is a convenience string a vendor may fill in badly or leave in the wrong language. Resolve the unit identifier if the unit matters to a calculation; render the display name only for humans.
- The whole metadata set is Optional by modelling rule. A node typed AnalogItemType with no range and no unit is a conformant node, so any UI that requires them has to have a fallback. Check during factory acceptance rather than discovering it on site.
- MultiStateDiscreteType indexes EnumStrings by position while MultiStateValueDiscreteType matches EnumValues by value. Treating one as the other produces state text that is consistently wrong by one position, which is the kind of defect that survives testing and shows up in a shift report.
Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.