Control Global’s Amplify Podcast ft. Chris Little
In recent years, rising inflation has led to increased pressure to control the cost of industrial projects. This is true of municipal utilities trying to responsibly use taxpayer dollars as well as manufacturers struggling to remain competitive. SCADA software manufacturers have always experienced this pressure.
Chris Little of Trihedral Engineering Limited, makers of VTScada monitoring and control software, recently appeared on the Control Amplified podcast with Control’s editor in chief, Len Vermillion. On the podcast, available at ControlGlobal.com/podcasts, they discussed why discounting software can never deliver the savings that industry needs. In fact, the key to unlocking those savings lies in how you use the supervisory control and data acquisition software itself.
Transcript
Len Vermillion: Chris, so discounting software is not the answer?
Chris Little: I am sure that’s a big surprise coming from a software manufacturer. For most SCADA systems, whether you are talking about a new facility or a major expansion, software is a fraction of the project’s overall price tag. It is dwarfed by the cost of construction, labor, PLCs, radio networks, and so on. As a result, there is a limited amount of savings you can wring out of one software line item.
We joke that even if we made our VTScada software completely free, with no recurring support costs, you are barely going to move the needle on the upfront or ongoing cost of your system. All you will do is end up with software that ages badly because no one is investing in keeping it up to date. We have a permanent team of developers who are putting out maintenance releases every two weeks.
Len Vermillion: What is the answer?
Chris Little: The most expensive component of any SCADA system is time. From an operational point of view, we all know SCADA systems are very good at identifying ways to save resources such as time. On their most basic level, they save operators from having to spend time travelling to every site to record readings and manage the process.
How you implement your SCADA can make a huge difference in how long it takes to design, develop, deploy, upgrade, support, and scale that system for decades.
Len Vermillion: There are a lot of stakeholders when it comes to these kinds of systems. Who are you talking to today?
Chris Little: These ideas apply right across the board from consultants, systems integrators, and of course, end users.
Len Vermillion: Let’s start with the integrators.
Chris Little: Their whole business is based on selling time and you can’t sell time you don’t have.
One of the best ways to save time is to build applications from standard features. The less you need to use script code to handroll basic SCADA elements such as trending, alarming or redundancy, the better. You should not have to cobble together applications from native and third-party components using custom scripting.
This approach significantly reduces the upfront project development time because all your components are pre-integrated. This can help you win projects by reducing the development time required. It also means that if a customer comes to you in crisis because their aging SCADA system finally failed, you can have them back up and running with a fully featured system in hours not days.
This scenario came up recently for a VTScada integrator in New England. One of their customers was afraid the Windows 7 PC running its legacy systems was about to fail. There was just enough time to make a copy before it did. It took less than a day to provide a fully featured modern SCADA system.
Another important part of that story was that we were able to convert the exported tag database from the old system so the Integrator could use it to create the new VTScada system. We were able to do that for them for free.
Using standard features helps eliminate an ongoing problem known as technical debt. Every line of code you write becomes a liability over time. Every developer has their own preferred way of scripting things. They may or may not have time to add comments to their code so others can understand it. There could have been half a dozen people writing code for the application. What happens when those developers move on? Will anyone be able to expand or troubleshoot that code? How much handholding will the system require each time the software or operating system is upgraded? Are Integrators budgeting time to manage that code into the future?
Standard features age better. Because we developed all our own technology, everything grows in lockstep with every upgrade.
Len Vermillion: Is scripting bad?
Chris Little: Not at all. Many systems contain unique functionality that requires a high degree of customization. The less you must keep reinventing basic functionality the more you can focus on the things that really do need special handling. VTScada is infinitely customizable, and it includes one of the most powerful object-oriented scripting languages on the market.
Len Vermillion: What else?
Chris Little: Support. Many small to medium size integrators only have the bandwidth to focus on bidding on and developing new installations. It is just not practical to provide ongoing support, which eliminates a valuable revenue stream. There are several ways to use your SCADA platform to make time to provide technical support.
One is application version control. In many cases, it can take time for problems that result from configuration to emerge. Application version control allows you to go back and identify the offending changes and reverse them, or simply roll back the application to the last known good version. This is an excellent way to provide timely emergency assistance to customers in need. VTScada is the only platform that includes version control as a native component. No configuration required.
The ability to provide remote support is another time saver. Many VTScada integrators report that they only need to go onsite to deal with hardware-related issues. There are two ways they typically do this. They connect to the user’s network via a VPN and make their computers a development node to their application. They make changes (or roll them back), commit those changes to all networked redundant servers, and disconnect.
The other way is to use a VTScada ChangeSet that contains all the files that make up the application in a single compressed file. A remote customer with little technical skill can easily generate a ChangeSet and send it to the integrator via FTP or email. The system integrator can install the application, make changes, and return a new ChangeSet that the customer can install without restarting the application.
In addition to eliminating hours of travel time, this can also reduce risk during months when travel is dangerous.
Len Vermillion: What about end users?
Chris Little: They certainly benefit from everything I just described for integrators.
The absolute most expensive kind of time for end users is downtime. This can mean an embarrassing loss of service, a missed quota, or an expensive lawsuit.
How you set up redundancy in your system architecture plays a critical role in eliminating downtime. How many servers do you have and where are they? When an RFP says that the new system will include redundancy, what does that mean? If it means two PCs in the same office, then you still have one point of failure. Many software platforms only support one level of server failover. That is often not enough in the event of a major weather or geological event. Make sure that the software supports multiple servers in multiple locations across a LAN or WAN.
Many smaller industrial users, including many water utilities have limited or no redundancy because of the perceived complexity and cost. They assume hot backup failover is something reserved for bigger systems with bigger budgets. Thanks to VTScada’s integrated design I mentioned earlier, advanced failover is practical for systems of any size. Configuring a redundant server, on site or at a remote location, takes seconds and requires no scripting whatsoever. To encourage customers to adopt multiple severs, we also provide discounted VTScada license bundles that you can find on our site.
Since VTScada also includes its own native Enterprise Historian, there is no need to spend time configuring a separate failover and synchronisation strategy for your historical data. VTScada does that automatically.
The other kind of time that is important to end users is system lifetime. SCADA system can take years to chose, develop, and deploy, and end users want to get the most they can from that investment. They don’t want to wake up one day to find that their software version has been discontinued or it no longer supports new operating systems. VTScada is forward compatible. We always provide a forward migration path for every version of our software. In most cases you can simply install the latest version right over the one you have installed. Since we maintain all our own features, everything works in lockstep.
Len Vermillion: How about consultants?
Chris Little: Consultants are in the business of cultivating long-term relationships with their customers. It can take a long time to win their business and build their trust. Sadly, it does not take much to lose it. One of the ways that trust can be broken is surprises like the ones I just mentioned. Namely, needing to spend time rebuilding their application because the software vendor abandoned their version. Again, VTScada was designed to scale indefinitely.
Another unhappy surprise is to find out down the road that the cost to bring their application up to date is way higher than they expected. The cost of VTScada’s optional support plan never increases while support remains current.