Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[sparkplug-dev] Sparkplug Spec Project Team Meeting - Meeting Notes - 23 March 2021

Hi all,

 

Please find the meeting notes from yesterday’s Sparkplug Spec Project Team Meeting below.

 

Sparkplug Spec Project Team Meeting - Meeting Notes - 23 March 2021

  • Attendees (9)
    • Chad Kienle
    • Dominik Obermaier
    • Frederic Desbiens
    • Ian Craggs
    • Ilya Binshtok
    • Josh Wolf
    • Nathan Davenport
    • Travis Cox
    • Wes Johnson
  • Terminology
    • Metric: define it in the terminology section.
    • Host: initial proposal was to remove and replace with Application. CL guys indicate that they prefer ‘Host’ over ‘Application’ or ‘Host Application’. Consensus seems to be that Host is the best term we have now, but if we can come up with something better it would be considered by the group.
    • How to properly test PrimaryHost commands (DCMD, NCMD) via the TCK?
      • How to best enumerate and then have the PrimaryHost exercise edge supported commands?
        • Edge can self-describe all of its commands so the TCK can signal to the PrimaryHost which commands should be sent when.
  • Can Sparkplug spec sections covering payloads by message type and message content be combined? Ian will work up an example to share with the group.
  • Supporting persistent connections: Should we explicitly disallow persistence within the context of Sparkplug?
    • There are possible scenarios out there that require persistent connections.
    • Seq Num / in-order delivery are problematic when using persistent connections.
    • Host applications need be resilient to duplicate and out-of-order messages.
      • Tahu could and should support this.
  • Supporting QoS 1:
    • The only Sparkplug message on QoS 1 is the STATE message.
    • Historical data could be sent on QoS 1. One doesn’t need to care about the order of changes at the Edge for historical data.
    • Proposal: Hold off on QoS 1 support for now. To be revisited later.
  • Data Types: Not enforced in a normative way.
    • Proposal: Make it part of the protobuf definition and normative.
  • Metric Quality: Statements around Quality should be normative
    • Quality is referenced throughout the spec in different sections.
    • OPCUA has many quality codes.
    • Ignition uses different quality codes.
    • Can include additional Quality property to further describe the Quality, but it will not be normative.
    • Proposal: Create Quality enumeration for Good, Bad, Stale

 

Thanks,

Nathan

Back to the top