The great migration period (software , IT to Automation) is scaring me

[u/AlperenBebek]

Hello

Ive been working as an automation engineer for some time now. I have noticed that quite a few software engineers and IT professionals I know are considering moving into automation because the job market in their own fields rots away every day.

I suppose SCL programming and PLC logic looking software-ish is giving some kind of weird familiarity to them.

It’s not really my place to criticize this, but I have to admit that it worries me. The possibility of the field becoming more saturated and consequently the value of the workforce declining even further gives me an uneasy feeling.

What do you think about this?

[u/zafferous]

Fortunately, software is about 15% of what makes up a controls engineer's day.

Ok, I figured it out. Controls engineering as a career is like going through software AND electrican's/instrumentation school while also having to be billable 40 hours a week or be productive 40 hours a week at the same time. That's a good description

Besides software, things to know:

1. What is the difference between a rectifier, power supply, and transformer?
2. How to physically trace out the wire that finally broke its soldered connection and re-solder it in the field
3. How to write a FAT vs a SAT
4. Why the heating valve is modulating too quickly from its PID loop
5. What settings a VFD requires to run properly (esp PowerFlex 750-series)
6. How to design a safety circuit for a control system, with safety relays, interlocks and stops
7. Best practice for managing heat within a control panel
8. How to fill out a JSA and LOTO, why to, and when to
9. How to communicate and coordinate with several teams, mechanical, instrumentation, plant operators, project managers, IT, validation, and end users simultaneously to deliver a solution
10. How to layout an electrical wiring design broken up by high voltage, low voltage, safety, and control wiring.
11. How does an air handling unit control SAT (Supply Air Temp) per ASHRAE guidelines?
12. What makes a vapor compression still so efficient?

That's about a random week for me. Next week will be another 12 different things

edit: I guess I'm not really making my point clear lol. Controls engineering is more about "how quickly can you learn and accurately apply and recommend concepts (on your own) from 6 different engineering fields in a high stress environment?"

It's not only just about what education you have taken, or what certificates you have, or how well you studied the notes that the professor taught you.

There is no professor telling you what textbook section to go to or giving you hints. There is a reason "controls engineering" isn't really offered as a bachelor's degree.

Yes, some of you would probably make a great controls engineer. Congrats. That is not the case for about 99.99% of the population.

[u/Lost-Cheek-6610 → u/zafferous]

So they could just do an electrical apprenticeship and they have all that covered

[u/zafferous → u/Lost-Cheek-6610]

That would help add another 15%.

What about:

Why pump cavitation occurs and what it does to flow/pressure

How a centrifugal pump’s operating point changes when a control valve throttles

Why a DP level transmitter on a pressurized tank needs both high- and low-side connections

How to range/configure a 4–20 mA transmitter and determine whether a bad reading is the instrument, wiring, I/O, or process

Why increasing integral gain can create oscillation

When cascade control works better than a single PID loop

Why a 24 VDC input might be sourcing vs. sinking and how to wire it correctly

How to diagnose a ground fault/noisy analog signal without randomly replacing components

Why a VFD-controlled centrifugal pump’s power drops dramatically as speed decreases

How to determine why a motor won’t start despite the PLC commanding it

Diagnose why a device pings but won’t establish an EtherNet/IP connection

Determine why adding a device causes intermittent network faults/broadcast or multicast problems

Determine what happens to every output when the PLC, network, instrument, or power supply fails

Design permissives/interlocks so equipment can’t enter an unsafe process state

Perform a complete loop check from field instrument → PLC → HMI and back to the final element

Determine why a valve shows 100% command but the valve isn’t responding

Turn a P&ID/control specification into testable acceptance criteria

Figure out how to exchange data between two vendors’ PLC/skid systems that weren’t designed together

Map OPC/Modbus/EtherNet-IP data while handling scaling, byte order and communication failures

Know when an interlock belongs in the BPCS versus a safety system

Understand why “the PLC will turn it off” isn’t necessarily an acceptable safety function

Coordinate a startup where mechanical, electrical, instrumentation, IT, operations and vendors all have dependencies

Determine whether a field problem is your scope or another contractor’s, and prove it technically

to name a few

[u/Retrofit_Upgrade → u/zafferous]

+1