Battery Management System applied toProjecto FST’s EV prototype

Bruno SantosProjecto FST — Instituto Superior Técnico (IST)

1049-001 Lisbon, PortugalEmail: brunomanuelsantos@tecnico.ulisboa.pt

Abstract—This thesis has the purpose ofdesigning, building and testing a new Bat-tery Management System (BMS) for the re-cent electric prototypes designed by ProjectoFormula Student Técnico (Projecto FST), inparticular the current FST-05e and the futureFST-06e. The new design should accommodatecore changes in the technology used by theProjecto FST team in accordance with the ap-plicable rules from the Formula Student (FS)competition.

In both mentioned prototypes, the team de-veloped / is developing a battery powered Elec-tric Vehicle (EV) with a 600V battery of pouchlithium cells, but potentially different configura-tions — dependent on cell capacity and other carspecifications like battery geometry. With sucha sensitive system, the BMS needs to be veryreliable and safe, even in a noisy environmentand subject to vibrations as is the case of avehicle, even more due to the competition natureof the project. At the same time, the systemshould still fit the budget of the team as wellas comply with space (and weight) limits andprovide all the appropriate interfaces.

The solution presented here is a hybrid BMSwith modular and distributed features composedby one master module and several slave mod-ules communicating through a Controller AreaNetwork (CAN) bus. This system also allows formore than one battery container, therefore morethan one master module may be present in thecomplete system.

I. Introduction

Battery Management Systems (BMSs) havebeen a major factor in the successful integration ofbatteries in all sorts of applications. One such ap-plication is Electric Vehicles (EVs), which representa trend in environment friendly mobility.

These EVs have used several battery technolo-gies, usually requiring high voltage and capacityinstallations. Consequently, these are among themost challenging applications where performance isgreatly influenced by the battery technology in use.

With the greatest shortcoming of batteries be-ing the energy density, these impacts are seen ina significant weight increase for the powertrainsystem and reduced autonomy. Moreover, highvoltages present in these vehicles as well as thegeneral instability of current technologies introduce

a new paradigm in product reliability and longevity,but also passenger safety.

Indeed, the highest performing batterychemistries are the ones raising the greatestconcerns. These are lithium-ion batteries, whichexcel in energy density and discharge capabilities.However, these require constant monitoring toavoid early failures and thermal runaways. Failureto provide these monitoring devices on a per cellbasis may result in fires or even explosions.

The BMS proposed here targets a system wherehigh performance is a major concern. Naturally,it’s the lithium-ion family of batteries that are tar-geted. The application is electric Formula Student(FS) car prototypes developed by the FS teamfrom Instituto Superior Técnico (IST) — ProjectoFormula Student Técnico (Projecto FST).

Figure 1: Prototype FST-05e and Projecto FSTteam in Germany 2013. [Courtesy of Projecto FST]

A. MotivationFS is an international competition for university

students governed by institutions like Society ofAutomotive Engineers (SAE) and Institution ofMechanical Engineers (IMechE).

The goal is the design of a formula type car andcompeting, both in pitching design concepts andbusiness plans to a jury, building and racing forbest times and efficiency. For these competitions,Formula SAE (FSAE) issues the base set of regu-lations [1].

Throughout its history, FS has seen an increas-ing interest in alternative powertrains, and cur-rently combustion and electrical prototypes com-pete directly with each other.

In search for greater competitiveness, ProjectoFST saw a great departure from the FST-04e‘safe’ and ‘simple’ approach. Indeed, the successfulBMS developed for FST-04e [2] was deemed neitherappropriate, nor scalable for following prototypes.

In 2013, the team developed its second electricprototype, the FST-05e. This prototype faced sev-eral mechanical and electrical issues in 2013 season,not being able to run. One of the main issues wasthe inability of the in-house developed BMS toproperly monitor its battery.

This work was then coordinated to develop anew generation of BMS to avoid the same problemsin FST-06e, which should reach the testing phaseearly 2015. Additionally, the system would be pro-totyped in FST-05e, allowing its on-track debut inSilverstone, United Kingdom, in 2014.

Several commercial solutions exist, but, giventhe critical nature of this system and the expectedlevel of integration within the prototype, an in-house solution was proposed. More so, extendingthe know-how and usage of self-developed electron-ics and tools has long been a goal for Projecto FST.

B. Scope and objective

This work comprises the identification of theavailable technologies and an analysis regarding thebest architecture to comply with the team’s goals.The proposed solution is a digital distributed BMSwith one or more master modules, each controllinga set of slaves.

The integration of the system took place withinthe 2014 season time frame, in FST-05e. How-ever, this car posed certain design constraints thatneeded to be addressed and avoid compromising inFST-06e and future solutions at the same time.

More so, in favor of early integration and fasterdevelopment, the original master module was used.This module also provided some interfaces thatwere intended to be deprecated in the new design.However, all the electronics and software should bemade targeting an unification of these systems.

With this approach, and the tools developedthroughout this work, the new BMS should providea future proof solution for a broad range of batteryconfigurations. Additionally, a unified code baseand hardware development should yield a greatermaintainability and longevity of the prototypeswith great benefits to design iterations.

All the developed hardware and software ref-erenced throughout this document are hosted athttps://bitbucket.org/projectofst with the prefixesFST BMS and FST CAN tools.

C. The prototypes

One of the objectives of this BMS design is toprovide a scalable and generic solution in hardware

and software. However, it also targets a close in-teraction and integration within two specific proto-types: FST-05e and FST-06e.

Tables I and II resume some specifications foreach car. A noteworthy difference is the cell ar-rangement where these two solutions, while dif-ferent, only represent a small subset of possibleconfigurations in future designs1.

Table I: FST-05e battery specifications.

Parameter ValueMaximum voltage 600VNominal voltage 532.8V

Minimum voltage 432VMaximum peak current 630A

Main fuse current 100AMaximum charging current 18A

Capacity 9.5AhTotal energy 5.7 kWh

Total number of cells 288Cell configuration 144s2pNumber of stacks 6

Table II: FST-06e battery specifications.

Parameter ValueMaximum voltage 600VNominal voltage 532.8V

Minimum voltage 432VMaximum peak current 250A

Main fuse current 160AMaximum charging current 10A

Capacity 10AhTotal energy 6 kWh

Total number of cells 144Cell configuration 144s1pNumber of stacks 12 (2 containers)

II. Battery management systemThe proposed system is a distributed approach

where, optionally, more than one master shouldwork cooperatively. Each slave module monitor agroup of 12 cells and each master should supporta minimum of 12 slaves. This allows for greatscalability in a FS prototype, whose batteries havea maximum of 600V.

The slave modules are responsible for monit-oring each individual cell. This comprises voltagemeasurements, temperature measurements and bal-ancing. The master coordinates the slave modules,controls the availability of power and implementsprotective measures to prevent damage to theTractive System (TS).

The current of the battery is also measured bythe master module, but the balancing current mustbe accounted for by the slave modules. To commu-nicate with each other, the modules use an internalController Area Network (CAN) bus through agalvanic isolation that ensures complete isolation1 Battery configuration will be represented as XsYp, refer-ring to X cells in series and Y in parallel.

2

12× cell 12× cell 12× cell 12× cell

slave slave slave slave

Master Master

isolated CAN

internaldedicatedCAN

Container 1 Container 2

Figure 2: Proposed topology for new BMS in a 2container configuration.

between the TS and the low voltage system of thecar.

Table III summarizes the targeted specificationsfor each measurement subsystem. These specifica-tions were competitively set against FST-04e [2],commercial solutions [3; 4] and established prac-tices and recommendations as per [5] among others.

Table III: Measurement limits.

Parameter Valuemaximum 4.7Vminimum 1.6V

Voltage error 10mVchannels per cell 1frequency 1Hzmaximum 120 ◦Cminimum −30 ◦C

Temperature error 5 ◦Cchannels per cell 0.5frequency 0.2Hzmaximum 200A

Current minimum −50Aerror 5Afrequency 20Hz

For historical reasons, the proposed system hasthe versioning scheme v3.x and v4.x, for slave andmaster modules respectively. This is to denote anew iteration in the teams’ history rather thanany dependency or implied similarity with previousversions.

The tool used to develop both the master andslave modules was Altium Designer. Module pro-gramming was achieved through a PICkit™ 3 andthe IPE interface [6; 7].

The code is written mostly in C with a fewassembly calls, compiled through the XC16 C com-piler and MPASM™ assembler (free versions) [8; 9].Most embedded software is C90 compliant, butsome Microchip extensions and assembly macrosare used.A. Slave module

The slave is composed of a Microprocessor Unit(MPU) and a BMS Integrated Circuit (IC). To-gether, through an internal Serial Peripheral Inter-face (SPI) bus, they measure voltages and temper-atures.

The choice for an integrated solution for thevoltage measurements provides great compactnessand precision without calibration processes — oneof the most relevant drawbacks of the previoussystem.

DC/DC CAN

NTCs

Balancingload

LTC

Isolated (to master)

SPI

12cellarray

Slave module

NTCs

Ana

log

multip

lexer

dsPIC

Figure 3: Slave module architecture (FST-05e).

The chosen IC was the Linear TechnologyLTC6804, however, given its unavailability for theproduction time frame, the similar but lower per-forming LTC6803 was chosen [10]. Nevertheless,hereby referred to as LTC , this IC provides fast andaccurate voltage measurements and integrate thebalancing of the cells preventing balancing relatederrors in measurements.

As virtually all solutions on the market, theseICs offer very low support for temperature meas-urements. The industry accepts 2 to 3 sensors tomonitor a large pack of cells, but the same doesn’thappen in FS, where more strict rules apply.

For this reason cell temperatures are measuredthrough the MPU directly connected to an ar-ray of Negative Temperature Coefficient thermis-tors (NTCs). For monitoring its own state, theslave has 3 Surface Mounted Device (SMD) NTCsspread through its Printed Circuit Board (PCB).All these NTCs would require significant powerrequirements, thus being multiplexed and only one— if any — is active at any time.

These temperatures are directly monitored bythe MPU, a Microchip dsPIC30F6012A [11]. Thismodel, hereby referred to as dsPIC , was chosen forits extensive use within other modules of the car,and thus familiarity. Together with a high perform-ance level and plenty of memory, this allowed afaster development, but there are cheaper altern-atives that should require minimal adaptations.

Another important task of the slave modules isthe determination of State of Charge (SoC), i.e. theamount of ‘fuel’ left. This is a very complex task asthis parameter has a strong dependency with a vastnumber of variables. Not being an essential feature,and given limitations within FST-05e regardingcurrent intensity measurements, the proposed solu-

3

tion is very simple and only takes voltage intoaccount.

a) Layout:FST-05e had very strict requirements regarding

the layout of the slave module. For this reason, thenew module borrows its layout from the originalone, despite offering a different solution.

dsPIC

Balance load(12 channels)

Cells

NTCs

CAN bus

(a) Top layer.

Isolation barrier(both layers)

LTC

Tem

p.Mux

es

(b) Bottom layer.

Figure 4: Slave module v3.1 (FST-05e).

This solution still relies heavily on wire connec-tions to the cells and temperature sensors, resultof FST-05e design. For FST-06e however, severalsolutions were proposed to include the BMS designin the stack design (a subdivision of the battery).Figure 5 illustrates one such solution currentlybeing prototyped by Projecto FST.

This solution should provide easier assembly ofthe stack, more accurate readings and, above all,reliability and easier assemblage.

(a) Partial render of proposed stack solutionin exploded view.

(b) Early proof of concept. The slave moduleshould connect to the exposed part of the busbars.

Figure 5: FST-06e stack concept. [Courtesy of Pro-jecto FST]

b) Self checks:With the emphasis on safety, reliability and

advanced diagnosis, several safety features are im-plemented within the slave module, beyond theover/undervoltage or low/high temperature detec-tion.

These features detect software faults througha watchdog timer, cell connection faults and tem-perature sensor faults. More so, even embeddedsystems are part of intrinsic and regular sanitychecks that detect faults within the componentssoldered in the slave PCB.

The detection is made on a per connection, permodule way, which enables the slave module to pre-cisely report the nature and origin of the identifiedproblem. Indeed, the only fault not covered by theself diagnosis routines is a failure of the MPU itself.

This situation needs to be covered throughproper error handling within the master module.

4

3.4V 3.2V 3.6V 4.2V 4.0V 3.4V +−

Figure 6: Example of an unbalanced array of cells.

c) Balancing:Balancing is a universal problem for arrays of

batteries. An unmaintained battery may becomeunbalanced to the point where it no longer allowssafe charging or discharging.

To maximize the available capacity of a bat-tery, one of several balancing techniques may beemployed. There are two major approaches: passiveand active balancing.

For the system in question, an active balancingsolution has no advantage in terms of cost orperformance. Due to the fast discharge projectedeven for the longest event in FS — endurance eventof 22 km —, an active system wouldn’t provide anysignificant increase of range and would likely resultin a heavier and bulkier battery.

Therefore, for this application, a passive balan-cing system yielded better performance overall andit is also simpler and cheaper to implement. In theproposed system, the balancing is done through onebank of resistors per cell that dissipate excessiveenergy of the most charged cells. This is done solelyduring the charging process.

To improve the charging performance, balancingshould occur sooner rather than later. Otherwisethe charging current may need to be reduced whilemost (or any) cell is still significantly discharged.This logic is implemented by the slave module,which decides whether each cell should be balanced,and the master, which enables balancing only inspecific situations.

The balancing load may be used (or disabled)by the slaves in some emergency situations regard-less of the master’s commands. These exceptionsinclude safety precautions against any harmful situ-ation to the cells and the slave modules themselves.

Finally, to monitor all 12 channels with only2 temperature sensors, a heat sink needs to beinstalled for thermal coupling, which also servesthe purpose of improving heat dissipation and,therefore, balancing performance.

For FST-05e, the best option was a 1⁄4 bricklow profile heat sink, illustrated within a fullyassembled slave module in figure 7.

B. Master moduleThe master module was developed only as a new

software for the original master with proper proto-cols and error handling, the missing componentsof the previous design. Indeed, from an hardwarepoint of view, the original master was not verytechnological, but was mostly functional except forsome safety issues in the TS activation.

Figure 7: Slave module v3.1 (FST-05e) fitted witha low profile heat sink.

In a latter phase, a new module was designed.However, the software was developed with all thefeatures in mind and the MPU in the original mas-ter was the same dsPIC used in the slave modulesand in the new master. In fact, the new module wasdesigned to be a drop in replacement, but accountfor a richer feature set and better safety.

Because of time constraints, the new solutionhas not been prototyped completely — i.e. somehardware functions were not yet validated — normanufactured or deployed in any prototype. How-ever, other than the software routines and proto-cols, all following references to the master modulerefer to the new proposed solution.

The overall master architecture is representedin figure 8.

dsPIC

DC/DCCAN

NTCSD card

Isolated (to slaves)

2× SPI

Master module

RTCC

CANDC/DC

protection

Current

Pre/Discharge

sensor

Fan control

AIRs control

Backuppower

LDO

Voltagereference

Figure 8: Master module architecture.

d) Layout:The new module required a higher component

density than the previous one, yet it includes morefeatures. These are a Secure Digital card (SD card),a Real Time Clock & Calendar, extra headers andsupport for an extra safety feature for the pre-charge and discharge circuits.

This new master version is represented in figure9.

e) Network responsibilities:

5

NTC sensor

Pre/Dischargeprotection

AIRs and Fan control

Internal

CAN

andsupp

ly

SD card

RTCC

Externa

lCAN

dsPIC

Con

fig.jum

pers

Current

sensor

(a) Top layer.

Mounting holes Isolation barrier

(b) Bottom layer.

Figure 9: Render of master module v4.0.

The master module connects to two CAN buses.One is only shared with the slave modules forminga closed network.

In this network, the master is the sole respons-ible for querying the slave modules to preventfault cases in which the slaves would be unable toreport any emergency — e.g. a wire fault in theCAN bus. But it also needs to coordinate the slavemodules while charging to ensure all slave modulesare balancing towards a common goal rather thanjust balancing the cells under their supervision.

And finally, a SD card and a RTCC allow highercomplexity features to be implemented and eventlogging with time and date. RTCC functions mayalso be provided to other modules residing in theouter network.

Regarding multi-master topologies, the pro-posed solution is that one or more masters areslaves to another single master, configured througha set of jumpers. This avoids group decision trees

with race conditions and synchronization problems.To guarantee correct operation of the master

module, a watchdog enforces a complete reset of themodule triggering a fail-safe deactivation of the TSin case of software lockup. However, a ping systemis available and may be configured with any othermodule in the outer CAN bus with access to theTS safety circuit as, for instance, a second master.

f) Tractive system control:The master manages the availability of high

power from the battery through a pair of Accumu-lator Insulator Relays (AIRs). With these relays,the master can interrupt any discharge or chargebeyond the limits of the battery.

However, the control of the tractive system is asafety critical task. Namely its activation requiresa soft charge feature and rules mandate a fastdischarge as well.

Batterycontaine

r AIR+

AIR-

K1

K2

R

C

Figure 10: Pre-charge and discharge circuit. Allswitches represent relays controlled by the mastermodule.

If any of these circuits experience a failure, theTS may become damaged with varying levels ofdanger. This was an issue with the original mastermodule. The revised master should detect all failuremodes, but that requires some exterior hardware.

A complete solution was proposed taking ad-vantage of the already existing Tractive SystemActive Light (TSAL) module — another rule im-posed module, responsible for the detection of highvoltage in the TS. Two of these modules shouldbe installed in the car, one inside the battery tomonitor availability of high voltage at the batterypoles — as already required by the rules —, andthe second one across the resistor R (figure 10).

The outputs of both TSAL modules should thenbe available to the master.

III. CAN toolsTo interface with the BMS through a common

computer, a set of tools were developed. The firstone is a translator module capable of convertingCAN messages into Universal Serial Bus (USB) andvice versa.

The remaining tools are embedded in a softwarepackage that provide an interface to the translatorand high level interfaces to several modules. Among

6

these high level tools, only one was developed.This interface targets the BMS, providing severalcontrols and displaying several parameters fromwithin the BMS in a user-friendly manner.

This software package targets x86_64 Linux,making use of GNU is Not Unix (GNU) tool chain(gcc v4.8.3). Moreover, to provide a Graphical UserInterface (GUI), it’s used the Qt framework 5.3.2.

All code is C11 compliant C++.

A. CAN-USB translator

This module is a Módulo CAN PIC FST [12],extensively used by Projecto FST, with an embed-ded dsPIC . The focus was then on the software andintegration, rather than the hardware.

This translator introduces a major improvementrelative to previous translator units used by Pro-jecto FST: a binary frame.

The previous solution used American StandardCode for Information Interchange (ASCII) encod-ing for their messages. While significantly simplerto develop, this imposes a significant overhead andbandwidth penalty, leading to less than 50 messagesper second against the maximum of ∼=6200 (CANbus 80% full).

Figure 11: Translator module. Left connector con-nects to CAN and the right one to USB; LightEmitting Devices (LEDs) indicate bus activity.

Together with the new hardware and a bufferimplementation, the new translator unit is capableof handling upwards of 3000 messages per secondand even higher rates in small bursts of messages.

A binary frame requires the usage of a CyclicRedundancy Check (CRC) for message consistencyand identification. This CRC is in fact one ofthe greatest performance limiting factors and paidversions of the Microchip compilers could introducesignificant improvements through optimizations.Nevertheless, this dsPIC is still able to doubleits current frequency, effectively halving the timerequired for CRC calculation and duplicating thebaudrate of the serial connection.

B. FST CAN interface

The underlying functionality of the interfaceand the translator are not tied to the BMS andshould then be made as generic and extensible aspossible. Figure 12 shows the architecture for thisinterface, where grayed out modules were not rel-evant for the objectives of this thesis, and thereforenot developed, but still accounted for in the design.

Console Battery moduleOther

interactivemodules

Input/outputmux

Temporalanalysismodules

Database

USBOtherdevicese.g. WiFi

Figure 12: FST CAN interface architecture. Blueblocks correspond to GUI interfaces. Grayed outblocks represent features not implemented.

g) Console module:The console GUI module is represented in fig-

ure 13. This module allows to input and receiveany CAN message without distinguishing betweensenders or purposes. For this reason, the consoleis particularly appropriate for early development,debug unpredicted situations and test newly addedfeatures.

Figure 13: Console tab of FST CAN interface.

h) Battery module:Unlike the console, the battery module has

knowledge of the message format, codes and pro-tocols. This allows it to represent BMS relatedinformation in an easy to read interface.

This module, illustrated in figure 14, has a maininterface that functions as a control panel. Here,only broad information is given to the user, but anoptional interface may be activated to show detailsof every cell being monitored, including any wirefaults or lack thereof.

To prevent the display of outdated informationand detect the battery has gone offline, this moduleimplements a series of watchdog timers that clearthe output.

7

Figure 14: Battery module of FST CAN interface.Screenshots taken at different times. Small windowhas a scrolling area showing all slave modules andnot just one.

In the image, the background window shows thebattery completely charged, just before the auto-matic cutoff by the master module. The window inthe foreground shows the detailed information forone slave in a previous, uncharged and unbalanced,stage.

IV. Tests and deplymentThe first milestone for the manufacture phase

of this BMS was the completion of the slave mod-ule. This module was first prototyped in-house inIST Taguspark facilities. The resulting module isillustrated in figure 15.

This phase consisted in a verification of designspecifications and the rigorous test of each func-tionality. With this prototype, all the hardwarecomponents were verified to be working as expected

Figure 15: Prototype slave v3.0 top layer.

and a few revisions were made prior to send forproduction.

The protocols between slave and master werealso set and enforced still before the installationwithin FST-05e. The majority of features and allthe safety check were implemented as well.

After scaling the system with one master andtwo slaves, the system was installed within thebattery of the fifth prototype for the next phaseof tests and development.A. Deployment

The fully assembled system is shown in figure16. From this point onwards, feature implementa-tion became a second priority with stability, safetyand reliability being the main issues. This was inpart due to tests that required a fully installedbattery, including tests on track. This goal was wellbalanced with the integration of the higher levelinterface.

The system demonstrated great stability afterinitial sensitivity issues. In fact, most problemswithin the battery container were soon result ofinstallation problems related to the dependency onwires and stack assemblage difficulty rather thanBMS related.

Figure 16: FST-05e fully assembled batterywithout lid. Connector on the left of the middlesection is low voltage only. Connector to the rightis for high voltage and current.

The BMS error handling proved to be essentialin the early integration process. The 300 wiresconnecting the slaves to the cells and respectivesensors proved to be a major source of early BMSfaults. However, the BMS was consistently able toidentify which wire(s) needed to be replaced.

Using the v3.4 hardware rather than the revisedv4.0, the master was also able to handle the 12slaves comfortably and assure the safe operation ofthe battery.

Finally, the British competition was an import-ant goal. Despite several successful tests prior tothe competition, mechanical and electric problemsplayed a huge role in a rather unsuccessful competi-tion in its dynamic events. Indeed, the car only took

8

Figure 17: Manuel Ferreira driving FST-05e in en-durance event, Silverstone, FSUK2014. [Courtesyof Projecto FST]

part in the endurance event — the most difficult tofinish — and only completed a handful of laps.

One of the problems was found within the bat-tery itself. Improper handling and assemblage ofthe cells are suspected to be the cause of the earlyfailure of the battery. The cell capability to retainenergy was severely damaged as a result.

More so, these cells were installed for the 2013season and never fully used given BMS problems,but they were also largely unmaintained as well.Therefore, it’s difficult to pinpoint the cause for thereduced lifespan of the battery.

Because of financial constraints, rebuilding abattery with all new cells was not feasible, but sincethe competition, the battery was rebuilt with thefew spare cells which only allowed a configurationof 144s1p. Therefore, the battery has currently halfthe design specified capacity, but the extra spacewithin the container also allowed to solve some ofthe assemblage problems of the previous solution.

Indeed, the battery is now proving to be moreconsistent and is expected to allow extensive teststo FST-05e, invaluable for the design of new pro-totypes.

V. ConclusionThis thesis addresses the problem of battery

management within a high performance vehiclewith a partially distributed solution. Most of theobjectives were indeed fully addressed, providing astable, safe and accurate system.

On one hand, these installation issues are highlydependent in a new battery design and not only ina new BMS architecture. On the other hand, boththe charger and better performance parameters likethe SoC had to be sacrificed given the large scope ofthe project. However, in a fast paced environmentlike FS, priority was rightfully given to the actualtesting, safety and stability of the car.

The final solution is not at feature parity with

commercial solutions just yet, but clearly has allthe capabilities to do so. Weighting in the verycompetitive cost of the proposed system, and theversatility it offers when compared with the samecommercial solutions, the proposed system becomesmore attractive.

Opportunities for improvements to achieve thisfeature parity (and even surpass it) were found allaround, which is not surprising given the broadscope of the project. However, the most relev-ant directions seem to be in SoC estimation al-gorithms. For better performance, greater integra-tion of mechanical design seems to be the greatestchallenge and FST-06e should be a step closer to adefinite solution.

On a competition perspective, the recovery ofFST-05e has been a difficult process with a myriadof mechanical and electrical problems, mainly Elec-tromagnetic Interference (EMI) related. This pre-vented a better performance in FSUK2014, buteach failure proved to be an invaluable lesson, alsoreflected in the proposed system.

Finally, tests proved quality assurance and goodmechanical design to be the main priorities in abattery design as no BMS system is able to replacethese. It can help however.

References[1] SAE, “2014 Formula SAE Rules,” 2014.[2] M. Guedes, “Battery Management System for

Formula Student,” Master’s thesis, InstitutoSuperior Técnico, 2011.

[3] elithion, “Lithiumate™ pro Product technicalinformation,” 2014.

[4] LION E-Mobility AG, “LION Smart Li-BMSv3 — Allgemeine Beschreibung des mod-ularen Batterie-Management-Systems,” tech.rep., LION E-Mobility AG, 2014.

[5] D. Andrea, Battery Management Systems forLarge Lithium Ion Battery Packs. ArtechHouse, 1st ed., 2010.

[6] Microchip, PICkit™ 3 Progammer/DebuggerUsers’ Guide, 2010.

[7] Microchip, Integrated Programming Environ-ment (IPE) Users’ Guide, 2013.

[8] Microchip, MPLAB XC16 C Compiler Users’Guide, 2013.

[9] Microchip, MPASM™ Assembler, MPLINK™Object Linker, MPLIB™ Object LibrarianUser’s Guide, 2013.

[10] Linear Technology, LTC6803-2/LTC6803-4Multicell Battery Stack Monitor, 2011.

[11] Microchip, dsPIC30F Family ReferenceManual, 2006.

[12] V. Almeida, “Volante Electrónico para oFST,” Master’s thesis, Instituto Superior Téc-nico, 2009.

9