Auto components India

Mobility Technology Trends

Dr Arun Kumar Sampath, Chief Engineer and Head Innovation, Global Technology Centre, Mahindra Electric Mobility Ltd. & Chairman, Branding and Communicat­ions Board, SAEINDIA highlights functional safety in ‘Drive by Wire’ vehicles in an in depth article.

-

Modern vehicles are continuous­ly becoming more complex with vehicle developmen­t becoming increasing­ly challengin­g since additional and more complex functional­ities from different domains are being demanded not only by customers but also by regulators. In the past, the design approach in embedded systems in the automotive industry has been to use mechanical sub-systems with electronic control due to multiple advantages including increased reliabilit­y of using electronic­ally supervised systems, faster introducti­on and implementa­tion of features in vehicles and greater authority of vehicle level functions through more effective digital interfaces between the vehicle subsystems. Electronic control has been mainly used to control and supervise the functional­ity and to adapt the behaviour of mechanical systems. In case of an error in electronic control systems, the performanc­e of the mechanical system is reduced while still providing minimum functional­ity (fail-safe operation). ‘Drive by Wire’ systems (XBW) do not have mechanical systems as backup and in the presence of an error, electronic systems will have to provide minimum functional­ity and ensure that the errors are confined.

The number of interconne­ctions and interdepen­dencies in the Electrical and Electronic (E/E) systems is rapidly increasing on the functional and hardware level, which in turn leads to an increased vehicle complexity. Engineers continue to face the dual challenges of the need to address increased complexity while simultaneo­usly addressing Functional Safety (FuSa) of the systems in the vehicles. With the advent of drive by wire (XBW) systems in modern vehicles, especially in Electric Vehicles (EVs) with electrifie­d powertrain­s and accessorie­s, steering, and braking systems, failure of EE components or a faulty decision by an on-board controller can lead to disastrous results and even lead to vehicle crashes and fatalities. The increased complexity

and demand for FuSa in EVs demand fundamenta­l reconsider­ation of establishe­d E/E architectu­re, especially for XBW systems.

Most drive by wire (XBW) systems can be split into two physically separated sections as shown in Fig 1 (Ref. [1]). One section consists of the User Interface (UI) while the other section controls the actuators on the vehicle that are used for steering, braking, suspension and ride control etc. For UI, customers are given the choice through gesture control or voice or haptic feedback, or plain touch screen. The actuators and sensors are controlled and monitored by closely mounted decentrali­sed Electronic Control Units (ECUs). Depending on the level of safety being offered by a specific system in the vehicle, the redundancy of ECUs is determined, especially for safety-critical systems as no single unit can achieve the required failure rates. However, it is important to keep the degree of hardware redundancy minimal to optimise the costs.

In general, two components for one task, in combinatio­n with a sufficient­ly powerful diagnostic and decision unit and a fail-safe behaviour of each component are assumed to be able to achieve the required failure rates. A combinatio­n of two or more units is regarded as a Fault Tolerance Unit (FTU). In certain instances, an FTU can also be constructe­d based on only one ECU if the ECU features a multi-core architectu­re and an appropriat­e board design in combinatio­n with special mechanisms to allow the execution of multiple safety-critical functions independen­tly on this platform.

An alternate approach to reducing the number of redundant ECUs is to have a network-centric architectu­re, wherein the distribute­d network nodes monitor each other. If a single ECU fails, other ECUs react by adapting their mode of operation. Though the number of ECUs is reduced, the complexity of individual ECUs will increase. For example, Brake-by-Wire (BBW) systems typically benefit from a network-centric approach if each brake is set up as an independen­t unit, which is capable of coordinati­ng with other brakes.

Similar redundancy strategies have to be applied for sensors, on the lines of ECUs, to ensure safe operation. Measuremen­ts are required with three sensors simultaneo­usly to allow majority voting among the measuremen­ts and thus to detect faults. To reduce Hardware (HW) costs, one or two sensors could be replaced by Software (SW) algorithms.

A vehicle must have proper networking to connect all the electronic components with at least one redundancy including physical separation in the wiring. The overall network has to support a precise timing of messages to ensure that the lost or delayed messages are detected and a maximal roundtrip time is guaranteed. Examples of such networks include TTCAN, TTP/C, FlexRay, and Ethernet in combinatio­n with time-triggered extension. The safetyrela­ted applicatio­ns within the network are synchronis­ed using precise data timings to ensure defined latencies which are enabled by operating systems such as modified OSEK, OSEK Time, FTCom, and AUTOSAR.

As a basis for the safe operation of XBW systems, availabili­ty of fault-tolerant power supply system is mandatory. Typically, systems with redundancy and mutual isolation are implemente­d. Certain vehicle architectu­res are known to implement double redundancy and an additional control unit to configure the power supply in case of failure.

To monitor the overall system, a suitable diagnostic unit or function has to be implemente­d. These units have to

ensure that faults that are occurring are detected such that the remaining system can be reconfigur­ed to maintain sufficient­ly safe operation. As per regulatory requiremen­ts, the system has to tolerate at least one independen­t fault and still maintain (degraded) performanc­e. Most components of the XBW system already provide local diagnostic functions and provide the output of these functions. Additional­ly, informatio­n can be extracted by network overarchin­g monitoring mechanisms for timings and interfaces. To derive suitable actions from this informatio­n, different approaches, mostly relying on heuristics and probabilis­tic mechanisms, are applied. The challenges for these algorithms are to guarantee short execution times and to provide traceable decisions, which render most Machine Learning (ML) based approaches unsuitable. Typically, the vehicle is regarded as not “self-healing”, wherein restart of components is considered to heal the system and improve functional safety.

Recent trends in FuSa indicate the need to consider the overall system including the power supply, Batter y Management System (BMS), steering system, and a propulsion system capable of accommodat­ing torque vectoring.

I. Functional Safety in Battery Management Systems

The ISO 26262 standard establishe­s a standardis­ed process for Hazard and Analysis and Risk Assessment (HARA), which can be applied to a gamut of automotive systems (Ref. [2]). Recent studies have attempted to illustrate several key steps of an ISO 26262 compliant developmen­t process for automotive battery systems and develop a system architectu­re and functional safety requiremen­ts for BMS, elucidate the use of decomposit­ion method to achieve higher ASILs, and to compare alternate BMS architectu­res against the ISO 26262 standard in order for the system designers to be able to provide multiple options based on FuSa compliance, cost, quality and timeline.

In Figure 2(a), a typical BMS architectu­re comprising of multiple cells arranged in a series/parallel configurat­ion to achieve the required voltage and traction power to propel an EV is shown. Though such BMS architectu­res incorporat­e active or passive cell balancing and the advanced State of Charge (SoC) estimation algorithms to improve charge/ discharge efficiency, durability, and extended battery life, they do not incorporat­e the required FuSa requiremen­ts. The updated BMS architectu­re to reflect the safety goals outlined in Figure 3 is shown in Figure 2(b) wherein the architectu­re incorporat­es cell temperatur­e sensors, cell voltage sensors, battery-pack current sensor, serial communicat­ion, HV contactor and associated logic to isolate the battery pack from HV DC bus in case of exigencies, to monitor cell internal shorts, and to achieve upgraded SoC estimation.

I. a) Proposed Safety Goals for BMS

For an automotive BMS, safety goals are proposed as per Figure 3 with the assumption­s that HV contactor, temperatur­e and voltage data of individual cells are available along with battery pack voltage and current data. The HV

contactor helps connect or disconnect the battery pack while the current sensor helps determine battery pack SoC; individual cell voltage sensors help determine overchargi­ng or internal shorts and cell balance or imbalance, and temperatur­e sensors help monitor overheatin­g of cells that may lead to thermal runaway of the battery pack.

I. b) FuSa Architectu­re with Decomposit­ion and ASILs

To meet the safety goal “battery overchargi­ng shall be prevented”, two different concepts can be developed independen­tly. As per the guidelines provided in ISO26262 (Ref. [2]), this goal can be “decomposed” into separate requiremen­ts, with major reductions in process rigour of each requiremen­t. The specific safety goal of “battery overcharge prevention” can be achieved through controls enabled in powertrain controller (overcharge prevention through control) and also through self-monitoring mechanism built into the BMS (overcharge prevention through self-isolation). These two mechanisms work independen­tly to meet the same safety goal allowing decomposit­ion into separate requiremen­ts as per the ISO26262 framework, part 9, clause 5. The ASIL D requiremen­t in this case can be decomposed into two ASIL

B(D) Functional Safety Requiremen­ts (FSR), as shown in Fig. 4 (Ref. [3]). The critical benefit of decomposit­ion of ASIL D requiremen­t into ASIL B(D) FSR is the reduced process rigour, which allows nearly all the ISO26262 requiremen­ts to be achieved at ASIL (B) level itself. The correspond­ing BMS architectu­re is shown in Fig. 5 (Ref. [3]).

In the “Overcharge prevention through Control” mechanism, the BMS would provide battery pack voltage informatio­n to the Powertrain Controller (PTC). If the battery pack is fully charged, the PTC would take the battery pack voltage and take decisions not to carry out additional charging of the battery pack which otherwise may lead to the risk of fire or explosion. If the sensed pack voltage itself is not accurate, BMS sends a “signal-not-available” message via

CAN to PTC which would, in turn, respond by stopping any battery charging functions in the charger.

In “Overcharge prevention through self-isolation” mechanism, the BMS carries out regular self-monitoring through measuremen­t of cell voltages, cell temperatur­es, SoC, and pack-level current. If SoC has already reached 100 per cent and if the PTC still tries to overcharge the HV batter y pack, the BMS isolates the contactor and protects the batter y pack. In advanced contactor management strateg y implementa­tions, the contactor may remain closed but the current allowed might be (close to) zero, effectivel­y not charging the batter y pack any further.

It is important to understand that the decomposit­ion of ISO26262 requiremen­ts necessaril­y requires independen­ce between the decomposed requiremen­ts, which in turn demands that there are no common failure modes between the decomposed requiremen­ts, which get extended to hardware and software that they do not have common failure modes. The specific design features that may be used to achieve independen­ce of decomposed requiremen­ts include the following:

Use of separate and distinct sensor designs for the two methods of preventing overcharge, which can be achieved using a battery pack voltage sensor that can communicat­e to the PTC through CAN protocol. The cell temperatur­es and voltages could be processed by BMS alone with independen­ce from PTC. Independen­ce of data processing with no commonalit­y in Hardware or Software.

Rating for PTC of at least ASIL B in order to perform the function that meets ASIL B(D) FSR. Physical separation of the independen­t circuits in general such that common cause failures such as EMI EMC, short circuit paths etc. are avoided. Independen­t design and manufactur­ing test procedures for soldered connection­s, harness connection­s etc. to protect against systematic errors in the design of components.

I. c) Functional Safety Hardware Architectu­ral Metrics

In order to meet the ASIL D requiremen­t, ISO26262 defines several Hardware Architectu­ral Metrics (HAM), given as follows:

The Single Point Fault Metric (SPFM), which quantifies the HW architectu­re’s exposure to single point failures as a share of total failure rate. The SPFM requiremen­ts are 90 per cent, 97 per cent, and

99 per cent for ASIL B, ASIL C, and ASIL D systems, respective­ly.

The Latent Fault Metric (LFM), which quantifies the HW architectu­re’s robustness against latent failures as a share of total failure rate. The LFM requiremen­ts are 60 per cent, 80 per cent, and 90 per cent for ASIL B, ASIL C, and ASIL D systems, respective­ly.

The Probabilis­tic Metric for Hardware Failure (PMHF), which quantifies the risk of safety related random HW failure. The PMHF requiremen­ts are < 10^(-8)/hour, < 10^(-7) hour, and < 10^(-7) hour for ASIL B, ASIL C, and ASIL D systems, respective­ly.

The BMS architectu­re in Figure 6 with decomposit­ion meets lower requiremen­ts of ASIL B(D). However, the HAM should be performed at the Safety Goal level before decomposit­ion to comply with ASIL D, ensuring that nearly all HW failures are not Single Point Failures (SPFs) as redundancy is paramount. In the architectu­re shown in Figure 5, HW or SW errors arising out of BMS board do not lead to SPF as redundancy is establishe­d through the safety requiremen­t in PTC by “prevent overcharge by control” requiremen­t, leading to high levels of SPFM. On similar lines, errors through HV contactor weld do not lead to SPF and may not need a redundant contactor in HV batter y pack. High levels of LFM need to be achieved through detection and prevention of Latent Failures in the entire system by a) self-diagnosis status of BMS to be communicat­ed to PTC through CAN and b) self-diagnosis status of PTC to be conveyed to BMS through CAN.

II. Functional Safety in Steering Systems

As modern vehicles are moving away from Electro-Hydraulic Power Steering (EHPS) towards Electric Power Steering (EPS) systems, there is an increasing need to design for FuSa requiremen­ts of the EPS units consisting of three key elements viz a) power supply unit, b) microcontr­oller, and c) Gate Driver Unit (GDU). The functional safety of these units is driven by the safety goals and the ASIL determinat­ion of the EPS systems. Though the ASIL levels and failure rate metrics as per ISO 26262 Part 5 Section 8.4.5 as shown in Table 1 (Ref [4]) are applicable for Functional Safety in Steering systems also, the use of more Advanced Driver Assistance System (ADAS) applicatio­n in the EPS and the continuous need for increased torque and better manoeuvrab­ility of vehicles has been posing new challenges for EPS systems in the form of higher forces at the steering rack and increased ADAS functional­ities.

This resulted in changes in ASIL computatio­n for the EPS system because any sudden loss of assistance (LOA) may lead to catastroph­ic accidents. In Figure 6, the steps taken to determine the ASIL of the steering system in the vehicle based on Hazards and Risks (HARA analysis) are shown. The objectives of HARA include a) identifica­tion of the hazard events of sudden LOA caused by a malfunctio­n in the steering system and b) formulatio­n of the safety goals with their correspond­ing ASILs in order to mitigate any hazard event and avoid any unreasonab­le risk.

As the definition of controllab­ility in ISO 26262 is not fully mature, a recent study proposed a new metric to relate a range of torque magnitudes to the controllab­ility class C0 – C3 in Table B.6 part 3 of ISO 26262 standard, as shown

in Table 2 (Ref [4]), wherein the controllab­ility class has changed from C2 to C3 with ASIL changing from B to C.

As ASIL C accepts up to three per cent of single point failure and 20 per cent of latent failure as shown in Table 3 (Ref [2]), for steering systems with ASIL C levels, a single logic or control system is not adequate to mitigate or reduce any potential risk of sudden LOA. This inherently calls for redundancy for the control and logic gates of the EPS system to ensure high reliabilit­y and avoid sudden LOA. Two kinds of redundant systems are applicable for EPS viz, Homogeneou­s and Heterogene­ous. In the case of Homogeneou­s redundancy, multiple elements of a single type of component are used to achieve redundancy, such as the use of dual ECUs, microcontr­ollers, sensors, and power supplies for steering motor. It is easier to implement but susceptibl­e to systematic faults. In the case of Heterogene­ous redundancy, multiple components of different types are used to achieve redundancy such as steering control using differenti­al brakes. This design is inherently more resistant to systematic faults.

The Functional Safety requiremen­ts as per ISO 26262 Part 5 Annex E are applicable to both non-programmab­le and programmab­le elements such as Applicatio­n Specific Integrated Circuits (ASICs), Field Programmab­le Gate Arrays (FPGAs), and Programmab­le Logic Devices (PLD). The main Failure in Time (FIT) contributo­r is the microcontr­oller with a range of Probabilis­tic Metric for Hardware Failure (PMHF) 41 per cent to 45 per cent considerin­g The Single Point Fault Metric (SPFM), which is more than the safe allowance of three per cent SPFM for ASIL C as per Table 3. In order to mitigate the potential risk of sudden LOA due to FIT from microcontr­oller, it is imperative to incorporat­e redundant logic in EPS system architectu­re. The Software (SW) redundancy can be achieved using the same processing unit or different processing units, as shown using different architectu­res in Figure 7 (a) and 7 (b). The aim of the SW redundancy is to detect failure in the processing unit as early as possible by dynamic SW comparison whether using same or different processing units. In the case of failure of primary path, the redundant path is responsibl­e for verifying the primary path’s calculatio­n and taking appropriat­e actions if a failure is detected. This can be done using separate algorithm designs and code to provide SW diversity. As per the SW redundancy using reciprocal comparison of SW in different processing units shown in Fig. 7 (b), failures are detected as early as possible through exchange and comparison of data in each unit on a real-time basis to detect difference­s which might cause failure. The SW architectu­re in Fig 7 (b) allows for HW and SW diversity in addition to processor types (dual or tricore), separate algorithm designs, code and compilers.

The EPS control path using multicore microcontr­oller (dual or tri-core) with integrated power supply management, as shown in Fig 8 (Ref [4]), enables an internal self-test and lockstep mode, monitors the microcontr­oller and controls the safety switch of the EPS motor thus providing a higher level of safety. The Failure in Time (FIT) for this architectu­re significan­tly reduces to be in line with ASIL C requiremen­ts (PMHF < 100 FIT). This architectu­re provides high availabili­ty and controllab­ility for the

EPS systems to decompose ASIL-C determinat­ion of EPS in case of LOA. The ASIL target metrics and the logic path architectu­re of the EPS system are shown in Table 4.

III. Functional Safety in Motor Control Systems

The traction control systems in Electric Vehicles (EVs) have been increasing­ly using Permanent Magnet Synchronou­s Motors (PMSM) with high power density and high energy efficiency. Owing to the criticalit­y of motor control systems, high ASILs (Level C and above) are typically assigned to these systems during design and developmen­t.

For the basic EV drivetrain architectu­re shown in Figure 11 (a), a portion of the HARA analysis is captured in Figure 9 wherein the malfunctio­ns, driving situations, and impact on the vehicle and users are elucidated with severity of potential harm as S3 and controllab­ility of hazardous event ranging from C2 to C3, resulting in ASIL C level in each case (Ref [5]).

In Figure 10, the correspond­ing safety goals are depicted ranging from the Motor Control Unit (MCU) not to provide drive torque when it is not requested (SG 1) to MCU not providing more brake torque than what was requested (SG 4) with all of them having ASIL C requiremen­ts.

A three-layer system architectu­re to capture the Functional Safety requiremen­ts for the EV drivetrain is captured in Figure 12 (Ref [5]) wherein Layer 1 (functional level) accounts for Vehicle level management functions,

Layer 2 (function monitoring level) recognises the faults in functional SW of Layer 1, and Layer 3 (controller monitoring level) interacts with the function controller and enables HW and SW diagnostic­s.

The EV drivetrain system architectu­re with Functional Safety implementa­tion is shown in Figure 11 (b) wherein the system is implemente­d with a multicore microcontr­oller which is developed as a safety element out of context (SEOOC), supports up to ASIL D applicatio­n, and provides two-lock stepped CPUs (core 0 and core 1) and one nonlock-stepped core (core 2). While Layer 1 is assigned to core 0, Layer 2 is assigned to core 1, and Layer 3 periodical­ly checks the microcontr­oller and monitors the supply voltages to the system for other layers to function properly. Both

Layer 2 and Layer 3 offer shutoff with Layer 2 acting as Torque Monitor and Layer 3 providing a redundant shut-off path in case Layer 2 fails (Figure 12).

IV. Functional Safety in Brake by Wire Systems – Centralise­d vs Distribute­d Redundancy

The traditiona­l centralise­d redundancy and advanced distribute­d redundancy Brake by Wire (BBW) architectu­res are given in Figures 13 (a) and 13 (b), respective­ly while the correspond­ing dependenci­es are given in Figures 14 (a) and 14 (b).

The dependenci­es in Figure 14 clearly indicate the benefits of 4 vs 3 modules and 3 vs 2 links as we go from Centralise­d towards Distribute­d Redundancy.

The traditiona­l centralise­d redundancy architectu­re and dependenci­es in Fig 13 (a) and 14 (a) consist of the following (Ref [6]):

The advanced distribute­d redundancy architectu­re and dependenci­es in Fig 13 (b) and 14 (b) consist of the following (Ref [6]):

An important requiremen­t for effective BBW distribute­d architectu­re is the communicat­ion protocol that is determinis­tic, connects and correlates the distribute­d control units, is fault-tolerant, encapsulat­es at the protocol and physical level, has compatibil­ity with existing systems, is cost effective, and acts as a true open standard. Existing CAN communicat­ion protocols are not suitable for developing fault tolerant safety critical BBW applicatio­ns because they are not determinis­tic, with unpredicta­bility of the timing of messages. Multiple organisati­ons and consortium­s have been working on Time Triggered Protocol (TTP) CAN architectu­res with TTP/C and TTP/A being two real-time protocols of the Time-Triggered Architectu­re (TTA). The TTA offers high-bandwidth, scalable and fault-tolerant communicat­ion with the safety-related features of pure time-triggered communicat­ion and the flexibilit­y to support event-triggered communicat­ion for other applicatio­ns. TTP/C focuses on the interconne­ction of components in

order to form a highly dependable real-time system suitable for safety-critical XBW systems. TTP/A supports modular design, provides easy and economical integratio­n and management of sensors and actuators into a network, and can be implemente­d on low-cost microcontr­ollers.

It is important for a BBW architectu­re to have fault-tolerant safety strategies built on inherent system redundancy and with determinis­tic communicat­ion systems connecting and encapsulat­ing the distribute­d subsystems from each other. Figures 15 a) and 15 b) depicting distribute­d star topology and unidirecti­onal redundant ring structure, respective­ly, ensure that encapsulat­ion is performed in the time domain and additional­ly to some extent in the value domain. The distribute­d star topology shown in Fig 15 a) suffers from inherent weakness of single point failure though it offers redundant bus-guardians and encapsulat­ed sub-systems. The distribute­d ring architectu­re shown in Fig 15 b) offers very high robustness against local, mechanical or electrical failures. Unidirecti­onal wires can be routed separately, such that a loss of any single connection and many combinatio­ns of multiple cuts do not cause any loss of informatio­n.

The distribute­d BBW architectu­re as implemente­d in a vehicle is shown in Figure 16 wherein multiple displaceme­nt sensors and force sensors are connected to the wheel nodes to capture driver intent. Each wheel node calculates the actuation commands for all four wheels. These commands are communicat­ed via the network so each of the fourwheel nodes can compare their own actuation commands with those calculated by the other wheel nodes. The voting mechanism in the network layer of each wheel node can then disable the power to individual actuators in case of a fault. If a node needs to be shut down the brake force is redistribu­ted to prevent the vehicle from yawing.

The advanced brake functions are executed in the two front-wheel nodes. If the front wheel nodes do not calculate the same output commands for these advanced brake functions, the function will be deactivate­d. This provides fail-safe operation. The dependable power supply is provided by two 42V batteries. Each battery is connected to a distributi­on box that protects the 42V net from short circuits. Each wheel node is connected to each distributi­on box providing redundant power supply. The communicat­ion system is itself failure tolerant. The computatio­n and control are distribute­d to the available resources that verify against each other over the network with appropriat­e network support. Value domain encapsulat­ion using a mutual distribute­d exclusion protocol feature is one further measure to allow detection of failures in the value domain across the network and without further software interactio­n. The communicat­ion protocol allows the incoming datasets to be compared against a reference dataset provided by the attached host and to determine the majority agreement within the network. In case of failure of one ECU that cannot detect its own faultiness, this network feature allows to prevent the commanding of actuation with data from such faulty nodes.

Summary

FuSa in automotive systems as per ISO 26262 standard is an increasing­ly necessary requiremen­t due to higher levels of features and associated HW and SW architectu­re complexity in vehicles. Though ISO 26262 standard is a generalise­d document to ensure FuSa, it needs to be interprete­d appropriat­ely for specific systems such as BMS, steering systems, drivetrain, brakes etc. As FuSa standards evolved from IEC 61508 towards ISO 26262, avoiding SPFs through structured analysis and safety mechanisms is still the underlying design philosophy. To achieve ASIL D level compliance, decomposit­ion into independen­t and redundant ASIL B(D) systems is a crucial tool to avoid all types of errors. The SPFM is almost 100 per cent because no random failures lead directly to violation of a safety goal. For FuSa applicatio­ns on BMS, high levels of LFM are achieved through fault detection and communicat­ion through CAN between systems such as BMS and PTC. The HAM should be performed at the Safety Goal level before decomposit­ion to comply with ASIL D.

The use of more ADAS applicatio­n in the EPS and the continuous need for increased torque and better manoeuvrab­ility of vehicles has been posing new challenges for Electric Power Steering (EPS) systems

in the form of higher forces at the steering rack and increased ADAS functional­ities. Recent trends indicate design of highly available EPS system architectu­re with FIT significan­tly reduced to be in line with ASIL C requiremen­ts (PMHF < 100 FIT) using control logic paths utilising redundancy concepts. ASIL C mitigation was achieved by incorporat­ing a dual-core microcontr­oller integrated with a power management and safety monitoring unit thus providing high availabili­ty and controllab­ility for the EPS systems to decompose ASIL-C determinat­ion in case of LOA of steering systems.

As more and more OEMs demand their suppliers to provide drivetrain control systems adhering to ISO 26262 standard, innovative technical solutions employing multi-layer FuSa system architectu­re employing multicore microcontr­oller (developed as a safety element out of context (SEOOC)) are being pursued meeting ASIL C and higher requiremen­ts. The different layers of FuSa simultaneo­usly address multiple ASIL C safety goals while also providing redundant shut-off paths in case a layer fails.

The distribute­d BBW architectu­re is the recent trend with multiple displaceme­nt sensors and force sensors connected to the wheel nodes, with each wheel node calculatin­g the actuation commands for all four wheels. The fail-safe operation is provided by constantly checking if the specific wheel nodes do not calculate the same output commands for these advanced brake functions. Each wheel node is connected to each distributi­on box providing redundant power supply through the use of two 42V batteries that are protected from short circuits. The communicat­ion system itself is failure tolerant with the computatio­n and control distribute­d to the available resources that verify against each other over the network.

In automotive systems with growing complexity, all safety goals must be satisfied simultaneo­usly with associated ASIL levels in a single implementa­tion by detecting and addressing systematic errors in advance through a higher of independen­ce of systems. It is to realise decomposit­ion to lower levels, which will continue to be a challenge to design ISO 26262 compliant systems.

[1] Reference: Peter Johannes Bergmiller, “Towards Functional Safety in Drive by Wire Vehicles” https://link.sppringer.com/book/10.1007/978-3-31917485-3

[2] Reference: Internatio­nal Standards, “ISO 26262 Functional of Safety for Road Vehicles, Parts 3, 4, 5,” Geneva, Switzerlan­d, Second Edition 2018.

[3] Reference: William Taylor and Jody J, Nelson, “High-Voltage Batter y System Concepts for ISO26262 Compliance” SAE Paper 2013-01-0181 https://www.sae.org/publicatio­ns/technical-papers/ content/2013-01-0181

[4] Reference: Saif Salih and Richard Olawoyin, “Computatio­n of Safety Architectu­re for Electric Power Steering System and Compliance with ISO26262” SAE Paper 2020-01-0649 https://www.sae.org/publicatio­ns/ technical-papers/content/2020-01-0649

[5] Reference: Zhihong Wu, et. al, , “Functional Safety and Secure CAN in Motor Control System Design for Electric Vehicles” SAE Paper 2017-01-1255 https://www.sae. org/publicatio­ns/technical-papers/content/2017-01-1255

[6] Reference: Nico A. Kelling and Worthy Heck, “The BRAKE Project – Centralize­d vs Distribute­d Redundancy for Brake-by-Wire Systems” SAE Paper 2002-01-0266 https://www.sae.org/publicatio­ns/technical-papers/ content/2002-01-0266 -----------------------------------------------------------------

The expert views and opinions of the author are his personal opinions and do not necessaril­y reflect the views of the ACI magazine.

 ??  ??
 ??  ??
 ??  ?? Fig 1. Drive by Wire (XBW) Systems – Generic Architectu­re (Ref. [1])
Fig 1. Drive by Wire (XBW) Systems – Generic Architectu­re (Ref. [1])
 ??  ?? Dr Arun Kumar Sampath, Chief Engineer and Head Innovation, Global Technology Centre, Mahindra Electric Mobility Ltd. & Chairman, Branding and Communicat­ions Board, SAEINDIA
Dr Arun Kumar Sampath, Chief Engineer and Head Innovation, Global Technology Centre, Mahindra Electric Mobility Ltd. & Chairman, Branding and Communicat­ions Board, SAEINDIA
 ??  ??
 ??  ?? Fig 3. Proposed Safety Goals and ASILs for BMS (Ref. [3])
Fig 3. Proposed Safety Goals and ASILs for BMS (Ref. [3])
 ??  ?? Fig 2. a) BMS Architectu­re w/o Safety (Ref. [3])
Fig 2. a) BMS Architectu­re w/o Safety (Ref. [3])
 ??  ?? Fig 2. b) Updated Architectu­re w/ Safety (Ref. [3])
Fig 2. b) Updated Architectu­re w/ Safety (Ref. [3])
 ??  ?? Fig 5. Revised BMS Architectu­re to meet Safety Goal SGBMS-001 with Decomposit­ion (Ref [3])
Fig 5. Revised BMS Architectu­re to meet Safety Goal SGBMS-001 with Decomposit­ion (Ref [3])
 ??  ?? Fig 4. Safety Goal SG-BMS-001 and extension to FSR with decomposit­ion (Ref [3])
Fig 4. Safety Goal SG-BMS-001 and extension to FSR with decomposit­ion (Ref [3])
 ??  ?? Figure 6. HARA Analysis for Electric Power Steering Ref. [4])
Figure 6. HARA Analysis for Electric Power Steering Ref. [4])
 ??  ??
 ??  ?? Table 1. ASILs and Failure Rates as per ISO 26262 Standard (Ref [2])
Table 1. ASILs and Failure Rates as per ISO 26262 Standard (Ref [2])
 ??  ?? Table 3. Handling of Safety Matrices of ASILs (Ref [2])
Table 3. Handling of Safety Matrices of ASILs (Ref [2])
 ??  ??
 ??  ?? Table 2. New ASIL assignment for ADAS and higher steering rack forces (Ref [4])
Table 2. New ASIL assignment for ADAS and higher steering rack forces (Ref [4])
 ??  ?? Fig 8. EPS Control path using a dual core microcontr­oller integrated with power management and safety monitoring (Ref. [4])
Fig 8. EPS Control path using a dual core microcontr­oller integrated with power management and safety monitoring (Ref. [4])
 ??  ?? Fig 7. Redundant SW Comparison using a) same processing unit; b) different processing units (Ref. [4])
Fig 7. Redundant SW Comparison using a) same processing unit; b) different processing units (Ref. [4])
 ??  ??
 ??  ?? Fig 9. Electric Drivetrain HARA Analysis (Ref [5])
Fig 9. Electric Drivetrain HARA Analysis (Ref [5])
 ??  ?? Fig 10. Electric Drivetrain Safety Goals (Ref [5])
Fig 10. Electric Drivetrain Safety Goals (Ref [5])
 ??  ?? Table 4. Safety and ASIL Target Metrics and Logic Requiremen­ts (Ref [4])
Table 4. Safety and ASIL Target Metrics and Logic Requiremen­ts (Ref [4])
 ??  ?? Fig 11. Electric Drivetrain System Architectu­re a) without and b) with Functional Safety (Ref [5])
Fig 11. Electric Drivetrain System Architectu­re a) without and b) with Functional Safety (Ref [5])
 ??  ??
 ??  ?? Fig 14. Dependenci­es of BBW Systems with a) Centralize­d Redundancy & b) Distribute­d Redundancy (Ref. [6])
Fig 14. Dependenci­es of BBW Systems with a) Centralize­d Redundancy & b) Distribute­d Redundancy (Ref. [6])
 ??  ?? Fig 13. BBW Systems with a) Centralise­d Redundancy and b) Distribute­d Redundancy (Ref. [6])
Fig 13. BBW Systems with a) Centralise­d Redundancy and b) Distribute­d Redundancy (Ref. [6])
 ??  ??
 ??  ?? Fig 12. Electric Drivetrain Functional Safety 3-Layer Architectu­re (Ref [5])
Fig 12. Electric Drivetrain Functional Safety 3-Layer Architectu­re (Ref [5])
 ??  ??
 ??  ??
 ??  ??
 ??  ?? Fig 15. a) Distribute­d Star Topology (Ref. [6])
Fig 15. a) Distribute­d Star Topology (Ref. [6])
 ??  ?? Fig 15. b) Unidirecti­onal Redundant Ring Structure (Ref. [6])
Fig 15. b) Unidirecti­onal Redundant Ring Structure (Ref. [6])
 ??  ??

Newspapers in English

Newspapers from India