Community Research and Development Information Service - CORDIS

H2020

ACCEPT Report Summary

Project ID: 636895
Funded under: H2020-EU.2.1.5.2.

Periodic Reporting for period 1 - ACCEPT (Assistant for Quality Check during Construction Execution Processes for Energy-efficienT buildings)

Reporting period: 2015-01-01 to 2016-06-30

Summary of the context and overall objectives of the project

Problem: What the consortium sees as a major problem today is the potential loss of benefits of energy-efficient building components because of the lack of knowledge or bad implementation during the construction processes.

Solution: During the project ACCEPT gets created – An Assistant for quality Check during Construction Execution Processes for energy-efficienT buildings. The assistant runs on Smart Glasses and unobtrusively guide workers during the construction on site. This provides a standardized and coordinated process for all workers, ensuring that all benefits of energy-efficient building components are maintained.

The better energy-efficient building components of today have one major flaw: The loss of efficiency through improper usage during the building process can be dramatic. ACCEPT will ensure the proper usage of the components during the building process with the help of Smart Glasses (Optical Head Mounted Displays, e.g. Google Glass or Epson Moverio ). The Smart Glasses unobtrusively provide the workers on site with guidelines exactly when needed, while common methodologies - defined by the site manager - for all workers can be incorporated to standardize and coordinate the overall working activities. The execution details brought to the construction site by ACCEPT can be customized for the working site, the building components and the different contractors to even bridge language barriers with ease. In this way it is possible not only to minimize the loss of efficiency due to thermal bridges or bad air-tightness, but also to increase the overall efficiency, reliability and productivity of the construction processes.
Relevant data will be aggregated passively on the construction site by workers wearing Smart Glasses as well as actively using different sensors accessed through a Smartphone operated by the site manager. In addition, visual annotations can be attached to objects in order to exchange context-based information between workers; bringing the Wiki idea to the construction site. The data is processed in a cloud environment with self-inspection methods to determine important characteristics (such as U-values) as well as to monitor the coordinated progress of different parties cooperating in the building process. Thereby a sophisticated tool for the quality control during the building process is provided which guarantees that the energy performance at commissioning stage will meet the one expected at design stage. ACCEPT will reach the following key objectives:
- Improving the final thermal, acoustic and energy performance of buildings by providing sophisticated quality assurance tools, which will be used actively or passively by different stakeholders during the construction process
- Measuring the contribution of each critical component for the thermal insulation and air-tightness by evaluating data gathered by a variety of sensors brought to the construction site
- Reducing the mismatch of energy performance between design and commissioning stage by providing guidelines to apply the sophisticated quality assurance tools mentioned before
- Providing guidelines and methodologies during the construction process by transferring knowledge between the different stakeholders of the construction process
- Increasing the efficiency, reliability and productivity of a construction processes
From a user perspective ACCEPT is focused on the following very clear main results:
1. The Construction Operator Assistant App (CoOpApp) running on Smart Glasses, which passively collects data and actively provides guidance to the worker on site during the building process. (Pillar I: Advanced Knowledge Transfer for Energy-efficient Construction)
2. A Site Manager App (SiMaApp) running on a mobile device, which allows to remotely coordinate the working process as well as collect additional data on site by different sensors. (Pillar II: Agile Project Coordination for Bridging Heterogeneity)
3. An interactive web-based Dashboard as a monitoring and quality assurance solution. The Dashboard will use self-inspection methods to determine important characteristics such as U-Values. (Pillar III: Adaptive Quality Assurance with Self-Inspection Features)
ACCEPT is fully dedicated towards achieving a maximum of impact. As such, the three results are demonstrated within 7 real-world pilots in 4 different EU countries, grouped into 3 piloting areas within the project.

Work performed from the beginning of the project to the end of the period covered by the report and main results achieved so far

The overall project progression is at a good pace. Due to the rigid controlling and management no unforeseen risk emerged.
Six deliverables were submitted as planned in the context of the work package 1 in the first period:
• D1.1 – Project Handbook: This “Project Handbook” provides a manual for project procedures and communications within ACCEPT. It defines the general rules for collaborating in the project and it specifies the tools and instruments used by the consortium.
• D1.2 - D1.6 – Quarterly Management Report: The Quarterly Management Report’s keep track of the work within the single work packages in each quarter. For this, each provides an overview of the work conducted, an estimation of the status of each work package, as well as providing a target-performance comparison regarding costs per partner and work package.

In WP2 the State of the Art of similar products or research projects were determined. Those projects, products and new created once are monitored in the course of the project to adapt the project, if it is necessary. Later, requirements were analysed in 21 international Focus groups of potential end users. Those were used to create a Functional Specification, to get a better understanding of the complete ACCEPT system from the end users point of view. The Functional Specification was followed by the Technical Specification, which specified the ACCEPT system more in detail for the technical partners of the consortium. That document leads the development process of the whole ACCEPT system.
In the first period, four meetings and a technical meeting were held. They were used to align the expectations, direction and strategy of the project. Important technical decisions were made, which were important especially for WP2.
Work in T2.2 – Market, Innovation and Applicability Watch – started with writing of a working plan and work schedule for D2.2, define the Market Watch Strategy and assign responsibilities in the consortium for collecting data in order to ensure innovative results. The first baseline of interesting products, software, and research projects were created. It consists of interesting products on the market or currently researched (innovation) or failed in the market (applicability). This State of the Art watch will then be updated over the course of the project.
For T2.3 – Business Model Canvas, Analysis and Definition – the main efforts involved the writing and participation in Brainstorming Business questionnaire, generating Business approach synopsis, group analysis of each Business Model Canvas (BMC) segment and summarisation of findings. At the end a BMC was created. Different workgroups focused on different aspects on the canvas. The BMC guides the development and research efforts. The results are summarised in D2.5.
In T2.4 – User Stories and Requirements Analysis – the focus group sessions were scheduled and the process of how to collect and review the input was defined. The requirements of the users were evaluated and User Stories generated. Multiple Focus groups of end users (architects, engineers, site managers, conductors and construction workers) in different countries were organised and the general project idea was presented. Ideas and requirements were collected based on the experience of the participants and elaborated to create the User Stories.
In T2.5 – Architecture Definition and Functional Specification – a description about the different sub components of the ACCEPT system was done based on the User Stories of T2.4. The user stories, collected in T2.4 were merged and prioritised based on multiple factors by the partners and their area of expertise. Premised on the different User Stories a high level architecture of every subcomponent was made and the functionalities of those components were described with multiple diagrams. So every partner has a better understanding of the innerworkings of the different components and what could be expected from the multiple subcomponents. The result acted as foundation for T2.6 - Technical Specification and Mockups.
In T2.6 – Technical Specification and Mockups – the Use Cases of D2.1 were translated into functionalities of the ACCEPT system. Later on, these functionalities were used to beacon the resulting analysing and designing process of the ACCEPT system. The resulting software architecture and mock ups are the main result of D2.8 – Technical Specification and Mockups. To be finally on schedule and since many issues had to be clarified between the technical partners, an additional meeting was held for three days.
The following deliverables were submitted as planned to the EC in the first period:
• D2.1 – Concept, Role Definition and Strategy Consensus – Within this central deliverable of the ACCEPT project the overall project vision in terms of its general positioning, the project’s business and its research and technological objectives are revealed. For that, a story is utilised to demonstrate typical use cases where different user groups can benefit; the logical structure as well as a high-level architecture of the ACCEPT System is described providing information from different perspectives.
• D2.2 – Market Innovation and Applicability Watch – The deliverable, which is the first of the three of T2.2, was completed with the contributions of the consortium members. Within this report, the strategy for conducting a continuous monitoring of the market is defined and a first version of a backlog of state-of-the-art products is presented. The products are compared against ACCEPT key concept functionalities in order to identify impact opportunities with the highest potential. The goal of the consortium is to continue monitoring the market throughout the project duration in order to feed new or updated information into the subsequent T2.2 deliverables.
• D2.5 – Business Model Canvas, Analysis and Definition – This deliverable analyses the business opportunities available for the results of the ACCEPT project. Using the Business Model Canvas approach, the ACCEPT Business Model has been created in a way which presents the best opportunities for a successful introduction to the market and a sustainable business model.
• D2.6 – User Stories and Requirements Analysis – The deliverable D2.6 corresponds to T2.4 and contains a complete description of the different activities and processes carried out to obtain a collection of user stories. These user stories are used as input to define the architecture definition as well as specifications to outline concrete tasks in later stages of the project (T2.5).
• D2.7 – Architecture Definition and Functional Specification: Based on the user stories created for D2.5, this deliverable introduces the requirements and the global architecture of the whole ACCEPT system. In this global architecture the components and their interaction are defined. It is based on the main components defined in D2.1 but is performed at a higher level of detail and also involves the specification of sub-components and actors. Last but not least, this deliverable concludes with the functional specification of all components providing an in-depth definition of their functionalities and behaviours.
• D2.8 – Technical Specification and Mockups: This deliverable describes technical implementation details of the ACCEPT system. It is based on the Functional Specification and the architecture of T2.5. It defines the interfaces, protocols and class/package structures including definitions of communication details between the components and the order of actions.

In T3.1 – Knowledge and Information Storage System – the analysis of BIM specific data storage conversions/possibilities and their efficiency were made. Further documentation, some adaptions for the ACCEPT system as well as bug fixing and refactoring were done.
In T3.2 – Smart Glass Assistant Foundation – research was done and time was invested to get more familiar with technologies like Unity. The generation and transformation of data in order to provide information to the smart glasses for object recognition was done and improved as well. The foundation and a first prototype of the general client for the smart glasses was implemented and different prototypes of apps were done, which will be used later on in the ACCEPT system. Among them an app to measure distances and a first version of an augmented reality app. This displays a 3D model from a BIM designing tool (Revit). 3D models, images, videos and virtual notes can be shown as augmented reality elements as well and the user can interact with the virtual notes to show instructions attached to them. Further, a first simplistic prototype, which transforms BIM models into Unity files was done.
For T3.3 – Mobile Assistant Foundation – the first prototype of the mobile client of the ACCEPT system was done. The time was spent on getting familiar with the technology and designing many parts of the user interface, that is orientated on modern smartphone applications to help new users to be more familiar with the system from the start. Further the designed user interface was implemented. The functionality of the client is mocked up and does not deliver the actual state of the ACCEPT system, currently.
In T3.4 – Autonomous Messaging Framework – research was done and the foundation for the AMF framework was laid down. Different options were analysed, TSB version 3 and the future upcoming TSB version 4 (RC) among others. The later has been selected as the most promising and progressive technology that makes use of AKKA framework and also aligned with the future directions in which the partner products will be developed. The partners advanced in the usage of the AKKA technology, went through the initial steps of application and of the Scala language (necessary for AKKA implementations) and tried several prototypes. The necessary literature has been acquired. In addition, an overall working plan was developed. Further, research was done concerning the robustness and durability of messaging and service invocations.
The first task of this work package was successfully carried out. The prototype for the Knowledge and information Storage is deployed and made available to the rest of the ACCEPT System. For the remainder of the project only bug fixes and maintenance of the component is foreseen. This early finalisation will allow for a detailed evaluation of the result.

Four tasks have started:
• T4.1 – Visual Wiki Framework
• T4.2 – Interaction with Visual Annotations
• T4.3 – Execution Details Assets – Distribution and Provisioning
• T4.4 – Interaction with Assets as Overlay
For T4.1 –Visual Wiki Framework - a first version of the Visual Wiki Data Model has been produced and some internal prototypes of the Visual Wiki services have been developed and tested to respond to requests using JSON and XML.
The platform has been developed including an API created alongside a Back-end system and a Front-end web platform to ease the processes of uploading, managing and creating content.
Using this Visual Wiki platform files such as 3D models, images, videos and documents can be uploaded, text can be written and formatted in the cloud and presentations mixing the previous media files can be created. Also, QR codes can be generated in order to create an easy way to expose information and offer services to CoOpApp such as indoor location, warning and augmented reality markers.
Actually the platform has been developed using an environment which uses Node.js (using Strongloop Loopback module), MongoDB and Ubuntu OS. The system is up and running on a cloud machine and it is ready to receive external requests from external apps.
For T4.2 – Interaction with Visual Annotations – EVAs are shown in the CoOpApp and they can actually be linked to instructions that can be shown if a user interacts with the note, when using the glasses.
For T4.3 - Execution Details Assets - Distribution and Provisioning - A prototype of a system for distribution and provisioning of special assets, needed for giving guidance for specific tasks and processes, has been developed and deployed in the test environment. The prototype uses Google Cloud (AppEngine and Cloud Datastore) technologies stack and proves the overall feasibility of a service by enabling an efficient transfer of information about usable assets to all clients, defining the distribution methodology. The asset format used in the prototype has been defined as XML metadata coupled with arbitrary binary payload, which allows flexible usage of the system in the following phases of the project, and which will evolve along as the project matures. Distribution of assets is implemented by using the Autonomies Messaging Framework (AMF) as the service registry and data transfer backbone, allowing clients seamlessly request and consume asset data. Further, work on detailed execution details have been done, including research, evaluation and preparation for specific steps of the construction process, especially in regards to Energy Efficiency components.
For T4.4 – Interaction with Assets as Overlay – the task, as T4.2, has just started and at this moment videos, models and images are shown in the app as augmented reality and 2D statics, they can only have basic interaction in CoOApp’s slides for instructions. End users started researching special assets that could be used as guidance for specific construction tasks and processes.
Regarding task 4.1, as important results obtained during the reporting period the first version of Visual Wiki Data Model and the first version of CoOpApp and SiMaApp have been developed.
The detailed results are Construction Operator Assistant App and Site Manager App (SiMaApp, the application for the smartphones), developers tested tools and development software like Unity3D, a game and multimedia apps engine and IDE, Vuforia SDK and other external libraries and packages to get a first approach to be able to show the Visual Wiki resources like 3D models, videos and images in the apps. Processes aimed to bring BIM models (IFC) over Unity3D have been analysed and tested in order to be able to use 3D models from the construction area in the apps.
For task 4.3, the proven feasibility of using Cloud technologies for asset distribution, especially from the point of view of reliability, redundancy and clustering. Flexible definition of asset data format, allowing easy integration in the upcoming phases of the project. Design of the Autonomies Messaging Framework foundation with extensibility and performance in mind, allowing diverse parties to interconnect, discover services and exchange information.

The WP5 started on M7 (July 2015) with the T5.1, which focuses on developing a groundwork for the whole Profile Nexus (PN), its profiles and services. On M16 (April 2016) three task T5.2, T5.3, T5.4 started referring to project, workflow and quality profiles, respectively. The first activity of this WP has initiated the development of coherent strategies and working plans of each task, considering partners know-how, capacities and effort. During the reporting period, the major effort was consumed to: elaborate a concept of the Information Data Model (IDM) for each profile, to research different technologies for creating PN (T5.1); to explore opportunities of data exchange between Building Information Modelling (BIM) software, PN and ACCEPT system (T5.2); to develop a prototype of the Workflow Profile as a REST interfaces (T5.3); to develop a prototype of the Quality Profile as a REST interfaces (T5.4).
Partners coordinated work via telco as well as during plenary/technical meetings.
All tasks started with writing of a working plan, defining a coherent strategy and assigning responsibilities within the working group in order to reach task’s objectives.
Work in T5
.1 – General Profile Definition and Profile Nexus with Mediator approached two aspects, theoretical aspect referred to IDM and implementation aspect referred to the creation of PN and its services.
Firstly, a theoretical concept of the IDM was elaborated. IDM was mapped using the ER-Diagram, where main entities, attributes and relationships were defined. The entities of each profile and their relationships were established based on the functionalities identified in User stories (T.2.4, T2.5) as well as User Cases (T2.1), which reflect real needs of stakeholders involved in the construction process. In order to show partners of the consortium how information within the ACCEPT system can be processed by PN and visualized on devices, an interactive mock-up was developed according to IDM.
As a second step, several activities referred to the implementation of the PN were carried out. Involved partners defined a mutual agreement on the consumed services and data being stored and exchanged in PN. A research was carried out to identify different technologies for implementation of asynchronous endpoints to allow component intercommunication. Directly related to the AMF AKKA implementation, these endpoints have to be compatible with the existing TSB realizations, therefore some compatibility testing were carried out. A prototype Project Workflow Profile module has been implemented and tested.
The task T5.2 – Project Profile Generation, Interaction and Integration focuses on developing the Data Abstraction Layer (DAL) that should transfer data from BIM software to ACCEPT system. To achieve this goal, firstly the level of BIM models among partners of consortium was investigated. Afterwards, the IFC data model was chosen to retrieve needed data from BIM model. Entities and attributes of IFC data model were identified in order to provide further information to the Project Profile.
The task T5.3 – Workflow Profile Generation, Interaction and Integration approached two aspects, theoretical aspect referred to IDM and implementation aspect referred to the creation of the profile. From the theoretical perspective, scheduling and workflow processes have been defining for the ACCEPT system and the theoretical concept of the IDM for this profile has been elaborating. According to theoretical concept of the IDM, the first prototype of the Workflow Profile was implemented, exposing its functionality via a set of REST interfaces. The prototype considered data structures related to task scheduling management. The proof of concept was designed to prove the feasibility of the Workflow Profile service deployed at Google AppEngine and using AppEngine Datastore as a storage, and with Swagger UI for REST interfcaces documentation, supporting hypermedia (self-exploratory interface) responses. The REST interfaces for working with workflow data were implemented and its result was presented to the involved partners.
The task T5.4 – Quality Profile Generation, Interaction and Integration focuses on developing the Quality Metrics Components (QMC) and defining quality check procedures connected to workflows of construction tasks. The first activity of this task has been defining the quality metrics for the building quality and for the quality of construction process.
Three successive versions of the Quality Profile have been developed, with a focus on ‘IT foundation’, ‘sensor data and analysis’ and ‘high-level scenario implementation’. As a server application, this module publishes REST web services. The data model for sensors, monitors and scenarios were developed. Monitors are the analysis components of the Quality Profile, which use sensors or other monitors as inputs. Generation of data for monitoring of humidity of concrete slabs and advanced monitor for the time estimation of the dryness of a slab was elaborated as well. Furthermore, the connection between the Quality Profile and the Dashboard and connection between the Quality Profile and the Sensor abstraction framework (SAF) was established.
The following important results have been achieved during the past period:
• In T5.3, the first prototype of the Workflow Profile has been developed, with REST interfaces defined and exposed according to the Technical Specification. The implementation of REST interfaces is based on the Adaptive Hypermedia concepts and HATEOAS principles. This allowed for more decoupling between consumers and producers of services. The prototype is based on the Google Cloud technologies stack, providing redundancy and scalability out of the box in addition to increased reliability of the solution. Consumers of the implemented services are able to self-explore the interface documentation using the bundled Swagger API documentation UI.
• In T5.4, the development of the Quality Profile has started and sound foundations have been put in place: a coherent data model, REST services, interaction with the dashboard and the Sensor Abstraction Framework, as well as the implementation of different ‘real-case’ scenario like the monitoring of the drying process of concrete slab on the construction site. A somewhat complex analysis is conducted during this monitoring, as an estimation date for slab dryness is computed based on multiple sensors. Warning messages are then issued when the drying process shows an abnormal behaviour or an unusual drying time.

WP6 began in the first quarter of the second year. All activities of the WP6 are focused on the quality assurance (QA) with the help of self-inspection features of a construction project. The first 3 tasks have initiated, the working plan is done and partners involved collaborate on:
• T6.2 - Quality monitoring
• T6.3 - Cyber Physical System and sensors
• T6.4 - Visual Data Mining
In T6.2 – Quality monitoring
• A working plan is done and T6.2 was divided in:
o Collection of user-partners feedback
Quality criteria and checklists
Quality indicators and thresholds
Widget for quality monitoring (focus on quality service algorithms)
o “Quality metrics survey” has been prepared, for Specifying quality thresholds for the quality monitoring and feedback from user-partners is in progress.
In T6.3 – Cyber Physical System and sensors
• A working plan is done and T6.2 was divided in:
o State of the art
o Framework SAF
o Selection of specific sensors
o Integration of specific sensors
• A first theoretical model of the concrete drying simulation is in progress.
• Development began with an initial prototype for the Dashboard web client application with sound foundations using DART and Polymer. Experimentations were conducted with graphs and responsive-design in DART/Polymer.
• The Implementation of a first sensor-related scenario about humidity monitoring of a concrete slab is in progress.
• State of the art of the indoor localisation was created.
• An approach for CPS integration and sensors has been created and three use cases were prepared for the application of sensors in different construction process scenarios.
• The research about the use of Cyber Physical Systems in the construction and data mining from site sensors has continued.
• Besides that, a hardware prototype for sensors was created and the developing of the SAF on the basis of this first set of sensors to validate the architecture/concept was started.
in T6.4 – Visual Data Mining
• The main execution mistakes were analysed occurring on construction sites. That means it has been identified, which errors occur often and have extensive consequences, either energetic or in terms of long-term damage. This study is limited to high-rise building construction, only.
The first version of the Dashboard has been developed, oriented toward sensors and the advanced scenario about drying slabs described above. The Dashboard is a web-client application. One of the design principle chosen for the Dashboard is to use only the latest advanced technologies available for web application today. This module is developed using the DART language, in conjunction with the Polymer library. After some exploratory work, a sound foundation for this module has been developed, using the responsive-design approach, so that the interface can be used both on regular screens or on tablets (the layout on smartphone is already quite good but still needs improvement in some places).
The Dashboard communicates with the Quality Profile to retrieve all the necessary data it wants to display. One of the key guidelines for the design of the Dashboard is: « When entering the Dashboard, the user must, in a glance, know where his attention is the most urgently required within the huge amount of data available about the construction site ». Following the slab-drying process scenario, the Dashboard directly displays, amongst all the slabs installed in the building, how many of them are raising potential issues. Following the link, the user can then see an initial categorization of the potential problems. Choosing from this selection, he can access the list of relevant slabs. He can then select any of them and reach the detailed analysis concerning this slab: summary information and status, as well as the historical charts representing the different sensors used for this analysis.

The work package commenced in the final month of QMR3, and focussed on developing a strategy for creating the Individual Pilot Plans. A Pilot Definition and Preparation workplan has been developed by INGL which served as the framework for all effort in T7.1. Each User Partner developed a simple Pilot Plan to explain their intentions for the Piloting Group for which they were responsible - and these were presented at the September Plenary Meeting in Alicante.
The Plenary Meeting also included a one-day workshop session, wherein the User Partners (EJD, FER, EPI, INGL, IBP) discussed the simple pilot plans and technical feedback from all other partners. A Pilot Plan Programme was agreed upon, as was an overview of the scope and ambition of each of the pilots. The piloting approach, timeline and validation criteria were formalised with the use of the user stories, and this was set out in D7.1
In 2016, User partners and technical partners have been collaborating fully on development of detailed mock-ups and first prototypes for each component of the ACCEPT system. Focus Groups have commenced across Europe for Pilot Groups 1 and 2.
CoOpApp’s functionalities were defined to be developed in Pilot I. The user partners made a first review of the mock-ups of the clients. Also an extraction of a part of the BIM model related to the pilot (Shopping centre in Almeria, Spain) was done. Collaborations between user and technical partners were done to develop the initial mock-up of the SiMaApp within InDesign, and have worked to progress this towards a ‘clickable’ PDF version.
Mock-ups of the CoOp App and SiMa App have been produced and taken to industry for review and validation through use of focus groups in the UK, Spain and Belgium. Usability, Functionality and Integration potential have all been explored heavily to further advance the brief for technical partners to begin development of the clickable prototypes. From these sessions, a Site Map has been developed for the SimaApp, categorising functionalities and initialising the development of worker profiles. Piloting of the Dashboard has not formally commenced yet, but preliminary discussions have been held to ensure quick mobilisation once the milestone is reached to begin the Task.
T7.1 – Piloting Definition and Preparation – focussed on creating a co-ordinated approach to delivering a successful pilot programme for the ACCEPT system. A template was developed during plenary sessions, against which Individual Pilot Plans were created for each of the proposed pilot groups and pilots themselves.
Pilot site providers have been engaged in Spain, Belgium and UK, ensuring that the providers understand the scope, ambition and trajectory of the project so that the most effective pilots can be delivered. Pilot Scenarios have been developed in conjunction with the Technical design to ensure suitable conditions are available on the proposed construction sites being used for piloting. Particular work was also undertaken in the area of health and safety requirements, access to data and the impacts of an international pilot programme on data ratification.
T7.2 - Piloting and Validation 1: Knowledge Transfer – commenced with a series of targeted meetings between relevant consortium partners, focussing on the scope and practicalities of testing the CoOp App on a construction site. Mockups were created and have been analysed by specialist focus groups comprised of on-site professionals. The development of particular scenarios required to validate Co-Op functionalities has also taken place in preparation for live-piloting in the 2nd Period.
T7.3 – Piloting and Validation II: Project Coordination – has involved detailed engagement with the proposed pilot site provider, Broadland Housing Association. The consortium has been working to ensure that the requirements for piloting are fully understood by the Pilot Site Provider, and has been developing sequencing programmes and protocols for ensuring safe deployment and monitoring of piloting activities. Six focus groups have taken place engaging external professionals to assess the clickable mock-up of the SiMa App and emerging prototype. Early testing of functionalities, layout, mapping and usability has allowed feedback to be integrated directly into the development of the main SiMa App prototypes.
T7.4 – Piloting and Validation III: Quality Assurance – has not commenced, but preliminary discussions have already taken place between relevant technical and user partners within the consortium to ensure that the software prototyping is aligned with the expected provision of the piloting sites due to be available for this task.
The following important results were achieved in the period:
• D7.1 – Piloting Definition and Preparation - The Pilot Plans set out what is planned on being monitored, how monitoring takes place and is controlled and how the feedback will be fed back into the developing prototypes. The aim of the pilot studies is to improve the developing prototypes using real life review and feedback, to prove the project concept with validation to the project goals.
• Ten workshops have been successfully held across Europe to engage external industry professionals in the assessment of mock-ups and the early prototypes for both CoOp App and SiMa App.

Much of the first period effort focussed on developing coherent strategies for impact and innovation management. Strategies for application, monitoring and reaction were developed for each task within the WP8. Partner-level research into exploitation and collaboration opportunities has taken place, followed by a consortium-wide assessment of impact potential for each proposed WP8 activity.
A selection of target-specific dissemination materials have been created to support the proposed activities and significant preparation has gone into early participation at more than 45 regional, national and international events, 27 of which were organised directly by the ACCEPT consortium. An international Advisory Board has also been established for the Project, and this convened once within the Period.
Over the period, partners have worked to develop engagement opportunities with the industrial and scientific communities. In particular, focus groups, informal meetings and social media have been used to foster industrial participation with ACCEPT, whilst conferences and academic papers have been used as tools for disseminating ACCEPT project progress and results with the scientific community.
It is notable that the later stage of the Period saw the core of the activities shifting from strategizing to application, with most effort being directly associated with an activity engaging external stakeholders Importantly, the work undertaken in WP8 has developed to carefully align with the progress in other WPs, seeking to maximise project impact through good-timing and targeted release of project information. Furthermore, WP8 work has fed back into other WPs through collaboration activities with industry professionals and academics on specific ACCEPT-related themes. To date, more than 400 people have been reached directly through ACCEPT organised events, whilst over 50,000 people have been reached through ACCEPT literature publications to date.
T8.1 – IPR, Exploitation and Innovation

Progress beyond the state of the art and expected potential impact (including the socio-economic impact and the wider societal implications of the project so far)

In the last 20 years, the construction industry has been somewhat revitalised by an interest in improving the quality of construction within architecture. In particular, the industry has been driven towards reducing energy consumption during occupation – through ever-enhanced building fabrics and Building Management Systems. In addition, the sector has harnessed the impact of sustainable material specifications on carbon footprints and the improvement in programming through use of pattern-building and component-based design.
However, the industry has continuously struggled to achieve consistent Quality in several key areas – As-built performance, knowledge transfer and Adaptability. Buildings across Europe consistently fall short of the performance designers think will be achieved, lessons and insight are very slowly – if ever – shared through the chain of people involved in construction, and variations, mistakes and problems nearly always result in a comprise due to cost, time and competence pressures within a project. ACCEPT will pursue even greater contributions to the quality of architecture than have been seen in recent years by seeking to provide an infrastructure for direct engagement with these three areas of the construction process. A significant reduction in the performance gap - between design and as-built performance of buildings – is achievable through utilisation of the functionalities and services proposed by the ACCEPT project. Environmental design standards such as Passivhaus , BREEAM and LEED already offer excellent design approaches for delivering highly efficient low energy buildings, but there remains enormous scope for improving the actual building performance achieved by these programmes. ACCEPT will tackle this by offering a ground-breaking change to the primary workflow of a construction project – realigning and reordering the balance of information, decision-making and accountability between architects, clients, manufacturers, construction workers and subcontractors. Historically, there have consistent shortcomings at design level on practical construction site knowledge and a similarly impacting lack of awareness over design intentions and reasoning once on site. The ACCEPT system becomes a conduit for continuous information flow between users, allowing architects to respond to site queries directly, and before covering-up of completed works, removal of scaffolding etc. The ACCEPT system will allow engineers and manufacturers to feed in to sequencing of tasks on site in line with their specialist understanding of the products in use, whilst subcontractors could highlight inconsistencies in detailing or undetected clashes that could only be foreseen with their craftsmanship knowledge. This dramatic increase in information transfer throughout the whole delivery chain would have a significant impact on individual’s understanding of the various construction roles and will lead to a fundamentally better educated (and by extension, capable) construction industry.
Delivery and Programming Apps such as WaveTrakMTS already contribute to project efficiencies by monitoring and automatically updating material inventories, whilst other innovations have occurred in surveying through incorporation of Point-cloud and radio frequency and infrared technologies. As BIM truly begins to take hold with Europe, these products can be managed and fed into a ‘live’ building model, ensuring it is more and more reflective of the as-built project. However, the software and project infrastructures currently in place to support Level 3 BIM do not offer comprehensive platforms for engaging with the building data at every position through the construction chain. For example, programmes such as WaveTrakMTS exist to allow engineers to find clashes between mechanical and structural installations but there is no compelling process to either feed this information back through the delivery chain or, indeed, allow on-site specialists to input on the evolving 3D model. ACCEPT would finally provide a daily ‘table’ around which the typical project team meeting can take place but with attendance and input from 20, 30 or even 100 relevant people. Such collaboration along the workflow is unprecedented and would have considerable implications on current Best Practice.
Progress within the construction sector can be extremely fast within isolated projects, where there is a useful combination of money, time and ambition – but unfortunately, these resources do not tend to be abundantly available in most projects. ACCEPT’s contribution to reducing programme time will certainly reduce pressure on financial budgets – as will the reduction in design and construction mistakes, snagging post completion and on-going maintenance (less leakage, reduced cold bridging and associated condensation damage etc.). Ambition is a very difficult thing to harbour or encourage – but in truth, the construction industry perhaps lack this on the whole because it is not adequately resourced. ACCEPT will offer huge innovation potential by properly informing people about what is going on in all relevant aspects of the project. A carpenter can have access to areas of the initial concept designs, legislative data, manufacturer guidelines, material specifications, budget and performance requirements which can and do affect the quality of a piece of joinery work. Equipped with this knowledge, and a platform upon which to partake in dialogue over design evolution, this carpenter will almost certainly offer superior craftsmanship input into a project.
With this increased opportunity for expression and collaboration, more elaborate and innovative architecture will undoubtedly follow. Longstanding construction problems such as exemplary waterproofing of basement structures, significant improvements in internal air quality and interfacing between structural and thermal elements will have ACCEPT as platform for discourse and resolution. ACCEPT will not develop everything from sketch but reuse existing components, technologies and infrastructures wherever possible and meaningful. For example, ACCEPT does not aim or try to create a new set of Smart Glasses. Instead, it will use one of the Smart Glasses that have been described I this section as a base and extend it with the developments that will be created in the course of ACCEPT. The results of ACCEPT will lift the overall process to a new level by providing three main outcomes. Firstly, the CoOpApp running on Smart Glasses, which passively collects data and actively provides guidance to the worker on site during the building process. Secondly, the Site Manager App running on a mobile device (e.g. a tablet), which allows to remotely coordinate the working process as well as collect additional data on site by different sensors. And thirdly, an interactive web-based Dashboard as a monitoring and quality assurance solution. The Dashboard will use self-inspection methods to determine important metrics.

Related information

Follow us on: RSS Facebook Twitter YouTube Managed by the EU Publications Office Top