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>
7.7 KiB
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 building’s 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
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 what’s happening in the energy market or on the grid at that moment.
This model works fine in stable, predictable environments. But today’s 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 doesn’t 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:
- Use local renewable energy first
- Store excess energy for future use
- Use stored energy during shortages
- 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:
- PV energy is first used to fully satisfy the hospital demand
- 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:
- PV energy is used as much as possible
- 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 20–30%) is maintained to ensure backup availability in case of emergencies.
6.2 Backup Operation (Grid Failure Scenario)
In the event of a grid outage:
- The battery is used as the primary energy source
- The hydrogen fuel cell acts as a secondary backup
- 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 hospital’s 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):
- PV generation
- Battery storage
- Hydrogen fuel cell
- Grid import
Energy Allocation Priority (Excess):
- Serve load
- Charge battery
- Produce hydrogen
- 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