Café XENON: A look at gridX’s energy management software

Beneath gridX’s sleek, easy-to-use interface lies a sprawling galaxy of code and data that powers everything that we do. From the energy sources our gridBoxes manage to the devices this energy powers, how much, when and countless other pieces of information run between the cloud and application to create a smooth, highly adept process that allows users to manage their energy efficiently and cost effectively. And it’s not only for the end user that everything must run smoothly, but energy companies and gridX too. The software has to be smart and flexible enough to allow our energy management system (EMS) to adapt to new markets, integrate assets and modify according to new regulations.

That sounds like a lot. How does it all work?

The development process at gridX is similar to a restaurant. There is the diner (the energy company) who enters and prepares to order a meal (i.e. utilize gridX’s energy management software). The host, the waiter, the menu and everything that makes up the restaurant setting is comparable to frontend development. This is the front-facing part of the application and it is all that the user sees. 

Once the client has ordered, the waiter relays this information to the staff in the kitchen – the backend – who then use data (aka the ingredients) to create the meal for the customer. The dish can be tailored to the customer’s specifications should there be something they want added, modified or left out.

Okay, now I’m hungry. Tell me more!

Each module within gridX has its own frontend/backend team: time of use tariffs, grid protector, peak shaver, energy optimizer, etc. By owning the full stack, each team becomes an expert of the needs and components of their specific module. This allows for faster work, easier collaboration with other teams and a greater opportunity for scale. Think of this as specialist teams for entrees, main meals or desserts – each team follows the same process but delivers a different outcome.

Data lake and calculator

The data that the renewable energy sources send through XENON are first sent to the data lake and calculator department. “It’s raw measurements that our team then sifts through to determine cost-effective storage and retrieval of the data,” says Chris Coltsman, DataLake and Calculator Team Lead. “All of the data gets rooted here.” The team uses this to create insights that are then passed on to help other gridX departments determine where processes can be enhanced. Like the ingredients for the meals at a restaurant, much of the development process starts here.

Backend

The backend facilitates and authorizes access for the frontend and API connections to the other components. It’s a central piece that links the functions provided by the other parts of the system like the data lake, calculator and EMS. Using Go, the backend receives live measurements from the gridBoxes and provides these to the frontend to show real-time consumption and provide access to configuration options. They are like the cooks and chef in the back of the kitchen, preparing the meal that will be brought out by the frontend. 

The backend lays the foundation for the prioritization of devices so that surplus energy is directed to various devices in the order of their choice. In special circumstances, these processes and/or prioritizations can be tailored to the specific needs of companies.

Frontend

While the backend provides the data that XENON uses, the frontend translates it into an interface customers understand. When users watch the wattage hours increase and decrease, they are watching the execution of frontend code written largely in typescript and javascript.

The frontend is also responsible for the customization clients may want, such as using their own brand colors and fonts. They customize the feature tiles for each client, so that each XENON application is unique to a company and displays the exact information they want. 

Integration

Part of what makes gridX’s solution so holistic is that XENON is compatible with many different energy devices and manufacturers. This is made possible by the integration team, who manage the software that monitors and controls the energy flows in and out of each gridBox. Think of this as a chef that tests the compatibility of new food pairings to ensure they always cater to customers’ palates.

OPTIFRA

The optimization framework, or “OPTIFRA” for short, is responsible for cost-optimal energy management and steering the gridBox in regard to monetary objectives. Its optimization models rely heavily on advanced forecasts for the weather, tariffs, household, etc. With the only codebase at gridX written fully in Python, OPTIFRA enables advanced features such as “time-of-use optimization” for the rule-based EMS. It enables appliances to follow optimal behavior, for example, by reducing the virtual capacity of a battery. These OPTIFRA inputs are then used by rule-based EMS to make fast decisions, such as ensuring defined charging values are not exceeded.

Rule-based energy management system

The gridBoxes themselves use algorithmic logic that was developed by the rule-based energy management system (EMS) team. This algorithmic logic enables holistic optimization within set requirements. Rule-based energy management takes decisions in less than one second based on real-time data from appliances and meter measurements. This quick decision making is what allows the EMS to optimize self-consumption or protect the fuse.

These decisions can be influenced by the user as they can set their own preferences. The code has been designed to both minimize costs and use energy in the most efficient manner.

Security and reliability

Part of what makes XENON so reliable is that all data is also stored and processed in the cloud. Should anything happen to the hardware – power outage, physical damage, etc. – the user’s data stays safe and secure, and their processes can continue to run. “Each gridBox is encrypted and secure,” assures Rômulo Berri, Edge Connector Team Lead. It is the edge connector department that is tasked with the communication between gridBoxes and the cloud. This is the bridge that connects the gridBox to the data lake and thus provides all of the information to keep everything going. “There is an authentication process that follows the industry's high security standards,” he says. “This makes breaking into a gridBox near impossible.”

Updates are not rolled out en masse. “We roll out only a fraction of an update at a time,” says Solutions Backend Team Lead Wolfgang Werner. “Then we fine-tune it, roll it out again, fine-tune it, roll it out – there is internal testing, running the data, looking at metrics. It’s not a linear process. It’s like circles within circles within circles.” The process, he adds, involves several iterations in order to produce good software. “We meander to the goal because we want to make sure our software is robust, secure, easily maintained and that we keep up our velocity. We want to operate on an ever growing scale.”

And just because a feature is released, doesn’t mean the developers place it on a back burner and forget about it. They continue to improve the code and functions, testing continually where improvements can be made. “We eventually phase it out if it’s too costly for customers or if there’s no business value,” Wolfgang adds.

What we love: People and challenges

When asked what they like most about working at gridX, the majority of developers gave the same response: the people and the challenges. “There are always complex use cases,” says Baptiste Feron, Head of Energy Management. “It can be either new regulations or new trends – like time-of-use tariffs or dynamic tariffs – and you have to find the right balance between being fast and being optimal.”

“You can code something here and see it work immediately,” says Patrick Grützner, Solutions Frontend Team Lead. “It’s like building a wall brick by brick. It’s very motivating.”

“Everyone here is solution- and goal-oriented,” says Wolfgang. “I haven’t seen many other companies that are so goal-oriented and rational.” He continues to say that developers have the chance to be hands-on in a lot of technical areas at gridX. “We’re building hardware that is remotely managed and communicates with the cloud from wherever it’s mounted. We have the data lake and web application development – we do so many big things with a company of this size, that it’s truly amazing. There are so many topics to dig into and developers are a huge chunk of the value chain, which, at larger companies, usually creates more conflict. Here, we do it all and there is little friction.”

Why cook at home when you can treat yo’self?

Energy management is a complex process that takes great expertise and skill to execute in a way that is both cost effective and efficient. It would take years to recreate the processes carried out by the gridBox and XENON. “We deal with 1.5 to 2.5 million data points per gridBox per day,” says Wolfgang (gridX recently hit a milestone of 10,000 active gridBoxes). “The scope of what we do is very broad. There are protocols that are used for communication with the energy resources. Companies would have to implement these and stay on top of the updates. It’s not realistic to do in-house, which is why we do it for them.”

“It’s an out-of-the box application,” says Patrick, adding that companies can start using gridX’s software straightaway. “We take care of the complexity.”

When you visit a restaurant, you trust the establishment to serve fine ingredients in a delicious fashion. This is what companies should also expect when partnering with gridX: top ingredients, top service and top chefs, that all result in a high caliber fine-dining experience. When companies dine with us, they never want to cook at home again!