Unit testing has been around for years in mainstream software development, and variations of unit testing are used in Industrial Automation software development presently. However Industrial Automation software design, be it PLC, SCADA, Batch, MES or DCS, is just not amenable to modern day automated unit testing in the same was that say Java or C# is. Proprietary control system vendors fail to expose methods and properties to external systems sufficiently, in order to enable automated testing. Many facets of modern software development that enable automated unit testing (such as interfaces – a way of extending class behavior) are not even implemented in modern control systems, even though they have been part of IEC61131-3 standard for quite some time. (ThingWorx platform being a notable exception).
So why automated unit testing? Better quality software. And, if more justification were needed, it can save you money. But what’s the point of wasting valuable development time trying to beat a control system into a unit testing framework if the control system itself is fundamentally misaligned with unit testing? There’s no point. But testing is one third of control system development costs, so perhaps the question should be: Why is this system costing so much to test? What are the alternatives?
In fact, the alternatives are on the way to market now, notably through any control system whose development platform is integrated with a unit testing -friendly platform (e.g. the Beckhoff Twincat platform). ‘Open’ control systems that support PLCOpen or OPC UA are by their nature, more amenable to unit testing. To what extent, depends on the implementation. HAL Software’s Spike application provides an OPC UA Unit testing framework whereby Python scripting language can be used to automatically test any methods exposed through OPC UA using the AAA (Arrange, Act, Assert) pattern.
Engineers have been testing and emulating inter system communication for years using the older OPC DA technologies and an MS Excel spreadsheet, and then largely manually transcribing the results into a test protocol. Spike takes this to the next level, allowing for method ‘Faking’, i.e. the ability to emulate the response of a third party system (e.g. an ERP system) with a particular value.
Check out the 7 minute video for a brief tour of Unit testing for Industrial Automation from within Visual Studio 2013, and then ask yourself if your project could benefit from this testing approach. If your project can benefit, then the next stage is to ensure that your prospective suppliers have a ‘unit testing ready’ solution. The best way to outline the projects testing requirements is to present a ‘mock up’ or architectural Spike of not only how you wish your control system to work, but also how you wish it to be tested. That’s what Spike was designed for.
See Spike in action or try it yourself, no sign up or login required.
Comments are closed.