As the programming world progresses at a rapid pace, developers continuously invent more efficient tools to build software. As a developer, the aim is always to focus on designing robust and efficient software while spending minimal time tapping out code.
While most of the world moves on with open software with a huge ecosystem of tools, control systems development is mostly locked down to the specific software environment enforced by the hardware vendor. Many of the development environments for PLCs were amazing tools in their time, however they have failed to innovate and keep up with the increasing demands on developers.
In this post I’ll be highlighting six critical features missing from the vast majority of control systems development software. While many have developed in-house tools to fill some of these gaps, vendors closed offerings nonetheless make such a task difficult with proprietary systems.
Automated testing is a huge productivity and reliability booster. Any highly critical system should be tested automatically every build, to ensure that no change breaks another part of the system that was thought to be unrelated. This means running a single command that exhaustively tests every component of the system automatically, on every build. Usually in less than a few minutes. When testing is automated, you no longer need to worry about the engineer that says “she’ll be right”, and deploys untested code to production.
In the world of control systems, this becomes exponentially more important. When you’re talking about software that controls large machinery and runs billion dollar industries – it’s unfathomable that a majority of code never undergoes automated testing.
Examples of automated testing tools for other languages:
C#/.NET: Ranorex (http://www.ranorex.com/), xUnit (http://xunit.codeplex.com/)
It would be unusual to find a software development outfit today that doesn’t use a version control system (VCS). Using a VCS provides not only a record of software development and the ability to revert to any point in time, it also allows collaboration – with built in project merging.
While some control system development environments do provide some method of version tracking, very few allow project merging, branching, tagging or any of the other powerful features of a modern VCS. This can make it difficult for even small teams of engineers to collaborate on one project, often resulting in only one person having a ‘lock’ on the copy of the entire project code. While VCSs can be used to version just about any file – including spreadsheets – one might expect that you could place the PLC source code file in a typical VCS. In reality this is difficult, as most PLC source code is stored in a single file or multiple binary files, preventing the VCS from doing any intelligent merging. This leaves developers in the same situation of having to keep a single master copy.
Examples of VCSs
Many PLC environments provide rudimentary debugging in the form of ‘online’ viewing. While this helps in many situations, it is difficult to see problems which occur faster than the refresh rate of the screen.
Standard programming environments provide breakpoints at a minimum to pause execution at a particular location or on a certain condition. This allows the developer to analyse the state of the system at that moment, especially where the moment would otherwise have been fleeting.
Logging provides similar utility, in that a developer can choose to output information on the execution state of the program. However logging is even more useful in production systems – when an error causes problems with production a developer first looks to the logs in order to determine the cause of the problem. Malcolm discussed an equivalent method we use in PLCs in Quantum Teleportation of Software.
Although a goal in many cases is to avoid duplication of code, in the control systems world it is often desirable to have duplicate code. For example, when diagnosing a fault on one of many motors – it’s much easier to see the fault and make changes on only that particular motor when the code is not tied up with the other motors.
However, when duplicating code there is an engineering cost associated with changes. If a change needs to be made to many of the same devices, it takes O(n) engineering time to make a single change. By avoiding duplicate code, a single change across a system should take only O(1) of an engineer’s time. If repeated code can be generated automatically you can have the best of both worlds – O(1) engineering time and complete code that an electrician can still read.
Code generation can often be implemented as part of a build process. While the worlds of C and C++ have a Makefile, which allows virtually any task to be carried out automatically on every build, the control systems world is locked to that which is provided by the vendor – which in many cases is very little.
Shortcuts for Power Users
Anybody who works with any tool for an extended period of time will inevitably learn tricks of the trade to make their process more efficient. For example, any proficient CAD drafter will know at least a few magic keyboard commands. Although the mouse was a revolution in simplifying user interfaces and reducing the learning curve of new software, even the most proficient mouse user cannot outpace a keyboard master. An engineering tool that provides a mouse-only interface is the equivalent of a word processor that has only an on-screen keyboard. There’s a reason nobody uses on-screen keyboards when writing a document.
Many control software development tools do provide at least some keyboard shortcuts for creating blocks or menu commands. However they still lack the customisability and automation that powerful programmer’s tools such as vim and emacs provide.
There are many areas in which the control systems world is yet to catch up with modern technology. But the control systems industry is one of the few remaining corners of the world where technology built in the 80’s still runs critical plant today. Change is slow in the industry, and for good reason. If it aint broke, don’t fix it. But candles weren’t broken – so why did we invent the light bulb?