iGFBs Pedia

What is an iGFB?

In the WeForming context, an Intelligent Grid-Forming Building uses monitoring, control and digital communication to coordinate its energy use and available local resources with wider energy-system needs. Depending on equipment and controls, it may adjust when it consumes electricity, use locally generated energy, store energy or make flexibility available through an external service.

How is it different from a conventional smart building?

A conventional smart building may automate heating, cooling, lighting and other functions. An iGFB adds an emphasis on coordinating energy-related decisions with external conditions, such as renewable generation, electricity prices or flexibility requests, when the required equipment and agreements are available.

Does “grid-forming” mean every building can stabilise the grid by itself?

No. The term should not be interpreted as a claim that every installation can provide every grid-support function. A specific service depends on the building’s equipment, controls, connection and service requirements.

What value can iGFBs create?

• Potentially improve the timing and efficiency of energy use.
• Increase use of locally generated renewable electricity where generation and demand can be coordinated.
• Help reduce peak demand or provide flexibility where technically and contractually available.
• Give operators better information about energy use and equipment operation.
• Support services and business arrangements between building owners and energy actors.

These are potential benefits, not guaranteed outcomes. Savings depend on baseline performance, prices, behaviour, equipment and control quality.

Which assets may support an iGFB?

Depending on the building, assets may include photovoltaic panels, stationary batteries, heat pumps, heating and cooling systems, thermal storage, EV chargers, controllable appliances and building automation systems. Not every building has all of these assets, and not every asset is available for external control.

Key concepts

• Demand response: changing electricity consumption in response to a price, grid condition or authorised service request, while respecting technical limits and occupant needs.
• Load shifting: moving some electricity use from one time to another.
• Peak shaving: reducing the highest level of demand during a period.
• Self-consumption: using locally generated electricity within the site.
• Storage: retaining electrical or thermal energy for later use.

How should flexibility be evaluated?

Measure the amount of power or energy changed, response time and duration, repeatability, comfort impacts and overrides, energy losses, baseline assumptions and uncertainty. Financial value should be distinguished from non-financial benefits.

Building Energy Management System (BEMS)

A BEMS collects information from building systems and supports monitoring, scheduling and control of equipment such as HVAC, meters, renewable generation and storage.

Real-time controller

A controller translates schedules or objectives into equipment actions and checks operational data. Specific timing ranges or implementation claims should be confirmed by the responsible technical source.

Digital twin and BIM

A digital twin is a digital representation of an asset or process used to understand behaviour, test scenarios or support decisions. Building Information Modelling (BIM) provides structured information about a building, but BIM and a live digital twin are not the same thing. Claims about a digital twin should state what it represents, which data it uses and how it has been validated.

AI, Model Predictive Control and reinforcement learning

AI and machine learning may support forecasting, pattern recognition, fault detection and optimisation. Model Predictive Control uses a model and forecasts to evaluate actions under constraints; reinforcement learning learns a policy from action outcomes. These methods are not interchangeable and are not required for every iGFB. Their performance must be evaluated and decisions affecting comfort or safety need appropriate constraints and oversight.

What is interoperability?

Interoperability means different systems or organisations can work together and exchange information in a way the receiving system can interpret and use. A connection or API alone is not enough; compatible meanings, units, identifiers, timing, security and procedures also matter.

What is a Data Space?

A Data Space is a governed environment where independent participants can make selected data or services available under agreed rules. A federated approach can allow data to remain with its provider while authorised parties access it through controlled mechanisms.

What do Connectors, catalogues and identity services do?

• Connector: provides a controlled technical route for a participant to exchange data.
• Data/service catalogue: describes available datasets or services so participants can discover them.
• Identity service: helps identify and authenticate participating organisations or services.
• Middleware: connects systems and provides shared integration functions.

A catalogue entry does not itself grant access or guarantee data quality. Likewise, a Data Space does not automatically guarantee privacy, security or quality; outcomes depend on implementation, identity and access controls, contracts, monitoring and applicable law.

Data sovereignty and privacy

Data sovereignty means participants retain meaningful control over how their data is accessed and used. Good practice includes collecting only necessary data, defining purpose-specific permissions, securing systems, clarifying responsibilities and providing understandable choices to occupants where personal data is involved.

Different participants contribute different responsibilities: building owners and asset managers set objectives; occupants experience effects on comfort, cost and privacy; facility managers operate systems; technology providers supply equipment and software; suppliers, DSOs, TSOs, aggregators, Energy Service Companies (ESCOs), public authorities and regulators contribute through their respective roles.

Business-model families described in the Pedia

• One-Stop-Shop (OSS): brings several services or steps together for a customer.
• Product-as-a-Service (PaaS): provides access to a product or function under a service arrangement.
• Innovative Financing Schemes (IFS): arrangements intended to address upfront costs.
• New Revenue Models (NRM): potential revenue from flexibility, aggregation or energy services.

These are options to evaluate, not evidence that every model is commercially viable. A business case should separate bill savings, service revenue and non-financial benefits, include capital and operating costs, set out assumptions and risks, and address occupant interests and data rights.

WeForming is a European research and innovation project titled “Buildings as Efficient Interoperable Formers of Clean Energy Ecosystems.” Its deliverables explore stakeholder needs, iGFB technologies, potential business models, interoperability and a reference architecture.

A demonstration can provide evidence about integration, operation, user acceptance and practical constraints. A pilot objective is not the same as a measured result. Public descriptions should distinguish whether a capability is planned, under implementation, operating, evaluated or completed.

The Pedia source document notes that pilot-specific descriptions—including site, installed technologies, status and outcomes—require confirmation against approved, pilot-specific sources before publication. Third-party project names and outcomes should likewise link to official sources and be checked for current status.

Related content: Project source register · WeForming video demonstrations · WeForming project pilot deployment context

A practical sequence

1. Set a clear objective, such as reducing energy use, improving renewable self-consumption, providing flexibility or improving monitoring.
2. Map meters, major loads, generation, storage, controls and connection constraints.
3. Understand occupant needs, accessibility, privacy and override requirements.
4. Check data availability, units, sampling, quality, permissions and ownership.
5. Assess interfaces, vendor constraints, integration and cybersecurity responsibilities.
6. Choose one use case and confirm its technical and commercial requirements.
7. Test controls with safe limits, failure modes, manual override and recovery.
8. Establish a baseline, indicators, time period and measurement method.
9. Review outcomes and improve based on evidence.

Useful performance indicators

• Energy: consumption, peak demand, self-consumption and renewable share.
• Flexibility: power change, response time, duration, availability and delivery accuracy.
• Occupant outcomes: comfort deviations, complaints, overrides and accessibility feedback.
• Operational: equipment availability, faults, maintenance and recovery time.
• Digital: data completeness, latency, failed exchanges and access-policy events.
• Economic/environmental: costs, verified savings, service revenue assumptions, emissions factors and renewable utilisation.

Good co-creation involves affected people in defining needs, testing options and reviewing outcomes. The Pedia notes that the initial survey of 36 respondents was concentrated in the Spanish demonstration and included a relatively highly educated group, so it should not be treated as representative of all European building users.

The WeForming Building Interoperability Solution (W-IBRA) is the digital infrastructure intended to help different building and energy stakeholders discover services, integrate data from varied systems, and exchange information under shared interoperability and governance rules.

Its integrated architecture connects the Middleware, distributed Connectors, App Store, identity services and related components. The aim is to help buildings participate more actively in clean-energy ecosystems while supporting scalable collaboration across different technologies and organisations.

Related terms iGFB · Data space · Interoperability

The service catalogue helps users find relevant data services through searchable descriptions and metadata. The App Store supports application discovery and deployment, connecting digital tools with the data and services they need.

For users, the intended value is easier access to suitable services—for example, services that may support energy optimisation, building monitoring or flexibility-related activities—without needing to understand every underlying technical component.

Related terms Service catalogue · Metadata · App Store

The Connector is the participant-side gateway for publishing and consuming data services. It supports structured, secure exchanges between participants, while the platform’s broader governance and interoperability mechanisms help coordinate who can discover and access which offerings.

The report describes local deployment as well as a cloud-hosted Connector-as-a-Service option. The latter can reduce the infrastructure burden for smaller stakeholders or residential participants.

Related terms Connector · Connector-as-a-Service · Data sovereignty

The Middleware coordinates the data-space ecosystem. Its described capabilities include service and metadata discovery, metadata synchronisation, participant and Connector governance, transaction monitoring and notifications. The Middleware primarily coordinates and manages the service process; data exchange is carried out through the Connectors.

This separation helps the platform coordinate participants while supporting controlled, decentralised data exchange.

Related terms Middleware · Metadata · Interoperability

The deliverable describes identity and governance mechanisms for participant onboarding, trusted participation, and controlled access to data services. Users and organisations are intended to retain autonomy over the data they make available and the parties with whom they share it.

Decentralised identifiers and verifiable credentials support identity and participation checks. These mechanisms are part of the platform’s approach to trust and accountability; they do not mean that every dataset is automatically public or shared with all participants.

Related terms Self-sovereign identity · DID · Verifiable credential

The report describes integration tests across the Middleware, Connectors and App Store, including metadata synchronisation, authentication, service publication, subscriptions, data exchange and transaction monitoring. It states that end-to-end scenarios were tested and that pilot participants use the platform for service publication, discovery and data provision/consumption.

This supports the conclusion that WeForming project progressed beyond separate software components to an integrated infrastructure used in pilot scenarios.

Related terms API · Data space · Interoperability

The report describes different deployment patterns across pilots, reflecting local needs and operational priorities. Data flows can support monitoring and optimisation of local energy systems, building energy and comfort analysis, flexibility assessment, and coordination involving assets such as photovoltaic generation, batteries and EV charging.

The report presents these as purposes and use cases for data exchange. It does not provide a single quantified energy-saving result that can be attributed to WeForming project across all pilots.

Source location Source location: WeForming integrated-platform deliverable, sections 8.1, including the pilot data-exchange status table.