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.
