> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/english-v14/getting-started/kunstliche-intelligenz-in-abb-buildingpro/ki-orchestrierung-in-abb-buildingpro.md).

# AI orchestration in ABB BuildingPro

## **Introduction**

The increasing integration of AI technologies into building management — such as reinforcement learning (RL), forecasting, and large language models (LLMs) — opens up entirely new possibilities for efficiency, comfort, and sustainability. For these individual components to work together optimally rather than running in isolation side by side, a central orchestration layer is needed.\
In Eliona, they take on **rule chains** exactly this role: They act as a visual, flexible, and extensible **AI orchestration tool**, which connects data, models, and actions into end-to-end intelligent workflows.

## **Rule chains as an orchestration hub**

Rule chains are not just classic automation logic — they form the **central control and integration layer** for all AI modules in Eliona.\
This allows you to:

* **Trigger AI models** (e.g., update forecasts, start/stop RL optimizations).
* **Dynamically link data sources** (live sensor data, historical data, forecasts, external APIs).
* **Implement decision logic** (conditions, prioritization, escalations).
* **Execute actions** (plant control, ticket creation, email sending, app interactions).

## **Examples of AI orchestration**

### **1. Peak load avoidance with forecast integration**

<figure><img src="https://content.gitbook.com/content/Nyvwhz1kEMXcHf4HLuZ8/blobs/HqKLyHe81JdOAfUKAMlo/forecast%20app%20(7).png" alt=""><figcaption></figcaption></figure>

* **Data sources**: Current load values + forecast attributes from the Forecast app.
* **Rule chain**:
  1. Get Data node reads the forecast peak load.
  2. Condition node checks whether the forecast value is > 200 kW.
  3. Action node reduces the supply temperature or shifts consumer loads.
  4. Optional: Email node proactively informs the energy team.
* **Result**: Peak loads are avoided before they occur.

### **2. Orchestrate reinforcement learning**

* **Trigger**: Forecast data or external events (e.g., tariff change).
* **Rule chain**:
  1. Condition node checks whether optimization potential exists.
  2. RL node starts or pauses the RL agent.
  3. Script node evaluates performance and automatically creates reports.
  4. **Fail-safe monitoring**: An additional condition node continuously monitors whether the running RL model performs unauthorized or safety-critical actions (e.g., exceeding comfort limits, impermissible switching frequency).
  5. If a violation is detected, an action node immediately sends a **stop signal** to the RL node and optionally an alert message to the operations team.
* **Result**: RL is only activated live when it brings maximum benefit — and can be both **automatically paused** and **immediately stopped** if it performs undesirable actions.

### **3. LLM-supported automation workflows**

#### **a) Rule chain via text prompt**

* **Use case**: With an LLM node, complete rule chains can be created through simple text input.
* **Example prompt**:\
  *“Create a rule chain that lowers the supply temperature by 2 K when grid peaks exceed 200 kW and creates a ticket for the energy manager.”*
* **Result**: The LLM translates the prompt into a visual chain with Get Data, Condition, RL node, and Action node.

#### **b) Agent node for ticket & email flows**

* **Ticket automation**: In the event of an alarm, the agent node uses the LLM to generate a complete ticket text, assigns the right service technician, and stores priority as well as context.
* **Email recommendation**: If a critical deviation is detected, the agent node drafts an email with action recommendations\
  *("Please add 1 K of heating until outside temperature > 15 °C")*\
  and sends it to the responsible department.

#### **c) Practical example: Autonomous AI optimizer**

1. **LLM node**: *“Optimize energy in building A, maintain a comfort range of 22 °C.”*
2. **Get Data nodes**: Read current sensor values, forecast data, and tariff information.
3. **Correlation Script node**: Identifies relevant influencing factors (e.g., outside vs. indoor temperature).
4. **RL node**: Configures and starts the world-based agent — pre-trained offline and ready to use immediately.
5. **Agent node**: Generates monthly reports, suggests rule chain adjustments, and briefly asks for manual approval.
6. **Action nodes**: Start/pause apps, send emails, create tickets when threshold values are exceeded.

## **Agent nodes – outlook for the future**

In future versions, Eliona will **Agent nodes** offer that:

* Can be fed with domain-specific expert knowledge.
* Make autonomous decisions and derive measures.
* Independently execute actions such as forecast updates, RL control, or escalation management.
* Be directly integrated into rule chains to enable fully automatic, learning building processes.

## **Benefits of AI orchestration with rule chains**

* **Centralization**: One platform for all AI modules and automation logic.
* **Flexibility**: Easy adjustment of workflows via drag and drop.
* **Transparency**: Every action is visually documented and auditable.
* **Scalability**: Usable for individual plants up to thousands of assets.
* **Future-proofing**: Expandable with new AI modules such as anomaly detection or computer vision.

## **Conclusion**

With the **AI orchestration in Eliona** rule chains become the centerpiece of autonomous building operations. They connect RL, forecasting, LLMs, and classic automation logic into a seamless, adaptive system — one that not only reacts, but acts proactively.\
This creates a platform that already makes operations more efficient today and is at the same time ready for the next generation of AI-powered smart buildings.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.buildings.ability.abb/collection/english-v14/getting-started/kunstliche-intelligenz-in-abb-buildingpro/ki-orchestrierung-in-abb-buildingpro.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.