Hello everyone,
My name is NIKOLAI RIABOV. I am a Lead Engineer at a Russian engineering company with more than 17 years of experience in Industrial Automation and Process Control Systems for oil industry facilities.
My professional experience is related to automation of oil pipeline transportation systems, including pumping stations and other process facilities where integration of field devices, electrical equipment, control systems, and supervisory systems is required.
My main area of work is system integration, verification, diagnostics, testing, and commissioning of integrated industrial automation systems.
My work is not focused on developing PLC program code. My main specialization is verification, diagnostics, and commissioning of already integrated automation systems.
I verify that all system components — field devices, electrical equipment, controllers, communication systems, and control software functions — correctly interact with each other as a complete solution.
During my projects, I work with different levels of industrial automation systems, including:

• field instrumentation and actuators;
• electrical control panels;
• I/O systems;
• PLC-based control systems;
• industrial communication networks;
• SCADA/HMI systems.

My typical activities include:

• Factory Acceptance Testing (FAT);
• Site Acceptance Testing (SAT);
• commissioning and startup support;
• verification of signals from field level to control systems;
• checking analog and digital signals;
• testing control algorithms, interlocks, and protection functions;
• troubleshooting technical issues during integration and commissioning;
• root cause analysis;
• verification of corrective actions after identified issues are resolved.

In complex industrial automation projects, many problems cannot be assigned to only one component or one engineering discipline. They often occur at the interfaces between different parts of the system.
For example, a problem with information display or control function operation may be related to:

• field equipment;
• electrical connections;
• I/O module configuration;
• communication between devices;
• controller configuration;
• SCADA/HMI;
• engineering documentation.

Therefore, troubleshooting requires analysis of the complete interaction chain — from field devices to control systems and operator interfaces.
I would like to ask engineers working in industrial automation, system integration, and commissioning:

1. How is this type of engineering activity usually defined in your companies?
2. Do your organizations have a separate engineering function responsible for system integration testing, verification, and diagnostics of complex automation systems?
3. What job titles are commonly used for specialists performing these activities?
4. How important is experience in system integration, diagnostics, and commissioning for modern industrial automation projects?
5. Who usually performs these tasks in your companies: Controls Engineers, Commissioning Engineers, System Engineers, or specialists from other areas?

I am interested in understanding how this type of engineering function is defined and organized in different industrial organizations, especially in companies working with complex automation systems and critical process facilities.
I would appreciate professional opinions and comments from engineers working with industrial automation, process control, system integration, and commissioning.
Thank you.

 

all of the above, and don't forget the operation and maintenance staff that run the plant, or the engineering construction team. What is just as interesting, in dealing with multinational teams and languages, the the goal is a reliable and safe design.

 

all of the above, and don't forget the operation and maintenance staff that run the plant, or the engineering construction team.

Hello Dave,

Thank you for your comment.

I agree that operation and maintenance staff are an important part of the overall process.

I would like to clarify one point. In your experience, during the development, integration, testing, and commissioning stages (before the system enters normal operation), is there usually one person or one engineering role that coordinates the overall system integration process?

For example, someone who follows the system through its lifecycle:

• design review;
• integration of different subsystems;
• Factory Acceptance Testing (FAT);
• Site Acceptance Testing (SAT);
• commissioning;
• troubleshooting of issues between different engineering disciplines;
• final verification before handover to operations.

Does this role exist in your organizations? If yes, what job title is usually used for this person?

Thank you for sharing your experience.

 

"I would like to clarify one point. In your experience, during the development, integration, testing, and commissioning stages (before the system enters normal operation), is there usually one person or one engineering role that coordinates the overall system integration process?"

All organizations have a manager of the over all project. They are often called the bean counters, as they are concerned predominantly in costs over runs and completion dates.

As one engineering professor remarked, those who finish with high grades, often end up working for those having less desirable grades. Basically, those that manage the project are more business like in there priorities. Don't forget all projects need both.

 

"I would like to clarify one point. In your experience, during the development, integration, testing, and commissioning stages (before the system enters normal operation), is there usually one person or one engineering role that coordinates the overall system integration process?"

All organizations have a manager of the over all project. They are often called the bean counters, as they are concerned predominantly in costs over runs and completion dates.

As one engineering professor remarked, those who finish with high grades, often end up working for those having less desirable grades. Basically, those that manage the project are more business like in there priorities. Don't forget all projects need both.

My role is basically to stick my nose into almost every technical part of the system before startup. I check how PLC/SCADA, communication networks, electrical circuits, instrumentation, and field devices work together as one system. If something doesn’t work, I try to localize where the problem actually is, get it corrected, and then retest everything before handover.


I usually handle the technical side of the system from internal testing all the way through commissioning and startup: internal checks, factory acceptance testing with the customer, testing at the customer’s site, technical coordination of installation work, commissioning, integrated system testing, and final startup.


And yes, during that process I basically have to “stick my nose” into almost everything, because the problem can be anywhere — in SCADA, the PLC, communication networks, electrical circuits, instrumentation, or the field equipment itself.

 

Apart from the design and purchase phase, you have construction completion checks and testing, then pre-startup testing, and finally operational and shutdown testing. You are on the right track.

 

Apart from the design and purchase phase, you have construction completion checks and testing, then pre-startup testing, and finally operational and shutdown testing. You are on the right track.

I’m interested in a broader question about industrial automation projects: how companies capture problems found during integration and commissioning, how they prevent the same issues from recurring, and how lessons from one project are carried over to future projects.

In complex control systems, some problems only become visible during FAT, SAT, system integration testing, or commissioning, especially issues involving the interfaces between PLC/SCADA, communications, instrumentation, electrical systems, and field equipment.

I’m interested in how companies deal with these problems after they are found:

• How are deficiencies normally documented and tracked?
• Is there a formal corrective-action and retest process?
• How are lessons learned transferred to later projects?
• Are recurring problems added to checklists, test procedures, design standards, or internal engineering practices?
• Have you seen cases where a problem found on one project led to changes that prevented the same issue from happening on other projects?

I’m especially interested in practical examples from engineers involved in FAT/SAT, integration testing, troubleshooting, and commissioning.

I’m also interested in how important these procedures are considered within system integration companies. Are they treated as a formal part of engineering quality and project delivery, or are they handled more informally depending on the project and team? How much attention do integrators typically give to preventing repeat problems across future projects?

 

Companies rely on those who are able to identify the flaws in the automation, given an understanding of the process and the project goals, the sensors, and actuating devices. It is not a teachable subject.