What is pack fire / off-gassing sensing?

In my pack projects, I treat off-gassing sensing as an early warning layer that sits above temperature hubs and insulation monitoring. Instead of waiting for hot surfaces or obvious smoke, I try to catch the moment when cells start venting gas or particles into the pack volume. That extra window lets me slow the system down, stop charging or trip a higher-level safety chain before a small defect turns into a full pack fire.

• What I detect – early gas venting, VOC spikes and fine particles escaping from cell vents, seams or harness feed-throughs, before heavy smoke appears.
• When it happens – after an internal fault starts heating a cell, but often before pack surface temperatures or insulation values move enough to trigger other alarms.
• How I use it – I limit pack power or charging current, flag an event in the BMS log and give the contactor logic a strong hint that something inside the pack is going wrong.

Failure chain & detection window

When I map out a pack fire event, I think in stages: a tiny internal fault heats a cell, then gas starts to form and escape, and only later do I see heavy smoke and obvious damage. Temperature hubs and insulation monitoring mostly guard the heating and electrical side of the story. With off-gassing sensing I try to live squarely in the gas-generation stage, before smoke or open flame makes the problem obvious.

• Stage 1 – Internal micro-short – a small defect or abuse event creates a tiny current path inside one cell.
• Stage 2 – Localized heating – internal regions get hot while pack surfaces and coolant plates may still look almost normal.
• Stage 3 – Gas generation / venting – materials break down and gas finds its way out through vents, seams and feed-throughs.
• Stage 4 – Smoke / open flame – now even a basic smoke detector can see the event, but system-level damage is already likely.
• Stage 5 – Pack damage & propagation – failure can spread between cells and modules if other protections do not react in time.

I still rely on temperature hubs and insulation monitoring to guard Stage 2 and the electrical insulation side. Here I am zooming in on Stage 3, where gas starts to escape but I may not see heavy smoke or strong thermal gradients yet.

Sensing options for off-gassing

When I shortlist sensing options for pack fire and off-gassing, I try to keep the list simple. In practice I lean on optical smoke and particle sensing, gas and VOC sensing SoCs, and a few multi-sensor nodes that combine them. Other ideas like pressure or acoustic sensing stay in the toolbox, but I rarely treat them as the primary detection layer for off-gas in an HV battery pack.

The table below is how I mentally compare the main options. I map each sensor family to its detection window, strengths, weaknesses and the kind of IC category I expect to source from automotive suppliers.

In my own designs I usually start from gas and VOC SoCs and then decide how much optical and temperature sensing I need around them. Pressure and acoustic channels stay on the “nice to have” side, not the backbone of the off-gas detection layer.

Node placement & system topology

Once I know what kind of sensors I want, the next decision is where to put them and how to wire them. In a real pack that means choosing between a few high-value nodes near vents and lids, or a more distributed scheme with sensors closer to each module and cooling channel. That choice drives harness length, latency, redundancy and the way I connect back into the BMS or high-voltage safety controller.

I also have to decide which nodes live on an always-on supply, which can sit behind switched rails, and how their alarms and data move into the system: simple digital inputs, LIN or CAN sensor nodes, or a higher-bandwidth link into a safety MCU.

Placement patterns

• Module vents – nodes placed close to cell or module vents to see off-gas as early as possible at the source.
• Pack lid and seams – sensors along the lid, service covers and harness feed-throughs where gas is likely to escape into the pack cavity.
• Cooling channels – positions in airflow paths and coolant manifolds where vapors may be carried away from a failing cell.

Central hub vs distributed nodes

Power domains and interfaces

• Always-on nodes – critical off-gas sensing powered even when the pack is “off”, with micro-amp standby current targets.
• Switched domains – additional sensing that only runs during driving, fast charging or defined operating modes.
• Interfaces to BMS / HVSC – simple alarm lines, LIN or CAN sensor nodes, or direct digital links into a safety MCU with diagnostics.

In this section I stay focused on where the nodes live and how they hook into the system. The analog front-end, MCU and alarm drivers that sit inside each node are covered in the dedicated signal-chain section.

Signal chain: optical/gas SoC + ULP MCU + alarm drivers

When I design a pack fire and off-gassing node, I think in terms of a simple signal chain: sensors feed an analog front-end, the front-end feeds an ADC or SoC, and a ULP MCU decides what to do with the result. At the far end of that chain I need robust alarm drivers and interfaces that can talk to the BMS, the high-voltage safety controller and, if needed, the contactor and relay logic in the BDU or BJB.

The goal is to keep the building blocks clear: optical and gas sensors, their AFE, the low-power MCU and the outputs that actually move the system. If any link is fragile, the whole off-gas detection layer becomes hard to trust in a real vehicle program.

Front-end and AFE

• Optical path – photodiode choice, LED driver strength, integration time and filtering so the ADC sees a clean, usable signal instead of raw noise.
• Gas front-end – sensor bias, small current or voltage readout, and temperature compensation to keep baselines stable over time.
• ADC and dynamic range – enough resolution to see early off-gas without saturating when events become severe.

ULP MCU and power modes

• Sleep and periodic wake – long sleep intervals with short sampling bursts so the node can stay online for years on a tight standby budget.
• Event-triggered sampling – using threshold comparators in the AFE to wake the MCU only when something moves, not on every timer tick.
• Clock, timers and watchdog – low-frequency clocks for background tasks and a watchdog that keeps the MCU honest in safety-critical operation.

Alarm outputs and interfaces

• Local alarms – LEDs, buzzers or a simple hardware fault line that makes it obvious when the node has raised a serious off-gas event.
• Digital bus – I²C or SPI into a BMS MCU, or a LIN or CAN sensor node when I want the off-gas node to appear as an addressable ECU.
• Links to BDU / BJB – dedicated alarm lines that can influence contactor and relay logic without pushing all decisions through the main CPU.

Robust alarm drivers

• Drive strength and isolation – enough current capability and electrical isolation to survive real harness faults and noisy HV domains.
• Short-circuit protection – current limiting and thermal shutdown so a shorted alarm line does not silently kill the node.
• Diagnostic feedback – open/short detection on alarm outputs, so the BMS can tell the difference between a quiet pack and a broken signal chain.

Power, reliability & diagnostics planning

An off-gas sensing node only helps me if it can stay alive for the whole life of the pack. That means planning its power budget, understanding how the sensors drift, building self-test into the signal chain and tying everything back to functional safety goals. I do not treat these topics as afterthoughts; they are part of the core design for any node that is supposed to see the first signs of a pack fire.

In practice I use a short checklist: how much standby current I can afford, how often I need to sample, how I will detect sensor and wiring faults and what level of safety integrity the system expects from this node.

Low-power modes and supply budget

• I need to keep the standby current of each node in the low micro-amp range wherever possible so the pack can sit parked for long periods.
• I need to set a duty-cycle for sampling that matches the detection window, not just a convenient timer value.
• I need to consider power-up behavior during maintenance and shipping modes so nodes do not wake up in undefined states.

Environment, ageing and drift

• I need to plan for temperature extremes, ageing and contamination when I choose sensor types and operating points.
• I need a strategy for baseline tracking so slow drift does not silently eat away my detection margin.
• I need to check how the node behaves after salt spray, dust and vapors so I do not discover a problem only in fleet.

Self-test strategies

• I need a loopback test for the optical path or gas front-end, not just a power-on check that the MCU is running.
• I need a periodic self-test sequence that exercises the ADC, thresholds and alarm paths without creating nuisance events.
• I need to log self-test failures so the BMS or vehicle can react and schedule service instead of flying blind.

Safety goals, diagnostics and redundancy

• I need a clear safety goal for the off-gas node, typically aligned with ASIL targets agreed for the pack fire detection function.
• I need diagnostics that can catch sensor open/short, ADC saturation, MCU lock-up and lost communication without relying on a single check.
• I need a redundancy concept, whether that means multiple sensors near one vent or distributed nodes with voting between them.

Integration with BMS & vehicle functions

An off-gas sensing node only becomes useful when the rest of the vehicle knows what to do with its alarms. In my projects I try to define clear alert levels, make sure the BMS can log and interpret them, and then hand a clean request to the vehicle control units that actually manage power limits, charging and contactors.

This section stays focused on signal shapes and interfaces. The detailed contactor control strategies and powertrain safety sequences live with the BDU and BJB functions, not inside the off-gas node itself.

Alert levels and system roles

• Warning – early off-gas or VOC changes that do not yet prove a pack fire. The BMS logs the event, increases monitoring and may start to limit charging current.
• Severe – persistent or repeated off-gas activity that suggests a real internal issue. The BMS sets a fault, tightens power limits and informs the vehicle control units.
• Emergency – strong off-gas combined with other evidence such as temperature or insulation changes. The system prepares to stop charging, reduce power aggressively and move towards opening contactors.

Logic ladder: from alert to vehicle action

1. Off-gas nodes raise a warning, severe or emergency alert based on their local thresholds and diagnostics.
2. The BMS validates the alert against other sensors and checks for plausibility, filtering obvious noise or transient glitches.
3. The BMS logs the event, updates SOH/SOF estimators and decides whether a vehicle-level reaction is required.
4. The BMS sends a request to the HVCU or VCU to limit power, stop charging or prepare for a safe contactor open sequence.
5. The HVCU or VCU applies actions such as derating torque, stopping DC fast charge and coordinating with the BDU/BJB to control contactors.

Interaction with BMS

• The BMS collects raw readings and alert bits from off-gas nodes, applies filtering and time correlation and turns them into internal fault codes.
• Off-gas activity feeds into SOH and SOF models, especially when it repeatedly comes from the same module or region of the pack.
• Important events are sent to telematics and remote diagnostics, so fleet operators and OEM backends can see emerging issues and respond early.

Vehicle controls and other sensing layers

• The HVCU or VCU uses off-gas alerts to reduce power, stop charging or move the vehicle into a defined safe state when the BMS requests action.
• Detailed contactor timing and sequences live inside the BDU/BJB safety logic; this page only defines how off-gas information reaches those blocks.
• Off-gas data is combined with thermal sensing, IMD and HVIL so no single sensor type carries the whole decision. Multi-source evidence improves both safety and robustness against false positives.

IC selection map

When I turn the pack fire and off-gas sensing concept into real hardware, I think in terms of a simple IC map. I need sensing SoCs for smoke and gases, ultra-low- power MCUs to run always-on nodes and robust drivers and interface ICs that can present alarms to the BMS, the vehicle network and the high-voltage safety path.

Instead of collecting part numbers, I group devices by category and a few key selection dimensions. Vendors such as TI, ST, NXP, onsemi, Renesas, Microchip and Melexis all have products in these spaces, but the right choice depends on my sensing targets, interfaces and safety goals.

BOM & procurement checklist

When I send RFQs for pack fire and off-gas sensing modules, I try to capture a short list of fields so suppliers understand that I am not asking for a generic smoke detector. The more clearly I describe what I need to detect, the operating window and the safety and power expectations, the more useful the responses become.

The bullets below are how I structure my BOM lines and RFQ templates for off-gas sensing nodes. Each one can become a column in a spreadsheet or a paragraph in a sourcing email.

• Sensor type & detection target – smoke, VOC, specific gases or a combination, including any preference for optical vs gas sensing technologies.
• Required detection window – whether I need early off-gas detection before temperature rises, heavy smoke, or both, and how these map to warning and emergency levels.
• Response time & threshold strategy – typical response times, single vs multi-level thresholds and how often the node is allowed to sample.
• Operating temperature & environment – ambient and internal pack temperature range, condensation, contamination and any sealing or coating constraints.
• Power supply & standby current budget – supply voltage range, always-on supply availability and the maximum standby current the node is allowed to draw.
• Communication interface – whether the module exposes I²C/SPI to the BMS MCU or appears as a LIN/CAN node on the vehicle network, and any diagnostic message expectations.
• Functional safety goal – target ASIL level for the off-gas detection function and the level of diagnostics and documentation expected from the supplier.
• Self-test & calibration requirements – built-in loopback tests, baseline tracking, calibration routines and how they are triggered and reported.
• Package, mounting & placement constraints – space envelope, preferred mounting near vents or cooling paths and any isolation or creepage requirements.
• Compliance & standards – relevant safety and EV regulations such as ISO 26262 and UNECE R100/R136, plus any OEM-specific standards the module must support.

Recommended topics you might also need

• Pack Intrusion / Water Ingress
• BDU / Pyro-Fuse Unit
• wBMS RF Bridge / Node
• Cool-Plate Temperature Hub

FAQs · Pack fire and off-gas sensing

These twelve questions are how I sanity-check my own pack fire and off-gas sensing design. Each answer is short enough to reuse in reviews, RFQs and search snippets, but detailed enough to capture real decisions about sensing options, node topology, power budgets, safety goals and how off-gas alarms connect into the BMS and vehicle.