Modular design, customized approach: How our EPOC® EMS combines quality and flexibility

The CONENGA Group brings years of experience in the process optimization and control of energy plants and energy parks. One insight has been confirmed time and again: No two plants are alike.

Whether it’s a biomass cogeneration plant, an industrial process energy supply, or a municipal district heating network—each site has its own unique combination of generators, storage systems, and consumers, as well as its own technical and economic constraints. An energy management system must be able to account for these differences.

At the same time, a system that automatically optimizes plant schedules must function reliably. An optimization model may appear technically sound yet still lead to unexpected results in a specific plant configuration. That is why, for us, it is not only the system’s flexibility that is crucial, but especially the ability to systematically test its individual components and the overall system.

With about a decade of experience in software development, I have taken on the task of expanding the CONENGA Group’s EPOC® Suite to include an energy management system that addresses precisely this reality: a solution tailored to each specific site and built on standardized, reusable, and tested components.

At first glance, this sounds like a contradiction. How can software be both standardized and customized at the same time?

The answer lies in modularity—and in a testing strategy that consistently leverages this modularity.

For us, an energy management system is more than just software for collecting and visualizing energy data. At its core, the EPOC® EMS is an optimization system (EMOS, Energy Management & Optimization System): It maps the technical and economic constraints of a site (site model), incorporates forecasts (e.g., weather forecasts, demand forecasts), and uses this information to calculate optimal schedules for the available generators, storage systems, and consumers.

It is precisely this challenge that makes the question of standardization versus customization particularly relevant. After all, if each location has different equipment, technical constraints, and business objectives, the underlying optimization model must also be flexible enough to adapt—while still functioning reliably.

How can this be achieved?

The Dilemma: Standard Solution or Custom Development?

When developing software solutions, two fundamental approaches can be distinguished: A standard solution is developed as a ready-made product for a broader range of applications and then configured at the customer’s site. In contrast, a custom development involves creating software specifically tailored to the requirements of a particular customer or site.

Both approaches have their merits, but each presents different challenges. Off-the-shelf solutions do not necessarily meet specific technical or business requirements. Custom developments can be tailored very precisely to a specific use case, but they require more development and maintenance effort. In addition, customer-specific functions and their interactions must be tested accordingly.

Neither option is ideal for our customers.

The solution cannot be to adapt the system to the software. It must be to flexibly adapt the software to the system—without having to redevelop and retest the entire software for every project.

An established approach in software development for precisely this type of challenge is Software Product Line Engineering (SPLE). In this approach, not every software system is developed completely independently. Instead, a family of related systems is created from a shared set of reusable components, functions, and other development artifacts. The individual products differ where their respective requirements dictate.

This is precisely the principle we follow in our energy management system.

We do not develop a completely new EMS for every location. Instead, we develop a common foundation consisting of tested system components, optimization algorithms, and technical rules, from which individual location-specific solutions can be assembled.

Standardization therefore does not occur at the level of the finished product, but rather at the level of the building blocks. This allows us to accommodate individual requirements while simultaneously drawing on functionality that has already been developed and tested.

Standardized Modules, Customized Systems

The EPOC® EMS features pre-built, implemented, and tested components for various types of systems. These include, for example, thermal buffers, battery storage systems, combined heat and power (CHP) units, and (biomass) boilers.

However, modularity does not end at the level of system components. The underlying algorithms are also designed as reusable building blocks.

One example is minimum operating times and minimum downtime. Such technical restrictions are relevant for a combined heat and power (CHP) plant, but can also play a role in other types of facilities. Therefore, once an algorithm has been developed and tested, it need not be limited to a single type of facility.

The advantages of this approach become clear when comparing two simplified sites:

• Site A has two generation sources—a biomass boiler and a PV system—a thermal storage unit, a greenhouse as an electricity and heat consumer, and a grid connection.
• Site B has a similar biomass boiler and thermal storage unit, as well as an additional battery storage system. Electricity and heat are supplied here to a production facility on site.

The same proven components for biomass boilers and heat storage systems can be used at both sites. For Site B, these components do not need to be redeveloped; they simply need to be configured to meet the technical requirements. The site will then be expanded to include modules for a battery storage system and the corresponding production facility.

A new plant configuration is thus created not through a completely new development, but by combining proven building blocks.

This approach thus corresponds to the basic principle of a software product line: a common base of reusable “core assets” forms the foundation for different variants. In our EMS, for example, these core assets include plant models, optimization algorithms, and technical constraints.

The specific site solution is created by selecting, configuring, and combining these building blocks, as well as by adding site-specific functionality.

Modularity Ensures Quality Through Systematic Testing

With an energy management system, functioning software alone is not enough. The calculated schedules must also operate reliably and transparently under various technical and economic conditions.

That is why, for us, testing is not a final step at the end of development. Testability is an integral part of the architecture. The modular structure of the EMS makes it possible to systematically test functionality at various levels.

This allows individual algorithms to be tested independently of a specific site. Building on this, system components can be tested before they are combined with other components to form a site model. Finally, the entire system is also tested with its site-specific configuration.

Algorithm → Component → Combination of Components → Complete Site

A new customer-specific component does not start from scratch. It can build on algorithms and components that have already been tested and is supplemented with tests specific to that component.

Reuse is therefore not limited to software code. Test cases, test knowledge, and test infrastructure also become reusable.

“Custom” does not mean “identical,” however

However, modularity does not mean that every component is operated exactly the same way at every location.

A battery, for example, can perform a wide variety of tasks: It can be used primarily to optimize self-consumption or to participate in a balancing energy market. Even two CHP units can differ significantly in terms of power limits, efficiency curves, or other technical constraints.

These differences can be addressed on several levels. Standard components can be adapted to the specific system using parameters—for example, with regard to power limits, efficiency curves, or operating strategies. If the configuration is insufficient, existing components can be expanded as needed. Technically, this involves building upon a class from the standard library and supplementing or adapting it with customer-specific properties.

This preserves the proven core functionality, while customization is built upon it in a targeted and traceable manner.

But what if the required module doesn’t even exist yet?

Not every type of equipment that will be needed in a future project has to be included in the standard library already. One example is an electrolyzer for hydrogen production.

An electrolyzer is not yet a standard component of our EMS. However, if one is needed for a project, there is no need to redevelop the entire optimization logic from scratch. Here, too, existing building blocks can be reused. For example, there are sound technical reasons to limit the frequent switching on and off of an electrolyzer. Minimum runtime and minimum downtime may therefore be relevant. The algorithm required for this was originally developed for a combined heat and power (CHP) plant and extensively tested. It can now be used as a building block in a new component as well.

In this way, new types of plants can also be built on an existing, modular basis.

Technical Box: What “Modular” Means in the Optimizer

The EPOC® EMS solves a mathematical optimization problem to determine optimal operating schedules for the plants involved. To do this, the underlying problem is formulated as a mixed-integer linear program (MILP).

It is therefore not merely a heuristic or a visualization of existing energy flows. The system calculates an optimized plant schedule while taking technical and economic constraints into account.

In matrix notation, the optimization problem can be written as:

The vector contains the decision variables of the optimization problem at each time step of the optimization horizon—for example, power output, storage levels, or the on/off states of plants. The vector describes the costs, while the associated constraints represent the technical and economic constraints.

The modularity of the EMS is also directly reflected in this mathematical model.

For an example site with a CHP unit, thermal storage, a PV system, and power-to-heat, the matrix and the vector can be represented as a combination of various plant blocks—the same applies analogously to the vectors of the constraints:

Each plant comes with its own set of technical constraints. The remaining entries are initially set to zero. It is only through the coupling conditions that the individual plants are linked together—for example, via a shared heat or power balance.

The individual plant blocks can, in turn, also have a modular structure. A CHP plant model, for example, can consist of general building blocks for minimum operating times and planned outages, which are then supplemented with individual properties and parameterized.

Advantages of the Modular Approach

In developing our EMS, we follow the principles of software product line engineering: A common software base consisting of reusable components and algorithms forms the foundation for various, individually configured site-specific solutions.

This approach offers us the following advantages in particular:

• High quality and lower risk of errors: Proven components and algorithms can be reused instead of being reimplemented for each project. New developments build on functionality that has already been tested.
• Good maintainability: Clearly defined and understandable components facilitate maintenance and further development. The modular structure and the resulting improved code readability help prevent errors during changes and keep future developments manageable.
• Traceable customization: Customer-specific requirements can be built specifically on existing components, rather than modifying the entire solution.
• Efficient implementation: Existing components and algorithms, as well as the associated development and test artifacts, can be reused for new locations.
• Scalability: New systems and requirements can be integrated as additional modules without having to fundamentally change the existing foundation.

Conclusion: Customized Solutions Based on Proven Technology

No two energy systems are alike. An energy management system must therefore take into account the specific technical and economic conditions of each site. At the same time, it must function reliably and remain manageable even as the system is expanded in the future.

This is precisely where the strength of our modular approach lies.

We do not standardize the system or the finished site. We standardize the building blocks from which the customized solution is constructed—thereby creating a common, systematically tested foundation.

In doing so, we follow the principles of software product line engineering: Reusable components and algorithms can be combined to create different, customized site-specific solutions and expanded as needed. This modularity not only enables flexibility but also facilitates systematic quality assurance.

The EPOC® EMS uses this foundation to model technical and economic constraints within an optimization model and, based on that, calculate optimal schedules for plant operations. It thus goes beyond the mere collection and management of energy data. From our project experience at the CONENGA Group, we know that very few sites already have a true optimizer for their schedules—often because individual plant configurations and available standard software are difficult to reconcile.

Our modular approach closes precisely this gap: customized optimization on a shared, reusable, and systematically tested software platform.

However, for the EMS to optimize operations automatically, it needs a robust data foundation. As I’ve already described in my blog post on digitalization, the collection and consolidation of operational data via CONENGA Process Data is a key foundation for this.

Digitalization and optimization are thus intertwined: The robust data foundation enables automated schedule optimization. The modular software platform, in turn, makes it possible to implement this optimization even for custom-designed sites on a quality-assured basis—while pursuing individual goals, fully in line with Industry 5.0.