Is the the Crimson Sparkplug B implementation compliant with the spec?

16 Jun 2026

Here are the results of the compliance testing. 

 

APPLICABLE PRODUCTS

All Crimson products with Sparkplug B capability

 

Sparkplug B v3.0 Findings — Brief Details

Red Lion Crimson 3.2 (DA70)

 

ID Finding Detail
F-001 bdSeq (birth-death sequence number) should increase by 1 increment at a time, but is jumping as if sourced from elsewhere. No observed operational consequence for known host applications.
F-002 Primary Host STATE not honored (application-layer failover)

Applicable only to deployments using application-layer Primary Host coordination (e.g., active/standby SCADA hosts on separate brokers, where standby promotes itself via STATE messages without broker change).

 

Crimson handles broker-redundancy failover correctly at the network layer (broker process crash, TCP loss, keepalive timeout).

F-003 Incomplete graceful disconnect — no self-published NDEATH Crimson does not seem to perform the spec-mandated self-publish NDEATH-before-DISCONNECT handshake on intentional shutdown. NDEATH still reaches subscribers via the broker's Will-firing mechanism which is the most common path for NDEATH delivery in any Sparkplug deployment anyway.
F-004 NDATA QoS dropdown controls publish QoS Crimson's QoS dropdown applies to PUBLISH operations. With QoS=0 selected, NDATA is published spec-compliant. With QoS=1 selected, NDATA fails the TCK assertion but provides MQTT-level delivery acknowledgment. This is a defensible engineering tradeoff exposed via user configuration, not a Crimson defect.
F-005 Will Message QoS hardcoded at 0 Will Message QoS cannot be configured to 1 regardless of dropdown selection. NDEATH delivery is at risk during broker-restart or network-degradation scenarios where QoS 0 messages may be dropped.
F-006 Primary Host STATE wait not implemented before BIRTH Same applicability as F-002; only relevant if the customer configures a Primary Host ID. In such cases, Crimson may publish BIRTH before the host is ready. Recovery typically occurs via host-issued rebirth.
F-007 Datatype field included in NDATA payloads Spec recommendation (SHOULD NOT), not a hard requirement. Pure bandwidth overhead — a few bytes per metric per publish. All host applications correctly ignore the redundant field. Negligible impact at any deployment scale.
G-001 No Sparkplug Templates support Spec-optional feature. Inapplicable if the deployment uses primitive metric types only. Inability to publish Template-typed metrics limits some host integrations that require UDT-style structured data.
G-002 No Sparkplug Datasets support Spec-optional feature. Inapplicable if the deployment does not require tabular metric data.
G-003 No Device-level hierarchy (Edge Node only) Spec-compliant flat structure. Loses Device-level lifecycle tracking and per-device command targeting in host applications. Acceptable simplification for most deployments; matters only if the customer's host application uses Device-level features.

 

ADDITIONAL INFO

Crimson Cloud Connectors: Sparkplug