Source-linked AI summary
Software Engineering for AI-driven Building Operation
Philipp Zech, Sascha Hammes, Johannes Weninger, Jürgen Pannosch, Gernot Steidl
TL;DR
AI-driven building control exposes a gap in SE4AI because physical systems have slow feedback, sparse data, and irreversible failures. Drawing on two project experiences, the paper identifies missing perspectives and proposes five practices as a foundation for SE4AI in cyber-physical systems.
Problem
SE4AI lacks perspectives for deploying AI in buildings governed by physical dynamics, delayed feedback, model mismatch, and consequences that cannot be fully observed or controlled.
Method
The paper structures recurring challenges and practices from practical experience across two interdisciplinary building-operation projects and discussions with project partners.
Results
The paper identifies the SE4AI gap, names missing perspectives, and proposes five practices forming a foundation for SE4AI in cyber-physical systems.
Takeaways & Limitations
The proposed template extends beyond buildings to physical domains including manufacturing, water treatment, traffic control, and energy grids.
Takeaways & Limitations
The contribution is a structured reflection on ongoing project experience rather than a formal empirical study.
Abstract
from arXiv · showhide
Building operations are energy-inefficient. Artificial Intelligence (AI)-driven control systems promise benefits through optimization and predictive control, but deploying them in real buildings reveals a significant software engineering (SE) challenge. SE for AI practices assume digital environments where failures mean poor user experience. Buildings are different. A bad control decision wastes energy irreversibly, violates occupant comfort, or accelerates equipment wear. Although actual safety-critical failures are rare, as real building automation systems are inherently fault-tolerant, the physical and lasting nature of even minor failures fundamentally changes SE4AI requirements. Rooted in two interdisciplinary research projects in civil engineering and computer science that target the AI-driven optimization of building operations, we identify the missing perspectives in SE4AI that currently stymie the successful deployment of AI-based systems for building operations. We further share lessons learned and best practices, and discuss broader implications for engineering AI-driven building operations and cyber-physical systems more generally. Our work proposes a foundation for SE4AI in systems where failure has physical consequences - one the research agenda below will need to validate.
1 Introduction
AI-driven building operations could improve energy efficiency and occupant comfort, but deploying such systems is fundamentally a Software Engineering challenge because buildings are cyber-physical systems where control failures have lasting physical consequences. This preliminary experience paper uses two interdisciplinary projects to identify challenges, share practices, and establish a foundation for SE4AI in building operations.
- Static, rule-based Building Automation Systems struggle with changing weather, occupancy, and equipment degradation, causing suboptimal performance and energy waste.
- Reinforcement Learning and Model Predictive Control can learn adaptive strategies from historical and live data to improve energy efficiency while maintaining occupant comfort.
- Directly applying SE4AI practices from digital environments is insufficient because building AI operates within cyber-physical systems governed by thermodynamics, hardware limits, thermal mass, and noisy data.
- Faulty building control decisions can shorten HVAC equipment lifespan, cause lasting discomfort, or waste energy irreversibly, unlike digital failures that can be contained through fast rollbacks.
- The paper draws on two interdisciplinary research projects to categorize building-operation challenges, derive lessons and best practices, and discuss implications for SE4AI in other cyber-physical systems.
- As a preliminary experience paper, it offers a structured foundation for more robust Building Automation Systems while reserving empirical validation of its proposed practices for future research.
2 Background and Related Work
This section situates the work in two interdisciplinary AI-driven building-operations projects and reviews related work across SE4BAS, SE4AI, and AI4BOS. It identifies a persistent disconnect between these areas, especially when deploying AI with fragmented legacy infrastructure and physical consequences.
- Project foundations: BOREALIS and ELEVATE expose recurring deployment problems involving fragmented legacy BAS, sparse or noisy data, physical deployment, and operator trust.BOREALIS targets adaptive RL control for HVAC and lighting, while ELEVATE combines Digital Twins with AI-driven optimization focused on indoor environmental quality.
- SE4BAS: SE4BAS research provides architectural patterns, semantic models, continuous engineering, and commissioning tools for modern building automation systems.The reviewed work includes service-oriented architectures, semantic interoperability, requirements engineering, continuous verification, model-based commissioning, and simulated Digital Twin testing.
- SE4AI: SE4AI emphasizes dependability, safety, testing, data, and iterative life cycles that treat data, models, and code as co-equal artifacts.Related work also includes MLOps pipelines, requirements engineering, ML integration patterns, quality assessment, and socio-technical concerns involving roles, communication, and documentation.
- AI4BOS: AI4BOS research has demonstrated energy-saving building control using surrogate optimization, RL, hierarchical multi-agent RL, industrial deployments, and physics-informed controllers.However, the passage notes that actual field deployments remain rare.
- Cross-area gap: The three areas rarely connect, leaving BOREALIS without SE4AI guidance for safe exploration and operator-trust recovery and ELEVATE without MLOps support for fragmented, intermittent building data.These project-specific gaps illustrate the broader deployment disconnect identified by the paper.
- Contribution and scope: The paper presents a structured reflection on recurring problems and practices from BOREALIS and ELEVATE rather than a formally empirical study.The reflections draw on ongoing work across different buildings and discussions with facility managers, lighting engineers, and control-system integrators.
3 Key Challenges
SE4AI for building operations faces five challenges arising from physical, irreversible, and long-horizon consequences rather than acute safety risks. These challenges include complex dynamics, limited experimentation, fragmented systems and data, and the need for operator trust and explainability.
- Physical consequences: Building-operation failures produce efficiency losses, comfort violations, and equipment wear whose physical consequences are persistent and difficult to reverse.Critical failures are rare because building automation systems are fault-tolerant, but even minor failures change SE4AI requirements.
- Physical dynamics: AI control operates in a coupled, nonlinear physical environment with delayed and noisy feedback that models cannot fully observe or control.Outcomes depend on thermal mass, airflow, radiation, humidity, equipment capacity, hydraulic pressure, and electrical loads.
- Evaluation and tool integration: Buildings cannot support ordinary A/B or shadow testing, while simulation suffers from model mismatch and engineering tools remain separated across ecosystems.Simulation, building control, and machine-learning training tools exist in separate ecosystems, complicating deployment workflows.
- Operator adoption: Facility managers must understand, override, and explain AI decisions because distrust can lead operators to disable systems, eliminating their value.Explainability is presented as a prerequisite for adoption rather than an optional feature.
- Data and system integration: Heterogeneous legacy systems lack common interfaces and repositories, while building data are sparse, noisy, inconsistent, and unsuitable for direct training pipelines.Examples include HVAC using BACnet, lighting using DALI, sensors using Modbus, and occupancy data stored separately.
4 Lessons Learned and Best Practices from the Field
Field experience from BOREALIS and ELEVATE yields best practices for safely deploying AI-driven building control. These practices combine simulation-first evaluation, realistic data requirements, interpretable design, and digital twins with cautious real-world validation.
- Simulation-first testing: Simulation-first testing screens out unsafe or poor-performing control policies before deployment, but real-system validation remains necessary because the sim-to-real gap persists.Building models contain uncertainty in thermal dynamics, occupant behavior, and equipment degradation, so policies can behave differently under deployment conditions.
- Simulation-first testing: Because building control is physical AI, policy behavior emerges from interactions among sensors, actuators, buildings, and occupants rather than from code alone.Virtual testbeds support pre-deployment evaluation, while staged deployment and continuous monitoring are needed for real-world validation.
- Data requirements: Data minimalism improves field robustness by designing policies for expensive, unreliable, privacy-sensitive, and realistically available data rather than assuming dense instrumentation.When dense data is available, it can support fault detection and drift correction, but systems still need safe fallback behavior when data disappears or becomes stale.
- Transparency and trust: Building-control systems should be interpretable from the outset because facility managers and occupants need to understand and accept automated decisions.Simpler policy architectures and integrated explanation modules are preferable to relying only on approximate post-hoc explanations.
- Digital twins: A synchronized digital twin can combine live building state with safe exploration and grounded what-if simulation before policies reach the real building.Digital-twin validation reduces deployment risk and can shorten commissioning cycles while avoiding the consequences of exploration in occupied buildings.
5 Discussion and Implications
The discussion frames SE4AI for building operations as a response to the mismatch between digital assumptions and physical-system consequences. It emphasizes digital-twin continuity, data minimalism, operator trust, regulatory readiness, and cautious generalization beyond the Austrian projects.
- Broader implications: SE4AI practices for building operations address a structural mismatch because buildings are physical systems rather than digital environments.The same challenges may arise in manufacturing, water treatment, traffic control, and energy grids, although their generalization remains empirically untested.
- Digital-twin continuity: A synchronized digital twin grounds simulation-first testing and explainability in the actual state and behavior of the physical system.It narrows the sim-to-real gap by maintaining continuity between virtual and physical systems, while enabling decisions to be replayed, inspected, and justified.
- Data engineering: Data minimalism is a first-class engineering principle because physical-system data is expensive, slow to collect, privacy-sensitive, and often unreliable.Designing for minimal data from the outset produces systems that are more robust, deployable, and maintainable.
- Trust and explainability: Operator trust is a core architectural requirement because distrust can lead facility managers to disable an AI system rather than merely ignore its recommendation.This makes explainability central to earning and maintaining trust, not merely a regulatory checkbox or UX afterthought.
- Regulation: GDPR and the EU AI Act require physical-system SE4AI practices to incorporate occupant-data, transparency, and oversight obligations from the start.These obligations affect how building AI systems are designed, documented, and deployed.
- Limitations: The findings’ generalizability is limited by the Austrian academic context, author-derived practices, confirmation bias, and analogy-based rather than empirical transfer to other CPS domains.These limitations are presented as consistent with positioning the work as the start of a research agenda.
6 Conclusion and Future Work
The paper identifies a gap between SE4AI’s digital assumptions and the physical realities of building operations, proposing five practices as a foundation for SE4AI in cyber-physical systems. Future work should validate these practices in real buildings, close the sim-to-real gap, build integrated tooling, and test transfer to other physical domains.
- 6 Conclusion and Future Work: SE4AI for buildings must account for thermodynamics, irreversible failures, sparse data, legal operator responsibility, and slow feedback.The paper frames five proposed practices as a foundation for SE4AI in cyber-physical systems.
- 6 Conclusion and Future Work: The five practices require field deployment in the BOREALIS and ELEVATE testbeds and measurement against operator trust, data efficiency, and time to deployment.Validation should use concrete outcomes rather than only simulated performance.
- 6 Conclusion and Future Work: Building digital twins need better calibration methods and evidence for when simulation-based testing is sufficient or insufficient.The paper identifies uncertainty in building digital twins as a central sim-to-real challenge.
- 6 Conclusion and Future Work: An integrated workflow from BIM through digital twins and AI to deployment remains absent, requiring interfaces between simulation, control, and machine-learning toolchains.The proposed tooling agenda starts with interoperability across these environments.
- 6 Conclusion and Future Work: The practices should next be tested for transfer to manufacturing, energy grids, and infrastructure, where physical reality similarly challenges SE4AI assumptions.The paper presents this cross-domain evaluation as a natural next step.
- 6 Conclusion and Future Work: Deploying trusted and effective building AI from algorithm to operation is fundamentally a software-engineering problem.The conclusion argues that this deployment path should eventually be treated explicitly as such.