October 19, 2005
Our last meeting with the prime consultant and city was on 9/23. In that meeting it was agreed that employing standard Ethernet communications was the preferred architecture for the project. In hopes that it would speed things along, I gave our engineers approval after that meeting to consider alternative architectures employing Ethernet HMIs and controllers with an alternative direct Ethernet cell radio. We considered solutions available in the same price range as the RTU and HMI that was to be provided on the previous (now expired) contract. We tested the most promising alternative. The tested alternative also included a cost-effective 0-55 degree C Ethernet switch/router/firewall.
The capabilities of the tested architecture/hardware/software (not specifically mentioned in the original spec but desirable) include:
1. Elimination of most relays and all analog isolators:
a. Digital I/O is individually isolated (necessary to work with separate CPTs in motor starters and VFDs unless relays are added);
b. Analog inputs (differential) are optically isolated so that station 4-wire drive speed feedback and flow inputs stay isolated from one another;
c. Analog outputs are optically isolated so drive speed reference outputs stay isolated from one another; and
d. The 2-wire analog input (differential) from bubbler pressure transmitter powered by panel 24V dc power supply, is isolated from all 4-wire inputs
2. Centralized configuration management for the RTU and HMI (the city has had definite problems with this in past), which makes it easy for maintenance personnel to maintain the system. a. RTU and HMI can be reprogrammed over the cell network from one of the SCADA servers (by QDS Systems or the city using remote terminal server administration, from any authorized Internet-connected computer); b. RTU and HMI have common IP addresses at all sites; only the modem address varies. Router/firewall/switch has common configuration at all sites. This is important in that it allows any of these parts to be changed without needing to use a notebook computer to set an IP address (in other words, they need only one spare of each type of device and we pre-configure all the spares with the default IP address). Because Verizon takes awhile to setup cell accounts, a spare modem and Verizon account is recommended. If a modem needs to be changed, the city can change the modem, call us, and we will (from our desktop while they are on the phone) change the IP address in the OPC servers to point to the new modem’s IP address; c. HMI contains configuration of RTU. To replace an RTU controller head, replace head (5 minutes) and push download button on HMI (password protectable). We can also, from our desktops, download to the RTU from the central server; d. HMI application resides on a compact flash card. To change out an HMI, replace unit (5 minutes) and move compact flash card to new unit. If flash card has been corrupted, use supplied backup flash card. We can also, from our desktops, download to an HMI from the central server; e. Setpoint changes have often been lost when controllers are replaced. This can be virtually eliminated by the HMI automatically updating its copy of the RTU program on a daily basis, including setpoints. To ensure central configuration stays current without incurring excessive cell traffic, we recommend that RTU configurations be transmitted from the local HMIs to the central server on a monthly basis; and f. HMI has the same look and feel as the central HMI, reducing the operator and maintenance personnel learning curve.
Since the selection of a supplier for this equipment is still undecided, we will reveal results of our testing and specific vendors in a later blog posting.
Are there other possible solutions? Certainly. Is our proposed solution a stronger technical and maintenance solution than the previously approved Modbus SCADA RTU and proprietary HMI? We believe so. It is low risk for us as we have experience using this hardware and software successfully, and have fully tested it for use in the city’s particular configuration. Importantly, it is compatible with what we are providing in the other phases without adding cost to those phases.
We spent considerable engineering time checking out the previously approved Modbus SCADA RTU and proprietary HMI alternative before we bid the Phase III SCADA and Phase IV communications contracts to verify we could meet performance requirements and to factor in how much time it would take us to develop on those platforms. We have again done this for the above suggested configuration at our cost. We have already done twice the normal checkout for free.
Of course, additional system configurations will need to be tested and approved by us to guarantee system performance. We will need to charge for this testing. As the prime engineering consultant also has to account for each hour, we trust they will understand that we may also need to charge additionally for our engineering on Phase III and Phase IV if we estimate the engineering development time will be longer for an alternative platform. We knew none of this extra cost was going to be very palatable, which prompted us to test and offer an alternative system. The proposed system meets and exceeds the original specifications and, because of past experience, we know we can configure it without incurring additional engineering costs, allowing us to provide a “no additional costs” guarantee.
