When Battery Management Meets Incident Detection
In the previous posts,
Previous forum posts:
Part 1 : The Idea behind EVA Guardian
Part 2 : The Architecture of EVA Guardian
Part 3 : The Incident detection system in EVA Guardian
Part 4 : The Battery management system in EVA Guardian
I developed the two major subsystems of EVA Guardian independently. The Battery Management System monitors the battery and provides parameters such as voltage, current, temperature, SoC and SoH. The Incident Detection System monitors vehicle dynamics using the MPU6500 and Edge AI. Both systems were working independently. But an EV is not made up of independent systems.
A battery condition can affect vehicle safety.
A vehicle incident can affect the battery.
And a communication failure between two safety-critical systems can itself become a problem.
So the next challenge was:
How do I make these two systems communicate reliably and, more importantly, how do I know when that communication can no longer be trusted?
This became the focus of this stage of EVA Guardian.
Creating a Master–Slave Architecture
For the integration, I used an RS485 transceiver on both Arduino UNO Q systems.The communication between the two nodes is based on UART, using:
- Pin 1 – TX
- Pin 0 – RX
The architecture is intentionally simple:
Incident Detection System → Master
Battery Management System → Slave
The IDS is responsible for initiating communication, while the BMS responds with its latest battery information.This gives me a deterministic communication model rather than having both systems continuously transmitting data and potentially interfering with each other.
Designing My Own Communication Protocol
Rather than simply sending a raw CSV string over UART, I wanted the communication layer to have a defined packet structure. This became particularly important because the system would later need to detect communication failures and distinguish between different types of faults.
The master sends a battery status request every two seconds. The basic command packet is structured as:
Start of Frame → Payload Length → Command → CRC → End of Frame
The start of frame is: 0x55 0xAA
The battery status command is: 0x01
And the packet terminates with:
0xAA
The CRC is used to provide an additional integrity check on the transmitted data.
Master Request
The IDS periodically sends:
SOF → 0x55 0xAA
Payload Length → Length of command payload
Command → 0x01
CRC → Packet integrity check
EOF→ 0xAA
In simple terms, the IDS is asking:
"BMS, give me your latest battery status."
BMS Response
The BMS receives the request and prepares a response containing the latest battery telemetry.
The response contains:
- Voltage
- Current
- Temperature
- Open Circuit Voltage
- Coulomb Count
- SoC
- SoH
The packet follows the same general framing structure
The response effectively tells the IDS:
"Here is the latest condition of my battery."
Why Poll Every Two Seconds?
The IDS polls the BMS approximately every 2 seconds. The BMS itself is continuously updating its battery measurements, so the IDS does not need to request the data continuously at the same rate as the IMU.
The 2-second polling interval provides a reasonable compromise between:
- Fresh battery information
- Communication overhead
- Processing requirements
- System reliability
The IDS therefore gets a periodic snapshot of the battery condition while continuing to perform its own high-rate incident detection independently.
From Separate Telemetry to Combined Telemetry
Once communication was working, the next step was to bring the BMS data into the existing IDS telemetry system.
Previously, the IDS primarily knew about things such as:
- Motion
- Speed
- Incidents
- Accident classification
Now it also receives:
- Battery voltage
- Battery current
- Battery temperature
- OCV
- Coulomb count
- SoC
- SoH
This information is stored in the IDS telemetry state and exposed through the WebUI. The result is a much more useful dashboard. Instead of having one screen for battery information and another for vehicle dynamics, the IDS becomes the central point from which both can be observed.
But What Happens When Communication Stops?
This was where the integration became much more interesting.
It is easy to demonstrate:
BMS connected → data received → everything works.
But I wanted to deliberately break the system. The communication path has three possible failure points:
Failure 1
IDS RS485 transceiver failure
Failure 2
BMS RS485 transceiver failure
Failure 3
Cable between the two systems
The challenge was:
If communication stops, how can the IDS determine which one has failed?
Simply displaying:
"RS485 communication error"
is not enough.
I wanted EVA Guardian to identify the probable source of the problem.
Step 1 – Wait for the BMS
After startup, the IDS begins polling the BMS every two seconds.
If everything is healthy:
IDS → Request
BMS → Response
IDS → Request
BMS → Response
and so on.
But if the IDS doesn't receive a valid response for 30 seconds, the system assumes that something has gone wrong.
Instead of immediately blaming the cable, the IDS begins a diagnostic sequence.
Step 2 – Test the IDS RS485 Transceiver
The first question is:
Is my own RS485 transceiver working?
The IDS performs a local loopback diagnostic. Specific GPIO lines are controlled to configure the RS485 transceiver into its loopback/test condition.
The diagnostic command used is:
0x02
with payload:
0x1010
The IDS sends the diagnostic pattern through its own RS485 interface.
If the transmitted data is successfully received back:
IDS RS485 transceiver = OK
If the IDS cannot receive what it transmitted:
IDS RS485 transceiver = FAULT
The WebUI then reports the appropriate diagnostic condition.
This is useful because the system doesn't immediately assume that the external cable or BMS is responsible.
Step 3 – Test the BMS RS485 Transceiver
Suppose the IDS transceiver passes its loopback test.
We now know:
My side is probably working.
But the BMS transceiver could still be faulty.
So the next diagnostic step is to communicate with the BMS through the network connection and ask the BMS to perform the same local loopback diagnostic.
The same command is used:
Command: 0x02
Payload: 0x1010
The BMS performs its own RS485 loopback test.
If the BMS successfully receives its transmitted data:
BMS RS485 transceiver = OK
The BMS reports this status back to the IDS.
If the BMS cannot complete the loopback:
BMS RS485 transceiver = FAULT
The IDS then displays this information on the WebUI.
Step 4 – So Where Is the Problem?
Now comes the interesting part.
Imagine:
IDS transceiver → OK
BMS transceiver → OK
but:
IDS <-> BMS communication → FAIL
At this point, both ends have independently verified that their own RS485 hardware is functioning.
That leaves the most likely problem:
The communication cable or physical connection between them.
The WebUI can therefore report:
Communication Cable Fault
instead of giving the user a generic communication error.
This is a small feature, but from a system engineering perspective, it makes a significant difference.
Why I Wanted This Diagnostic Capability
Imagine this system inside an actual vehicle.
A technician receives an error:
BMS Communication Failure
What should they check first?
The BMS? The IDS? The transceiver? The cable?
Without diagnostics, troubleshooting becomes a manual process.
With the diagnostic logic implemented in EVA Guardian, the system itself can narrow down the problem.
Instead of:
Communication Failure
the system can provide:
IDS RS485 Fault or
BMS RS485 Fault or
Communication Cable Fault
This is the difference between monitoring a system and diagnosing a system.
Another Problem: What Happens to the Power Connector?
After dealing with communication failures, I wanted to investigate another practical failure scenario. The physical power connection between the BMS and IDS can also deteriorate. A connector doesn't necessarily go from:
Perfect → Completely Broken
It can gradually become worse. A poor connection can introduce additional resistance and therefore cause a voltage drop. So I added another voltage measurement point at the IDS side.
Monitoring the Power Connection
The IDS measures the voltage arriving through the power connection using its own voltage measurement circuit connected to:
A0
At the same time, the BMS provides its measured battery voltage through RS485. Now I have two values:
BMS-side voltage
Measured directly by the BMS.
IDS-side voltage
Measured after the power connection. The system continuously compares the two.
Conceptually:
Battery voltage -> BMS measurement -> Power connector / cable -> IDS measurement
The difference between these measurements gives an indication of what is happening across the connection.
Detecting Connector Degradation
If the voltage difference starts becoming noticeable but the connection is still functioning, the system generates a warning. For the current prototype, I configured a threshold around 500 mV for the degradation warning.
The WebUI can display a message such as:
️ There is a connector degradation. Please show it to the mechanic soon before any severe damage.
The purpose is not to wait until the connector completely fails. The objective is to identify a potentially deteriorating connection early.
Detecting a Broken Connection
The other extreme is a significant voltage drop indicating that the power path may have become disconnected or severely compromised. In this situation, the system moves from a warning condition to an error condition.
The WebUI can then indicate:
Power connection fault
This gives the user a clear distinction between:
Warning and Critical failure
In this demonstration, I intentionally introduce a degraded connection and observe the voltage difference between the BMS and IDS sides.
Making Accident Detection More Reliable
The integration also gave me an opportunity to improve the accident notification mechanism. One of the problems with a pure ML-based event trigger is that a single inference window can occasionally produce an incorrect classification.
Imagine the model outputs:
Accident – 91%
for one inference window. Should that immediately trigger an emergency message? I decided that for this system, the answer should be:
Not yet.
Instead, the system now requires the model to classify the event as Accident across more than three consecutive inference windows before triggering the emergency response.
Conceptually:
Accident -> Accident -> Accident -> Accident confirmed -> Telegram alert
This gives the system an additional layer of event confirmation.
Preventing Telegram Alert Flooding
Another practical issue appeared during testing.
If the accident condition remains active, the model can continue producing:
Accident
Accident
Accident
Accident...
Without protection, the Telegram system could potentially send multiple notifications for the same event.
To prevent this, I implemented an accident cooldown mechanism. Once an emergency alert has been dispatched, the system temporarily suppresses additional alerts for the same event.
This creates a cleaner workflow:
Detection
→ Confirmation
→ One emergency notification
→ Cooldown
rather than flooding the emergency contact with repeated messages.
The Complete Data Flow
At this point, the integrated system has several independent data paths operating simultaneously.
Vehicle Dynamics
MPU6500 -> 42 Hz acquisition -> EMA filtering -> Edge AI inference -> Incident classification
Battery
Voltage / Current / Temperature -> BMS processing -> SoC / SoH / OCV / Coulomb Count -> RS485 -> IDS
Diagnostics
RS485 timeout -> IDS loopback test -> BMS loopback test -> Cable fault identification
Power Connector
BMS voltage -> IDS-side voltage -> Voltage difference -> Connector warning / fault
Emergency Response
Confirmed accident -> Telegram -> WebUI alert
All these paths finally converge at the IDS telemetry layer.
And Now... Let's Break It
For me, this is one of the most interesting parts of the project.
Instead of only showing the system working perfectly, I wanted to demonstrate what happens when I intentionally introduce faults.1.
- Pull the RS485 cable : Does the system identify the communication failure.
- Simulate a transceiver problem : Can it distinguish an IDS-side fault from a BMS-side fault?
- Introduce connector degradation: Does the voltage comparison detect it
- Simulate an accident: Does the ML model confirm the event before sending the alert
- Trigger a confirmed accident: Does the Telegram notification reach the registered user?
These tests make the project much more representative of an actual engineering system.
Complete Integrated System Demonstration
This video demonstrates the complete system operating as a single platform, with the BMS and IDS communicating through RS485 while the WebUI displays the combined telemetry.
Automatic Power Switching
This demonstration focuses specifically on the safety relay and automatic power switching mechanism.
Communication Fault Detection
Here I intentionally interrupt the communication link and demonstrate how EVA Guardian performs its diagnostic sequence.
Power Connector Degradation
This demonstration shows how the system compares the BMS-side and IDS-side voltage to identify a potentially degrading power connection.
Moving From Electronics to a Vehicle
The electronics are now beginning to look like a system. But I wanted the final demonstration to look like a vehicle rather than a collection of development boards sitting on a table. So I started building a small cardboard EV model. The intention is to physically represent where the different subsystems would exist in an actual vehicle and route the wiring accordingly. The model is still under development, but it will provide the physical foundation for the final demonstration.
The Finishing Touch
This part of the physical model is currently in progress and will be completed in the next stage.
What Has Changed?
Looking back at the beginning of the project, I had two separate systems.
The BMS could answer:
"How is my battery doing?"
The IDS could answer:
"What is happening to my vehicle?"
After this integration, the system can start answering:
"How is my vehicle doing, how is its battery doing, and can I trust the information I'm receiving?"
That last question is particularly important. Because a smart system should not only provide information. It should also know when the information itself may be unreliable. That is why the communication diagnostics, connector monitoring and fault handling became such an important part of this stage.
What's Next?
The next stage is to move the integrated electronics into the physical EV demonstrator.
I am currently working on the cardboard vehicle model that will house the BMS, IDS, power switching and communication architecture.
The next phase will focus on:
- Integrating the electronics into the vehicle model
- Finalizing the automatic safety power switching
- Refining the WebUI
- Improving fault indication and system status
- Demonstrating the complete end-to-end safety workflow
- Presenting the system as a single EV platform rather than individual modules
The goal for the final demonstration is simple:
Don't just show that EVA Guardian works.
Show what happens when something goes wrong.
That is where I believe the real value of the project lies.
Final Thoughts
This stage has been one of the most interesting parts of EVA Guardian because I moved away from developing individual features and started thinking about system behaviour. A real vehicle doesn't operate in perfect conditions.
- Cables can fail.
- Connectors can degrade.
- Sensors can produce abnormal values.
- Communication links can disappear.
And an accident can happen at any time. The objective of EVA Guardian is therefore not simply to detect these events. It is to identify, communicate, diagnose and respond to them. And with the BMS and IDS now working together, EVA Guardian is getting much closer to the original vision:
A vehicle that can sense what is happening, understand the situation, identify when something is wrong, and take the appropriate action.
The two systems are now talking.
The next step is to put them inside the vehicle.
Github Repo: https://github.com/ForgedCircuits/EVA-Guardian.git