ALLSHIFT/docs/02-specifications/rule-based-controller.md
pepe 72dd781dbc Organize documentation into docs/ and superseded/
Audit every document in the repository, convert the non-markdown ones into
markdown reports, and split current documentation from outdated material.

docs/ — 31 markdown documents in seven numbered sections. Twenty are new
reports generated from .docx / .pdf / .xlsx / .mlx / .m sources that were
previously unreadable in the browser and undiffable in git. Each report
carries a provenance block (source path, format, MD5) and links back to its
original; all 13 recorded checksums verify against the files on disk.
Machine-extraction losses (PDF table column interleaving, Word OMML
equations, embedded figures) are called out explicitly rather than silently
smoothed over.

superseded/ — outdated material with a documented reason per entry:
two byte-identical ClickUp re-exports, an older revision of the BIDMC/UCSD
energy-flow doc (the retained copy adds the SoC Violation Rate KPI), a
duplicate of Shift input data.docx, the May 2026 simulation plan, the
root PV+Battery.md now covered by a fuller report, GitHub's stock
demo-repository template, and a zero-byte placeholder. Its README also
records what was deliberately NOT retired and why — the "Old Frameworks"
and "Old Simulations" folders hold unique Simulink revisions, and
"Big Ugly Folder" holds the only copy of framework revision 1.3.

Findings worth flagging, all documented in the reports:
- Simulink lineage recovered from each .slx's internal coreProperties.xml
  revision counter. The current model is
  Current Framework/Bobert0206_Initial_Simulation_Framework.slx (rev 2.7);
  the top-level copy is rev 1.3, five revisions behind.
- Simulations/Constants.m is a truncated byte-prefix of the Current
  Framework copy, silently missing H2_leak, H2_cap and E_H2_vol_h.
- The PEM electrolyser and fuel cell are unmodified MathWorks Simscape
  examples still at vendor defaults; the "10x bigger" sizing TODO recorded
  in Constants.m was never carried out.
- controller-claude.m does not compile — undefined P_Electro_max, outputs
  unassigned on several paths.
- The specification set uses two incompatible variable naming conventions
  and disagrees on action-space size (5 vs 16).
- MA_hourly_load.csv (13.7 MB) is the same 35,040 rows as 89993-0.parquet
  (2.4 MB).
- Clinical data is the MIMIC-IV *demo* (ODbL, 100 patients), not full
  MIMIC-IV — redistributable, but the licence and citation are unrecorded.

Housekeeping: untrack 21 Simulink build artefacts (slprj/, *.slxc) and add
ignore rules for them. Root README rewritten around the new layout.

Recruitment notes naming individual candidates are excluded from version
control via .gitignore rather than committed; the generic question template
is kept in docs/07-team-and-operations/.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:20:33 -07:00

7.7 KiB
Raw Permalink Blame History

RULE-BASED EMS

Rule-Based Energy Management System to Enhance PV Self-Consumption in a Building: A Real Case

“The EMS presented in this article is a rule-based EMS (RB-EMS) and its objective is to maximize the self-consumption rate (SCR) of PV energy actuating on the heating, ventilation and air conditioning (HVAC) of ESTIA2 building involved in the CSC, taking into account the comfort of users.”

HVAC: heat, ventilation and air-conditioning

CSC: collective self-consumption

“At each time step, the priority is to self-consume the buildings energy production. Then, any surplus is used to charge the battery and, finally, it is exported to the grid in case the storage system is full. Import from the grid is the last resort in case of low local production and not enough stored energy inside the battery. ”

This paper uses HVAC as the flexible load

rather than a battery. When there is excess

PV, instead of storing electricity in a battery,

it runs the heating/cooling system harder

(pre-heating or pre-cooling the building).

The building itself acts as a thermal "battery."

Step 1 / Read data
It read PV power being generated (PPV) and building consumption
(PC). Then calculates e = PPV-PC (the energy surplus or deficit)

Step 2 / Compare e against a threshold h
e < -h: More consumption than PV (deficit)
HVAC units are sorted by room temperated, if a room is above
comfort threshold, the corresponding unit is switched OFF to reduce
consumption, then checks if any OFF units can be turned ON for
comfort maintenance
|e| < h: Roughly balanced
PV and consumption are close enough, so no action needed
e > h: More PV than consumption (surplus)
Excess solar energy is available, the controller looks for HVAc units that are
OFF and could be switched ON. Switches ON the unit in the coldest room
to absorb the extra PV energy. If more surplus remains, it may switch OFF a unit and ON another to redistribute

Step 3 / Wait 5 minutes, then repeat until the end of day (5 minutes is the sampling time)

*Techno Park in France


RB-EMS vs AI-EMS

tibo energy

Rule Based EMS How
A rule-based EMS runs on predefined rules. Think: “if the solar array produces more than 50 kW, switch on the battery” or “only charge the EV fleet between 22:00 and 06:00.” The system follows these instructions literally, regardless of whats happening in the energy market or on the grid at that moment.
This model works fine in stable, predictable environments. But todays energy market is anything but stable. Dynamic energy prices change every quarter of an hour, renewable generation fluctuates with the weather, and grid congestion is forcing companies to actively steer their power flows.

AI Energy Management
AI energy management takes a fundamentally different approach. Instead of fixed rules, the system uses machine learning and predictive models to continuously learn from data: historical consumption, weather forecasts, energy prices, grid load and the behaviour of every connected asset.
Based on that data, an AI-driven EMS makes autonomous decisions every few minutes. When to charge? When to store? When to feed back to the grid? The system doesnt optimise based on a static rule, but based on what is smartest right now.


HOW WOULD THIS LOOK FOR US?

1 Objective

The purpose of the rule-based controller is to manage energy flows within the hospital energy system using a deterministic set of priorities. This baseline strategy ensures:

  • Reliable supply to hospital demand
  • Efficient use of on-site renewable energy (PV)
  • Rational use of storage systems (battery and hydrogen)
  • Reduced reliance on the grid where possible

2 System Components

The controller manages the following energy sources and storage systems:

  • Photovoltaic (PV) generation
  • Battery storage system
  • Hydrogen system
    • Electrolyzer (electricity → hydrogen)
    • Fuel cell (hydrogen → electricity)
  • Grid connection
  • Hospital load demand

3 Control Philosophy

The controller follows a priority-based dispatch strategy, where energy is allocated based on predefined rules rather than optimization.

The general philosophy is:

  1. Use local renewable energy first
  2. Store excess energy for future use
  3. Use stored energy during shortages
  4. Use the grid as a last resort (or strategically based on price)

4 Energy Allocation Logic

4.1 Normal Operation

At each time step, the controller compares PV generation with hospital demand.

Case 1: PV Generation Exceeds Demand

When on-site renewable generation exceeds the hospital load:

  1. PV energy is first used to fully satisfy the hospital demand
  2. The excess energy is allocated as follows:
    • Charge the battery until it reaches maximum capacity
    • If the battery is full, use excess energy to produce hydrogen via the electrolyzer
    • If both battery and hydrogen storage are full, excess energy is exported to the grid

Case 2: PV Generation is Less Than Demand

When PV generation is insufficient:

  1. PV energy is used as much as possible
  2. The remaining demand is supplied:
    • Battery discharge (if sufficient charge is available)
    • Hydrogen fuel cell (if hydrogen is available)
    • Grid import as the final fallback

5 Cost-Aware Operation (Optional Enhancement)

To improve economic performance, electricity price signals can be incorporated:

  • During peak price periods:
    • Prioritize battery discharge and hydrogen usage
    • Minimize grid import
  • During off-peak periods:
    • Prefer grid electricity if it is cheaper
    • Preserve stored energy for future high-cost or emergency periods

6 Reliability and Hospital Constraints

Given the critical nature of hospital operations, additional constraints are introduced:

6.1 Minimum Battery Reserve

A minimum state of charge (for example 2030%) is maintained to ensure backup availability in case of emergencies.

6.2 Backup Operation (Grid Failure Scenario)

In the event of a grid outage:

  1. The battery is used as the primary energy source
  2. The hydrogen fuel cell acts as a secondary backup
  3. Energy is prioritized for critical hospital loads

6.3 Critical vs Non-Critical Loads (Optional)

If load segmentation* is available:

  • Critical loads (ICU, operating rooms, emergency systems) are always prioritized
  • Non-critical loads may be reduced or shed during severe shortages

*dividing the hospitals total electricity demand into different categories based on priority, function, or flexibility, so the energy system can make smarter decisions during shortages or optimization.

7 Hydrogen System Role

Due to lower round-trip efficiency compared to batteries:

  • Hydrogen is primarily used for:
    • Long-term energy storage
    • Backup during extended shortages
  • It is only produced when:
    • Battery storage is fully utilized
    • Excess renewable energy is available

8 Summary of Control Priorities

Energy Supply Priority (Deficit):

  1. PV generation
  2. Battery storage
  3. Hydrogen fuel cell
  4. Grid import

Energy Allocation Priority (Excess):

  1. Serve load
  2. Charge battery
  3. Produce hydrogen
  4. Export

9 Limitations of Rule-Based Approach

  • Does not anticipate future demand or generation
  • Cannot optimally respond to dynamic electricity prices
  • May lead to suboptimal use of storage systems
  • Lacks adaptability to changing conditions