Parasitic Battery Drain Problems and AUTOSAR Acceptance Testing.
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 . 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 
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.
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 . In bus level, the scope of acceptance tests includes 
* 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. 
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"  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  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  (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.
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
ASR NM - AUTOSAR NM
APIM - Accessory Protocol Interface Module
AUTOSAR - AUTomotive Open System ARchitecture
CAN - Control Area Network
CAN NM - CAN Network Management
CAN_H - CAN High
CAN_L - CAN Low
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., http://www.searchautoparts.com/automechanika-chicago/commitment-training/parasitic-battery-drains
[4.] Specification of CAN Network Management_4.2.2 (AUTOSAR_SWS).
[5.] Wake Up for Automotive Communication Networks-BOSCH, http://grouper.ieee.org/groups/802/3/RTPGE/public/july12/hoganmuller 02a 0712.pdf.
[7.] http://www.auto sar.org/about/technical- 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."
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 level (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 ECUs from FCDIM Signals/ECU States Ready to Normal sleep state <CAN> Multimedia OFF ON status (Telephony unit) <CAN> HMI status OFF ON (ACM Unit) TABLE 3 Communication matrix for system with signals and guards. Signals ECU <CAN> <CAN> <CAN> <CAN> <CAN> HMI multimedia illumination key status ASR NM status status status Audio unit Equals X X X TRUE ON Telephony X Equals X X TRUE unit ON Display X X Not X TRUE unit Equals OFF Display X X X Not TRUE unit Equals keyout 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 keyout 4. Defect 4 NA region with Active clock enabled: Display unit stops transmission in 1 Hr 11 sec and not responds for power button 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 issues 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 Management 13. Defect 13 Audio unit sends NM message on CD source request
|Printer friendly Cite/link Email Feedback|
|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.|