Offset

How to prevent vehicle daytime (customer set on screen) to broadcast in the system (from MHU to CVC)

ChatGPT said:

To prevent the broadcast of vehicle daytime (set by customer on screen) from MHU to CVC, you can take several approaches depending on your system architecture and project phase (development, integration, or validation).

---

✅ Step-by-Step Solutions

🟢 1. Modify the MHU Application Logic

In the MHU software (Head Unit), prevent the value from being sent over CAN when it's set or changed.

c
// Pseudocode if (!allow_daytime_broadcast) { // Skip sending message or set default/neutral value return; }

Add a flag or condition (e.g., allow_daytime_broadcast) to control whether Vehicle_Daytime signal is sent.

Alternatively, filter it when user changes the date/time through the HMI.

🟢 2. Modify the CAN Stack / Signal Update Function

If the Vehicle_Daytime is part of a CAN message (e.g., Vehicle_Status_Msg), you can:

• Suppress the update of the signal value before sending

• Or freeze the value to a default (e.g., 0 or last known good)

c
canMsg.data[2] = 0x00; // overwrite the daytime field to zero

---

🟡 3. Mask or Ignore at the CVC Receiver Side

If MHU cannot be changed (e.g., black-box Tier 1), configure CVC (Central Vehicle Controller) to:

• Ignore the signal in its parsing logic

• Mask the signal value if received (do not use it in logic)

c
if (msg_id == VEHICLE_STATUS_MSG) { // Ignore or discard daytime parsed_daytime = INVALID; }

---

🔴 4. Modify the DBC File (only if allowed)

If your DBC allows flexibility and you're not using this signal:

• Remove or comment out the Vehicle_Daytime signal from the message

• Or set its value range to 0 to prevent usage by downstream tools

⚠️ Only do this if all stakeholders agree (e.g., EE, Tier 1, safety)

---

🔴 5. Block the CAN Message via Gateway (if available)

If the MHU-to-CVC path passes through a CAN gateway ECU, you can:

• Filter the message at gateway level

• Drop or override specific signals

Example: In a zonal controller or gateway filter table.

=============================

if the customer's setting time and the system time is different, how can we know this offset? To remote troubleshot, we will rely on the system log. But the time in the system log is different with time of the customer's screen time, may lead to difficult to troubleshoot

ChatGPT said:

You're absolutely right — time desynchronization between the customer-set screen time (often via MHU/HMI) and the system time (e.g., CVC, logger, or backend timestamp) can cause major troubleshooting challenges, especially in remote diagnosis. To resolve or mitigate this, here's how you can measure, log, and correct the time offset.

---

✅ Goal:

Detect and log the time offset between the customer-set time and the internal system time.

---

✅ 1. Log Both Timestamps Explicitly

In system logs (e.g., CVC, TCU, logger):

• Always log both:

  • System timestamp (e.g., real-time from RTC or GNSS)

  • Customer-set screen time (received via CAN from MHU)

Example log:

yaml
[SystemTime: 2025-07-15 14:03:20] 
[MHU_ScreenTime: 2025-07-15 13:56:40] 
Event: RadarFault

➡️ This allows you to compute and track offset = SystemTime - MHU_ScreenTime.

---

✅ 2. Create a Diagnostic Signal for Time Offset

Define a new CAN signal (or reuse existing one if available):

• Name: ScreenTimeOffset

• Value: int32 (seconds or milliseconds)

• Calculation: SystemTime - MHU_SetTime

• Source: compute on receiving ECU (e.g., CVC or gateway)

You can log or display it in diagnostics to detect desyncs like:

pgsql
Offset = +420 seconds → user time is 7 minutes behind

---

✅ 3. Auto-correction Feature (optional)

Some systems implement time auto-correction:

• Periodically compare HMI time vs. GNSS or RTC

• If offset > threshold (e.g., 2 minutes), prompt user or sync automatically

🔒 For ADAS safety-critical use cases, only allow read-only monitoring to avoid misuse.

---

✅ 4. Remote Logging Strategy

To support remote troubleshooting, make sure:

• Time zone and DST (Daylight Saving Time) are clearly included in the log

• All logs are timestamped in UTC or a clearly marked time base

• The source of each time (MHU, RTC, GNSS, backend) is labeled

---

✅ 5. Error Codes or Flags for Desync

Optionally define a DTC or diagnostic flag like:

• TIME_OFFSET_EXCEEDS_THRESHOLD

• CUSTOMER_TIME_UNTRUSTED

It can help engineers or cloud backend to filter faulty data.

=======================================

How to set Tsync in CAN dbc message from MHU to CVC?

ChatGPT said:

To set Tsync in a CAN DBC message from an MHU (Master Head Unit) to a CVC (Central Vehicle Controller), you'll need to follow both the signal definition and timing rules in your DBC and ECU communication design. Here's how you can approach it step by step:

---

✅ 1. Understand What Tsync Means

Tsync usually stands for time synchronization, a signal used to:

• Synchronize timestamps between ECUs

• Align internal clocks for time-dependent functions (e.g., logging, diagnostics, fusion)

It can be:

• A dedicated signal in a CAN message (e.g., Tsync_Counter)

• Or a periodic message with a defined send cycle (e.g., Tsync_Msg every 100 ms)

---

✅ 2. Locate the Message in the DBC File

• Open your .dbc file using a tool like Vector CANdb++, CANape, CANalyzer, Kayak, or python-can DBC parser.

• Look for the message sent from MHU to CVC.

• Example:

graphql
BO_ 1234 Tsync_Message: 8 MHU SG_ Tsync_Counter : 0|8@1+ (1,0) [0|255] "count" CVC

---

✅ 3. Set the Tsync Signal

To configure or change the value of Tsync, do one of the following:

a. At Runtime (in code on MHU side):

If you're coding the MHU firmware:

c
uint8_t tsync_counter = 0; void send_tsync_msg() { CAN_Message tsync_msg; tsync_msg.id = 0x1234; // Use your actual ID tsync_msg.data[0] = tsync_counter++; // Tsync value send_can_message(tsync_msg); }

Usually sent periodically (e.g., every 100 ms).

• CVC uses this counter to check sync, drift, or delays.

b. In Vector Tools (for simulation or testing):

If you're simulating messages in CANoe/CANalyzer:

capl
variables { message Tsync_Message tsync_msg; msTimer syncTimer; } on start { setTimer(syncTimer, 100); } on timer syncTimer { tsync_msg.Tsync_Counter += 1; output(tsync_msg); setTimer(syncTimer, 100); // resend every 100 ms }

---

✅ 4. Ensure Timing Consistency

In the DBC file:

• The cycle time of the message should match expectations (e.g., 100 ms).

• The signal size and format (e.g., 0|8@1+) must be correct.

---

✅ 5. Use Tsync on the CVC Side

CVC typically:

• Stores the last Tsync counter value

• Monitors delta between received values

• Detects if messages are missing or delayed (e.g., watchdog logic)