Hardware-in-the-Loop Simulation of a Controller Area Network-Based Battery Management System for Electric-Powered Emergency Response Boats ^†

Abstract

We developed a hardware-in-the-loop simulation of a battery management system (BMS) using controller area network (CAN) as the communication backbone for electric-powered response boats in flood rescue. A LiFePO4 pack and discharge motor/charger were modeled in MATLAB/Simulink/Simscape, while an STM32 Nucleo-F446RE executed CAN messaging. The BMS monitored voltage, current, temperature, and state of charge. Results indicate CAN’s reliability under rescue-like disturbances: priority arbitration delivered over-temperature and over-current warnings ahead of routine telemetry; error detection and retransmission preserved data integrity; and bus-load analysis showed low latency for urgent frames without interrupting state-of-charge reporting, improving situational awareness and reducing operator risk.

1. Introduction

The archipelagic geography of the Philippines and its recurring flood events create operating conditions in which small crafts must navigate narrow waterways, submerged streets, and debris-laden channels. The increasing frequency of super typhoons, increasing by 106% since 1993, combined with continuous sea level rise due to climate change, underscores the urgent need to explore enhanced flood response measures [1]. Although conventional outboard engines remain standard, electrified small crafts are investigated for their potential to improve handling, responsiveness, and mission readiness, provided that their reliability can be convincingly established. On such platforms, the battery management system (BMS) and its controller area network (CAN) communication links are essential to operational safety. CAN communication reduces wiring requirements, provides transparency, and enables instantaneous message signaling, thereby strengthening system reliability [2].

Simulations and hardware-in-the-loop (HIL) testing enable the evaluation of BMS-over-CAN reliability. Simulations are conducted to monitor battery conditions, specifically cell voltages, pack voltage, current, and temperature, under load profiles representative of boat usage. They generate protection flags and status information for CAN messaging, including over-voltage, under-voltage, over-temperature, over-current, and imbalance states. By constraining the scope to battery-related variables and explicit flags, the simulations produce signals that map directly to operational decisions and can be verified without ambiguity in subsequent tests.

Simulations are essential to BMS testing, and MATrix LABoratory (MATLAB) is employed to assess system accuracy and reliability before real-world application [3]. HIL testing preserves real-time bus timing, arbitration, and error handling, enabling verification that life-safety frames meet timing budgets under congestion while allowing direct observation of end-to-end latency, jitter, and error-confinement behavior. Moreover, HIL yields traceable artifacts, such as time-stamped flags, identifiers, and scaling, that support repeatability and regression checks, which are often missed in conventional bench tests. We developed a reliability-centric perspective on CAN-based BMS communication for exploratory electric rescue craft in the Philippines, integrating simulations and HIL to ensure observability, fault tolerance, and predictable coordination among the battery, contactors, and drive electronics.

2. Materials and Methods

2.1. Battery and Load Model

We modeled a 4-series (4S) LiFePO₄ pack in MATLAB/Simulink Version 25.1 using Simscape battery and electrical blocks (The MathWorks, Inc., Natick, MA, USA) (Figure 1 and Figure 2).

Each cell employs temperature-dependent open-circuit voltage and internal resistance and is represented by a single thermal node with convective cooling. The pack drives a controlled current source at the terminals so that operating duty can be prescribed without modifying the plant topology. State of charge (SoC) is estimated using coulomb counting through a current sensor and a bounded integrator constrained to 0–100%. Passive equalization is to be implemented through a shunt-bleed element with a voltage threshold, hysteresis, and a temperature inhibit.

To emulate a small-rescue-craft operation, a CC-CV load subsystem is used to generate step, ramp, pulse-train, and cruise profiles under both hot and cool ambient conditions. Constant-current segments represent acceleration bursts and throttle blips, while constant-voltage segments represent charger behavior and voltage-limited plateaus. The balancing subsystem uses voltage-based enable and disable conditions and records per-cell activity, bleed currents, and voltage spread, in order to quantify equalization performance.

The MATLAB plant emitted a fixed 26-byte record each update over serial with their corresponding scales: four cell voltages (mV), pack current (A × 100), four state of charges (thousandths of a percent), and four cell temperatures (K × 100). The assembled firmware in an interrupt-driven RX path applies LiFePO₄ limits with hysteresis and debounce, and raises per-condition alarms as follows: over-voltage, under-voltage, over-current, over-temperature, and cell imbalance. Alarms are sent immediately on state change with an optional periodic reminder. Plant telemetry was rate-limited to 0.5 s, wherein the latest record was republished on CAN as four frames that include voltage, current, state of charge, and temperature. A blocking transmittance helper waited for a free mailbox and completion to prevent drops and preserve order. A heartbeat sent the signal every 0.5 s to confirm liveness and TX health. This kept the bus load low, prioritized alarms, and made analyzer traces easy to read.

The CAN map separates periodic data from faults for readability and arbitration. Telemetry uses a contiguous mid-range block of 0x500 (cell voltages), 0x501 (pack current), 0x502 (state of charge), and 0x503 (temperatures). Therefore, tools filter them as a set. Alarms used lower IDs to win arbitration of 0x110 (over-voltage), 0x111 (under-voltage), 0x112 (over-current), 0x113 (over-temperature), and 0x114 (cell imbalance), and a single heartbeat at 0x5FF carried simple counters over the bus. All fields were little-endian words matching the Simulink scales, enabling direct analyzer interpretation without the need for post-processing. Grouping telemetry into four fixed frames simplified periodic publishing and ensured consistency, while assigning each alarm a distinct identifier made active conditions explicit and facilitated per-alarm filtering, logging, and testing.

2.2. Hardware Setup

The system comprises an STM32 NUCLE-F446RE development board driving a short, correctly terminated CAN segment monitored by a Waveshare USB-CAN adapter (Waveshare Electronics, Shenzhen, China), forming a minimal, yet standards-compliant network for evaluating the BMS firmware (Figure 3).

CAN1 is mapped to PB8/PB9 in alternate-function mode, with a 120 Ω termination at both ends of the bus (CAN-H and CAN-L) and a shared reference ground to the analyzer to avoid common-mode issues. The microcontroller clock is set to 84 MHz (CAN kernel 42 MHz), from which a standard timing configuration produced a 500 kbps bus rate representative of typical automotive and marine CAN links. Host communication for configuration and debug used the USB virtual COM on Universal Synchronous/Asynchronous Receiver/Transmitter, channel 2 (PA2 and PA3) at 115,200 baud, 8N1, while the on-board LED on PA5 provided a simple heartbeat and transmit-queue activity indicator without requiring instrumentation. On the personal computer, the Waveshare tool was configured for 500 kbps with internal termination enabled and filters set to pass only the alarm frame, the four telemetry frames, and the heartbeat identifier, providing a view of BMS traffic and making it straightforward to confirm correct frame rates, identifiers, and payload under different test scripts.

3. Results

3.1. MATLAB Plant Results

Figure 4 shows three repeated charge–discharge cycles (SoC, per-cell voltage, pack temperature, and current) that follow the intended rescue-craft duty profile: high-current CC discharge for launch and acceleration of the boat, reduced CC discharge for cruising, a short dwell (idle), then CC charge with negative current followed by a CV taper. The electrical response matches LiFePO₄ behavior, with a flat voltage plateau, load-dependent IR sag, a knee near the lower SoC bound, and a clean CC rise to a CV clamp; this makes under-voltage and over-temperature thresholds easy to set without chasing fast transients. The nearly linear SoC decrease during discharge with no simulation drift means that similar missions consume a repeatable fraction of battery capacity, enabling simple and reliable remaining mission time estimates for the crew.

Cell overlays remain almost coincident (small ΔV_max-min) such that the stack stays well balanced even under high-load cycles, and the BMS can expose most of the nominal capacity without a large safety margin for imbalance. Thermal rise is modest (≈1–3 K), peaking at end-discharge and early constant current (CC) when I²R heating is largest and flattening in constant voltage (CV), which is compatible with sealed compartments, hot Philippine ambients, and back-to-back sorties. Passive shunt balancing uses ΔV_on = 10 mV with a 4 mV hysteresis, with ON delay 2 s, OFF delay 5 s, enabled only near top-of-charge (V_cell ≥ 3.45 V, |I| ≤ C/10); bleeding occurs mainly during CV holds while the boat is docked, progressively shrinking ΔV_max–min with negligible extra heating. In practice, each deployment starts with an equalized pack with maximum usable capacity and reduced risk of a weak cell limiting thrust during critical rescue maneuvers.

3.2. CAN Telemetry Arbitration, Loading, and Reliability

3.2.1. CAN Arbitration and Prioritization

The integrated system operated reliably with a CAN map that explicitly encodes arbitration and prioritization for the rescue-boat application: routine telemetry is grouped at mid-range IDs, voltages (0x500), currents (0x501), state of charges (0x502), and temperatures (0x503), while dedicated alarms (e.g., over-voltage, over-current, etc.) are reserved at lower identifiers so that safety-critical events always win bus access when they coincide with status traffic. On this map, MATLAB sends 26-byte plant records over the virtual COM port and the STM32 rebroadcasts them on CAN at a fixed half-second cadence, with the analyzer consistently showing the intended four-frame burst (0x500 to 0x503), followed by a heartbeat (0x5FF) for liveness (Figure 5).

Decoding the captured bytes confirmed end-to-end scaling: one burst reported cell voltages around 2.98–3.00 V per cell (about 11.9 V pack), a pack current of 60.00 A from the Ax100 field, and temperatures near 300.1 K, roughly 27 °C, across all sensors; a second burst showed a lower pack voltage set (2.82 V per cell) with zero current and the same temperature, matching the Simulink frame used for transmission. After adding mailbox-aware, blocking sends, and a 500 ms publish period, all four telemetry frames were delivered every cycle with no drops; the temperature frame, which had previously been the most likely to be lost, appeared continuously once the ordering and mailbox waits were enforced, so that higher-priority alarm frames can pre-empt telemetry when necessary without compromising the periodic battery data expected by the emergency response boat’s supervisory controller.

3.2.2. Bus Load and Timing

Each 26-byte plant record from MATLAB is republished by the SMT32 as four fixed telemetry frames plus one heartbeat every 500 ms. Assuming standard CAN 2.0 A frames with 8 data bytes, a single frame occupies roughly 110 to 130 bits, including overhead. With five frames per 0.5 s, the BMS produces about 10 frames per second, which corresponds to approximately 1200 to 1300 bits per second. At a bus speed of 500 kbps, this yields a utilization of only about 0.25% to 0.30% of the available bandwidth. Even if alarms or additional nodes are to be added later on, the BMS traffic remains well under 1% of the bus capacity. This very low load means the battery node is unlikely to interfere with the performance of the emergency response boat, and it also gives ample margin for future expansion, such as adding charger status or other modules. The fixed 500 ms publish period provides a deterministic 2 Hz update rate that is more than sufficient for slowly varying variables such as voltage, temperature, and state of charge.

3.2.3. CAN Error Handling

The firmware and bench setup were exercises for reliability rather than only basic functionality (Figure 6). To probe fault behavior, an ACK-loss condition was deliberately created by preventing the receiving node from acknowledging traffic, under which the bus repeatedly retransmitted the affected frame until the fault was cleared, demonstrating that the controller correctly follows the CAN error and retry mechanisms. For an emergency response boat that may experience wet connectors, intermittent nodes, or harsh electrical noise, this behavior is essential: a lost over-current or over-temperature frame is not simply dropped, but retried until it is successfully received or the node transitions into a safe error state.

4. Discussion and Conclusions

The results show that the HIL setup for the CAN BMS is not only technically coherent but also appropriate for the realities of small electric rescue crafts operating in Philippine flood response. The LiFePO₄ model’s flat plateau, clear low-SoC knee, modest 1–3 K thermal rise, and minimal inter-cell spread mean that protection thresholds and balancing logic can be tuned initially and be maintained consistently over repeated sorties. In practice, this supports simple, robust monitoring and remaining-runtime indicators for crews who must decide quickly whether a boat can safely deploy again into strong currents or debris-filled streets. On the communication side, the CAN layout and measurements show that battery telemetry occupies only about 0.25–0.30% of the bus, with alarm identifications pre-empting routine frames and automatic retransmissions verified under forced acknowledgment loss. This combination ensures that critical flags reach human intervention even when the network is shared with other nodes and even when connectors are noisy. Overall, the integrated plant, firmware, and CAN link provide repeatable, well-prioritized, and low-overhead battery information that fits the constraints of compact, rapidly deployed emergency response boats.