Company: Valeo Powertrain Systems Business Company: Valeo Powertrain Systems Business

Similar documents
Deriving safety requirements according to ISO for complex systems: How to avoid getting lost?

Functional Safety and Safety Standards: Challenges and Comparison of Solutions AA309

Software architecture in ASPICE and Even-André Karlsson

Failure Diagnosis and Prognosis for Automotive Systems. Tom Fuhrman General Motors R&D IFIP Workshop June 25-27, 2010

FMEDA-Based Fault Injection and Data Analysis in Compliance with ISO SPEAKER. Dept. of Electrical Engineering, National Taipei University

Safe Automotive software architecture (SAFE) WP3 Deliverable D331a2: Proposal for extension of metamodel for error failure and propagation analysis

Safety Argument based on GSN for Automotive Control Systems. Yutaka Matsubara Nagoya University

Understanding SW Test Libraries (STL) for safetyrelated integrated circuits and the value of white-box SIL2(3) ASILB(D) YOGITECH faultrobust STL

FUNCTIONAL SAFETY AND THE GPU. Richard Bramley, 5/11/2017

Functional safety in BATTERY MANAGEMENT SYSTEMS

Certified Automotive Software Tester Sample Exam Paper Syllabus Version 2.0

Automotive ECU Design with Functional Safety for Electro-Mechanical Actuator Systems

What functional safety module designers need from IC developers

ISO Functional Safety Management in the Autonomous Car industry and the overview of the required safety lifecycle.

AN5333. Safety application notes for MC24XS4 family. Document information

Alexandre Esper, Geoffrey Nelissen, Vincent Nélis, Eduardo Tovar

Functional Safety Design Packages for STM32 & STM8 MCUs

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C- Ware, the Energy Efficient Solutions logo, Kinetis,

Verification Futures The next three years. February 2015 Nick Heaton, Distinguished Engineer

MC33903/4/5 Block Diagram. Analog, Mixed-Signal and Power Management. Legend. MCU Voltage Regulator (V DD ) Internal CAN Regulator (V CAN )

NORME ISO : APPLICATION SUR LE LOGICIEL DU BOITIER DE SERVITUDE INTELLIGENT (BSI) DE PSA

Is This What the Future Will Look Like?

Click ISO to edit Master title style Update on development of the standard

Solving functional safety challenges in Automotive with NOR Flash Memory

Automotive Functional Safety

OPERATING INSTRUCTION

Safety Driven Optimization Approach for Automotive Systems. Slim DHOUIBI, PhD Student, VALEO - LARIS

COMPASS: FORMAL METHODS FOR SYSTEM-SOFTWARE CO-ENGINEERING

NTC/PTC- SIMULATION NTCS channel version

Original operating instructions Safety relay with relay outputs with and without delay G1502S / / 2016

88 Dugald Campbell. Making Industrial Systems Safer Meeting the IEC standards

ISO meets AUTOSAR - First Lessons Learned Dr. Günther Heling

Software Verification and Validation (VIMMD052) Introduction. Istvan Majzik Budapest University of Technology and Economics

Functional Safety simulation using SaberRD

Autoranging True RMS Multimeter User Manual

Hiperface DSL Combined with Safety

Industrial Embedded Systems - Design for Harsh Environment - Dr. Alexander Walsch

Institutionen för systemteknik

New developments about PL and SIL. Present harmonised versions, background and changes.

Using Fault Injection to Verify an AUTOSAR Application According to the ISO 26262

aentron Energy System 1 to 900 Vdc

Safety and Reliability of Software-Controlled Systems Part 14: Fault mitigation

A tool based estimation computation method of MCU random failure rate &functional safety metrics

V&V: Model-based testing

Original operating instructions Safety relay with relay outputs G1501S / / 2016

Integrated Assessment of AutomotiveSPICE 3.0, Functional Safety ISO 26262, Cybersecurity SAE J3061

Battery Stack Management Makes another Leap Forward

SysML Modeling Guide for Target System

Automating Best Practices to Improve Design Quality

How Microcontrollers help GPUs in Autonomous Drive

Riccardo Mariani, Intel Fellow, IOTG SEG, Chief Functional Safety Technologist

DUAL PLATE D630 Installation and Maintenance en / a

Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS)

Safe Automotive software architecture (SAFE)

SOFTWARE QUALITY. MADE IN GERMANY.

Virtual Hardware ECU How to Significantly Increase Your Testing Throughput!

Functional Safety Architectural Challenges for Autonomous Drive

Setpoint Isolators. Technical Manual. HA Issue Parker SSD Drives, a division of Parker Hannifin Ltd. WARRANTY

New ARMv8-R technology for real-time control in safetyrelated

Entwicklung zuverlässiger Software-Systeme, Stuttgart 30.Juni 2011

Software Architecture. Definition of Software Architecture. The importance of software architecture. Contents of a good architectural model

Introduction: Transient Voltage Suppressors (TVS) for Automotive Electronic Protection. SM8/5Z Series APPLICATION NOTE

S-14 S-14. Compact Digital Multimeter. Compact Digital Multimeter

Redundant Power Supplies. Keep Machines Up When Power Goes Down

DEPENDABLE PROCESSOR DESIGN

European Conference on Nanoelectronics and Embedded Systems for Electric Mobility

Driver Assistance Pushes New Flash Functionalities

C-DIAS Analog Input Module CAI 086 For eight, ±10V voltage inputs

UNISONIC TECHNOLOGIES CO., LTD

BRIO. Application note BRIO Extension & Ethernet redundancy. EN50155 Basic Remote I/O module P DOC BRIO 101E V01

Hardware-Software Codesign. 1. Introduction

ISO Compliant Automatic Requirements-Based Testing for TargetLink

A general-purpose industrial input/output

Control unit SG-EFS 104/4L. EN Operating instructions. Innovative by tradition. Version SG-EFS 104/4L AC/DC 24 V

Fault-Injection testing and code coverage measurement using Virtual Prototypes on the context of the ISO standard

IsoLoop Isolated CAN Evaluation Board

Foundation Fieldbus Safety Instrumented System (FF SIS) FF-SIS Meeting. Hannover. April 21, 2004

Hardware-Software Codesign. 1. Introduction

Drives Motors and PLCs

Pluto AS-i. Safety PLC. Approvals: Control of: Features:

REGULATED DC POWER SUPPLIES.

VDE Testing and Certification Institute

INTRODUCTION. Mechanical Considerations APPLICATION NOTE Z86E21 THERMAL PRINTER CONTROLLER ZILOG

FSO Webnair FSO Safety Functions Module. ABB Group February 11, 2015 Slide 1

Designing and Analysing Power Electronics Systems Using Simscape and SimPowerSystems

SINUMERIK Safety Integrated. Possible Encoder Connections

SPC584Cx, SPC58ECx. 32-bit Power Architecture microcontroller for automotive ASIL-B applications. Features

STM32 F0 Value Line. Entry-level MCUs

±15kV ESD-Protected, Single/Dual/Octal, CMOS Switch Debouncers

SPC58NE84E7, SPC58NE84C3

Introduction to Control Systems Design

Is this presentation suited for you?

Instruction book IQAN-LSL. Publ no HY /UK Edition 0301

MANUFACTURING TECHNICAL INSTRUCTIONS - SAFETY. Subject: Control Reliability for Machinery & Equipment

Workpackage WP2.5 Platform System Architecture. Frank Badstübner Ralf Ködel Wilhelm Maurer Martin Kunert F. Giesemann, G. Paya Vaya, H.

TwinSAFE Scalable Safety Solutions. Dr. Guido Beckmann Technology Marketing

SAFETY MANUAL SIL Switch Amplifier

Safety and Security for Automotive using Microkernel Technology

SINAMICS SINAMICS G120. Frequency inverter with Control Units CU240E-2 CU240E-2 DP CU240E-2 F CU240E-2 DP-F. Function Manual Safety Integrated 07/2010

FUNCTIONAL SAFETY FOR INDUSTRIAL AUTOMATION

Transcription:

"La démarche «Building» appliquée à la Sûreté de Fonctionnement des onduleurs" Building strategy application to functional safety of inverters Hicham LAHBIL Amélie THIONVILLE Company: Valeo Powertrain Systems Business Company: Valeo Powertrain Systems Business Group\ Electronic Product Group Group \ Electronic Product Group Address: Créteil, 2 rue Andrée Boulle Address: CERGY SAINT CHRISTOPHE, 14 avenue des Béguines Résumé Cette publication présente une nouvelle démarche en cours de déploiement, elle concerne le métier de sûreté de fonctionnement, Cette démarche permet d optimiser et de factoriser les efforts d études et de développement, dans le cas d une organisation développant diverses produits présentant des similitudes. L objectif est de pouvoir utiliser des «building» préeistants, déjà conçus, vérifiés et validés. Cette démarche permet un gain important de temps et de ressource, et permet une meilleure agilité dans les développements des onduleurs Summary This paper presents a new approach being deployed for dependability discipline; this approach allows optimizing and communalizing the study and development efforts in the case of an organization developing diverse products with similarities. The aim is to use the "building " eisting, already designed, verified and validated. This approach enables a significant gain in terms of time and resource, and allows for better agility in the developments of inverters 1 Introduction Different inverters used in different automotive applications (12V, 48V or High voltages) present many common points, this fact imply that many modules are similar, these module have the same definition, and generally the same limits and interfaces. Only some adaptations are needed to move from one application to another one, theses modules are what we call building s, Concretely, at the first level, an inverter consists of control parts and power parts, than at the second level the control parts consist of different hardware s and at the third level, we have software with its own specific hierarchy 2 VALEO Safety lifecycle: Before detailing the approach, it is important to present the safety lifecycle applied in the VALEO methodology, it describes different safety activities. The concerned activities by this paper approach are surrounded by red dotted circles. Subset of Customer Safety goal Requirements Component specification Elicitation FSC PHA UE list SFMEA Qual FTA Customer safety analysis FTA Quant System Validation Test Safety Tests Acceptance Test Component design TSC FMEDA / FTA Qual./ DFA FMEDA / FTA Quant. Component Validation test Safety Tests HW, SW specification Elicitation TSC (HW, SW) HW, SW Validation Safety Tests HW, SW design Safety HW, SW architecture efmea SW Safety Analysis HW, SW Integration and test Safety Tests HW/SW implementation Figure 1. Overall safety process description Communication 8F /1 page 1/8

3 Inverter environment Generally, inverters are used to control machines, the functions of the system (inverter + machine) are: Generator mode to supply the vehicle power network (Battery and different loads) Motor mode to provide torque to vehicle to start engine or to assist thermal engine (hybridization) The inverter may be integrated with machine or may be standalone, the system (inverter + machine) may be Belt Driven or beltless: Electric Motor directly on the crankshaft of the engine Electric Motor between engine and gearbo with an additional clutch Electric Motor behind the gearbo through a disconnect clutch To loads Vehicle power network (12V or 48V) CAN BUS network Battery VCU Inverter Machine Electrical energy conversion to mechanical energy to vehicle Vehicle mechanical energy conversion to electrical energy 4 Building approach Figure 2. Inverter environment How Building approach could be done for safety discipline? In this paper, we will try to answer this question by focusing on two eamples of safety activities (Technical safety concept and efmea) The first steps are: 1) Make a list of different developed products. 2) Define list of safety goals allocated to these products and their ASIL. 3) Determine architecture similarities between applications Different inverters are generally concerned by the same list of safety goals, some difference linked to characterization of safety goals eist (threshold values, reaction time ) but these differences are not a barrier to building approach. The ASIL level of safety goals may vary from one application to another, in these cases, the idea is to take into account the highest ASIL if there is no significant over cost, and otherwise the component is developed depending on the ASIL. To introduce net chapter, the figure below gives hierarchy and link between safety goals obtained from Hazard analysis and risk assessment activity applied at system level, and declined to functional safety requirements allocated to components of the system. Hazard analysis and risk assessment Safety goal 1 Safety goals 2 Safety goal n requirement 1 requirement 2 requirement 3 requirement 4 requirement n Figure 3. The different levels of safety requirements Communication 8F /1 page 2/8

4.1 Safety goals allocation Safety goal are top-level safety requirement resulting from the hazard analysis and risk assessment, to illustrate the approach, the table below gives an eample of a list of safety goals allocated to three similar applications Applications Application A ASIL Application B ASIL Application C ASIL Safety goal_001 C C C Safety goal_002 C C Safety goal_003 C B B Safety goal_004 A A A Safety goal_005 C C Safety Goal_006 B B A Table 1. Safety Goals Allocation The allocation of safety goals to the different elements is done after performing two types of safety analyses; deductive and inductive analyses (FTA and FMEA) Usually a safety goal is allocated to components or subsystems responsible of its violation, but it may also be allocated to components or subsystems that are not and do not participate in any way to its violation, this option allows in the design of the system to share and optimize development efforts between different sub systems. 4.2 requirements Allocation The functional safety requirements are derived from the safety goals, and then allocated to the product; the net table gives list of functional safety requirements allocated to different applications Applications coverage Application A ASIL Application B ASIL Application C ASIL FSR_001 SG_001 X C X C X C FSR_002 SG_001 X C X C X C FSR_003 SG_002 X C X C FSR_004 SG_002 X C X C FSR_005 SG_003 X C X B X B FSR_006 SG_003 X C X B X B FSR_007 SG_004 X A X A X A FSR_008 SG_005 X C X C FSR_009 SG_005 X C X C FSR_010 SG_006 X B X B X A FSR_011 SG_006 X B X B Table 2. FSR allocation to different applications After safety goals refinement into Functional Safety Requirements allocated to different applications. Then the Functional Safety Requirements are allocated to a component by refinement to a list of technical safety requirements allocated to the functional s of the component architecture. Functionnal Safety requirements Technical Safety requirements HW or SW requirements Communication 8F /1 page 3/8

4.3 Architectures similarities Net figures are given as eamples, common of three similar applications are shown in blue color, Voltage 2 Voltage 1 s Protection2 Protection4 Power supply BUS communication Protection1 MCU Drivers Protection3 Power parts WDG Position Sensors Temperature s Figure 4. Application A architecture Voltage 1 Protection2 Protection4 Power supply BUS communication Protection1 MCU Drivers Power parts WDG Position Sensors Temperature s Figure 5. Application B architecture Voltage 2 Voltage 1 Protection2 Power supply BUS communication Protection1 MCU Drivers Protection3 Power parts WDG Position Sensors Temperature s Figure 6. Application C architecture Communication 8F /1 page 4/8

4.4 Technical safety requirements The net table shows how the functional safety requirements are allocated to functional s of different architectures of the three applications, the idea behind this allocation table is to know common requirements between different applications. Common modules and common functional safety requirements are shown in blue color. Block FSR_001 FSR_002 FSR_003 FSR_004 FSR_005 FSR_006 FSR_007 FSR_008 FSR_009 FSR_010 FSR_011 Protection3 Voltage s 2 s Protection1 Application A Application B Application C Protection2 MCU WDG Power supply BUS com Position s Temperature Table 3. FSR allocation to different building s drivers Voltage 1 Power Protection4 After the allocation of FSRs to different building is done, the technical safety requirements are specified, this level of specification is shared between different applications (when it concern common building ). Communication 8F /1 page 5/8

When many building s are used in an application, the structure of the technical safety concept looks like to: General chapters Architecture chapter Technical safety concept Technical safety requirements Chapter on TSRS of non building s Chapter on TSRs of Building 1 Chapter on TSRs of Building 2 Common chapters Specific chapters... Chapter on TSRs of Building s n Figure 6. Eample of use of building 4.4.1 Eample of shared technical safety concept : CAN communication safety requirements The CAN communication requirements are allocated to MCU to secure CAN frames containing critical data with ASIL. Net requirements are specified in a generic way for CAN building : Identifier TSR_Application_X_013 ASIL Upward traceability: TSR_Application_X_013 TSR_Application_X_014 CAN frames containing ASIL A/B/C/D data shall be protected by an appropriate timeout monitoring compliant with the safety concept ASIL C/D data transmitted on CAN shall be protected with a sequence counter ASIL A or B or C or D ASIL C or D FSR_Application_X_006 FSR_Application_X_00 TSR_Application_X_015 ASIL C/D data transmitted on CAN shall be protected with an applicative CRC ASIL C or D FSR_Application_X_00 4.5 efmea building strategy The second activity concerned by Building approach in this paper is efmea (electronic Failure Modes and Effect Analysis), in Valeo methodology, it is a qualitative and quantitative analysis done at each hardware level, it identifies basic event (Failure modes) and associated failure rate to feed FMEDA and FTA safety analyses. Inputs for this analysis are electronic components reliability failure rates and failures modes, reliability failure rate is changing depending on application mission profile, But failure modes of component are the same, local effect are generally similar, a few adaptations are needed depending on the application. Eample of HW building, the function is to measure the +BAT voltage Communication 8F /1 page 6/8

Figure 7. HW building When known building s are designed in the same way, safety analysis like efmea could be done commonly; the table below gives an etract of an efmea of a building as eample: Block ID Block Name Part ID Part Description Part Failure Mode +BAT_MEASUREMENT R3200 RES 100K 1% 100mW TF 100PPM 0603 +BAT_MEASUREMENT R3200 RES 100K 1% 100mW TF 100PPM 0603 +BAT_MEASUREMENT R3201 RES 7.32K 1% 100mW TF 100ppm 0603 +BAT_MEASUREMENT R3201 RES 7.32K 1% 100mW TF 100ppm 0603 open circuit Parameter change open circuit Parameter change Local Effects at output (Basic events) loss of +Bat measurement function no effect loss of +Bat measurement function no effect +BAT_MEASUREMENT C3202 CAP 1nF 10% 50V X8R 0603 open circuit no effect +BAT_MEASUREMENT C3202 CAP 1nF 10% 50V X8R 0603 short circuit loss of +Bat measurement function +BAT_MEASUREMENT D3200 +BAT_MEASUREMENT D3200 DIOD SCHOT DUAL 200mA 30V BAT54S SOT23 open circuit degration of pulse protection DIOD SCHOT DUAL 200mA 30V BAT54S SOT23 short circuit degration of pulse protection Table 4. +Bat voltage measurement efmea Effects at component level Specific to each application This efmea could be reused in every application using this building ; only a review of the effect at component level could change, the largest part is already ready for use. 5 Conclusion Building approach allows saving time and enables a good reactivity to develop products, to insure effectiveness of this approach, a good understanding of ISO26262 and a good proimity with HW and SW development teams are necessary. This approach could be epanded to many other safety activities like FMEDA and test activities, 6 Acknowledgement Thanks goes to everyone having made possible the accomplishment of this paper. 7 References [1] ISO26262 INTERNATIONAL STANDARD. [2] Building Blocks Strategy / François PELLIER [3] Valeo Safety Methodology (M.LEEMAN) 8 Glossary ASIL: Automotive Safety Integrity Level. CAN: Controller Area Network. CRC: Cyclic Redundancy Check efmea: Electronic Failure Modes and Effects Analysis FMEDA: Failure Modes and effects Diagnosis Analysis FSC: Functional Safety Concept. FSR: requirement. FTA: Fault tree Analysis HW: Hardware. Communication 8F /1 page 7/8

LPFM: MCU: SG: SPFM: SW: TSC: TSR: WDG: +Bat: Latent-Point Fault Metric. Microcontroller Unit Safety Goal. Single-point fault metric. Software. Technical Safety Concept Technical Safety Requirement. Watchdog Battery Voltage Communication 8F /1 page 8/8