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" <christofer.d...@c-ware.de>:

    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" <j.feina...@pragmaticminds.de>:
    
        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" <som...@isb-fn.de>:
        
            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 <j.feina...@pragmaticminds.de> 
            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, 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
            
        
        
    
    

Reply via email to