What is a battery management system?

The introduction certainly anticipates it to some extent: A battery management system must, hence the name, manage the battery. However, this is more complex than it may sound at first; after all, a great many different states have to be read out. We focus here only to a limited extent on the technical component, on the numerous aspects to be considered in terms of technical prerequisites, sensors, bus systems for reading out the data and much more – taking this into account is the task of the Requirements engineeringThe latter has a separate role in the development, which we will take up in the course of this article.

A battery management system monitors many standard functions, such as the temperature of the battery, the charge level or the number of charge cycles and their required time. However, it must also be able to perform or at least delegate certain functions: What happens if the battery exceeds a critical temperature? Is a signal triggered? From which sensor, and to which control unit does the sensor transmit the data, and what does the control unit do with it? Where does it send its emergency signal, and what happens then? How can this be tested, and does this need to be taken into account during development? (Spoiler: Good development already takes test scenarios into account in the top left-hand corner of the V-Modell). Preventing overcharging or undercharging of the battery is also one of the tasks of a BMS. An uncontrolled overcharge could in the worst case lead to an explosion of the battery, a constant deep discharge could destroy the battery as well, since batteries should in principle not reach a charge level that falls below the last percent of the battery capacity – however, this is only one example from the large smorgasbord of tasks of a BMS. It needs communication interfaces, has to calculate parameters and much more. The exact requirements to be met by a BMS are usually specified by the OEM, especially if the OEM does not have its own complete system consisting of battery and BMS, but only an existing battery structure in which as many batteries as possible have been installed in the underbody of the vehicle. Developing a BMS for this is a typical task for Tier 1 suppliers such as Cognizant Mobility. Of course, there are other suppliers of battery management systems such as Victron, Infineon, Marquardt and some more. However, Cognizant Mobility provided us with a number of experts, with whom we were able to explore what exactly makes a good battery management system and which development steps are particularly important for this in order to deliver strong and innovative work.

What makes a good battery management system?

The question of what ultimately defines a good BMS may vary from manufacturer to manufacturer and from developer to developer. From Cognizant Mobility’s point of view, however, modularity and scalability are decisive factors for working on modern BMSs in a customer-oriented and, above all, efficient manner. Most Tier 1 OEMs have fixed platform strategies – an example would be large companies like Bosch or Infineon. This also has its justification. But who is the customer? If the customer is a well-known manufacturer such as Audi, BMW or Mercedes, they also have their own platform strategies that are not adapted for suppliers. Instead, a plan already exists for how batteries will be integrated into vehicles. The task of the subcontractor is a soft set-up, within the framework of which the given – and usually unchangeable – specifications of the customer are processed.

In order to be able to implement this in a time and cost-saving manner for the customer, a high degree of modularity is required, which allows fast and effective adaptation to the customer’s requirements. This applies to software – one of Cognizant Mobility’s core competencies – as well as hardware and the ECU level. If what the customer wants can be implemented quickly and easily, this enables initial value creation.

However, a distinction must be made between the actual high-voltage battery as a product and the pure battery management system – even if we sometimes mention hardware and software in the same breath. Manufacturers often outsource the production of the battery to their own subcontractor, while other suppliers with the appropriate skills are contracted for the BMS. This is not always the case everywhere, but the above example is a perfect example.

Of course, there are other models, as indicated at the beginning: some field manufacturers already have a package model, in which the vehicle is equipped with the desired number of batteries, but for which there is no management system. This is where software and knowledge suppliers come in to develop the systems. Accordingly, they must not only be familiar with pure software development, but ideally also have knowledge of cell physics and charging technology. Finally, it should be known how a BMS must react when a battery is forcibly charged at over 200 kW. If their temperature subsequently rises to 300 degrees, the consequences can be devastating. Knowing how to program an algorithm for charging and discharging is also essential. After all, you don’t discharge a battery to zero percent – we’ve already touched on this, too – or it will simply break down.

All these aspects, together with modularity and flexible scalability, are core elements of a good battery management system, coupled of course with extensive knowledge of requirements management and knowledge at the programming level. Let’s take a closer look at that, too.

Important requirements for the development of battery management systems: Functional safety

Honestly? We could make it very simple at this point and state that good knowledge of embedded systems development is important and close the chapter. Because it would be true – just not the detailed view we like to offer at Mobility Rockstars. So let’s dig a little deeper and look at the four pillars on which – beyond testing – the development of a strong BMS rests.

Functional safety (often casually abbreviated to “FuSi” within the industry) is an elementary building block that must be taken into account right from the start of the V-Modell. After all, safety is essential. We have already written an article about the general significance of functional safety and its importance together with the relevant specialist department; if you are interested, you can find it under this link.

FuSi must therefore be taken into account right from the start of requirements engineering, for which it is important not to reduce the vehicle to just the battery, but to perceive it in its entirety. For example, it is necessary to weigh up which control systems should be implemented redundantly or otherwise. If sensible concepts are drawn up at an early stage, this can considerably minimize the effort and, as a direct consequence, the costs. Functional safety and requirements management in particular are therefore immensely important competencies in the development of battery management systems. It almost goes without saying that development is carried out in accordance with Automotive Spice, a state-of-the-art standard in embedded development for assessing process maturity, according to which suppliers are also usually audited – meaning that OEMs hold audits at suppliers’ premises, during which all questions relating to development and implementation must be able to be answered. Often, it is not a question of “how”, but “what”: The Automotive Spice (ASPICE) standard states what has to be done, and the supplier has to show how it is done in the ASPICE audit.

Battery management systems and their requirements – Requirements engineering

For any large project, not only in the development of battery management systems, detailed requirements management is a key competence. Here, a distinction must still be made between requirements engineering and requirements management – two different tasks that are included in the German-language term “Anforderungsmanagement” (requirements management) and are not further differentiated there.

Requirements management presents itself primarily as an administrative task that deals with managing customer requirements, making them available to other roles in the project, and dealing with baseline creation. Requirements engineering, both in principle and in this specific project case, is about creating all the requirements relevant to the project – in this case for battery management systems: Which modules, which signals, which algorithms are to be used for certain functions. Good requirements management means working with particularly fine granularity and dividing up requirements: Only as many requirements as are absolutely necessary, but these are so granular that there is no room for interpretation for the next steps and stakeholders. Even later testing is ideally taken into account at the beginning. So an example would be the battery, and specifically the temperature to be measured by the BMS. Sounds like a simple requirement, but there is more to it – how is the temperature measured? From which sensors? Is there enough space on the board, are all components available to perform the functions? Which components exactly? What functions specifically so that all signals can be interpreted by the software, and how and in what form should the interpretation be output? Where to? In any case, or is a signal that reflects a standard function evaluated differently than an emergency signal?

To implement this effectively and competently in requirements management, experience and communication are absolutely necessary skills. Conversations on a recurring basis with product and function owners, with testers, with Scrum teams – they should all be involved in appropriate reviews in order to offer the customer an optimal project and ultimately product.

The software development of battery management systems

We will deal with this point for the sake of completeness. Of course, this is an essentially important aspect in terms of know-how and competence, but it rather describes the general ability to develop embedded systems. Sure, a BMS has special requirements: There is a very high proportion of complex device drivers that can dock directly to hardware interfaces, and there are many special connections. Direct measurement pins, for example, must be designed to specific battery hardware requirements.

After the basic software developers (keyword Classic Autosar Standard, more on this in this article) have developed, to put it simply, the “operating system” on which the application software is based in the further course, the functions can be tackled in the V-model (example of a V-model: https://evav.omnex.com/7-levers/automotive-spice ). Functions like the charge level, maintenance prompts and much more – you know the examples by now. Functions, for example, are written using Matlab Simulink, which is considered one of the most important tools of all in function development. In this framework, functions are modeled graphically, from which code is generated automatically. This is summarized under the term model-driven software development, usually abbreviated as “MDSD”.

Almost needless to say, the strength of a supplier in the area of the development level is primarily expertise, project experience and a clean meshing of requirements management, functional safety and basic and application software development.

Innovation through technology openness: the bottom line

What remains to be said finally in a detailed technical article that covers all relevant points? Perhaps that battery management systems are complex products that call on a variety of skills to be developed correctly in a highly dynamic project environment. While there are certainly numerous companies in this field that offer corresponding development, partly autonomously, partly as part of other suppliers (“body leasing”), there are nevertheless major differences in efficiency, which is reflected for customers not only in product satisfaction, but also in saved effort and cost input. Requirements management in particular is an immensely important point that is not given adequate attention in all circumstances, as is the early integration of functional safety and a granular division of all tasks that takes into account contingencies, changing requirements and tasks right through to testing right from the start.

In order to meet these requirements, it is essential to be open to all technological approaches. It’s important to break away from the mindset of some suppliers, who put a lot of effort into steering customers into their own system and creating a lock-in effect that is quite intentional, as is well known from ill-advised cloud migrations. A battery management system should therefore adapt to the customer during development, and not the customer to the supplier’s systems – against the background of ISO21434, an extremely important point that has even gained relevance for approval.

Of course, this also means that developers should quickly get used to new technologies – especially in the current material shortage, hardware stacks can change, cell technologies can follow. With a flexible modular system, suppliers such as Cognizant Mobility can react quickly. The keyword is parameterization: a new solution does not always have to be invented for every customer, but customization and flexibility are elementary. The code, in which the ultimate truth lies, does not have to be rewritten, but must remain extensible in order to also live the propagated technology openness. And this is true in both the proverbial and figurative sense – the wheel turns, and we turn with it.

So feel free to contact us if you have set up as a client in the field of BMS and are now looking for real, flexible and efficient development potential – we will be happy to have a straightforward chat and provide an initial, non-binding assessment.

But the journey doesn’t end here for all other readers either, because we have more great links for you, namely here, here or here, or you can scroll a bit further and read another exciting tech article on the mobility of tomorrow.

Thank you for your attention.