All fields of each Inputs and Outputs arguments must be filled, the user relies on them to discover the model information.

The vendor specific predictor return code should be returned using the DiagnosticInfo.SymbolicId.

The role of the MVAPredict method is really to allow a client to predict against the target MVAModel. The MVAPredict method:

• May be called at any time after the AnalyserDeviceStateMachine reaches the Operating state if the MVAModels are located in the ChemometricModelSettings located at AnalyserDevce level. Potential conflicts with AnalyserChannel operations like loading configuration shall be handled by the implementer following the rules describe below.
• May be called at any time after the AnalyserChannel reaches the Idle state, during Idle, Starting and Execute state, if the MVAModel are attached to a given Stream. This will avoid potential conflicts with AnalyserChannel operations like loading configuration.
• May be called more than once concurrently by the same client.
• May be called concurrently by more than one client at the same time.
• Shall produce output MVAOutputParameters that may be used directly without having to do intermediate mathematic or method call.

This is the server responsibility to deal with multi-threading issues. The client side shall never have to deal with these issues. It is perfectly legal to serialize all requests on a given model and even at the Predictor level, as long as the client does not have to be aware of it.

The MVAPredict method Executable and UserExecutable attributes shall be used to signal when MVAPredict may be called or not.

The implementer may allow some MVAModels to be updated directly by writing the Value attribute of the MVAModel. For example, let say that the Value attribute is an exact copy of the model file, the client application only has to use the OPC UA Write service to transfer the model directly to the UA server. If the model is too large to fit in a single UA message, the model may be transferred in chunk using the NumericRange parameter of the Write service.

All ADI time management rules apply:

• All output parameters shall have the same timestamp as the main parameter, the one defined by MainDataIndex.

To avoid unexpected behaviours, the following rules must be applied when models are updated with the Write service:

• ADI server shall verify the integrity / validity of the Model ByteString and returned an error code if not correct without modifying anything in the actual server configuration. If the model is transferred in chunks, the final verification shall be done on the write of the last chunk.
• ADI address shall be updated to reflect the new model.
• ADI server shall handle multi-threading issues where a GetConfiguration, SetConfiguration GetConfigDataDigest and others, while updating the models. This may be done by serializing the requests as long as the client does not have to be aware of it.
• ADI server shall return the vendor specific predictor return code using the DiagnosticInfo.SymbolicId.

If the MVAModel is used to evaluate values appearing in any AcquisitionData FunctionalGroup, the following supplemental rules must also be applied:

• MVAModel objects may only be updated when the AnalyserChannel is in Stop state.
• ADI server shall update/change the Configuration and the ConfigDataDigest if the new model is different from the previous one and only in that case.