I am working on model-level worst-case execution time (WCET) analysis for IEC 61499 based on 4DIAC (I presented some of the work at th 4DIAC workshop 2013). Inspired by the demonstration you had at the workshop, and how you deal with inter-node (device/resource communication) I started investigating how I could generate the publish/subscribe FBs automatically, and use them (and the information provided by generation) in the analysis. For now the WCET analysis is done on the application level, and doesn't take into account any FBs defined in the FBN of the resources.
To get better results with this automatic generation, it would be very helpful if you could answer some questions on how you currently generate the publish/subscribe FBs by hand... (I'll just list them so they are easier to see...). Any help would be very welcome!
What are the exact FBs you use for this communication? Is it the PUBLISH_X/SUBSCRIBE_X FBs in the /net/ folder of the library?
Is there any problems with having more than SUBSCRIBE FB listening to one PUBLISH FB?
Can I use the SUBSCRIBE FB-s without connecting all the output ports (e.g. not using one of the output data or the output event port)?
How do you configure these blocks? Is it only the ID data input port, with the IP address and port?
When configuring the communication, do you always use multicast IP addresses, or do you sometimes use a concrete device IP?
Is the same approach applied to inter-resource and inter-device communication?
How do you implement such communication on other types of networks, e.g. CAN bus?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
having an option to automatically generate appropriate communication function blocks for mapped applications would be a great improvement for 4DIAC. I know that nxtControl offers this in some way and I also heard that people at the University in Bilbao have been working on this topic. However I don't know any results.
Regarding your questions find below some answers.
What are the exact FBs you use for this communication? Is it the >PUBLISH_X/SUBSCRIBE_X FBs in the /net/ folder of the library?
Event and data connection decouple the FBs from each other. That means that a FB has no knowledge where its events and data are coming from and also no knowledge on where its events and data is used. The PUBLISH/SUBSCRIBE communication model represents this interaction very well and therefore is best suited for maintaining the event and data connections across resource boundaries.
Is there any problems with having more than SUBSCRIBE FB listening to one PUBLISH FB?
You can have as much SUBSCRIBE FBs to a PUBLISH FB as you like. You could even have more than one PUBLSIH FB. However this could be hard to handle.
Can I use the SUBSCRIBE FB-s without connecting all the output ports (e.g. not using one of the output data or the output event port)?
If you don't use the events outputs the data outputs would still be updated and could be used in data connections with other function blocks. The only difference would be that the data would not be handled with the IND event of the SUBSCRIBE FB but with the event that triggers the FB connected to the data outputs of the SUBSCRIBE FB.
With data outputs the situation is a little bit different. Currently both sides (i.e., PUBLISH and SUBSCRIBE) need to have the same amount of data ports (i.e., the number of SDs in PUBLISH need to be equal to the number of RDs in SUBSCRIBE). Furthermore on both sides all ports must be connected to a port with a concrete data type. The reason for this is that we use this information for generating the message on the PUBLISH side. On the SUBSCRIBE side we need this for detecting if the correct amount of data and the correct data has been received.
A simple solution for 4DIAC would be to try to parse what is there and set this as type for the output. This would be possible in the current implementation of FORTE. However the message format used in by the compliance profile is very simple and in rare cases a parsing in that way could lead to problems.
In order to improve this situation a rework of the IEC 61499 message format would be needed. For example, a header containing information on the number of bytes in the packet as well as the number of elements would greatly improve the situation.
How do you configure these blocks? Is it only the ID data input port, with the IP address and port?
In principle yes if you are on Ethernet or want to use an Ethernet network. See also answer of last question
When configuring the communication, do you always use multicast IP addresses, or do you sometimes use a concrete device IP?
Typically we only use multicast addresses however this is a target network or protocol specific option. The rules for the classic PUBLISH/SUBSCRIBE on Ethernet are defined in here: http://holobloc.com/doc/ita/s3.htm
Is the same approach applied to inter-resource and inter-device communication?
You could use it. However there we typically use the local PUBLISH/SUBSCRIBE (i.e., PUBL_x, SUBL_x blocks) which work in shared memory and are therefore a little bit more efficient.
How do you implement such communication on other types of networks, e.g. CAN bus?
In principle you could develop own function blocks for each network. However we identified that this is maybe not the best option. Especially for the user as he gets a big load of FBs and also for maintaining and implementing them. Most of the code would be duplicated. Therefore we implemented in 4DIAC a concept where we have just 4 kinds of communication function blocks (i.e., Publish, Subscribe, Client, and server) and have so called communication layers which will take over communication specific tasks (a short overview is given in the wiki: http://sourceforge.net/apps/mediawiki/fordiac/index.php?title=FORTE_Communication_Infrastructure).
For example we have a layer for Ethernet and a layer for the FBDK ASN.1 encoding. Together they allow a communication with FBDK and FORTE devices. But you could add further layers like a CAN layer.
In order to use specific layers you have to specify them with parameters at the ID parameter. e.g. fbdk[].ip[]225.0.0.1:61500].
In FORTE you can find examples for such layers already for the local communication (yes even the PUBL and SUBL use internally the layers), Serial interface, OPC-DA, and Modbus. However not all communication FB types may be supported by an layer (e.g., Modbus TCP und OPC DA are currently only supported for the CLIENT FB.
For the generation in the end it means that you need again only insert an PUBLISH / SUBSCRIBE pair and afterwards configure the ID parameter.
I hope this sheds some light in the FORTE and IEC 61499 communication infrastructure.
Cheers,
Alois
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately plugin package "mdh prototype tools.zip" found at http://www.idt.mdh.se/~jcn01/research/4DIAC-plugins/ currently does only contain the timing analysis plugin. The feature "automatic generation of function blocks" is missing.
Are there any plans for integrating this feature into 4DIAC-IDE or how to get the full package of "mdh prototype tools.zip"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
It seems that a wrong version of zip ended up on-line. I don't have direct access to upload a new version, but I'll get it updated sometime next week!
Thank you for the interest!
Luka
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
I am working on model-level worst-case execution time (WCET) analysis for IEC 61499 based on 4DIAC (I presented some of the work at th 4DIAC workshop 2013). Inspired by the demonstration you had at the workshop, and how you deal with inter-node (device/resource communication) I started investigating how I could generate the publish/subscribe FBs automatically, and use them (and the information provided by generation) in the analysis. For now the WCET analysis is done on the application level, and doesn't take into account any FBs defined in the FBN of the resources.
An example of what I'm planning to implement can be seen here:
https://www.dropbox.com/s/cksjegfyfj8cn24/Inter-node%20communication%20examples%20-%20option%201.pdf
To get better results with this automatic generation, it would be very helpful if you could answer some questions on how you currently generate the publish/subscribe FBs by hand... (I'll just list them so they are easier to see...). Any help would be very welcome!
Hi,
having an option to automatically generate appropriate communication function blocks for mapped applications would be a great improvement for 4DIAC. I know that nxtControl offers this in some way and I also heard that people at the University in Bilbao have been working on this topic. However I don't know any results.
Regarding your questions find below some answers.
Event and data connection decouple the FBs from each other. That means that a FB has no knowledge where its events and data are coming from and also no knowledge on where its events and data is used. The PUBLISH/SUBSCRIBE communication model represents this interaction very well and therefore is best suited for maintaining the event and data connections across resource boundaries.
You can have as much SUBSCRIBE FBs to a PUBLISH FB as you like. You could even have more than one PUBLSIH FB. However this could be hard to handle.
If you don't use the events outputs the data outputs would still be updated and could be used in data connections with other function blocks. The only difference would be that the data would not be handled with the IND event of the SUBSCRIBE FB but with the event that triggers the FB connected to the data outputs of the SUBSCRIBE FB.
With data outputs the situation is a little bit different. Currently both sides (i.e., PUBLISH and SUBSCRIBE) need to have the same amount of data ports (i.e., the number of SDs in PUBLISH need to be equal to the number of RDs in SUBSCRIBE). Furthermore on both sides all ports must be connected to a port with a concrete data type. The reason for this is that we use this information for generating the message on the PUBLISH side. On the SUBSCRIBE side we need this for detecting if the correct amount of data and the correct data has been received.
A simple solution for 4DIAC would be to try to parse what is there and set this as type for the output. This would be possible in the current implementation of FORTE. However the message format used in by the compliance profile is very simple and in rare cases a parsing in that way could lead to problems.
In order to improve this situation a rework of the IEC 61499 message format would be needed. For example, a header containing information on the number of bytes in the packet as well as the number of elements would greatly improve the situation.
In principle yes if you are on Ethernet or want to use an Ethernet network. See also answer of last question
Typically we only use multicast addresses however this is a target network or protocol specific option. The rules for the classic PUBLISH/SUBSCRIBE on Ethernet are defined in here: http://holobloc.com/doc/ita/s3.htm
In principle you could develop own function blocks for each network. However we identified that this is maybe not the best option. Especially for the user as he gets a big load of FBs and also for maintaining and implementing them. Most of the code would be duplicated. Therefore we implemented in 4DIAC a concept where we have just 4 kinds of communication function blocks (i.e., Publish, Subscribe, Client, and server) and have so called communication layers which will take over communication specific tasks (a short overview is given in the wiki: http://sourceforge.net/apps/mediawiki/fordiac/index.php?title=FORTE_Communication_Infrastructure).
For example we have a layer for Ethernet and a layer for the FBDK ASN.1 encoding. Together they allow a communication with FBDK and FORTE devices. But you could add further layers like a CAN layer.
In order to use specific layers you have to specify them with parameters at the ID parameter. e.g. fbdk[].ip[]225.0.0.1:61500].
In FORTE you can find examples for such layers already for the local communication (yes even the PUBL and SUBL use internally the layers), Serial interface, OPC-DA, and Modbus. However not all communication FB types may be supported by an layer (e.g., Modbus TCP und OPC DA are currently only supported for the CLIENT FB.
For the generation in the end it means that you need again only insert an PUBLISH / SUBSCRIBE pair and afterwards configure the ID parameter.
I hope this sheds some light in the FORTE and IEC 61499 communication infrastructure.
Cheers,
Alois
I know that this discussion is more than a year old but I'm also interested in the feature having publish/subscribe FBs generated automatically.
The approach and screenshots of Luka Lednicki looks promising, a presentation about an IDE plugin also can be found here:
http://www.fordiac.org/fileadmin/pdf/etfa_2014/4DIAC_Talk6_Automatic_generation_of_distributed_communication_in_4DIAC.pdf
Unfortunately plugin package "mdh prototype tools.zip" found at http://www.idt.mdh.se/~jcn01/research/4DIAC-plugins/ currently does only contain the timing analysis plugin. The feature "automatic generation of function blocks" is missing.
Are there any plans for integrating this feature into 4DIAC-IDE or how to get the full package of "mdh prototype tools.zip"?
Hello!
It seems that a wrong version of zip ended up on-line. I don't have direct access to upload a new version, but I'll get it updated sometime next week!
Thank you for the interest!
Luka
Hi Luka!
Thanks for your answer and your support!
I'm looking forward to it :-)
Cheers!
Thomas