As gridX Product Manager of Asset Integration Daniel Gomes Makohin says: “In the field, energy assets are the hands and eyes of XENON – and integration is the circulatory system making them work.”
As the energy space becomes more and more decentralized, gridX is continually extending the compatibility of its platform. They do this by integrating additional distributed energy resources (DERs) to help their partners scale, focusing on the most future-proof original equipment manufacturers (OEMs), and the most relevant models within their portfolio. For this to happen, different assets and OEMs must be ‘integrated’ with their XENON platform.
Synergies for multiple partners
There are two ways to get the integration ball rolling. The first is when partners approach them with a request for a particular OEM with selected models.
The second is when they find an OEM or asset that they determine to have great potential in the market or will bring synergies for multiple partners. Once one of these options is set in motion, the integration process gets under way.
Integrating towards singularity
Step 1: Evaluation
Step 1.1: Is it a priority?
When first faced with a new OEM or asset, their integration team asks themselves a series of questions to determine whether the integration makes sense on a business level – both financial and operational – for themselves and their customers.
Typical questions are:
- What is the potential impact of this new asset in terms of revenue for both ourselves and our partners?
- What timeline do our partners expect for the rollout?
- What are the technical expectations?
- What’s the reputation of the product?
- Does the asset align to our energy management system’s (EMS’s) overall strategy?
Step 1.2: Can we integrate it?
- After our team has assessed whether we want to integrate an asset, the next step is: can we?
Information and technical documentation
Then, depending on the device type, they require additional data points to be able to manage it
The answer to this question comes down to data. They start with a general evaluation of all assets from the OEM to get an overview if all of the information and technical documentation they require is available. If it is, their team members then determine the technical feasibility of the integration based on these data points.
It’s important to note that these points include general measurements, as well as measurements that differ according to device type. For example, they require the following of all devices:
- A unique identifier
- Power measurements
- Voltage
- Current
- Apparent power
Then, depending on the device type, they require additional data points to be able to manage it, rather than simply monitoring it. For this example, they’ll focus only on EV charging stations (EVCS) and battery inverters.
EVCS
- Plug state
- Charging station state, e.g. ready, authorized, charging error
- Max. charge/discharge power
Battery
- State of charge
- Minimum charge power
- Maximum charge power
- Capacity
- State of health
Once these assessments are made, there is a further evaluation into the outlook of the OEM’s cooperation, validating their documentation and verifying if there is a plan for testing the integration. If all of these boxes are checked, they align with their partners and the OEM to greenlight the project, have the assets sent to their Test Lab and begin the integration process.
Insufficient data accuracy
Step 2: The actual integration
They start the integration with initial tests in their Test Lab to confirm whether or not the device provides the necessary interfaces and information. If it does, the integration process continues.
Step 2.1: Benchmarking
For quality assurance, all assets go through a benchmark process. Integrated assets are measured in a predefined series of tests to rate response times, delays and accuracy of the interface. Assets that do not meet their quality standards (e.g. delayed response times, insufficient data accuracy, etc.) fail this phase and the integration process is stopped.
To start the benchmarking process, their team develops software that allows the gridBox to “speak” to the asset (in this case, think of the gridBox as a polyglot that can speak multiple languages in order to communicate with different assets).
Range of discovery protocols
Step 2.2: Scanner implementation
The scanner is the software that detects and identifies the device in a network and forwards its ID and device type to their backend. For the scanner, they rely on a range of discovery protocols like ARP and SEMP. The scanner is considered done once they are able to detect and identify the appliance in a network.
Once the scanner has been implemented, their team must create the code for the “driver”: a piece of software that connects the gridBox to the asset. This is needed to monitor and, if possible, control the asset.
Abstract control commands
Step 2.3: Monitoring implementation
This step is relevant for assets they want to control in addition to monitoring
This step enables them to read values from an appliance and normalize them so that they can be reported to the backend in a standardized format. Because units and data types may vary by manufacturer and model, the data often needs to be converted to comply with their format (again, much in the same way language localization takes place when translating a text from something like English to Spanish, Dutch to Portuguese, etc.).
Step 2.4: Controller implementation
This step is relevant for assets they want to control in addition to monitoring. The aim here is to map abstract control commands to specific asset commands. In other words, protocols and commands vary from device to device. To provide an abstraction layer that removes this variation, they build an adapter. This would ensure, for example, that the command to discharge a battery is the same regardless of the actual battery and the protocol it employs.
EV charging station
The set of commands that they map here depends on the appliance type because although a battery requires both a discharge and a charge command, an EV charging station only requires a charge command (unless it supports bi-directional charging).
Once all of the commands have been mapped and implemented, and the scanner and driver allow the asset and gridBox to speak the same language, they move on to final end-to-end testing and documenting the integration.
Step 3: Testing and documentation
The last step of the integration is testing. Their development team is highly skilled, and part of what makes them so skilled is their process of testing assets, products and features in order to debug and ensure the highest functionality. During the integration testing stage, they also document the setup process in order to keep quality consistent.
Ensuring optimal performance
Step 3.1: Practice (testing) makes perfect
They have several tests that cover different use cases and touch on all of the features of their drivers
They test each integration from end-to-end to ensure optimal performance between the asset and the different XENON modules (e.g., the Tariff Timer, Energy Optimizer, Peak Shaver, etc.). Depending on the asset they’re integrating and the needs of their partner, they run tests in their lab, in the field or both.
During the testing stage, their backend team takes control over the asset and attempts to manage it remotely in order to verify that everything is working as it should. They have several tests that cover different use cases and touch on all of the features of their drivers. Some tests can be executed independently, while others require actions, such as plugging in an EV for testing an EVCS. All tests are done in their lab.
Asset’s individual functionalities
The general criteria for testing is scanning to find the asset from the frontend and monitoring it. If necessary, their developers will also test whether it can be controlled, too. Tests differ according to asset type, such as:
- Meters
- Inverters
- EVCS
- Heat pumps
- IO devices
Tests for each focus on the asset’s individual functionalities. For example, batteries that are controllable are tested for inverters, and EVCS is tested if they can do a PV surplus charge. Specific tests can also be requested, such as the capabilities for advanced uses like in time-of-use optimization.
Extended field testing
Step 3.2: Rollout
After successful testing for monitoring and controllability with the EMS, the implementation follows the software rollout of gridX via weekly and stable releases. It is first pushed to the alpha stage. As it matures, it moves to beta and then stable.
If requested or deemed sensible by/with the customer, they can also add extended field testing. For 4 to 6 weeks, they do end-to-end testing together with other devices at a customer location. If desired, this will be done after the software release (i.e., alpha stage).
Documenting the entire process
Step 3.3: Documentation
As computer scientist Damian Conway once said, “Documentation is a love letter that you write to your future self.” And, in this spirit, they finish the integration by documenting the entire process.
Installers will need to know how the appliance must be installed and configured to function with XENON
Documentation typically covers the commissioning of the appliance. In this state, the asset always starts from the gridBox’s default setting. Each step and change made thereafter are documented thoroughly. Screenshots are required. As the developer testing the asset moves through the steps, they add all changes and findings to the commissioning documents.
This serves two purposes: first, if changes are required in the future, extensive documentation makes it easier for any engineer to comprehend and amend the previous work. Second, installers will need to know how the appliance must be installed and configured to function with XENON. Once all steps are successfully completed, it is made available to their customers.
Decentralized clean assets
In addition to saying that integration is what makes XENON’s hands and eyes work, Gomes Makohin also adds: “Providing high quality integrations is fundamental to get the correct data and, later, to properly steer assets toward the optimal operation point, especially from an economical and environmental perspective. Put simply: if we can't reach the assets, nothing can be done at all.”
Integration doesn’t just open the door for new assets and OEMs; it is the very doorknob that has to be turned
Integration doesn’t just open the door for new assets and OEMs; it is the very doorknob that has to be turned. Without it – or without it done correctly – decentralized clean assets that are the foundation to the energy transition will work against each other, rather than in harmony, rendering the energy transition a failure. Part of what sets XENON apart from other home energy management systems is the close cooperation with OEMs. They don’t just rely on certain APIs from different OEMs; they work together with them.
Revolutionizing the energy landscape
The efforts of their integration team stand as a testament of their commitment to driving innovation and progress within the energy ecosystem. By meticulously integrating the most crucial and relevant OEMs and models for the partners, they not only accelerate their growth but also propel the entire industry forward.
They empower their partners to scale faster than the market, ushering in a new era of integration (pardon the pun), efficiency and sustainability. As they continue to forge ahead, their mission remains clear: to revolutionize the energy landscape and shape a future defined by collaboration, ingenuity and boundless potential.
