This section helps define, initialise and position Parameters in the Analyser Server address space.

A configuration parameter defining one of the settings of the hardware of the analyser.

A configuration parameter defining one of the settings of the behaviour of the analyser.

A status parameter exposing the state / status of the hardware of the analyser i.e. power supply temperature.

A status parameter exposing the state / status of the behaviour of the analyser i.e. which Stream is active?

A configuration parameter defining one of the settings of the hardware of the analyser for the current acquisition or the one to be started i.e. gain of a detector.

A configuration parameter defining one of the settings of the behaviour of the analyser for the current acquisition or the one to be started i.e.: duration of the acquisition.

A status parameter exposing the state / status of the hardware of the analyser for the current acquisition or the one to be started i.e. detector gain too high.

A status parameter exposing the state / status of the behaviour of the analyser for the current acquisition or the one to be started i.e. % done of the ongoing acquisition.

A result parameter exposing results generated by the analyser or derived from it i.e. absorbance spectrum, particle size distribution, concentration.

A ChemometricModel parameter exposing the model definition used to convert ScaledData to derived properties e.g. concentration derived from the absorbance spectrum.

An input I/O from a PLC indicating when the sample is ready.

An output I/O telling the sampling system that it can now grab a sample from the process.

This question is very important because even if you can expose a Parameter, this does not mean that you should do so. Providing too many Parameters will create a complex address space for no good reason. The following questions should be asked:

Who will use this Parameter?

The end users like the acquisition results.

The configuration tools like the acquisition configuration Parameters.

The analyser vendor production people may like setting the serial number.

The service personnel may like internal diagnostics.

R&D people may like some obscure servo loop control Parameter

Which client system component will record the Parameter?

The plant DCS likes the concentration

The Historian likes absorbance spectrum and concentration

The Asset management likes expected remaining life of IR source or laser.

This section answers some common questions regarding the types of Parameters.

All Parameters should be derived from DataItemType

Try to use types defined in the ADI specification, they have been defined specifically for analyser data.

Try to use types defined in DI specification, they have been defined to standardize device Parameters.

Try to use types defined in OPC UA specification

If none of the predefined types are appropriate, derive a new type from one of the existing ones. This approach allows generic clients to handle them more easily.

Use standard Properties when appropriate. This allows generic clients to handle them more easily.

Define EngineeringUnits where appropriate. This is very important from a user perspective to know what he/she is dealing with.

Set Description and Definition Attributes to allow Analyser Server browsing and to help generic clients understand what they are looking at.

Set EURange and InstrumentRange where appropriate to help generic clients better interpret the results.

For Boolean Parameters, consider using TwoStateDiscreteType to provide useful names for True and False values.

This section aims to provide help in deciding what values should be assigned to Parameter Attributes and standard Properties.

BrowseName

English name of the Parameter, which is used for programmatic purpose only. It is never shown to the user. You should avoid using “_” character because it may clash with some development tools.

AccessLevel

Definethis Attribute if this Parameter’s value is Read-Only or Read/Write independent of the user access rights. In general, this value is constant except if it depends of the state of the analyser.

UserAccessLevel

Define this Attribute if this Parameter’s value is ReadOnly or Read/Write based on the user access rights of the user who is trying to access it. The server shall update this attribute at runtime based on who is logged in.

WriteMask

Define this Attribute if this Parameter’s attributes are ReadOnly or Read/Write independent of the user access rights. In general, this value is constant except if it depends of the state of the analyser. If the server can always provide a good value, there is no need to bother the user with it.

UserWriteMaskDefine this Attribute if this Parameter’s attributes are ReadOnly or Read/Write based on the user access rights of the user who is trying to access it. The server shall update this Attribute at runtime based on who is logged in. If the server can always provide a good value, there is no need to bother the user with it.

MinimalSamplingInterval

Define at which rate the server monitors / updates the value of this Parameter.

If the server never updates this Parameter by itself, there is no need to define MinimalSamplingInterval.

If the server updates this Parameter, MinimalSamplingInterval should be initialized with a value based on the rate at which the analyzer will update the Parameter.

Do you want to allow the user to set this value or let the server decide? If yes, WriteMask and UserWriteMask shall be set. In any case, a reasonable initial value shall be provided.

This section aims to provide a set of guidelines for deciding in which FunctionalGroup a given Parameter should be located:

If it is common to all AnalyserChannels, it should be at the AnalyserDevice level.

If it is common to all Streams of a given AnalyserChannel, it should be at the AnalyserChannel level.

If it is different for each Stream, it shall be at the Stream level.

If it is a configuration Parameter that does not change from acquisition to acquisition, it should be in the Configuration FunctionalGroup.

If it is a Parameter that is not intended to be modified by the user, is should be in the FactorySettings e.g. SpectralRange of the analyzer, which it is defined at the factory.

If the Parameter changes for each acquisition, it should be in AcquisitionSettings e.g. DetectorGain.

If the Parameter describes the setting of the current acquisition or the one to be started, it should be in AcquisitionSettings e.g. NumberOfScansToBeDone.

If the Parameter is an input from an external system like a PLC, and used to control the acquisition cycle, it should be in AcquisitionSettings e.g. AcquisitionTrigger.

If a status Parameter is independent of the acquisition in progress, it should be in a Status FunctionalGroup e.g. DiagnosticStatus.

If a status Parameter changes during the acquisition, it should be in the AcquisitionStatus FunctionalGroup e.g. Progress.

If the Parameter is updated at the end of each acquisition, it should be in AcquisitionData e.g. ScaledData.

If the Parameter is derived from a Parameter in AcquisitionData, it should also be in AcquisitionData e.g. the concentration derived from the absorbance spectrum.

ADI specification does not define when the Parameters in the AcquisitionSettings FunctionalGroup should be changed. As a general rule they should not change after the start of acquisition except for a case involving an acquisition trigger.

It is a good practice to define the validation rules for each Parameter. For example:

Valid range

List of possible values

Cross-Parameter validation rules e.g. MinFrequency shall be smaller than MaxFrequency

Cross-FunctionalGroup validation rules e.g. if the analyzer is in MidIR configuration, MaxFrequency shall be smaller the 7899cm-1.

A consistent way of defining these validating rules is important for the ability to write generic ADI tools.