plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: [DISCUSS] The State and Future of PLC4X
Date Fri, 19 Apr 2019 14:45:56 GMT
Hi Otto,

I guess you are referring to OPC-UA ... well of course we should support that ... but as currently
the performance of OPC-UA on PLCs is so extremely crappy I would personally like to postpone
that a little. But I would never object anyone wanting to work on that ... wanna get your
fingers dirty? ;-)


Am 19.04.19, 14:28 schrieb "Otto Fowler" <>:

    RFC 62541?
    On April 18, 2019 at 05:38:56, Christofer Dutz (
    Perfect ;-)
    Am 18.04.19, 11:34 schrieb "Julian Feinauer" <>:
    Hi Chris,
    So lets simply use the terms opc-ua server or bridge and opc-ua client : )
    Do you agree?
    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.
    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 : )
    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.
    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.
    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
    Freundliche Grüße
    Markus Sommer
    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
    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
    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
    * 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.
    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

View raw message