RV-ECU: Maximum Assurance In-Vehicle Safety Monitoring Philip Daian, Bhargava Manja Runtime Verification Inc., USA Shin’ichi Shiraishi Toyota Info Technology Center Inc., USA Akihito Iwai DENSO International America Inc., USA Grigore Rosu University of Illinois at Urbana-Champaign and Runtime Verification Inc., USA Copyright c 2016 SAE International ABSTRACT The Runtime Verification ECU (RV-ECU) is a new de- velopment platform for checking and enforcing the safety of automotive bus communications and soft- ware systems. RV-ECU uses runtime verification, a formal analysis subfield geared at validating and ver- ifying systems as they run, to ensure that all manu- facturer and third-party safety specifications are com- plied with during the operation of the vehicle. By compiling formal safety properties into code using a certifying compiler, the RV-ECU executes only prov- ably correct code that checks for safety violations as the system runs. RV-ECU can also recover from vi- olations of these properties, either by itself in sim- ple cases or together with safe message-sending li- braries implementable on third-party control units on the bus. RV-ECU can be updated with new specifica- tions after a vehicle is released, enhancing the safety of vehicles that have already been sold and deployed. Currently a prototype, RV-ECU is meant to eventu- ally be deployed as global and local ECU safety mon- itors, ultimately responsible for the safety of the entire vehicle system. We describe its overall architecture and implementation, and demonstrate monitoring of safety specifications on the CAN bus. We use past automotive recalls as case studies to demonstrate the potential of updating the RV-ECU as a cost effec- tive and practical alternative to software recalls, while requiring the development of rigorous, formal safety specifications easily sharable across manufacturers, OEMs, regulatory agencies and even car owners. INTRODUCTION Modern automobiles are highly computerized, with 70 to 100 complex and interconnected electronic control units responsible for the operation of automotive sys- tems, and roughly 35 to 40 percent of the develop- ment cost of modern automobiles going towards soft- ware. In the next 10 years this number is expected to jump to between 50 and 80 percent, and even higher for hybrid vehicles. This will only be more true with the advent of autonomous vehicles [1, 2]. It is not surprising, then, that the automotive industry suffers from nearly every possible software fault and resulting error. Many unbelievable stories have hit the news, including cases where cars are hacked and re- motely controlled, including brakes and the engine, completely ignoring drivers input. In some cases prior physical access to the car was needed, in others the car was not even touched. Massive automobile re- calls in the past few years have been due to software bugs, costing billions [3, 4, 5, 6, 7, 8, 9]. Moreover, almost 80 percent of car innovations currently come from computer software, which has therefore become the major contributor of value in cars [1]. As software becomes more and more integral to the function and economics of vehicles, the safety and security of car software has taken center stage. LIMITATIONS OF CURRENT APPROACHES Tra- ditional software development quality processes rely on static analysis tools and techniques to improve the quality, security and reliability of their code. Static analysis tools analyze software code against a set 1
Transcript
RV-ECU: Maximum Assurance In-Vehicle Safety MonitoringPhilip Daian, Bhargava Manja
Runtime Verification Inc., USA
Shin’ichi ShiraishiToyota Info Technology Center Inc., USA
Akihito IwaiDENSO International America Inc., USA
Grigore RosuUniversity of Illinois at Urbana-Champaign and Runtime Verification Inc., USA
The Runtime Verification ECU (RV-ECU) is a new de-velopment platform for checking and enforcing thesafety of automotive bus communications and soft-ware systems. RV-ECU uses runtime verification, aformal analysis subfield geared at validating and ver-ifying systems as they run, to ensure that all manu-facturer and third-party safety specifications are com-plied with during the operation of the vehicle. Bycompiling formal safety properties into code using acertifying compiler, the RV-ECU executes only prov-ably correct code that checks for safety violations asthe system runs. RV-ECU can also recover from vi-olations of these properties, either by itself in sim-ple cases or together with safe message-sending li-braries implementable on third-party control units onthe bus. RV-ECU can be updated with new specifica-tions after a vehicle is released, enhancing the safetyof vehicles that have already been sold and deployed.
Currently a prototype, RV-ECU is meant to eventu-ally be deployed as global and local ECU safety mon-itors, ultimately responsible for the safety of the entirevehicle system. We describe its overall architectureand implementation, and demonstrate monitoring ofsafety specifications on the CAN bus. We use pastautomotive recalls as case studies to demonstratethe potential of updating the RV-ECU as a cost effec-tive and practical alternative to software recalls, whilerequiring the development of rigorous, formal safetyspecifications easily sharable across manufacturers,OEMs, regulatory agencies and even car owners.
INTRODUCTION
Modern automobiles are highly computerized, with 70to 100 complex and interconnected electronic controlunits responsible for the operation of automotive sys-tems, and roughly 35 to 40 percent of the develop-ment cost of modern automobiles going towards soft-ware. In the next 10 years this number is expected tojump to between 50 and 80 percent, and even higherfor hybrid vehicles. This will only be more true withthe advent of autonomous vehicles [1, 2].
It is not surprising, then, that the automotive industrysuffers from nearly every possible software fault andresulting error. Many unbelievable stories have hit thenews, including cases where cars are hacked and re-motely controlled, including brakes and the engine,completely ignoring drivers input. In some cases priorphysical access to the car was needed, in others thecar was not even touched. Massive automobile re-calls in the past few years have been due to softwarebugs, costing billions [3, 4, 5, 6, 7, 8, 9]. Moreover,almost 80 percent of car innovations currently comefrom computer software, which has therefore becomethe major contributor of value in cars [1]. As softwarebecomes more and more integral to the function andeconomics of vehicles, the safety and security of carsoftware has taken center stage.
LIMITATIONS OF CURRENT APPROACHES Tra-ditional software development quality processes relyon static analysis tools and techniques to improve thequality, security and reliability of their code. Staticanalysis tools analyze software code against a set
1
of known rules and heuristics and notify the opera-tor of warnings and violations. Nearly all companiesdeveloping a reasonably large code base use codequality tools. The reader interested in how static anal-ysis tools perform on automotive-related software isreferred to [10]. Even with all of the resources spenton these tools, software is still full of bugs and reliabil-ity weaknesses. This may be fine when the softwareis running on something as simple as a cell phone,or a laptop computer that your child uses for home-work, but this is unacceptable at best, and dangerousat worst, when the software runs in an automobile.
Model checking [11] is a complementary approachthat has found some use in the automotive industry.While rigorous and thorough, this approach suffersfrom serious drawbacks that make its use impractical.Besides the infamous ”state explosion” problem, themost significant drawback of model checking is the is-sue of model faithfulness. Models being used mustbe correct with regards to the system being inspectedand the environment it operates in. With the complex-ity of modern software and hardware systems, andthe (often) specificity of the models involved, greatcare must be taking in validating the model itself aswell as the system with regards to the model. This isan extremely error prone and time intensive process.A previous comparison of model checking to staticanalysis by a team heavily invested in finding bugsthrough model checking tools found that issues in themodel itself caused model checking to miss five errorscaught by static analysis, concluding that “the mainsource of false negatives is not incomplete models,but the need to create a model at all. This cost mustbe paid for each new checked system and, given finiteresources, it can preclude checking new code.” [12].Besides the model, the tool itself must also be trustedto properly verify the properties over the model, re-quiring either a highly-audited open source tool or an-other source of high confidence in the tool itself.
The portability of these models and specifications isalso dubious: any changes in the underlying systemrequire a correct change in the model, a non-trivialprocess that must be repeated often for complex sys-tems [11]. Equivalent specifications can thus have dif-ferent meanings based on the models being used.
While this does not matter if the model is spe-cific to some standard, such as a programming lan-guage [13], with many tools and applications of modelchecking this is not the case [14, 15]. So, while ex-pressive, models can be complex and non-portable.Overall, while model checking has the potential fordetecting deep and subtle errors, the requirement fora model introduces many restrictions and complexi-ties that make the tools difficult to manage and in-
tegrate effectively into most engineering teams, re-stricting their use to teams with high levels of formalexpertise and critical applications requiring the maxi-mum possible assurance, thus preventing widespreadadoption by the automotive industry as a whole.
ENABLING SAFETY STANDARDIZATION Anotherhurdle on the path to greater automotive safety isthe lack of standardized automotive safety specifica-tions. Because many specifications are informallyexpressed and never formalized, communication be-tween Tier 1 suppliers and their OEM partners is of-ten incomplete with regards to safety, producing com-ponents that may behave unpredictably in the sys-tem as a whole. Moreover, formalizations that existtend to be difficult or impossible to port between Tier1 suppliers. One clear industry need stemming fromverification-based development methodologies is theneed for portable formal safety specifications. Specifi-cations should be expressed in lightweight formalismsthat are easy to understand and communicate, andshould stay separate from the particular verificationapproach that is employed for their checking.
The RV-ECU runtime verification approach we pro-pose makes use of a model that is being automaticallyextracted as an abstraction of the executing system it-self, eliminating the need for expensive, heavyweight,non-faithful or non-portable models covering all thecorner cases of the implementation. This specifica-tion minimalism allows for reusable specifications thatcan also be used to minimally communicate preciserequirements between partners and vendors involvedin the development of the final automotive system.
Lastly, we observe that in currently developed auto-motive systems, both the safety and the functional-ity of the system and its components are consideredand implemented together, as part of the same de-velopment process. Because safety and function-ality are necessarily related to each other, this ap-pears to be logical. However, this intermixing of safetychecks in components that are primarily functionalrepresents a violation of the maximum possible sepa-ration of concerns in an ideal system architecture, inwhich safety would be considered and implementedseparately from the desired functionality, allowing fora clean separation that promotes both safety testingand rigorous reasoning about safety properties.
RV-ECU proposes and promotes an architecture thatachieves this separation of safety from functionality inthe vehicle, allowing them to be developed largely in-dependently and easing the burden on engineers re-sponsible for developing functionality while providinga rigorous toolset for safety checks to engineers andmanagers responsible for safety and compliance.
2
RUNTIME VERIFICATION
Runtime verification is a system analysis and ap-proach that extracts information from the running sys-tem and uses it to assess satisfaction or violation ofspecified properties and constraints [16]. Propertiesare expressed formally, as finite state machines, reg-ular expressions, linear temporal logic formulas, etc.These formal requirements are used to synthesizemonitors, and the existing code base is instrumentedwith these monitors. Runtime verification can be usedfor many purposes, including policy monitoring, de-bugging, testing, verification, validation, profiling, be-havior modification (e.g., recovery, logging), amongothers. In the development cycle, runtime verificationcan be used as a bug finding tool, a testing approach,a development methodology focusing on the creationof formally rigorous specifications, while in a produc-tion system it can be used as a component respon-sible for enforcing a set of safety requirements on asystem to preserve its global safety during operation.
Ideally, developers and software quality managerswould like to validate a system prior to its operationand release, in the coding and testing phases of thesoftware engineering lifecycle. This would allow max-imum assurance in the performance of the deployedsystem before release, increasing software depend-ability. However, as previously discussed, static val-idation methods such as model-checking [17] sufferfrom limits preventing their use in real large-scale ap-plications. For instance, those techniques are oftenbound to the design stage of a system and hencethey are not shaped to face-off specification evolution.Even when static analysis techniques do scale, theyare limited by the properties they can check, and maynot be able to check interesting behavioral properties.Thus, the verification of some properties, and elimina-tion of some faults, have to be complemented usingmethods relying on analysis of system executions.
Figure 1 shows an example of an automotive safetyspecification being compiled to code that enforces itat runtime using the technology underlying RV-ECU.The specification is called “safe door lock”, and is firststated in plain English informally, as safety require-ments are currently expressed. This is translated toa formal requirement manually by domain experts, asshown in the orange box using linear temporal logic:it is always the case that a valid door open event im-plies that there has not been a door lock since the lastunlock; a recovery action is attached that closes thedoor when a violation is detected (violation handler).
Previous efforts in the runtime verification field havefocused on the development of formalisms appropri-
ate for specifying expressive properties while syn-thesizing efficient monitors [18, 19, 20, 21, 22, 23],steering program and system executions to obtain de-sirable behaviors [24], combining runtime verificationwith other approaches including static analysis [25],minimizing runtime overhead to make monitoring de-ployed systems practical [22, 26], and integrating run-time verification with existing projects automaticallythrough both binary and source instrumentation, of-ten leveraging aspect-oriented programming [27, 28].
Because runtime verification is a relatively new field,the number of practical and commercial applicationsof the technology is less substantial than that of staticanalysis tools, model checkers, or deductive programverifiers. There have, however, been some practicalapplications of the theory of runtime enforcement forprogram safety and security [29, 30, 31], or to en-force access control policies at system runtime [32,33]. Runtime verification has also been applied to mo-bile applications to provide fine-grained permissionscontrols and enforce device security policies [34].
RV-ECU: A VEHICLE SAFETY ARCHITECTURE
Because the automotive industry develops some ofthe most widely deployed safety critical software ofany industry, it represents an ideal context where thebenefits of runtime verification can make a significantdifference. Runtime verification is one of the few tech-niques allowing for the complete separation of safetyand functionality concerns in the vehicle architecture.Towards this goal we introduce RV-ECU, a develop-ment platform, also referred to as a “workbench” ora “system” in the paper, for checking and enforcingthe safety of automotive bus communications. Forbrevity, whenever the context is non-ambiguous wetake the freedom to use the same name “RV-ECU” forany of its components or even for other componentsthat make use of code produced using RV-ECU.
At its core, RV-ECU consists of a compiler from for-mally defined safety specifications to monitoring coderunning on embedded control units. The safety spec-ifications can be designed in any known mathemati-cal formalism, with RV-ECU providing a plugin-basedsystem to enable the development of custom for-malisms for the specific automotive needs. Currently,some supported specifications languages include fi-nite state machines, regular expressions, linear tem-poral logic, and context-free grammars.
Figure 2 shows an overview of the RV-ECU method-ology, which takes formal specifications as input andfrom them automatically outputs code checking thesespecifications as well as a proof object certifying the
3
Figure 1: Example automotive specification being compiled into code that enforces it at runtime through RV-ECU
correctness of this code over the mathematical se-mantics of the specification formalism and of the un-derlying programming language. Thus, the code out-put by the RV-ECU compiler provides correctnessproof certificates of the monitoring code as well as ofthe recovering code which is executed when the orig-inal specification is violated. These certificates canbe checked in third party theorem proving software,providing the maximum known assurance guaranteesthat the code running on-device implements the givensafety specifications and their recovery handlers.
The benefits of the RV-ECU approach are numerous.In the design and production stage of the vehicle pro-duction lifecycle, use of RV-ECU can augment manualtesting, as the technique provides strong guaranteeswith regards to safety property violation and recov-ery. This can greatly simplify and speed up the testingcycle, saving many engineer man hours. RV-ECU’scompatibility with many formalisms and its function asa compiler to monitors completely decouples consid-erations of functionality from those of safety. Auto-motive software engineers are free to focus their ef-forts on code that enhances the functionality of soft-ware systems aboard the automobile, while safety en-gineers can focus on formalizing and testing safetyproperties. This decoupling allows for the develop-ment of modular and reusable safety formalisms thatcan easily be shared between automotive suppliersand OEMs. This can be revolutionary, as it ensurescompatibility in safety specifications between OEMsand Tier 1 suppliers. It even makes possible a stan-dardized database of formal safety properties main-tained and updated by state regulatory bodies.
GLOBAL AND LOCAL MONITORING Figure 3shows the RV-ECU system running on a vehicle. It isimportant to note that RV-ECU can be applied in twoplaces: the generated monitoring code can either runon a separate control unit to monitor the global trafficon the bus, or be integrated within an existing controlunit (e.g., the power steering ECU) to prevent it fromtaking unsafe actions. We therefore distinguish twocategories of monitors, with “global” monitors observ-ing the bus on a dedicated ECU and “local” monitorsobserving the bus from the perspective of an existingECU responsible for some functionality.
These global and local monitors can then further com-municate to increase their effectiveness. When usedtogether, the global monitors can track the state ofthe entire vehicle system, with local monitors track-ing only the state important to a particular controller.By communicating over the CAN bus, they are ableto share messages and commands, and the globalmonitor is able to instruct the local monitors to block
Figure 3: RV-ECU running both globally and locally,checking and enforcing vehicle system-wide safety.
or modify messages they may otherwise allow.
For simple testing and safety specifications involv-ing one component, local monitoring can be used.With complex or resource-intensive properties involv-ing multiple components, global monitoring can beused. A combination of these approaches can be ap-plied both in the testing cycle and the production auto-mobile, spanning the extremes between global mon-itoring of the entire system only with untrusted coderunning on individual components and local monitor-ing of specific components only with no global speci-fications or dedicated hardware. This flexibility allowsOEMs and Tier 1 suppliers to choose how and wherethey apply the runtime verification technology, allow-ing for incremental rollouts of local monitors at firstfollowed by the eventual implementation of a globalmonitor, or vice versa.
Figure 4 shows the ideal RV-ECU deployment, withall ECUs on the bus containing local monitors anda global monitor attached to the full system. In thisexample, no communication can flow between un-trusted, manually-written code implementing function-ality (highlighted in yellow) and the vehicle bus withoutapproval from high-assurance, provably correct, au-tomatically generated code implementing the safetyspecifications of the vehicle.
The use of RV-ECU therefore protects the overallsafety of the system from both malfunctioning con-trollers and malicious accesses (hackers), maintain-ing a set of safety invariants specified rigorously
5
Figure 4: RV-ECU protecting the CAN bus from unsafe messages
during the development of the vehicle. Moreover,the safety monitoring code generated by RV-ECUuses state-of-the-art techniques and algorithms de-veloped by the runtime verification community specif-ically aimed at minimizing runtime overhead.
CERTIFIABLE CORRECTNESS
As previously mentioned, the code generated by theRV-ECU system from safety specifications addition-ally carries proof certificates. Proof certificates aremathematical objects expressed as objects in the Coqautomated theorem proving assistant [35], a proof as-sistant that has been widely successfully applied todetect security flaws in popular software [36], provemathematical theorems [37], and create and provethe most complete currently certified C compiler [38].
The proof objects we provide will mathematicallyprove that the code we generate correctly implementsthe specification inputs provided, with regards to themathematical formal semantics of the programminglanguage itself. These proofs will be machine check-able by third party theorem proving tools includingbut not limited to Coq, providing multiple independentsources of assurance that the generated code is rig-orously correct. Such proof objects can also be usedin the context of certifying vehicle safety, with their for-mal rigor providing the maximum known standards forsoftware development in the context of rating develop-ment assurance in standards like ISO 26262.
RECALLS AND RV-ECU, A CASE STUDY
One of the key problems in the automotive industrywe believe will be helped by the RV-ECU technologyis a reduction in the required number of software re-calls, as well as a quicker and less costly responsewhen recalls must be performed. To demonstrate thisapplication of our technology, we consider previoussoftware-caused recalls in the automotive industry.
We do not have to look far to find good examples. Justa few months ago two security researchers unveiledan exploit that gave them full, remote access to the
CAN bus of the Chrysler Jeep Cherokee [39]. Thetwo researchers found an unauthenticated open porton the car’s Uconnect cellular network interface, andused this foothold, as well as the fact that firmware bi-naries were unsigned, to update the car’s networkinghardware over the air with a backdoored firmware thatgave them the ability to sniff CAN messages.
An unauthenticated SPI line between their back-doored chip and a CAN controller allowed them towrite arbitrary messages over the CAN bus. Theircontrol over the car was near total - they demon-strated complete wireless control over braking, thesound system, the driver display, door locks, AC,windshield wipers, steering (in reverse), and trans-mission [40]. They publicized their research, afterdisclosing the issue to regulators the car companiesinvolved, with a dramatic article in Wired magazine.A Wired journalist took a spin in a hacked car, whichthe researchers remotely drove into a ditch [39]. Thisannouncement created waves both in the automotiveindustry and among the general public, and continuesto inspire both continued media and public discussion,as well as safety legislation citation. The hack led toa recall of 1.4 million cars, the proposal of new vehi-cle cyber safety regulation in Congress, and a $400million drop in Fiat Chrysler’s market cap [41].
This incident highlights the deficiencies of the au-tomotive industry with regards to safety, and theadverse effects of informal software engineeringmethodology on both end consumers and the bot-tom line. Fiat was lucky in that the two security re-searchers chose to disclose this exploit. More exploitsalong the same vein are sure to exist. How then canruntime verification technology help automobile man-ufacturers improve vehicular safety?
In this specific case, RV-ECU could have come intoplay in multiple ways. The researchers mention intheir Blackhat conference paper that, to their surprise,while the Jeep’s firmware update mechanism was de-signed to be operated via the dashboard display, noth-ing prevented them from sending firmware updatecommands over the air, without authentication. Thisentire attack approach would have been rendered in-
6
valid with one simple global safety property formal-izing the requirement that firmware updates must bedriven from the dashboard display only.
This does not, however, deal with the more funda-mental problem that CAN traffic is unauthenticatedand multicast. This means that all an attacker needsto do to gain control over an automobile is gain accessto the CAN bus and impersonate legitimate ECUs.Through local and global monitors, RV-ECU easilyallows the implementation of authentication and au-thorization protocols as lightweight formalisms com-pletely orthogonal to the functionality of the softwarecomponents. In other words, the engineers develop-ing the code that achieves the desired functionality ofthe ECU need not worry about authentication, that be-ing added automatically by RV-ECU. This achieves aseparation of concerns that makes authentication andauthorization simpler and more portable.
Even if the researchers found a way past that, properformalization of vehicle safety would prevent manyof their attacks from taking place, even if they couldimpersonate legitimate ECUs. For example, the re-searchers gained complete control over the transmis-sion, and in a dramatic display of their work cut thetransmission while a Wired journalist took their car fora ride down an interstate in St. Louis. This attackcould have been rendered useless by formalizing thefollowing simple and common sense safety propertyof a vehicle: if a vehicle is traveling faster than somex miles an hour and the brake is not engaged, do notallow a shift into neutral gear. RV-ECU would assurethat, even if the attackers could send arbitrary CANmessages over the bus, any attempt to violate safetyspecifications would simply not work, thus maintain-ing the safety of the overall vehicle system even in thepresence of malicious actors and commands.
Even if such a specification were not preinstalled withthe vehicle, new safety specifications could cause thevehicle to be updated with the specification at a laterdate and protect all newly sold vehicles from exhibit-ing the same problem. With no impact on function-ality assuming correct operation of the specification,the costs to test, implement, and distribute the safetyupdates would be significantly less than that of adealership-based reflash of the entire ECU, a changedirectly affecting both the safety and the functionalityof the component.
A PRACTICAL DEMONSTRATION
The first step towards demonstrating the separationof functionality and safety on a vehicle architectureusing RV-ECU is the creation of a real-vehicle demo
showcasing our architecture monitoring a realistic butsimplified safety property.
Consider the following body-related property of doorsafety in a minivan, with electronic controllers thatopen the rear sliding doors in response to messagesover the CAN bus: Unless the driver has unlockedthe rear doors from the global vehicle lock/unlock con-trols, and the doors have not been locked since, themotor responsible for opening the doors should notdo so. The safety monitoring code of this property aswell as its automatic generation using the technologyunderlying RV-ECU have been illustrated in Figure 1.
It is not difficult to imagine a situation in which thisproperty could be violated. For example, with a mali-cious attacker gaining control of only the infotainmentsystem, connected to the body CAN bus, the mali-cious attacker could easily spoof a “rear door open”message while the vehicle is moving at high speeds toendanger the safety of any potential rear passengers.Alternatively, even in situations where no malicious at-tacker is present, a malfunctioning ECU connected tothe body bus anywhere in the car could create suchan unsafe situation by sending a message to the mo-tor to engage. Finally and most likely, a passengerseating in the rear seat may (mistakenly) push thedoor open button, which subsequently sends the mo-tor engage message. The last scenario above is ob-viously checked by almost all cars, likely using a pro-tocol implemented in the door ECU that sends data-collecting messages to other ECUs and then it sendsthe motor engage message only if it determines it issafe to do so. Not only that the door ECU is morecomplex than needs to be due to mixing functionalityand safety, but the overall systems is still unsafe, be-cause the other two scenarios can still happen. WithRV-ECU, all three scenarios above are treated thesame way, with a global monitor ECU in charge ofmonitoring the safety property possibly among tensor hundreds of other similar properties, and with anyother ECU free of developer-provided safety checkingcode. The overall system is simpler and safer.
Towards creating such a demo, we have obtained aSTM3210C-EVAL development board implementingthe popular STM32 embedded architecture. We aremimicking a minimal AUTOSAR-like API exclusivelyfor interacting with the CAN bus, and running our cer-tifiable high-assurance code to monitor and enforcethe previously mentioned property in a 2012 HondaOdyssey minivan. We intend to demonstrate it as partof our presentation in SAE 2016. Figure 5 shows ourdevelopment embedded board running on the CANbus of our demo vehicle, attached through a connec-tion in the driver’s side lock control unit.
7
Figure 5: RV-ECU development prototype connected to the body CAN bus of a 2012 Honda Odyssey
FUTURE WORK AND APPLICATIONS
The main focus of Runtime Verification, Inc., in thenear future is to gather real specifications and usecases for the RV-ECU technology and architecturefrom automotive customers and partners. We are ac-tively seeking customers and partners in this space,and aim to rapidly bring our technology to industry.
One unanswered research question regarding theproposed RV-ECU safety architecture, shared withother formal analysis methods in the automotive do-main, is what is the ideal formalism suited for math-ematically defining automotive properties. RuntimeVerification, Inc., will work with their automotive part-ners and customers to provide an intuitive domain-specific formal representation and associated pluginfor our system allowing safety engineers or man-agers to comfortably specify such properties, lower-ing the barrier to entry for our technology and facilitat-ing its uptake in industry. Such a plugin would likelyalso support the definition of real-time and temporalsafety properties to fully specify the range of possiblesafety specifications associated with a safety-criticalreal time system.
As part of this process, we are seeking an automotivemanufacturer or supplier willing to experiment with ourtechnology in their development environment, evalu-ating the benefits of our specification language, codegeneration infrastructure, and the general separationof safety and functionality we provide to the specifica-tion and monitoring of complex software systems.
TECHNICAL LIMITATIONS AND DRAWBACKS
There are several limitations and drawbacks raisedby the potential vehicle architecture we propose. Thefirst is the additional communications on the CAN busrequired between the local and global monitors. In theproposed architecture, traffic can be as much as dou-bled for safety critical messages when the RV-ECUacts as a relay point, as compared to when safety isnot checked at all. In an already overcrowded bus,such limitations could be prohibitive to the implemen-tation of our solution. To mitigate this, it is possibleto monitor properties primarily locally, monitoring onlyproperties involving multiple ECUs through the globalsafety monitor. It is worth noting that existing architec-tures also require a number of messages to be sentspecifically for checking safety, e.g., the door ECU re-questing data from other ECUs when the door openbutton is pushed; more research is needed to com-pare the number of messages that RV-ECU requiresversus the existing architectures. In the long term,our hope is that efforts aiming to replace the CANbus with faster and higher-throughput communicationstandards will allow for our additional communicationwithout overburdening the system.
Another key technical challenge for our technology isdeveloping a formalism and infrastructure capable ofhandling the real-time properties required by the au-tomotive industry. Because we have no access to theproprietary specifications currently used, we are un-able to develop such a system. We thus wish to startwith an architecture capable of handling non-real-timeproperties, extending it with real time support as is re-
8
quired to handle the needs of our customers.
The main risk in the adoption and development of run-time verification in automotive however lies in the de-velopment of accurate, rigorous specifications whichthe automotive industry does not currently have in thedevelopment process. With only a vague, often in-formal notion of formal system safety, the majority ofOEMs and suppliers have not fully and rigorously de-fined precisely what the safety of a vehicle systemconsists of. This initial effort to formalize the notionof safety in the vehicle may be cost prohibitive anddifficult, but remains necessary for the eventual cre-ation of a system with strong safety guarantees andhigh assurance. We believe this undertaking will havea positive effect on the automotive industry, providinga rigorous notion and understanding of what safetymeans in the context of the vehicle system. This rig-orous notion will help at every level of the develop-ment cycle, facilitating testing, development of newfunctionality, and regulatory certification.
One further and clear technical limitation of our ap-proach is its inability to protect from hardware faults.Because our approach operates at the software level,any flaws in the CAN driver being used or the hard-ware of any individual ECU can still cause prob-lems undetectable and unforeseen by the specifica-tion monitoring system. While the former can be mit-igated by full verification of the CAN driver, a moretraditional fault detection approach is likely more suit-able for detecting faults in the actuators, sensors, andprocessing hardware involved in the vehicle system.
It is also important to note that extensive full-vehicletesting will still be required despite the presence ofour safety architecture. The effects of our monitoringcode and the effects of the interactions of the spec-ification monitors with the full system cannot be de-termined without testing. We hope that with rigorous,checkable specifications and descriptive error condi-tions, our system will speed the testing cycle for safetyrequirements by allowing rapid evaluation of the sys-tem against its stated requirements. Despite this, rig-orous conventional testing is still required to maintainthe safety of the full vehicle system.
Lastly, there is a risk that our specifications willthemselves introduce safety risks in the system: ifthe specifications are inaccurate, unforseen circum-stances can create unexpected programmatic behav-iors actually detrimental to the safety of the system.For example, in Figure 4, a monitor could theoreti-cally override or exclude a message by the controllerit incorrectly believes to be unsafe, which would itselfcause safety problems in the vehicle. While this isundoubtedly possible, our belief is that any unforseen
behaviors in the formal specifications provided couldjust as readily be present in the code itself, whichimplements informal specifications. Formalizing thespecifications implicit in the current codebase rigor-ously will not inherently introduce unforseen behav-iors, and we expect that such formal rigor in the test-ing phase will actually help reveal previously uncon-sidered safety-critical interactions. In the cases wherethere are unintended interactions between the moni-tors and the system itself, traditional testing should beable to reveal them at least as readily as it reveals in-consistencies between actual and expected behaviorin current systems.
CONCLUSION
Thus, we claim that separating safety and function-ality in the modern automobile system would helpfind software bugs early in development, avoid recalls,and improve communication between original equip-ment manufacturers and their suppliers. We proposeruntime verification as one solution allowing for thisseparation, and introduce a potential architecture forrealizing such a practical separation.
We see that specifications checked at runtime can beboth concise and formally precise, allowing for theirdevelopment by engineers and managers not trainedin formal methods while ensuring they are modularand easily sharable. We implement such a systemwith a practical demonstration of a simplified bodysafety property, and lay out the roadmap for futurework enabled by the separation of safety and function-ality. We discuss the technical limitations and draw-backs of our approach, including resource overhead,incomplete specifications, and an inability to deal withlow level hardware faults.
Overall, we seek to develop a commercial product us-able by the automotive industry to add runtime verifi-cation to vehicles, both in the testing and developmentcycles and in production. We intend to partner withinterested parties towards the development of such asystem, and target it to suit the needs of our partnersand customers.
ACKNOWLEDGEMENTS
We would like to thank our partners at Toyota InfoTechnology Center, Inc., and DENSO InternationalAmerica, Inc., for their collaboration, industry insight,and generous funding. We would also like to thank theNational Science Foundation and NASA for fundingwork related to this project under SBIR (small busi-ness development) grants.
9
Further assistance for this work was provided byresearch and development performed at the For-mal Systems Laboratory of the University of Illinoisat Urbana-Champaign, including funding from NSF,NASA, DARPA, NSA, and Boeing grants.
References
[1] Robert N Charette. “This car runs on code.” In:IEEE Spectrum 46.3 (2009), p. 3.
[2] Shinichi Shiraishi and Mutsumi Abe. “Auto-motive system development based on col-laborative modeling using multiple adls.” In:ESEC/FSE 2011 (Industial Track) (2011).
[3] Larry P. Vellequette. Fiat Chrysler recalls 1.4million vehicles to install anti-hacking software.http : / / www . autonews . com / article /
20150724/OEM11/150729921/fiat-chrysler-
recalls - 1 . 4 - million - vehicles - to -
install-anti-hacking.
[4] Christiaan Hetzner. VW ordered to recall 2.4million cars in Germany with cheat software.http : / / www . autonews . com / article /
20151015/COPY01/310159986/vw- ordered-
to-recall-2-4-million-cars-in-germany-
with-cheat-software.
[5] Reuters. Toyota recalls 625,000 cars over soft-ware malfunction. http : / / www . dw . com /
[14] NuSMV Home Page. http://nusmv.fbk.eu/.Accessed: 2014-05-17.
[15] UPPAAL: Academic Home. http : / / www .
uppaal.org/. Accessed: 2014-05-17.
[16] Klaus Havelund and Grigore Rosu. “Preface:Volume 55, Issue 2.” In: Electronic Notes inTheoretical Computer Science 55.2 (2001),pp. 287–288.
[17] E. Allen Emerson and Edmund M. Clarke.“Characterizing Correctness Properties of Par-allel Programs Using Fixpoints.” In: Proceed-ings of the 7th Colloquium on Automata,Languages and Programming. Springer-Verlag,1980, pp. 169–181. ISBN: 3-540-10003-2.
[18] Klaus Havelund and Grigore Rosu. “Monitor-ing Programs Using Rewriting.” In: 16th IEEEInternational Conference on Automated Soft-ware Engineering (ASE 2001), 26-29 Novem-ber 2001, Coronado Island, San Diego, CA,USA. IEEE Computer Society, 2001, pp. 135–143. ISBN: 0-7695-1426-X. DOI: 10.1109/ASE.2001.989799.
[19] Amir Pnueli and Aleksandr Zaks. “PSL ModelChecking and Run-Time Verification ViaTesters.” In: FM 2006: Formal Methods, 14thInternational Symposium on Formal Meth-ods, Hamilton, Canada, August 21-27, 2006,Proceedings. Ed. by Jayadev Misra, TobiasNipkow, and Emil Sekerinski. Vol. 4085. Lec-ture Notes in Computer Science. Springer,2006, pp. 573–586. ISBN: 3-540-37215-6. DOI:10.1007/11813040_38.
[20] Andreas Bauer, Martin Leucker, and ChristianSchallhart. “The Good, the Bad, and the Ugly,But How Ugly Is Ugly?” In: Runtime Verifica-tion, 7th International Workshop, RV 2007, Van-couver, Canada, March 13, 2007, Revised Se-lected Papers. Ed. by Oleg Sokolsky and Ser-dar Tasiran. Vol. 4839. Lecture Notes in Com-puter Science. Springer, 2007, pp. 126–138.ISBN: 978-3-540-77394-8. DOI: 10.1007/978-3-540-77395-5_11.
[21] Howard Barringer, Klaus Havelund, David E.Rydeheard, and Alex Groce. “Rule Systems forRuntime Verification: A Short Tutorial.” In: Run-time Verification, 9th International Workshop,RV 2009, Grenoble, France, June 26-28, 2009.Selected Papers. 2009, pp. 1–24. DOI: 10 .
1007/978-3-642-04694-0_1.
[22] Feng Chen and Grigore Rosu. “ParametricTrace Slicing and Monitoring.” In: Tools andAlgorithms for the Construction and Analy-sis of Systems, 15th International Conference,TACAS 2009, Held as Part of the Joint Euro-pean Conferences on Theory and Practice ofSoftware, ETAPS 2009, York, UK, March 22-29,2009. Proceedings. Ed. by Stefan Kowalewskiand Anna Philippou. Vol. 5505. Lecture Notesin Computer Science. Springer, 2009, pp. 246–261. ISBN: 978-3-642-00767-5. DOI: 10.1007/978-3-642-00768-2_23.
[23] Howard Barringer and Klaus Havelund. “Inter-nal versus External DSLs for Trace Analysis -(Extended Abstract).” In: Runtime Verification- Second International Conference, RV 2011,San Francisco, CA, USA, September 27-30,2011, Revised Selected Papers. 2011, pp. 1–3. DOI: 10.1007/978-3-642-29860-8_1.
[24] Moonjoo Kim, Insup Lee, Usa Sammapun,Jangwoo Shin, and Oleg Sokolsky. “Monitor-ing, Checking, and Steering of Real-Time Sys-tems.” In: Electr. Notes Theor. Comput. Sci.70.4 (2002), pp. 95–111. DOI: 10.1016/S1571-0661(04)80579-6.
[25] Eric Bodden, Laurie J. Hendren, Patrick Lam,Ondrej Lhotak, and Nomair A. Naeem. “Col-laborative Runtime Verification with Trace-matches.” In: Runtime Verification, 7th Interna-tional Workshop, RV 2007, Vancouver, Canada,March 13, 2007, Revised Selected Papers.Ed. by Oleg Sokolsky and Serdar Tasiran.Vol. 4839. Lecture Notes in Computer Science.Springer, 2007, pp. 22–37. ISBN: 978-3-540-77394-8. DOI: 10.1007/978- 3- 540- 77395-5_3.
[26] Feng Chen and Grigore Rosu. “Mop: an ef-ficient and generic runtime verification frame-work.” In: Proceedings of the 22nd Annual ACMSIGPLAN Conference on Object-Oriented Pro-gramming, Systems, Languages, and Applica-tions, OOPSLA 2007, October 21-25, 2007,Montreal, Quebec, Canada. Ed. by Richard P.Gabriel, David F. Bacon, Cristina Videira Lopes,and Guy L. Steele Jr. ACM, 2007, pp. 569–588. ISBN: 978-1-59593-786-5. DOI: 10.1145/1297027.1297069.
[27] Volker Stolz and Eric Bodden. “Temporal As-sertions using AspectJ.” In: Electr. Notes Theor.Comput. Sci. 144.4 (2006), pp. 109–124. DOI:10.1016/j.entcs.2006.02.007.
[28] Justin Seyster, Ketan Dixit, Xiaowan Huang,Radu Grosu, Klaus Havelund, Scott A. Smolka,Scott D. Stoller, and Erez Zadok. “Aspect-Oriented Instrumentation with GCC.” In: Run-time Verification - First International Confer-ence, RV 2010, St. Julians, Malta, November 1-4, 2010. Proceedings. 2010, pp. 405–420. DOI:10.1007/978-3-642-16612-9_31.
[29] Mads Dam, Bart Jacobs, Andreas Lundblad,and Frank Piessens. “Security Monitor Inliningfor Multithreaded Java.” In: Genoa: Proceedingsof the 23rd European Conference on ECOOP —Object-Oriented Programming. 2009, pp. 546–569. ISBN: 978-3-642-03012-3.
[30] Irem Aktug, Mads Dam, and Dilian Gurov.“Provably Correct Runtime Monitoring.” In: FM’08: Proceedings of the 15th int. symposiumon Formal Methods. Turku, Finland, 2008,pp. 262–277. ISBN: 978-3-540-68235-6.
[31] Ulfar Erlingsson and Fred B. Schneider. “SASIenforcement of security policies: a retrospec-tive.” In: NSPW ’99: workhop on New securityparadigms. 2000, pp. 87–95. ISBN: 1-58113-149-6.
[32] Horatiu Cirstea, Pierre-Etienne Moreau, andAnderson Santana de Oliveira. “Rewrite BasedSpecification of Access Control Policies.” In:Electron. Notes Theor. Comput. Sci. 234(2009), pp. 37–54. ISSN: 1571-0661. DOI: http://dx.doi.org/10.1016/j.entcs.2009.02.
071.
[33] Anderson Santana de Oliveira, Eric Ke Wang,Claude Kirchner, and Helene Kirchner. “Weav-ing rewrite-based access control policies.” In:FMSE’07: Proceedings of the ACM workshopon Formal Methods in Security Engineering.2007, pp. 71–80.
[34] Ylies Falcone, Sebastian Currea, and Mo-hamad Jaber. “Runtime verification and en-forcement for Android applications with RV-Droid.” In: Runtime Verification. Springer. 2013,pp. 88–95.
[35] ProofObjects: Working with Explicit Evidencein Coq. http : / / www . cs . cornell . edu /
