In a presumably simple migration and upgrading job, some things could be really simple when you use the black box concept. It could also gets really complicated when the black box concept is applied.
This is a presumably simple Scada upgrading project. Objective: To upgrade an old desktop PC with Indusoft Web Studio v6.1 to a new Beckhoff Panel PC equipped with latest Indusoft Web Studio v7.1
The old PC has Windows XP Prof and it is connected to a Mitsubishi PLC A series and Daikin D-bac gateway. The PLC controls the exhaust fans and pumps in various blocks of the building. As for Daikin gateway is for control of VRV located in different rooms. The Indusoft Web Studio is version 6.1
The new Beckhoff Panel PC equipped with latest Intel CPU and Windows 7 Prof. The Indusoft Web Studio was upgraded to latest version 7.1 SP3.
There are several black box assumptions made here:
1) the target devices (ie. PLC and Bacnet Gateway) are fully functional since it has been working fine with the old PC.
2) Indusoft driver remains the same even with the upgraded version.
3) cable and connection remains the same when upgrading from old to new PC.
When we arrived at the work site, we installed the new Beckhoff PC and powered it up. Then, we plugged in the serial cable that connects to the Mitsubishi PLC and tested the comms. Viola! Everything was working as expected and assumptions were correct thus far.
The "fun" comes when we plug in the Ethernet cross cable which connects to the BacNet/IP gateway. The comms fails to work. We turned to the protocol analyzer, field read/write command in IWS log. The only message we get is "device is unavailable".
In the old PC, there was a Bacnet-OPC server (from Scada Engine) that passes information through Opc-DA protocol. In the new PC, we are removing the Bacnet-OPC server and uses the build in BacNet/IP driver from Indusoft. We expects that the comms will works the same way since it's standardized on a well renown Bacnet standard.
After many attempts and trials, we decided to go really deep into the protocol by using Wireshark to monitor the network traffic and protocol send between the 2 devices. Only then did we realize that the Daikin BacNet Gateway is totally ignoring all the read commands from the new PC.
Therefore, our black box assumptions could be wrong after all. We have no idea what to expect from the BacNet gateway and we can't tell for sure if the target device is functioning properly.
Our 2nd assumption on the Indusoft driver could also be wrong too. As the older Indusoft project uses OPC-DA, by assuming that things will works the same when we use BacNet/IP in replacement is a big mistake.
At the end of the day, we'll need Daikin specialist to provide us with professional advice if these assumptions are to be proven correct or not. That's just parts and parcels of an engineer life. Debug!
After many attempts and trials, we decided to go really deep into the protocol by using Wireshark to monitor the network traffic and protocol send between the 2 devices. Only then did we realize that the Daikin BacNet Gateway is totally ignoring all the read commands from the new PC.
Therefore, our black box assumptions could be wrong after all. We have no idea what to expect from the BacNet gateway and we can't tell for sure if the target device is functioning properly.
Our 2nd assumption on the Indusoft driver could also be wrong too. As the older Indusoft project uses OPC-DA, by assuming that things will works the same when we use BacNet/IP in replacement is a big mistake.
At the end of the day, we'll need Daikin specialist to provide us with professional advice if these assumptions are to be proven correct or not. That's just parts and parcels of an engineer life. Debug!
No comments:
Post a Comment