SIRIUS A Drive-by-Wire University Project. Per Johannessen Chalmers University of Technology Volvo Car Corporation

Transcription

1 SIRIUS 2001 A Drive-by-Wire University Project Per Johannessen Chalmers University of Technology Volvo Car Corporation

2 Outline Background SIRIUS projects Control system evolution Design process Redundancy strategies Result

3 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

4 Drive-by-Wire Introduction Replacing mechanical linkages with electronics Braking-, steering-, suspension-, throttle-systems Functionality Safety Cost

5 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

6 SIRIUS 2001 Design Task Build a drive-by-wire car with four wheel steering and both right and left hand side steering November 2001

7 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

8 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

9 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

10 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

11 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

12 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 Physical Car Non-redundant HW-architecture Redundant HW-architecture

13 Functional Model Acceleration Driver Deacceleration Steering

14 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

15 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

16 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

17 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 Physical Car Non-redundant HW-architecture Redundant HW-architecture

18 Redundancy Strategy System Inherent redundancy Components Software redundancy Local redundancy

19 Redundancy Strategy System Inherent redundancy Inexpensive Components Software redundancy Expensive Local redundancy Utilize the system s redundancy top-down

20 Inherent Redundancy Examples Already in the system More actuators or sensors than degrees of freedom Challenge to identify and utilize Steer with wheel brakes

21 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

22 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

23 Scalable Software Redundancy Example Minimize communication Broadcast basic sensor data Allocate control to actuator nodes Increases fault tolerance for transient failures

24 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

25 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 Physical Car Non-redundant HW-architecture Redundant HW-architecture

26 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

27 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

28 SIRIUS Software Architecture

29 SIRIUS 2001 Network Topology

30 SIRIUS August 2001

31 SIRIUS Steer Types 2WS Parallell 4WS

32 SIRIUS Pure Driving Pleasure May 2001

33 SIRIUS 2001 A Drive-by-Wire University Project Per Johannessen perjohannessen johannessen@cechalmersse