🚀 The Future of Industrial Software: Who is Responsible Post-Commissioning?

[Süeda Asil]

Transitioning from Control Engineering to a Software Discipline​

When I started my career as a control engineer, my focus was on PLCs, HMIs, and equipment running smoothly. Questions like whether the sequence is correct, if the operator can understand it, and if the maintenance team can troubleshoot at 2 AM are still important. But over the years, these questions have led me to higher layers, such as networks, servers, virtualization, cybersecurity, and applications that connect production to the rest of the business.

As industrial automation transforms into a software discipline, a new question arises: Who will ensure all these systems remain operational after the project team leaves?

Rising Up the OT Stack: Cloud-Native Architectures​

For much of my career, the systems surrounding the PLC followed familiar patterns. We would typically install industrial software on virtualized Windows servers, connect applications, and complete the commissioning process. Now, some OT platforms are adopting cloud-native architectures. Containers, orchestration, and independent software services that perform functions like data exchange, authentication, and monitoring are becoming part of the environments that control engineers deliver and support.

The term cloud-native doesn't necessarily mean the application runs in the cloud; these architectures can also reside on-premises. However, it changes how software is deployed, how its components interact, and what maintaining the environment means. I can understand what an application needs to do for production, but I might not know every detail of its underlying platform. An infrastructure expert might understand the platform deeply but struggle to grasp why a routine change requires careful coordination with operations. This is where collaboration becomes vital.

Control System Healthy, So Why Isn't the System Working?​

Consider a facility six months after commissioning. Production is ongoing, the PLC is executing logic, and the HMI looks normal. But an application sending production information to a business system has stopped updating. The control team confirms the controller is communicating. The IT team confirms the server is accessible. The application vendor asks if there's been a network change. Meanwhile, operations are waiting for information.

Perhaps a certificate expired, a service stopped, or a security change affected an account the application relied on. Finding the cause requires people who understand different parts of the same system. It also requires someone to track the problem across these boundaries. Verifying that each component is accessible doesn't explain why the overall application isn't working. These are the dependencies we need to understand before delivering a system. Otherwise, the customer discovers support gaps during an incident.

A Working Relationship Between IT and OT is Essential​

For years, we've talked about IT/OT convergence. In practice, collaboration can still be limited to project checkpoints: approve the architecture, provision the servers, open connections, and assist during commissioning.

As industrial software becomes more connected, this relationship needs to extend into daily operations. OT understands the process and the consequences of disruptions. IT brings expertise in infrastructure, identity, security, and managing software throughout its lifecycle. It's important for both groups to sufficiently understand the other's responsibilities so they can make decisions together. An update might make sense from a security perspective but require a production outage to implement. Delaying it might preserve today's production schedule but create a growing support or security issue. These decisions require a conversation about actual plant conditions.

The practical questions are simple: How will we know if a service stops working? Who will manage credentials? Where will we test an update? How will we recover if it fails? These conversations should be integrated into project planning while the people designing the environment are still at the table.

How Can Integration Partners Help?​

Manufacturers are building teams to support these environments, but it takes time. Hiring a single person doesn't automatically cover control, networking, infrastructure, application development, and software operations. System integration partners can help customers fill this gap. Doing so requires a closer relationship than simply delivering a project and waiting for a support call.

At BW Design Group, one of the capabilities we bring to this relationship is a dedicated Industrial DevOps practice. This provides us with specialists who can work alongside our control and infrastructure teams on the deployment and continuous operation of industrial software platforms.

For someone with a background like mine, having this expertise available is important. I can bring process requirements and operational concerns into the conversation, then work with colleagues who understand how to support the platform behind the application.

Together, we can help customers build ways to monitor systems, manage changes, and recover from failures while developing their internal capabilities. We can also help determine which responsibilities the customer is ready to take on and where ongoing partner support makes sense. This arrangement should evolve as the customer's team develops.

A Better Handover Starts Before Commissioning​

Commissioning will always be a significant milestone. Getting equipment to run reliably takes real effort, and no one who has lived through a commissioning process takes it lightly. But a successful commissioning doesn't answer every question about the years that follow.

Along with the application, drawings, and training, the customer needs to understand how the environment will be supported. This includes ownership, access, monitoring, updates, and a workable way to bring IT, OT, and integration partners together when needed.

Seeing how the technology stack has evolved, especially in recent years, has changed my thinking about project delivery. I still care if the sequence works and if the maintenance team can troubleshoot at 2 AM. Now, I also want to know who they will call when the PLC is working perfectly, but the problem lies elsewhere.