Likely just find a system integrator in your area and apply.
The guy who got me my job was a MS CS, my employer sought him out because they needed a guy for internal software projects. I did a hackathon with him and he hired me as his replacement when he moved to the gaming industry.
My degree is Software Systems Engineering, most of my coworkers are Electrical Engineers or some form of Electrical Diploma.
As long as you have a decent foundation in Networking and Digital Logic you'll be perfectly suited to program PLC/SCADA...
Can you explain what to expect from a "system integrator" company or job? I did a quick google for those in my areas and they seem all over the place, not one mentions "PLC/SCADA"?
So, "systems integration" job involves making systems interoperate as seamlessly as possible, by doing so adding new features, or reducing weaknesses, like for example vendor lock-in (sadly this is not always possible in industrial automation, see below). So the concept applies also to other sectors - and there are indeed non-industrial automation SIs - you might want to add terms like "PLC", "SCADA", "ICS" (industrial control systems), "industrial automation", "controls" to your search.
As for my own experiences in the (industrial automation) system integration industry, in Italy:
As I said before, and said elsewhere by TheCapn, vendor lock-in (in the form of employing equipment by one company, and their tooling, and their services, etc.) is a thing. But at the same time, your job is to make heterogenous systems interoperate! So most certainly you'll have to work not with your usual tools. Personally I have found that the most successful companies rely on some vendor (and their support, and their expertise), but are very open with working with, and know, the others. Obviously the more you can develop autonomously the better; it is a trade-off between freedom of action and access to more credible (branded, battle-tested, supported by big company etc.) solutions.
Knowing when to add one part to the system, or where you can just expand one of the already existing parts in order to accomplish the task is fundamental. Too often I have seen superflous parts added where it would have been enough to extend one of the existing parts a little (This is often due to vendor lock-in, you cannot work on some equipment, so you put another device by your vendor of choice).
Another thing I love about my job is the "Jack-of-all-trades" mindset required. Also human skills are important, especially here where the industry is mostly composed of little shops: sometimes you just have to understand enough to call the right specialist and contract that part of the job to them. I started as more of a computer person than a engineering one, but I managed to gain some expertise over time thanks to this knowledge transfer.
Now that more IT is entering the shop floor, many places are adopting some solutions (for diagnostics, data collection etc.) with more "computer" content than the past; for example all the predictive maintenance platforms big vendors are developing. Or you can concentrate on the "upper" levels, like SCADA, MES; of course working with these tools is not super CS rocket science, most of the time. You can start from positions more akin to programming, then work your way into process sensors technology, electrotechnics, etc. That's what I did.
Edit: System integrators as sibling says, I second that!
Controls aren't much different than other industries who rely on vendor product solutions either imo. You can talk to your SCADA vendor to see what their Historian / MES solution is and look at integrating that or develop a custom solution. Each obviously have pros/cons. What you might gain in rapid development using the Vendor provided solution your client will probably lose in steep licensing fees. Vendor solutions are typically set up in a way that anyone could configure them using only the manual and a few tutorials but giving any joe the ability to set up a system always has the drawback of the system being very "one size fits all" and customizing it to work in certain scenarios is difficult.
True! Hence my, "most of the time". I recently had to heavily customize a SCADA event engine with my plugins due to the particular requirements of the system; come to think of it, I might have as well rewritten the whole thing, but I had some "non-technological" limitations. :)
