We’ve said many times before that manufacturing software is fighting to make it into the last decade compared to the rest of the world. What does that mean exactly? We’re going to go through a few examples here.

Forms

Most business systems and software you interact with has some sort of data entry form involved. If you have used your company’s ERP system you will have seen countless forms, and if you have ever bought something online you are probably very familiar with the standard billing/shipping address forms.

With the proliferation of things like SPC in the manufacturing world in recent years, forms are becoming more common in manufacturing. The problem is that while forms are one of the first features you will learn how to implement on any web development technology stack, usually with built-in support for managing Create, Read, Update, Delete (CRUD) forms for whatever data model you are using, they usually require from scratch development in SCADA platforms. Heck, forms are even a built-in feature of the HTML language.

Inductive Automation teased forms as a new feature for their Perspective Module in an upcoming release at ICC 2021 during the developer panel. They are the most forward thinking SCADA platform when it comes to being able to build true business applications so this bodes well moving forward. Still it would have been really nice to have forms built-in from day 1, saving us a huge amount of development time over many projects.

Object Relational Mapping (ORM)

Hot on the heels of forms the concept of ORM is sorely lacking in the SCADA world. What ORM does is allows you to define a model of what your data looks like, then automatically maps this to the structure of your database allowing you to have a true object oriented development approach without having to actively worry about what the data looks like in the database.

ORM tools save you from having to write a lot of queries by hand, instead abstracting them away to functions. Languages like Ruby on Rails or Microsoft’s LINQ to SQL are good examples of how this works.

If we want to get all of the employees from a table in the database for a particular customer, it would look like the following in SQL:

SELECT * FROM employees WHERE company = ‘Corso Systems’

To do the same thing in something like Ruby on Rails with an ORM interface we would simply write:

employees.Where(company=’Corso Systems’)

Although this is a simple example, when in development you aren’t worried about what the database looks like, as you define a model in code and it exposes everything you need to use for your application.

The real power of ORM tools is that you can define calculations and transformations in the data model which is super useful for things we do often in SCADA like unit conversions or scaling.

As SCADA platforms move more towards database integrations and becoming full fledged business software solutions ORM tools will become more necessary long term.

Unit Testing

The other major piece of technology that would be great to adopt from the world at large is the concept of Unit Testing.

This is a little harder to implement in a typical manufacturing environment where not everyone has a digital twin, or even a development PLC to test changes against, still it would be great to be able to do things like test lots of user input on text fields to find bugs that will inevitably break things.

Unit testing essentially lets you write tests on whatever you develop and provides a way to run these tests to validate your code against the real world and perform a first-pass analysis on any bugs that might occur. As you develop and release things into production you keep all of the existing tests, then add new tests for new functionality, running everything on a build to make sure the new additions don’t break anything you had before.

This would prevent things going unnoticed before a release like an operator fat fingering 5t6 when they mean to enter 56 for a setpoint and the system not knowing what to do with the letter and things going haywire or popping up an error.

Funnily enough, according to the Ignition Developer panel at ICC 2021, Inductive Automation has a huge unit testing framework set up for the Ignition Development team. This means it isn’t a concept lost in the development of SCADA software itself, it just hasn’t bridged the gap to the implementation side yet.

Wrapping Up

None of these things are impossible to implement in SCADA solutions, they simply don’t exist out of the box. In a training class these would be called out as “an exercise for the reader”.

There are probably dozens of other things you could include on this list if you wanted to get into the nitty gritty details, however these are the few items that we most often say “it would be great if…” which means we have versions of them we have developed to help us do our projects more efficiently, just like a lot of integrators out there although having a standardized tool would make life easier for everyone without having to divulge all of the secret sauce to the rest of the world.

Do you have anything you’d like to see added to SCADA systems moving forward or tools you’ve developed to make your life as a SCADA developer easier? Let us know with the button below, we’d love to hear what you think!