Printer Friendly

Parasitic Battery Drain Problems and AUTOSAR Acceptance Testing.

1. Motivation

The list of issues that can cause a car battery to die is so long as to approach never ending, but virtually every battery killer out there can be shoehorned into the following basic categories: battery problems, electrical system problems, simple user error (leaving Hood, Door, window, trunk in open position during park, key in ignition cylinder/proximity key states) extreme weather conditions and issues with power train codes [1, 2]. Some newer vehicles are designed to leave the headlights, dome lights, or even the radio on for a while after shut the engine off and remove the keys which will shut off on a timer [3]. In today's Auto world, the software components are high and hence this paper focuses on software code issue that causes battery drain problem in the vehicle.

Section 1 describes the possible ways of occurrence of parasitic battery drain problems in vehicle. Section 2 describes basic functionality of CAN NM and power consumptions at various levels in a vehicle. Section 3 talks about the test procedure currently followed by ECU suppliers whereas Section 4 explains the system (Infotainment) used for study and analyze battery drain issues reported from vehicle. It also relates current test method with the reported issue. Section 5 is a proposal to avoid test escape of a set of battery drain problems from supplier and it details developed simulation model and test case design (TCD). Section 6 compares the existing TCD along with recommended one and picturizes the issues identified by the proposal. Section 7 concludes this work.

2. Introduction to AUTOSAR

This paper describes importance of AUTOSAR acceptance tests and design of acceptance test suite. It explains the relationship between acceptance and interoperability, interoperability of ECUs in a vehicle, and the need to avoid diverging acceptance test standard by the ECU supplier in their engineering process.

2.1. Design of AUTOSAR CAN NM [4]

The AUTOSAR CAN NM is based on a decentralized direct network management strategy, which means that every network node performs its activities self-sufficiently depending on the network management protocol data units (PDUs) that are received or transmitted within the communication system.

The main concept of the AUTOSAR CAN NM algorithm can be defined by the following two key-requirements:

* Every network node in a CAN NM cluster shall transmit periodic network management PDUs as long as it requires bus-communication; otherwise it shall transmit no network management PDUs.

* If bus communication in a CAN NM cluster is released and there are no network management PDUs on the bus, in a configurable amount of time which is determined by CANNM_TIMEOUT_[TIME.sup.1]+ CANNM_WAIT_BUS_SLEEP_[TIME.sup.2], bus goes to sleep followed by shut down of ECU.

2.2. Sleep Mode, Current Consumption Considerations

During shut down, internal power supply of every ECU is disconnected, only the transreceiver (Tx) at physical level is active. This in turn, cumulatively reduces power consumption at vehicle level. When wakeup event is detected, Tx switches on internal power supply of ECU via INH pin [Figure 1].

As long as network PDU transmits in CAN network, ECU power supply stays connected and determined sleep current measurement cannot be achieved. Sleep current measurement at various levels are shown in Table 1[5].

3. Existing Test Method

Currently standard acceptance test suite is followed by ECU suppliers. Standard acceptance tests are written at the specification level, intended to validate the implementation of the AUTOSAR platform at its interfaces. Executing these tests validates the interoperability of the basic software stack-under-test with AUTOSAR application software components and interoperability at the vehicle network level on the other [6]. In bus level, the scope of acceptance tests includes [7]

* Bus behavior (e.g. transmission behavior, bus off handling, state management)

* Bus protocols (e.g. transport protocol, network management, diagnostic communication)

In addition to this, Product suppliers shall derive their own test suites with their permutation and combination, as a part of self-declaration of acceptance of the product. [8]

3.1. Pitfalls of Existing Test Method

ECUs continue to transmit NM message and keeps the bus awake even after sleep conditions are met. The strategy used to test the network management section focuses only on transmission of network message during startup/shutdown. Following are the drawbacks in current test method.

* On change event (signals) from nodes that controls the sleep character of other ECUs to keep the bus awake for the necessity of the network are not considered for sleep/wake up performance.

* Also the performance of the ECU wakeup due to disturbance that happens during the bandwidth of bus idle phase mostly not considered by ECU suppliers.

4. Description of System, Issues and Analysis

4.1. System Model for Study

Figure 2 shows the system model taken to study the problem. IPC unit is the master of the system while the Display unit is the intermediate gateway module that serves for the communication between master and other nodes in the system. Any node which needs to stay active, keeps the bus alive with the transmission of the network message. As long as any NM message present in the bus, other ECUs remain to be in ready to sleep state and continues transmit its application message.

Figure 2 depicts how the Display unit depends on application events <CAN>illumination status, <CAN>Key status (from Cluster unit), Audio Unit depends on <CAN>HMI status (from Display unit), and APIM looks for <CAN> Multimedia status (from display unit) for the transition of different network states of the respective ECU.

Generally, when battery drain problem is reported in the vehicle, it causes suspicious that the ECU which draws more current is a babbling node in the vehicle. For the below reported issues, initial assumption is transmission of message by any node in the network during bus idle phase causes deadlock in the system by continuous transmission of a NM message. When the occurrence is not known, simulation model is developed to create disturbance in the bus idle phase with varying duration of milliseconds, which resulted in failure identification. However, executing standard acceptance tests for network management and startup/shutdown tests does not help to recreate it.

4.2. Reported Issues Considered from Vehicle

4.2.1. Battery Drain Issue due to Illumination Status A software design change implemented in cluster unit, between two CAN signals <CAN>illumination status and < CAN>dimming status, the order in which they set their status to sleep ready state before enter into ready to sleep state. As the display unit designed to check dimming level status instead of illumination status, This change leads to failure in Display unit ability to set its ready to sleep state.

4.2.2. Battery Drain Issue due to Multimedia Status Another battery drain issue reported in the vehicle stated that failure of the display module to set it's on change event to a default value (in a specific case) before entering into "ready to sleep state" causes another ECU (Telephony unit) in the network to remain in active state. This, in turn, causes the entire network in the system to remain active.

In both the cases, one ECU looks for the state of health/data from another ECU in the network which is ready for sleep/whose job is already done correctly or incorrectly. While car makers and AUTOSAR consortium works for the concept called "Partial Networking with Selective Wake up" [9] which saves energy even during functional state of a vehicle, energy drain during non-functional mode, due to deadlock in single ECU leads to the failure of entire E/E Architecture.

With respect to the scope of interoperability, we need to clearly focus on the correct behavior of an ECU within the network that mainly relates to the handling of defined states, timing and data on the dedicated buses which is driven by OEM-specific design decisions, so-called "Communication Matrix", shown in Tables 2 and 3.

Table 3 shows the value of guards (external ECU sleep control CAN signals) that an ECUs in infotainment system needs to maintain at different states, as these signals controls the state manager of other ECUs in the system.

5. Proposed Testing Method

Figure 3 [7] provides a view of acceptance testing in the overall test activities. Basic network management testing involves standard acceptance testing and OEM specific qualification testing, which is sufficient to clear module acceptance of the product. But project specific tests - in combination with configuration - are missed to carry out which leads to startup shut down problems in the vehicles.

5.1. Test Guidelines for CAN NM Testing

In the above cases (discussed in Section 4.2), an application event has influence over the CAN NM algorithm and its transmission. Considering this as a network management testing, it will comprise into three parts:

* Basic acceptance testing provided by the OEM (ECU Test Procedure Specifications)

* Entry/Exit criteria from different network modes [3] (Appendix A.1)

* Project specific configuration combination tests

A test procedure is designed for this configuration's specific combination and implemented in various programs with the help of the simulation design shown here.

5.2. Simulation Model

With the solution identified in Section 4, test cases are designed for application events that impacts network messages of an ECU under test. Similarly, for battery drain problem described in Section 4.2.2, it is identified an application event from the device under test (DUT) that impacted the network layer of other ECUs in the network. But these events can be triggered in "n" number of combinations which cannot be predicted. E.g. multimedia system status changes during multiple user triggered events such as voice, telephony system, extended entry/exit mode, different multimedia state entry/exit conditions.

A simulation model was developed in accessory protocol interface module (APIM) node to monitor application events continuously and the node release bus (stops transmission of NM message), only when the desired event reaches the desired state (Figure 4). By any means, if the CAN event from the DUT does not reach sleep ready state, the simulation model does not allow the network to enter sleep mode.

Different network states are considered during design; if the application event from DUT gets triggered at any state, designed telephony unit simulation wakes the network and keeps it alive.

Also, simulation model is developed to continuously monitor NM message transmission (Figure 5) from the ECU. As the transmission of NM PDU, varies based on configuration and trigger events, number of PDUs are monitored for each trigger and updated via GUI to user. It is set to fail, If the number of PDUs could not match with configuration aspect. This approach eases configuration based network testing methodology.

Various network states (normal operation state, ready sleep state, prepare bus sleep mode, bus sleep mode) are monitored from the system and presented in GUI. "On change" application events that can trigger sleep/wakeup are added here, where the tester can initiate any trigger at any states. The time duration for which node is active for individual wakeup triggers are also monitored from the CAN bus and outputted to the GUI.

Figure 6 is the panel monitors the status of ECUs in the network. It shows three different stages of infotainment network. In first stage, ECUs ACM (Audio unit) and APIM (Telephony unit) are ready to sleep state where they transmit only application messages. ECUs FCDIM (Display) and IPC (Cluster) are in normal operation state which transmits both application and NM messages to keep the network active. In second stage, all the ECUs in the network are reach ready to sleep state, transmits only application messages. In third stage, the network is in complete sleep state.

Figure 7 shows various wakeup triggers for display unit and gives the duration of NM transfer for each trigger to the tester.

6. EXISTING vs PROPOSED Testing Methodology

The objective of testing is to find defects when they are cheaper to remove. Current NM acceptance testing, involves communication and electrical level robustness tests, physical level fault tolerant tests (CAN_H, CAN_L). Communication robustness includes basic startup/shut down test and accuracy in transmission of on change, on write events of application messages in CAN bus. This forms the test suite for AUTOSAR acceptance testing.

Proposed testing method is, Project specific configuration combination test and state transition test are missing in this standard testing method. This leads to occurrence of battery drain problems (due to issues in state manager) in the vehicle which is seen at customer fleet/end user that could be controlled at ECU supplier level.

For configuration testing, test suite shall be developed with possible use cases. A sample of use cases developed for display unit is shown in Appendix A2.Also test suite shall include use cases for state transition with entry/exit timings equals to boundary value conditions Appendix A1.

Interoperability testing and reuse of test suites is the main target when developing a solution for problems of any open standard. By reuse of these test suites and configuration specific combination testing, several new set of software defects has been identified across various programs in audio and display ECUs, which are listed in, Figure 8.

Table 4 displays the description of new defects identified in various programs.

7. Conclusion

This paper proposes to consider Application signals which impact other Nodes NM Behavior, as part of NM test suite. CAN signals shall be categorized into an application specific event and NM trigger events of other ECUs in the network. This boosts test depth and increases reliability of the product.

Along with standard acceptance testing Configuration specific tests need to be identified and executed. This approach will be useful to identify issues present in state manager of an ECU and provide a complete package of AUTOSAR acceptance test suite. With such test suite, several NM issues are identified which may impact entire system in the vehicle.

As a summary, AUTOSAR acceptance test identify and control the issue within the state manager of an ECU in the Network. Since the on-change application events from an ECU impacts state manager (present in system services layer of AUTOSAR Architecture [10, 11]) of other ECUs in the Network, every ECU specification shall contain communication matrix of entire Network in the system. This will aid to fulfill acceptance testing at a satisfactory level and control parasitic battery drain issues occurs in vehicle due to software failure.

Future work includes the extension of the application to CAN NM algorithm testing (Figure A.2). Multiple scenarios to be identified for the entry/exit criteria of these states and test design shall be improved further to test CAN NM algorithms as a part of network management testing.


ACM - Audio Control Module


APIM - Accessory Protocol Interface Module

AUTOSAR - AUTomotive Open System ARchitecture

CAN - Control Area Network

CAN NM - CAN Network Management

CAN_H - CAN High


DUT - Device under Test

ECU - Electronic Control Unit

ECUm - ECU State Manager

E/E - Electrical/Electronics

FCDIM - Front Control Display Interface Module

GUI - Graphical User Interface

HMI - Human Machine Interface

IPC - Instrument Panel Cluster

ICP - Integrated Control Panel

INH - Inhibit

NM - Network Management

OEM - Original Equipment Manufacturer

PDU - Protocol Data Unit

SRS - Software Requirement Specification

TCD - Test Case Design

Tx - Trans receiver

[micro]C - Microcontroller



[2.] Miller, M.,


[4.] Specification of CAN Network Management_4.2.2 (AUTOSAR_SWS).

[5.] Wake Up for Automotive Communication Networks-BOSCH, 02a 0712.pdf.


[7.] overview/acceptance-tests

[8.] Alain Gilberg, A., Bernd Kunkel, B., Alain Ribault, C., Philippe Robin, D., and Noe Spinner, E., "Conformance Testing for the AUTOSAR Standard."

[9.] Liebetrau, T., Kelling, U., Otter, T., and Hell, M., "Energy Saving in Automotive E/E Architectures."

[10.] Dhanamjayan, P.R., Kuruvilla, J., and Manjusree, S., "ECU State Manager Module Development and Design for Automotive Platform Software Based on AUTOSAR 4.0."


A. Appendix

Anandan Thiyagaraj, Visteon Technical and Services Center (VTSC)


Received: 18 Oct 2017

Accepted: 11 Mar 2018

e-Available: 18 Apr 2018



AUTOSAR, Acceptance Testing, Configuration based NM Testing, Sleep/ Wake-up performance, ECU state manager (ECUm)


Thiyagaraj, A., "Parasitic Battery Drain Problems and AUTOSAR Acceptance Testing," SAE Int. J. Passeng. Cars--Electron. Electr. Syst. 11(2):2018, doi:10.4271/07-11-02-0013.
TABLE 1 Current measurements.

Various    Current

levels     requirements
Car level  40 mA
ECU level  100-200 [micro]A
Physical   18-30 [micro]A

(1) Wait time for no NM message present in bus.
(2) Wait time for no application message present in bus.

TABLE 2 Matrix for signals and guards of different states for other

Signals/ECU        States
                   Ready to  Normal
                   sleep     state

<CAN> Multimedia   OFF       ON
status (Telephony
<CAN> HMI status   OFF       ON
(ACM Unit)

TABLE 3 Communication matrix for system with signals and guards.

ECU         <CAN>   <CAN>       <CAN>         <CAN>       <CAN>
            HMI     multimedia  illumination  key status  ASR NM
            status  status      status

Audio unit  Equals  X           X             X           TRUE
Telephony   X       Equals      X             X           TRUE
unit                ON
Display     X       X           Not           X           TRUE
unit                            Equals
Display     X       X           X             Not         TRUE
unit                                          Equals

Note: Normal state refers the state where ECU transmits NM message to
hold the bus. Ready to sleep refers ECU transmits only application
specific events in the bus.

TABLE 4 Description of NM Defects.

S. No  Issue      Description

 1.    Defect 1   Display unit enters
                  into active clock state
                  for a non-wake up trigger
 2.    Defect 2   Display unit does not hold
                  the bus when power Mode
                  > = Accessory
 3.    Defect 3   Display unit does not stop
                  Display NM Msg transmission
                  in 11 sec after PM change to
 4.    Defect 4   NA region with Active clock
                  enabled: Display unit stops
                  transmission in 1 Hr 11 sec
                  and not responds for power
 5.    Defect 5   Display unit exits active clock
                  state before the expiry of AC
                  timer when HLA =0
 6.    Defect 6   CAN signal wakeup holds the
                  bus for 11 sec
 7.    Defect 7   Sleep Indication Table issues
 8.    Defect 8   Program#1 - Sleep Indication
                  table issues
 9.    Defect 9   Program#2 - Sleep Indication
10.    Defect 10  NM Message not send in
                  Network when chime is active
11.    Defect 11  AUTOSAR message not
                  transmitted when power
                  up chimes module is active
12.    Defect 12  Clarification on Network
13.    Defect 13  Audio unit sends NM message
                  on CD source request
COPYRIGHT 2018 SAE International
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2018 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Thiyagaraj, Anandan
Publication:SAE International Journal of Passenger Cars - Electronic and Electrical Systems
Article Type:Technical report
Date:Apr 1, 2018
Previous Article:Experimental Study on the Internal Resistance and Heat Generation Characteristics of Lithium Ion Power Battery with NCM/C Material System.
Next Article:Simulation of Arc Quenching in Hermetically Sealed Electric Vehicle Relays.

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters