ACC speed auto-set

[AINils]

GTI and R also sometimes a little bit special. But depend on used driving profile and ACC setting of profile.

 

[jyoung8607]

1- The CAN protocol incorporates a robust CRC mechanism ensuring 'error-free' for each packet. Why did VW designers add an extra CRC inside the package?

It's called end-to-end protection because there is often more than one transport "hop" between the sender and receiver(s) of the message payload.

In the simplest scenario, there could be software bugs or hardware-level memory corruption in the CAN gateway that relays messages between CAN buses. A message could be received with a valid transport-level CRC, experience a single bit flip while being copied, and be retransmitted with a different but valid transport-level CRC. Transport-level protection isn't enough.

There are also times when the same payload crosses different transports. For example, MLB/MLBevo with blended FlexRay and CAN network topology will need to translate some of the messages back and forth. As one example, it was noted during reverse-engineering of the Audi Q8 that Lane Assist over FlexRay is done with a message almost identical to HCA_01 as used on CAN, and continued to use the same payload-level CRC algorithm, though FlexRay itself uses entirely different transport-level protection.

2- Why does the extra CRC formula have to be so complicated? A simple formula involving all the bytes of the packet is not enough?

I really don't know. I do know the AUTOSAR spec considers Profile 2 to be deprecated, but there are many other profiles.

All manufacturers seem to apply some level of payload-level protection, but some of them are pro-forma, like XOR or a true basic checksum. Older Volkswagen (PQ, prior to MQB) use XOR. Some manufacturers seem to apply a bit of security-through-obscurity. You can see examples of other manufacturers in that same opendbc file I linked you to earlier.

None of them are true cryptography, at least before AUTOSAR SecOC, and in the modern world there are reverse-engineering tools that make most of them trivial to figure out, and will do a lot of the busywork for you on the more complex/annoying ones.

3- It is reasonable to send a data packet with a neutral command from time to time to declare that the processor on the steering wheel is healthy. But why every 30 milliseconds? Isn't for example every 1000 milliseconds enough? What is the risk?

There exist some CAN messages that update this way, for example Blinkmodi_02 for the turn signals. From memory, I think it updates at 2Hz plus edge triggering on state changes. There are others that shift rates depending on whether the function is active. As an example, HCA_01 sends at 1Hz unless lane guidance is active, and it then goes to 50Hz.

I can only speculate as to why Volkswagen chose a static frequency of 33Hz for GRA_ACC_01. They may have wanted faster fault detection, if the message goes missing (for example, due to a fault in the steering wheel clockspring) the Cancel button might cease to work.

4- As you have experienced, why is the error not reported when the rolling counter gets messed up (of course only once)? So what problem does the counter in the package solve?

The counter itself is intended to provide a little protection against replay of messages. This can happen, for example, if a CAN bus participant transmits a message but doesn't hear an ACK and sends it again, or otherwise gets in a loop transmitting the same message. This can happen due to either software or hardware faults.

Each CAN message has its own definition of tolerances: allowable time to wait for the first message at wake-up/power-on, allowable time between messages (expected rate), and allowable lost messages before declaring a fault. Those tolerances will vary greatly between messages.

 

[jyoung8607]

As a comparison, pressing the Start/Stop switch sends a specific packet to change the engine's Start/Stop state. There is no additional CRC, no counter in the packet, and no repetition. This is quite logical!
Here is the packet:

00 00 06 5A 08 00 00 00 01 00 00 3C 00

The auto start/stop button probably isn't considered safety relevant under an ASIL analysis. To summarize, there probably aren't any failures or malfunctions of the auto start/stop button that could meaningfully increase the risk of losing control or crashing. Or if such a risk exists, it's mitigated by other means, like higher-level play protection in the start-stop coordinator. All that button really does is set one of the dozens of stop-inhibit conditions that already need such higher-level filtering/protection.

By comparison, the cruise control buttons (especially Cancel) are probably given higher weighting in safety analysis.

IDE02756,Number of manual engine starts,70,
IDE02757,Number of automatic engine starts,4,
IDE03008-MAS04415,Stop process prevented-Ambient air pressure,not active,
IDE03008-MAS04416,Stop process prevented-Sporadic function prevention,not active,
IDE03008-MAS04417,Stop process prevented-Poor start detection,not active,
IDE03008-MAS04590,Stop process prevented-Mixture adaptation,not active,
IDE03008-MAS06602,Stop process prevented-Engine temperature,not active,
IDE03008-MAS06604,Stop process prevented-Start/stop sensors:,not active,
IDE03008-MAS06605,Stop process prevented-Regeneration Mode,not active,
IDE03008-MAS06606,Stop process prevented-Brake under pressure too low,not active,
IDE03010-IDE00924,Number of prevented stop processes-Steering angle,1,
IDE03010-MAS01627,Number of prevented stop processes-Steering,7,
IDE03010-MAS02040,Number of prevented stop processes-Anti-play protection,0,
IDE03010-MAS04415,Number of prevented stop processes-Ambient air pressure,0,
IDE03010-MAS04416,Number of prevented stop processes-Sporadic function prevention,0,
IDE03010-MAS04417,Number of prevented stop processes-Poor start detection,0,
IDE03010-MAS04589,Number of prevented stop processes-Diagnosis of exhaust system,0,
IDE03010-MAS04590,Number of prevented stop processes-Mixture adaptation,2,
IDE03010-MAS04591,Number of prevented stop processes-Air system diagnosis,0,
IDE03010-MAS04592,Number of prevented stop processes-Hybrid battery performance too low,0,
IDE03010-MAS04593,Number of prevented stop processes-Auxiliary equipment power consumption too high,0,
IDE03010-MAS04595,Number of prevented stop processes-Deceleration takeover active,0,
IDE03010-MAS04805,Number of prevented stop processes-Clutch protection K0,0,
IDE03010-MAS04870,Number of prevented stop processes-Thermostat testing not completed,0,
IDE03010-MAS05758,Number of prevented stop processes-Driving situation,11,
IDE03010-MAS06602,Number of prevented stop processes-Engine temperature,15,
IDE03010-MAS06605,Number of prevented stop processes-Regeneration Mode,0,
IDE03010-MAS06606,Number of prevented stop processes-Brake under pressure too low,0,
IDE03010-MAS08032,Number of prevented stop processes-DTC memory entry in engine control module,0,
IDE03010-MAS09416,Number of prevented stop processes-Learning function active,0,
IDE03010-MAS11563,Number of prevented stop processes-hood open,2,
IDE03010-MAS11835,Number of prevented stop processes-Function locked due to frequent stalling,0,
IDE03010-MAS12085,Number of prevented stop processes-Brake pedal information: plausibility,1,
IDE03010-MAS12864,Number of prevented stop processes-Slow traffic detected,0,
IDE03010-MAS13643,Number of prevented stop processes-E machine output too low,0,
IDE03010-MAS13644,Number of prevented stop processes-Engine protection active,0,
IDE03010-MAS13645,Number of prevented stop processes-Fuel gelling protection active,0,
IDE03010-MAS13661,Number of prevented stop processes-Exhaust treatment diagnosis,0,
IDE03010-MAS16918,Number of prevented stop processes-Restriction in start system,0,
IDE03011-MAS01627,Number of requested start processes-Steering,0,
IDE03011-MAS04369,Number of requested start processes-Engine temperature too high,0,
IDE03011-MAS04370,Number of requested start processes-Engine temperature too low,0,
IDE03011-MAS04416,Number of requested start processes-Sporadic function prevention,0,
IDE03011-MAS04592,Number of requested start processes-Hybrid battery performance too low,0,
IDE03011-MAS04593,Number of requested start processes-Auxiliary equipment power consumption too high,0,
IDE03011-MAS04595,Number of requested start processes-Deceleration takeover active,0,
IDE03011-MAS06606,Number of requested start processes-Brake under pressure too low,0,
IDE03011-MAS06607,Number of requested start processes-SCR System requires restart,0,
IDE03011-MAS09730,Number of requested start processes-CAT heating,0,
IDE03011-MAS11563,Number of requested start processes-hood open,0,
IDE03011-MAS11834,Number of requested start processes-Rolling vehicle,0,
IDE03011-MAS13644,Number of requested start processes-Engine protection active,0,
IDE03011-MAS13645,Number of requested start processes-Fuel gelling protection active,0,
IDE03011-MAS16918,Number of requested start processes-Restriction in start system,0,

 

[Hamid]

It's called end-to-end protection because there is often more than one transport "hop" between the sender and receiver(s) of the message payload.

In the simplest scenario, there could be software bugs or hardware-level memory corruption in the CAN gateway that relays messages between CAN buses. A message could be received with a valid transport-level CRC, experience a single bit flip while being copied, and be retransmitted with a different but valid transport-level CRC. Transport-level protection isn't enough.

There are also times when the same payload crosses different transports. For example, MLB/MLBevo with blended FlexRay and CAN network topology will need to translate some of the messages back and forth. As one example, it was noted during reverse-engineering of the Audi Q8 that Lane Assist over FlexRay is done with a message almost identical to HCA_01 as used on CAN, and continued to use the same payload-level CRC algorithm, though FlexRay itself uses entirely different transport-level protection.



I really don't know. I do know the AUTOSAR spec considers Profile 2 to be deprecated, but there are many other profiles.

All manufacturers seem to apply some level of payload-level protection, but some of them are pro-forma, like XOR or a true basic checksum. Older Volkswagen (PQ, prior to MQB) use XOR. Some manufacturers seem to apply a bit of security-through-obscurity. You can see examples of other manufacturers in that same opendbc file I linked you to earlier.

None of them are true cryptography, at least before AUTOSAR SecOC, and in the modern world there are reverse-engineering tools that make most of them trivial to figure out, and will do a lot of the busywork for you on the more complex/annoying ones.



There exist some CAN messages that update this way, for example Blinkmodi_02 for the turn signals. From memory, I think it updates at 2Hz plus edge triggering on state changes. There are others that shift rates depending on whether the function is active. As an example, HCA_01 sends at 1Hz unless lane guidance is active, and it then goes to 50Hz.

I can only speculate as to why Volkswagen chose a static frequency of 33Hz for GRA_ACC_01. They may have wanted faster fault detection, if the message goes missing (for example, due to a fault in the steering wheel clockspring) the Cancel button might cease to work.



The counter itself is intended to provide a little protection against replay of messages. This can happen, for example, if a CAN bus participant transmits a message but doesn't hear an ACK and sends it again, or otherwise gets in a loop transmitting the same message. This can happen due to either software or hardware faults.

Each CAN message has its own definition of tolerances: allowable time to wait for the first message at wake-up/power-on, allowable time between messages (expected rate), and allowable lost messages before declaring a fault. Those tolerances will vary greatly between messages.

I really appreciate all the detailed and helpful answers you provided—thank you for sharing your knowledge.