Cas Clients

 

Home Energy Management System (HEMS)

 

By Vladimir Williams

21/10/2026

 

As much as I love nuclear energy, I still believe that we should move towards a hybrid decentralized energy infrastructure for better reliability and greater resilience (N-1 redundancy). Now, of course, I'm not suggesting we each put a 10 MW micro-nuclear reactor into each neighborhood; don't get me started! This is where other renewables, like wind turbines and solar panels, come in. Paired with a local energy storage system (home batteries), access to a centralized grid for backup power, and integrated into aggregation systems like virtual power plants (VPPs), such power generation could reduce electrical bills, improve grid stability, and allow millions to achieve energy independence. Power to the masses, am I right? With the increasing availability, reliability, and falling price of home batteries and solar panels, this is an increasingly attractive option—for more details, check out IndexBox's 2026 France study.

 

My gears are already turning. Let's design such a system—a home energy management system (HEMS)—for ourselves and see how cheap we can make it! We're going to use a model-based approach to help make systems-level decisions, specifically, we'll be using the Arcadia (Architecture Analysis and Design Integrated Approach) method implemented in Eclipse Capella. Arcadia uses a structured, iterative process, flowing from general to particular, starting with broad and vague concepts to end at a detailed and specialized description [Weinberg, Gerald M. An introduction to general systems thinking. Vol. 304. New York: Wiley, 1975]. In model-based systems engineering (MBSE), this approach is formalized in the RFLP (Requirement, Function, Logical, and Physical) philosophy, where we move from broad operational and systems analyses, to detailed logical and physical architectures. Placed within a V-model (le cycle en V), we can continue to develop our system throughout its lifecycle, from capturing customer operational needs to system integration, verification, and validation (IVV). Along the way, we iteratively track requirements and cross-check each stage of development from conceptualization to operation, maintenance, and retirement.

 

With all these frameworks and structured methodologies, you might now be asking "Why bother?" Certainly with a system as simple as a hotel desk bell, these formalized approaches might rightfully be considered "overkill". As the system complexity increases, however, a formalized approach becomes more and more necessary—ad hoc approaches just won't cut it! While using these structured methods, we can meet the objectives and requirements in an efficient way, minimizing rework, catching errors early, and effectively communicating the purpose and function of the product to a multidisciplinary team. One way I like to think about it is as a structured method for solving a design optimization problem—much like machine learning's unconstrained optimization problem of finding local minima in a loss landscape—it doesn't always find the best solution, but it helps us build a list of options, develop selection criteria, and finally decide on the one which balances stakeholder, management, and engineering constraints.

 

On y va ! First by defining the problem to be solved by our system and then by realizing the solution. With Arcadia, we work through the following levels of abstraction, or layers:

  1. Operational Analysis to define what the user wants to accomplish
  2. System Analysis to formalize what the system has to accomplish for the user
  3. Logical Architecture to develop how the system will work to fulfill expectations
  4. Physical Architecture to develop how the system will be developed and built

Additionally, we can formalize component requirements in the End Product Breakdown Structure. The power behind using Capella is that all these entities/actors, capabilities, and relationships between them that we define at each layer are rigorously integrated into a semantic model. After completing each of the Operational, Systems, Logical, and Physical layers, we transition functions and entities to the next layer, allowing relationships to traverse the different layers and perspectives of our analysis. Since the underlying foundation is a unified model repository, modifications to any element are reflected across all related diagrams and layers. This provides the ability to validate properties of the and the architecture of the system with stakeholders and engineers of different specializations.

 

1. Operational Analysis

 

We start by performing a high-level analysis to define the problem: Who are the key players? What do they want to accomplish? How is our HEMS going to deliver the needs? At this stage, we it describe the operational ecosystem without committing to a system boundary. Capella encapsulates this in three key diagrams:

  • The Operational Capabilities Blank (OCB), which defines the involved entities and their operational capabilities

  • The Operational Activity Interaction Blank (OAIB), which defines the activities and the interactions between them which need to be undertaken to accomplish the capabilities, and

  • The Operational Architecture Blank (OAB), which assigns the activities to the actors and entities defined in the OCB.

In the OCB, boxes and nodes are used to represent operational entities (OEs) and their operational capabilities (OCs), while relationships are represented using arrows. For example, we (the User) wanting to reduce our electrical bills is represented by showing an arrow pointing from the "Reduce Electricity Bill" OC node to the User rectangle:

 

 

The OAIB has a similar dialect, but this time representing operational activities (OAs) as boxes with arrows between them representing interactions. For example, to reduce our electrical bill, something needs to "Generate Solar Power", "Store Surplus Energy", and "Power Home Usage". This chain of activities is represented as a directed graph in the OAIB:

 

 

In the OAB, we assign these OAs to the different OEs, for example, "The Sun provides solar irradiance, the Home Energy Management System generates and stores energy, and the User consumes it":

 

 

Here, I've identified chains of OAs to define Operational Processes which can be linked to our specific OCs.

 

2. System Analysis

 

At this step, we shift our focus onto the system's perspective. We formally define the system boundaries and connect operational capabilities to the capabilities of the system. Capella encapsulates this in two key diagrams:

  • The System Architecture Blank (SAB), drawn from the system persective assigns the activities to the actors and entities defined in the OCB, and

  • The Mission Capabilities Blank (MCB) addresses what the system must do to help achieve the operational capabilities defined in the Operational Analysis layer.

From this perspective, the system is a black box interacting with external entities and actors. As a rule of thumb, if it's something the system achieves (a capability) it belongs in the MCB, while if it's something the system does (a function) it belongs in the SAB. For example, "Reduce Electricity Bill" is something the system achieves, while "Harvest Solar Power" is something the system does.

 

 

You'll notice here the traceability Capella affords us. The transition from OAB to SAB created realization links where each System Function (SF) in the SAB realizes an OA from the OAB. This is how the Arcadia method guarantees that our system does what the operational context requires. The OAB is about the operational ecosystem, while the SAB is about the system's external responsibilities within that ecosystem, both are technology-agnostic.

 

3. Logical Architecture

 

This part always gets me as giddy as a child opening presents on Christmas morning, because here is where we get to open the black box and start to gain a notion of the solution to our problem! We define and refine logical components that have technology-agnostic responsibilities in our system: what logical role does each part plays, not what physical device it is.

 

 

I've already built a proof-of-concept Energy Management component in my Virtual Power Plant project, which takes user preferences to decide when to charge and discharge the batteries. It consumes battery state data—the state of charge (SOC), battery temperature, etc.—and applies rules like "don't discharge below 20% SOC", while sticking to user-set preferences like "prioritize backup", "maximize savings", or "allow VPP participation".