What to Do When Your Automation Engineer is No Longer Available: Building Reliable Industrial Automation Support?

The production line stops at 10:42 a.m.

The maintenance electrician checks the control panel. Power is available. The PLC is running. The HMI is showing an alarm, but nobody on the current team knows why that particular interlock exists or which part of the sequence should be checked first.

The engineer who originally programmed the PLC left the company eighteen months ago. The integrator who commissioned the system is no longer available, and the latest PLC project is somewhere on an old engineering computer. Nobody is completely certain which version is running in production, and the network diagram was never updated after several machines were added.

Production is waiting.

This is not simply a staffing problem. It is a knowledge continuity problem.

Canadian manufacturers are already dealing with pressure around skilled technical resources. Statistics Canada reported that 24.4% of businesses expected recruiting skilled employees to be an obstacle during the second quarter of 2026. Another 16.9% expected a shortage of labour, while 16.1% expected difficulty retaining skilled employees. Among businesses with 100 or more employees, 39.1% expected recruiting skilled employees to be an obstacle.

At the same time, automation and other technologies continue to become part of manufacturing operations. Statistics Canada reported that 47.9% of Canadian businesses had adopted new technologies during the previous three years, while 85.7% of businesses that adopted new technologies provided training to help employees use them.

For manufacturers, these trends create a practical challenge: a production system should not depend entirely on one person’s memory, one engineer’s laptop or one integrator’s availability.

A reliable industrial automation support strategy moves critical knowledge into controlled source files, accurate documentation, tested backups, network records, employee training and dependable technical support.

Your automation engineer should be an important technical resource, not the only place where your automation system’s knowledge exists.

What Happens When One Person Knows How Everything Works?

An experienced automation engineer often carries much more knowledge than appears inside the PLC program.

They may remember why a timer was added, why a machine sequence contains an unusual interlock, which HMI screen has a maintenance function, which VFD parameter was changed during commissioning or which communication setting connects one machine to another.

Some of that information may never have been formally documented.

The PLC program can still exist, but the reasoning behind the program may be missing. An electrical drawing can still be available, but it may not show modifications made several years later. A SCADA system can still be running, but nobody may know how the original tags, alarms and communication paths were configured.

That creates a gap between having an automation system and being able to support that automation system.

The risk becomes particularly serious when the person who understands the system leaves, retires, changes roles or simply becomes unavailable during a production emergency.

A simple test for single person dependency

Pick one critical production line and ask someone who was not involved in its original commissioning to locate the following:

Several “No” answers do not necessarily mean the production system is about to fail. They show where important knowledge may still be concentrated in individuals rather than protected by the organization.

That is where a structured automation system audit should begin.

1. Recover the Automation Knowledge Before You Need It

The first step is not replacing the PLC or rebuilding the SCADA system.

Start by finding out exactly what the plant already has.

Legacy automation projects often contain several generations of files spread across engineering computers, USB drives, network folders and old project directories. A technician may have a newer version of the PLC program, while an engineer has the latest HMI project on another computer. The electrical drawings may have been updated separately, and the network configuration may exist only in an old commissioning document.

A proper audit brings those pieces together.

For every critical machine, document the control hardware, software, communication architecture, field devices, documentation and backup status. Record the PLC model, I/O modules, HMI, SCADA system, VFDs, remote I/O and relevant industrial network equipment.

Then identify where the editable project files are stored, which versions are current and who is responsible for maintaining them.

A useful automation record should include:

• PLC hardware and engineering project
• HMI project and tag information
• SCADA application and configuration
• VFD parameters and communication settings
• I/O information
• Electrical drawings
• Industrial network information
• Engineering software and version requirements
• Known modifications
• Backup location
• Recovery procedure
• Internal and external support contacts

This information becomes the foundation for future industrial automation services and makes technical assistance much more efficient.

A support engineer should not have to spend the first several hours discovering which PLC is installed before actual troubleshooting can begin.

2. Protect the Actual PLC, HMI and SCADA Source Code

One of the most important lessons in legacy automation is that a running controller does not necessarily mean the plant has the complete engineering project.

A PLC may be operating perfectly while the manufacturer has no current editable source project.

A controller upload can be useful, but it may not contain every element that existed in the original engineering environment. Depending on the platform, comments, symbolic information, project organization, libraries, HMI files, SCADA configuration and other engineering information may not be available from the controller alone.

The same issue can occur with HMI and SCADA systems.

A manufacturer should know where the editable engineering projects are stored and which version is approved for production.

A file called PLC_Final_Final_2 sitting on an engineer’s desktop is not a reliable source code management system.

The company needs a controlled storage location, clear naming, revision information and defined responsibility for updates.

The goal is not simply to have a copy of the program. The goal is to know which program is current, where its engineering files are stored and how the system can be restored or modified safely.

3. Use Version Control to Prevent the “Which Program Is Running?” Problem

Automation modifications often happen under production pressure.

An engineer changes a timer, adjusts a sequence, modifies an interlock, downloads the program and confirms that the machine runs. Production resumes, and the engineer moves on to the next issue.

Months later, another engineer finds an older project file.

Now there are several versions of the same PLC program, and nobody is completely certain which one is running.

That situation can make an otherwise straightforward troubleshooting task much harder.

A simple revision process can prevent it.

The process does not need to be complicated.

The important point is that the plant should be able to answer one question quickly:

Which PLC, HMI or SCADA program is currently approved for production?

That information is invaluable during automation troubleshooting because engineers can compare known revisions instead of guessing which modification may have changed system behaviour.

4. Build Backups Around Recovery, Not Just File Storage

Many manufacturers believe they have automation backups because someone once copied a PLC program to a USB drive.

That is not enough.

The backup may be two years old. The PLC may have been modified several times since then. The engineering software required to open the project may no longer be installed. The PLC project may exist while the HMI and SCADA files are missing.

A useful backup strategy needs to answer four practical questions:

• What is backed up?
• Where is it stored?
• How current is it?
• Can the system actually be restored?

The Canadian Centre for Cyber Security recommends regular backups and emphasizes testing restoration procedures rather than assuming a backup will work when it is needed. Its industrial control system guidance also highlights the importance of maintaining backups and addressing unsupported systems and outdated components.

For a manufacturing environment, backup planning should extend beyond PLC logic.

Consider:

• PLC programs
• HMI projects
• SCADA applications
• Industrial PC configurations
• VFD parameters
• Network configurations
• Robot programs
• Engineering software information
• Electrical documentation
• Critical system records

Backup is Not the Same as Recovery

A backup is a copy.

Recovery is the ability to use that copy to restore the system.

That difference becomes critical during a production emergency. A manufacturer may have the correct PLC project but no compatible engineering software. The latest SCADA files may exist but require a database configuration that was never preserved. The program may be current but the network information needed to reconnect the equipment may be missing.

A practical recovery process should identify:

What failed

↓

Which files are required

↓

Where those files are stored

↓

Which software is required

↓

Who is authorized to restore the system

↓

How the restored system will be tested

PRO TIP

Test recovery during a planned maintenance window instead of discovering a problem with the backup during a production shutdown.

A backup that has never been tested is an assumption.

A tested recovery process is an operational capability.

5. Document the Industrial Network Before a Communication Fault Occurs

A machine that stops communicating can create a difficult troubleshooting problem because the visible symptom does not always identify the actual cause.

The PLC may be healthy.

The VFD may be healthy.

The SCADA application may be healthy.

The actual problem may be somewhere in the communication path.

Without a network diagram, technicians can spend valuable time checking individual devices without knowing how those devices relate to one another.

A useful network record should identify the relationships between:

• PLCs
• HMIs
• VFDs
• Remote I/O
• Industrial switches
• SCADA servers
• Engineering workstations
• Connected production equipment

Device names, addresses and relevant communication relationships should also be recorded.

This information supports both PLC support and SCADA support because communication problems frequently cross several layers of an automation system.

The Canadian Centre for Cyber Security recommends careful management of remote access and appropriate security controls for industrial control environments.

Good network documentation therefore supports operational troubleshooting as well as responsible security management.

6. Use One SCADA Fault to Test the Whole Support Process

Consider a common production complaint:

“The SCADA screen stopped updating.”

The first reaction may be to blame SCADA.

The actual problem could be somewhere else.

The information path may look like this:

Field device

↓

PLC input

↓

PLC logic

↓

Industrial network

↓

Communication service

↓

SCADA server

↓

SCADA tag

↓

Operator screen

A failure anywhere along that path can create a similar symptom for the operator.

That is why effective SCADA troubleshooting cannot always be performed by looking only at the SCADA application. The support process may need to examine PLC diagnostics, network status, communication services, SCADA tags and field conditions before identifying the actual cause.

This is also why manufacturers can benefit from an industrial automation support provider capable of working across PLC, HMI, SCADA, networking and control systems.

A production problem may begin at one layer and become visible at another.

7. Turn One Engineer’s Memory into Plant Knowledge

The most valuable automation information may never have appeared in the original drawings.

It may exist only in someone’s experience.

For example, an engineer may know that a conveyor will not start when a particular upstream permissive is missing. They may know which PLC bit represents that condition, where the condition appears in the diagnostics screen and which recovery procedure normally restores the machine.

That knowledge is extremely valuable during a production interruption.

It should not remain in one person’s memory.

Document the areas that normally depend on experience:

• Machine sequences
• Start conditions
• Stop conditions
• Interlocks
• Critical alarms
• Reset procedures
• Manual operation
• Automatic operation
• Communication dependencies
• Known unusual logic
• Common failure conditions
• Recovery procedures

The objective is not to produce a huge manual that nobody reads.

The objective is to capture the knowledge a qualified engineer would otherwise have to rediscover.

8. Create a Troubleshooting Playbook for Critical Production Equipment

A maintenance team does not need a 200 page document sitting in a folder that nobody opens during an emergency.

A concise troubleshooting playbook can be much more useful.

For each critical production system, document the first diagnostic steps for common problems.

Machine will not start

The technician should know which control power, permissive, PLC status, safety condition, output and drive status should be checked first.

PLC fault

The documentation should identify where diagnostics are available, what common conditions should be reviewed and when the issue should be escalated.

Communication fault

The playbook should identify affected devices, relevant network equipment and the communication path connecting them.

VFD fault

The record should show where fault information appears, where parameters are stored and which conditions should be checked.

Sensor fault

The technician should know the corresponding PLC input and the expected signal state when the sensor operates.

HMI problem

The first diagnostic step should determine whether the issue is local to the operator interface or related to PLC communication.

SCADA problem

The team should check the underlying PLC data and communication path before assuming that the supervisory application itself has failed.

This creates a repeatable starting point for automation troubleshooting and gives an external support engineer better information during remote assistance.

9. Remote Industrial Automation Support Can Reduce the Impact of Skills Gaps

A manufacturer may have experienced maintenance electricians and mechanical technicians without having advanced PLC, SCADA or industrial networking expertise available at every hour of the day.

That is where remote industrial automation support can provide practical value.

For suitable problems, an authorized support engineer may be able to review PLC diagnostics, program logic, HMI behaviour, SCADA alarms, communication status, VFD faults and network information without immediately travelling to the facility.

This can reduce response time for software, programming and communication issues.

Remote access must be controlled carefully. The Canadian Centre for Cyber Security recommends that remote access to industrial systems be managed carefully, limited to authorized users and protected with appropriate security measures.

A responsible remote support arrangement should define:

• Who can connect
• When access is permitted
• Which systems can be accessed
• How access is authenticated
• How activity is monitored
• How access is removed after the support session

Remote support should improve technical response without creating unnecessary exposure to the plant’s control environment.

10. Establish Technical Support Before the Next Production Emergency

Many manufacturers establish an external support relationship only after a serious automation failure.

That creates additional pressure because the support engineer has to learn the system while production is already stopped.

A better approach is to establish technical support while the plant is operating normally.

An automation specialist can become familiar with the PLC platforms, SCADA environment, industrial network, HMI configuration and critical production equipment before an emergency occurs.

The relationship can then support:

This is where industrial automation services become more than emergency assistance. They become part of the plant’s long term technical capability.

11. Build Ongoing Support Around the Plant’s Actual Risk

Not every automation system requires the same level of technical support.

A standalone conveyor may need basic documentation and backup protection. A critical production line may require faster response, regular backup verification and deeper system documentation.

A facility operating several PLC platforms, SCADA applications, robots and industrial networks may need a more structured programme.

A practical support model can be organized into four layers:

This changes the relationship with automation.

The plant is no longer relying on:

“Call someone when the machine stops.”

Instead, it has a process for maintaining the technical knowledge and capability required to keep its control systems reliable.

12. Audit Legacy Automation Before It Becomes an Emergency Project

Legacy automation is not automatically a problem.

A PLC can operate reliably for many years. An older SCADA system can also continue serving production needs when it is properly maintained and supported.

The risk appears when the plant no longer has the information, software, hardware support or technical knowledge required to maintain those systems.

Look for warning signs such as:

• Missing PLC source files
• Unsupported PLC hardware
• Old engineering software
• Incomplete electrical drawings
• Unknown network configuration
• Unverified backups
• Obsolete HMI computers
• Unavailable replacement components
• Unknown access information
• Programs understood by only one person

Several of these conditions appearing together should trigger an automation system audit.

The Canadian Centre for Cyber Security recommends updating or replacing unsupported industrial control systems and outdated components where practical, while recognizing that continuous operation can make such changes difficult.

The practical lesson is important: modernization should be planned around production requirements rather than triggered only by failure.

13. Separate Reliability Work from Automation Modernization

Not every old automation system needs to be replaced.

Sometimes the PLC is reliable and only the documentation requires attention.

Another plant may have current source files but outdated network equipment.

A third plant may have obsolete controllers that should be replaced before replacement components become difficult to obtain.

The correct response depends on the actual condition of the system.

This approach avoids recommending a complete replacement simply because equipment is old.

The first question should be:

What is creating the operational risk today?

14. Create a Machine Knowledge Package for Every Critical Production Line

A machine knowledge package brings the important information about a critical system into one controlled record.

The package should contain enough information for a qualified engineer to understand the system without depending on informal conversations with the person who originally programmed it.

Equipment information

Machine name, location, manufacturer, model and production function.

Control information

PLC, HMI, SCADA, VFDs, remote I/O and related controllers.

Software information

Project files, versions and required engineering software.

Electrical information

Drawings, I/O information and panel details.

Network information

Addresses, switches and communication paths.

Recovery information

Backup location and restoration procedure.

Modification history

Major changes made after commissioning.

Support information

Internal contacts and external technical resources.

The result is simple but powerful.

A new engineer has somewhere to start.

More importantly, the next engineer does not have to reconstruct the entire automation system from zero.

15. Train the Maintenance Team Around the Actual Automation System

Documentation is valuable, but people still need practical knowledge.

Training should focus on the equipment the maintenance team actually operates and supports.

A technician should know where PLC diagnostics are located. An electrician should understand how a VFD communicates with the controller. An engineer should know how the HMI, PLC and SCADA layers relate to one another.

Good training uses the plant’s own equipment.

Ask:

How does this machine decide that it is ready to start?

Which PLC inputs are part of the start permissive?

Where does this HMI value come from?

What happens when this VFD reports a fault?

Which network path connects this remote I/O station?

What should be checked before changing PLC logic?

Statistics Canada reported that 39.8% of Canadian businesses used in house training with internal resources and staff to address skills gaps during the previous year. Among businesses with 100 or more employees, 71.1% used in house training for this purpose.

For manufacturers, this reinforces an important point: automation investment needs knowledge transfer alongside technology.

The Goal is Not to Replace Skilled Automation Engineers

Documentation does not replace engineering expertise.

A skilled automation engineer remains essential for complex PLC programming, SCADA development, commissioning, system modifications, integration and difficult fault diagnosis.

The purpose of documentation is different.

It gives that engineer a reliable starting point.

A well documented system allows an experienced specialist to spend time solving the actual production problem instead of searching for the correct program, reconstructing the network architecture or decoding undocumented machine logic.

The plant is not trying to eliminate expertise.

It is trying to stop expertise from disappearing when one person leaves.

A Mature Industrial Automation Support Model

Reliable support should operate as a continuous cycle rather than a series of emergency interventions.

Document

Capture the automation architecture, source files, electrical drawings, network information and operating knowledge.

Protect

Maintain current backups, revision history and tested recovery procedures.

Monitor

Review critical systems, obsolete hardware, recurring faults and documentation gaps.

Respond

Use qualified PLC support, SCADA support and automation troubleshooting when problems occur.

Improve

Modernize weak areas, update documentation and strengthen the system after significant changes.

This creates an automation environment that becomes stronger after every support intervention.

A recurring PLC fault should result in more than a temporary fix. The cause should be documented, the program revision should be saved, the backup should be updated and the troubleshooting information should be added to the plant’s records.

That is how reactive support becomes long term reliability.

Is Your Automation System Dependent on One Person?

A manufacturer should be able to answer several questions without calling the engineer who originally built the system.

• Where is the latest PLC program?
• Where is the HMI project?
• Where is the SCADA configuration?
• Can the industrial network be mapped?
• Can the system be restored from backup?
• Are the electrical drawings current?
• Does maintenance understand the critical machine sequence?
• Who can provide PLC support during a production interruption?
• Who can provide SCADA support when communication fails?
• Who can perform automation troubleshooting when the original engineer is unavailable?

A “no” answer does not mean the plant needs an immediate system replacement.

It means the plant has identified an automation support gap.

That gap can be addressed through documentation, system audits, backup management, training and qualified external support.

Five Actions to Take Before the Next Automation Emergency

Manufacturers dealing with a departed automation engineer do not need to solve every problem in one project.

Start with these five actions.

1. Find the current programs

Locate the PLC, HMI, SCADA, robot and VFD project information.

2. Verify the backups

Check dates, versions, software requirements and restoration capability.

3. Document the control architecture

Record PLCs, I/O, network devices, communication paths and major equipment relationships.

4. Audit the knowledge gaps

Identify undocumented sequences, interlocks, modifications and obsolete components.

5. Establish technical support

Create access to qualified PLC support, SCADA support and automation troubleshooting before the next major production problem.

This approach gives the plant a practical starting point without forcing an immediate full system replacement.

Why Knowledge Continuity Matters to Canadian Manufacturers

The Canadian labour environment makes knowledge continuity increasingly important.

Statistics Canada reported that recruiting skilled employees was an expected obstacle for 24.4% of businesses during the second quarter of 2026. Among businesses with 100 or more employees, the figure was 39.1%.

At the same time, nearly half of Canadian businesses had adopted new technologies during the previous three years, and most technology adopters provided training to support employees.

For manufacturers, these developments are connected.

Automation is becoming increasingly important, while access to people who understand increasingly complex production systems cannot be taken for granted.

A manufacturer that invests in automation also needs to invest in the ability to maintain, troubleshoot and recover that automation.

Documentation, source code management, training, backup verification and technical support are therefore part of production resilience.

What Reliable Industrial Automation Support Should Actually Deliver

Good support should leave the plant stronger after a problem has been solved.

Suppose a manufacturer experiences a recurring PLC fault.

A support engineer investigates the program, identifies the cause and helps restore production.

That is useful.

The stronger outcome comes next.

The fault is documented.

The PLC revision is recorded.

The backup is updated.

The troubleshooting procedure is improved.

The affected documentation is corrected.

The maintenance team receives the relevant information.

Now the plant has gained something from the incident.

The next engineer does not have to rediscover the same information.

That is what separates reactive assistance from a mature industrial automation support programme.

Frequently Asked Questions

What should a manufacturer do when the engineer who programmed its PLC is no longer available?

Start with an automation system audit. Locate the latest PLC, HMI and SCADA project files, verify backups, document the industrial network and identify undocumented machine logic. Establishing qualified PLC support and automation troubleshooting resources can then reduce the risk of future production interruptions.

Why is PLC source code important?

A controller may contain the active control logic, but the original engineering project can contain important information required for modification, troubleshooting and future development. Source files should be stored in a controlled location with clear revision information.

What should be included in an industrial automation backup?

A useful backup strategy can include PLC programs, HMI projects, SCADA applications, VFD parameters, network configurations, robot programs, electrical documentation and the software information required to restore the system.

How often should automation systems be backed up?

The schedule should match the criticality of the equipment and the plant’s recovery requirements. Critical systems need a defined backup process, version identification and tested restoration procedures. The Canadian Centre for Cyber Security recommends regular backups and testing recovery procedures.

What is the difference between PLC support and automation troubleshooting?

PLC support can include program review, diagnostics and controlled programming changes. Automation troubleshooting looks at the wider control system and can involve PLCs, HMI, SCADA, VFDs, networks, instrumentation and communication paths.

Can SCADA support be provided remotely?

Many SCADA configuration, diagnostic and communication problems can be investigated remotely through properly secured access. Physical equipment faults and certain electrical issues may still require an engineer or technician on site.

Why is network documentation important for industrial automation?

PLC, VFD, HMI, remote I/O and SCADA systems often depend on industrial communication networks. A documented network makes it easier to identify affected devices, communication paths and potential causes when equipment stops exchanging information.

Should a manufacturer have an ongoing automation maintenance agreement?

A planned support arrangement can make sense for critical production systems, legacy equipment or plants with limited internal automation expertise. The scope can include backups, system audits, troubleshooting, documentation reviews, programming support and modernization planning.

Does losing the original automation engineer mean the PLC system needs to be replaced?

Not necessarily. A reliable PLC can often continue operating for many years. An audit should first identify the actual risks, such as missing source files, unsupported hardware, poor documentation, obsolete software or repeated faults. Targeted improvements may solve the problem without replacing the complete control system.

Your Automation System Should Not Become a Mystery When One Engineer Leaves

The most dangerous part of losing an automation engineer is not losing access to a particular person.

It is discovering that critical knowledge about the production system left with them.

The PLC may still be running. The SCADA system may still be collecting information. The machines may still be producing. Then one unusual fault exposes missing documentation, outdated backups, unknown network connections and undocumented programming decisions.

For Canadian manufacturers dealing with skilled labour pressure while continuing to adopt new technologies, that knowledge gap can become a genuine operational risk.

The answer is not to depend on one replacement engineer.

Build a support structure around source code management, version control, tested backups, network documentation, machine knowledge, maintenance training, system audits, secure remote assistance and ongoing technical support.

Reliable industrial automation support should make the system easier to understand, easier to troubleshoot and easier to recover.

Most importantly, it should give the next qualified engineer somewhere to start.

Your automation system should be understandable, recoverable and supportable even when the person who originally built it is no longer available.

For Canadian manufacturers dealing with legacy PLCs, undocumented SCADA systems, recurring automation faults or limited internal technical resources, professional industrial automation services, PLC support, SCADA support and automation troubleshooting can provide the technical continuity needed to keep critical production systems maintainable today and ready for future improvements.

Speak With an Automation Specialist!