Additions to SpC Roadmap

[RickBullotta]

Not sure the best way to get these added to the roadmap, so here goes the list:

• Expand Sparkplug Aware MQTT Server definition to include automatic expansion of DATA and BIRTH metric content into individual topics
• Expand Sparkplug Aware MQTT Server definition to a REST API for querying metadata
• Expand Sparkplug Aware MQTT Server definition to a REST API for querying most recent data and for connectionless publishing of DATA and BIRTH messages
• Add strong data typing for inputs and output to commands as part of BIRTH or METADATA
• Implement a reliable request/response mechanism so that commands can return data, error codes, or other result content
• Consider eliminating group/node/edge IDs altogether and allowing a flexible hiearchy using namespace/message_type/any_hiearchy (note that this would not break existing apps given a new namespace for the next version of SpB)
• Add new primitive types for location and generic JSON
• Separate data and metadata in BIRTH messages and leverage the MQTT retain flag to optimize/minimize load on edge nodes and to enable application tooling to discover metadata even if an edge node is offline
• Clarify which components of a Sparkplug metric are mandatory and which are optional

[russwaddell]

These are clear. Most of the bullets seem worthy of their own issue, to be labeled "future release" or "current release" for tracking, assignment, comment or review if necessary, and bundling into Projects or Milestones if appropriate. Prioritization would also be helpful if these aren't all certain to go into the immediate next release.

[russwaddell]

These three seem straightforward and useful incremental enhancements in line with typical user requirements.

• Expand Sparkplug Aware MQTT Server definition to include automatic expansion of DATA and BIRTH metric content into individual topics
• Expand Sparkplug Aware MQTT Server definition to a REST API for querying metadata
• Expand Sparkplug Aware MQTT Server definition to a REST API for querying most recent data and for connectionless publishing of DATA and BIRTH messages

This should be routine unless there's some demonstrated case where strong typing breaks something.

• Add strong data typing for inputs and output to commands as part of BIRTH or METADATA

Significant project to undertake? Needs more detailed fix(es) proposed.

• Implement a reliable request/response mechanism so that commands can return data, error codes, or other result content

Substantial reworking of the data model needs more details on how, why, use cases, deficiencies in existing model, comparison against models alongside which SpB is often deployed. If group/node/edge is an outlier compared to other commonly used modeling approaches, the rework is well worthwhile. If replacing group/node/edge simply reworks to harmonize with another model that's not currently or likely to be more widespread, this seems like potentially wasted effort.

• Consider eliminating group/node/edge IDs altogether and allowing a flexible hiearchy using namespace/message_type/any_hiearchy (note that this would not break existing apps given a new namespace for the next version of SpB)

These seem like useful evolutionary fixes.

• Add new primitive types for location and generic JSON
• Separate data and metadata in BIRTH messages and leverage the MQTT retain flag to optimize/minimize load on edge nodes and to enable application tooling to discover metadata even if an edge node is offline
• Clarify which components of a Sparkplug metric are mandatory and which are optional

[JeremyTheocharis]

Hi,

Adding to @RickBullotta point regarding flexible topic hierarchies. First some background to understand where I am coming from.

I am Jeremy, Co-Founder and CTO of the United Manufacturing Hub (https://github.com/united-manufacturing-hub/united-manufacturing-hub). We generally love the idea of having a standard for MQTT topics, but the current SparkplugB standard is not usable for us. The current standard is quite focused on the producer device group/node/edge which fits for a lot of IoT use-cases, but not for manufacturing, where our customers and users prefer to sort their data into a ISA95 compatible equipment model. There are not really a lot of standards out there in manufacturing that are globally accepted, but the ISA95 one actually is.

This is the reason why we have not adopted SparkplugB yet and instead are doing our own topic structure standard (see our proposal here: https://learn.umh.app/proposal-new-datamodel-for-the-united-manufacturing-hub/)

We would be happy with anything that would allow us to to sort devices into the ISA95 equipment model, maybe something like <enterprise>/<site>/<area>/<productionLine>/<workCell>/<deviceID>/<one-or-many other topics that can be adjusted based on the use-case>.

In the case of UMH, we would then use that along the lines of <enterprise>/<site>/<area>/<productionLine>/<workCell>/<deviceID>/<UMH-datamodel-version>/<tagGroup>/<tag>

However, this model will likely only work in manufacturing and is not applicable to other IoT use-cases. Maybe append a in front of it to allow different models? one could be the current one, one could be ISA95.

[JeremyTheocharis]

Just added a potentially sparkplug-b compatible model to our proposed datamodel (https://learn.umh.app/proposal-new-datamodel-for-the-united-manufacturing-hub/#potentially-sparkplugb-compatible):

• Allow flexible number of topic levels for modeling physical world tree structures
• The last element of the physical tree structure is always the device ID
• the message type is not indicated by the position in the topic structure, but instead it is the only element in the topic starting with an underscore, which improves automated processing
• after the message type, there is again an unlimited amount of possible topics, so that data can get modelled better. if you have a device sending really a lot of data, not every consumer wants to go through all of it, some only want to subscribe to a very specific type

[RickBullotta]

Whatever you need @wes-johnson, let me know. Happy to help flesh out the details and specifics, write some specs or code, etc...