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

Transcription

1 "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

2 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

3 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 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

5 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

6 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 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_ 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

7 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 BAT_MEASUREMENT R3200 RES 100K 1% 100mW TF 100PPM BAT_MEASUREMENT R3201 RES 7.32K 1% 100mW TF 100ppm 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

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