Milestone
- 3.0.0.0: SparkplugB Peer-2-peer Edge Node
- 9.9.9.9: Backlog
- 2.0.0.0: Example
- 2.0.0.0: Device
- 2.0.0.0: TLS
- 2.0.0.0: Protobufs full
- 3.0.0.0 Full Feature Product (FFP)
- 2.0.0.0 Standard Feature Product (SFP)
- 3.0.0.0: High Availability
- 2.0.0.0: Edge
- 3.0.0.0 Historical Values
Searches
Help
#102 Paylaod: refactor
At the moment, there is a relatively complex structure for adding metrics and its subobjects to a Device, and then later to a payload. You have to add all of the pools of objects, and pass these between the FB's.
Some issues:
1. The calls for each Object are quite a lot of lines of code, with up to 10 different pools needed.
2. Some people might accidentally add a metric to two different owners.
So the proposal is for each object to have an interface to register its children. The children then use this interface as an input, and register themselves.
Note that a Metric may have two owners, a Device and a Payload.
Payload Implements IPaylaod
Metric.itfOwner := Payload;
Or myMetric : Metric := (itfOwner := Paylaod);
or myMetric(itfOwner := Payload);
Also take into consideration that the SCADA node might actually want the freedom of Pool Objects, ie it might still want MetricsPool. This might mean making two seperate calls available.
Yeah, but since CODESYS3 does not support method overloads, we still need to provide some sort mechanism (trick) that will support these parallel calls. I am thinking about a base Metric class with two separate inherited implementations. Liskov polymorphism principle says these are interchangeable.
Get Outlook for Androidhttps://aka.ms/ghei36
From: tickets@mqttsparkplugb.prj.forge.codesys.com tickets@mqttsparkplugb.prj.forge.codesys.com on behalf of i-campbell forge@codesys.com
Sent: Friday, December 18, 2020 2:12:42 PM
To: Ticket #102: Paylaod: refactor 102@tickets.mqttsparkplugb.prj.forge.codesys.com
Subject: [mqttsparkplugb:tickets] #102 Paylaod: refactor
[tickets:#102] Paylaod: refactor
Status: open
Milestone: 2.0.0.0: Protobufs full
Labels: Payload Improvement
Created: Fri Dec 18, 2020 01:12 PM UTC by i-campbell
Last Updated: Fri Dec 18, 2020 01:12 PM UTC
Owner: i-campbell
At the moment, there is a relatively complex structure for adding metrics and its subobjects to a Device, and then later to a payload. You have to add all of the pools of objects, and pass these between the FB's.
Some issues:
1. The calls for each Object are quite a lot of lines of code, with up to 10 different pools needed.
2. Some people might accidentally add a metric to two different owners.
So the proposal is for each object to have an interface to register its children. The children then use this interface as an input, and register themselves.
Note that a Metric may have two owners, a Device and a Payload.
Payload Implements IPaylaod
Metric.itfOwner := Payload;
Or myMetric : Metric := (itfOwner := Paylaod);
or myMetric(itfOwner := Payload);
Also take into consideration that the SCADA node might actually want the freedom of Pool Objects, ie it might still want MetricsPool. This might mean making two seperate calls available.
Sent from forge.codesys.com because you indicated interest in https://forge.codesys.com/prj/mqttsparkplugb/tickets/102/
To unsubscribe from further messages, please visit https://forge.codesys.com/auth/subscriptions/
Related
Tickets:
#102So there are actually two distinct "Metrics":
The metric that resides in a payload, ie what has been transmitted on the wire.
The representation of the data in the metric, ie every bit of information about the metric.
For this reason, I think new FB's should be made. The current are called FB_PayloadMetric, FB_PayloadTemplate etc.
There should be new FB's created, named FB_Metric, FB_Template etc. These can be built hierarchically using the itf's, and the metric will ultimately register itself to an FB_EoN.
An FB_Metric will contain a hidden FB_PayloadMetric, which will be donated to the FB_EoN encoder and FB_EoN decoder. Actually, this is exactly how the FB_SparkplugBoolean etc functions now. This should be extended to the other objects. possibly the FB_SparkplugBoolean through FB_SparkplugUUID could be combined into an FB_Metric. This idea needs to extend to the other Payload objects, so FB_Template contains a hidden FB_PayloadTemplate, etc.
Rehashing: 2 types of data representation;
1) FB_Metric: The metric that resides in a payload, ie what has been transmitted on the wire,
2) FB_Template: The representation of the data in the metric, ie every bit of information about the metric.
These two objects should form the basis for FB_PayloadMetric and FB_PayloadTemplate.
FB_Metric will encapsulate (composition) a private FB_PayloadMetric instance which will be passed to the FB_EoN encoder and FB_EoN decoder.
This idea is to the extended with the other Payload objects, so FB_Template encapsulate a private FB_PayloadTemplate instance, etc.
Implemented and demonstrated