Automotive Remote Keyless Entry System Using RAPIDSEA CAN IVN Stack

Automotive Remote Keyless Entry System Using RAPIDSEA CAN IVN Stack

Snapshot

RAPIDSEA supported an automotive body electronics supplier in building a production-ready remote keyless entry system with mobile key fob integration using the RAPIDSEA CAN IVN Stack. By deploying a configurable CAN IVN layer for vehicle-side communication, the team delivered a validated lock/unlock architecture, covering RF front-end to body control module CAN integration, in 8 weeks, with the CAN protocol layer fully decoupled from the RF and mobile application stacks.

Customer Profile

Automotive body electronics supplier developing access control systems for passenger vehicle OEMs in India and Southeast Asia. Product portfolio covers central locking modules, passive entry systems, and next-generation mobile key solutions replacing traditional RF fobs with smartphone-based access. End customers include vehicle OEMs integrating at production and aftermarket fleet operators.

Business Context

As OEMs began mandating smartphone-based digital key support alongside legacy RF fob compatibility, the tight coupling between the RF layer and vehicle CAN interface became an architectural liability. A firmware change to the BLE mobile key stack risked destabilising the CAN lock/unlock command interface. The customer needed a CAN IVN stack for vehicle access systems sitting as a cleanly defined layer between the access decision logic and the body control module's CAN command interface.

Key Challenges

•  Tight RF-CAN Coupling in Legacy Architecture: The existing firmware embedded CAN frame construction directly in the RF decode interrupt handler, making it impossible to add BLE mobile key support without refactoring the entire access control state machine.
•  OEM-Specific CAN Command Frames: Each OEM programme used different CAN IDs and payload encodings for lock, unlock, trunk release, and window closure commands, requiring a separate firmware build per OEM without a configurable approach.
•  Door Status Broadcast Parsing: The body control module broadcast door ajar, lock status, and interior light state at 100ms intervals. The access control application needed to consume these broadcasts for state-aware command logic.
•  Command Arbitration and Debounce: Mobile app users triggering rapid successive lock/unlock commands over BLE introduced command burst conditions on the CAN bus, causing body control module rejection responses and visible actuator chatter on door locks.

Target Platform

STM32G0-series Cortex-M0+ MCU, a cost-optimised 32-bit device balancing CAN FD capability with bill-of-material constraints of a body electronics module. Managed three concurrent interfaces: CAN to the body control module, UART to the RF receiver, and UART bridge to a BLE co-processor. RAPIDSEA CAN IVN Stack's MISRA-C compliant, OS-agnostic architecture integrated cleanly into bare-metal firmware.

Why RAPIDSEA

•  Clean Layer Separation: RAPIDSEA CAN IVN Stack's API surface provided a well-defined boundary between access decision logic and the CAN physical layer. RF, BLE, and NFC access paths all called the same CAN command API, eliminating the coupling that had blocked the mobile key extension.
•  Runtime-Configurable Frame Tables: CAN command frame IDs, payload layouts, and broadcast filter configurations loaded from a compact OEM profile stored in flash, same firmware binary serving multiple OEM programmes through a factory-programmed profile selection.
•  Built-In Receive Filter and Broadcast Parser: Configurable receive filter allowing door status broadcast frames to be routed directly to the application's status callback. The customer's state machine consumed structured door status objects rather than raw CAN payloads.

Solution: How to Build a CAN Stack for Automotive Keyless Entry Systems

CAN IVN Stack Embedded Integration: STM32G0 HAL Mapping

STM32G0's FDCAN peripheral mapped to the RAPIDSEA HAL transmit, receive, and filter callbacks. Both classic CAN and CAN FD modes configured at the HAL level. HAL bring-up and first CAN frame transmission to the body control module simulator completed in one day.

Runtime OEM Profile Engine

Five OEM programme configurations compiled into binary profile tables stored in internal flash. At factory programming, the active OEM profile index written to a dedicated flash configuration sector. Switching OEM programme required only a factory configuration byte change, no firmware rebuild.

Access Decision to CAN Command Interface

Access control state machine refactored to call a single CAN command API regardless of triggering access technology. RF decode, BLE mobile key confirmation, and NFC tap events all resolved to the same lock/unlock/trunk command calls.

Command Arbitration and Debounce

RAPIDSEA CAN IVN Stack's transmit queue configured with a minimum inter-command interval of 300 milliseconds, preventing burst command sequences from BLE rapid-tap events from generating back-to-back CAN frames. Eliminated actuator chatter and BCM rejection responses.

Door Status Broadcast Parsing

Receive filter configured to pass the BCM's door status broadcast frame ID to a dedicated receive callback. RAPIDSEA CAN IVN Stack extracted door ajar, lock status, and interior light state signals and populated a structured status object updated at the 100ms broadcast rate.

Engineering Impact

Conclusion

Building a CAN IVN stack for automotive remote keyless entry that scales across multiple OEM programmes, supports simultaneous RF and mobile key access paths, and handles door status broadcast parsing cleanly requires a protocol layer that is genuinely decoupled from the access technology above it. The RAPIDSEA CAN IVN Stack gave this body electronics supplier exactly that, a configurable, OEM-profile-driven CAN interface absorbing five OEM variants from a single firmware binary.

Connect with our experts to explore RAPIDSEA CAN IVN implementations.