SIRIUS 2001 - Chalmers · 94221-Per Johannessen TTPforum / 2003-08-04 SIRIUS Projects • SIRIUS is...

94221-Per JohannessenTTPforum / 2003-08-04

SIRIUS 2001SIRIUS 2001A Drive-by-A Drive-by-Wire UniversityWire University Project Project

Per JohannessenPer JohannessenChalmers Chalmers UniversityUniversity ofof TechnologyTechnology

Volvo Volvo Car CorporationCar Corporation


OutlineOutline

• Background

• SIRIUS projects• Control system evolution• Design process

• Redundancy strategies• Result


“Cars are driven by people. The guidingprinciple behind everything we make atVolvo, therefore, is - and must remain -

safety”

Gustaf Larson & Assar Gabrielsson

Volvo’s HeritageVolvo’s Heritage


Drive-by-Drive-by-WireWire – – IntroductionIntroduction

• Replacing mechanical linkageswith electronics

• Braking-, steering-, suspension-,throttle-systems

• Functionality• Safety• Cost


SIRIUS ProjectsSIRIUS Projects

• SIRIUS is a co-operative project between Volvo Car Corporationand Luleå University of Technology.

• SIRIUS aims at giving final year mechanical engineering studentsan opportunity to apply their skills and knowledge to realengineering problems.

• The students are expected to create designs which have thepotential to be adopted by Volvo Cars in the future.


SIRIUS 2001 – DesignSIRIUS 2001 – Design Task Task

Build a drive-by-wire car with four wheel steeringand both right and left hand side steering

November 2001


SIRIUS 2001 –SIRIUS 2001 – Organization Organization

• 41 MSME students• 2 PhD students as project leaders• Teachers at Luleå University• Engineers at Volvo Cars

Project Partners

Human Resources

~75.000 USDFunding


Sensor A

Sensor M

Sensor B

Sensor C

...

LocalControl

LocalControl

LocalControl

...

Actuator A

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 ControlTraditional Local Control


Sensor M'

Sensor A

Sensor M

Sensor B

Sensor C

...

LocalControl

LocalControl

LocalControl

...

Actuator A

Actuator B

Actuator N

...

LocalControl

• Subsystems are independently designed• Impossible to fully utilize the potential of the system• Costly to implement fault tolerance / redundancy

Traditional Local ControlTraditional Local Control


Sensor A

Sensor M

Sensor B

Sensor C

... Sen

sor F

usio

n

Glo

bal C

ontro

l

LocalControl

LocalControl

LocalControl

LocalControl

...

Actuator A

Actuator B

Actuator C

Actuator N

...

• Increases the possibilities in the design of the system• Increases the complexity in the system• Similar for many mechatronic systems

Global ControlGlobal Control


Guiding PrinciplesGuiding Principles

• Design the system as a whole, as opposed toindependently 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.


Physical Car

FunctionClass of Failure Failure Effects on System Severity

Acceleration Omission No acceleration available Car eventually stops MarginalCommission Sudden acceleration Car increases its speed rapidly CriticalStuck Constant acceleration Car increases its speed Critical

DeaccelerationOmission No deacceleration possible Car can't stop CatastrophicCommission Wheels lock Car stops during skidding CatastrophicStuck Constant deacceleration Car continues to brake Critical

Steering Omission No control of steering Car looses stability CatastrophicCommission Steering when unintended Car changes trajectory unintended CatastrophicStuck Car maintains its turning angleCar continues on its trajectory Critical

FFA

2

Design Task

Acceleration

Deacceleration

Steering

Driver

Use Case

1

Non-redundant HW-architecture

5

Redundant HW-architecture

6

6

6

DesignRequirements

3

RedundancyStrategies

Task Graph

4

5

Design ProcessDesign Process


Acceleration

Deacceleration

Steering

Driver

Functional ModelFunctional Model




Deacceleration Omission No deacceleration possible Car can't stop CatastrophicCommission Wheels lock Car stops during skidding CatastrophicStuck Constant deacceleration Car continues to brake Critical

Steering Omission No control of steering Car looses stability CatastrophicCommission Steering when unintended Car changes trajectory unintended CatastrophicStuck Car maintains its turning angle Car continues on its trajectory Critical

Design Requirements from Use Case and FFADesign Requirements from Use Case and FFA

Steering must fail in a stuck state.

Acceleration must fail in a omission state.

Braking must fail in a stuck state.

Acceleration

Deacceleration

Steering

Driver


Task GraphTask Graph

S1

SM

A1

A2

AN

S2......

T1

T2

T3

T4

T5

T6

Sensors Tasks Actuators

Acceleration

Deacceleration

Steering

Driver


S1 S2 SM

ANA1

......

S1

SM

A1

A2

AN

S2......

T1

T2

T3

T4

T5

T6

Wherever there isactuators or sensors,add a node.Low overhead cost.

A

A

AASS

S

SS

S

Non-redundant Hardware ArchitectureNon-redundant Hardware Architecture


Physical Car





FFA

2

Design Task

Acceleration

Deacceleration

Steering

Driver

Use Case

1


5


6

6

6

DesignRequirements

3


Task Graph

4

5



Redundancy StrategyRedundancy Strategy

System

Components

Local redundancy

Inherentredundancy

Software redundancy


Redundancy StrategyRedundancy Strategy

System

Components

Inexpensive

Expensive

Local redundancy

Inherentredundancy

Software redundancy

Utilize the system’s redundancy top-down


• Already in the system• More actuators or sensors than degrees of freedom• Challenge to identify and utilize

Steer withwheel brakes

Inherent Redundancy Inherent Redundancy –– Examples Examples



3 out of 4wheel brakes





3 out of 4wheel brakes


Brake withengine



• Minimize communication• Broadcast basic sensor data• Allocate control to actuator

nodes• Increases fault tolerance for

transient failures

Scalable Software Redundancy Scalable Software Redundancy –– Example Example


IntrinsicRedundancy

Sensor A

Sensor M

Sensor B

Sensor C

... Sen

sor F

usio

n

Glo

bal C

ontro

l

LocalControl

LocalControl

LocalControl

LocalControl

...

Actuator A

Actuator B

Actuator C

Actuator N

... LocalRedundancy

Scalable Software Redundancy

• A system approach supports a high degree of system utilization• Utilize redundancy in a top down approach

Global Control Redundancy StrategiesGlobal Control Redundancy Strategies


Physical Car





FFA

2

Design Task

Acceleration

Deacceleration

Steering

Driver

Use Case

1


5


6

6

6

DesignRequirements

3


Task Graph

4

5



S1 S2 SM

ANA1

......

S1

SM

A1

A2

AN

S2......

T1

T2

T3

T4

T5

T6

• Minimize communication• Use scalable SW redundancy

Task AllocationTask Allocation


SIRIUS – Hardware SIRIUS – Hardware ArchitectureArchitecture

Node_FL

Node_RL

Node_FR

Node_RR

Node_C1 Node_C2

s

b

s

b

s

b

s

b

c

t • Add hardware where required using statistical analysis and no-single-point of failure requirement


SIRIUS – SIRIUS – Software ArchitectureSoftware Architecture


SIRIUS 2001 – SIRIUS 2001 – Network TopologyNetwork Topology


SIRIUS – August 2001SIRIUS – August 2001


SIRIUS – SIRIUS – Steer TypesSteer Types

2WS Parallell 4WS


SIRIUS – SIRIUS – Pure Driving PleasurePure Driving Pleasure

May 2001


SIRIUS 2001SIRIUS 2001A Drive-by-A Drive-by-Wire UniversityWire University Project Project

Per JohannessenPer Johannessenper.per.johannessenjohannessen@@cece..chalmerschalmers.se.se

SIRIUS 2001 - Chalmers · 94221-Per Johannessen TTPforum / 2003-08-04 SIRIUS Projects • SIRIUS is...

Documents

Transcript of SIRIUS 2001 - Chalmers · 94221-Per Johannessen TTPforum / 2003-08-04 SIRIUS Projects • SIRIUS is...