1. RV-ECU: Maximum Assurance In-Vehicle Safety Monitoring
Philip Daian, Grigore Rosu, Bhargava Manja, Runtime Verification Inc.
Shinichi Shiraishi, Toyota Info Technology Center USA Akihito Iwai, DENSO International America Inc.

2. Why Bother? What’s the goal of RV-ECU? Reduce or Avoid Recalls
Our attempt to tackle mentioned problems
Safety requirements not violated, dynamically updatable
Even if car is hacked (no distinction between hacked or malfunctioning ECU)
Easier compliance to ISO for safety
Safety monitors generated automatically (provably correct)
Enhanced communication between OEMs and suppliers
Formal safety specifications will be required and shared
Easier, better, faster testing
Separation of major concerns: safety versus functionality
Develop a component capable of monitoring and enforcing safety on vehicle communication networks
16AE-0158/

3. Some Background (you all already know)
Modern automobiles highly computerized, including dozens of Electronic Control Units (ECUs) communicating over the CAN bus
16AE-0158/

4. Some Background (you all already know)
Recall is an important unsolved problem in automotive
Recalls are costly ($2B+) and bad for business, and software related recalls are (increasingly) common
16AE-0158/

5. Some Background (you all already know)
More ECUs, more money on electronics, more features, more code
Source: "Automotive Embedded Software Verification and Validation Strategies", Shankar Akella, Emmeskay Advanced Technology Solutions
16AE-0158/

6. ISO comes on the scene
ISO changing the face of automotive: first functional safety standard, in response to growing software complexity trends
Both OEMs and suppliers scrambling for compliance
16AE-0158/

7. The Problem : A Summary Current state-of-the-art not ideal
Formal safety requirements not available
OEMs blame suppliers, suppliers blame OEMs
ECUs developed by suppliers; code not available
Poor CAN bus architecture
Any ECU can send messages to any other ECU
ECU sent messages cannot be stopped
16AE-0158/

8. One Solution : A Summary
Local
monitors
RV-ECU: in charge of monitoring global safety
Provably correct (both monitoring and recovery code)
ECUs locally monitored
Their critical CAN bus messages “approved” by local monitors
Local monitors communicate with RV-ECU
Local monitors achieved by instrumentation or API
RV-
Global
monitor
16AE-0158/

9. Local and Global Monitors
ECU
Usual ECU Code
ECU
RV-ECU
Local
monitor
CAN Bus
All monitoring code (red) generated automatically from safety requirements; recovery code verified
Monitoring code (red) checks if requirements are met during operation of system, enforces requirements when possible
Certifiably correct (checkable proofs also generated)
Local monitors added through instrumentation (automatically) or provided API, and can prevent ECU from misbehaving
Local ECUs consult with RV-ECU to assure global safety
Adding authentication (digital signatures, etc.) allows for more precise requirements to be specified
16AE-0158/

10. Local and Global Monitors
Informal requirements
Formal requirements
Safe door lock
Doors should always open only if they were unlocked in the past and not locked since then; at violation, close door.
…(hundreds of these)
 d : always (Open(d) implies
not Lock since UnLock)
@violation : Close(d)
Formalize requirements
(by domain experts,
using various formalisms;
here an interval logic)
Automatically
generated
Monitor for each d
// One such monitor instance
// in RV-ECU for each door d
State: one bit, b
b = UnLock || !Lock && b
if (Open && !b)
then send(Close)
Provably correct
16AE-0158/

11. The Hardware / Software : Current Status
Prototype RV-ECU on an STM ECU board (STM3210C-EVAL)
Working on a real car (model omitted)
controlling safety of wipers, windows, doors on the body CAN (B-CAN)
controlling safety of brakes and acceleration on engine CAN (F-CAN)
For the time being, local monitors intended to be as simple as just requesting acknowledgements for messages to be sent on the bus from RV-ECU
So RV-ECU does all monitoring, but local monitors ensure that safety violating messages are not sent
16AE-0158/

12. Can Formalized Properties Really Tackle Recall?
We surveyed past software- related recalls since 2010 with more than 10k cars, formalized properties for each
16AE-0158/

13. What is a Formalized Requirement?
This property can easily be formalized, corrected by a ERE-based monitor
ere : (cruise_control_start cruise_control_message* cruise_control_stop)*
@ fail {
CAN_DO(CruiseControl, Stop, 1); }
16AE-0158/

14. Demos! Body CAN, Engine CAN, and more!
Demo videos
We will now show body and F-CAN demos
Also available at runtimeverification.com/ecu
16AE-0158/

15. Wrap Up
Think about safety, avoiding recall in terms of formalizing what safety is
Formal requirements of bus communications can increasing safety in cars to be developed in our small company with SBIR funding from NSF, NASA, and research collaborations with automotive companies
Main insight: separate safety from functionality and take no chances with safety (use highest assurance known for it!)
Our architecture only one solution for formal global system safety
Through our system we seek a practical impact
We need partners to help us take this out of prototype phase
Come talk to us or visit us at runtimeverification.com!
Questions?
16AE-0158/