Modular Battery Management System interface to integrated Vehicle Control Unit

Creating a BMS playground using Arduino

Joel André

Karlstad University In collaboration with NEVS

Bachelor Thesis in Electrical Engineering, 22.5 hp

2020-06-05

Modular Battery Management System

interface to integrated Vehicle Control Unit

Creating a BMS playground using Arduino

Karlstad University

Faculty of Health, Science and Technology

Department of Engineering and Physics

Bachelor Thesis in Electrical Engineering, 22.5 hp

National Electric Vehicle Sweden AB

Examiner: Magnus Mossberg

Internal supervisor: Jorge Solis, Karlstad University

External supervisor: Przemysław Radecki, NEVS

Trollhättan, Sweden

© Joel André, 2020

i

Preface

This report marks the end of a three-year long journey at Karlstad University and is the final part

necessary for my Bachelor of Science degree in Electrical Engineering. The subject of this thesis was

found through contact with Anders Dahlen, José Guerrero and Przemysław Radecki at NEVS, whom I

all would like to thank for having faith in me during this project. To have worked with solutions for a

sustainable future have for me been rewarding, and the help from all of you have been greatly

appreciated.

I want to give a special thanks to my supervisor at NEVS, Przemysław Radecki for answering questions,

giving me ideas and helping with overall the structure of the report. Without you, the task would

probably not have been possible. My gratitude also extends over the whole Drivemode team at NEVS,

who have all been curious and helpful towards the project during my time there.

At Karlstad University, I want to thank Magnus Mossberg and my internal supervisor Jorge Solis for

helping me with all academic questions I have had. Lastly, I want to thank Copperhill Technologies and

Wilfried Voss for letting me use images from their published book about Controller Area Network.

iii

Abstract

Development today has moved more towards battery technology, partly due to the increased demand

of electric vehicles (EVs). The quest for a sustainable society is at an all-time high, with electrification

of almost all devices only being the beginning. Due to the use of the fragile Lithium-Ion battery, a

system that controls and monitors the battery must be implemented to ensure that it operates

normally. A system like this is often referred to as a Battery Management System (BMS), in this case

for Lithium-Ion batteries.

The objective in this thesis is to construct a modular BMS playground for NEVS in Trollhättan to

continue development on. The interface for the system will consist of Controller Area Network (CAN),

a fast and robust communication protocol used in almost all personal vehicles today, and Isolated

Serial Peripheral Interface (isoSPI), an isolated adaptation of one of the most common communication

protocols used in sensors and microcontrollers so far.

The BMS will be constructed of four individual subsystems using Arduino, each with a different

purpose. These four subsystems are later merged into one BMS system to offer communication

between CAN and isoSPI, thus supporting a future integration of this BMS to the Vehicle Control Unit

of an EV. Moreover, since the BMS is going to be developed for a vehicle, modes for engaging the

vehicle to drive and stop will be made. In order to provide some safety measures, automatic

disconnection of the battery in case of an error will be added.

The BMS with the previously mentioned features, also capable of doing voltage measurements with a

safe connection/disconnection of the battery was then made. Features such as current and

temperature monitoring were omitted due to time constraints and will in the future instead be done

by NEVS along additional features.

This thesis was conducted by Karlstad University and NEVS in Trollhättan, Sweden.

iv

Contents

Chapter 1: Introduction ..................................................................................................... 1

1.1 Background .............................................................................................................................. 1

1.2 Problem definition ................................................................................................................... 2

1.3 Objective.................................................................................................................................. 3

1.4 Method .................................................................................................................................... 3

1.5 Limitations ............................................................................................................................... 4

1.6 Outline ..................................................................................................................................... 4

Chapter 2: Theory ............................................................................................................. 5

2.1 Battery Management System for Li-Ion Batteries ................................................................... 5

2.2 Communication Protocols ....................................................................................................... 6

2.3 Serial Peripheral Interface ....................................................................................................... 6

2.4 Isolated Serial Peripheral Interface ......................................................................................... 8

2.5 Controller Area Network ......................................................................................................... 9

2.6 The Pre-Charge Method ........................................................................................................ 14

2.7 Mathematical Calculations .................................................................................................... 15

Chapter 3: Execution ....................................................................................................... 18

3.1 Overview of the BMS ............................................................................................................. 18

3.2 Battery Management Unit..................................................................................................... 19

3.3 Cell Management Unit .......................................................................................................... 29

3.4 CAN/isoSPI Translation Board ............................................................................................... 31

3.5 Battery Junction Box .............................................................................................................. 35

3.6 Merge of the Four Subsystems.............................................................................................. 45

Chapter 4: Results ........................................................................................................... 47

4.1 The engage of Drive Mode .................................................................................................... 48

4.2 The disengage of Drive Mode (Stop) ..................................................................................... 49

4.3 The engage of the Extra Function ......................................................................................... 50

4.4 Error Messages ...................................................................................................................... 51

Chapter 5: Conclusions .................................................................................................... 53

5.1 Final Conclusions ................................................................................................................... 53

5.2 Further Work ......................................................................................................................... 54

References ...................................................................................................................... 55

v

Appendix A: Schematics .................................................................................................. 57

A1: The schematic of the Battery Management Unit ....................................................................... 57

A2: The schematic of the Cell Management Unit ............................................................................. 58

A3: The schematic of the CAN/isoSPI Translation Board .................................................................. 59

A4: The schematic of the Battery Junction Box ................................................................................. 60

Appendix B: Source code ................................................................................................. 62

B1: The Drive Mode of the Battery Management Unit ..................................................................... 62

B2: The Error Detection of the Battery Management Unit ............................................................... 65

B3: The CAN Conversion .................................................................................................................... 66

B4: The Measurement Conditions ..................................................................................................... 67

B5: The functions of the Battery Junction Box .................................................................................. 68

B6: The functions for the Cell Management Unit ............................................................................. 70

vi

Definitions

Terms and symbols Description

EV Electric Vehicle

BMS Battery Management System

SOH State of Health

SOC State of Charge

BMU Battery Management Unit

BJB Battery Junction Box

CMU Cell Management Unit

VCU Vehicle Control Unit

Li-Ion Lithium-Ion

CAN Controller Area Network

CAN FD Controller Area Network Flexible Data-Rate

SPI Serial Peripheral Interface

isoSPI Isolated Serial Peripheral Interface

SOF Start of Frame

ID Identification

LSB Least Significant Bit

MSB Most Significant Bit

CRC Cyclic Redundancy Check

HV High Voltage

I/O Input/Output

DC Direct Current

IEC International Electrotechnical Commission

PCB Printed Circuit Board

V Volt

A Ampere

W Watt

F Farad

Ω Ohm

Chapter 1: Introduction

1

Chapter 1: Introduction

1.1 Background

The necessity of systems with integrated battery management systems are stronger than ever

today. With EVs on the rise and a growing number of electronical devices, a system that

controls, monitors and adapts Li-Ion battery packs in all its shapes and sizes is required for a

continued development in today’s technology.

In the case of EVs, a battery management system (BMS) that communicates with both isoSPI

and CAN protocol is key for enabling further development and testing in the electric vehicle

industry. Almost all vehicles today are benefiting from CAN communication, from small

personal vehicles to large industrial machines, with the advantages ranging from its high

transmission speed and lack of complexity, no matter the size of the application. [1]

Most sensors and devices outside car applications lack the support for CAN, which makes the

communication between the sensor and the VCU in the car rather difficult. A solution

consisting of a translator, which enables communication with CAN, would eliminate the

problem and create a useful foundation for further development of BMS systems. Applying

this together with isoSPI, the standard communication protocol for sensors and

microcontrollers with an increased toleration for noisy environments, and a finished product

playground is made. The benefits of isoSPI also extends over its protection and safety regards

as it provides full galvanic isolation, minimizing hazards to personnel. [2]

NEVS engineering department focus on creating new technologies and innovations and will

later integrate a system like this in the “brain” of the car, the VCU, eliminating the need for an

external BMS system and allowing for a more customizable experience.

This project marks the beginning of that journey, with a future integration of this system to

the VCU soon to be done by NEVS.

Chapter 1: Introduction

2

1.2 Problem definition

NEVS is planning to develop their own BMS based on modular blocks. The intention is to make

a setup that fits different battery packs and is easily configurable to adopt for different

applications. The idea of this work is to create four individual systems that can communicate

with each other. Due to the use of different communication protocols in the system, a

translator is required to enable the conversion of protocols and make it possible for those

systems that do not initially speak the same language to communicate with each other.

The subsystems which will be created with their form of communication are presented below

in figure 1:1.

Figure 1:1 The four subsystems of the modular BMS

The tasks that each subsystem will perform are:

Battery Management Unit

o Communicate via CAN 2.0B

o Command three actuators (send a request to connect/disconnect the battery)

o Monitor voltage levels, temperature, current flow and the state of actuators (relays)

o Automatically disconnect the battery in case of a measurement error

o Provide a graphical interface to the user

Cell Management Unit

o Communicate via isoSPI

o Monitor voltage levels of individual battery cells

o Perform cell balancing

Chapter 1: Introduction

3

CAN/isoSPI Translation Board

o Communicate via CAN 2.0B and isoSPI

o Translate CAN signals to isoSPI

o Translate isoSPI signals to CAN

o Control the Cell Management Unit

Battery Junction Box

o Communicate via CAN 2.0B

o Control three actuators (relays)

o Measure voltage levels, temperature, current flow and state of actuators

With these functionalities, three modes are going to be made, controlled by the Battery

Management Unit. A function for connecting the battery to the system (Drive Mode), a

function for disconnecting the battery to the system (Stop) and a function to monitor the data

of the measured sensors (Extra).

1.3 Objective

The main aim with this project is to develop a battery management system based on modular

blocks with the key features described in 1.2 Problem definition. Using market available

Arduino development boards, knowledge in software development and designing hardware in

an embedded system will be expanded. The objectives are achieved when a modular system

that monitors and controls cells within battery packs is finished and delivered for NEVS to

continue work on.

1.4 Method

To achieve this battery management system, each system will be constructed using market

available Arduino development boards. The work will be based on coding in the Arduino

language, using the Arduino IDE software compatible with Arduino boards.

First, schematics for the systems needs to be modeled and a part list for the hardware created

in order to have a clear path for the assembling going forward. The subsystems will then be

created, tested and validated one by one to ensure that each system is working satisfactory

before merging all four systems into one. When the functionalities of the complete system

have been obtained and communication is working properly, the objectives can be considered

as reached.

Before the actual work begins, theoretical knowledge on communication systems, BMS

systems and similar areas must be improved on by reading literature, which will be included

in the final report.

Chapter 1: Introduction

4

1.5 Limitations

Due to the complexity of a real-world battery management system and the irrelevance of

advanced features in this development environment, features such as charge control,

advanced cell protection, State of Health (SOH) and State of Charge (SOC) will in this project

be omitted. Thus, only the features presented in 1.2 Problem definition are to be applied to

the developed system in this project.

1.6 Outline

In the first chapter, an introduction to the project was presented. Following in Chapter 2,

appropriate theoretical information will be given to the reader with details about the main

communication protocols used and the functionality of a BMS. This will provide enough

information to understand the necessity and challenges of a system like this. Chapter 3

describes the implementation of the theoretical background on the project and how each

system was constructed and later merged into one. The results will be presented in Chapter 4,

where the final graphical interface between the user and the system is explained in detail. The

results in Chapter 4 are later analyzed and discussed with comments on how it could be

improved and finished, with a conclusion as a closure. Continuing after Chapter 4, a list of

references and the final Appendix will follow.

Chapter 2: Theory

5

Chapter 2: Theory

2.1 Battery Management System for Li-Ion Batteries

2.1.1 Background

Modern Li-Ion batteries are complex and fragile and thus require monitoring and control. A

battery management system (BMS) provides an answer for those needs as it monitors,

protects and maximizes the performance of such batteries. However, the need for control

extends over several more factors than just performance optimization. Li-Ion battery packs

consists of several battery cells which can provoke hazards if not charged or discharged

correctly. Overcharging of cells can result in heat, or in some extreme cases, fire. It is therefore

of greatest importance to include safety measures when designing a BMS, especially in a

vehicle.

Of the reasons stated above, when charging a Li-Ion battery, the charging must stop when the

battery has reached its maximum voltage for the battery not to become overcharged. In

addition to charge control, cell balancing is also a key feature of the BMS as it allows the Li-Ion

battery pack to stay at a higher state of charge (SOC), without overcharging the most charged

cell [3].

2.1.2 Cell Balancing

Due to factors as temperature, charge/discharge cycles, manufacturing differences and aging

of batteries, some cells in battery stacks discharge faster than others. Therefore, cell balancing

becomes a necessary task in order to maintain a healthy battery with a high SOC. SOC is

determined by the level of charge relative to the total capacity of the battery and is often

measured in [%]. For a BMS, there are two ways of performing cell balancing, passive or active.

The basic idea of the two is to equally distribute the SOC between each cell in the battery so

that each cell holds the same level of charge [3]. See figure 2:1 for a graphical representation

of the desired outcome of cell balancing.

Figure 2:1 A demonstration of cell balancing

Chapter 2: Theory

6

Passive balancing works like a discharge resistor. In short, energy is converted to heat as the

discharge resistor drains the most charged cell during the charge period. This results in an

equal initial charge of cells, but with the cost of a small amount of energy wasted during the

charge period [4]. A similar representation of a discharge resistor is illustrated in figure 2:14.

Active balancing retains the same benefits as passive balancing, without wasting energy. The

price to pay is complexity, as several complex algorithms are applied with more intricate

circuits. Analog Devices has constructed an active cell balancer consisting of a flyback

converter (a buck-boost based converter) that limits the healthiest cells from being fully

charged before the weak cells has completed charging. This is done without the unwanted

energy dissipation of the discharge resistors [5].

2.2 Communication Protocols

Almost all devices today are connected in one way or another. For the devices to talk to each

other, some sort of communication interface must exist. This task is made possible by

communication protocols, which offer different types of protocols depending of the

communication standard for electronic devices. This provides guidance for data transmitting.

This sets of rules vary from area to area, with each area having a different communication set

for their own needs. A common interface for two-way communication between basic

electronic devices is Serial Peripheral Interface (SPI), which works by physically connecting the

devices with each other, using a master and slave configuration [6].

In automotive applications, Controller Area Network (CAN) is the modern communication

standard that offers a robust, low cost solution that can be applied to cars, trucks and robots

[7].

2.3 Serial Peripheral Interface

One of the most common communication protocols used today is Serial Peripheral Interface

(SPI). SPI is used by sensors and components to establish a communication between the device

and a microcontroller.

By utilizing a bus consisting of

four signals, Master Out Slave

In (MOSI), Master In Slave Out

(MISO), a clock (SCK) and Slave

Select (SS), an interruption

free data transmission can be

achieved [6].

The master-slave relationship works by having one master with one or more slaves. The master

can transmit data to each slave, while each slave is only able to communicate with the master.

In figure 2:2, a simple configuration consisting of one master and one slave is pictured.

Figure 2:2 SPI Configuration

Chapter 2: Theory

7

2.3.1 SPI Transmission

A SPI transmission is digital and thereby built by bits. For the master to transmit a signal to the

slave, the master must first initiate a clock signal (SCK), deciding the speed of the transfer. One

bit of data is transferred every clock cycle. Then, Slave Select (SS) is brought LOW, representing

a zero, to establish a connection with the desired slave. When the clock cycle match between

the master and slave and a connection has been established, data transfer can begin [8].

By using SPI, data between the master and slave can be sent at the same time, uninterruptedly.

This method of transfer is called full duplex.

Figure 2:3, 2:4 and 2:5 illustrate each step of the data transmission.

Figure 2:3 A clock signal is sent by the master

Figure 2:4 Slave Select is brought low to establish a connection with the slave

Figure 2:5 Data transmission between the master and slave can begin

Chapter 2: Theory

8

2.4 Isolated Serial Peripheral Interface

In automotive systems where electrical noise is high and reliability is key, there is a need for a

more robust protocol that handles these tough conditions while remaining cheap and safe.

Isolated Serial Peripheral Interface (isoSPI) is an adaptation of SPI that retains the advantages

of SPI while being electrical isolated.

The advantages of isoSPI comes from having two wires, twisted together and using

transformers for electrical isolation. At each end of the wire, termination resistors with a

resistance of about 100Ω are used. As a result of this, external electromagnetic interference

on the wires becomes neglectable and galvanic isolation is achieved.

There are several ways of designing transformers for a high voltage application of isoSPI. The

easiest, but most costly solution is to use reinforced transformers combined with the method

stated above to fully isolate the signal. However, when choosing transformers, it is often

recommended to select transformers rated to at least ten times the nominal voltage for the

application, often making the cost high.

A cheaper solution is to combine the transformer with a coupling capacitor in order to

distribute the isolation over both the capacitor and transformer, lowering the requirement for

the transformer. The coupling capacitor then blocks DC signals from passing to the wire and

thereby isolates the connection to the other side [2]. A preview of such a system is illustrated

in figure 2:6.

Figure 2:6 A system preview of an isoSPI application

The most common interface for isoSPI is the readily

available Ethernet LAN port, the RJ45.

The RJ45 connector consists of eight wires and is pictured

in figure 2:7.

Figure 2:7 A RJ45 connector

Chapter 2: Theory

9

2.5 Controller Area Network

2.5.1 History

Developed by Bosch in 1986, Controller Area Network (CAN) made complex communication

between sensors, microcontrollers and ECUs easy and manageable, while being sufficiently

robust for use in the automotive industry. By 1993, the first version of CAN was submitted for

international standardization, depicting its data link and physical layer with increased speed

and thus becoming the new standard for commercial vehicles. The new standard fell under ISO

11898 and was later followed up by 11898-2, presenting a different, parallel form of data

transmission but which never took off [1].

The first implementation of CAN in the car industry was done by Mercedes-Benz in 1992, by

controlling parts of the engine with CAN-communication. In this case, two separated closed

systems were integrated, physically separated from each other.

In 2012, another breakthrough in CAN technology was made by Bosch. The development of

CAN FD (CAN Flexible Data-Rate) begun with an increased transmission speed of up to 8

Mbit/s. This enabled the use of more complex systems in modern EVs.

Today, CAN is used by almost all car manufacturers, but is also integrated in trucks and

electrical machines among others. The most common version of CAN used today is CAN 2.0B.

2.5.2 The CAN physical interface and wiring

Utilizing the physical DB9 connector pictured in figure

2:8, the interface for standard CAN transmission

consists of nine pins, where only two of them are

needed for basic operation. The signals used for CAN

information is located at pin 2 and pin 7, where pin 2

correspond to CAN LOW and pin 7 to CAN HIGH [9]. Pin

1 begins from the top left position and continues from

left to right.

Figure 2:8 The male DB9 connector for CAN

Chapter 2: Theory

10

Table 2:1 describes the pinout of the CAN DB9 connector.

Table 2:1 The CAN DB9 connector pinout

Pin Signal Description

1 - Reserved

2 CAN LOW CAN-bus dominant low

3 CAN GND Optional CAN ground

4 - Reserved

5 CAN SHIELD Optional CAN Shield

6 GND Optional ground

7 CAN HIGH CAN-bus dominant high

8 - Reserved

9 CAN V+ Optional external power supply

To establish a connection between the connectors, CAN HIGH and CAN LOW needs to be

twisted in order to eliminate external noise generated by magnetic fields from the wires and

environment. Furthermore, termination resistors positioned parallel to the CAN HIGH and CAN

LOW must be placed at the beginning and end of the wired connection, as in figure 2:9. By

using termination resistors, energy from reflected signals can be absorbed and thereby

canceling possible interference caused by the signals. The typical resistances for the

termination resistors are 120Ω.

Figure 2:9 CAN DB9 connector wiring

Chapter 2: Theory

11

2.5.3 CAN Transmission

CAN 2.0B operates at half-duplex, which means that messages can be transmitted in any order,

but only received one at a time. Each sent CAN message carries a unique message identifier

(ID) which is decoded by the receiver to construct a priority list based on the number of the

ID. This means that a message with a lower priority will be halted from being received if a

message with a higher priority is sent at the same time. The priority list is based on the number

of the ID, where the lowest number acquires the highest priority. Due to this property, CAN

nodes can send and receive any number of messages continuously, without disrupting the bus.

[7]

CAN transmission is voltage dependent, which means that there is no need for a common

ground. This is also the reason why CAN only needs two wires to transfer data, CAN High and

CAN Low. Specifed from the ISO-11898-2 standard, each signal can possess two states,

dominant and recessive. Depending on the signal, the applied voltage can either be 1.5V, 2.5V

or 3.5V. In figure 2:10, graphical representations of the two states are shown with their

respective voltages. As CAN transmission is digital, the two logical states are decoded by the

differential voltage between the two signals. When both signals are in the recessive state, the

differential voltage between them is zero and is decoded to represent a logic 1. If both signals

are in the dominant state, the differential voltage becomes 2V and is then decoded to

construct a logic 0. Since the absolute values of 0V and 2V often are hard to achieve, thresholds

are used to make the decoding simpler. The minimum threshold to read the state as recessive

is usually less than 0.5V (0.5V) to read the state as dominant.

[10]

Figure 2:10 The recessive and dominant states of CAN

Chapter 2: Theory

12

2.5.4 The CAN message structure and frame layout

A typical CAN message is structured by several different “frames”. These frames, all with a

different purpose, exists to provide an error free, robust transfer of data that can be easily

deconstructed by the receiving end. The four common frames used in CAN transmission are

the data frame, the remote frame, the error frame and the overload frame [7].

In figure 2:11, a detailed overview of the CAN data frame is illustrated. It begins with the SOF

(Start of Frame) which indicates that new data is incoming. This is followed by a Message

Identifier frame that gives the message an ID and reserves a location for the frame in the

memory. The Control Field then provides information about the frame format of the message.

The format can either be a Standard Frame Format or an Extended Frame Format, built by an

11-bit Identifier and a 29-bit Identifier respectively.

Figure 2:11 The CAN data frame format [7]

In the Data Field, all raw data are contained. The data can be up to 64 bits (8 bytes) and are

often composed of one of two frame layouts, Little Endian made by Intel, or Big Endian made

by Motorola.

Chapter 2: Theory

13

In Little Endian, data begins at the least significant bit (LSB) and continues from the current bit

counting upwards, thus ending at the most significant bit (MSB). Using Big Endian, the LSB and

MSB are from Little Endian reversed. However, data still begins at the LSB but continues from

the current bit counting downwards, still going from right to left, ending at the MSB at a lower

byte number. See figure 2:12 for a more detailed overview on Little and Big Endian.

Figure 2:12 Little Endian (left) and Big Endian (right)

Thereafter, the CRC sequence (Cyclic Redundancy Check) begins. The CRC sequence is an error

detecting code which is applied to detect accidental changes in the data sent. When this

sequence is complete, and the message has been properly received by all nodes, an

acknowledgement frame is sent to confirm the reception. To conclude the CAN message, the

EOF (End of Frame) gets sent, indicating that the message has come to an end.

Chapter 2: Theory

14

2.6 The Pre-Charge Method

As electric vehicles contain energy circuits with capacitive loads, connecting a battery pack to

such systems can cause huge initial inrush currents as the capacitors are being charged to the

voltage of the battery pack. The currents can be up to several kA, possible destroying

components and devices in its process. To avoid this, the pre-charge method must be utilized

to relieve the system from the heat damage of the large currents created at the startup.

Instead of the utilization of two contactors, in this case relays, the addition of contactor C in

figure 2:13 provides a reduction in current flow as it has a current limiting resistor. There is no

benefit to contactor C being connected to the positive terminal of the battery, but the industry

standard suggests a mounting similar to the one in the picture.

Figure 2:13 The move towards a typical pre-charged circuit

When pre-charge is initiated, contactor A and C closes. This provides current to the capacitive

load, but since the circuit now is pre-charged, the current is considerably lower than before. It

is however important to calculate the dissipated power when choosing a pre-charge resistor

due to the high current that enters it. In some circumstances, the power dissipated can be over

1000 W due to the high initial currents.

When all capacitive loads are charged with the same voltage as the battery and the inrush

current has subsided, contactor B closes. In theory, there is not a need for contactor C to open

again, but to save coil power, contactor C is often opened when contactor B has closed [3].

The resistance and rated power of the pre-charge resistor differs between circuits. Thus, it is

important when designing a pre-charge circuit to calculate the resistance needed. The

complete calculation of the pre-charge resistor can be found in 2.7.1 Pre-charge resistor

selection.

Chapter 2: Theory

15

2.7 Mathematical Calculations

A list of mathematical calculations used in this project and how they can be expressed are

described here.

2.7.1 Pre-charge resistor selection

To calculate the resistance of the pre-charge resistor, formula 1-5 [3] are used. The pre-charge

circuit is illustrated in figure 2:14.

The pre-charge surge current reaches 1

𝑒 ≈ 37 [%] of its initial value after a time of:

𝑇 = 𝑅 × 𝐶 (1)

Where T is the desired time of pre-charge, R is the resistance of the resistor and C is the

capacitance of the capacitor. The current is reduced to a manageable level after 5 × 𝑇.

The resistance of the resistor becomes:

𝑅𝑝𝑟𝑒𝑐ℎ𝑎𝑟𝑔𝑒 =𝑇

5×𝐶 (2)

The dissipated energy of the resistor is:

𝐸 =𝐶×𝑉2

2 (3)

Where V is the voltage of the battery.

The dissipated power of the resistor is:

𝑃𝑡𝑜𝑡 =𝐸

𝑇 (4)

The instantaneous power becomes:

𝑃 =𝑉2

𝑅𝑝𝑟𝑒𝑐ℎ𝑎𝑟𝑔𝑒 (5)

Chapter 2: Theory

16

Figure 2:14 The pre-charge circuit

2.7.2 Discharge resistor selection

Due to high voltages on the load capacitor, a safety measure consisting of a discharge resistor

must be utilized. The following expressions describes how it can be chosen. The RC discharge

circuit is pictured in figure 2:15.

The discharge resistor can be calculated by the formula: [11]

𝑅𝑑𝑖𝑠𝑐ℎ𝑎𝑟𝑔𝑒 =−𝑡

𝐶×ln(𝑉𝑠𝑎𝑓𝑒

𝑉𝑜) (6)

Where t is the desired time taken to discharge the capacitor, C is the capacitance of the

capacitor, Vsafe is the voltage the capacitor safely can be discharged at and Vo the initial voltage

of the capacitor.

The voltage for safe discharge has been set by IEC and is stated to 120V DC [12].

The voltage drop of a resistor can be calculated using Kirchhoff’s voltage law:

∑ 𝑉𝑘 = 0𝑛𝑘=1 (7)

Where n is the total number of voltage drops measured and Vk is the size of the voltage drop.

Chapter 2: Theory

17

Figure 2:15 The RC discharge circuit

2.7.3 Voltage divider

In order to calculate the output voltage of a voltage divider, the following formula [11] can be

used:

𝑉𝑂 = 𝑉𝑖𝑛(𝑅1

𝑅1+𝑅2) (8)

Where Vin is the input voltage, R1 is the resistance of the first resistor and R2 is the resistance

of the second resistor. A common voltage divider is illustrated in figure 2:16.

Figure 2:16 A typical voltage divider

Chapter 3: Execution

18

Chapter 3: Execution

3.1 Overview of the BMS

The idea of the BMS was to operate as one, with each subsystem providing data to another.

An overview of the whole system is drawn in figure 3:1. The system contained a battery

management unit (BMU) as the requester of the functions, a battery junction box (BJB) that

held the relays for the battery, and a cell management unit (CMU) which made up each cell of

the battery. A translation unit was also included in order to translate signals with different

forms of communication between each other. For troubleshooting, a wire connected to a PC

was attached in order to sniff the CAN-bus and to simulate some of the subsystems before

they had been built. When the subsystems had been built and merged into one, the wire to

the PC would not become necessary.

The main communication protocol used in this system was CAN 2.0B, set to 500kbps. This

provided a sufficient transfer speed while it retained the robustness of CAN. This form of

communication was used between the BMU, BJB, CAN/isoSPI translation board and the PC.

Between the CMU and CAN/isoSPI translation board, isoSPI was utilized. The CMU, which

contained the battery, was directly connected to the BJB from the positive and negative

terminals of the battery.

Figure 3:1 Overview of the BMS

Chapter 3: Execution

19

3.2 Battery Management Unit

The main tasks of the BMU were to send signals to engage “Drive Mode”, engage the mode to

stop and have a signal reserved for extra features. A description of these features can be found

in 3.2.3 Features. A simplified circuit was first built on a breadboard to make diagnostics and

troubleshooting easier when testing the system compared to a soldered board. When the

simplified circuit had been built and worked as it should, the final version was created and

soldered to a Sparkfun Qwiic Shield board with the correct components.

Before the assembly began, a full schematic over the system was created. The schematic is

illustrated in Appendix A1.

3.2.1 Components

The components used for the BMU are listed below.

o 1 pc. [13] Arduino Uno Rev.3 SMD

o 1 pc. [14] Sparkfun CAN-Bus Shield

o 1 pc. [15] Sparkfun Qwiic Shield

o 1 pc. [16] Peak CAN-USB adapter

o 1 pc. Breadboard

o 1 pc. Box (220x150x70 mm)

o 3 pcs. Push buttons

o 3 pcs. Two-position switch

o 6 pcs. LED-diodes (5 mm)

o 1 pc. DB9 female connector

o 1 pc. DC female plug (5.5/2.1 mm)

o 1 pc. USB type B connector

o 6 pcs. 300Ω resistors

o 6 pcs. 10kΩ resistors

o 2 pcs. 120Ω resistors

o 1 pc. 12V DC adapter

Chapter 3: Execution

20

3.2.2 Assembly

3.2.2.1 The prototype system

At the beginning of assembly, a prototype system was built. The focus was to construct a

simple circuit that responded to the user’s requests, without CAN support. This was done in

order to have solid foundation for the rest of the assembly going forward and to make sure

that the electrical schematic was properly designed. Here, a breadboard and a button were

used instead of the Qwiic shield and the on/off switch, as it offered a more user-friendly

solution at the time.

A simpler and lighter source code was also applied, due to its lack of complexity compared to

the finished system later built. The finished prototype system is pictured in figure 3:2. When

the blue button was pressed, a blue LED connected to the button was lit up to ensure that it

had been pushed and voltage to the circuit with the red LED applied, representing a request

for a function to initiate.

Figure 3:2 The finished prototype system for the BMU

Chapter 3: Execution

21

3.2.2.2 The finished system

Unlike the prototype system, all connections on the finished system were soldered. Here, all

three switches were used, each controlling one LED diode as an output. However, the LED

diode directly connected to the switch was here removed, since it did not add any functionality

to the finished product. A LED diode solely at the output provided more than enough

verification that the switch had been flipped and that the request had been sent.

The three development boards were stacked on top of each other as their manuals suggested,

with the Arduino Uno Rev.3 SMD at the bottom, the Sparkfun CAN-bus shield in the middle

and the Qwiic shield at the top. The components were soldered on the Qwiic shield with the

cables going underneath the circuit board.

The Uno Rev.3 SMD by Arduino provided enough digital and analog ports and was the clear

solution for this task with its wide compatibility with other add-on shields. The Sparkfun CAN-

bus shield was chosen for the CAN transmission due to its ease of use, with several tutorials

available online. In addition to this, software libraries for this shield were already made so that

the time-consuming hassle of creating your own could be avoided. Similar reasoning was done

for the Qwiic shield, as its compatibility with the Sparkfun CAN-Bus made it a clear choice for

a compact circuit board to solder components on.

Outgoing from the CAN-bus shield, the CAN LOW and CAN HIGH wires were twisted with a

120Ω termination resistor at the end. To connect the two CAN wires to a computer and the

rest of the system, the wires were soldered onto a female DB9 connector and attached to the

Peak CAN-USB adapter. The finished product is illustrated in figure 3:3.

Figure 3:3 The finished system for the BMU

Chapter 3: Execution

22

An enclosure for the BMU made up of a box was made to improve the user experience and

general interaction with the system. The three switches and LED diodes were moved to the

top of the box and labeled with their corresponding action. The CAN input was attached to the

right side of the box and the DC input for the Arduino on the left side. To finish the enclosure,

a USB port to enable communication between the BMU and a PC was then added. The

enclosure made for the BMU is pictured in figure 3:4-3:6.

Figure 3:4 The top of the BMU enclosure

Figure 3:5 The left side of the BMU enclosure

Figure 3:6 The right side of the BMU enclosure

Chapter 3: Execution

23

3.2.3 Features

The initial mode, “Drive Mode”, needed to provide some safety measures in case of unknown

failures in the system. Since the BMU controlled the actions of the BJB, the BMU must have

been able take the initiative if something were to happen to the battery. The automated safety

measures needed for Drive Mode are listed below.

o Stop the system if the battery voltage was to high/low

o Stop the system if the system voltage was to high/low

o Stop the system if the battery temperature was to high/low

o Stop the system if the system current was to high

The specification of the limits chosen for the measured properties above are detailed in Table

3:1.

Table 3:1: The specification of the system properties

System property Limit

Battery Voltage 10 – 13 [V]

System Voltage 10 – 13 [V]

System Current 0 – 2 [A]

Battery Temperature 10 – 55 [oC]

These values were chosen to protect the Arduino from power peaks, wrong input voltage and

temperature. More information about the specifications of these values for the Arduino Uno

can be found in official Arduino store [13].

The order of actions for when the user chose to engage Drive Mode were the following:

1. Check if the system properties were OK

2. Initiate pre-charge (close the Pre+ and Main- relay)

3. Connect the battery (close the Main+ relay)

4. Terminate pre-charge (open the Pre+ relay)

The BMU also needed to have a function for stopping the vehicle. The mode was named

“Stop”, with the sole purpose to open the contactors, thus disconnecting the battery and

forcing the vehicle to stop.

If communication between the BMU and the rest of the system would stop working, a

communication timeout error was required to be delivered to the user. In addition to this,

other warning texts also had to be added to improve the user experience. All finished warning

and error messages can be found in 4. Results. The purpose of these warning texts was to

imitate the features of an automotive environment and to enable a safe interaction of the

system to the user. Although not mandatory, this was done due the future integration of this

BMS to a vehicle.

Chapter 3: Execution

24

3.2.4 Programming

The coding of all subsystems, including the BMU, were accomplished using the Arduino IDE

software. As Arduino IDE contained the necessary libraries for all Arduino boards, proper

libraries for the Arduino Uno were in this application chosen. Also, since the CAN-shield was

provided by Sparkfun, several ready-made libraries by Sparkfun [17] to allow the shield to work

as intended were utilized when programming.

To check if the CAN-signals were correctly sent and received, the free PC-available software

BUSMASTER was used. BUSMASTER allowed to create real CAN messages and in this case

simulate the measurements coming from the BJB. Simulated values for the battery voltage,

system voltage, system current, battery temperature and state of contactors were here

created. This became useful since the actual battery and BJB yet not was constructed at this

point. This software was also the reason why the PEAK USB-adapter was chosen for the PC

interface, as its out-of-the-box compatibility allowed it to communicate with the constructed

systems without problems.

A flow chart describing each step of Drive Mode was made and is illustrated in figure 3:7. The

full source code for this mode can be found in Appendix B1.

Figure 3:7 The flow chart for Drive Mode

Chapter 3: Execution

25

3.2.4.1 Construction of the outgoing CAN message

The message sent by the BMU was constructed of 8 bytes with the frame layout of Little

Endian. To stay consistent, all messages for all systems going forward were constructed using

Little Endian. The main purpose of the message sent from the BMU was to give orders to the

BJB to open or close the contactors.

Byte 0 of the message was reserved for the Main+ relay, byte 1 for the Main- relay and byte 2

for the Pre+ relay. The address of this message was 0x631 and is pictured in figure 3:8 where

“message.data[0-7]” represents each byte of the message.

Figure 3:8 The CAN message from the BMU

Chapter 3: Execution

26

3.2.4.2 Deconstruction of the incoming CAN messages

Four incoming messages to the BMU were received in total. Message 1 came from the BJB and

contained information about the battery voltage, system voltage, system current, battery

temperature and state of contactors. Messages 2-4 originated from the CMU and contained

information about the voltage of all 12 cells.

The byte charts for message 1 are represented in figure 3:9-3:15. Byte 0-1 contained

information about the battery voltage, byte 2-3 about the system voltage, byte 4-5 about the

system current, byte 6 about the battery temperature and byte 7 about the state of contactors.

The address for this message was 0x630.

Figure 3:9 Battery voltage Figure 3:10 System voltage Figure 3:11 System current

Figure 3:12 Battery temperature Figure 3:13 State of Main+ relay Figure 3:14 State of Main- relay

Figure 3:15 State of Pre+ relay

Chapter 3: Execution

27

To interpret each measurement, a function was initially created to decipher the battery

voltage, system voltage and system current as they consisted of more than one byte. Bit

masking was used to automatically merge the byte number of the LSB and MSB.

To decipher the state of contactors, since they all consisted in the same byte, bit masking and

bit shifting techniques were utilized. The functions for bit masking which was created were

named “CANconvert”, “MainContactorP”, “MainContactorM” and “PreContactor” and are

illustrated in figure 3:16. The finished deconstruction of the CAN message from the BJB is

shown in figure 3:17 and the full source code for the bit masking functions can be found in

Appendix B3.

Figure 3:16 The functions "CANconvert", "MainContactorP", "MainContactorM" and "PreContactor"

Figure 3:17 The incoming message from the BJB

Chapter 3: Execution

28

Data from the CMU were deconstructed in a similar way as the battery voltage, system voltage

and system current were from the BJB. Each received cell voltage consisted of two bytes,

making the total size of transfer 24 bytes, or three full CAN messages.

In figure 3:18, one of the three deconstructed messages from the CMU is presented, as the

structure was identical between all three messages. The addresses for the messages were

0x633, 0x634 and 0x635.

Figure 3:18 One of the incoming messages from the CMU

Chapter 3: Execution

29

3.3 Cell Management Unit

The CMU housed all 12 cells of the battery, which in this case were simulated by twelve 100Ω

resistors, physically connected in serial, parallel to the BJB. Since no actual battery was

connected to the CMU, resistors had to be used for the circuit board to function properly. Also,

since the CMU did not contain any microcontroller and thus only being a physical layer, all

programming work for the CMU were instead done on the Linduino of the CAN/isoSPI

translator. The CMU only provided the sensors needed to perform the measurements.

An electrical schematic over the CMU was created to help with the assembly. The complete

schematic can be found under Appendix A2.

3.3.1 Components

The components needed for the CMU are listed below.

o 1 pc. [18] Analog Devices DC2259A

o 1 pc. [19] Analog Devices DC1941D

o 12 pcs. 100Ω resistors

o 1 pc. 14-pin SPI ribbon

o 1 pc. 12V DC adapter

3.3.2 Assembly

To construct the cells of the battery, twelve 100Ω resistors were connected in serial between

port 4 and 16 on the DC2259A. Port 1-3 of the board were for auxiliary applications and not

used for this project. Following, a 12V DC adapter was connected in parallel over port 4 and

port 16, equally distributing the voltage across all twelve resistors. This meant that the

theoretical voltage of each cell approximately became 1V. However, due to minute losses in

the finished system, values under 1V could sometimes be observed.

From the SPI port labeled “bottom” on the battery stack monitor, a 14-pin SPI ribbon was

added to connect the DC2259A to the isoSPI demo board (DC1941D). Furthermore, a RJ45

cable was also connected to the isoSPI port on the demo board in order to grant access to data

from the CMU. The jumpers JP1, JP2, JP3 and JP4 were set to 0 to configure the battery stack

monitor as a one board stack solution. If more than one DC2259A were to be stacked together

in the future, the configuration for the jumpers would need to be changed. The completed

system is shown in figure 3:19.

Chapter 3: Execution

30

Figure 3:19 The main part of the CMU (DC2259A)

The choice of the DC2259A came down to its combability with the Linduino and its

communication interface by SPI. In the manual for the DC2259A, the method for connecting

the unit with a Linduino was clearly stated, and if the user wanted a connection by isoSPI, the

instructions stated that clearly as well. Overall, it provided an easy experience and was the

right choice for this project. The isoSPI demo board, the DC1941D, was the only available

solution for the DC2259A in order to provide a communication interface by isoSPI, hence why

it was chosen.

Due to the CMU only being a physical layer, no coding for this system had to be done.

Chapter 3: Execution

31

3.4 CAN/isoSPI Translation Board

For the CAN/isoSPI translator to work, an Arduino Uno compatible shield with both CAN and

isoSPI support needed to be used. Signals from the CMU, containing information about the

battery cells sent by isoSPI, had to be sent back to the BMU if the BMU was to request the

measurements. This meant that the isoSPI signals had to be converted to CAN signals, which

was the one of the main features of this system. Furthermore, since the CMU did not contain

any intelligence, functions for the voltage measurement of cells had to be included on this

system.

A schematic over the CAN/isoSPI translator unit was created before the assembly. The

schematic can be found in Appendix A3.

3.4.1 Components

The components needed for the CAN/isoSPI translator are listed below.

o 1 pc. [20] Linduino One

o 1 pc. [21] Analog Devices DC2617A

o 1 pc. RJ45 cable

o 1 pc. Box (220x150x70 mm)

o 1 pc. C14 female connector

o 1 pc. DC female plug (5.5/2.1 mm)

o 1 pc. USB type B connector

o 1 pc. 12V DC adapter

3.4.2 Assembly

To construct the translator, the CAN/isoSPI shield from Analog Devices was stacked on top of

the Linduino One. This device was the only available solution that both provided a connection

by CAN and isoSPI, hence why it was chosen. The shield was as the Linduino also made by

Analog Devices, thus maximizing compatibility between the two devices.

To connect the translator to the CMU, a RJ45 cable was used. The Linduino is an Arduino Uno

compatible system with similar characteristics as the genuine Arduino, but with an added port

for regular SPI communication. This offered the help of troubleshooting before the isoSPI

solution was properly constructed. However, this port was not used in the final product.

The shield had a built-in resistor for CAN termination; therefore, no external resistor needed

to be used. To enable this feature, jumper JP2 had to be set to ON. The fully assembled

CAN/isoSPI translator is pictured in figure 3:20.

Chapter 3: Execution

32

Figure 3:20 The assembled CAN/isoSPI translator

An enclosure was as for the BMU also made for the CAN/isoSPI translator. Since the sizes of

the CMU and CAN/isoSPI translator both were compact enough to fit in the same enclosure,

only one enclosure was made for the two systems. Power for the simulated battery was

provided by a C14 connector attached to the left side of the box. At the same side, wires from

the positive and negative terminals of the battery were passed through the box by a grommet,

not to damage the cables and for the BJB to access. The DB9 connector for CAN was placed on

the front of the box, and a DC power plug for the Arduino at the back. An USB port to enable

communication between the Translator and a PC was also then added. The completed

enclosure for the CMU and CAN/isoSPI translator is illustrated in figure 3:21 and 3:22.

Figure 3:21 The front of the enclosure for the CMU and CAN/isoSPI translator

Chapter 3: Execution

33

Figure 3:22 The back of the enclosure for the CMU and CAN/isoSPI translator

3.4.3 Features

Other than converting isoSPI-signals to CAN and vice-versa, features such as independent cell

voltage measurement and balancing of cells were to be desired. The measurement for the

voltage across all cells was not done here but instead done by the BJB. This was due to the

measurements of the Linduino were done by software, thus not being as reliable and robust

as traditional methods for voltage measurement.

Also, to measure the voltage across all cells using software was in this case not as accurate as

traditional methods, since it did not take the whole system in consideration, avoiding potential

losses.

3.4.4 Programming

The Linduino One came pre-programmed with a software called QuikEval. QuikEval is a

software developed by Analog Devices that controls and monitors compatible battery stack

devices, including the DC2259A used for the CMU. Therefore, to evaluate the status of the

CMU, this software was in the beginning utilized to make sure everything on the CMU worked

as it should. This was also one of the reasons for choosing the Linduino One over the genuine

Arduino Uno in the first place.

After evaluation for no errors on the CMU, coding began. Since the CAN/isoSPI translator

provided the processing power needed to monitor the CMU, and the CMU only being a

physical layer, all programming work made for the CMU was done on this system. Ready-made

libraries for the DC2259A [22] were here used and modified to construct the function for the

measurement of cells. The libraries already contained most features of the QuikEval software,

so only the features presented in 3.4.3 Features were utilized. The full source code for the

measurement of the cells can be found in Appendix B6.

Chapter 3: Execution

34

Due to time constraints, the ability to perform cell balancing was omitted. Cell balancing would

not make this system perform better at this time, as it was only meant to be implemented for

future combability with Li-Ion batteries. Thus, the performance, even without cell balancing,

remained the same.

For the CAN transmission and reception to work, a few lines of code in the Sparkfun library

had to be edited. The CAN microcontroller in the DC2617A, MCP2515, was here the same, but

not the position of the chip select pin. To solve this, the chip select had to be assigned to digital

pin 9 instead of digital pin 10 on the Linduino.

3.4.4.1 Construction of the outgoing CAN messages

The simulated battery cells on the CMU were measured to three decimals precision. Therefore,

each measurement value was allocated two bytes of data in the forwarded message to the

BMU. This meant that a data value up to 65.535V could be transmitted. Since the maximum

voltage of each cell in the CMU would be just over 12V if all other cells were to break down,

two bytes of allocation sufficed. The functions “CANconvert_msb” and “CANconvert_lsb” were

used to divide the integers to the correct byte number of the LSB and MSB. The full source

code for the CAN conversion can be found in Appendix B3. In figure 3:23, one of the outgoing

messages from the CMU is presented, as the structure was identical between all three

messages. The addresses for the transmitted messages were 0x633, 0x634 and 0x635.

Figure 3:23 One of the outgoing CAN messages from the CMU

Chapter 3: Execution

35

3.5 Battery Junction Box

With the Battery Junction Box (BJB) containing the principal part of the battery

connect/disconnect circuit (pre-charge circuit), several preparatory calculations of resistor

values were required. For that to be possible, the capacitance of the system in which the

battery connected needed to be approximated, and a desired time for pre-charge chosen. In

addition to this, a desired time for safe discharge also needed to be determined.

NEVS approximated the capacitance of an ordinary connected EV system to 1000µF, desired a

pre-charge time of under 500ms and a discharge time of under 1s. The following calculations

took these values in consideration when solving for suitable resistor values. For the two

voltage measurements, a voltage divider also needed to be created since the input voltage for

the Arduino could not be greater than 5V to avoid damage to the board.

In order to verify the functionality of the pre-charge circuit, a prototype system was first built.

When the desired performance of the prototype system was achieved, the work on the proper

system begun. An electrical schematic over the BJB was created before the assembly. The

schematic can be found in Appendix A4.

3.5.1 Preparatory calculations

3.5.1.1 Discharge resistor

Due to the possibility that the battery voltage would exceed 800V in the future, a discharge

resistor capable of safely discharging 800V was calculated. In theory, since the voltage in this

system only was 12V, no discharge resistor would be needed.

Using formula (6), the resistance needed for the discharge resistor was:

𝑅𝑑𝑖𝑠𝑐ℎ𝑎𝑟𝑔𝑒 =−1 [𝑠]

1000 [µ𝐹] × ln(120 [𝑉]800 [𝑉]

)≈ 527 [Ω]

A discharge resistor with a value of 100Ω was thereby chosen to be sure of a discharge time

under 1s.

Using formula (5), the instantaneous power of the resistor was:

𝑃𝑑𝑖𝑠𝑐ℎ𝑎𝑟𝑔𝑒 =122 [𝑉]

100 [Ω]= 1.44 [𝑊]

A resistor capable of dissipating at least 5W was thereby chosen.

Chapter 3: Execution

36

3.5.1.2 Pre-charge resistor

Using formula (2), the resistance needed for the pre-charge resistor was:

𝑅𝑝𝑟𝑒𝑐ℎ𝑎𝑟𝑔𝑒 =500 [𝑚𝑠]

5×1000 [µF]= 100 [Ω].

Using formula (7), the voltage drop across the discharge resistor was:

𝑉𝑠 − 𝑉𝑝𝑟𝑒𝑐ℎ𝑎𝑟𝑔𝑒 − 𝑉𝑑𝑖𝑠𝑐ℎ𝑎𝑟𝑔𝑒 = 0

12 [𝑉] − 100 [Ω] × 𝐼 − 100 [Ω] × 𝐼 = 0

12 [𝑉] − 200 [Ω] × 𝐼 = 0

→ 𝐼 =12 [𝑉]

200 [Ω]= 60 [𝑚𝐴]

→ 𝑉𝑑𝑖𝑠𝑐ℎ𝑎𝑟𝑔𝑒 = 100 [Ω] × 60 [𝑚𝐴] = 6 [𝑉]

Using formula (5), the instantaneous power of the resistor was:

𝑃𝑝𝑟𝑒𝑐ℎ𝑎𝑟𝑔𝑒 =62 [𝑉]

100 [Ω]= 720 [𝑚𝑊]

Issued from the previous calculations, a resistor capable of dissipating 5W was chosen.

3.5.1.3 Resistors for the voltage divider

To achieve the maximum output voltage of 5V, calculations for the resistance of the two

resistors were required. The input voltage (battery voltage) was 12V, but for safety

precautions, the input voltage was in the following calculations set to 15V. The reason for this

was to protect the Arduino, if the battery voltage were to spike above 12V.

Since the input voltage was similar for the two voltage dividers used in the pre-charge circuit,

the same values for the resistors could be applied. To limit current from entering the voltage

divider and prevent voltage drops, the value of R1 was set to 100kΩ.

Chapter 3: Execution

37

Using formula (8), the resistance of R2 became:

5 [𝑉] = 15 [𝑉] × (100𝑘 [Ω]

100𝑘 [Ω] + 𝑅2)

→ 𝑅2 = 50𝑘 [Ω]

Since a resistance of 50kΩ is not a standardized value for resistors, the resistance of R2 was set

to 47kΩ. This resulted in a maximum voltage output level of 4.796V if the input voltage was

15V.

3.5.2 Components

In addition to the components of the previous calculations, the complete set of components

needed for the BJB are listed below.

o 1 pc. [13] Arduino Uno Rev.3 SMD

o 1 pc. [23] Seeed Relay Shield v3.0

o 1 pc. [14] Sparkfun CAN-bus shield

o 1 pc. [24] Sparkfun Temperature Sensor - TMP36

o 1 pc. [25] Sparkfun Current Sensor Breakout - ACS723

o 1 pc. Breadboard

o 1 pc. Through-hole PCB (150x100 mm)

o 2 pcs. 100kΩ resistors

o 2 pcs. 47kΩ resistors

o 2 pcs. 100Ω resistors (5 W)

o 2 pcs. 220Ω resistors

o 1 pc. 1000µF capacitor (100 V)

o 3 pcs. Push buttons

o 1 pc. Box (220x150x140 mm)

o 1 pc. LED-diode

o 1 pc. DB9 female connector

o 1 pc. DC female plug (5.5/2.1 mm)

o 1 pc. USB type B connector

o 1 pc. 12V DC adapter

Chapter 3: Execution

38

3.5.3 Assembly

3.5.3.1 The prototype system

The idea of constructing a prototype system was primarily to check the functionality of the

pre-charge circuit; that the voltage divider worked correctly and to be sure there would be no

short-circuits that could damage the components in the finished system.

The prototype system consisted of the Arduino Uno, connected by wires to a breadboard

where a simplified model of the pre-charge circuit was built. Instead of relays, simple push

buttons were chosen for their modularity, removing the need for complex programming since

they could be manually pushed. The capacitor was also switched out, in this case for a LED-

diode that easily could provide verification that the buttons had been pushed and that the

circuit operated normally. Due to this, the pre-charge as well as the discharge resistor needed

to be changed to larger ones, not to damage the LED-diode. 220Ω resistors were therefore

chosen to restrain the current to a more manageable level. The finished prototype system is

illustrated in figure 3:24.

Figure 3:24 The prototype system for the BJB

Chapter 3: Execution

39

3.5.3.2 The finished system

By NEVS request, the utilization of a HV capacitor capable of 100V DC was necessary in order

to provide less modifications needed for future high voltage applications of the BMS. All

components were soldered on the through-hole PCB as per the schematic in Appendix A4. The

add-on shields used in this subsystem were stacked on top of the Arduino. The order from the

bottom was:

1. Arduino Uno Rev.3 SMD

2. Seeed Relay Shield v3.0

3. Sparkfun CAN-bus Shield

4. The through-hole PCB board with the pre-charge circuit

There was no reason for this stacking order apart from available space, and that it was

mandatory for the Arduino to sit at the lowest point. All shields shared the same sets of digital

and analog I/O. At the relay shield, relays 2-4 were used out of the four total relays. Here, the

order mattered. Not for the functionality, but for declaring constants when coding. The input

for the BJB came from the CMU and consisted of a positive and negative wire, both connected

to the pre-charge circuit on the PCB.

The choice of the Seeed Relay Shield v3.0 fell under its four individually controlled relays and

compatibility with the Arduino Uno, making it an excellent choice for this system. Several

tutorials on the device were also available, along with general tips and tricks in order to get

started.

Since there already were two terminations for CAN in the system, no termination resistor was

needed for the BJB. However, the cable from the BJB to the female DB9 connector still needed

to be twisted not to damage the CAN transmission. In the future, it would be possible to attach

more “batteries” to the BJB, but in such a case, resistor values and their capacity to dissipate

power would need to be overlooked. The finished system is pictured in figure 3:25 and 3:26.

Figure 3:25 The side view of the finished BJB

Chapter 3: Execution

40

Figure 3:26 The top view of the pre-charge circuit on the finished BJB

Due to a lack of time and logistic problems, the current shunt for measuring current and the

thermistor for monitoring the temperature of the battery could not be built as the parts had

not arrived yet. However, the necessary coding for them to work properly was still developed

to ensure an easier implementation of the devices in the future.

An enclosure was made for the BJB, consisting of a slightly taller box than for the boxes of the

other systems. This was due to the height of the system. Two holes were made for the battery

input from the CMU at the right side of the box, with grommets to protect the cables. At the

same side, a female DC plug was attached to provide power to the Arduino. The CAN input,

consisting of a DB9 connector was placed on the left side of the enclosure. A USB port to

enable communication between the BJB and a PC was also then added. The completed

enclosure for the BJB is illustrated in figure 3:27 and 3:28.

Figure 3:27 The left side of the enclosure for the BJB

Chapter 3: Execution

41

Figure 3:28 The right side of the enclosure for the BJB

3.5.4 Features

To prevent the system from taking unnecessary damage, some safety precautions needed to

be implemented. The relays could not be activated at the same time or be activated in any

order. To solve this, an order of executions was arranged, and a grouping of three tasks made

to eliminate the risk for that to happen.

The first task for the BJB if initiation of Drive Mode was made was to pre-charge the circuit.

The Main- and Pre+ relay would then close and thus charge the capacitor. Only when the relays

had been fully closed and the time of pre-charge expired, the second task could begin. The

purpose of the second task was to close the Main+ relay. When this relay had closed, current

would be flowing in the system, allowing the system to operate normally. The third and final

task was to open the Pre+ relay. After the Pre+ relay had opened, the system would be running

at its normal capacity and would be charged with the same voltage as the battery.

If this order of executions were to deviate, an error message would be sent, and all relays

opened to restrict current from flowing in the system. The full source code for this sequence

can be found in Appendix B5. In addition to this, four measurements needed to be made on

the BJB:

o A voltage measurement of the battery

o A voltage measurement of the system

o A current measurement of the system

o A temperature measurement of the battery

These measurements were continuously sent back to the BMU for it to evaluate the status of

the system.

Chapter 3: Execution

42

3.5.5 Programming

The libraries used to program the BMU were also utilized for the BJB, as the same add-on shield

for the CAN transmission was utilized. In order to sniff the CAN-bus, the software BUSMASTER

was used with the Peak CAN USB adapter for a connection to a PC. No library for the relay

shield needed to be added since the digital pins of the Arduino could be programmed to

control their operation.

The flow chart for the coding sequence used for the BJB can be read in figure 3:29.

Figure 3:29 The flow chart for the BJB

Chapter 3: Execution

43

In order to calculate the correct voltage from the voltage divider, formula (8) was applied. The

source code for this expression is illustrated in figure 3:30, where R11, R12, R21 and R21

represents the same resistors as the ones presented in the electrical schematic for the BJB.

The resistors were individually measured prior to being used to ensure that the output voltage

would be correct.

Figure 3:30 Calculation of the battery and system voltage

3.5.5.1 Construction of the outgoing CAN message

As explained in 3.2.4.2 Deconstruction of the incoming CAN messages, byte 0-1 of the message

from the BJB contained data of the battery voltage, byte 1-2 of the system voltage, byte 3-4 of

the system current, byte 5 of the battery temperature and byte 6 of the state of contactors.

The reasons for this were that the battery voltage, system voltage and system current could in

the future contain data up to 800V and 300A respectively, thus needing more than one byte

of allocation. One byte of data only offered data values up to 255.

To transmit the state of each individual contactor state in one byte, each contactor was

granted a different value. As the Main+ relay had bit order one, its value was set to “1” when

closed. The Main- relay had bit order two, so its value when closed was set to “2”. The Pre+

relay had lastly bit order three and was given a value of “4” when closed. This would total in a

value of “7”, if all contactors were to be closed and a value of “0” if all contactors were to be

opened.

The outgoing CAN message from the BJB is illustrated in figure 3:31. Its address was 0x630.

Figure 3:31 The outgoing CAN message from the BJB

Chapter 3: Execution

44

3.5.5.2 Deconstruction of the incoming CAN message

The incoming CAN message came from the BMU and contained information about the desired

values of the contactors. As in 3.5.5.1 Construction of the outgoing CAN message, each

contactor was granted a unique value.

The incoming CAN message from the BMU is presented in figure 3:32.

Figure 3:32 The incoming CAN message from the BMU

Chapter 3: Execution

45

3.6 Merge of the Four Subsystems

Before merging the subsystems into one, a wiring harness needed to be created to connect all

subsystems with each other. Then, the PEAK CAN adapter connected to a PC was added for

troubleshooting. The subsystems were then tested individually, and when the communication

between all systems worked, actual tests of the modes for the BMU begun.

3.6.1 The wiring harness

To improve the performance of the CAN communication, the wiring harness was made as

short as possible. This was done to limit possible external noise and disturbances from other

electronic devices. The harness consisted of three DB9 male connectors and one DB9 female

connector with the CAN HIGH and CAN LOW wires twisted between the connectors. Since

the terminations for the system already existed, no more termination resistors were added.

The finished wiring harness is shown in figure 3:33.

Figure 3:33 The wiring harness for the BMS

Chapter 3: Execution

46

3.6.2 Completion of the BMS

After connecting the BMS as in figure 3:34, one CAN message was first sent from the BMU in

order to see if the CAN transmission for the BMU and the CAN reception for all other

subsystems functioned correctly. Each system was then similarly tested one by one to ensure

normal operation. Since the BMU received four CAN messages total at the same time, a time

schedule for each CAN message needed to be added to avoid conflicts between the messages.

This is due to CAN only being half duplex. This procedure was also done for the CMU, as it

transmitted more than one message.

The communication between the CMU and the CAN/isoSPI translator had already been tested

and therefore did not need any modifications to function properly. When the communication

between all systems worked without problems, Drive Mode, the mode to Stop and the Extra

function was initiated on the BMU, although not at the same time. Values for battery voltage,

system voltage, system current, battery temperature and state of contactors were then at last

simulated outside their threshold by BUSMASTER to see if the error detection worked without

flaws. All modes functioned properly and are described in 4. Results.

Figure 3:34 The setup for the completed BMS

Chapter 4: Results

47

Chapter 4: Results

As the software development was one of the main focuses of this project, the results will consist of a

graphical interface between the user and the system as a whole. Achieved communication between

the subsystems has thereby been proven, and sufficient functionality reached.

The following chapters will describe each interaction and presentation of data between the user and

the BMS from the built-in console of Arduino IDE. All interactions were performed on the BMU as the

description of 1.2 Problem definition suggested.

Based on the event, one of three LED diodes on the BMU would shine if the system was trying to be

run. In figure 4:1-4:3, the illumination of the red, blue and green LED is illustrated respectively.

Figure 4:1 Illumination of the red LED

Figure 4:2 Illumination of the blue LED

Figure 4:3 Illumination of the green LED

Chapter 4: Results

48

4.1 The engage of Drive Mode

Before engaging Drive Mode, the CAN-bus was required to be initiated without errors. If the

initiation was OK, the message in figure 4:4 would be presented to the user.

Figure 4:4 A message to let the user know that the CAN initiation was OK

When CAN had been initiated correctly, the system properties described in 3.2.3 Features were

checked to be sure that they were within their limits. If the result turned out positive, pre-

charge could be initiated, and the user notified that it had been initiated. The blue LED would

then be illuminated. The message for this is illustrated in figure 4:5. The full source code for

the measurement conditions can be found in Appendix B4.

Figure 4:5 A message to let the user know that pre-charge was initiated

If the sequence for pre-charge passed without errors, Drive Mode could be engaged, enabling

the system to function properly. The green LED would then be illuminated. The message that

would then be presented to the user is presented in figure 4:6.

Figure 4:6 A message to let the user know that Drive Mode was engaged

Chapter 4: Results

49

4.2 The disengage of Drive Mode (Stop)

If the disengage of Drive Mode was requested, all contactors would be opened and the battery

would be disconnected, thus disconnecting the system in the process. This mode could be

initiated at any time and was required if any errors of the system occurred. If the disengage

was properly executed and the time to discharge the capacitor had passed, all LED diodes

would be turned off. The message to let the user know that Drive Mode had been disengaged

and that the system had stopped is pictured in figure 4:7.

Figure 4:7 The message to let the user know that the system had been stopped

If the switch to engage Drive Mode was still activated when trying to disengage, a warning

message to let the user know that it needed to be switched off was presented. Only when the

Drive Mode switch had been disengaged, the mode to stop could proceed. This message is

illustrated in figure 4:8.

Figure 4:8 The message to let the user know that Drive Mode needed to be disengaged before stopping

Chapter 4: Results

50

4.3 The engage of the Extra Function

An extra function was added for troubleshooting and to give a short overview of the system.

All obtained data from the BJB and CMU were here presented, granting access to the status of

the battery voltage, system voltage, system current, battery temperature, state of contactors

and the voltage of each individual cell. This function could be engaged at any time. A snapshot

from when the system was working at normal conditions and the Extra Function had been

engaged is pictured in figure 4:9.

As mentioned earlier, due to a lack of time and logistic problems, data from system current

and battery temperature could not be accessed as they were yet to be implemented.

Figure 4:9 A snapshot of the Extra function

Chapter 4: Results

51

4.4 Error Messages

Several error messages were made in case of possible failures in the system. The messages

could either come when the system already was running, during the engage of Drive Mode or

when the system was trying to engage Drive Mode. If an error would occur, the red LED would

be illuminated, and the blue or green LED switched off.

The representations of error messages from when the state of contactors, battery voltage or

the battery temperature were outside their limits and the user was trying to engage Drive

Mode are illustrated in figure 4:10-4:12 respectively. The full source code for the error

detection can be found in Appendix B2.

Figure 4:10 The message to let the user know that the battery was yet not disconnected

Figure 4:11 The message to let the user know that the battery voltage was outside limits

Figure 4:12 The message to let the user know that the battery temperature was outside limits

If pre-charge, the closing of the Main+ contactor or the disengage of pre-charge could not be

initiated, suggesting a fault in the communication between the BMU and BJB, a message

presented in figure 4:13 would appear. This message was caused by a communication timeout,

set to 10s.

Figure 4:13 The message to let the user know that the communication to the battery was not working

Chapter 4: Results

52

However, if pre-charge could not be disengaged, the system could still be connected and

power to the system could be active. According to NEVS if this scenario were to happen, for

some users, to allow the vehicle to still be drivable was preferred over not being able to drive

at all. The contactors would then remain the same and a message to warn the user then

printed, instead of an error message. This message is pictured in figure 4:14.

Figure 4:14 The message to warn the user that power to the system may be active

If data from the battery voltage, system voltage, system current or battery temperature would

be outside their limits when Drive Mode was engaged and the system was running, similar

error messages would also be printed. The battery would then be disconnected automatically

as a safety measure. The error messages if this were to happen are presented in figure 4:15-

4:18 respectively.

Figure 4:15 The message to let the user know that the battery voltage was outside limits and that the

system was stopping

Figure 4:16 The message to let the user know that the system voltage was outside limits and that the

system was stopping

Figure 4:17 The message to let the user know that the system current was outside limits and that the

system was stopping

Figure 4:18 The message to let the user know that the battery temperature was outside limits and that

the system was stopping

Chapter 5: Conclusions

53

Chapter 5: Conclusions

5.1 Final Conclusions

To summarize, a battery management system based on modular blocks has been made, with

the majority of requirements detailed in 1.2 Problem definition achieved. The main objectives

with the project have been fulfilled, and a useful playground for NEVS to continue work on has

been delivered. This system will become a key part in future development for NEVS, with many

plans connected to this system in particular. There are many things with this system that will

be improved on going forward, as BMS systems for Li-Ion batteries are complex with many

difficult challenges. However, the intent of this work was not to develop a fully functional BMS

with plug-and-play capabilities, but to develop a playground for continued development. The

development of a system that communicated between both CAN and isoSPI will only grant a

glimpse into the future, rather than operate as a functional, standardized product that could

be released to the market today. Therefore, the advantages of this modular system are that

more features easily can be added, and to combine the BMS with the VCU would in the future

allow a more customizable experience for the developer, which this system may enable.

To include a way to measure current and battery tempe