Evaluation of Electric-Vehicle Architecture Alternatives

Purnendu Sinha, Vinod Agrawal*

Global General Motors R&D, India Science Lab
GM Tech Center (India), Bangalore 560066, India
Email: [email protected]
(*) Former GM Employee

Abstract—As trends in electric-vehicle (EV) research show baseline system-level architecture which includes sensors, con-
that with introduction of advanced electric-propulsion systems, troller, actuators and communication networks. The proposed
ensuring continued safe operation of such automotive system may baseline architecture is then analyzed by a single-element-
require high-integrity system design for both hardware and soft-
ware components. Furthermore, key subsystems must have cer- fault-analysis technique considering both random and system-
tain degrees of fault-tolerance capabilities for mitigating potential atic failures. This analysis renders information about criti-
hazards resulting due to random or systematic failures. With cal system-components whose failure or unavailability may
that perspective, this paper describes our proposed approach have severe consequences on the overall system performance.
for developing system-level EV architecture alternatives with Taking into account technical safety concepts, system-level
different levels of fault-tolerance capabilities and also discusses
rationale for design choices and trade-offs. These architectures redundancy and controls are then incrementally introduced
have been evaluated following the guidelines of the draft ISO in this baseline architecture for avoiding undesired vehicle
26262 Standard. behavior and/or mitigating potential hazards.
Our specific contributions in this paper include: (a) defini-
I. I NTRODUCTION tion of a functional EV architecture and high-level system-
Electric propulsion technologies can lead to significant safety requirements, (b) starting with the developed baseline
improvements in vehicle performance and energy utilization architecture which is derived out of this functional architec-
efficiency [1], [2], [5]. Certain sub-systems such as electric ture, illustration/discussion of an incremental way of introduc-
propulsion system, electric brake- and park-by-wire systems ing redundancy to develop new architecture alternatives for an
need to have certain measures (e.g., fault-tolerance including electric vehicle with varied degrees of fault-tolerance capa-
fail-safe, fail-operational, etc. capabilities) for mitigating po- bilities, and (c) analysis of proposed architecture alternatives
tential hazards which could occur due to both random failures through reliability analysis techniques following the guidelines
and systematic failures in such systems. We follow guidelines of the draft ISO 26262 Standard.
of the safety management process being developed by the draft The paper is organized as follows: Section II describes
ISO 26262 Standard [3] for functional safety of E/E systems our proposed approach for EV architecture development. Sec-
in road vehicles to develop approaches for providing such tion III presents a high-level functional architecture of an
measures. Based on the preliminary hazard analysis (PHA)1 electric vehicle and system safety requirements. The baseline
conducted for a generic battery electric vehicle, for the identi- and two variants of fault-tolerant system-level architectures
fied potential hazards under worst-case risk assessment, these are discussed in Sections V and VI, respectively. Section VII
three sub-systems namely electric propulsion system, electric presents analysis of proposed architecture alternatives. Sec-
brake- and park-by-wire systems have been categorized as tion VIII concludes the paper.
ASIL D. II. P ROPOSED A PPROACH FOR E LECTRIC V EHICLE
We have developed an approach for providing architectural A RCHITECTURE D EVELOPMENT
support for fault-tolerance at the system level following the
guidelines developed by the draft ISO 26262 Standard [3]. We present a methodology for providing architectural sup-
We start with sub-system level specification and performs port for fault-tolerance at the system level. Our approach in-
functional decomposition to derive a functional workflow. corporates guidelines of the safety management process being
Based on this workflow, a functional architecture is developed. developed by the draft ISO 26262 Standard for functional
In accordance with the draft ISO 26262 process, at this stage safety of E/E systems in road vehicles [3]. The key aspect is to
the findings of preliminary hazard analysis (PHA) are taken identify single-point failures in the system and suggest some
into account, which lists hazards and their potential causes as form of redundancy either structural or analytical depending
well as safety goals. Derived functional safety requirements on the criticality/severity to handle such faults. Fig. 1 depicts
necessitate that these systems exhibit fail-safe/fail-operational our proposed approach.
behavior. Based on this functional architecture, we develop a
1 Results presented in this paper are preliminary in nature and bear no We briefly explain the overall process. Availability of the
relevance to any production-intent electric-vehicle development program. overall system functional specification at some level of func-

978-1-61284-247-9/11/$26.00 ©2011 IEEE

 Fig. 1. Our Approach for Defining Architectural Support for Fault-tolerance

tional details is the starting point for our approach to pro- interpreter receives driver’s inputs from steering wheel, brake
ceed. The process begins with sub-system level specification pedal, accelerator pedal, etc. and then considering vehicle
and performs functional decomposition to derive a functional speed and projected vehicle path, generates propulsion and
workflow. Based on this workflow, we draw a system structural brake torque commands to be sent to the electric motor(s). The
view for a specific sub-system. In accordance with draft ISO vehicle motion control consists of two main blocks – (a) the
26262 [3] safety management process, at this stage we also path controller which as per desired path to be followed gives
take into account the findings of preliminary hazard analysis forces and moments demands to the force distributor which
(PHA) which lists hazards and their potential causes as well as determines the desired forces to be given to each motor, and
safety goals. For each sub-system, all critical elements which (b) energy management controller which calculates the desired
could be a single-point of failure in the system are identified power needed from the power supply, determines the state of
from the related structural view. After having identified a the charge and estimates the overall traction force to be sent to
set of critical elements for each subsystem, we then take command integrator/controller unit. The command integrator
a union of these sets, and derive a set of critical-elements and allocator block combines the requests coming from the
for the top-level system. At this stage, we can also draw vehicle motion control and the energy management units and
a mapping of critical structural elements and sub-systems determines/distributes the torque request to each motor. The
which highlights the importance or impact of each critical motor controller receives a torque/speed command and drives
element in terms of dependencies of different functions on the motor accordingly, and also sends feedback to the vehicle
this specific element. Continuing with the main thread of motion control/driver command interpreter.
activity, we perform detailed structural decomposition of each
critical element. At this stage we also take into account A high-level system functional architecture for an electric
functional safety concepts/requirements. Per PHA inputs, we vehicle encompassing functional blocks described earlier is
also incorporate suggested controls or possible measures to shown in Fig. 2. Some of the critical sensors could employ
handle the identified hazards. Based on these inputs as guiding different redundancy schemes (for example, triple-modular-
principles and a functional specification of critical structural redundancy configuration for brake-pedal inputs, duplex con-
elements as well as the impact-map of critical elements figuration for accelerator-pedal inputs, etc.) for fault-tolerance.
identified in the structural diagram, we define the system-level With recent trends in integrated modular controls, it has been
architectural support for fault-tolerance driven by the safety- envisioned that vehicle motion control and energy management
criticality requirement. strategies/algorithms can be mapped on to a single ECU with
due consideration for both spatial and temporal partitioning.
Power Electronics block integrates different power electronics
III. E LECTRIC V EHICLE : F UNCTIONAL A RCHITECTURE &
devices such as inverter, protector, connector, fuses, etc. RESS
S YSTEM S AFETY R EQUIREMENTS
may consist of a high-voltage battery and an optional super-
We first describe some of the key functional blocks of capacitor to store charges. APM converts 360V DC into 12-
an electric vehicle and then present a high-level functional 24V DC for other electronics/control devices in the vehicle. In
architecture for the same. Driver interface and command Fig. 2, the lower-boxed unit deals with energy management.
 Fig. 2. Proposed Electric Vehicle System-level Functional Architecture Fig. 3. Fault-Tree for Unintended Acceleration Hazard for Propulsion System

V. H IGH -L EVEL BASELINE S YSTEM A RCHITECTURE AND

IV. FAULT-T REE A NALYSIS FOR I DENTIFIED H AZARDS
P RELIMINARY S INGLE -E LEMENT FAULT A NALYSIS
A set of potential hazards has been identified based on Based on the functional architecture depicted in Fig. 2, a
generic functional aspects of an electric vehicle. A system- structural view for the system is developed. It is considered
safety-risks assessment was conducted and vehicle-level safety that a single electronic control unit (ECU) called Motion and
requirements were derived. Table I shows a partial list of Energy Controller (MEC) can manage both vehicle motion
PHA results. As per the draft ISO 26262/CD guidelines, safety and energy management functions. The Power Inverter Module
requirements of various sub-systems are as follows: (PIM) represents the conglomeration of power electronics
devices. This structural view (as shown in Fig. 4) forms the
• Propulsion system – Fail-safe baseline system architecture for our study. Different commu-
• Regenerative energy storage system – Fail-operational nication buses such as CAN or FlexRay can be used with
• Park-by-wire – Fail-Operational sufficient redundancy (for example, a dual-channel FlexRay
• Brake-by-wire – Fail-operational bus can be used wherever redundant communication path is
From system-level architecture point of view, our purpose required).
of using fault-tree techniques is to understand root causes and
logical relationships of basis events that would lead to specific
hazards mentioned above.

A. Fail-safe Propulsion System

The unintended vehicle acceleration hazard is primarily due

to malfunctioning of electric propulsion system. Following the
high-level functional architecture as presented in Section III
(see Figure 2), there are two main potential factors for this
hazard to occur: (a) due to motor-driver (power electronics
inverter/converter) faults, an electric motor creates too much
(or unintended) torque; (b) the motor controller requests
unintended positive torque. The second factor could result due Fig. 4. Vehicle-Level System Architecture for an Electric Vehicle (Baseline)
to (a) the motor controller could be faulty or the local torque
monitor fails to check the unintended positive torque request For the baseline system architecture (See Fig. 4), a basic
from the motor controller and (b) erroneous sensor values single-element fault analysis is performed to examine whether
as inputs to the controller resulting from faulty drive-mode a specific component’s failure has any impact on other sys-
selection switch, vehicle speed sensors and/or acceleration tem elements, which eventually could result in an undesired
pedal sensors. Logical relations among these events are shown system-behavior (see Fig. II). Some of the underlying assump-
in Figure 3. tions include:
 TABLE I
S AFETY R ISKS A SSESSMENT

Sub-Systems Potential Hazard Title Worst-Case Risk Assessment

Propulsion Unintended vehicle acceleration due to unintended
positive torque from the propulsion system ASIL D
Regenerative energy storage system Unintended loss of power from the storage systems
leading to loss of power to the vehicle systems ASIL D
Brake-by-wire Unintended loss of deceleration (no brake apply) ASIL D
Park-by-wire Unintended park disengage ASIL D

• The MEC module will do all the calculations necessary two diagonally opposite EMBs are available. As parking brake
for safety-related functions. needs to be fail-operational, to avoid single point MEC failure,
• The vehicle can be brought to a safe state prior to a FL EPB and FR EPB are connected to MEC#1 and MEC#2,
second independent fault. respectively. As an alternate architecture design, considering
• Each wheel will have frictional brakes. Front wheels will both MECs can form a fail-operational unit (based on dual-
have electric-park-brake calipers. An electric park brake duplex concepts with each MEC being a fail-silent unit), both
will engage when PRNDL moves to ‘P’ position and the FL and FR EPBs can be connected to both MEC modules
vehicle speed is very low or zero. with MEC#1 being the primary controller to send park brake
• When a PIM becomes non-operational, then the associ- command to EPBs. In case MEC#1 fails, MEC#2 can send
ated wheel(s) will be free-wheeling and the associated the command on the communication buses D and E. The
damper(s) will exhibit default behavior. PIM has two communication controllers to be able to connect
Table II essentially captures the fact that if a specific to two MECs via separate communication buses. Moreover,
component fails or is unavailable, then which actuators or the communication bus F is considered to have dual-channels
other system components would be impacted due to this (redundancy) to ensure that sensor data are communicated
failure. For example, for the architecture shown in Fig. 4, to both MECs in case one of the channels fails. Next, as
if the MEC module fails, then we would basically loose regenerative storage system needs to exhibit fail-operational
propulsion, frictional brakes, electric park brakes, steering, characteristics in order to mitigate a potential hazard of
RESS management and HMI. Other table entries can be “unintended loss of power from the storage systems leading
interpreted in a similar way. to loss of power to the vehicle systems,” we have included a
redundant RESS (also associated sensors as shown in Fig. 4)
VI. P ROPOSED EV S YSTEM A RCHITECTURES WITH in the architecture. The motor can have dual-windings that can
FAULT-T OLERANCE C APABILITIES be energized independently of each other [4].
We next discuss how in an incremental manner fault-
tolerance capabilities can be introduced in the baseline archi- Architecture Alternative #2
tecture based on an understanding of the failure behavior of In both the baseline and the alternative #1 architectures, the
the system components and their interactions. PIM and the electric motor could still be single-point failures.
Architecture Alternative #1 As a first step towards introducing redundancy in electric
The total loss of MEC module in the baseline architecture motor and a corresponding PIM, we could have small-sized
could lead to a potential hazard or into a non-operational state electric motor connected to the rear axle to provide limp-home
for different functionalities. As a first step towards introducing mode capabilities or creep-torque to drive the vehicle for a
fault-tolerance, we include an additional MEC module in the shorter distance at a low speed. As an alternate design, rear
architecture (See Fig. 5(a)). Note that each MEC module in-wheel motors could also be considered as prime movers
is designed to be fail-safe/fail-silent. It is also possible to along with the front motor. However, given the recent trends
configure these two MEC modules to form a fail-operational and advancements in in-wheel motor technology as being con-
MEC module based on dual-duplex schemes. We also address sidered, we could use an in-wheel motor (and corresponding
issues related to replica-determinism and task-synchronization PIM) each in two rear wheels. This configuration is shown
for proper functioning of such architecture configurations. in Fig. 5(b). To ensure uninterrupted communication between
two MECs and three PIMs we propose using redundant buses
(e.g. dual channel FlexRay bus) with active stars (to tolerate
With two MECs configuration, we can also split the control point-to-point link faults). Moreover, both PIMs and MECs are
of FR/RL and FL/RR friction brakes among them as shown having two separate communication controllers that connect
in Fig. 5. MEC#1 controls FL/RR friction brakes via sending to two active stars (AS#1 and AS#2). Also, communication
command over communication bus E and MEC#2 does the buses B and C connecting redundant RESS’s to the two MECs
same for FR/RL friction brakes via communication bus D. are considered to have redundant buses/channels. Regenerative
This is suggested from vehicle stability perspectives to ensure dampers on the front wheels are connected to the front PIM
that in an event of a MEC failure, the braking forces from and that on the rear wheels are connected to the corresponding
 TABLE II
P RELIMINARY S INGLE -E LEMENT FAULT A NALYSIS

Components EMB EPB EPS Motor RESS HMI

FR FL RR RL FR FL
MEC X X X X X X X X X
PIM X X
Comm. b/w MEC& PIM (Bus A) X X
Comm. b/w MEC& FR/RL (Bus D) X X
Comm. b/w MEC& RR/FL (Bus E) X X
Comm. b/w MEC& RESS (Bus C) X X
Comm. b/w MEC& RESS (Bus B) X X
Motor X X
EMB FR X
EMB FL X
EMB RR X
EMB RL X
EPB FR X
EPB FL X
360V Power Supply X X
12V Power Supply X X X X X X X X
Speed Sensor (SS) X
Steering Angle Sensor (SAS) X
IMU X
Brake Pedal Position Sensor (BPPS) X X X X
PRNDL Position Sensor X X
Accelerator Pedal Position Sensor (APPS) X X
Parking Brake Position Sensor (PBPS) X X
Sensor Comm. Bus (Bus F) X X X X X X X
Actuator Comm. Bus (Bus G) X X

Fig. 5. Fault-Tolerant Electric Vehicle Architectures: (a) Alternative #1 and (b) Alternative #2

PIMs. mechanical brakes (diagonal pairs) and regenerative braking

are considered.
As the analysis has been carried out only for illustration
VII. A NALYSIS OF A RCHITECTURE A LTERNATIVES purposes, without specifying exact failure rates for individual
In this section, we present reliability-block-diagram (RBD) components, we have assumed the failure rate to be 1 × 10−8
based analysis of proposed architecture alternatives for an (a representative value) for all components and the system
electric vehicle. Fig. 6 shows RBD in the context of electric life-time to be 3800 hrs (driving time of 380 hrs/year for
propulsion, brake- and park-by-wire systems for architecture 10 years). As shown earlier in Table I, all three subsystems
alternative #2 and the end events considered are loss of propul- namely propulsion system, brake- and park-by-wire systems
sion, loss of park-brake and loss of braking, respectively. Note have been categorized to be ASIL D and as per the draft ISO
that the RBD captures the nuance that (a) both rear in-wheel 26262 guidelines, the systems need to satisfy the requirement
motors would be required to provide the desired propulsion of having a failure rate less than 1×10−8 per operational hour.
torque in case the front motor fails, and (b) for braking, both For RBD analysis, we have used the Reliability Work-
 Fig. 6. RBD for Different Subsystems for Architecture Alternative #2

TABLE III
R ELIABILITY E STIMATES FOR EV A RCHITECTURE A LTERNATIVES

Systems Alternatives MTTF [h] Downtime [h/lifetime] Unreliability Failure Frequency [/h]
Propulsion Base 1 × 107 0.722 3.8 × 10−4 1 × 10−7
Alt. #1 1.77 × 107 0.289 1.52 × 10−4 4 × 10−8
Alt. #2 2.51 × 107 2.94 × 10−5 2.31 × 10−8 1.22 × 10−11
Braking Base 1.51 × 107 0.361 1.9 × 10−4 5 × 10−8
Alt. #1 1.95 × 107 0.217 1.14 × 10−4 3 × 10−8
Alt. #2 2.32 × 107 0.0722 3.8 × 10−5 1 × 10−8
Park Brake Base 1.74 × 107 0.361 1.9 × 10−4 5 × 10−8
Alt. #1 2.83 × 107 0.144 7.5 × 10−5 2 × 10−8
Alt. #2 2.5 × 107 0.0722 3.8 × 10−5 1 × 10−8

bench tool from Isograph. Benefits of our proposed incre- was also presented. Our preliminary analysis shows that signif-
mental approach for introducing fault-tolerance are reflected icant improvement in reliability estimates can be achieved with
for Architecture Alternative #2 (See Table III) in terms of a systematic approach for introducing fault-tolerance for meet-
(a) improvement in MTTF (e.g., by a factor of 2.5 for ing stipulated safety/reliability requirements as recommended
propulsion), (b) substantial decrease in total downtime (e.g., by the draft ISO26262 Standard.
by a factor of 5 for braking and park-brake), (c) decrease
R EFERENCES
in unreliability (significantly for the propulsion system) and
(d) overall, meeting the requirement of failure rate less than [1] C.C. Chan, “The State of the Art of Electric and Hybrid Vehicles,” Proc.
of the IEEE, Vol. 90, No. 2, pp. 247-275, Feb. 2002.
1 × 10−8 per operational hour. [2] Y. Hori, “Future Vehicle Driven by Electricity and Control - Research
on Four-Wheel-Motored: UOT Electric March II,” IEEE Transactions on
VIII. C ONCLUSION Industrial Electronics, Vol. 51, No. 5, October 2004.
We have proposed system-level-architecture alternatives [3] ISO/CD 26262-5 “Road Vehicles - Functional safety” Part 5 Product
Development: Hardware Level, 2008.
with fault-tolerance capabilities for an electric vehicle. We [4] C.B. Jacobina, et al., “Reconfigurable Fault Tolerant Dual-Winding AC
have illustrated a step-wise manner to introduce fault-tolerance Motor Drive System,” IEEE 36th Power Elect. Specialists Conf., 2005.
capabilities to a base architecture to derive other architecture [5] Yan-e Zhao, et al., “Development of a High Performance Electric Vehicle
with Four-Independent-Wheel Drives,” SAE 2008-01-1829, 2008.
alternatives. Reliability analysis of three subsystems electric
propulsion system, electric brake- and park-by-wire systems