dependable and secure automotive cyber- physical systems ... · (uscar) is the umbrella...

Sharing technology for a stronger America

04/11/2011

Dependable and Secure Automotive Cyber-

Physical Systems

William MilamFord Motor Co.

Chair CPS Task Force

Sharing Technology for a Stronger America

What is USCAR?

The United States Council for Automotive Research LLC

(USCAR) is the umbrella organization for collaborative

research among Chrysler LLC, the Ford Motor Company and

the General Motors Corporation. Founded in 1992, the goal

of USCAR is to further strengthen the technology base of the

domestic auto industry through cooperative research and

development.


USCAR Mission

• Create, support and direct U.S. cooperative

research and development to advance automotive

technologies

• Be responsive to the needs of our environment and

society and include the appropriate public and

private stakeholders as required


Dependable and Secure Automotive Cyber-

Physical Systems

• Workshop was held in Troy Michigan on March 17 and 18.

• We had 97 registered participants from academia, government and industry.

• Breakout groups for:– Secure and High Confidence Platforms

– Open Experimental Platforms

– Driver in the Loop

– Safety Critical Design Process


Secure and High Confidence

Research Challenges• Software Complexity

– Impossible to validate sufficiently through testing as number and complexity of modules increases and need to be integrated

– New business-models with many suppliers and developers

• Assurance (Safety and reliability)– Cost effective Fail-Operational Systems

– Moving from Fail-Safe to Fail-Op

– Protect against common mode of failures

– (EMC, Power Supply, Lighting, …)

• Cyber-Physical Security– More connectivity into our vehicles

– More safety critical controls (towards autonomous driving and by-wire)

– Open-source platforms (for Infotainment)

– Open protocols: ODBII, Right to Repair


• 3-5 year:

• Model-based / Math-based design – Currently, components are modeled, but full vehicle environment not widely use.

– Formal methods are needed.

– Component integration and full vehicle not currently done.

• Integration methods including models, tools and data are needed.

• Formal Methods are currently only being used for research.

• Automated Validation and testing

• Run-Time Safety monitors / Safety Goals violation (current: – Current practice does not use full safety monitor model in run time.

– Separate requirements for safety monitor is still needed. Formal methods are needed.

• ISO-26262 Functional Safety deployment in process, but is not a complete solution.

Secure and High Confidence Platforms

Software Complexity Roadmap


• 5-10 yr:

– Self-Healing mechanisms

• This is not fault tolerance, it is low level software to take care of exceptions, for example buffer overflow. This is in research. The goal is for each control unit to do self checking to keep alive and fail predictably. Eventually new software uploads uploaded in 10 year timeframe. Ability of the system to apply fixes, predetermined.

• Fuzzy techniques to break down the system to model the interactions and/or entry points. Not currently used. Possible research topic.

• Automatic generation of system models from requirements or existing partial models.


Software Complexity Roadmap cont.


• 3-5 year:

• Fail Safe Platform with supervisor controller

– Some aspects of fail-operational included.

– Supervisor controller is part of the platform.

• System run-time diagnosis and Built in self test

• System Test and Validation

– Virtual validation, HIL, etc.


Assurance Roadmap


• 5-10 year:

• Formal analysis techniques

• Real-time analysis

• Probabilistic techniques

• Model-based testing and validation

• Moving from diagnosis to prognosis

– Predicting failure before it happens to avoid the malfunction

of the system/network.


Assurance Roadmap


• 10-20 year:

• Cost effective approach to Fail-operational

• The effects of architectures on Assurance, Safety and Security.

• Asymmetric redundancy management and correctness issue.

• Dynamic reconfiguration of functions (in distributed systems)

• Reconfigurable Hardware platforms

• Deterministic Redundant Platforms

– Networking (FlexRay , TT-Ethernet)

• Synchronization and scheduling

– ECU(s)

• Lessons learned from distributed world transfer to automotive

• Cyber-Physical System Co-design

– Combining physics based principles with computer science

– Resource Aware Control Methods

• Formal Methods

– Scalability

– Mixed modes (temporal vs discrete vs continuous)


Assurance Roadmap


• 3-5 year:

– Adapt existing IT security techniques to automotive industry.

• Low hanging fruit

– Identify threat models (threats, actors, etc…)

– Domain analysis

• Physics of problem need to be brought into the analysis.

– Develop a security specific automotive process

• Standards,

• Processes

• Tools

• culture


Security Roadmap


• 5-10 year:

– Adapt existing IT security techniques to automotive industry.

• Add rigor including more systematic methods (formal)

– Trusted Hardware and Software Platforms for CPS systems

– Secure V2x implementation and models

– Production ready tool chain.

– Supply chain and maintenance security solutions available.

– Refine threat models (threats, actors, etc…)

– Update Domain analysis

– Refine security specific automotive process


Security Roadmap


• 10-20 year:

• Predictive Threat tools developed

– Behavior analysis

– Systematic at a higher level

• Continue to follow security community trends

• Automatic updating of security measures

• Develop monitor and enforce higher levels of security.

• Trusted Hardware and Software Platforms for CPS systems

• Secure V2x implementation and models

• Production-ready tool chain (support process)

• Supply chain and maintenance security solutions available.


Security Roadmap


Open Experimental Platforms

What’s “Open”?• Data (subject to human subjects approval)

• Inputs

• Experiments– Methodology

– Results

– Algorithms, tools, analysis

– Design/development processes

– Observations

• Code/Models

• Interfaces (incl. what to buy for integration)

• Time or Access to system and sources

3/18/11 14



State of the Practice

• Localized development of open platforms (can be

used by others, but results not broadcast well).

• Lots of repeated work.

• Lots of work to keep components working in

integrated environment as other components

change.

• Lots of OEM subsystem models but difficult to

integrate efficiently into complete vehicle model.

3/18/11 15



Suggestions

• Work in the OEP must be precompetitive

• Approaches, and results, must be shared

• Work done on new feature functions

• Work is done a layer above proprietary info.

• Good results may result in auto manufacturer

entering into more 1-to-1 agreements

• Sites, not just vehicle(s), must be part of OEP

3/18/11 16


Open Experimental Platform

Issues with Tools and Methods• Virtual vehicle platform

– Content and fidelity driven by research questions

– Subsystem replacement to change fidelity (need proper interfaces)

– Validating abstractions/models

– “May” come from validating experiments

• Learning from other experiments/design process/verification & validation

– Suites of standard models

– Build/spec your simulation

– Black/white/grey box for certain components

• Methods

– Checking non-functional requirements

– Multi-level, traceability and interfaces at multiple levels

• Problems/Questions

– Non-synchronous model refinement/evolution

– Commercial or free models (e.g., CarSim)?

– How many physical vehicles to start with?

– Addressing interoperability (different manufacturers)

3/18/11 17


Open Experimental Platform

Research Roadmap and Milestones

• 2-3 years– Catalog of existing OEPs and components

– Determination of Institutional model

– Process to mature existing testbeds to institutional(s), or build new

• 3-5 years– First results validating approaches to challenge problems

• 10 years– Validated models for virtualization, “choose your system”

• 20 years– Extensions to other vehicle types

– Robust models

3/18/11 18


Safety Critical Design Process

Research Challenges

• Emergence: Competing (safety) goals of separately safe systems. E.g. ACC wants to speed up as the car ahead speeds up to avoid a merging vehicle, but a collision avoidance wants to slow down.

• Non-deterministic behavior - how do we learn from components and analyze/compose them?

• Requirements Analysis - In combinations of separately developed subsystems, how do we identify and handle conflicting and/or missing requirements, prior to integration level testing?

• ISO26262 is a functional safety (electrical/software) reference, but insufficient for total system safety. ISO is a quality office issue. How do we track the safety aspects beyond the scope of ISO-26262?



State of the Art• FMEA, Concept FMEA (inductive, like a top-down FTA), Design FMEA

(deductive, after a design is complete).

• USTAG required ISO26262 standard to include functional interaction failures

(emergent properties). This modified the original definition of safety analysis from

component failure to unsafe malfunction.

• VDA EGAS – German developed standard for throttle by wire, asymmetrical CPU

hardware monitoring (enhanced watchdog).

• Formal methods - inefficient for large scale systems

• Tools for system safety analysis (e.g. formal methods) are not commonly in use

by all engineers.

• Integrity monitoring is useful to safety

• Simulink/Stateflow is platform dependent and cannot verify timing

• Learn over time & retrofit (e.g. FAA).



Promising Opportunities for Research

• 3-5 Years

– Theories of Monitorability is an area to develop. Safety specification of the monitor, is

the system predictable, observable? What about in the presence of noise?

– Timing needs to be part of the V & V. Realtime guarantees of deliveries of packets for

sensor – extend this approach to the safety system and analysis.

• 10 Years

– Integration of different safety methods, tools, approaches.

– Integration of analyses, top-down (new functions) and bottom-up (legacy components,

new components)

• 20 Years

– Emergence: Competing (safety) goals of separately safe systems. E.g. ACC wants to

speed up as the car ahead speeds up to avoid a merging vehicle, but a collision

avoidance wants to slow down.



Education Based Recommendations

• CPS needs cross-disciplinary curricula inclusive of

safety.

• MechE's/ElecE's don't appreciate software safety

sufficiently. This leads to process failures if safety is

put off until the end when it is too late to make big

changes.

• We need to be able to find trained safety engineers.

Can there be a degree program developed?


Driver in the Loop (DITL)

Introduction

• DITL automotive system research studies the

system which integrates and cooperates the

driver with the vehicle’s cyber systems

through various degrees of autonomy ,

authority distribution, and systems interaction.

• DITL automotive system has multiple levels of

dynamic interaction (h2v, v2v,v2i, etc.).



Research Challenges

• Real-time driver state modeling

• Real-time/adaptive decision making

• Presentation of information (e.g., unambiguous communication to the driver)

• Dynamic authority distribution/level of autonomy

• Driver workload estimation (traffic, weather, vehicle, and road conditions)

• Multi-domain simulation capability for driver-vehicle interaction cross all traffic conditions

• Verification and validation

• Cooperative communications

• Fault-tolerance and automatic reconfiguration of the cyber system

• Transferring the decision making knowledge learned in DITL system to automotive systems with different degrees of autonomy (especially fully autonomous systems)



State of the Art/Practice• Pretty new area for automotive systems

• Lot of areas have been studied independently– Human-robot interaction

– Adjustable autonomy

– Pilot-in-the-loop

• This is not another human factor research, it studies a cyber-human interaction in real-time, dynamic , interactive environments for vehicle system control purpose

• We want to move the human modeling to the same level of dynamic models used by the other cyber-physics system

• DITL system is different from Pilot-in-the-loop system



Recommendations

• Recommend NSF/DOT to fund projects in this area

• Expand the current Engineering/CPS to include the other area such as computational neuroscience, cognitive science, etc.

• Establish a funding model to enable transition from NSF funded basic research to DOT funded applied research



Research Milestones• SHORT TERM

– Real-time driver state modeling

– Real-time/adaptive decision making

– Presentation of information (e.g., unambiguous communication to the driver)

– Dynamic authority distribution/level of autonomy

– Cooperative communications (V2V, V2I)

• INTERMEDIATE– Fault-tolerance and automatic reconfiguration of the cyber system

– Driver workload estimation (traffic, weather, vehicle, and road conditions)

• LONGTERM– Multi-domain simulation capability for driver-vehicle interaction cross all traffic

conditions

– Verification and validation

– Transferring the decision making knowledge learned in DITL system to automotive systems with different degrees of autonomy (especially fully autonomous systems)


USCAR Automotive Cyber Security Taskforce

Understand the software and communication

security landscape as it applies to vehicles.

Form research partnerships with academia,

business, and government focusing on

vehicle software and communication security.


LAST SLIDE!

Thanks for listening!

dependable and secure automotive cyber- physical systems ... · (uscar) is the umbrella...

Documents