Why the visual layer needs a lifecycle standard, not just a project standard.
Building automation graphics are usually built near the end of a project. By that point, schedules are tight, budgets have been picked over, and everyone is focused on getting the system accepted.
That creates a predictable problem. The graphics may be good enough to complete the project, but nobody has made a plan for the next 10 or 20 years.
The BAS will change. Equipment will be replaced. Buildings will be renovated. Points will be added. Operators will come and go. Another controls contractor may eventually take over the site. Yet the graphics are often handed over as if they are finished artwork instead of a working part of the building’s operational infrastructure.
That is the gap the industry needs to address.
Project completion is only the beginning
A BAS graphic has two very different jobs.
The first is to help complete the controls project. It must display the correct equipment, connect to the correct points, meet the specification, and pass owner review.
The second job lasts much longer. It must help operators understand what is happening in the building, find problems, train new staff, and make changes without rebuilding the interface every time the system evolves.
Most project standards address the first job. Far fewer address the second.
A graphic can look polished on turnover day and still become a liability later. The problem is usually not appearance. It is the lack of structure behind the appearance.
What gets lost at turnover
When owners receive BAS graphics, they may receive functional screens but not everything needed to maintain them. Common gaps include:
- No documented navigation hierarchy
- No clear naming rules for equipment, floors, buildings, or points
- No record of approved colors, fonts, symbols, and alarm states
- No reusable source assets
- No guidance for adding new equipment without changing the visual language
- No ownership assigned for future graphic updates
- No process for verifying that a revised graphic still points to the correct data
These gaps are manageable in one building. Across a campus or national portfolio, they compound quickly.
One site may use equipment names. Another may use room numbers. One branch may use red to show an alarm. Another may use it to show heat. A new contractor may recreate symbols because the original files cannot be found. Eventually, the owner has several versions of the same BAS and none of them operate the same way.
The system is technically connected, but the operator experience is fragmented.
A graphic standard is more than a color palette
Many BAS graphic standards are treated like brand guides. They define colors, logos, fonts, and perhaps a few sample screens. Those items matter, but they are only the visible portion of the standard.
A useful lifecycle standard should also define:
Information hierarchy
What should an operator see at the campus, building, floor, system, and equipment levels? What information belongs on the main screen, and what should require a deeper click?
Navigation logic
Can an operator move through the system the same way regardless of building, equipment type, or controls contractor? Can they return to the previous level without guessing? A turnkey graphics package typically covers navigation, floor plans, system graphics, and point mapping as one connected experience—not a pile of unrelated screens.
Equipment representation
Are similar systems represented consistently? Does an air handling unit built five years from now follow the same basic layout as one built today?
Status and alarm behavior
Do color and animation communicate a specific operational condition, or are they being used mainly for decoration? Operators should not have to relearn the meaning of a screen from one building to the next.
Asset ownership
Who retains the editable graphics, symbol components, templates, and documentation? Proprietary platform files may be unavoidable, but owners should still understand what they will receive and what can be reused. Reusable symbol libraries are one practical way to keep visual language consistent across projects and platforms.
Change control
Who approves future changes? How are revisions documented? What prevents a small addition from introducing a second visual standard?
Verification
How will the team confirm that labels, commands, values, histories, alarms, and database references remain correct after changes?
Without these elements, a graphic standard is mostly a look. With them, it becomes an operating system for the visual layer.
The next issue is machine readability
The industry is moving toward more structured building data. Project Haystack, Brick Schema, and the work surrounding ASHRAE Standard 223 reflect a broader push to describe building systems, equipment, points, and relationships in ways that software can understand.
BAS graphics should not be separated from that movement.
Today, most symbols are only visual objects. A fan looks like a fan to a person, but the graphic itself may not identify what the object represents, what equipment it belongs to, or how it relates to the underlying data.
Adding structured metadata to visual assets creates new possibilities. Graphics can become easier to audit, search, organize, reuse, and eventually generate or update with automation. It can also help preserve meaning when assets move between projects, teams, or software environments. That is the direction behind approaches like Vectortology™, which embeds semantic data into vector symbols so the visual layer can connect more cleanly to building data models.
This does not mean every owner needs to launch an ontology initiative tomorrow. It means the industry should stop creating visual assets with no thought about what the asset is, where it came from, or how it will be used later.
The graphic of the future will need to communicate with both the operator and the software supporting the operator.
Better turnover starts before graphics are built
The worst time to decide how graphics will be maintained is at the end of the project.
Owners, consultants, and system integrators should answer a few questions before production begins:
- Is there an existing owner standard, and is it detailed enough to be repeatable?
- Who has authority to approve the visual and navigation standard?
- What editable files and reusable assets will be included at turnover?
- How will new buildings and equipment be added without creating a different interface?
- Who is responsible for validating graphics against the live database?
- How will revisions be documented after occupancy?
- Should graphic assets include metadata that supports future search, auditing, interoperability, or automation?
These questions are not glamorous, but they are far less expensive to answer before hundreds of screens have been created.
The owner should inherit a system, not a collection of screens
The BAS interface is one of the few parts of a building automation system that operators use every day. It is also one of the least consistently maintained.
The industry spends considerable time defining sequences, points, networks, cybersecurity requirements, and commissioning procedures. The visual layer often receives a few pages in the specification and becomes a late project task.
That approach is backward.
A BAS graphic is not finished because the project is closed. It is successful when it can remain understandable, consistent, and maintainable as the building changes. Building owners are already rethinking the interfaces they inherit at handoff—and expecting more than polished screens on day one.
The next step for our industry is not simply better looking graphics. It is treating graphics as long-term operational assets with standards, ownership, structure, and a plan for change.
That would improve project delivery today while giving building owners something they can still use years after everyone else has left the job.
