This article was originally posted by PIONIX, and is reused with permission.
Corporate bankruptcies are a nightmare. Let’s not talk about personal fates at this point but about the questions that are inevitably asked when it comes to the continued operation of the purchased product.
In our case, as we get this question a lot: Is it possible to run EVerest on this charger from that manufacturer? We are getting this question more since Powerdale’s bankruptcy and we probably will get way more questions after what happened to Tritium.
Impact of losing software updates
When a company goes bankrupt, in most cases the company as a whole or in parts is sold. The company that acquires the IP of the charging station software could continue to use it to keep providing services to the previous customers of the charger manufacturer.
As an owner of these chargers, you can count yourself lucky if the insolvent manufacturer will not disappear but is acquired. Afterwards, you will be at the mercy of the acquirer on the kind of support you will get, and it might even cost you more to keep getting support. This is understandable from the acquirer’s point of view. They need to invest time and money to keep giving support.
Not getting new features might result in not receiving updates to the latest versions of protocols: Take for example ISO 15118-20. Now it is ok to have chargers without ISO 15118-20 support, soon this could be essential to run a competitive charger network.
Even without considering updates in protocols, as more and more new EVs are released, bugs in the software might be found that cause newer EVs not to be able to charge. Bug fixes are essential to constantly improving interoperability.
The table below shows the impact of different levels of software updates that could be provided, if at all by a company that takes over the IP for these chargers.
| Software updates | Result | Impact |
|---|---|---|
| Full updates | Chargers will keep working for years to come. | None |
| Bug fixes and security patches | Chargers will keep working, but in future functionality might be limited as newer versions of protocols will not be implemented. | Low |
| Security patches only | Chargers will keep working, but might start getting more problems with charging newer vehicles etc. Workarounds in CPMS might be needed. | High |
| None | See above, with added risk of chargers getting hacked, which could be a step stone for hackers to get into the CPMS and further. | Severe |
Impact of not having an open management protocol
Some charger manufacturers have their own protocol to manage chargers, instead of OCPP. If these chargers are sold to CPOs or site owners, their functionality will always depend on the charger manufacturer. These chargers typically only work via the cloud services of the manufacturer. If the manufacturer goes bankrupt and the cloud service stops working: the charger will not work anymore from day one.
Tip: Don’t buy chargers that have not implemented OCPP in the hardware.
Impact losing maintenance cloud
More and more charger manufacturers are implementing a maintenance cloud, a second connection to their chargers. This enables the manufacturers to get insights into the performance of their hardware. By doing this, they can provide better guarantees to their customers, e.g. for uptimes.
The maintenance cloud is a good idea. But it needs to be implemented correctly. If the chargers do not work without the maintenance cloud, they might not work when the manufacturer goes bankrupt.
Therefore, our strong advice: Check if chargers will work without the maintenance cloud.
Impact of not having spare parts and technical support
As a CPO/site owner, you hope to buy and operate hardware for a long period. You make plans to keep optimising uptime. You plan preventive maintenance. For this, you have to rely on spare parts from the manufacturer. Having hardware in your chargers needs to be reviewed: How much stock will at all times be kept available for you, how long ahead will you get end-of-life announcements, etc. Will you have access to spare parts when the manufacturer goes bankrupt?
To ensure your operation is impacted as little as possible by the bankruptcy of your supplier you have to have the right-to-repair in all our contracts. And make sure this gives you, at least in case of bankruptcy, access to the entire source code, so you have a chance to make it compatible with alternative spare parts if needed.
You need to make sure your engineers get enough technical training so they can keep debugging issues even when the manufacturer’s technical support is no longer available.
Reduce the risk of going bankrupt: Go Open Source
Using open source instead of building custom software can greatly reduce the development, time-to-market, and maintenance costs of the firmware.
Companies could go for a commercial stack, but this does not give the company control over their own firmware, they will need to keep using the 3rd party software and rely on the roadmap of the supplier which could slow down the introduction of new features and bug fixes, etc. This also adds the risk of the software stack supplier going bankrupt. Open source does not have this risk. An open source project with a striving community will survive even if one or multiple of the contributors go bankrupt.
By the way: Are you a manufacturer that needs to implement any new protocol like OCPP 2.0.1? Migrate to open source now! EVerest and e.g. libOCPP can be used to add OCPP support to any software stack.
Open Source can more easily be maintained after bankruptcy
If a manufacturer that has used open source goes bankrupt, it will be a lot easier to maintain the firmware compared to maintaining custom-made firmware. There are many experienced developers from all around the world available who could be hired to scale up the team.
EVerest is a full software stack for EV charging stations. It contains all the needed protocols and state machines to build a charger. EVerest contains drivers for common charger hardware. Typically, EVerest makes up more than 80% of the software needed to make a charger tick.
The board support package and drivers to let EVerest work on the real hardware might be custom, depending on the chosen hardware. Most custom software will be in the user interface, especially when the charger has a customer graphical interface. If it is a wall box charger without a display, EVerest could be more than 90%.
Think of the following scenario: Manufacturer B buys charger Manufacturer A.
Both have been using EVerest. In this case, B will have a way easier time to harmonise software and take care of the legacy products from A.
Manufacturer B could create a new firmware package for the chargers of company A. Combining the hardware support, via the board support package of A with the unique features and UI of their own chargers.
For example, this could look like this:
Advice: If you are a CPO and want a bit more peace of mind: Buy chargers built on top of open-source software LFE EVerest. Make sure you get access to all the resources needed to build the software. If the manufacturer goes bust you can find other companies that can maintain the chargers for you.
Can you run EVerest on your stranded assets?
You are a CPO and are left with assets that are no longer being updated, and no longer maintained. Maybe the new owner will not (or cannot) maintain the chargers, or even worse: nobody bought the leftovers of the manufacturer. What can you do? Can you install EVerest on these chargers?
Short answer: that depends and is a lot easier when the original manufacturer is willing to lend a helping hand. Are they willing to give the encryption keys to the kingdom and provide the map to the kingdom? More on this in a later blog post.
Advice: Make sure in your contracts that you get access (at least in such a disastrous situation) to keys and the firmware, so you can reuse both for a potential EVerest portation. But be aware, in case of insolvency, all licensing promises might be void, and even if you have it on paper, you might not get access to the data, or the licence is waived.
About the author Robert de Leeuw, Technical EVangelist at Pionix [LinkedIn]
Robert is an experienced software developer/architect. He is an EV charging veteran with 10+ years of experience. His focus has been on the protocols used in the industry. For years he has been leading the development of OCPP (de-facto standard for managing EV charging stations) and OCPI (de-facto standard for exchanging roaming information).
