# Design of new EV control system (Inverter + ECU + peripherals)



## cts_casemod (Aug 23, 2012)

Hi folks,

As some of you, following my built thread, may know I am designing an inverter for a 3 phase induction motor.

Or at least that was the plan...

Right now the project evolved not to be a motor controller, but the complete vehicle management system.

So how does this relate to real life?

A main ECU controls parameters of the vehicle and, in general manages the whole setup.

Each battery (traction and auxiliary) is equipped with a smart battery monitor that reports, real time remaining capacity and battery status. The main ECU therefore controls the charging status and displays to the user.

The ECU can replace the cluster, if desired. It can calculate trip mileage, total mileage and display warning messages. It is equipped with an RFID style reader to unlock and start the Vehicle.
Brake lights engaged automatically when the vehicle is regenerating

There is provision for solid state controls to engage charger and DC-DC and I am working in a solid state battery contactor. This will allow over-current detection and hopefully save the burden of buying expensive DC fuses.

The inverter is based on a dspic33F operating on closed loop DTC. This works with ACIM motors. It can only work when matched with a valid ECU and Key

Maximum voltage will be 440VDC, to match most industrial equipment rated at this voltage.

Right now I would like to know any desirable features that you guys think, from a user point of view, could be nice to implement and perhaps get some help on bits here and there.

There is currently no individual battery protector/balancer. The battery protector does not check every individual cell, it does, however compare each battery block to find a possible faulty cell. 

Any advice or tips greatly welcome.


----------



## sergiu tofanel (Jan 13, 2014)

In real life, vehicle control functions are farmed out to different controllers that communicate via a CAN bus. While the dspic is a formidable microcontroller, it makes for a lousy computer because of all the extra hardware it needs. I would keep the design simple (motor control functions only), while building a separate module for the BMS. Auxiliary functions such as vehicle lock/unlock, HVAC, etc, can be delegated to yet another module. 

I believe that everything can be tied in together quite elegantly via a Raspberry Pi. It has plenty of computing power to manage everything and implement other features such as touch screen displays, wi-fi system access, and the graphically demanding instrument cluster display.


----------



## cts_casemod (Aug 23, 2012)

That's pretty much reassembles how the system works.
The dspic sits there all day drinking beer's and controlling the motor. Easy life. All the user interface and networking are managed by the ECU, which records vehicle mileage, gathers data from several sensors and warns the driver if any errors are found.
So in practice I can add slaves to the system that work independently (whatever they are intended to do) and report information to the master unit which can override certain things by user command.

CAN networking is great. But the price is a bit heavy when considering every nodule needs it's own hardware, many with required isolation.
So far I am having success with an I2C network. Relatively easy to isolate and many sensors can be commanded directly by the host CPU, bringing costs down considerably. It is, however possible that CAN can be implemented in the ECU itself to communicate with existing peripherals, but right now I have more on my plate that I can handle.
WiFi communication is not planned, but I have planned for an SMS server that can report things as battery charged, remaining time to complete charge, immobilize the vehicle remotely or track GPS position. For this same reason the ECU is powered at all times and needs to be capable of deep sleep operation.


----------



## eldis (Sep 3, 2013)

I would vote for the CAN bus. It's the best way how to interconnect modules in such environment, plus it implements prioritizing by default (lower address have the highest priority for transmitting). Therefore even 99% saturated EV data bus with tons of logging will be as responsive to important commands as if there would be nothing else on the bus. Bonus is that today almost any good MCU contains at least one HW CAN peripheral.

Actual implementation is also not so expensive, consisting only of two chips - CAN transceiver and 5V to 5V DC/DC module. the total cost will be like 10-20 dollars per module.

From my system:


----------



## cts_casemod (Aug 23, 2012)

Any code examples?

You only posted the isolator chip, which is cheap, I need some sort of Can to SPI converter to be able to use can with small microcontrollers. This is the main issue I am having right now. 
Only the PIC has a built in CAN peripheral.


----------



## eldis (Sep 3, 2013)

cts_casemod said:


> Any code examples?
> 
> You only posted the isolator chip, which is cheap, I need some sort of Can to SPI converter to be able to use can with small microcontrollers. This is the main issue I am having right now.
> Only the PIC has a built in CAN peripheral.


I have several modules with CAN built-in. Can't say much about PIC microcontrollers, as I'm not using them. The cheapest board with CAN on my table costs 13 dollars and is Cortex M4 from Texas Instruments:
http://www.ti.com/tool/ek-tm4c123gxl

Contains full USB debugger and all the pins are on pin headers (arduino-like). Considering the price of these boards, I resigned on putting a chip like that directly on a PCB and instead buy the kit and design a small pluggable "shield" that contains all the functionality I need (that board is then small and easy to make as well).

I don't see much of a point in posting a snipped of the code, as the CAN initialization is MCU-specific. If you will choose something like that later on, I can provide you with some examples. After you initialize your CAN peripheral, sending a packet is as easy as sending data to a serial port or I2C. Receiving as well.


----------



## sergiu tofanel (Jan 13, 2014)

A quick search reveals that there are several dsPIC's out there with CAN transceivers already built in. Most of these are priced in the $6-$10 range. So really, price and hardware are not the issue.

Quick question for cts casemod: when you say ECU, do you mean the existing Engine Control Unit from a donor car, or a custom built computer deigned to interface with the motor controller?


----------



## cts_casemod (Aug 23, 2012)

sergiu tofanel said:


> A quick search reveals that there are several dsPIC's out there with CAN transceivers already built in. Most of these are priced in the $6-$10 range. So really, price and hardware are not the issue.
> 
> Quick question for cts casemod: when you say ECU, do you mean the existing Engine Control Unit from a donor car, or a custom built computer deigned to interface with the motor controller?


A custom built computer deigned to interface, along other peripherals, with the motor controller. Check my built thread, on my signature, there are a few early versions of the system streaming data to a computer and a display. Perhaps I misleadingly assumed people would check that first, so I do apologize if my description is a bit misleading.

Right, I leave the CAN implementation to you guys, apparently its dead easy to implement, so it shouldn't be much of an hassle to interface to what I already have, which is brilliant.

The architecture I use, mostly is 8 bit AVR Series from atmel. I am not really familiar with most of the micro controllers stated. I own a nucleo, but I am not very happy with the arduino like environment, lack of debuggers, etc.

Atmel offerings are the AT90CANxxx and some Atmega32Mx with built in CAN peripheral I could evaluate. Sadly the Atmega32Mx are not available trough Farnell, so that leaves the AT90CANxxx locally available. This is the reason I would rather implement using an external IC trough the SPI bus, since I have a much wider range available.

But quite honestly there's not a lot of data going in an out to the motor controller. Its mainly just error messages or some startup information. The main computer takes care of checking currents, motor speed and other information directly from the sensors or from the battery monitor


----------



## cts_casemod (Aug 23, 2012)

Right,

So I have both an STM32F401 and an STM32F103 board right here with me. Guess we could work with this, each has a CAN peripheral.


----------



## eldis (Sep 3, 2013)

I think that project like this is rather ambitious. Before this thread overflows with small details of functionality we would like to see, it would be cool to take it from the top and work our way to the bottom.

Finding an answer to questions like:
- what kind of subsystems there are, can they work separately
- what do they do and need as inputs to operate
- is there a master system? Can modules talk to each other, thus bypassing the master?
- how is a system failure propagated? Common interlock system?
- Can existing solutions be easily integrated or do we want them to be? (BMS systems, original car systems)
- Logging, how complex, is there a unit collecting useful information and displaying it, or a PC/tablet going through all the packet on it's own?

As I am also designing everything from scratch, with some things already done while other in conceptual stage (my own induction/BLDC controller, high power charger, BMS system, instrumentation panel, logging, startup sequencing, error handling), I would be willing to cooperate and share results.

As a start, I can offer my BMS system, which we are currently prototyping. It is a semi-distributed system, with a CAN interface from the outside. It consists of two BQ76PL536A chips per board, each chip monitoring from 3 to 6 cells (so up to 12 cells per board). Each cell has individual balancing using MOSFET transistor and an SMD resistor as a load. There are two temperature probes per 6 cells. Top balancing.

These boards are then stackable using NORTH and SOUTH bus - an SPI interface that uses current instead of voltage to communicate, to overcome problem of different potentials between boards, without using any optocouplers. All the boards are the same. The southest chip on the southest board has a MCU module attached to it (using headers similar to Arduino). You can stack something like 190 cells in series using many boards. BQ76PL536A chips communicate to each other in the chain of current-based SPI, so the MCU has to talk only to one on the bottom (ground potential) and chips forward the messages between each other to create a large addressable space.

You might have seen this technology few weeks ago on the Tesla pack teardown pictures. I was really happy to see that Tesla is doing it the same way - it means it cannot be that bad approach 

I'm attaching some relevant slides from one of the presentations I've made about my electric Golf


----------



## dcb (Dec 5, 2009)

The thing about it is the most obvious items you would talk to use uart (60kw charger, various open source controllers) and so while CAN is nice, having a lot of uart ports makes it less of a "bring the mountain to mohammed" project. And if you work with open source projects you might be able to integrate a finer level of functionality.


----------



## eldis (Sep 3, 2013)

dcb said:


> The thing about it is the most obvious items you would talk to use uart (60kw charger, various open source controllers) and so while CAN is nice, having a lot of uart ports makes it less of a "bring the mountain to mohammed" project. And if you work with open source projects you might be able to integrate a finer level of functionality.


Do they use UART to communicate during run? Or just as a configuration interface?


----------



## dcb (Dec 5, 2009)

I don't know all the details of every controller, just saying that it seems a little premature to be focused on CAN so early in the discussion. A lot of things are just gonna be a voltage reading, some uart, maybe some i2c, who knows?

adding a central controller reminds me a lot of middleware, you don't rewrite all the mainfraimes, you work with what you've got. I wouldn't rule out intercepting throttle or other sensors personally.


----------



## cts_casemod (Aug 23, 2012)

It is indeed. Hard to immagine how long Ive spent with this. And that's why I am very reluctant on making any major changes like a change on the control CPU. I rather add whatever peripherals I need.

I am the kind that rather prefers to built everything from scratch than to use existing solutions, for example for the motor controller as I know exactly how they will work and most importantly what will be behaviours be in case of a failure. Otherwise I could just contact ST, get their motor control library and follow an automated process to get my chip programmed to do what I need. No programming skills required 
I've been told there is a similar system from Texas as well.

With this in mind the components work independently. The main unit will only relay information to the user and can partially communicate with the inverter, for example to request it to slow down in case of an under voltage.
The main unit has power to switch down any component on the network if it desires to do so, for example in the lack of communication. Ultimately it can also command the a full shutdown using the main contactor.
Systems like charger are controlled from the main computer given parameters from the battery control unit, although in the event of a fault I decided the system will give a safe timout to inform the driver and switch itself off. I don't really want to go trough the hassle of making the components communicate on their own without supervision.

I would be quite happy to interface your BMS to my existing controller and soc monitor which happens to be a TI part as well. Please do let me know how you are getting alone, prototyping wise. I was thinking in this same part anyway so I have a spare or two with me right now.

It is also interesting to point again that the main computer will be powered at all times in a deep sleep operation. So I have planed to interface this to a modem to get charging info or just in case I want to make an instantaneous battery check remotely.

Expandability, the system can be coded to add peripherals I can make some macros to enable or disable then, but at the end of the day it is a programmable device and I don't want to commit to any particular system. For example, if the user doesn't want to use a given controller and has a solitron or other type that uses a given interface then it will be possible to use that instead. I have a bunch of buses available on the main host: CAN, SPI, USART, TWI...

Data logging: I haven't found that to be a priority, but provisions are made to use SD Card storage for that purpose. In fact I am already using an SD Card for other purposes.


----------



## cts_casemod (Aug 23, 2012)

But to all the posters above, I already confirmed the main unit will be CAN enabled, I don't see why the fuss  The bus will be there to be used as required, what I don't agree from the first topic is to have every single component hanging on the can network. I have a pretty reliable TWI ( aka I2C) network communicating with a few peripherals that are I2C enabled and I don't see the point in interfacing that with a micro just to plug into the CAN network when I can rather speak directly with the device from the master unit. Its one less thing to code, add latency or malfunction. Just want to make this perfectly clear.

The other thing is, this is an embedded design. Users are free to change the code, but programming skills are required, so even tough the interface is there its not just a plug and play thing like a computer, nor do I want that.


----------



## eldis (Sep 3, 2013)

cts_casemod said:


> I have a pretty reliable TWI ( aka I2C) network communicating with a few peripherals that are I2C enabled


I have always wondered how well slow speed buses like I2C handle an environment with high switching noise of inverter operation. Since you're using it in your car, did you try to probe the bus during operation with an oscilloscope? How long cables are you using? Are they shielded?

For example in the industry it is common to use the current to communicate over a simple data link. One of the examples is 4-20mA current loop used by many sensors (usually connected to a PLC) http://en.wikipedia.org/wiki/Current_loop


----------



## cts_casemod (Aug 23, 2012)

All of my signals are generated from a current source. The throttle uses a 0 to 33mA current source since it is an analog signal. Anything below 5 mA and higher than 28mA is considered a fault.

For the I2C the main link uses a current source isolated bus. I tested operation at 400KHz without issues. The square wave looks fine as long as you don't try to use the signal from the micro to drive 20 peripherals without buffers.


----------



## dcb (Dec 5, 2009)

Thanks for the constant current signal tip, it may sound naive but I hadn't considered it before for yet another (distributed) bms project and it is solves a few concerns (and might be trivial to implement). So with it actively controlling hi and low current on the driver, it seems like it would have some noise suppression built in, no?


----------



## cts_casemod (Aug 23, 2012)

eldis, my latest acquisition is a BQ78350, you might want to have a look at that for your own purposes as well.

This is an integrated IC that does fuel gauging, cell protecting and balancing in one chip and LiFEPO4 chemistry is supported by default, returning accurate SoC readings. It conforms with the SMBUS protocol, so you can get some pretty standard information without much of a trouble. There is a set of universal commands for soc, voltage, etc.

One still has to implement isolation between modules, but hey, 15 cells covers a lot of work!


----------



## cts_casemod (Aug 23, 2012)

dcb said:


> Thanks for the constant current signal tip, it may sound naive but I hadn't considered it before for yet another (distributed) bms project and it is solves a few concerns (and might be trivial to implement). So with it actively controlling hi and low current on the driver, it seems like it would have some noise suppression built in, no?


Most definitively. My electronics are placed on top of the inverter and DC-BUS link, so there's a significant amount of noise.

For I2C, however you cannot control the low current, only the high. The devices pull the line low themselves, so you need to be careful about implementation, the buffer is bidirectional, so adds some complexities.

For analog signals and fully digital signals such as an encoder it is a no brainer. In fact not only the current source avoids noise and line capacity issues, but it can also be used by your host to detect a wiring failure, both short to VCC or GND. This is very good design practice in a harsh vehicle environment.


----------



## eldis (Sep 3, 2013)

cts_casemod said:


> eldis, my latest acquisition is a BQ78350, you might want to have a look at that for your own purposes as well.
> 
> This is an integrated IC that does fuel gauging, cell protecting and balancing in one chip and LiFEPO4 chemistry is supported by default, returning accurate SoC readings. It conforms with the SMBUS protocol, so you can get some pretty standard information without much of a trouble. There is a set of universal commands for soc, voltage, etc.
> 
> One still has to implement isolation between modules, but hey, 15 cells covers a lot of work!


Thanks for the info, I'll check it out later. From the first glance it seems to me that it only replaces the MCU (you still have to use one of the BQ chips to do the actual monitoring and balancing). It might be quite convenient to use on an e-bike or scooter, as it comes with coulomb counter etc. When you need a simple solution and don't want to program your own code for the BMS, it might be a good choice.


----------



## cts_casemod (Aug 23, 2012)

eldis said:


> Thanks for the info, I'll check it out later. From the first glance it seems to me that it only replaces the MCU (you still have to use one of the BQ chips to do the actual monitoring and balancing). It might be quite convenient to use on an e-bike or scooter, as it comes with coulomb counter etc. When you need a simple solution and don't want to program your own code for the BMS, it might be a good choice.


You still need the MCU to communicate with the SMBUS devices on the network and translate that to whatever interface you wish to use. CAN for example.

The chip is programmed just like any other, the SMBUS makes simpler to get some parameters such as SoC of battery voltage, for more advanced features like checking individual cell voltage the normal communication protocols apply


----------

