The Pi Connector for GE e-terraHabitat systems was apparently only written to support GE's Electrical SCADA systems (EMS/DMS) that are based on e-terraHabitat. They also have Oil & Gas Pipeline SCADA systems, also based on e-terraHabitat, known as "ETPL" (e-terraPipeline), which have a slightly different record structure for POINT and ANALOG records. Both expose their data via GE's SAMPLER technology, which at a basic level works the same for both types of SCADA systems, the difference is in the record structure related to POINTS and ANALOGS that is slightly different for each system.

The existing Pi Connector would need a minor tweak to also be compatible with the ETPL systems.

Currently, when the connector sees that I'm requesting an ANALOG record, it also attempts to read in a set of ANALOG record master data known as ALGNAM (analog name) records. The record structure for EMS/DMS systems has an ALGNAM description stored in a field named TEXT_ALGNAM. But the equivalent fieldname in the ETPL system is DESCRIP_ALGNAM. Unfortunately, when the TEXT_ALGNAM field is found to not exist, the Pi Connector stops reading any additional data. This should be a simple text-string change in the Pi Connector, for ETPL SCADA systems only.

Similarly, when it sees I've requested a POINT record, it tries to read POINT record master data from PNTNAM records. Here, there's a bigger gap in functionality. The EMS/DMS system tries to read TEXT_PNTNAM, which should map to DESCRIP_PNTNAM for an ETPL system. But it also tries to read a set of 4 TEXT##_PNTNAM records, which would contain the 4 possible statenames in an EMS/DMS system. In the ETPL system, these fields don't exist; instead, the PNTNAM records each have a series of child records named DITEXT; and each DITEXT record defines one possible STATE. This would be a more complicated change, involving a request for all defined DITEXT records, and then parsing out the PNTNAM from the resulting composite keys, and then building the required digital state sets with variable quantities of states (2, 4, 8, or 16) and populating them with the ID_DITEXT values.

Attaching pictures showing the record structure that exists in the ETPL system, and the errors encountered when attempting to read from an ETPL system.

Note that I worked with GE to test a temporary workaround involving the creation of dummy fields in the ETPL system that line up with the EMS/DMS system. But making this permanent would require re-compiling our SCADA system with the database schema update in place. It would also not have any valid data in the fields, so the resulting Digital State Sets would all have Null field values, and the descriptions would all be null as well in the Pi database.

Dear Connector Experts,

for our Enterprise data integration project we have the need to use Apache Kafka / Confluent as the "data highway".

This requires to send data to PI DA/AF from Kafka and also to read from PI DA/AF back into Kafka.
I know that there are Integrators to actually read, but I also need the write-into-PI-option.

Any comment on this if you have any plans on this would be great.
The following data types are in focus for us for this:
- Process Data (time series data) of Sensors / Actuators
- Batch Data (Event Frames)
- AF Content (Plant structure information)
- data needed to automatically create Tags (optional)

Many thanks in advance!

When running the discovery tool from a subnet with no BBMD to query BACnet devices on a separate subnet, it seems like the auto discovery tool is seen as a ‘foreign device’, so the devices do not respond correctly.

When analyzing a Wireshark trace, the discovery tool sends an ‘Original -Broadcast-NPDU’ Who-Is request to the BBMD on the other network, because it is seen as a foreign device, the request is not forwarded onto the sub-devices by the BBMD on this separate subnet. We can see that no I-am requests are sent back to the discovery tool.

As the discovery tool is seen as a foreign device, we believe it will need to use a Distribute-Broadcast-To-Network type of Who-Is request to get the BBMD on the other subnet to perform the broadcast and return the results to the tool. (Yet Another BACnet Explorer was able to discover the devices using DBTN). We believe the connector will need this functionality too unless all the BACnet devices were manually specified.

The functionality for the connector and discovery tool to be able to use this type of broadcast would be necessary for similar architectures, the ability for it to either automatically try the DBTN broadcast, or for the user to manually force the broadcast would be very helpful.

When running the discovery tool from a subnet separate from the BBMD and BACnet devices, it seems like the auto discovery tool is seem as a ‘foreign device’, so the devices do not respond correctly. There is no BBMD on the subnet the connector is on.

When analyzing a Wireshark trace, the discovery tool sends an ‘Original -Broadcast-NPDU’ Who-Is request to the BBMD on the other network, because it is seen as a foreign device, the request is not forwarded onto the sub-devices by the BBMD on this separate subnet. We can see that no I-am requests are sent back to the discovery tool.

As the discovery tool is seen as a foreign device, we believe it will need to use a Distribute-Broadcast-To-Network type of Who-Is request to get the BBMD on the other subnet to perform the broadcast and return the results to the tool. (Yet Another BACnet Explorer was able to discover the devices using DBTN)

The functionality for the connector to be able to use this type of broadcast would be good for similar architectures, the ability for it to either automatically try the DBTN broadcast, or for the user to manually force the broadcast would be very helpful.