Smarter, more sustainable building services
Smarter, more sustainable building services
Automated building tracking systems make it possible for buildings to dynamically adapt to changing conditions, making them more comfortable for users and more energy efficient. Buildings are, however, often designed, planned and built based on assumptions about how they will be used, how inhabitants will behave and external factors such as temperature, climate or general weather conditions. Building services are created to match these assumptions. In most cases, once a building is commissioned, there is little chance to significantly improve or adapt its functionality in a cost-efficient way. Refinements and adaptations often involve a research institute conducting a post-building monitoring phase of 12-24 months but this is usually an expensive and time consuming process.
This use case demonstrates how the Eclipse Arrowhead approach can be applied to shift the optimization of building services and the development of building tracking systems from design time to run time. In the scenario presented, sensors in the building automation system feed data into a simulation model that tracks the building in real time. Virtual sensors calculate optimized control settings that can be fed back into the automation system. Feeding experiences and insights generated during the operation of the system back into the process also enables the building tracking software and its algorithms to be updated at runtime.
The use case also highlights a move toward multi stakeholder automation and digitalization. The standard scenario for designing and implementing building services generally involves only one stakeholder, often a research institute responsible for generating the necessary assumptions. The engineering process presented in this use case involves three stakeholders, where the main stakeholder - the developer of the building tracker - works together with the installer/planner of the building services and the facility manager to define the requirements for the specific building. Requirements might include the automation systems to be used, which services are to be controlled and what interfaces to the building tracking system are desired. Each of the stakeholders is engaged in various processes throughout the design and operation of the system with all three taking responsibility to transfer important know-how in the training and education phase.
Watch the full presentation here: https://www.youtube.com/watch?v=F0I4hjMHGM0&list=PLr0AcmG4OlO0JYuemYSHbfA189b__ErnZ&index=2&t=3s
Automated building tracking systems make it possible for buildings to dynamically adapt to changing conditions, making them more comfortable for users and more energy efficient. Buildings are, however, often designed, planned and built based on assumptions about how they will be used, how inhabitants will behave and external factors such as temperature, climate or general weather conditions. Building services are created to match these assumptions. In most cases, once a building is commissioned, there is little chance to significantly improve or adapt its functionality in a cost-efficient way. Refinements and adaptations often involve a research institute conducting a post-building monitoring phase of 12-24 months but this is usually an expensive and time consuming process.
This use case demonstrates how the Eclipse Arrowhead approach can be applied to shift the optimization of building services and the development of building tracking systems from design time to run time. In the scenario presented, sensors in the building automation system feed data into a simulation model that tracks the building in real time. Virtual sensors calculate optimized control settings that can be fed back into the automation system. Feeding experiences and insights generated during the operation of the system back into the process also enables the building tracking software and its algorithms to be updated at runtime.
The use case also highlights a move toward multi stakeholder automation and digitalization. The standard scenario for designing and implementing building services generally involves only one stakeholder, often a research institute responsible for generating the necessary assumptions. The engineering process presented in this use case involves three stakeholders, where the main stakeholder - the developer of the building tracker - works together with the installer/planner of the building services and the facility manager to define the requirements for the specific building. Requirements might include the automation systems to be used, which services are to be controlled and what interfaces to the building tracking system are desired. Each of the stakeholders is engaged in various processes throughout the design and operation of the system with all three taking responsibility to transfer important know-how in the training and education phase.
Watch the full presentation here: https://www.youtube.com/watch?v=F0I4hjMHGM0&list=PLr0AcmG4OlO0JYuemYSHbfA189b__ErnZ&index=2&t=3s