The core purpose of local wake-up (such as KL15 power-on or sensor trigger) directly entering the Immediate Transmit State is to achieve rapid network-wide collaborative wake-up through high-frequency NM messages that seize the bus. The specific design logic is as follows:
1. Core Purpose
- Accelerate Network Synchronization
The ECU that wakes up locally acts as an active wake-up source and needs to notify other nodes first.
It sends 10 frames of NM messages at a 20ms cycle (CANNM_IMMEDIATE_NM_TRANSMISSIONS=10), waking up all ECUs that rely on remote wake-up in a very short time (≤200ms).
In contrast to remote wake-up: the passively woken ECU must wait for regular NM messages (500ms cycle) to respond, while local wake-up can actively accelerate this process.
- Avoid Application Message Conflicts
In the Immediate Transmit State, application messages must be delayed (e.g., delayed until Tx_Enable_Time).
This ensures that NM messages occupy the bus first, preventing conflicts or packet loss caused by application messages being sent when the network is unsynchronized.
- Identify Wake-up Type
The Byte 1 Bit 4 of the NM message will be set to 1 (Active Wakeup Bit), indicating that this is a local wake-up event.
The receiving node can distinguish the wake-up type based on this and adjust its response logic (e.g., gateways need to synchronize wake-up with associated subnets).
2. Technical Implementation Mechanism
- State Machine Forced Transition
After local wake-up, the ECU skips the regular offset time (CANNM_MSG_CYCLE_OFFSET) and directly transitions from Bus-Sleep → Immediate Transmit State.
The first frame of the NM message must be sent within T_start_message ≤200ms.
-
Parameter Configuration
Parameter Value Function CANNM_IMMEDIATE_NM_CYCLETIME 20ms ±10% Fast sending cycle CANNM_IMMEDIATE_NM_TRANSMISSIONS 10 frames Fast sending count (mandatory) Tx_Enable_Time Delay time Application message sending delay (to prevent conflicts) -
Cooperative Sleep Assurance
If the wake-up event is invalid (e.g., false trigger), the ECU will revert to Bus-Sleep mode if it has not verified within T_timeout_wakeup ≤4000ms.
3. Comparison with Normal Wake-up
| Scenario | Trigger Condition | NM Sending Behavior | Network Synchronization Speed |
| Local Wake-up | KL15 power-on, sensor | 20ms cycle × 10 frames → 500ms cycle (directly seizing the bus) | ≤200ms |
| Remote Wake-up | Receiving NM message | Delayed CANNM_MSG_CYCLE_OFFSET after 500ms cycle | ≥500ms |
Note: Remote wake-up cannot trigger Immediate Transmit.
4. Design Essence
By seizing the bus with high-frequency, high-priority NM messages, the issue of startup delay in distributed ECU systems is addressed:
Synchronization Efficiency: Replaces traditional random offset waiting, forcing the entire network to quickly enter communication state.
Power Consumption Optimization: Invalid wake-up events (e.g., false triggers) can quickly return to sleep (T_goingtosleep ≤3000ms).
Fault Diagnosis: Combined with Byte 1 Bit 4 identifier, it supports tracing the wake-up source.
This mechanism is the core design of AUTOSAR NM for achieving low-power collaboration, especially suitable for control systems that require rapid response (e.g., door locks, lighting).