Control Systems Engineer

I have designed, maintained, updated, implemented, and commissioned many kinds of control systems in a variety of locations, architectures, and industries. I did this in the context of both projects and products. The salient features of control systems are sensing, comparison, and corrective output in real-time.

• I started out by including specifications for control elements on the process diagrams I prepared for the paper industry. These were almost exclusively in the form of standalone loops that controlled a valve or generated and alarm based on a single, measured value. I learned about the wide variety of instruments that were available, and many of the controls were pneumatic.
• The models I wrote for nuclear power plant simulators were not themselves control systems, but they included the actions of control systems, which gave me terrific training in the discipline. I also began to learn about logical controls, interlocks, recorders, accumulators, and the like.
• The model-predictive control systems I wrote for the steel industry had to perform a lot of operations, calculations, and data exchanges, but generally didn't involve a lot of control values. Indeed, the point of those systems was to generate values for things that couldn't be measured, namely average and maximum differential temperature within a steel workpiece. The supervisory systems I wrote were referred to as Level II, while the PLC-based Level I systems did the heavy lifting. They managed all of the digital and analog inputs, outputs, control logic, limits, and alarms. The Level 2 system read certain state and instrumentation data from the Level 1 system and used that to perform its calculations. It sent proposed temperature and material handling setpoints back to the Level 1 system, along with some status and alarm information, and the Level 1 system performed the detailed actions necessary to reach the setpoints. The Level 1 systems were (at the time) programmed using a vendor-specific form of ladder logic. Ladder logic may be different than high-level or procedural code but it can still be organized in a clean, modular fashion or a big, jumbled mess. I saw it done both ways and preferred the former, but the latter did work. The Level I systems also incorporated PC-based HMI systems to handle the user interface and data logging functions. A lot of the instrumentation, local controls, and emergency cutoffs were colloquially referred to as "Level 0." I learned about end-to-end and enterprise controls, time calculations, historical logging, mutex permissions, and more.
• I took over maintenance of a PC-based product used to control induction melting furnaces. This system was 10-15 years old by the time I started working on it. It was a DOS program written in C++ and communicated directly with the sensing and control hardware via serial ports. It was originally written as a fairly literal translation of the previous PLC control logic but later maintainers added two distinct generations of changes to the software. By the time I started it was something of an unholy mess but it worked and I was able to make it do everything it needed to. I learned a lot more about low-level hardware communications and things like interlocks and one-shots.

• In my next position I modified low-level communications software that let PC host software talk to networks of far-flung HVAC controls. I got a better feel for dedicated equipment protocols, low-level TCP/IP packet management, and supporting multiple operating systems.
• Two of the evacuation simulation systems I worked on included real-time communications and control elements. I was able to apply, and teach my colleagues about, much that I had learned previously.

I have always enjoyed writing graphics, animation, and user-interface code of all kinds, and those skills have found expression in a lot of my work.