Modular Battery Management System interface to integrated Vehicle Control Unit: Creating a BMS playground using Arduino

Modular Battery Management System

interface to integrated Vehicle Control Unit

Creating a BMS playground using Arduino

Joel André

Karlstad University

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.

iv

Contents

Chapter 1: Introduction ... 1

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

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

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

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.

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

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.

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.

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.

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.

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

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.

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

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Ω.

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) and greater than 0.5V (>0.5V) to read the state as dominant. [10]

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.

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.

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.

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 (3)

Where V is the voltage of the battery.

The dissipated power of the resistor is:

𝑃𝑡𝑜𝑡= 𝐸

𝑇 (4)

The instantaneous power becomes:

𝑃 = 𝑉2

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:

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

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:

𝑉𝑂 = 𝑉𝑖𝑛( 𝑅₁

𝑅₁+𝑅₂) (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.

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.

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

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.

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.

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

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 [o_C]

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.

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.

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.

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

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"

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.

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.

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.

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.

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.

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.

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.

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

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 [𝑊]

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Ω.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.