`ASSET_COUNT` DataItem not auto-rendered as `representation="DATA_SET"`; stream observation named `AssetCount` instead of `AssetCountDataSet`

[ottobolyos]

Summary

Per MTConnect v2.x, the ASSET_COUNT DataItem is defined as a DATA_SET-representation observation (a map of asset-type → count). cppagent automatically materialises ASSET_COUNT DataItems with representation="DATA_SET" on Probe and as AssetCountDataSet observations in the stream. MTConnect.NET-Applications-Agents v6.9.0 emits ASSET_COUNT as a plain EVENT with no representation attribute, and its stream observation is named AssetCount (scalar) instead of AssetCountDataSet. This diverges from the cppagent reference and silently drops the asset-type → count map structure the spec defines.

Environment

• MTConnect.NET-Applications-Agents at v6.9.0 (official Docker image trakhound/mtconnect.net-agent:6.9.0, published 2025-10-16 — binary-equivalent to v6.9.0.2).
• Broker: eclipse-mosquitto:2.0.22.
• Comparison agent: mtconnect/agent:latest = cppagent v2.7.0.7 with JsonVersion = 2, SchemaVersion = 2.7.
• Format ID: JSON-CPPAGENT-MQTT (the bug is in the auto-generator, so XML Probe shows the same defect regardless of format).

Reproduction

Minimum rig — agent with a Device but no explicit ASSET_COUNT DataItem in the Devices.xml (the library auto-generates one when assetBufferSize > 0):

# applications/MTConnect-Agent/appsettings.yaml
devices: devices/devices.xml
assetBufferSize: 1000
modules:
- mqtt-relay:
    server: localhost
    port: 1883
    documentFormat: JSON-CPPAGENT-MQTT
    topicPrefix: MTConnect/Document
    topicStructure: Document

devices/devices.xml — any Device with at least one child component. The ASSET_COUNT DataItem is injected by the library, not declared by the operator.

Subscribe and inspect Probe + Current:

mosquitto_sub -h localhost -t 'MTConnect/Document/Probe/<uuid>' -C 1 \
  | jq '.Device.DataItems.DataItem[] | select(.type=="ASSET_COUNT")'
mosquitto_sub -h localhost -t 'MTConnect/Document/Current/<uuid>' -C 1 \
  | jq '.MTConnectStreams.Streams.DeviceStream[0].ComponentStream[0].Events'

Observed — MT.NET Probe

Device's auto-generated ASSET_COUNT DataItem:

{
  "category": "EVENT",
  "id": "TestDevice_assetCount",
  "type": "ASSET_COUNT",
  "name": "assetCount"
}

No representation attribute. No DATA_SET semantic.

Observed — MT.NET Current Events

"Events": {
  "AssetCount": [
    { "value": "UNAVAILABLE", "dataItemId": "TestDevice_assetCount", "name": "assetCount", "timestamp": "...", "sequence": 15 }
  ]
}

Plain AssetCount event with a scalar value.

Expected — cppagent JSON v2 reference

Run mtconnect/agent:latest with the same Devices.xml, same MqttService sink. Capture equivalent topics:

cppagent Probe — DataItem:

{
  "category": "EVENT",
  "id": "TestDevice_asset_count",
  "representation": "DATA_SET",
  "type": "ASSET_COUNT"
}

cppagent Current — Event:

"Events": {
  "AssetCountDataSet": [
    { "value": "UNAVAILABLE", "count": 0, "dataItemId": "TestDevice_asset_count", "timestamp": "...", "sequence": 20 }
  ]
}

AssetCountDataSet with the count property — the data-set structure.

Evidence files: probe.json + current.json (MT.NET) vs cppagent-probe.json + cppagent-current.json (cppagent).

Authority

• Prose standard, Part 4 — Assets Information Model: ASSET_COUNT is defined as a DATA_SET-representation EVENT (per-asset-type counts).
• XMI: MTConnectSysMLModel.xml carries the ASSET_COUNT DataItem type with the DATA_SET representation classification.
• XSD: MTConnectStreams_2.7.xsd — DataSetValueType + AssetCountDataSet element typing.
• cppagent reference: auto-injects representation="DATA_SET" on the Device's ASSET_COUNT DataItem and renders the stream observation as AssetCountDataSet.

The auto-injection of this DataItem (when an agent manages an asset buffer) must preserve the DATA_SET representation. A plain EVENT with a scalar UNAVAILABLE / text value loses the asset-type → count mapping.

Root cause — library source

Likely in whichever module auto-generates the Device's asset-related DataItems when assetBufferSize > 0 is configured. Search targets:

• libraries/MTConnect.NET-Common/Agents/MTConnectAgent.cs
• libraries/MTConnect.NET-Common/Devices/DataItem.cs
• The AssetChanged / AssetRemoved / AssetCount auto-DataItem construction path, wherever it lives (the matching pattern is the auto-generated per-Device asset-event DataItems whose ids are <deviceId>_assetCount / <deviceId>_assetChanged etc.).

The fix is to set representation = DATA_SET on the auto-injected ASSET_COUNT DataItem and wire the stream-observation serialiser to emit AssetCountDataSet instead of AssetCount.

Impact

• Consumers coded against the cppagent JSON v2 output model AssetCountDataSet with per-type counts. MT.NET's AssetCount never matches that shape; consumers either fall back to a scalar integer or skip the data entirely.
• Asset-tracking pipelines that rely on per-type counts (e.g. CuttingTool count vs QIF count) cannot be built on MT.NET data without additional compute upstream.
• Violates the spec's v2.x representation semantic for this specific DataItem type.

Suggested fix

1. When auto-creating the Device's ASSET_COUNT DataItem, set Representation = DataItemRepresentation.DATA_SET.
2. Rename the stream observation class emission from AssetCount to AssetCountDataSet.
3. Populate the count sub-property per asset-type key as cppagent does.
4. Verify the Agent Device's asset-count data item uses the same treatment (cppagent does).
5. Add a test asserting the auto-generated Probe contains representation="DATA_SET" on every ASSET_COUNT DataItem + the stream contains an AssetCountDataSet observation.

Stability across MTConnect versions

ASSET_COUNT has been a DATA_SET-representation EVENT since v1.5 (when the DATA_SET representation type was introduced). Unchanged through v2.7. Fix is version-agnostic.

Related issues

• Organizers._systems list is stale — causes asymmetric <Systems> auto-nesting in Device.AddComponent() #134 — Organizers._systems list is stale — another hand-maintained library registry that diverges from the XSD-driven auto-generated class set. Both smell like the same class of issue: hand-maintained tables drifting from auto-generated code. If a regeneration discipline is introduced (fix proposal in issue Organizers._systems list is stale — causes asymmetric <Systems> auto-nesting in Device.AddComponent() #134), this defect's fix pathway benefits from the same tooling.
• Add support for MTConnect Standard v2.6 and v2.7 #133 — Add MTConnect v2.6 + v2.7 support — the uplift may add new DATA_SET-representation DataItems; the auto-generator fix here should generalise so it picks up new types without per-type case-coding.

References

• cppagent reference output: test_package/json_printer_stream_test.cpp (see AssetChanged + AssetRemoved event treatment and the DATA_SET handling nearby).
• MTConnect prose standard Part 4 — Assets Information Model: https://www.mtconnect.org/standard-download20181.
• XSD: MTConnectStreams_2.7.xsd — DataSetValueType + AssetCountDataSet typing.
• Evidence captures: probe.json, current.json, cppagent-probe.json, cppagent-current.json.