Skip to content


  • Add this article to your LinkedIn page
  • Add this article to your Twitter feed
  • Add this article to your Facebook page
  • Email this article
  • View or print a PDF of this page
  • Share further
  • Add this article to your Pinterest board
  • Add this article to your Google page
  • Share this article on Reddit
  • Share this article on StumbleUpon
  • Bookmark this page

How to speed up software commissioning to deliver machines faster

Inventing something new is all well and good, but without efficient machines to automate the industrial processes, the idea is unlikely to be profitable. Addressing this challenge can be both time and resource intensive.

In our experience of bringing innovative products to market, we’ve found that commissioning is a time-critical part of the traditional design and build process. So, anything we can do to reduce the commissioning time without compromising quality will reduce the overall development time.

Commissioning is a critical path activity

The way machine developments normally go, we write the programmable logic controller (PLC) software before building the physical machine. This results in a period where the software team is waiting to test their work on the machine.

When the machine is ready, the software and mechanical teams get the machine working without product (we call this dry cycling), this focuses on checking that the machine’s individual parts do what they should. It’s then ready for process commissioning using product (we call this wet cycling), this focuses on quality and speed.

While software commissioning should be about making the machine work safely and reliably, part of its purpose is to find and fix operational software bugs. Whenever we find a bug, we need to diagnose its cause and correct the software, creating delays. So, to address this inefficiency, we developed a way to test the software without the physical machine, making use of the previously inactive time.

Leveraging software development best practice

It’s standard practice to use automated testing and continuous integration to find bugs as we develop software. However, the development tools for PLC software from major vendors make it difficult to use these approaches, which is why we created something new to tackle this challenge.

Automated testing

This allows our developers to write tests as they write PLC code. We transfer the sequences and logic we want to test in the production code to a test harness application that runs on a PLC emulator. This lets developers test behaviours without having the machine, finding bugs while the code is still fresh in their mind so they’re easier and faster to fix. By re-running all the tests, we can confirm any fixes or new code blocks haven’t ‘broken’ other parts of the software.

Continuous integration

Writing tests and code in parallel takes some extra time, but it’s off the critical path and is worth the effort due to the improved quality and shorter commissioning times, creating an overall time vs. cost benefit. Continuous integration takes some of the burden of running tests away from the developer, ensuring they run and telling the team if any fail.

How much time does this save?

We first used this technique a few years ago for a set of three machines. We estimated software commissioning would take 14 days for all three machines, but by using a PLC emulator to test the software before we finished building the machines, it took just four. We spent less time debugging code and more time getting the machines’ efficiency right. Overall, it was a smoother commissioning process, allowing the software and mechanical teams to work in tighter collaboration sooner.

Of course, we’ve now adopted this as standard practice for all our machine development projects.

Contact the author

Contact the manufacturing process innovation team