Page Comparison

Outline

You'll learn This covers the basics of how a solar car's electrical system and how we've approached these challenges. This includes:

...

A solar car's electrical system involves a number of different sub-systems that are each responsible for a different task.

• Solar
  • Photovoltaic (PV) array: Collects energy from the sun and is our primary source of power
  • Maximum Power Point Tracker (MPPT): Maximizes the array's output and matches the battery voltage
• Motor
  • Motors: Generally special high-efficiency direct-drive brushless DC (BLDC) motors; responsible for actually moving the car
  • Motor Controllers: Generates the electrical pulses in the correct order required to drive the motors
  • Precharge Controllers: Precharges and discharges the capacitors in the motor controllers to prevent arcing and shocks
• Battery
  • Battery Pack: Stores and outputs energy; extremely dangerous
  • Battery Management System (BMS): Monitors the voltage, temperature, and current of the battery pack, ensuring that it stays within safe operating ranges
• Power Distribution: Handles low-voltage (LV) and high-voltage (HV) power rails; responsible for ensuring power is distributed properly and safely
• Driver Controls
  • Lights: Handles all lights in and on the car
  • Driver Input: Reads switches, buttons, and pedals and notifies the appropriate system
  • Dashboard: Displays information for the driver such as speed and battery status
• Controller Area Network (CAN) bus: Automotive communication protocol; the network that systems communicate with each other over
• Telemetry: Collects and transmits data from the car to an external receiver for remote monitoring

...

Finally, the car produces and processes a lot of data. That data is collected and transmitted to an external receiver, allowing us to monitor the car without plugging into it. In addition, we can process the data more efficiently and look at long-term trends to optimize driving habits.

Controller Area Network (CAN)

CAN is the system that ties the entire car together. Without CAN, our systems wouldn't be able to talk to each other, rendering them useless. It's like a LAN network, but for cars. For more information on the protocol, the Wikipedia article is pretty good.

CAN was designed as an automotive communications protocol, so it's very robust and great for our purposes. It defines both physical and low-level standards, allowing us to define our own high-level protocol on top of the barebones protocol provided. The protocol is designed for sensor networks, where each node broadcasts data autonomously and doesn't really care if that data was received.

Overview

For normal high-speed CAN, the following core concepts are defined:

• Differential signalling: We use the difference between the values of a balanced pair to represent our logic values, improving noise immunity and the ability to handle different grounds or logic voltages.
• Linear bus topology: A CAN bus should be linear with short stub nodes along the bus and an end node at each end, usually terminated with 120 ohm resistors.
• Message-based broadcast: Data is broadcasted to the entire network as fixed-length packets where the ID determines its priority.
• Multi-master bus: All nodes act as masters and do not distinguish between specific message sources or destinations.
• Error detection: CRCs are used to verify message integrity and error frames alert nodes of network errors.

As far as we're concerned, a CAN frame consists of an identifier and up to 8 bytes of data. The rest of the frame is actually used for things such as a data checksum and control bits, but we don't need to worry about them.

There are two types of identifiers, standard (11 bits) and extended (29 bits). The lower the ID, the higher the priority. This is accomplished through the concept of "dominant" (logic 0) bits where the differential is actively driven apart and "recessive" (logic 1) bits where the differential is returned to around 0V. From Wikipedia:

The CAN specifications use the terms "dominant" bits and "recessive" bits where dominant is a logical 0 (actively driven to a voltage by the transmitter) and recessive is a logical 1 (passively returned to a voltage by a resistor). The idle state is represented by the recessive level (Logical 1). If one node transmits a dominant bit and another node transmits a recessive bit then there is a collision and the dominant bit "wins". This means there is no delay to the higher-priority message, and the node transmitting the lower priority message automatically attempts to re-transmit six bit clocks after the end of the dominant message. This makes CAN very suitable as a real time prioritized communications system.

High-Level Protocol

We've defined our own high-level protocol for MSXII by dividing the standard identifier into message ID, type, and source device. The general idea behind our protocol is to take advantage of CAN's broadcast-based system and have nodes perform actions based on the messages that they receive, regardless of the source device. By defining the message ID in the most significant bits and the source device in the least significant bits, the source device has almost no effect on the frame priority. Since that information is transmitted mostly for telemetry, our chunking accurately reflects the effect each field should have on a frame's priority.

...

One option we're currently exploring is using the remote transmission request (RTR) bit to represent ACKs. Unfortunately, the CAN standard defines frames with the RTR bit set as remote frames. These frames are used to request data to be sent to a destination device and do not contain data fields. Instead, the data length code (DLC) represents the data length of the expected response. Using the RTR bit to represent ACKs would be misusing the protocol.

Power

Power distribution is one of the most important systems, ensuring that power gets to where it needs to safely. In the case of a fault (killswitch or BPS), it disconnects the entire HV bus, isolating the battery pack. In MSXII, we have 2 main DC buses, an LV bus for powering boards at around 12V and an HV bus for powering the motors and receiving power from the solar array at around 130V.

LV Power

Our LV bus is powered from two sources, directly from the main battery pack through a DC-DC converter and a supplementary battery. Since our supplementary battery is necessary for starting the car and handling faults where it isn't safe to use the main battery, we try to avoid the use of the supplementary battery whenever possible.

Thus, we define two types of LV rails:

• Protected: Powered off of the DC-DC when possible, but falls back to the supplementary battery when necessary
• Unprotected: Powered solely off of the DC-DC

Critical systems that must be active when the car is off or in a fault condition such as power distribution or the BMS are powered off of a protected rail. On the other hand, non-critical systems such as the cameras or motor controllers do not need to be active and are thus powered off of an unprotected rail. In our case, we enforce these rails in hardware, simplifying the firmware and ensuring that non-critical systems can't be powered from the supplementary battery by accident.

HV Power

Our HV bus comprises of the main battery pack, the solar array and associated MPPTs, and motors and motor controllers. We control the power distribution between these systems through the use of special high-voltage relays, allowing our LV boards to control the HV bus. Note that all of our relays are electromechanical normally-open (NO) relays so they fail open.

• Battery relay: Connects the battery pack to the rest of the HV bus
• Solar relay: Connects the MPPTs (and thus the array) to the rest of the HV bus
• Motor relays: Connects the motor controllers (and thus the motors) to the rest of the HV bus

For safety, each relay's coil is connected to a multi-pole relay that is powered through a latching killswitch. This means that if the killswitch is hit, all relays will immediately lose power and disconnect, isolating each HV system. If a fault is read over the CAN bus, the coils can be unpowered through the power distribution board, providing the same result. For additional safety, we expect all critical systems to continuously broadcast a heartbeat packet. If any system's heartbeat packet is missed more than once in a row, we consider that a fault condition and isolate the HV bus. This also protects us from possible instability in the CAN network, ensuring that we never miss a critical message.

Motor System

The motor system encompasses the motors, motor controllers, and precharge controllers. We use two high-efficiency BLDC motors (NGM SC-M150s) to make the car move. We have off-the-shelf motor controllers that explicitly support these motors (Tritium WaveSculptor 20s) and handle the extremely complex work of safely converting the HV DC bus into a 3-phase output to drive the motors. Our motors are the primary consumers of power in our car and set the target bounds of our HV bus.

BLDC Motors and Motor Controllers

The operating principle behind any electric motor is the use of electromagnets to attract or repel permanent magnets in such a way that an axle spins. A brushless DC motor relies on electronically controlled phases to switch alternating windings of the motor, removing the need for a commutator. For a decent explanation on how a BLDC works, see this video. This results in a high-efficiency, reliable motor that just requires a separate controller to drive. Although the basic idea is relatively simple, motor controllers like the ones we use can be extremely complex, supporting both sensor and sensorless drive modes, built-in buck and boost converters, and DSP/PID algorithms for speed control.

In addition to the ability to cause the motor to spin by providing power to it, we can use it as a generator to slow the car down. By converting the kinetic energy of the rotating wheel to electrical energy through the reversal of current in the motor, we can recover some energy and charge our battery pack. This is known as regenerative braking, and it's a bit more efficient than traditional friction-based mechanical braking. This is the secondary source of power for our battery pack, but we need to be very careful with how much power we recover from regenerative braking so we don't damage our pack.

Precharge Controllers

Our motor controllers contain large capacitors in their HV input circuit, requiring precharge and discharge circuits to safely charge and discharge the capacitors.

The idea behind a precharge circuit is that when a capacitor is connected to a DC source, the capacitor starts charging with a huge inrush current that decays exponentially to a more reasonable amount. Since we use HV relays to connect the motor controllers to the main HV bus, the combination of high voltage and high current can cause arcing to occur within the relay, damaging the contacts and possibly welding them together. A precharge circuit uses a power resistor to limit the maximum current until the capacitor is charged to around 95% of the main HV bus voltage before closing the HV relay. This prevents the relay from being damaged and keeps the system safe.

When we want to turn the car off, the capacitors present in our motor controllers continue to retain their charge. This is a major shock hazard, so we employ the use of a discharge circuit that essentially places a power resistor across the capacitor, discharging it to a safe voltage.

For MSXII, we've designed an analog precharge/discharge controller that handles motor controller precharge and discharge automatically. The controller expects a 12V input that is its sole power source and represents whether the motor controllers should be charged or discharged. When unpowered, it enters the discharge state so any faults will result in immediate isolation and discharge the motor controllers to a safe working voltage.

Motor Controller Interface

As one of the few off-the-shelf components in our electrical system, our motor controllers define a high-level CAN protocol to use for controlling them. Unfortunately, their protocol does not work with our defined protocol, and so we require a motor controller interface board that translates our protocol into their drive commands.

This also allows us to isolate the motor controllers on their own CAN bus, preventing them from interfering with our main system CAN bus. We can also operate the motor CAN bus at a different network speed and implement dedicated control algorithms.

Battery

Our main HV battery pack buffers energy from the solar array and powers the motors. We build our own packs using hundreds of lithium-ion cells. Currently, we're using lithium nickel manganese cobalt oxide (NMC) 18650s, which give us the best combination of energy density, maximum discharge rate, and price. 18650 is just a term for a cylindrical cell that measures around 18.6mm x 65mm.

In order to assemble our pack, we purchase individual 18650 cells. We use Panasonic NCR18650Bs, which have a nominal voltage of 3.7V and a capacity of 3400mAh. Then, we assemble these cells in parallel to form modules or strings. Putting cells in parallel increases the capacity and maximum discharge rate of the assembled module, but each module still has a nominal 3.7V. To raise the voltage to our operating voltage, we place modules in series to form the bare battery pack. These assembled packs are normally denoted by the number of cells in series and parallel. For example, our pack in MSXII is designed to contain 1296 cells with 36 cells per module and 36 modules in series. This is referred to as a 36s36p pack. Note that it is critical that cells of the same capacity and chemistry are used, and that all modules contain the same number of cells in parallel. We want all cells to experience the same load, and the overall performance of the pack is only as good as that of its weakest cell.

When building our pack, we need to ensure that cells are balanced and matched. Matched cells refer to those which exhibit the same characteristics such as internal resistance and capacity. Cells are balanced when they are at the same voltage. When cells are connected in parallel, they automatically self-balance since the parallel connection keeps them all at the same voltage and always allows charge to be moved between them. However, when they are in series, if improperly matched or unbalanced, some cells become overstressed, diminishing their capacity and limiting the overall performance of the pack. To combat this, there are a number of cell balancing strategies.

• Passive balancing: Excess energy is removed from cells with the highest charge through a bypass resistor until their voltage matches that of the weaker cells. Although this method is cheap and relatively simple, it is very slow and just burns excess energy, limiting the pack's performance.
• Active balancing: Excess energy is moved from cells with higher charge to those with lower charge, usually through the use of a capacitor or inductor. This approach is much more efficient, but is much more complex and expensive.

Unbalanced cells affect the lifespan and maximum performance of the overall pack, with weaker cells getting worse the more the battery is cycled. Based on the relatively short required lifespan and minimal number of cycles required of our battery packs, we have decided to focus on building a matched battery pack and periodically balancing the pack over integrating a complex cell balancing system into our BMS.

Battery Monitoring System (BMS)

We like lithium-ion for its energy density, but the factors that make it so appealing also make it extremely dangerous. Lithium-ion cells are highly susceptible to something called thermal runaway if overheated or overcharged, where internal damage causes the cell to become thermally unstable. The resulting high heat of the failing cell can propagate to neighboring cells, causing it to become thermally unstable, creating an uncontrollable positive feedback loop. This can quickly result in a massive battery fire that releases toxic fumes and is very difficult to extinguish.

To keep our pack safe, we monitor a number of variables in the pack:

• Over/Under-voltage: Each cell must stay within its safe operating voltage. Too low and we cause irreversible damage to the electrodes, permanently reducing its capacity. Too high and we risk thermal runaway in addition to electrode damage. We monitor each module individually and normally try to keep them between 3.0V and 4.2V.
• Over current: Drawing too much current or overcharging can cause thermal runaway and reduces the capacity of the pack.
• Over/Under-temperature: Lithium-ion cells operate optimally within a certain temperature range. Too cold and we lose capacity and risk electrode damage. Too hot, and we risk thermal runaway. We monitor the temperature of the cells to watch out for thermal trends.

We cannot directly map a lithium-ion battery's voltage to remaining life, especially since they have non-linear charge and discharge curves. Instead, we monitor the battery's state of charge (SOC), which is defined as the available capacity as a percentage of either its rated or maximum effective capacity. This is a relatively arbitrary measure without units. There are a number of different methods of SOC estimation:

• Voltage-based: Given charge and discharge curves at a specific load, we can map the current battery voltage to its SOC. This works relatively well if our load is around that of the load at curve generation, but generally fails to take temperature, age, and measurement error into account. This is a concern because applying a load can cause the battery voltage to drop and certain parts of lithium-ion charge and discharge curves are very flat. Unfortunately, the load in an electric vehicle is typically anything but constant.
• Current-based (Coulomb Counting): By integrating the current flow over time, we can calculate the charge transferred in and out of the pack. We can then subtract the charge transferred from the total charge of a fully charged pack to obtain the SOC. This is more accurate than voltage-based SOC estimation, but requires a reference point and is suspectible to accumulated measurement error.
• Internal Impedence: The internal impedence of the cell can be measured and used to estimate the SOC. This is extremely difficult, but ASICs have been designed to interpret the data.

Our planned SOC algorithm primarly uses current-based SOC estimation to handle the large changes in current due to acceleration and regenerative braking. When the current flow is relatively stable or minimal current is flowing, we can use voltage-based SOC estimation to re-calibrate the SOC and set the reference point for current-based SOC estimation to continue from.

Solar

Solar cells, or photovoltaic (PV) cells, directly convert photons from the sun into electrical energy. Our solar array consists of a number of solar modules comprising of solar cells, similarly to how a battery pack is built.