Controls Engineer

The Controls Engineer designs and programs the control logic that makes a critical-facility power and cooling plant respond correctly - the building management system (BMS / BAS) and the electrical power monitoring system (EPMS), the PLC / SCADA / DDC programming, the sequences of operation (SoO) and control narratives, the points list and I/O, the alarm and setpoint strategy, and the integration that ties the mechanical, electrical, and monitoring layers into one coherent system. Core ownership is the sequence of operation and how it is programmed - how the plant runs normally and, above all, how it behaves on a failure, a transfer, or a loss of comms - so an operator has a console that shows the truth and logic that protects the load when something trips. This is an individual-contributor seat reporting to a critical-facilities / datacenter engineering manager, with design and programming ownership of the controls and close partnership with the mechanical and electrical designers, the commissioning function, the controls vendor / integrator, and the operations team who will run what it builds. It is not the Commissioning Engineer who proves the integrated system behaves through functional and integrated testing (this seat programs the logic that gets proven - program-it vs prove-it), not the Electrical Engineer who designs the power system itself - the one-lines, the load calcs, the protection and coordination (this seat designs the controls and monitoring that operate and observe that power system - power-design vs controls-logic), not the Power Generation Engineer who owns the generation and prime-power systems and their native control strategy - the gensets, the paralleling switchgear (this seat owns the facility-wide BMS / EPMS integration across the plant, not the generation system's internal controls), and not the Sr. Datacenter Operations Technician who operates the plant from the BMS / EPMS console and responds to the alarms (this seat programs what that console shows and how the logic responds - program-the-console vs operate-the-console). Performance is visible in whether the plant does the right thing on a real failure or transfer without a logic-caused load impact, whether the integrated systems test passes the first time, and whether the operator's console is meaningful rather than a nuisance-alarm flood - so better control design produces measurable, provable resilience. What separates great from average is designing for how the plant fails, not just how it runs: a sequence of operation written so the transfer, the chiller loss, and the loss of a sensor land the plant in a safe, defined state instead of an undefined one; a points list and integration disciplined enough that a device swap does not rewrite the plant; an alarm strategy rationalized so a real event is not buried; loops tuned to stability rather than left to hunt; and every point checked out end to end - field to graphic - before it is handed to commissioning to prove. A mediocre controls engineer programs the happy path, floods the console with alarms nobody trusts, leaves the failure logic to chance, and hands over code no one else can read; a great one makes the plant behave correctly on its worst day and hands over a documented system the operator can run and the commissioning agent can prove.