Software block diagram

This page will describe the software block diagram of the nuttx example

Software block diagram

Figure 1 the software block diagram can be found. The BMS application consists of several tasks that run semi parallel (since it is still a single core processor). These tasks use functions from software components. The NuttX RTOS will take care of switching between tasks. The CLI part is called by calling the BMS application from the nuttshell interface with commands. The nuttshell is the serial (or UART) communication to the NuttX RTOS and can be used to communicate with the BMS application. The explanation of the blocks can be found in below in Component description.

Figure 1: Software block diagram

Component description

CLI

The command line interface (CLI) component takes care of communication with the user through the NuttX nutshell, it can be used during debugging of the smart battery application or a specific battery under test. The communication is mapped to use a universal asynchronous receiver-transmitter (UART) also known as the root console. The CLI can output messages in colors if the ANSI escape sequences are enabled in the terminal.

The application command may be followed by optional arguments such as:

· sleep

· deepsleep

· wake

· reset

· help

· show

· set

· get

With the set or get command the user can read and write every value, including the configuration parameter list. These values can be read/written by calling the BMS application followed by a set or get command followed by the name of the variable. In the case of a set command this would instead be followed by the new value of the variable. Try the command “bms help” to see the help of the CLI. For more information on using the parameters, see chapter https://app.gitbook.com/o/-L9GLsni4p7csCR7QCJ8/s/4sYITYOw8lqjlbpxfe9d/~/changes/1/software-guide-nuttx/untitled-1

DroneCAN / CyphalCAN

There can only be one of these two CAN components active at the same time, either the DroneCAN component or the CyphalCAN component. This can be set via the parameter “can-mode”. After setting this, do a “bms save” and a “reboot” to apply the change.

The DroneCAN module manages the DroneCAN communication as the name already suggested. There are 2 parts of this communication, the synchronous and the asynchronous communication. For that reason, there is a task running to take care of both communications.

The synchronous communication is the updates of the different battery information messages. This is done with a certain update rate, depending on the message. If the BMS measurement interval is more than 1 second, it will influence this as well. These messages can then be sent regularly to the DroneCAN bus. Other devices connected to this bus can then read the messages, these devices could for example be an FMU/VMU for a drone or rover or other devices. This update with new data gets triggered via the updater task.

The asynchronous communication is when another DroneCAN device on the DroneCAN bus is requesting data. This can be battery data or a BMS parameter. Or another DroneCAN device would like to change a parameter of the BMS. When this happens, it is not triggered by the updater task, but the DroneCAN task will take care of this.

For the CAN communication, it will use the CAN PHY in the SBC (UJA1169).

If configured corrected, you could see the battery information in PX4, ArduPilot or QGroundControl.

CyphalCAN is supported as well, please see chapter "CyphalCAN".

LED state

The LED state module can be used to control the RGB LED. It can set an RGB color on or off and blink the LEDs at given intervals. If a LED needs to blink a blinker task will be used to ensure it blinks. This module is used to inform the user visually of various states and status.

This part is used implement the LED states given below

State	LED state
Self-test	Red
Deep sleep	Off (after 1 second white LED on)
Sleep	Off
Wake-up	Green
Normal	Green blinking (with state indication) 1 blink 0-40% 2 blinks 40-60% 3 blinks 60-80% 4 blinks 80-100%
Fault_on (output power on)	Red
Fault_off (output power off)	Red blinking
Charging	Blue
Charging done	Green
Balancing/self-discharge	Blue blinking
Charger connected at startup	Red-blue blinking

SMBus

SMBus is an alternative way to communicate BMS information to a host device that has I2C, like an FMU/VMU. The BMS could be seen as an I2C peripheral device. Reading from specified BMS I2C registers allows the device to read BMS data. Data like voltages, temperatures, state of charge, average current could all be read from these registers. The SMBus needs to be enabled with the variable “smbus-enable” to work.

NFC - NTAG5

The NFC module manages NFC communication. NFC communication can be used to read all kind of battery parameters. Via NFC a device should be able to read the values with a refresh rate of once a second. The updater task will be used to update the data in the NTAG5 NFC device. It can operate in a similar manner to a double ported EEPROM, and NFC records can include standardized messages for HTTP or text records. In this way the NFC tag could be updated regularly with status information. That information could be added to text message, and for example a smartphone would be capable of reading the message with data attached, this is done with minimal coding effort. This method removes the need for any custom software on the reading device.

Authentication - A1007

The authentication module will take care of the authentication using the A1007 chip. The A1007 is capable of secure asymmetric key exchange and storage as well as secure monotonic counters and flags for use in such things as counting charge or discharge cycles or permanently flagging under-voltage or over-temperature conditions.

This component is not implemented yet. Only IC presence verification via I2C is implemented.

Display

The display module manages information presented on an optional local I2C LCD display (e.g. SSD1306 type). The display should be connected to J23. Both 3.3V and 5V are supported in the software. There is a framebuffer which makes sure the data is transferred to the display. Information like SoC, SoH, output status, BMS mode, battery voltage, average current, temperature and ID can be found on the display. This makes sure the user can easily see the battery information it needs.

Power (MCU power mode)

The power component is used to control the MCU power modes. There are 3 BMS application power modes that are made which each mode for its own purpose.

RUN mode

• RUN mode

  • In this mode, the MCU power mode is set to RUN mode. The MCU will run on an 80MHz clock. All needed peripherals are enabled.

  • This is the usual mode of the MCU.

• STANDBY mode

  • In this mode, the MCU power mode is set to (Very Low Power Run) VLPR mode. The MCU will run on an 2MHz clock. At this low clock speed, the BMS is saving a lot of power.

  • Both SPI modules and the serial interface (CLI) is active to still have communication with the BCC, SBC for the WD and potentially a user.

  • This mode is a lot slower, but it saves a lot of power while still maintaining a connection to be able to measure as well.

  • One use case of this mode is during the CHARGE-RELAXATION state. You need to monitor the voltages, but this does not need to be a fast loop as the power to the charger is disconnected and thus you make sure the cells are not drained as much as in the RUN mode.

• VLPR mode

  • In this mode, the MCU power mode is set to (Very Low Power Run) VLPR mode. The MCU will run on an 2MHz clock. At this low clock speed, the BMS is saving a lot of power.

  • Only the SBC SPI module and the serial interface (CLI) is active to still have communication with the SBC for the WD and potentially a user.

  • This mode is a lot slower, but it saves the most power. There is no monitoring of the battery. The MCU relies on an GPIO interrupt pin from the BCC for waking up.

  • One use case of this mode is during the SLEEP state. No power is drawn, and you want to drain the battery as little as possible, while still reacting on a use command to for example configure the BMS. If current is drawn, the mode will change to NORMAL or CHARGE and the MCU mode will change as well.

SBC (LDOs + CAN + W.D.) - UJA1169

The SBC module manages the power of the voltage regulators in the SBC. With this module the SBC can be set in normal mode, standby mode and sleep mode. In the normal mode both V1 (powers the MCU and more “VCC_3V3_SBC”) and V2 (powers internal CAN PHY and 5V “VCC_5V_SBC”) are powered. In standby mode, V2 is off and in sleep mode both regulators V1 and V2 are off. The sleep mode is needed for the DEEP SLEEP state. The SBC provides an external watchdog as well. The main loop will “kick” (reset) the watchdog at the end of the loop.

Bat management - MC33772B

The Bat management (battery management) part is the most important part, it will oversee the whole battery management. It will be used to monitor the battery, the PCB (temperatures) and calculate voltages, temperatures, current, SoC, SoH, average power and more. It will ensure the BCC chip (MC33772B) reacts if thresholds are exceeded. Functions of this part can be used to drive the gate driver IC, which allows it to disconnect or connect the battery from the BMS output power connector. Because this is such a large part of the system, the Bat management part has its own tasks. This task can not only utilize the functions in the batmanagement component, but has a configuration component to configure the BCC, a monitoring component to monitor the battery data and a balancing component to take care of balancing. All these components can access the BCC libraries. These libraries can access the NuttX drivers like the timers and the GPIO (reset BCC pin).

The batManag task will oversee the measurements and if triggered, it will do the calculations, check for errors, check for transition currents and handle the cell balancing / self-discharge. In the SW, the measured battery data and calculated battery data is put in two structs. It will save the newly made battery data and calculation data structs in the data part and trigger the updater task that there is new data available.

Data

Since different parts need to use the same data, a data library is made to take care of this. This library will make sure it is protected against usage at the “same” time by multiple tasks. If you set a parameter, it will make sure the system will act on it.