Porsche Battery System Solutions For Motor Racing And Series Production
Porsche Engineering has been developing high-performance battery system solutions for motor racing and series production for more than 20 years. The battery management system (BMS) has the task of assessing the condition of the battery, defining the current operating limits, and ensuring operation within those limits.
In battery electric vehicles (BEVs), the battery management system (BMS) plays a central role. It consists of the battery management controller (BMC) and cell module controllers (CMCs). The CMCs are integrated directly into the modules of the high-voltage battery and supply the BMC with measured values such as cell voltage and temperature. They are also responsible for cell balancing: High-voltage batteries consist of a large number of individual low-voltage battery cells. However, tolerances result in the cells having their own individual physical properties, which can cause problems when using the system. To prevent this, the CMCs balance the state of charge of the cells—either passively by means of resistors connected in parallel, or actively by transferring charge from weaker to stronger cells. The BMC is the central element of the BMS and uses its own current sensors in addition to the measured values from the CMCs. One of its functions is to ensure that the battery operates safely. After all, battery systems contain large amounts of energy and are capable of releasing this energy very quickly. Any uncontrolled or unintended release must be prevented at all costs. In addition, the BMC must find an optimal compromise between battery life and performance, because operation outside the specified parameters can cause damage to the system. Typical causes include excessively high currents; excessively high or low temperatures, which damage the electrolyte or lead to higher current sensitivity; and overvoltage or undervoltage, which can damage the electrolyte or the active materials.
To prevent this, the BMS is used to change current limits, restrict operating modes, or adjust the cooling according to the battery condition. “Based on the measured values from numerous temperature, current, and voltage sensors, the BMS derives three crucial battery parameters: The state of charge (SoC) and the capacity, which determine the remaining range, and the internal resistance, which limits performance,” explains Lukas Mäurer, Project Leader High-Voltage Battery Functions at Porsche Engineering. “It is also responsible for safety functions such as overcurrent shutdown and crash detection, as well as for communication with the other controllers in the vehicle.”
Image Credit: Porsche Media
Over 20 years of experience
Porsche Engineering has already developed diverse BMSs on behalf of customers and can take on all tasks that arise in connection with the V-model— from requirements surveys to vehicle testing. “As a company, we have been active in this field for more than 20 years, and I have personally been involved with battery management systems for six years,” says Mäurer. Despite all the experience gained over the course of numerous projects, developing a BMS remains a challenging task even for experienced developers: The software is exceptionally complex, which poses several challenges for both engineering and project management. Porsche Engineering therefore attaches great importance to a stringent and transparent process. It begins with requirements management, something that the experts pay particular attention to. “And it’s not just about laying the technical foundations—this is also where the further course of the project is decided,” emphasizes Achim Olpp, Project Leader at Porsche Engineering.
Checking the specifications
Potential problems need to be identified and eliminated by checking a new set of specifications as soon as it has been drafted. Olpp refers to the ‘rule of ten’. With each stage of software development, the costs of rectifying errors increase by a factor of 10. The effort it involves increases with each process step, since work that has already been done must be checked and redone from the point at which the error arose. Subsequent errors also must be ‘caught’ again. This almost automatically jeopardizes what are often tight schedules, especially in the case of software that exists in different versions customized for multiple customers.
In order to prevent this kind of additional work, having the author of the software requirements specifications, working under the direction of the requirements engineer, call together all project participants for a ‘review’ of the specifications supplied by the customer has proved a good approach. “Everyone then gathers around the table, including the software architects and developers as well as the testers and the customer,” Olpp explains. “It’s a much better way to understand the requirements that arise from the specifications and to define the potential solutions for the specifications more systematically. When there are multiple customers, the review provides the opportunity to harmonize different interests.” Although this increases the workload somewhat at the beginning, it brings significant time savings in the long run. Planning of the work scopes builds up on this solid foundation. “We hold a capacity workshop two weeks before each software release cycle to match the customer’s needs with the available resources,” Olpp reports. “This way, we know exactly what can be accomplished in the time available. And the customer can prioritize work packages where applicable.”
Clear picture of capacities Precise capacity management can also help prevent the dreaded ‘scope creep’. This is when the requirements for a product change continuously and spontaneously during its development, which often results in delays. “If you clearly identify your capacities, you can also better understand and coordinate the effects of requirement dynamics like this,” says Olpp. When using software carry-over parts for multiple models and brands in particular, a lot of care needs to be taken during this step. Incorrectly integrated scopes can simultaneously jeopardize several vehicle series due to the modular schedule. Software architects are also confronted by several challenges during BMS development. Among other things, they must make allowance for the fact that cell chemistry and battery design are constantly evolving.
“A modified battery cooling system has an impact on thermal management, among other things,” explains Mäurer. “The temperature of the individual battery cells cannot be completely determined using sensors. For example, if 60 sensors are used to determine the temperature for 200 cells, the software architecture must support different sensor installation positions and different cooling concepts such as multi-sided cooling plates.” This is why BMS functions must be developed so that they are easy to adapt to such changes, he says. When it comes to software architecture, the use of software carry-over parts also leads to additional challenges. They necessitate modular structures that meet the requirements of a specific vehicle, but do not result in disadvantages in other models.
Adapting to resources
The software development step follows the definition of the software architecture and aims to make solutions from predevelopment suitable for series production. A typical task, for example, is to adapt algorithms to the limited resources in terms of processing power and memory capacity of the control units in vehicles— without compromising the quality of the results. “In predevelopment, usually only a single cell is monitored with sensors; in the vehicle, there are several dozen,” says Mäurer. “But you can’t simply run the algorithm used for a prototype dozens of times in succession in series production, because that would make the required processing power too high.” BEVs also make use of many innovative functions, for example for fast charging. They often operate at the limit of what is currently technically feasible. During the transition from prototype to production status, these functions must be made robust enough to run without problems in all conditions. “In the case of fast charging, this could be achieved by implementing control algorithms that limit the charging current in the event of imminent overheating or voltage overshoot,” says Mäurer.
If the customer is also pursuing a software carry-over part strategy, developers must also ensure a high degree of adaptability of their functions, for example to adapt to different cell chemistries or hardware concepts. “Software development for series production is a transfer service for which Porsche Engineering, among others, is particularly well suited,” as Mäurer sums up. “We have gained a lot of experience in BMS development, from motor racing to large-scale production. Our solutions are present in all brands within the Volkswagen Group, but also in the 919 Hybrid, Porsche’s Le Mans winner.” In addition, Porsche Engineering also has its own cell and battery expertise, as well as experience with new technologies such as 800-volt networks in vehicles. The experts evaluate how well the software that was developed meets the requirements for the first time during the module test. In this test, the smallest units of the programs—for example, for calculating residual capacity—are fed with defined input values. If they deliver the expected results, the algorithm is, basically, working correctly. Otherwise, the software developers have to edit the program code. “As the first verification step, the module test offers a lot of potential to save time and money,” says Mäurer. “After all, anything found here would require significantly more effort to fix later in the project.”
Dual control principle during testing
At Porsche Engineering, the dual control principle applies for module testing: Programming and testing are carried out by different employees. At the very end, a representative from quality assurance joins in who, in addition to the result, also validates the development processes completed beforehand. This ensures that the next steps in the V-model—integration, software, and vehicle testing—can build on a good foundation. After all, Project Manager Olpp’s advice applies to the entire development process: “Without solid processes, a BMS project is like a skyscraper without a stable foundation.”
… notes from SP