ItemInfo / MonitoredItem: inefficient design

[ralphlange]

There is a flaw in the design of the ItemInfo and MonitoredItem objects that may lead to inefficient data transfer and reduced performance when multiple EPICS records are connected to the same OPC UA item.

Currently, each record creates its own OPCUA_ItemInfo structure, with its own copy of the data, timestamp, and set of flags (e.g. stat, noOut); each record adds a monitored item to the subscription.

In the case of multiple records connecting to the same item (e.g 32 bi records connecting to the 32 bits of a status word), that same item is added multiple times as a monitored item to the subscription. Each data change event leads to the same item update being sent multiple times over the network. Especially for array type data, this may lead to a considerable performance hit.

Some parts of the object should exist only once (i.e. per monitored item): data, timestamp, OPC status, the IOSCANPVT structure, the lock semaphore. Other parts must exist once per connected record: pointer to record fields, record related flags (record data type, noOut), the CALLBACK structure.

[bkuner]

" (e.g 32 bi records connecting to the 32 bits of a status word)" That is not they habitual way it is used. Up to now use opc and opcua is to interface a PLC where the PLC programmer splits the signals he want to process to bits if he wants to see a bit - and this bit gets a name and a link to the EPICS. Don't want to say that there will never be a status word, but I have see this only in the early years of our use of opc (MLS - RF amplifier). Our current devices have about 1000 Bits as boolean values. So I would not like to do much work on this. It would cause much work for low earning.

[ralphlange]

I see what you mean.

However, for ITER's standard PLC interface (using TCP block read/write much like the SLS/Zimoch driver) we recently had to add the status word ("packed bits") format, as our first user (the cryo system) has more than 100.000 bits to integrate. Combined with the requirement of 20Hz updates, sending a byte on the wire for every bit didn't scale well. (There's also a 32kByte limit for the block transfers.)

Actually, those cases can be handled sufficiently by using mbb[io]Direct records and doing the demultiplexing in the database.

Maybe the example database that is part of the module shouldn't use this inefficient setup, then. It should also be properly documented, warning the user that binding multiple records to a variable will create multiple subscriptions and lead to the item being sent multiple times over the wire.