Ability to Explicitly Define Cloud Data Type for Modbus TCP Data in Edge Data Store

Description / Business Context

I am currently using AVEVA Edge Data Store with the Modbus TCP interface to collect data from industrial devices and forward it to CONNECT Data Services (CDS).

For each Modbus data selection, the Modbus configuration is done through:

• The Modbus register definition (address, size, encoding)

• The dataTypeCode property, which makes sense at the Modbus protocol level

However, I am facing a limitation regarding how the data is typed once it is ingested into CDS.

Current Behavior

When data is sent from Edge Data Store to CDS, the resulting cloud data type is derived directly from the Modbus dataTypeCode, resulting in types such as:

• TimeIndexed.UINT16

• TimeIndexed.INT32

From my point of view, this does not make sense at the cloud level:

• At the Modbus layer, I fully agree that registers, word size, and encoding matter.

• At the cloud level, the data is transported as JSON, and ultimately represents either:

  • a number

  • or a string

The low-level Modbus encoding should not dictate the semantic data type exposed in CDS.

Conversion Properties Inconsistency

Additionally, when using:

• conversionFactor

• conversionOffset

The data type is automatically converted to TimeIndexed.Single, as stated in the official documentation.

This behavior implicitly proves that:

• Cloud-side data typing is already decoupled from the Modbus dataTypeCode

• The dataTypeCode is effectively used only as an intermediate step

Current Workaround and Its Limitations

Today, the only way to control the cloud data type is to configure:

conversionFactor = 1 or ConvertionOffset = 0

This workaround:

• Has no physical or functional meaning

• Breaks traceability and documentation of intent

• Can easily introduce errors if forgotten or misunderstood

• Is not acceptable for long-term, maintainable configurations

Requested Improvement

I would like to request the addition of a new configuration property on Modbus data selections, for example:

• cloudDataType

• or outputDataType

This property would allow users to explicitly force the desired cloud data type, independently from the Modbus register encoding, for example:

• TimeIndexed.Double

• TimeIndexed.Single

• TimeIndexed.Int32

• TimeIndexed.String

This would:

• Clearly separate protocol-level concerns from cloud semantic typing

• Remove the need for artificial conversion factors

• Improve configuration clarity, robustness, and auditability

• Align better with how data is actually consumed in CDS and downstream analytics

Conclusion

In summary, the Modbus dataTypeCode should remain a low-level transport concern, while the cloud data type should be explicitly configurable, as it represents the semantic meaning of the data.

This enhancement would significantly improve data modeling quality and reduce configuration-related errors.

Thank you for considering this request.