Commercial vs. Industrial Software Engineering: Differences & Key Tips

May 3, 2019 | 4 min read

Matthew Chartier, Senior Software Engineer

In our mission to transform industrial automation through Software-Defined Manufacturing, world class software and tools are essential. As an engineer with a background in programming software for the commercial industry, I’m constantly intrigued by how different the experience of developing code is for manufacturing processes. The engineers who program software for industrial machines operate under unique constraints, including international standards and the need to be compatible with specialized industrialized hardware, resulting in entirely different workflows than their counterparts writing commercial software.  There exists in these distinctions an opportunity to greatly improve productivity and quality-of-life for industrial software engineers. Here are the differences that I’ve found most notable, along with practical tips that industrial software engineers can take away from their commercial counterparts.

Classical Languages

The most apparent distinction between how industrial and commercial software engineers work is the set of programming languages they use. Commercial software engineers employ modern languages like Python, C Sharp, and JavaScript that are regularly updated with newer, more expressive capabilities. In stark contrast, industrial software engineers are limited to a small set of decades-old languages such as Structured Text, Instruction List, and Ladder Diagram that often lack many of the latest functionality and conveniences that make code easier to write and understand.

In the absence of these features, it becomes even more important to make good use of those which are available and abide by general best practices and design principles for software development such as separation of concerns. While Structured Text does not support classes as they are used in most object-oriented languages, features like functions and function-blocks can be used to encapsulate related state and behavior, making the PLC code easier to understand, maintain, and test.

Keeping it Real-time

The difference in the technology used by industrial and commercial engineers isn’t arbitrary, but rather the result of vastly different requirements. Commercial software (apps that interact with people and their data) can keep us waiting. If you’ve ever watched a loading screen or been inconvenienced by a “hanging” or “frozen” app, you’ve experienced this. Good developers will strive to minimize periods of unresponsiveness, but in most domains, there is some tolerance for the occasional hiccup. Industrial software can’t get stuck waiting because it controls operations that must be executed quickly, precisely, and safely. When your code directs the movement of a 100lb robotic arm, every millisecond counts.

Industrial engineers satisfy these rigid time constraints by writing real-time programs. Commercial software applications are not real-time; they are free to take as long or as short a time as is necessary to compute a result. Real-time programs must always respond within a fixed period, never missing a “deadline”. Industrial engineers must always be conscious of these time constraints and ensure that their code never takes too long to run.

The Most Open Office

Open office environments are a recent trend in the commercial software world. This can result in a noisier work environment, but with the advantage of facilitating consistent collaboration. Industrial engineers have long been accustomed to working in a particularly noisy open office environment – the factory floor! The noise level of an average factory is around 80 decibels, about the same volume as a garbage disposal and 20x louder than the music leaking from your coworker’s AirPods.

In a factory setting, politely asking those around you to quiet down so that you can focus is unlikely to be productive. The remaining option is to reduce the amount of work that is directly dependent upon being connected to a machine on the factory floor.

Industrial engineers program directly on the machine that will be running their code because they need to account for its unique specifications; they can’t write a program on just any machine with the expectation that it will run the same way on any compatible device. In commercial software development, when we are working with an external dependency that is costly to access, we sometimes build components against a simulated or mock interface until we are ready to validate the entire system end-to-end. Similar abstraction of external dependencies could enable industrial engineers to do more of their work off the factory floor, at least until they need to test their integrations and deploy to the line.

The Future is Bright

Software-Defined Manufacturing will revolutionize manufacturing by transferring the intelligence of the process from hardware to software. This effort will necessarily modernize the tools and methods that industrial engineers use to program machines on the factory floor, bringing best practices from the software industry that will improve the reusability, maintainability, and reliability of production code. Tomorrow’s industrial engineers will be equipped with tools that will enable them to work better, faster, and in greater comfort.

About the Author

Matthew Chartier is a senior software engineer at Bright Machines currently working on creating software that will make it easier for industrial engineers to program their robots. Prior to joining our team, he developed services at Amazon for Alexa Calling and Messaging. Matthew has an A.B. degree with a concentration in Computer Science and secondary field in Mathematical Sciences from Harvard University.

To learn more about our capabilities in building the backbone of AI, visit Bright Machines.