plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uschold Andreas <Andreas.Usch...@tgw-group.com>
Subject Feature prospect of project plc4x
Date Tue, 11 Sep 2018 13:26:29 GMT
Hi all,

In early 2017 we started the development of a Java based visualization / SCADA in the context
of ware houses and logistic centers. One design goal was (and still is) to be able to use
the system in a transparent way with any kind of data source, not only PLCs, but also network
equipment, embedded systems, building technology, IT hardware and high level IT processes
(e.g. ERP). So we developed a modular platform very similar to what is available in PLC4X
now. We already implemented PlugIns for the S7 and Beckhoff AMS communication from scratch,
Allen Bradleys CIP and SNMP are next in line.
The goals and the design of PLC4X seem to be pretty similar to ours. We want to evaluate whether
we can expect mid-term or long-term benefits by switching over to plc4x and participate in
its develoment process.

Until now i identified two functional aspects plc4x doesn't seem to address which are very
important to us.

The first aspect is a normalized, hierarchic, human readable namespace, just like a table
of contents for any device.
Each variable on a PLC can be represented as a "data point" and provides information on how
to gather the real data from a data source (e.g. just a mapping to an address (s7://...) or
even more complex transformations). In case of AMS or OPC it is straight forward to read the
namespace information from a device. With S7 you still can make use of the information provided
by the SZL and offer "raw namespaces", representing I/Q/F/T/C/DB as big byte arrays / word
arrays. Import the information from a Step7 project is also no witch craft.
Mostly frontends benefit from this concept.
I know about the PlcLister-Interface, but it is just empty and even the AdsTcpPlcConnection
doesn't provide an implementation. Are namespaces the way described above on the road map
or at least in scope?

The second aspect is throughput optimization and request reorganization.
Protocols like S7 and CIP have very strong restrictions on the the amount of data which can
be fetched with one telegram. If one request addresses to much information, it should be up
to the connection to split the request transparently and join the partial responses. The current
state of PLC4Js s7-driver just cuts of after 19 items in one telegram. All surplus items are
silently ignored. Thus a user must know about the limitations of the underlying protocol and
must design requests accordingly.
On the other hand most requests are probably very small (ints, words, even only a bit). Reading
only those individually each with one call renders bandwith to nearly zero.
Often fetched data is adjacent to another relevant information. Requests could be merged so
effectively more data can be fetched within one telegram.
In most of our scenarios it is not important to have the "fresh" read value, but to have a
_recent_ value. A value read up to three seconds ago is sufficient for most our use cases,
especially since most values can be considered as volatile on the PLC side. We have a bunch
of independent systems which need to gather a lot of information from one PLC. Some information
is gathered only by one system, some information by all systems. Sometimes relevant information
is accumulated in one memory area, sometimes it is fragmented over the entire PLC.
With a central component coordinating and optimizing all current requests, it is possible
to take the burden of taking care about through put from the user of the library, optimize
the throughput for everyone and eliminate duplicate reads from different systems by sharing
data.
Right now i don't see any efforts regarding this in PLC4J.

I would like to hear your optinions on these two aspects and whether it is relevant for the
PLC4X project.


Best regards
Andreas


Mime
View raw message