4. Restraint control module (RCM) calibration and diagnostics

The Restraint Control Module (RCM) is the central electronic control unit of the occupant protection system. It hosts the crash-sensing algorithm, deploys the airbags and pretensioners, and continuously monitors the health of every sensor and squib in the restraint loop. For a launch readiness engineer, the RCM is where calibration data, diagnostic trouble codes (DTCs), and vehicle communication interfaces converge. Getting these three elements correct and verifiable is a prerequisite for any restraint system sign-off.

Key Calibration Parameters

RCM calibration is stored as a dataset flashed into non-volatile memory. The parameters that most directly affect launch readiness fall into four groups:

• Deployment thresholds and severity levels: acceleration or pressure thresholds that separate "no-fire," "first-stage," and "second-stage" decisions. Typical frontal calibration uses a velocity change (Δv) threshold in the range of 15–25 km/h for low-severity first-stage deployment, with a higher threshold for second-stage. These values are vehicle-specific and must match the body structure and seat configuration.
• Time-to-fire (TTF) and suppression windows: the time window after impact within which a deployment command must be issued. A typical frontal TTF is 15–30 ms. Out-of-position (OOP) suppression logic uses occupant classification sensor (OCS) input to inhibit deployment when a child seat or small occupant is detected.
• Sensor configuration and orientation: the number and mounting orientation of satellite accelerometers, pressure sensors in the door, and roll-rate sensors. Each sensor's position and axis polarity must be declared so the algorithm resolves the crash direction correctly.
• Vehicle variant coding: a coding string that tells the RCM which airbag set, seat belt pretensioners, and side curtains are installed. A mismatch between coding and physical hardware will set a configuration DTC and may inhibit deployment.

Calibration data is usually delivered as a hex or S-record file and flashed via the diagnostic interface. After flashing, the RCM performs a checksum verification. A failed checksum leaves the module in a safe state with deployment disabled — a condition that must be cleared before the vehicle leaves the line.

Fault Codes and Diagnostic Strategy

The RCM stores both current and history DTCs. Current DTCs indicate a fault present in the current ignition cycle; history DTCs are retained for a defined number of warm-up cycles. For launch readiness, the critical distinction is between latching and non-latching faults. A squib circuit open or short will latch and illuminate the airbag warning lamp until the fault is repaired and the code cleared.

Common RCM DTC families include:

When a DTC is set, the diagnostic strategy should follow a defined sequence: read the freeze-frame data, verify the circuit with a breakout box and multimeter, check connector seating and terminal tension, then clear and re-read. A code that returns immediately after clearing indicates a hard fault; a code that returns only after a drive cycle indicates an intermittent condition, often a harness chafe or a marginal connector.

Communication Interfaces

The RCM communicates over the vehicle's controller area network (CAN) and, on many platforms, a dedicated diagnostic link. The primary interface for calibration and diagnostics is the OBD-II port, which provides access to the diagnostic CAN bus (ISO 15765-4) and, on some vehicles, a separate CAN FD or Ethernet channel for high-speed flashing.

Key interface characteristics:

• CAN bus speed: 500 kbit/s for the powertrain/chassis bus, 125 kbit/s for the comfort bus. The RCM typically resides on the chassis bus.
• Diagnostic protocol: UDS (ISO 14229) over ISO-TP (ISO 15765-2). Services used include 0x10 (session control), 0x27 (security access), 0x2E (write data), 0x31 (routine control), and 0x19 (read DTC information).
• Flashing: bootloader access via a seed-key security handshake, followed by block transfer and checksum verification. Flash time for a full RCM dataset is typically 2–5 minutes.
• Signal integrity: CAN termination resistors (120 Ω at each end) must be present. A missing or double termination will cause communication errors that mimic RCM faults.

For launch readiness, the communication interface must be validated under three conditions: normal operation, after a fault is set, and during a flash event. A common failure mode is a bus-off condition caused by a shorted CAN line, which prevents the RCM from communicating and blocks all diagnostic access. In that case, the physical layer must be repaired before any software-level diagnosis can proceed.

Launch Readiness Verification Sequence

A reproducible RCM verification for launch readiness follows a defined sequence. The inputs are the vehicle, the correct calibration file, and a diagnostic tool with UDS capability. The steps are:

1. Connect the diagnostic tool to the OBD-II port and establish a UDS session (service 0x10, sub-function 0x03 for extended diagnostic session).
2. Read the RCM identification block (service 0x22, DID 0xF190 for VIN, DID 0xF187 for part number, DID 0xF189 for software version). Confirm these match the release documentation.
3. Read all DTCs (service 0x19, sub-function 0x02). Record current and history codes. Clear all codes (service 0x14).
4. Perform a flash event if calibration is outdated. After flashing, re-read the checksum and confirm it matches the release file.
5. Cycle the ignition and re-read DTCs. Any returning code indicates a hard fault that must be resolved before sign-off.
6. Verify the airbag warning lamp extinguishes after the bulb check and remains off during a short drive cycle.

The expected output is a clean DTC report, a matching calibration checksum, and an extinguished warning lamp. Typical failure symptoms include a persistent U-code indicating bus loss, a B-code indicating an open squib circuit, or a configuration code indicating a coding mismatch. Each symptom maps to a specific repair path: bus loss requires physical layer inspection, squib faults require circuit continuity testing, and coding faults require re-flashing the correct variant dataset.

In summary, RCM calibration and diagnostics for launch readiness depend on three tightly coupled elements: a verified calibration dataset with correct thresholds and coding, a disciplined DTC read-clear-verify cycle that distinguishes hard from intermittent faults, and a validated communication interface that supports both normal diagnostics and flash events. When these three are confirmed with recorded identifiers and a clean post-cycle DTC report, the restraint system is ready for launch sign-off.