Parameters defined for the AnalyserDeviceType are described in the following tables. The tables correspond to mandatory FunctionalGroups defined for the AnalyserDeviceType. Additional Parameters may be defined on subtypes of AnalyserDeviceType and associated with those FunctionalGroups.

All AnalyserDevice Parameters exist as components of ParameterSet Object defined on that AnalyserDevice through inheritance from DeviceType. Each Parameter defined for an AnalyserDevice shall be accessible through one or more FunctionalGroup defined on that AnalyserDevice. Note, that the same Parameter is not instantiated more than once. Both, ParameterSet and a specific FunctionalGroup maintain References to the same instance of the Parameter.

Table 3 shows Parameters that will be organized by the Configuration FunctionalGroup.

Table 3 – AnalyserDevice Configuration Parameters

BrowseName

Description

VariableType

Optional/

Mandatory

ConfigData

Optional representation of the AnalyserDevice configuration

FileType

O

ConfigData is an optional representation of the AnalyserDevice configuration. When it is present, it may be used to read and write the AnalyserDevice configuration in chunks. The main purpose of this element is to provide a way to read and write configuration that are larger than the maximum size of the OPC UA message. Reading and writing configuration through this object are subject to the same state machine constraints as GetConfiguration and SetConfiguration.

To maintain configuration consistency, the server must grant read and write access to one and only one user at any given time.

The steps to update the configuration through the ConfigData object are:

  1. When SetConfiguration is allowed based on the state machine states, a single user may cal “open” the ConfigData. If an “Open” is attempted when not permitted, the server shall return “Bad_InvalidState”.
  2. The user updates the configuration by calling repeatitively and in increasing order “write” method on ConfigData. If the “Write” are not sequential, the server shall return “Bad_InvalidArgument”.
  3. When the whole configuration has been written, the user calls “close” method on the ConfigData.
  4. The server is responsible to verify the configuration. If an error occurs during the verification, the server shall return “Bad_InvalidArgument” on the “Close”. In case of error, the previous configuration is restored.
  5. The server commits the new configuration. . If an error occurs during the commit, the server shall return “Bad_InvalidArgument” on the “Close”. In case of error, the previous configuration is restored.

Table 4 shows Parameters that will be organized by the Status FunctionalGroup. All Parameters organized by this FunctionalGroup shall be read-only.

Table 4 – AnalyserDevice Status Parameters

BrowseName

Description

VariableType

Optional/

Mandatory

DiagnosticStatus

General health status of the analyser

DataItemType

DataType=DeviceHealthEnumeration

M

The DiagnosticStatus Parameter reflects the general health of analyser. It is defined as a Variable of DataItemType type and its possible values are defined by [OPC 10000-100] enumerationDeviceHealthEnumeration. Its value must be the same as DeviceType.DeviceHealth Property.

Table 5 shows Parameters that will be organized by the FactorySettings FunctionalGroup component of the AnalyserDeviceType.

Table 5 – AnalyserDevice FactorySettings Parameters

BrowseName

Description

VariableType

Optional/

Mandatory

The SerialNumber, Manufacturer, Model, DeviceManual, DeviceRevision, SoftwareRevision and the HardwareRevision Properties are defined on DeviceType and as such available on AnalyserDeviceType. As a general rule, they are read-only properties. However, they can be updated to reflect changes made to the analyser configuration e.g. upgrading the firmware.

DeviceRevision Property will be used to indicate an overall change in the analyser. It is mandatory and shall be updated automatically or manually each time the analyser configuration is altered. It is the customer’s QA responsibility to determine if this particular change affects the validation of the analyser.

The RevisionCounter Property is an incremental counter indicating the number of times the semi-static data within the AnalyserDevice has been modified.

If the analytical device represented by an AnalyserDevice Object is unable to publish a value for a mandatory Parameter defined in Table 5, the Analyser Server should provide a way to manually enter that value.