From dev-return-1998-archive-asf-public=cust-asf.ponee.io@plc4x.apache.org Fri Apr 19 12:27:56 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 548B7180627 for ; Fri, 19 Apr 2019 14:27:56 +0200 (CEST) Received: (qmail 347 invoked by uid 500); 19 Apr 2019 12:27:55 -0000 Mailing-List: contact dev-help@plc4x.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@plc4x.apache.org Delivered-To: mailing list dev@plc4x.apache.org Received: (qmail 328 invoked by uid 99); 19 Apr 2019 12:27:55 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Apr 2019 12:27:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 63A6DC227C for ; Fri, 19 Apr 2019 12:27:54 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id NFV3Pw2kVQ7x for ; Fri, 19 Apr 2019 12:27:52 +0000 (UTC) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 267455FD95 for ; Fri, 19 Apr 2019 12:27:52 +0000 (UTC) Received: by mail-io1-f45.google.com with SMTP id p23so4263240iol.13 for ; Fri, 19 Apr 2019 05:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=Lbmq/Od1O4j+kLx7K5UvPnGf7jyhFAIX64m60I/FymI=; b=hwB0/4tPUPupjPtXF7Xp5xO9/mK4NSYWGLFg5qzeVcenud3saBUu2qRz/eATtWGGDo hAoQg+7SEzBbWNI7vPeQ/05EgO+0NtU8oEIf6lWrqmxyJ8EEQxvCgthTR1n3bcuicerl 3N3FN3Us/E2X5zpwu9sLoVvqVc9UuRVej7fTx5mE98vBJfYQSJDuoaQew0g58/dsw+8n nS+ovPgD8bcCoi6G3LcI2u4BcospeoFVdARBvs8B8XGOjOkJ6c8WEyHyUDUfJfFvbL0d s5Bjw0Qy2FPuDqAIc0rxX3zIjxteavApidUBdBcoNzGK6qY7OH/gFFuIIr6GzNvzhUz+ jV7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=Lbmq/Od1O4j+kLx7K5UvPnGf7jyhFAIX64m60I/FymI=; b=JqQydV/LdAMq6TOnx+ZuqR/bUkndUpzyyR/A08H+HB2TsX+qA97TP4tbAiYSrzQv5n VnKleycFgbSEe6tBeKToSqTedaZgIyZ+eRz8kkI/RrNoLqSHUHCpMvqEZDqQch+ZqnYL IzOhb2Ko6AGjym0G3ZX9nME2GEsYxeu5c3BFUdebQy77zriqJdQ0QxF4BD7euRcP4ewx ttYUmZRWySI6Sk3anvDzL5t7BCovAHpRNr5yZ3IDhmXBR3AzHHXqT2netpR4o7h/LW1u OLj0g02FNMRgs/xrnyTFLxCqahRsDRa2aZ0RMrtPGwrxh6acxrgzmeuvauVf9tusyhka zAgQ== X-Gm-Message-State: APjAAAUf4eVnPSy2eVsea7L3XOyeBcaQZtgPocMfhxPZOxETtqRgX9w+ Gow0wrRDbmyhKnUP+hLO2UzglarxiOcHMYXcTpvF8Q== X-Google-Smtp-Source: APXvYqzVTUfg00WF2se766IAzDabGlpFKuNq8WEzzIScy1e/rn7Pb86VdDNOd9s9vbAE+6mr5rNpgm0X/YB0EIGFWek= X-Received: by 2002:a5d:9045:: with SMTP id v5mr2452833ioq.177.1555676871388; Fri, 19 Apr 2019 05:27:51 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 19 Apr 2019 05:27:50 -0700 From: Otto Fowler In-Reply-To: <7EC9EDCE-AEB2-4582-A32D-0CEE471EB178@c-ware.de> References: <2F674AF1D7CD6E4A8EED8B73EE0C335D01010021@ISB-01.isb-fn.local> <0BDE5EB7-77C6-41D9-8BDC-54A1CB471046@pragmaticminds.de> <9A640CFD-072E-41B9-880C-3B58121EB0C5@pragmaticminds.de> <0E8A3F93-CAF0-432A-AB2A-630121F6ABEA@c-ware.de> <2A1286E0-D8E8-4DAA-893F-3423F0867762@pragmaticminds.de> <7EC9EDCE-AEB2-4582-A32D-0CEE471EB178@c-ware.de> MIME-Version: 1.0 Date: Fri, 19 Apr 2019 05:27:50 -0700 Message-ID: Subject: Re: [DISCUSS] The State and Future of PLC4X To: dev@plc4x.apache.org Content-Type: multipart/alternative; boundary="0000000000004df52c0586e13f5a" --0000000000004df52c0586e13f5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RFC 62541? On April 18, 2019 at 05:38:56, Christofer Dutz (christofer.dutz@c-ware.de) wrote: Perfect ;-) =EF=BB=BFAm 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=C3=BC=C3=9Fe Markus Sommer Gesch=C3=A4ftsf=C3=BChrer 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: sommer@isb-fn.de Web: www.isb-fn.de Gesch=C3=A4ftsf=C3=BChrer: 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=C3=BCngliche 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=E2=80=99s time for us to g= o 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=C3=B6rn, 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 =E2=80=9Cfronts=E2=80=9D or centers of activity (o= r where I think we should spend it). * Language adoption =E2=80=93 We should define and deliver APIs and binding= s 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=C3=B6rn who wanted to investigate C# and the =E2=80=9CIn= terop Server=E2=80=9D which I played around a bit (in fact, Matthias made a python binding yesterday=E2=80=A6) * Driver Generation =E2=80=93 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 =E2=80=93 We have a set of tools that are based on PLC4= X and which enable to do things which where unthinkable before. Some are * Scraper =E2=80=93 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 =E2=80=93 Yet to come. Maps OPC UA requests to PLC4X reques= ts 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 =E2=80=9Cguess=E2=80=9D some= thing 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 =E2=80=93 As plc4x is open, it allows us to implem= ent 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 =E2=80=9Ctype safe=E2=80=9D and Busine= ss-esque way to communicate with PLCs. Here I see a lot of potential and possible next steps could be (discussed by Matthias and me) * =E2=80=9CRicher=E2=80=9D Typesystem (not just primitives and Arrays as cu= rrently) 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 =E2=80=9Ckiller-feature=E2=80=9D 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 =E2=80=9Cbroa= den=E2=80=9D 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 =E2=80=9Cpresentable=E2=80=9D fo= rm and prepare a short =E2=80=9Coverview=E2=80=9D talk about this for the next meetup, if in= teresting --0000000000004df52c0586e13f5a--