When I was first made aware of Trihedral Engineering’s trademarked marketing claim to “the industry’s most powerful SCADA software” in VTScada, I’ll admit to being a bit skeptical. The claim seemed to overstate the status of a relatively small player from Nova Scotia—and certainly represented more hubris than I’d come to expect from our customarily modest neighbors to the north.
But over the past several years, I must admit I’ve gained a new respect for the unique ways in which VTScada—and Trihedral—stand apart in the industrial software arena. And when I attended VTScadaFest for this first time this year, I was at first impressed by the confirming claims of Harshad Bhagwat, CTO of Itanta, a developer of no-code dashboarding and analytics software, who related the company’s experience with VTScada.
“We work with many SCADA software makers,” Bhagwat said, “but the kind of performance we can deliver working with VTScada is unheard of.” His company had benchmarked the speed with which VTScada delivered data to his company’s software, and found it outperformed another popular and well-known SCADA package by speeds of nearly 100 to 1. “It was so fast, we thought it wasn’t working,” Bhagwat said.
And it’s not just performance claims that raise eyebrows. Another is that any application written for VTScada since 1990—that’s more than three decades—has consistently run without modification on the very latest update of VTScada, now approaching release 12.1.
So, it was with great anticipation that I attended the VTScadaFest session entitled, “Philosophy Behind VTScada,” delivered by Founder and President Glenn Wadden, to learn more of just what it is that makes VTScada so special.
A language, not an application
“VTScada is, at its core, a programming language, a visual tag system (or VTS) that generates code in the background based on what you see on the screen,” Wadden began. That visual programming language has since been web-enabled, and had VTScada scripting and other functionalities added to it, but its core has otherwise remained the same, he explained. “That’s why we have that backward compatibility—we’re always adding to it but never taking away.”
Further, the language itself is based on state logic, which at the time Wadden developed the first VTS, had not yet been applied to a software language. “State logic itself dates to the 1940s, to digital electronic circuits,” he explained. Having learned about state logic at university, he thought it made sense to implement it in software—and first did so in 1986, the year before the first paper on state logic applied to a software language emerged in 1987. “VTScada is still the only programming language based on state logic,” Wadden said.
And what is it that makes state logic special? First, it’s important to understand that software performance is inherently dependent on the number of variables interacting. Classical software programming is based on input-process-output, but data is changing, time is passing, and the more variables interact, the more things can go wrong. In fact, the number of interactions rises with the square of the number of variables, so complexity can quickly escalate.
State logic, on the other hand, “restricts the view to the things that matter, looking only at what effects a change propagates,” Wadden said. Similar to reporting by exception, this event-driven approach means the program need deal with fewer variables within an organized hierarchy. In the end, this translates to simplified code, with fewer bugs, that executes faster. “Performance is no longer dependent on scale,” Wadden added, “but how many things change.”
VTScada also gains performance from its object-orientation, which is “really valuable, but not as novel” as state logic, Wadden said. “In VTS, every tag is an object, as is every report, every form,” he said. “It was created this way because at the time there was nothing else capable of doing the job.”
Other essential features of VTScada are late binding and layering. “Late binding means you can change what happens on the fly, overriding the previous configuration without the need to recompile,” Wadden explained. “It’s especially liberating for running systems—you don’t need to shut down to make a change.” Similarly, layering refers to how applications run on top the core and inherit the qualities of core; and the same for user code on top of that. Updates to upper layers don’t affect those below.
“All contribute to overall ease of use, and forward/backward compatibility,” Wadden said, citing Ontario Hydro, which has run some applications continuously for 22 years without shutting down. “They’ve always been able to upgrade; adding rather than changing.”