#59 Implement a "SparkplugB Primary Node " for use in a CODESYS runtime

0.0.0.0: SparkplugB Peer-2-peer Edge Node
accepted
i-campbell
None
2022-11-05
2020-09-19
aliazzz
No

An MQTT based SCADA system is unique in that the Host node is NOT responsible for establishing and maintaining connections to the devices as is the case in most existing legacy poll/response device protocols. With an MQTT based architecture, both the Host application as well as the devices establish MQTT Sessions with a central MQTT Server(s). This is the desired functionality as it provides the necessary decoupling from any one application and any given device. Additional MQTT clients can connect and subscribe to any of the real time data without impacting the primary SCADA Host application(s).

The SparkplugB Primary Node (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit it's functionality of can be somewhat limited when compared to a PC based implementation. The implementation of a Primary Node within a PLC runtime however can also have advantages over a traditional PC based implementation. This is why we have chosen to CUT LOOSE the SCADA part and just implement the Primary Node itself.

The Primary Node we envision just provides (exposes) all incoming data centrally and has the possibility to issue Edge Of Network Node- or Device Commands. Setup of a secure true distributed brand independent control system with this type of setup is made available! As a bonus this setup allows for ANY modern SCADA system you like on top of the CODESYS Primary Node i.e. "Bring your own SCADA" (BYOS).

In order to implement a "Primary Node", the implementation must follow all rules/graphs as outlined in paragraph 8.1 through 8.4

By definition we achieved this thiugh we still need icing onnthe cake.

Related

Tickets: #3

Discussion

  • aliazzz

    aliazzz - 2020-09-19
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,6 +1,5 @@
 An MQTT based SCADA system is unique in that the Host node is NOT responsible for establishing and maintaining connections to the devices as is the case in most existing legacy poll/response device protocols. With an MQTT based architecture, both the Host application as well as the devices establish MQTT Sessions with a central MQTT Server(s). This is the desired functionality as it provides the necessary decoupling from any one application and any given device. Additional MQTT clients can connect and subscribe to any of the real time data without impacting the primary SCADA Host application(s). 

-The Primary Application (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit  it's functionality of can be somewhat more limited due to the nature of the limits of the hardware.
-The implementation of a "Primary Application" within a PLC runtime however can also have advantages over a traditional PC based SCADA.
+The Primary Application (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit it's functionality of can be somewhat more limited when compared to a PC based implementation. The implementation of a "Primary Application" within a PLC runtime however can also have advantages over a traditional PC based implementation.

-In order to implement a "Primary Application", the implementation must follow all rules/graphs as stated in paragraph **8.1 through 8.4**
+In order to implement a "Primary Application", the implementation must follow all rules/graphs as stated in **paragraph 8.1 through 8.4**
     

  • aliazzz

    aliazzz - 2020-09-19
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -2,4 +2,4 @@

 The Primary Application (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit it's functionality of can be somewhat more limited when compared to a PC based implementation. The implementation of a "Primary Application" within a PLC runtime however can also have advantages over a traditional PC based implementation.

-In order to implement a "Primary Application", the implementation must follow all rules/graphs as stated in **paragraph 8.1 through 8.4**
+In order to implement a "Primary Application", the implementation must follow all rules/graphs as outlined in **paragraph 8.1 through 8.4**
     

  • hermsen

    hermsen - 2020-12-20
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,5 +1,7 @@
 An MQTT based SCADA system is unique in that the Host node is NOT responsible for establishing and maintaining connections to the devices as is the case in most existing legacy poll/response device protocols. With an MQTT based architecture, both the Host application as well as the devices establish MQTT Sessions with a central MQTT Server(s). This is the desired functionality as it provides the necessary decoupling from any one application and any given device. Additional MQTT clients can connect and subscribe to any of the real time data without impacting the primary SCADA Host application(s). 

-The Primary Application (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit it's functionality of can be somewhat more limited when compared to a PC based implementation. The implementation of a "Primary Application" within a PLC runtime however can also have advantages over a traditional PC based implementation.
+The Primary Application (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit it's functionality of can be somewhat limited when compared to a PC based implementation. The implementation of a "Primary Application" within a PLC runtime however can also have advantages over a traditional PC based implementation. This is why we have chosen to CUT LOOSE the SCADA part and just implement the Primary Application itself.
+
+The Primary Application we envision just provides (exposes) all incoming data centrally and has the possibility to issue Node or Device Commands. Setup of a secure true distributed brand independent control system with this type of setup is made available! As a bonus this setup allows for ANY modern SCADA system you like on top of the CODESYS Primary Application i.e. "Bring your own SCADA" (BYOS).

 In order to implement a "Primary Application", the implementation must follow all rules/graphs as outlined in **paragraph 8.1 through 8.4**
     

  • hermsen

    hermsen - 2020-12-20
    • summary: Implement a "Primary Application" for use in a CODESYS runtime --> Implement a "SparkplugB Primary Node " for use in a CODESYS runtime
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,7 +1,7 @@
 An MQTT based SCADA system is unique in that the Host node is NOT responsible for establishing and maintaining connections to the devices as is the case in most existing legacy poll/response device protocols. With an MQTT based architecture, both the Host application as well as the devices establish MQTT Sessions with a central MQTT Server(s). This is the desired functionality as it provides the necessary decoupling from any one application and any given device. Additional MQTT clients can connect and subscribe to any of the real time data without impacting the primary SCADA Host application(s). 

-The Primary Application (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit it's functionality of can be somewhat limited when compared to a PC based implementation. The implementation of a "Primary Application" within a PLC runtime however can also have advantages over a traditional PC based implementation. This is why we have chosen to CUT LOOSE the SCADA part and just implement the Primary Application itself.
+The SparkplugB Primary Node (aka primary SCADA Host) can also be implemented in a CODESYS based PLC albeit it's functionality of can be somewhat limited when compared to a PC based implementation. The implementation of a Primary Node within a PLC runtime however can also have advantages over a traditional PC based implementation. This is why we have chosen to CUT LOOSE the SCADA part and just implement the Primary Node itself.

-The Primary Application we envision just provides (exposes) all incoming data centrally and has the possibility to issue Node or Device Commands. Setup of a secure true distributed brand independent control system with this type of setup is made available! As a bonus this setup allows for ANY modern SCADA system you like on top of the CODESYS Primary Application i.e. "Bring your own SCADA" (BYOS).
+The Primary Node we envision just provides (exposes) all incoming data centrally and has the possibility to issue Edge Of Network Node- or Device Commands. Setup of a secure true distributed brand independent control system with this type of setup is made available! As a bonus this setup allows for ANY modern SCADA system you like on top of the CODESYS Primary Node i.e. "Bring your own SCADA" (BYOS).

-In order to implement a "Primary Application", the implementation must follow all rules/graphs as outlined in **paragraph 8.1 through 8.4**
+In order to implement a "Primary Node", the implementation must follow all rules/graphs as outlined in **paragraph 8.1 through 8.4**
     

  • hermsen

    hermsen - 2020-12-23

    How do we arrange that all autodiscoveres metrics can be exposed dynamically?

    • An idea would be to build a dynamic list of the metrics that are being discovered on birth of each EoN or Device.

    A user typically only wants data that is of interest to them so we will only subscribe to the list the user wants to be subscribed on. Maybe this total metrics 'list' could be provided to the user in some form of file? Then the subscription list (typically a subset of the total metrics list) van be consumed and that is all that is needed to subscribe to certain data?...

    • IIOT lib SL needed on server and EoN side,
    • Configfile / ini / json / xml ???

    Other ideas are welcomed

     

  • i-campbell

    i-campbell - 2020-12-23

    FB_PrimaryNode
    Can be given pools of Groups, EoNs, Devices, Metrics (eventually also sub objects).

    FB_PrimaryNode.ScanForNodesAndDevices() forces a STATE transition ==> OFFLINE ==> ONLINE
    It will then, over the next 60 seconds, receive various NBIRTHs and DBIRTHs (actually, the application will always be waiting for these xBIRTHs)

    on NBIRTH
    1. add new group or use existing group
    2. add new EoN to group or use existing EoN
    3. for each metric, add new or use existing Metric
    4. if an existing metric was not found in NBIRTH, then remove the metric (return it to the pool)

    on DBIRTH
    1. use existing group or abort
    1. use existing node or abort
    1. add new Device to EoN or use existing Device
    1. for each metric, add new or use existing Metric
    1. if an existing metric was not found in DBIRTH, then remove the metric (return it to the pool)

    FB_PrimaryNode has functions:
    1. FB_PrimaryNode.GetMetricbyName(GroupID,NodeId,DeviceId,MetricName);
    2. FB_PrimaryNode.GetMetricbyAlias(GroupID,NodeId,DeviceId,MetricAlias);

    Also itterators.
    1. FB_PrimaryNode.GetFirstGroupID / GetNextGroupID
    1. FB_Group.GetFirstNodeId / GetNext
    1. FB_EoN.GetFirstMetric / GetNextMetric
    1. FB_EoN.GetFirstDevice / GetNextDevice
    1. FB_Device.GetFirstMetric / GetNextMetric

     

  • hermsen

    hermsen - 2021-10-23
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -5,3 +5,5 @@
 The Primary Node we envision just provides (exposes) all incoming data centrally and has the possibility to issue Edge Of Network Node- or Device Commands. Setup of a secure true distributed brand independent control system with this type of setup is made available! As a bonus this setup allows for ANY modern SCADA system you like on top of the CODESYS Primary Node i.e. "Bring your own SCADA" (BYOS).

 In order to implement a "Primary Node", the implementation must follow all rules/graphs as outlined in **paragraph 8.1 through 8.4**
+
+By definition we achieved this thiugh we still need icing onnthe cake.
    • status: open --> accepted
    • assigned_to: i-campbell
     

Log in to post a comment.