Hi, Julian,
as you said, there are some very interesting topics there.
For us, the aspects for complex types, driver generation via a model-based +
platformindependant approach and a kind of generated OPM are particularly
interesting. Where we would spend some work with for example students,
discussions or LOC :) because it would increase the maintainability (model
based CG) and offers a even better usability through a near complete
abstraction of an automated class/struct/ object generation.
+1 from me :)
Mathi
________________________________
Von: Julian Feinauer <j.feina...@pragmaticminds.de>
Gesendet: Mittwoch, 17. April 2019 09:06:36
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, drivers) to the new
picture which evolved over the last to years.
Of course, feel free to agree, disagree or participate with other opinions.
Julian
PS.: I could offer to bring this in a more “presentable” form and prepare a
short “overview” talk about this for the next meetup, if interesting
