Perfect ;-)
Am 18.04.19, 11:34 schrieb "Julian Feinauer" <[email protected]>:
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" <[email protected]>:
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"
<[email protected]>:
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"
<[email protected]>:
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"
<[email protected]>:
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"
<[email protected]>:
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: [email protected]
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 <[email protected]>
Gesendet: Mittwoch, 17. April 2019 09:07
An: [email protected]
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
