SIRIUS 2001 A Drive-by-Wire University Project Per Johannessen Chalmers University of Technology Volvo Car Corporation
Outline Background SIRIUS projects Control system evolution Design process Redundancy strategies Result
Volvo s Heritage Cars are driven by people The guiding principle behind everything we make at Volvo, therefore, is - and must remain - safety Gustaf Larson & Assar Gabrielsson
Drive-by-Wire Introduction Replacing mechanical linkages with electronics Braking-, steering-, suspension-, throttle-systems Functionality Safety Cost
SIRIUS Projects SIRIUS is a co-operative project between Volvo Car Corporation and Luleå University of Technology SIRIUS aims at giving final year mechanical engineering students an opportunity to apply their skills and knowledge to real engineering problems The students are expected to create designs which have the potential to be adopted by Volvo Cars in the future
SIRIUS 2001 Design Task Build a drive-by-wire car with four wheel steering and both right and left hand side steering November 2001
SIRIUS 2001 Organization Project Partners Human Resources Funding 41 MSME students 2 PhD students as project leaders Teachers at Luleå University Engineers at Volvo Cars ~75000 USD
Traditional Local Control Sensor A Sensor B Local Control Actuator A Sensor C Sensor M Local Control Local Control Actuator B Actuator N Subsystems are independently designed Impossible to fully utilize the potential of the system Costly to implement fault tolerance / redundancy
Traditional Local Control Sensor A Sensor B Local Control Actuator A Sensor C Sensor M Sensor M' Local Control Local Control Local Control Actuator B Actuator N Subsystems are independently designed Impossible to fully utilize the potential of the system Costly to implement fault tolerance / redundancy
Global Control Sensor A Local Control Actuator A Sensor B Sensor C Sensor Fusion Global Control Local Control Local Control Actuator B Actuator C Sensor M Local Control Actuator N Increases the possibilities in the design of the system Increases the complexity in the system Similar for many mechatronic systems
Guiding Principles Design the system as a whole, as opposed to independently designed subsystems Utilize redundancy top-down at all levels All components / sub-systems will fail, sooner or later Minimize hardware, additional hardware increases cost, failure rate and complexity
Design Process Function Class of Failure Failure Effects on System Severity Design Task 1 Acceleration Driver Deacceleration Steering Use Case 4 2 Acceleration Omission No acceleration available Car eventualy stops Marginal Commission Sudden acceleration Car increases its speed Critical rapidly Stuck Constant acceleration Car increases its speed Critical DeaccelerationOmission No deacceleration possible Car can't stop Catastrophic Commission Wheels lock Car stops during Catastrophic skidding Stuck Constant deacceleration Car continues to brake Critical Steering Omission No control of steering Car looses stability Catastrophic Commission Steering when unintended Car changes trajectory unintended Catastrophic anglecar continues on its trajectory Critical Stuck Car maintains its turning FFA 3 Design Requirements 6 Task Graph 5 Redundancy Strategies 6 5 6 Physical Car Non-redundant HW-architecture Redundant HW-architecture
Functional Model Acceleration Driver Deacceleration Steering
Design Requirements from Use Case and FFA Driver Acceleration Deacceleration Steering Function Class of Failure Failure Effects on System Severity Acceleration Omission No acceleration available Car eventually stops Marginal Commission Sudden acceleration Car increases its speed rapidly Critical Stuck Constant acceleration Car increases its speed Critical Deacceleration Omission No deacceleration possible Car can't stop Catastrophic Commission Wheels lock Car stops during skidding Catastrophic Stuck Constant deacceleration Car continues to brake Critical Steering Omission No control of steering Car looses stability Catastrophic Commission Steering when unintended Car changes trajectory unintended Catastrophic Stuck Car maintains its turning angle Car continues on its trajectory Critical Acceleration must fail in a omission state Braking must fail in a stuck state Steering must fail in a stuck state
Task Graph Acceleration Driver Deacceleration Steering Sensors Tasks Actuators S 1 T 1 T 3 A 1 S 2 T 5 T 2 S M T 4 T 6 A 2 A N
Non-redundant Hardware Architecture S 1 T 1 T 3 A 1 S 2 T 2 S M T 4 T 5 T 6 A 2 A N Wherever there is actuators or sensors, add a node Low overhead cost A S A S S A S S A S S 1 S 2 S M A 1 A N
Design Process Function Class of Failure Failure Effects on System Severity Design Task 1 Acceleration Driver Deacceleration Steering Use Case 4 2 Acceleration Omission No acceleration available Car eventualy stops Marginal Commission Sudden acceleration Car increases its speed Critical rapidly Stuck Constant acceleration Car increases its speed Critical DeaccelerationOmission No deacceleration possible Car can't stop Catastrophic Commission Wheels lock Car stops during Catastrophic skidding Stuck Constant deacceleration Car continues to brake Critical Steering Omission No control of steering Car looses stability Catastrophic Commission Steering when unintended Car changes trajectory unintended Catastrophic anglecar continues on its trajectory Critical Stuck Car maintains its turning FFA 3 Design Requirements 6 Task Graph 5 Redundancy Strategies 6 5 6 Physical Car Non-redundant HW-architecture Redundant HW-architecture
Redundancy Strategy System Inherent redundancy Components Software redundancy Local redundancy
Redundancy Strategy System Inherent redundancy Inexpensive Components Software redundancy Expensive Local redundancy Utilize the system s redundancy top-down
Inherent Redundancy Examples Already in the system More actuators or sensors than degrees of freedom Challenge to identify and utilize Steer with wheel brakes
Inherent Redundancy Examples Already in the system More actuators or sensors than degrees of freedom Challenge to identify and utilize Steer with wheel brakes 3 out of 4 wheel brakes
Inherent Redundancy Examples Already in the system More actuators or sensors than degrees of freedom Challenge to identify and utilize Steer with wheel brakes 3 out of 4 wheel brakes Brake with engine
Scalable Software Redundancy Example Minimize communication Broadcast basic sensor data Allocate control to actuator nodes Increases fault tolerance for transient failures
Global Control Redundancy Strategies Sensor A Local Control Actuator A Intrinsic Redundancy Sensor B Sensor C Sensor M Sensor Fusion Global Control Local Control Local Control Local Control Actuator B Actuator C Local Redundancy Actuator N Scalable Software Redundancy A system approach supports a high degree of system utilization Utilize redundancy in a top down approach
Design Process Function Class of Failure Failure Effects on System Severity Design Task 1 Acceleration Driver Deacceleration Steering Use Case 4 2 Acceleration Omission No acceleration available Car eventualy stops Marginal Commission Sudden acceleration Car increases its speed Critical rapidly Stuck Constant acceleration Car increases its speed Critical DeaccelerationOmission No deacceleration possible Car can't stop Catastrophic Commission Wheels lock Car stops during Catastrophic skidding Stuck Constant deacceleration Car continues to brake Critical Steering Omission No control of steering Car looses stability Catastrophic Commission Steering when unintended Car changes trajectory unintended Catastrophic anglecar continues on its trajectory Critical Stuck Car maintains its turning FFA 3 Design Requirements 6 Task Graph 5 Redundancy Strategies 6 5 6 Physical Car Non-redundant HW-architecture Redundant HW-architecture
Task Allocation S 1 T 1 T 3 A 1 S 2 T 5 T 2 S M T 4 T 6 A 2 A N Minimize communication Use scalable SW redundancy S 1 S 2 S M A 1 A N
SIRIUS Hardware Architecture s c Node_FL Node_C1 Node_C2 t Node_FR s Add hardware where required using statistical analysis and no-single-point of failure requirement b b s s Node_RL Node_RR b b
SIRIUS Software Architecture
SIRIUS 2001 Network Topology
SIRIUS August 2001
SIRIUS Steer Types 2WS Parallell 4WS
SIRIUS Pure Driving Pleasure May 2001
SIRIUS 2001 A Drive-by-Wire University Project Per Johannessen perjohannessen johannessen@cechalmersse