Implement support for complex field types in the PLC4X API (PLC4X-113)
I think that going with a 'DataType' which defines is primitive/map/list
methods is not a valid start. What's gonna happen if we will get a
java.util.Date and all surrounding variant types?
My point is that this part of library should leave a lot of freedom for
type definitions as different PLCs will definitely have their own edge
cases to be covered.
If you will start with collections at beginning you will quickly run
into troubles when you will only think of generics. Top level type
representing a "data type" needs to stay unaware of specific types for
clarity of code and stability of APIs.
When I think of type system I see following variants (don't mind it -
its just sample pulled out from hat):
Type
` ContainerType (map, list, set, array)
` GenericType (map, list, set, array?, json?)
` KeyValueType (map, struct)
` CollectionType
` SetType extends CollectionType>
` ListType extends CollectionType>
` PrimitiveType
` ArrayType // built into JVM, primitive container
` Int32Type
` JavaType // user supplied types for mapping purposes
` EnumType>
` LongType
` UTF8Type
` JsonType // mapped value type, not a field type!
Primary role of fairly free "type" definition of the top is
composability at bottom levels. A numeric types can be reflected by a
NumberType and so on. I can also think of very special kinds of
structures which PLCs can support such structs with names or not or
various mutable or not counter types. Above structure leaves space to
support these.
My conclusion in this area come from earlier Cassandra background.
Cassandra type mappings at infrastructure level have similar concept to
what you linked. Core (marshal) types and their CQL driver
representations follow similar concept and it works. However at our
mapper layer which we did back in 2013 we started from generics.
```
public interface Type {
Serializer getSerializer(); // handle to/from byte sequence
String getTypeName(); // will we need that at all for plcs?
}
```
After several months we got more elements into schema which come from
needs we had and growing Cassandra abilities.
Over time we ended up with below type definitions:
```
// Type which can be mapped 1:1 to Java class and object fields
public interface JavaType extends Type {
Class getJavaType();
}
// Parametrized type ie. List but also Identifiable
interface GenericJavaType extends JavaType {
List> getTypeArguments();
}
// Edge case type which requires special handling
public interface ComplexType extends Type {
}
```
Because we worked with Java all type definitions required generic type
bound. This was something which we introduced on our own as Cassandra
type system didn't provide that and we needed that to build object
mapping layer. If you think of evolution of OPM module then generics
will turn to be a quite nice addon which calcite seems to skip.
Collection types which you mentioned in example link can be reflected by
separate Map/List/Set types as shown in beginning and verified via
instanceof operator. They could be also embedded in interface with
"default" implementations returning false, however my small advice would
be to not do that.
This are my ½€ :-)
Cheers,
Łukasz
On 18.04.2019 09:27, Julian Feinauer (JIRA) wrote:
> Julian Feinauer created PLC4X-113:
> -
>
> Summary: Implement support for complex field types in the PLC4X
> API
> Key: PLC4X-113
> URL: https://issues.apache.org/jira/browse/PLC4X-113
> Project: Apache PLC4X
> Issue Type: New Feature
> Components: API
> Reporter: Julian Feinauer
>
>
> *This is a (possibly) incompatible change.*
>
> Currently we have support for primitives as well as lists (arrays) as first
> class "ciitzens" of the PLC4X model.
> Especially, when thinking about OPC UA, but also other protocols like ADS
> (and even S7) support complex objects in their programming model.
> Thus, it is necessary to refactor / extend the API to support these complex
> objects.
>
> I guess we need at least
> * primitives
> * lists
> * maps (should be equal to "structs")
>
> Basically, this should be roughly equivalent to what one can represent with
> JSON.
> Thus, the API could be structured i two ways.. first, we could use an
> internal Node Tree to represent the objects, but we could also provide to use
> someone elses NodeTree or structure to represent the Objects.
> For example Jackson.. this would even allow us to directly map these objects
> to POJOs via Jackson.
>
> As example for such a model, one can look at that of Apache Calcite:
> https://github.com/apache/calcite/blob/3fa29455664bec0056c436491b369e0cd72242ea/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java
>
> They have an interface with methods
>
>
> {code:java}
> public interface DataType
> {
> // Checker
> boolean isMap;
> boolean isList;
> boolean isPrimitive;
>
[WEBSITE] Updated website in preparation of the graduation announcement on Tuesday
Hi all, as I didn’t hear any complaints, I merged the graduation-preparation branch into develop and the website is now updated to no longer reference the incubator (You might have to refresh the cache … at least I had to) I hope I found all mentions of “incubating” in the places that should be removed and didn’t remove any where they shouldn’t have. However I left the git repos unchanged for now as I thought it would be better to update them as soon as the repos are really changed or people might stumble over this and get mad at us. I opened tickets for all outstanding migration tasks and will be having an eye out for them during the weekend. The build should also no longer produce release artifacts with “incubating” in their name, the generated artifacts should no longer contain the incubation disclaimer, but I guess we have enough time to verify this in the next weeks. In order to test everything I would like to step up as RM for the 0.4.0 release and we should do that pretty soon in order to have the first proper release out there and by being the RM I can test, correct and document any things that might have changed. Gonna be a great day on Tuesday … the News will hit the media sometime around 12-13 local time here in Germany. So for now all I can do is wish you guys some happy Easter holidays if you happen to have them … if not … well then just some happy days ;-) Chris
AW: [DISCUSS] The State and Future of PLC4X
Hi all, can clearly only be done via an adapter. I would only implement the efficient writing and reading of data via OPC UA. If we want to implement all the other functionalities, that's too much. For all other functionalities I don't need much performance. What do you mean? Happy Easter Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.: +49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Bjoern Hoeper Gesendet: Donnerstag, 18. April 2019 10:14 An: dev@plc4x.apache.org Betreff: AW: [DISCUSS] The State and Future of PLC4X Hi erveryone, I agree with Markus because OPC UA is somewhat universal. If we want something open source there is a stack which is quite evolved already: https://github.com/open62541/open62541 it is maintained by a bunch of institutes (one of them is the Process Control Institute in Aachen). So we should at least think about an adapter to OPC UA. The thing we would need to prove is that we can really get faster than the vendor OPC UA server. Another thing that I think is promising and needed is adaptation to field bus systems like Profinet and EtherCAT because they provide good performance and a quite general applicability. And are at least not vendor specific. Best Regards Björn -Ursprüngliche Nachricht- Von: Markus Sommer Gesendet: Donnerstag, 18. April 2019 09:06 An: dev@plc4x.apache.org Betreff: AW: [DISCUSS] The State and Future of PLC4X Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.: +49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation of drivers * Automated Documentation / Spec Generation (!! * Ecosystem / Tools – We have a set of tools that are based on PLC4X and which
[BUILD-STABLE]: Job 'PLC4X/PLC4X/develop [develop] [293]'
BUILD-STABLE: Job 'PLC4X/PLC4X/develop [develop] [293]': Is back to normal.
Re: [DISCUSS] The State and Future of PLC4X
Perfect ;-) Am 18.04.19, 11:34 schrieb "Julian Feinauer" : Hi Chris, indeed. So lets simply use the terms opc-ua server or bridge and opc-ua client : ) Do you agree? Julian Am 18.04.19, 11:32 schrieb "Christofer Dutz" : Hi Julian, That's what I mentioned in the other email. We have to be careful with the term OPC-UA Support and differentiate between OPC-UA Server and OPC-UA Client (PLC4X opc-ua client) I was talking about a OPC-UA Server ... you seem to be about a client. For the Server we wouldn't need the feature you are mentioning. Chris Am 18.04.19, 11:27 schrieb "Julian Feinauer" : Hi Chris, there are two ways.. and you are doing the other one, I think : ) You are talking about the OPC UA interface for other drivers, or? There, you do that implicitly by your config, so this is fine. But, especially when we start to implement an OPC UA Driver, this will fall on our feet : ) Julian Am 18.04.19, 11:19 schrieb "Christofer Dutz" : Hi Julian I don't agree that we have to do the other first. Right now I was thinking about building a configuration that could offer a complex type structure to OPC-UA clients but map simple Addresses to elements of such a tree. So I think we could start without refactoring. Chris Am 18.04.19, 09:15 schrieb "Julian Feinauer" : Hi Markus, I agree with you. And, as one can see in my mail.. there are multple efforts which are currently going. So perhaps, if we focus a bit, we should reach first results pretty fast. But I think one necessity is a refactoring to a complex type model. I will file a Jira for that. Julian Am 18.04.19, 09:06 schrieb "Markus Sommer" : Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a so
Re: [DISCUSS] The State and Future of PLC4X
Hi Chris, indeed. So lets simply use the terms opc-ua server or bridge and opc-ua client : ) Do you agree? Julian Am 18.04.19, 11:32 schrieb "Christofer Dutz" : Hi Julian, That's what I mentioned in the other email. We have to be careful with the term OPC-UA Support and differentiate between OPC-UA Server and OPC-UA Client (PLC4X opc-ua client) I was talking about a OPC-UA Server ... you seem to be about a client. For the Server we wouldn't need the feature you are mentioning. Chris Am 18.04.19, 11:27 schrieb "Julian Feinauer" : Hi Chris, there are two ways.. and you are doing the other one, I think : ) You are talking about the OPC UA interface for other drivers, or? There, you do that implicitly by your config, so this is fine. But, especially when we start to implement an OPC UA Driver, this will fall on our feet : ) Julian Am 18.04.19, 11:19 schrieb "Christofer Dutz" : Hi Julian I don't agree that we have to do the other first. Right now I was thinking about building a configuration that could offer a complex type structure to OPC-UA clients but map simple Addresses to elements of such a tree. So I think we could start without refactoring. Chris Am 18.04.19, 09:15 schrieb "Julian Feinauer" : Hi Markus, I agree with you. And, as one can see in my mail.. there are multple efforts which are currently going. So perhaps, if we focus a bit, we should reach first results pretty fast. But I think one necessity is a refactoring to a complex type model. I will file a Jira for that. Julian Am 18.04.19, 09:06 schrieb "Markus Sommer" : Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C
Re: [DISCUSS] The State and Future of PLC4X
Hi Julian, That's what I mentioned in the other email. We have to be careful with the term OPC-UA Support and differentiate between OPC-UA Server and OPC-UA Client (PLC4X opc-ua client) I was talking about a OPC-UA Server ... you seem to be about a client. For the Server we wouldn't need the feature you are mentioning. Chris Am 18.04.19, 11:27 schrieb "Julian Feinauer" : Hi Chris, there are two ways.. and you are doing the other one, I think : ) You are talking about the OPC UA interface for other drivers, or? There, you do that implicitly by your config, so this is fine. But, especially when we start to implement an OPC UA Driver, this will fall on our feet : ) Julian Am 18.04.19, 11:19 schrieb "Christofer Dutz" : Hi Julian I don't agree that we have to do the other first. Right now I was thinking about building a configuration that could offer a complex type structure to OPC-UA clients but map simple Addresses to elements of such a tree. So I think we could start without refactoring. Chris Am 18.04.19, 09:15 schrieb "Julian Feinauer" : Hi Markus, I agree with you. And, as one can see in my mail.. there are multple efforts which are currently going. So perhaps, if we focus a bit, we should reach first results pretty fast. But I think one necessity is a refactoring to a complex type model. I will file a Jira for that. Julian Am 18.04.19, 09:06 schrieb "Markus Sommer" : Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together
Re: [DISCUSS] The State and Future of PLC4X
Hi all, and regarding the fieldbus protocols: - We purchased the full spec of the Profinet protocol and will register a profinet-id in the next few weeks. Implementing this would only be limited by the time we have and the willingness to do so ;-) - EtherCat is where our Raw Sockets would have to come in (With Profinet I'm not 100% sure). As the EtherCat communication doesn't run on UDP or TCP, but on Ethernet frames directly. Currently the RawSocket Netty support would need quite a bit of love ... I implemented it as a prototype and it seems to be working, however it is not fully integrated into Netty yet. Chris Am 18.04.19, 10:30 schrieb "Julian Feinauer" : Hi all, Fedlbus is a good Keyword. Yesterday I met with Ralf Koelle and Rolf Wutzke from scitis / sotec and they were quite interested in these two. @Ralf, @Rolf: I took the freedom to take you in CC. Do you already have a working stack for these protocols? Julian Am 18.04.19, 10:14 schrieb "Bjoern Hoeper" : Hi erveryone, I agree with Markus because OPC UA is somewhat universal. If we want something open source there is a stack which is quite evolved already: https://github.com/open62541/open62541 it is maintained by a bunch of institutes (one of them is the Process Control Institute in Aachen). So we should at least think about an adapter to OPC UA. The thing we would need to prove is that we can really get faster than the vendor OPC UA server. Another thing that I think is promising and needed is adaptation to field bus systems like Profinet and EtherCAT because they provide good performance and a quite general applicability. And are at least not vendor specific. Best Regards Björn -Ursprüngliche Nachricht- Von: Markus Sommer Gesendet: Donnerstag, 18. April 2019 09:06 An: dev@plc4x.apache.org Betreff: AW: [DISCUSS] The State and Future of PLC4X Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation
Re: [DISCUSS] The State and Future of PLC4X
Hi Chris, there are two ways.. and you are doing the other one, I think : ) You are talking about the OPC UA interface for other drivers, or? There, you do that implicitly by your config, so this is fine. But, especially when we start to implement an OPC UA Driver, this will fall on our feet : ) Julian Am 18.04.19, 11:19 schrieb "Christofer Dutz" : Hi Julian I don't agree that we have to do the other first. Right now I was thinking about building a configuration that could offer a complex type structure to OPC-UA clients but map simple Addresses to elements of such a tree. So I think we could start without refactoring. Chris Am 18.04.19, 09:15 schrieb "Julian Feinauer" : Hi Markus, I agree with you. And, as one can see in my mail.. there are multple efforts which are currently going. So perhaps, if we focus a bit, we should reach first results pretty fast. But I think one necessity is a refactoring to a complex type model. I will file a Jira for that. Julian Am 18.04.19, 09:06 schrieb "Markus Sommer" : Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation of drivers * Automated Documentation / Spec Generation (!! * Ecosystem / Tools – We have a set of tools that are based on PLC4X and which enable to do things which where unthinkable before. Some are * Scraper – A tool to scrape massive amounts of data from multiple PLCs based on a yml configuration, this is mostly driven by Tim * OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests which then go native to the PLCs. Matthias started some work on this, Tim looked over it and I think Chris plans on implementing something here also *
Re: [DISCUSS] The State and Future of PLC4X
Hi Bjoern, One thing we have to keep in mind with that code is that it's licensed under the Mozilla Public License v2.0, which is a weak copy-left license. While it's not forbidden to use that, we have to be careful in using it and we have to correctly label it [1] The other thing is that usually these external drivers differ greatly from their internal structure. There are exceptions such as the Modbus and EtherNet/IP drivers as the author of these chose to use the identical setup we have for building our drivers. Good thing he is the same author as the Eclipse Milo project [2], which has a nicer license and should probably be a better fit from an architecture point of view. At least if I was to start implementing an OPC-UA server, this would be my implementation of choice at the moment. If we simply force such an external driver into PLC4X we will increase the problems with maintaining the drivers ... and especially in porting this to other languages. And we have to be careful ... This one feature request would be an OPC-UA Server ... this wouldn't allow us to communicate with OPC-UA PLCs, but instead enable OPC-UA Clients to access legacy hardware using this OPC-UA server which simply uses PLC4X to handle the backend communication. It's a so-called protocol bridge. Chris [1] https://www.apache.org/legal/resolved.html [2] https://github.com/eclipse/milo Am 18.04.19, 10:14 schrieb "Bjoern Hoeper" : Hi erveryone, I agree with Markus because OPC UA is somewhat universal. If we want something open source there is a stack which is quite evolved already: https://github.com/open62541/open62541 it is maintained by a bunch of institutes (one of them is the Process Control Institute in Aachen). So we should at least think about an adapter to OPC UA. The thing we would need to prove is that we can really get faster than the vendor OPC UA server. Another thing that I think is promising and needed is adaptation to field bus systems like Profinet and EtherCAT because they provide good performance and a quite general applicability. And are at least not vendor specific. Best Regards Björn -Ursprüngliche Nachricht- Von: Markus Sommer Gesendet: Donnerstag, 18. April 2019 09:06 An: dev@plc4x.apache.org Betreff: AW: [DISCUSS] The State and Future of PLC4X Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (wil
Re: [DISCUSS] The State and Future of PLC4X
Hi Julian I don't agree that we have to do the other first. Right now I was thinking about building a configuration that could offer a complex type structure to OPC-UA clients but map simple Addresses to elements of such a tree. So I think we could start without refactoring. Chris Am 18.04.19, 09:15 schrieb "Julian Feinauer" : Hi Markus, I agree with you. And, as one can see in my mail.. there are multple efforts which are currently going. So perhaps, if we focus a bit, we should reach first results pretty fast. But I think one necessity is a refactoring to a complex type model. I will file a Jira for that. Julian Am 18.04.19, 09:06 schrieb "Markus Sommer" : Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation of drivers * Automated Documentation / Spec Generation (!! * Ecosystem / Tools – We have a set of tools that are based on PLC4X and which enable to do things which where unthinkable before. Some are * Scraper – A tool to scrape massive amounts of data from multiple PLCs based on a yml configuration, this is mostly driven by Tim * OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests which then go native to the PLCs. Matthias started some work on this, Tim looked over it and I think Chris plans on implementing something here also * We had multiple discussions about tools that “guess” something about locations of variables or their types. Chris brought that up yesterday and plans to do something there, Matthias and I discussed this several times and we plan to also do something with one or two students there * New programming models – As plc4x is open, it allows us to implement new programming models on top of it. The best example I can give is OPM, the JPA equivalent of PLC4X. The idea is to work with POJOs and annotations and EntityManagers (as Beans) and have a “type safe” and Business-esque way to communicate with PLCs. Here I see a lot of potenti
Re: [DISCUSS] The State and Future of PLC4X
Hi all, Fedlbus is a good Keyword. Yesterday I met with Ralf Koelle and Rolf Wutzke from scitis / sotec and they were quite interested in these two. @Ralf, @Rolf: I took the freedom to take you in CC. Do you already have a working stack for these protocols? Julian Am 18.04.19, 10:14 schrieb "Bjoern Hoeper" : Hi erveryone, I agree with Markus because OPC UA is somewhat universal. If we want something open source there is a stack which is quite evolved already: https://github.com/open62541/open62541 it is maintained by a bunch of institutes (one of them is the Process Control Institute in Aachen). So we should at least think about an adapter to OPC UA. The thing we would need to prove is that we can really get faster than the vendor OPC UA server. Another thing that I think is promising and needed is adaptation to field bus systems like Profinet and EtherCAT because they provide good performance and a quite general applicability. And are at least not vendor specific. Best Regards Björn -Ursprüngliche Nachricht- Von: Markus Sommer Gesendet: Donnerstag, 18. April 2019 09:06 An: dev@plc4x.apache.org Betreff: AW: [DISCUSS] The State and Future of PLC4X Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation of drivers * Automated Documentation / Spec Generation (!! * Ecosystem / Tools – We have a set of tools that are based on PLC4X and which enable to do things which where unthinkable before. Some are * Scraper – A tool to scrape massive amounts of data from multiple PLCs based on a yml configuration, this is mostly driven by Tim * OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests which then go native to the PLCs. Matthias started some work on this, Tim looked over it and I think Chris plans on implementing something here also * We had multiple discussions about tools that “guess” something about locations of variables or their types. Chris brought that up yesterday and plans to do something there, Matthias and I discussed this several times and we plan to also do something with one or two students there * New programming models – As plc4x is open, it allows us to implement new pr
AW: [DISCUSS] The State and Future of PLC4X
Hi erveryone, I agree with Markus because OPC UA is somewhat universal. If we want something open source there is a stack which is quite evolved already: https://github.com/open62541/open62541 it is maintained by a bunch of institutes (one of them is the Process Control Institute in Aachen). So we should at least think about an adapter to OPC UA. The thing we would need to prove is that we can really get faster than the vendor OPC UA server. Another thing that I think is promising and needed is adaptation to field bus systems like Profinet and EtherCAT because they provide good performance and a quite general applicability. And are at least not vendor specific. Best Regards Björn -Ursprüngliche Nachricht- Von: Markus Sommer Gesendet: Donnerstag, 18. April 2019 09:06 An: dev@plc4x.apache.org Betreff: AW: [DISCUSS] The State and Future of PLC4X Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.: +49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation of drivers * Automated Documentation / Spec Generation (!! * Ecosystem / Tools – We have a set of tools that are based on PLC4X and which enable to do things which where unthinkable before. Some are * Scraper – A tool to scrape massive amounts of data from multiple PLCs based on a yml configuration, this is mostly driven by Tim * OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests which then go native to the PLCs. Matthias started some work on this, Tim looked over it and I think Chris plans on implementing something here also * We had multiple discussions about tools that “guess” something about locations of variables or their types. Chris brought that up yesterday and plans to do something there, Matthias and I discussed this several times and we plan to also do something with one or two students there * New programming models – As plc4x is open, it allows us to implement new programming models on top of it. The best example I can give is OPM, the JPA equivalent of PLC4X. The idea is to work with POJOs and annotations and EntityManagers (as Beans) and have a “type safe” and Business-esque way to communicate with PLCs. Here I see a lot of potential and possible next steps could be (discussed by Matthias and me) * “Richer” Typesystem (not just primitives and Arrays as currently) which covers complex objects * Mapping of complex objects from POJOs to PLC segments (Like structs in S7 or ADS) * Auto-generation of annotated POJOs from PLC
[jira] [Created] (PLC4X-113) Implement support for complex field types in the PLC4X API
Julian Feinauer created PLC4X-113:
-
Summary: Implement support for complex field types in the PLC4X API
Key: PLC4X-113
URL: https://issues.apache.org/jira/browse/PLC4X-113
Project: Apache PLC4X
Issue Type: New Feature
Components: API
Reporter: Julian Feinauer
*This is a (possibly) incompatible change.*
Currently we have support for primitives as well as lists (arrays) as first
class "ciitzens" of the PLC4X model.
Especially, when thinking about OPC UA, but also other protocols like ADS (and
even S7) support complex objects in their programming model.
Thus, it is necessary to refactor / extend the API to support these complex
objects.
I guess we need at least
* primitives
* lists
* maps (should be equal to "structs")
Basically, this should be roughly equivalent to what one can represent with
JSON.
Thus, the API could be structured i two ways.. first, we could use an internal
Node Tree to represent the objects, but we could also provide to use someone
elses NodeTree or structure to represent the Objects.
For example Jackson.. this would even allow us to directly map these objects to
POJOs via Jackson.
As example for such a model, one can look at that of Apache Calcite:
https://github.com/apache/calcite/blob/3fa29455664bec0056c436491b369e0cd72242ea/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java
They have an interface with methods
{code:java}
public interface DataType
{
// Checker
boolean isMap;
boolean isList;
boolean isPrimitive;
// Getter for complex types
DataType get(String key);
DataType get(Long i);
// Primitive getters
long getLong();
String getString();
//...
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] The State and Future of PLC4X
Hi Markus, I agree with you. And, as one can see in my mail.. there are multple efforts which are currently going. So perhaps, if we focus a bit, we should reach first results pretty fast. But I think one necessity is a refactoring to a complex type model. I will file a Jira for that. Julian Am 18.04.19, 09:06 schrieb "Markus Sommer" : Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation of drivers * Automated Documentation / Spec Generation (!! * Ecosystem / Tools – We have a set of tools that are based on PLC4X and which enable to do things which where unthinkable before. Some are * Scraper – A tool to scrape massive amounts of data from multiple PLCs based on a yml configuration, this is mostly driven by Tim * OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests which then go native to the PLCs. Matthias started some work on this, Tim looked over it and I think Chris plans on implementing something here also * We had multiple discussions about tools that “guess” something about locations of variables or their types. Chris brought that up yesterday and plans to do something there, Matthias and I discussed this several times and we plan to also do something with one or two students there * New programming models – As plc4x is open, it allows us to implement new programming models on top of it. The best example I can give is OPM, the JPA equivalent of PLC4X. The idea is to work with POJOs and annotations and EntityManagers (as Beans) and have a “type safe” and Business-esque way to communicate with PLCs. Here I see a lot of potential and possible next steps could be (discussed by Matthias and me) * “Richer” Typesystem (not just primitives and Arrays as currently) which covers complex objects * Mapping of complex objects from POJOs to PLC segments (Like structs in S7 or ADS) * Auto-generation of annotated POJOs from PLC programs (much like JPA or the C# ORM does that based on an existing database). This could be a “killer-feature” as it would really allow type-safe end to end communication with the plc with zero plc specific knowledge Other Topics in this area that can be named are
AW: [DISCUSS] The State and Future of PLC4X
Hi all, I was at the Hannovermesse and the industry clearly relies on OPC UA. If PLC4x could realize a very fast OPC UA, this would be a massive advantage over other manufacturers. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.: +49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Julian Feinauer Gesendet: Mittwoch, 17. April 2019 09:07 An: dev@plc4x.apache.org Betreff: [DISCUSS] The State and Future of PLC4X Hi all, as we had a lot of non-technical discussions and topics the last time (the coming of age of a software project, I guess) it’s time for us to go back to the real fun part and do technical shit. I had a lot of discussions (on list and off list) with several people like Chris, Matthias, Björn, Tim and others and wanted to share my thoughts on the future of PLC4X as I see it (from a solely technical perspective). Currently, I see several “fronts” or centers of activity (or where I think we should spend it). * Language adoption – We should define and deliver APIs and bindings for other languages to bring what we currently have to other people and other communities. The activities we have there are currently (from my head): Markus and C++, Björn who wanted to investigate C# and the “Interop Server” which I played around a bit (in fact, Matthias made a python binding yesterday…) * Driver Generation – This is a well-known Topic which is currently driven by Chris. This is a large topic, which includes * Model Generation (currently dfdl and state-xml) * Templates for many languages (will partially derive from above) * A build process, to wire both together * Some kind of Test Suite to check the correct generation of drivers * Automated Documentation / Spec Generation (!! * Ecosystem / Tools – We have a set of tools that are based on PLC4X and which enable to do things which where unthinkable before. Some are * Scraper – A tool to scrape massive amounts of data from multiple PLCs based on a yml configuration, this is mostly driven by Tim * OPC UA Server – Yet to come. Maps OPC UA requests to PLC4X requests which then go native to the PLCs. Matthias started some work on this, Tim looked over it and I think Chris plans on implementing something here also * We had multiple discussions about tools that “guess” something about locations of variables or their types. Chris brought that up yesterday and plans to do something there, Matthias and I discussed this several times and we plan to also do something with one or two students there * New programming models – As plc4x is open, it allows us to implement new programming models on top of it. The best example I can give is OPM, the JPA equivalent of PLC4X. The idea is to work with POJOs and annotations and EntityManagers (as Beans) and have a “type safe” and Business-esque way to communicate with PLCs. Here I see a lot of potential and possible next steps could be (discussed by Matthias and me) * “Richer” Typesystem (not just primitives and Arrays as currently) which covers complex objects * Mapping of complex objects from POJOs to PLC segments (Like structs in S7 or ADS) * Auto-generation of annotated POJOs from PLC programs (much like JPA or the C# ORM does that based on an existing database). This could be a “killer-feature” as it would really allow type-safe end to end communication with the plc with zero plc specific knowledge Other Topics in this area that can be named are * A connection pool to share / reuse connections for efficiency (which was implemented by Sebastian and is absolutely crucial for us!) * A central monitoring component (similar to how a Webserver monitors each side access and the results and latencies and so..), I am currently working on this and hope to provide a PR soon Of course, all of this is solely based on my personal opinion or things that came out in discussions with other involved people. For me, this structure makes sense and perhaps it helps us to “broaden” our scope a bit from the initial focus (drivers, drivers,
