From Vitali:
All, I wanted to follow up on our last meeting on the topic and provide perhaps a better business reasoning to why SPLC have implemented their communication states as they did and allow you to better understand the problem so that we can reach to other customer and see how they solve similar problem.
First, in contradiction to many our other customer that I know of, SPLC utilizing satellite communication as their preferred method of communication with the field devices. This communication method is mainly driven due to their off-shore assets where no leased line or cellular are available.
After further discussion with Matthew, he explained to me what are the pain point with this communication method. In essence, although VSAT communication is widely convenient at reaching remote location, it is not very stable. Many factors can play a role of losing comms through satellite.
In particular, clouds, rain or even a helicopter flying by, can cause signal loss to the host.
To prevent continuously communication switching between active connections back and forth, SPLC have came up with rationalized thresholds that will define after how many attempt the comms shall be considered good or bad. In essence, they allowed some flexibility based on the their communication topology (VSAT).
Second, In SPLC communications topology, there can be cases where SCADA system have partially bad comms with the field device. In this case, the SCADA system is not able to send commands (solicited messages) to the fields device however still able to receive messages from the field (unsolicited messages) as SPLC PLCs are remote poll devices. For SPLC this case is not ideal, however it is better than a complete comms out. This condition is defined as Simplex path condition.
With the introduction of this “Simplex” state SPLC in essence, have 3 communication states; Good, Simple and Failed. In the Communication path testing ADD, SPLC have outlined list of requirements that define an automatic mechanism that will test backup path and select the best communication path possible out of available paths to the field device.
To achieve this, SPLC’s mechanism is sending solicited messages to PLC counting them up and also, checking the paths for unsolicited messages from the PLC. Based on the thresholds configured, the mechanism determines the status of each path.
With this approach, SPLC preventing from SCADA system to switch communication based on intermittent problem but rather switch once the threshold was violated.
Third, As Jason advised in his email (and I observed with few as well). Our clients, disabling the automatic path selection to prevent a case of system switching comms when there are intermittent problems occur on the line and allow their SCADA operators (or appropriate personnel ) to switch comm paths for the remote.
Although, baseline OASyS records number success and fail messages, it does with respect to the hour and is designed as a solicited messages only, aka, for Host poll type communications. I think for remote poll we have a gap as its difficult to figure out when the remote will send message to SCADA.
Based on my knowledge, OASyS can solve this with the Age Watch dog. In essence, monitor the krunch time of points and make sure they are not too old. However, this a different approach to SPLC method of testing the connections.
In summary, SPLC solution is have chosen a different approach to test and failover their paths.
As you heard already, SPLC is starting a process to review their communications devices, PLCs and protocols in order to modernize them. As I understood, there are many pain point with their current converters that attached to the PLCs (micro-omni – I have little to no knowledge of these). However what I have understood Matthew, they are not planning to drop the VSAT comms and such will not have major affect on the comm stats mythology.
I hope this enough business problem points to reach out to Epco, Exel and Coch (coke?) people to see how they solve their problems.
