We can’t afford to consider sensors without also considering the systems in which they operate. System designers must safeguard system operations while striking the right balance in terms of alerts shared with drivers.
From a hardware perspective, preventing unintended activities comes down to ensuring that silicon chips, as well as the high-speed interfaces transferring the data to ECUs, are protected from exploitation. In a vehicle, each sensor typically has its own dedicated ECU. The challenge, for both hardware designers and software developers, is that sensors in the field are expected to receive “dirty” data; however, they need to have the logic to discern what is dirty and what is not. In other words, they cannot rely on the user or the backend to discern the data for them.
When something does go wrong due to a security breach, most systems today don’t have a really good way to communicate that an error occurred. Consider ADAS, which is designed to warn drivers of impending dangers on the road as well as potential system failures—early enough so that the driver (or the vehicle) can take appropriate action. There’s a delicate balance in terms of the amount of information to provide to the driver. It’s important not to limit the information provided to prevent user errors due to information overflow. At best, incidents are often flagged internally to be investigated at a future date if the log is ever retrieved, normally due to an accident. Usually, such system errors or failures trigger a recall that requires a trip to the dealership and, for the carmaker, a potentially expensive fix. A better approach would be to build in the security to prevent a malicious act from causing the error in the first place.