Forty percent of the building automation workforce will retire in the next ten years. The numbers are not subtle. The average BAS field engineer is in their late fifties; the average controls programmer fluent in PPCL or BACnet at the field-panel level is older than that. Most have been in the same buildings for decades. Most of what they know lives in their heads.
This is not a problem you can hire your way out of. The pipeline is too thin. The colleges turning out controls engineers are not turning out enough of them, and the ones they do graduate are heading toward integrators and tech vendors not facility operators.
The shape of the problem.
Walk into a 30-year-old commercial building and ask the chief engineer a question. Watch the answer.
It will not come from a runbook. It will come from memory. "Oh, that AHU that's the one with the bad damper actuator on the return side. We worked around it in 2014 when the original part went obsolete." Or: "That alarm fires every Tuesday morning because the chiller starts before the cooling tower fan has come up. Ignore it for the first 20 minutes."
None of this is in the documentation. Some of it is in the BAS as a hardcoded override that nobody remembers writing. Most of it is operational tribal knowledge that gets passed down by physical proximity a senior tech showing a junior tech, in the mechanical room, pointing at the actual equipment.
When the senior tech retires, that pipeline breaks.
What we tried first.
The obvious response is documentation. Write it all down. Build runbooks. Ship them to the next generation.
This fails for the same reason it has always failed: the act of writing full documentation is its own full-time job, the people who know enough to write it are the busiest people in the organization, and the resulting documents go stale within a quarter.
We tried building a knowledge-capture program at one of our larger sites. Six months in, we had 400 pages of runbooks and a maintenance team that ignored them because the answer they needed was always on page 312, written for a slightly different model number, with a key step omitted because the author assumed the reader knew it.
The runbooks were not the answer. The runbooks were a partial input to the answer.
What is actually working.
Three things, layered.
One: PPCL X-rays. We started running our PPCL Review tool against inherited Siemens code at the field-panel level. The output is not "here is what your code does" it is "here are the 22 programs that are dead code, the 8 that have hardcoded overrides nobody remembers writing, and the 3 that are duplicates of each other with subtle drift." That output is a refactoring map. It tells the next-generation controls team where to start.
Two: Conversational knowledge. We pair the runbook library with an on-premise AI assistant that ingests the documents and answers questions in natural language with sources cited. A junior tech standing in front of a chiller can ask "what is the startup sequence for chiller-3 after a power loss?" and get the actual answer from the actual runbook, not a hallucination.
The on-premise part matters. Most facility operators cannot send proprietary equipment configurations and operational procedures to a cloud AI vendor. We run the inference locally so the knowledge stays inside the network.
Three: Closed-loop work order data. Every closed work order captures what was actually done parts, time, photos, voice notes. Over a year, that history becomes a queryable archive of "how did we fix this last time" that survives turnover. Future failure analysis pulls from it.
What we are not solving.
None of this replaces the senior engineer. The senior engineer's judgment about which alarms to chase first, which contractor to call, and which manufacturer rep actually returns calls is irreplaceable.
What we can do is make sure that when the senior engineer leaves, the next person inherits a system where:
- The PPCL is documented well enough to maintain
- The runbooks are accessible at the moment they are needed
- The work-order history is rich enough to pattern-match against
- The asset data is accurate enough to trust
Without that foundation, every senior engineer departure is a step backward. With it, the next generation has a chance.
What we recommend.
If your organization has a senior engineer or controls programmer within five years of retirement, three things to do now:
- Capture the PPCL or the equivalent. Get the source code out of the panels and into version control. Not because you are going to refactor immediately because you cannot refactor what you do not have.
- Start the runbook ingestion. Even imperfect, partial runbooks have value. Get the senior engineer to record voice notes if writing is too slow. Transcribe and ingest.
- Make work-order close-out non-trivial. Photo, parts, time, narrative. The next person looking at this asset in three years should be able to read what was done and why.
None of this is glamorous. None of it is what gets executive attention. All of it pays for itself in the year after the senior engineer retires when the question that used to take a phone call now takes a search.
The institutional knowledge is leaving the building. The question is whether you are capturing it on the way out, or finding out the hard way that it's gone.
Kevin Fedor is the founder of Arcis FM and the engineering lead on A·IQ Analytics. He spent fifteen years in the trenches of building automation before starting Arcis. Connect on LinkedIn.
