Low Carbon Vehicle Technology Program Workstream 6: Vehicle Supervisory Control (VSC) Date: 18 th May 2011 Speaker: Cian Harrington, Cranfield University Workstream team members: Jaguar Land Rover, Ricardo, WMG, MIRA, Cranfield University, Coventry University, TMETC
LCVTP Workstream 6 Vehicle Supervisory Controller (VSC) Aim: To design the next generation Vehicle Supervisory Controller (VSC) system that is scalable and transferable between different types of Hybrid and Electric Vehicles to avoid major re-design for each Hybrid/Electric vehicle program. Workstream Objectives: To develop the potential architectures, safety strategies, hardware design, simulation models, controls software and diagnostics strategy for the next generation of VSC. Benefits: Re-using common software and hardware parts for different Hybrid and Electric Vehicle types optimises development, reduces integration effort & costs resulting in lower overall program costs and faster time to market.
LCVTP Workstream 6 VSC Development Generic Series Hybrid Architecture Safety Strategy Functional Safety Concept ISO 26262 Safety Requirements VSC Diagnostics Design FMEA Countermeasures Plausibility Checks VSC ECU VSC Controls Power Manager Driver Evaluator Demand & Split Arbitration Instantaneous Optimisation Predictive Optimisation
LCVTP Workstream 6 Project Partners Partner Area of Responsibilities Workstream Leader & VSC Requirements Cascade VSC Hardware Design Vehicle Simulation & Modelling VSC Diagnostics Strategy & Development Hybrid Safety Strategy VSC Diagnostics Development VSC Architecture & Software Development VSC Controls Software Development & Support
LCVTP Workstream 6 Project Status & Milestones Date February 2010 July 2010 December 2010 July 2011 Milestones Project Kick-Off Technology Selection Concept Readiness Application Readiness 30 th November 2011 Project Completion
VSC Hardware Design Approach Use a 32 bit automotive microprocessor. > Consider microprocessor development roadmaps for future upgrades. Include as much memory as possible to allow for enhanced functionality on future vehicles. Re-use existing circuit modules from other Ricardo projects where possible. > Mainly from Ricardo rapid prototyping system Micrcontroller, communication buses & some I/O. Under bonnet application.
External Connectors External Connectors VSC Hardware Design Block Diagram CIC61508 Supervisor Infineon 32 bit microcontroller & power supply IC Four CAN buses 6 36V Power Supply Two Flexray buses Analogue Inputs 0.5A Low Side Outputs 2 LIN buses Thermistor Inputs Internal Analogue Measurements 3A Low Side Outputs 10A Low Side Outputs 35 digital inputs Digital Inputs 50mA High Side Outputs 24 analogue inputs with 2 sensor supplies External Event Triggers Rotational Sensor Inputs TC1797 Microcontroller 3A High Side Outputs 150mA PWM Push-Pull Side Outputs 1 H bridge Signal Inputs H-Bridge Output 12 high side outputs (various current levels) CAN bus Analogue Outputs Flexray Power Outputs 25 low side outputs (various current levels) LIN Bus 5V Sensor Supplies 6 push pull outputs RS232 Serial Comms JTAG Interface Debug Port 3 analogue outputs
VSC Hardware Safety Strategy Based on CIC61508 safety companion IC. > Under-voltage and over-voltage shutdown. > The safety path is controlled by an error counter mechanism and system state machine. > Three levels of system disable signals can be defined to trigger after the error counter reaches pre-defined values. > Propose that these signals are used to: Disable communication buses. Disable Enable signals to other electronic modules. Disable a system relay which supplies power to loads controlled by the VSC.
VSC Hardware Mechanical Design Prototype only. Parts machined from solid. Thermal dissipation through conduction and convection. Sealed. Approximate dimensions 300 mm x 200 mm x 45 mm.
Simulation & Modelling Development Environment Initial JLR REEV model developed from WARPSTAR basis > Being validated against Limo-Green (REEV) test results > Basis for shared model across workstreams
Simulation & Modelling Deployment Control Model Optional Carmaker Interface Dymola Plant Model Simulation Results
Simulation & Modelling Hardware-In-Loop HIL Platform running LCVTP full vehicle model in real-time
VSC Architecture Physical Level (REEV) Physical architecture of the electric hybrid: REEV DC/DC Converter DC to vehicle load DC Hydraulic Brake system C H Fuel ICE M INV Batt T AC DC DC DC AC T INV M Trn T Wheel From external AC source AC On board charger DC DC BUS
VSC Architecture s Level (REEV) Charger Battery DC/DC converter Vehicle loads Foundation Transmission Plant BMS DC/DC control Brakes Controller TCU Control Peak Power Tertiary Power Hydraulic Brake Transmission DC BUS Hybrid Vehicle Vehicle Chassis Continuous Power Vehicle Supervisory Controller Drive ICE ECU APU Manager INV Control Energy Management Driver Demand Motion Control Drive Control Control Fuel tank ICE M INV INV M Plant
VSC Architecture Reference Level (REEV) Reference architecture for electric hybrids Target Generation Tertiary Power Pwr Cmd Pwr Act Pwr Avail Trq Dmd Trq Dmd Trq Avail Trq Cmd Trq Act Trq Avail Brakes Cap Pwr Avail Continuous Power Pwr Act Pwr Cmd Vehicle Energy Management Cap Pwr Avail Pwr Act Pwr Cmd Peak Power Pwr Avail Vehicle Motion Control Trq Act Trq Cmd Trq Avail GearChangeReq Drive GearAct TrqDownReq Transmission
VSC Architecture Deployment (REEV) VSC Deployment showing inclusion of APU Manager Vehicle Supervisory Control Target Generation Trq Cmd Tertiary Power Pwr Avail Pwr Act Pwr Cmd Trq Dmd Trq Avail Trq Dmd Brakes Vehicle Energy Management Pwr Avail Vehicle Motion Control Trq Avail Capacity Pwr Avail Pwr Act Pwr Cmd Pwr Act Pwr Avail Capacity Pwr Cmd Trq Act Trq Avail Trq Cmd APU BATT Drive
VSC Architecture Final Design (REEV)
VSC Architecture Reusability Physical Level (Parallel Hybrid) Physical architecture of mechanical hybrid: Parallel Hydraulic Brake system From external AC source DC to vehicle load C Fuel On board charger AC DC DC ICE T INV CVT Trn DC AC T M Clutch 1 T T T Clutch 2 Torque BUS T H Wheel Batt DC/DC Converter DC DC BUS
VSC Architecture Reusability s Level (Parallel Hybrid) Charger Battery INV M DC/DC converter Vehicle loads Foundation Plant BMS INV Control DC/DC control Brakes Controller Control Peak Power Tertiary Power Hydraulic Brake DC BUS Torque BUS Hybrid Vehicle Vehicle Chassis Continuous Power Vehicle Supervisory Controller Drive Line ICE ECU CSP Manager CVT Control Energy Management Driver Demand Motion Control Clutch 1 Control Clutch 2 Control Control Fuel tank ICE CVT Clutch 1 Clutch 2 Plant
VSC Architecture Reusability Reference Level (Parallel Hybrid) Reference Architecture for Mechanical hybrids Target Generation Brakes Tertiary Power Pwr Avail Pwr Act Pwr Cmd Vehicle Energy Management Trq Avail Trq Dmd Pwr Act Pwr Avail Capacity SPLIT Peak Power Trq Dmd Trq Avail Trq Act Trq Cmd Vehicle Motion Control Trq Cmd TrqDownReq Trq Cmd GearChangeReq GearAct Pwr Act Capacity Pwr Avail Continuous Power Transmission
Controls Software Implementation (REEV) VSC implementation showing I/O wrapper VSC Implementation, internal high level, showing 5 classes: > Target Generation > Energy Management > Motion Control > Thermal Management > APU Manager
Controls Software FMEA FMEA Objectives > Enhance base design of VSC > Define requirements for system diagnostics > Define additional DVP items Functional based, interface focussed, concept system FMEA > 3 primary functions were analysed: Provide torque command to drive Manage energy apportionment efficiently within the systems' constraints Mode management 11 weeks to complete (approximately 170 man hours)
Controls Software FMEA Outcomes & Diagnostics The outcomes were in expected areas but the analysis provided some additional insights Pareto effect in rate of action discovery > Soon starts to repeat but occasionally an important new item does crop up late in the analysis Key system level diagnostic areas arising from the FMEA: > Torque plausibility (including sign & magnitude) > Power monitoring (including split values) > Communications integrity
Controls Software Directionality (REEV) FMEA requirement Directionality management Alternate between MAX and MIN VEM Pwr depending on direction and mode Mode Powerflow Discription comment Max Trq Map Min Trq Map Drive Charge or discharge Rev Charge or discharge +ve Bus Pwr Avail (Dis) Max Drv Trq N Min Drv Trq -ve Bus Pwr Avail Dyn map Dyn map This could be simplified to always having the same max and min maps This could be simplified to always having the same max and min maps Min Drv 1 Min Drv 2 Assumption SW quadrant (regen can only be entered from NW MaxTqAvail MaxTqAvail Min Drv 3 MaxRgnTq MaxT Arb MaxTqAvail Min Rev 1 Min Rev 2 MinTqAvail MinTqAvail MinT Arb MinTqAvail PRND
SOC [] Power [W] Controls Software ECMS functionality results Basic results showing ECMS responding to 3 x 104 2.5 2 1.5 Low SOC Condition Dmd Pwr APU Pwr TPS Pwr Batt Pwr low SOC 1 condition 0.5 0-0.5-1 0 20 40 60 80 100 120 140 160 180 200 0.34 0.32 SOC 0.3 0 20 40 60 80 100 120 140 160 180 200 Time [s]
Safety Strategy Hazard Analysis & Risk Assessment Hazard Analysis & Risk Assessment performed at the vehicle level in accordance with ISO 26262 (functional safety of road vehicles) > ISO 26262 in draft form but considered state of the art Analyses hazardous events > i.e. a hazard in a specific operational situation e.g. undemanded acceleration whilst cornering at high speed on a low mu surface Each hazardous event is ranked for Severity (S), Exposure (E) and Controllability (C). > Severity = the degree of harm should an accident occur > Exposure = the likelihood of being in the operational situation > Controllability = chances of controlling the hazard should it occur
Safety Strategy Safety Goals From the Hazard Analysis & Risk Assessment, safety goals are defined for each worst case hazardous event > e.g. the vehicle occupants shall not be subjected to vehicle acceleration without driver demand At least one safety goal is defined for each hazard Safety goals are the highest level functional safety requirements A Functional Safety Concept (FSC) can be defined once the safety goals are known Requirements in the FSC can then flow down to system, hardware and software level safety requirements
Safety Strategy ASILs Automotive Safety Integrity Level (ASIL) can be defined as the degree of rigour used to apply safety measures so that unreasonable residual risk is avoided ASIL A being the least stringent, ASIL D the most stringent ASILs are initially allocated to the safety goals (Severity x Exposure x Controllability = ASIL) ASILs flow down to system, hardware and software safety requirements > ASIL decomposition can take place if independent systems exist ASILs are only allocated to electronic control, sensing and actuation elements (e.g. not mechanical or hydraulic elements)
Safety Strategy ASILs Calculating ASILs C1 C2 C3 E1 QM QM QM S1 E2 QM QM QM E3 QM QM A E4 QM A B E1 QM QM QM S2 E2 QM QM A E3 QM A B E4 A B C E1 QM QM A S3 E2 QM A B E3 A B C QM = Quality Measure (i.e. adoption of company quality procedures is suffice) E4 B C D
Thank you for your attention Questions??