Automation of Electrical Fault Induction for Safety Testing of the Power Train Software in Heavy Vehicles

(1)

Automation of Electrical Fault Induction for Safety Testing of the Power Train Software in Heavy Vehicles

DANIEL FRYKMAN, HENRIK WEMMERSTEN

Master of Science Thesis Stockholm, Sweden 2013

(2)

(3)

Automation of Electrical Fault Induction for Safety Testing of the Power Train Software in

Heavy Vehicles

DANIEL FRYKMAN, HENRIK WEMMERSTEN

Master of Science Thesis MMK 2013:41 MDA 451 KTH Industrial Engineering and Management

Machine Design SE-100 44 STOCKHOLM

(4)

(5)

Examensarbete MMK 2013:41 MDA 451

Automatisering av elektrisk felinducering för säkerhetstestning av drivlinans mjukvara i tunga fordon

Daniel Frykman, Henrik Wemmersten

Godkänt Examinator Handledare

2013-06-12 Mats Hanson Carl-Johan Sjöstedt

Uppdragsgivare Kontaktperson

Scania CV AB Fredrik Jansson

Sammanfattning

Nyckelord: Inducering av elektriska fel, automatisering, testning av drivlinans mjukvara, säkerhetstest, tunga fordon.

En av de främsta prioriteringarna vid utveckling av mjukvara till tunga lastbi- lar på Scania är att verifiera att lastbilens beteende är säkert. Således spende- ras mycket tid på säkerhetstester vars syfte är att verifiera att ny mjukvara in- te medför säkerhetskritiska förändringar i fordonets beteende. De säkerhets- tester som behandlas i rapporten testar beteendet av mjukvaran i motorns styrenhet när den utsätts för elektriska fel. Bakgrunden till varför säkerhets- testerna genomförs beskrivs i ett säkerhetskritiskt och juridiskt perspektiv samt vilken testmetodik som används. Dessutom tydliggörs vilken del av ut- vecklingsprocessen som testerna genomförs i.

Slutligen utvecklas ett automatiskt testsystem för att effektivisera samt höja kvalitén av säkerhetstesterna som genomförs på Scania. De elektriska fel som kan induceras med det automatiska testsystemet är kortslutning av styrenhetens kablage mot lastbilens batteri samt kabelbrott. Resultaten ifrån tester genomförda på det automatiska testsystemet visar att säkerhetstester- na utförda manuellt respektive automatiskt är ekvivalenta. Vidare så minskar exekveringstiden för ett testfall signifikant samt att valideringsmöjligheterna förbättras genom bättre dokumentation och ökad repeterbarhet.

(6)

Master of Science Thesis MMK 2013:41 MDA 451

Automation of Electrical Fault Induction for Safety Testing of the Power Train Software in Heavy Vehicles

Daniel Frykman, Henrik Wemmersten

Approved Examiner Supervisor

2013-06-12 Mats Hanson Carl-Johan Sjöstedt

Commissioner Contact person

Scania CV AB Fredrik Jansson

Abstract

Keywords: Electrical fault induction, automation, testing of power train software, safety tests, heavy vehicles.

In the development of software for heavy-duty trucks at Scania one of the main priorities is to ensure that the behavior of the truck is safe. Hence, much time is spent on safety tests where the purpose is to verify that new software does not imply safety critical changes in the behavior of the vehicle.

The safety tests treated in this thesis are about testing the reliability of the software in the electronic control unit while it is exposed to electrical malfunctions. The background of why the safety tests are performed is described in a legal and safety critical perspective and also what test methodology that is used. Further the phase in which the safety tests are carried out in the development process is highlighted.

Finally, an automated test system is developed for increasing the efficiency as well as the quality of the safety tests performed at Scania. The electrical malfunctions that are possible to induce with the automated test system are short-circuiting to battery of the truck and disconnections. The results from the tests performed on the automated test system indicate that the safety tests that are performed manually respectively automatically are equivalent. Further, the results show that the time to perform the tests significantly decreases and the possibility for validation is improved through better documentation and increased repeatability.

(7)

Preface

We would like to thank our supervisors,Carl-Johan Sjöstedt at KTH, Örjan Söderberg and Håkan Bengtsson at Scania for the regular feedback each week and for the support during this master thesis. Also thanks toFredrik Jansson, the head of system test engine at Scania and our examinerMats Hanson at KTH for making this thesis possible. We are also grateful for the support thatTommy Andersson at Scania provided with the manufacturing of the prototype.

The theory chapters in the thesis consist of two individual segments whereHenrik Wemmersten is the author of Chapter 3 and Daniel Frykman of Chapter 4. The residual of the report is written together.

(8)

(9)

Abbreviations

ABOB Automated Breakout Box

BAT+ Battery Anode

BAT- Battery Cathode

BOB Breakout Box

CAN Controller Area Network DAC Digital-to-Analog Converter DOC Diesel Oxidation Catalyst DPF Diesel Particle Filter DTC Diagnostic Trouble Code

EC European Commission

ECU Electronic Control Unit EGR Exhaust Gas Recirculation EMS Engine Management System FMEA Failure Mode Effect Analysis GPIO General Purpose Input/Output GUI Graphical User Interface HIL Hardware-in-the-Loop

IEEE Institute of Electrical and Electronics Engineers LED Light Emitting Diode

MCU Micro Controller Unit MIL Malfunction Indication Light

(10)

OBD On Board Diagnostics PCB Printed Circuit Board

POT Potentiometer

PWM Pulse Width Modulation RPN Risk Priority Number

SCR Selective Catalytic Reduction TTL Transistor-Transistor Logic

UART Universal Asynchronous Receiver/Transmitter USB Universal Serial Bus

VCI Vehicle Communication Interface VGT Variable Geometry Turbocharger VVT Verification, Validation and Testing

(11)

List of Figures

1.1 The electronic control unit for the power train at Scania. . . 1

2.1 The V-model. . . 6

3.1 Engine components. . . 10

4.1 The classification tree of testing techniques. . . 17

4.2 Hardware-in-the-Loop schematic. . . 21

5.1 A Breakout Box. . . 24

5.2 System overview. . . 25

5.3 The manual faults. . . 26

5.4 The configuration of relays. . . 27

5.5 A simple current limiter. . . 29

5.6 The control of the relays. . . 30

5.7 Flow chart of the software in the microcontroller. . . 32

5.8 Flow chart of a typical test case with the automated test system in Python. . . 33

5.9 Schematics of the modularity of the hardware. . . 36

6.1 The automated test system. . . 37

6.2 The Graphical User Interface . . . 39

List of Tables

5.1 The possible electrical faults. . . 28

5.2 Input commands and response messages for the microcontroller. . . 31

(12)

Introduction

The increasing amount of electronics in vehicles and tougher legislations, e.g. regarding diagnostics and emissions, enhance the need of additional software. [1] In order to maintain satisfied customers and keep the vehicle safe and flawless, software testing is mandatory. However, the fact that the software is at constant development whereas the reliability of the truck still needs to be maintained introduces the need of regression tests that each new version of the software needs to pass. Some of these regression tests are currently performed manually in full-vehicle which does not provide repeatability in an exact manner. One of these tests is a full-vehicle safety test which purpose is to verify that no dangerous situations occur when an Electronic Control Unit (ECU), see Figure 1.1, in the truck is subjected to electrical malfunctions. More specifically, how the software of the ECU acts when electrical malfunctions occur. The electrical malfunctions that the ECU is subjected to in the safety test are short-circuits to battery and disconnections.

These should be detected by the ECU, in terms of Diagnostic Trouble Codes (DTCs) and corrective actions, in order to prevent dangerous situations to arise.

Imagine a mechanic performing a service on a truck and a wire of an ECU connected to a peripheral unit is accidently disconnected or short-circuited. Will the fault affect the driver in any way? Could the fault propagate and thereby inhibit any safety critical functionality? Will the driver be informed if something is wrong?

Figure 1.1. The ECU for the power train at Scania.

(16)

CHAPTER 1. INTRODUCTION

1.1 Purpose

The purpose of this thesis is to shorten the duration of test cases regarding the safety critical functions of the ECUs, as well as covering more test cases in a more rigorous way.

To run tests faster and more accurately automation is preferable. With an automated environment, the safety tests, involving the truck standing still, could be executed during nights which would increase the utilization of the test-vehicles. Thus, more focus can be put during the days on other tests that require full operation of the truck. Furthermore automation will provide repeatability in terms of exact execution and documentation of the tests. Another aspect is the economical one. An estimation of how much time that is consumed on the safety tests is about 1200 man hours each year and this time only entails testing of the ECU dedicated for the Engine Management System (EMS). Thus, a small increase of efficiency has potential to yield a significant reduction of the time spent on the tests in question.

1.2 Research Question

The answer this thesis will acquire regards the following question: How could an automated test environment for electrical tests of full-vehicles be designed? Sub questions that arise are: what are the advantages and disadvantages with an automated environment, in terms of effectiveness, safety and time? Does it add uncertainties into the testing process?

1.3 Method

To answer the questions stated in the section above a background study was performed.

The purpose of the study was to understand how to identify critical parts of the system that need to be a part of the safety tests and the reason behind performing them, as well as their importance. Further, knowledge was acquired about different testing techniques to understand why the manual safety tests are formed as they are and why they are performed in full-vehicles.

When the essential theory was obtained, the design of an automated testing environment took place. The design was an iterative process where the stakeholders of the project were informed regularly in order to, as early as possible, identify any deficiencies or misconceptions in the design. Finally the developed prototype was tested in a full- vehicle where a part of the safety test was automated. The tests were performed in order to verify and validate the automated test system. These tests are the results which made it possible to draw conclusions and answer the research question.

1.4 Testing Environments

When performing tests, emphasis must be put on the selection of an appropriate testing environment. If the purpose of a test is to verify logical functions in the software, a sufficient test environment could be a Hardware-In-the-Loop (HIL) environment, presented 2

(17)

1.5. PROJECT DELIMITATIONS

in Chapter 4. However, when for instance testing emission levels, the theoretical models implemented in a HIL system may not always be consistent enough or legally justified. In that case the most suitable testing environment could be in an engine test bed. Although when the purpose of testing is to ensure safety or driving behavior, the most appropriate environment is in the vehicle’s designated environment, i.e. full-vehicle tests.

The manually performed safety test for the EMS on a heavy-duty vehicle is in principal performed as following: The EMS is programmed with the software that should be tested.

Two Scania Vehicle Communication Interfaces (VCIs) are connected to the vehicle, one dedicated for reading DTCs and the other one for internal variables. The wiring for the actuators and sensors, which normally go directly into the EMS are routed through a Breakout Box (BOB). Further, a test case is executed according to the test specification. A typical part of the test concerns short-circuiting an actuator to the battery, which is done manually with the BOB. Another part of the test could be to simulate signals from different sensors to the ECU. Finally the test results are compared with the expected outcome and documented.

1.5 Project Delimitations

The main focus in this thesis is on the development of an automated test system that can be used when testing the safety critical functionality of the EMS on heavy-duty trucks, more specifically how the software behaves if electrical malfunction occurs. The electrical malfunctions in question are short-circuits to battery and disconnections. The implementation of the individual test cases in the safety test is put aside, since the HIL framework provides the necessary functionality for validating the tests. Therefore the implementation of the test cases for the safety test will be trivial. For the agreed requirements of the automated test system, see Appendix A.

1.6 Thesis Outline

The thesis is divided in two parts, a pre-study and a project part. The pre-study consists of Chapters 2-4 which describes the theory behind the full-vehicle testing. These chapters describe the test cycle and in which phase the full-vehicle tests take place. The rationale of testing is also described, where a question like, why are the safety tests performed? is answered, in both legal and safety aspects. In the final theory chapter, different testing techniques are described where automatic testing is highlighted in order to understand how the software within the ECUs can be tested.

The second part covers the design and the implementation of the automatic test system for the full-vehicle electrical safety tests. The implementation chapter describes the requirements of the test system and how they are achieved through software and hardware design. In Chapters 6-7 the automated test system is evaluated, results are formed and conclusions are drawn based on the results in order to answer the research question.

(18)

(19)

Chapter 2

The Testing Procedure

In this chapter the phases of a project are described as well as the test activities performed in each phase. The phase in which the safety tests are performed is in the early integration phase before releasing new software outside the departmentResearch and Development at Scania. Finally, the termsfault, error and failure are distinguished.

2.1 Verification, Validation and Testing

In order to understand the concept of Verification, Validation and Testing (VVT), the individual terms need to be defined. The association for advancing technological in- novation, Institute of Electrical and Electronics Engineers (IEEE), defines them as follows : [3, p.14,18]

Verification: “The process of evaluating a system to determine whether the products of a given lifecycle phase satisfy the conditions imposed at the start of that phase”.

Validation: “The process of evaluating a system to determine whether it satis- fies the stakeholders of that system”. A typical validating question would be- Have we built the right system?, compared to the verifying one- Have we built the system right?

Testing: “An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component”.

The purpose of VVT is to find and eliminate faults at an early stage in the project.

To accomplish that, VVT thinking should be implemented in all phases of the project.

Especially when the requirements of the project are developed, it is crucial that these are testable. Thus, the system can be verified and validated towards them during the entire cycle of the project. In another point of view, the purpose of VVT is to eliminate defects within the constraints time, money and other resources.

(20)

CHAPTER 2. THE TESTING PROCEDURE

The next section describes the phases of a common project model, where the focus is put on how the VVT activities are implemented in each phase.

2.1.1 The V-Model

One way to visualize how a project can be executed is the V-model. It was developed after problems arose with the earlier waterfall model. One of the main problems concerning the waterfall model is that it presumes stable and known requirements at the beginning of the project, which implies high and unnecessary risks. Due to the lack of iterative thinking in the waterfall model, bugs and system faults are bound to be found at the later stages of the project which can be devastating due to increased cost of the development. [4]

The V-model can visually be represented as the letterV, hence its name, see Figure 2.1.

The left side is describing the requirement and the designing phases and the right side is containing the validation, verification and testing. Each layer of the V-model seen from the top is regarded as a coupled pair, i.e. the system should be tested towards the system requirements.

User Requirements

System Requirements

Detailed Design

Implementation Global Design

Component Test Execution

Integration Test Execution

System Test Execution

Acceptance Test Execution

Definition

Design Integration

Qualification

Implementation

Figure 2.1. The V-model. The highlighted phase is where the safety test for the EMS is performed.

6

(21)

2.1. VERIFICATION, VALIDATION AND TESTING

Phases of the V-Model

In the first phasesystem definition, the system, hardware and software requirements are formulated precise and completely. The requirements should be written in a VVT perspective, which means that they should be well defined and testable. Thus, making it possible to test and validate the system towards the pre-defined requirements.

When the system proceeds to the next phasesystem design, VVT will have a greater role, in terms of test strategies. In this phase, the concept, the principles and the architecture of the system are developed. The overall system is divided into subgroups and the relations between them are described. In this phase a risk-based analysis called Failure Mode Effect Analysis (FMEA) can be performed, in order to identify the critical functions and risks, which ease the development of the test strategies. Read more about FMEA in Chapter 3. Prior proceeding to the implementation phase, the design is validated and verified that it meets the system requirements. One way to accomplish this is by the means of a virtual prototype which enables early validation. By utilizing the virtual prototype during the coming phases the physical tests can be reduced and their corresponding cost.

The next phase system implementation concerns the realization of the design concept developed in the previous phase. For hardware systems, the implementation only concerns a prototype. At the end, all the individual functions, subsystems, components should exist and be functional. The part of the VVT is to verify the system against its requirements as well as validating towards the stakeholders. This process should be iterative. Before entering the integration phase, unit testing is performed in order to confirm that the components and functions work as intended.

In thesystem integration phase the implemented subsystems should be interconnected into a complete system. The role of the VVT in this phase is to verify that the system as a whole and the interfacing between the subsystems works and meets the requirements.

The testing can be done in a HIL testing environment where the software is acknowledged to work as intended with the surrounding components, environment and according to the system design specification. This is the phase where the safety test for the EMS software is performed at Scania. The majority of these tests are usually performed manually, since they are safety critical and plenty of them require that the vehicle is operated on a road, which is hard to achieve automatically. However there are some tests that do not require a maneuvered vehicle, such as testing of some electrical hardware malfunctions and part of the diagnostics.

The last phase,system qualification is the assurance phase. The system runs through formal tests often requested by agencies, standards and customers. No development of the system should ideally be done during this phase. The VVT goal is to assure quality, and more formally validate and verify requirements from the systemdefinition phase. [3]

2.1.2 Types of Malfunction

Amongst test engineers a common way to distinguish malfunctions is to separate them into three types: fault, error and failure. The different types and their correlation are explained below.

(22)

CHAPTER 2. THE TESTING PROCEDURE

A fault, often called a “bug”, is a flaw in the design that will appear when an appropriate test is introduced to the system. The fault is caused by a human. It could be badly designed software or the test case itself. According to a phenomenon called The Pesticide Paradox, the effectiveness that tests, performed multiple times, have on bugs tend to de- crease as soon as the development of the software goes further. That means that regular maintenance of test cases is of great importance in order to prevent software bugs. [5]

When a fault in a system is activated it results in an error which can lead to a failure if the system violates its specification.

If a system is decomposed into several sub-systems, the chain of fault, error and failure could be applied recursively. For instance, if a mechanic by mistake disconnects a wire for a sensor or an actuator, a fault is introduced. When the ignition is turned on and the engine starts, the fault is activated due to the absence of the actuator or sensor, causing an error. If the error affects the operation of some part of the vehicle such that it cannot perform according to its specification, it is said to be a failure. Thus, an error does not necessarily result in a failure. [6]

The chain of fault, error and failure can be demonstrated with an example from the safety test. The EMS is exposed to a faulty input signal coming from a sensor. The faulty signal could have been caused by another component’s failure somewhere else in the system.

The output from the sensor is read by the ECU. Depending on the implementation of the software, the signal could be deemed as faulty. If the ECU acts upon the signal then an error has occurred. If that affects the operation of the truck, it yields a failure. In that case there are solutions for preventing the failure to propagate further into the system. The faulty sensor could be deactivated and if the system is redundant, another sensor could be used instead. Other options are to use the last valid value from the sensor or calculate a theoretical value. Without these implemented corrective actions, the engine control could become unstable which could lead to other failures of the vehicle, e.g. engine failure. This is partially what the safety test is about, verifying that the chain of propagating failures into the system is stopped before it harms the driver or the vehicle.

8

(23)

Chapter 3

Rationale for testing

This chapter describes the reasons for performing the full-vehicle tests in both a legal and a safety perspective. First some of the engine components are described briefly in order to understand why these are important to test. Further, vehicle diagnostics is introduced which is one of the legislations for trucks. The last section treats a risk-based analysis method which is used to identify potential hazards in a system in order to sort out what to include in the safety tests. This is important for the implementation of the automated test system dedicated for the safety tests. This since the analysis provides a systematic approach of how to identify potential deficiencies in the system where corrective actions are needed in order to mitigate the failure effects.

3.1 Engine Components Overview

As the emission legislations have become stricter, with the introduced Euro 6 legislation in 2013 according to [7], new subsystems have been added to the after treatment system of a diesel engine. The emissions from a diesel engine consist of hydrocarbons (HC), ni- trogen oxides (N Ox), carbon monoxide (CO) and soot particles. In order to achieve the emission levels required by Euro 6, the following components are integrated in a diesel engine: Exhaust Gas Recirculation (EGR), Selective Catalytic Reduction (SCR), Diesel Ox- idation Catalyst (DOC) and Diesel Particle Filter (DPF), see Figure 3.1. The simplified functionalities of these are described below.

The purpose of EGR is to cool and re-circulate the exhaust gases into the cylinder which decreases the flame temperature due to added mass and less amount of oxygen. This in turn results in less exhaust-gas emissions. The amount of re-circulated exhaust-gases is controlled by a valve. What also is added to the engine, partly for lowering the emissions, is the intake throttle. Together with the Variable Geometry Turbocharger (VGT) and the EGR accurate control of the amount of oxygen in the cylinder is achieved.

The first part in the after treatment system is the DOC, where diesel is injected in order to oxidize CO into CO₂ and water vapor H₂O as well as N O to N O₂. The last oxidation is important for the functionality of the down-stream components. The DOC is followed by the DPF, where soot particles formed in the combustion chamber are filtered.

(24)

CHAPTER 3. RATIONALE FOR TESTING

Figure 3.1. Engine components.

Downstream, the SCR is placed which function is to reduce N Ox into N2. In principal a chemical solution called Urea, also known as AdBlue, is added which reacts with the N Oxin the SCR.[1]

These components, forming the after treatment system are complex and require plenty of sensors for optimal operation and control. Another essential part is the fuel-injection system, which consists of a set of injector attached to a common rail. The pressure in the rail determines how much fuel that can be injected into the cylinder during a specified time and it is controlled by a valve.

A failure of one of these components could end up in a safety critical situation. For instance, if the valve controlling the pressure in the rail fails and the pressure changes in a non-controllable manner, the engine could start to rush if not proper handled by the ECU. Therefore finding the potential failures and estimating what effects they will have are essential.

3.2 Official Legislations

For a vehicle to be released on the market the manufacturer has to obtain an approved certification of the vehicle’s technical requirements, called EC-type approval. In Europe it is the European Commission (EC) that determines whether or not the vehicle is approved.

Some of the inspected requirements concern emissions, diagnostics, electromagnetic com- patibility, torque output and contingency plans in case of severe malfunction. [2]

This section will mostly aim on the diagnostics part of the legislation, since that is interlaced in the safety test which is in the scope of the project.

3.2.1 On Board Diagnostics

Due to the rise of electronics and use of software in the automobile, the complexity has increased which puts hard demands on diagnostics. Due to the stricter emission control legislation, the emissions are now required to be monitored. The additional system that monitors the emissions during the vehicle operation is called On-board Diagnostics (OBD). [8] According to the European-OBD legislation formed in January 2001, any fault that relates to the emissions need to be logged and displayed to the driver. [9] OBD of an electronic system is the capability of the ECU of interpreting and performing self- 10

(25)

3.2. OFFICIAL LEGISLATIONS

monitoring tests with the use of software. It means that the ECU should detect failures and store them as DTCs. This includes monitoring of sensor supply voltage, detection of short-circuiting and disconnected wires i.e. open circuits. Plausibility checks are done continuously, e.g. the crank shaft and the cam shaft speed are compared. Thus it is possible to detect if a sensor is broken or if its output is faulty. Other critical sensors like the pedal sensor are redundant, meaning that there is more than one sensor, with which the signals are compared. [8] The exhaust emissions are primarily controlled by the EMS and the exhaust gas after treatment ECU. These two control units combined have the strategies for how to run the engine and how to keep the emissions down. They are connected to a number of actuators and sensors that are crucial for the engine and the emission control to function. Each system performs an internal diagnosis for their protection.

With the European-OBD legislation, it is mandatory to detect failures in the engine and emission control system. If a fault results either in a raise of the emissions above the pre-described threshold level or if a major functional failure of the control system occurs, the fault must be indicated. [2] If an emission related fault is detected, it is stored as an event within the emission control system. This results in a so called limp home mode, where certain restrictions in the operation of the truck are applied, such as limitation of the speed or torque. This is done in order to maintain driving safety and avoid break- down of the engine and for minimizing the exhaust-gas emissions. [8] It also provides the possibility to proceed to the closest workshop for repairs. The occurrence of an emission related failure connected to the OBD should be visualized in the instrument cluster, to in- form the driver about the violation. In Europe, the fuel injection system, DOC, DPF, EGR and SCR are some of the components, according to [2], which need to be supervised of the OBD. All of the relevant DTCs must be readable using a standard diagnostic tool, called a scan tool. The approved standard protocol for reading the error codes is Controller Area Network (CAN), using either ISO 15765 or SAE J1939. The procedure for the testing of the OBD should, according to [2], be done as follows:

1. The malfunction of a component that belongs to the EMS or the emission control system should be simulated.

2. Further, the simulated malfunction should be preconditioned over the specified pre- conditioning cycle, i.e. the engine should be operated of the purpose of achieving stability of itself, the emission control system and for the OBD monitoring.

3. After stability has been achieved, the engine should be operated with the simulated malfunction over the OBD test cycle, which is a shortened European Stationary Cycle (ESC) where the same individual modes shall be performed.

4. Finally the OBD has to react to the simulated malfunction and indicate it in an appropriate way e.g. in the instrument cluster, alerting the driver with a Malfunction Indication Light (MIL).

(26)

3.3 Risk-Based Analysis

One method of risk-based analysis is called FMEA, which is an engineering technique, commonly used during the system design of a product before it reaches the customers, to define, identify and eliminate potential risks and failures in the system. The generic course of action for performing a FMEA is following:

1. Determine the failure modes.

2. Identify the effect of each failure mode and grade the severity, the occurrence rate and the probability of detecting the failure mode.

3. Calculate a Risk Priority Number (RPN), which is the product of the severity, the occurrence rate and the probability of detecting the failure mode. [10]

The failures that are especially important to identify and get rid of are single-points of failure. A single point of failure is when a failure of a part propagates into the whole system, causing it to fail. Imagine a network, where a router connects the nodes. A failure of the router would lead to a complete failure of the whole network. [11] With a truck as example, a possible single-point of failure could be the sensor for the engine speed.

Without knowing the engine speed, the truck cannot operate. Thus, these single-points of failure should at all cost be avoided. One solution is to introduce redundancy, which in the previous example would include multiple sensors. Then it is up to the ECU to choose which sensor to trust.

Additional safety could include mathematical models for calculating a reasonable value, which in turn can be compared with the sensor value. If these two values significantly differ and the model is trustworthy, the sensor can be disregarded. If the mathematical models are not accurate enough, the last valid sensor value can be utilized for further operation.

3.3.1 The Purpose of FMEA

FMEA is an effective tool to use during the conceptual and preliminary design of a system in order to get an understanding of the reliability of the system. Identifying the failure modes at an early stage in the development is preferable in order to mitigate the effects of a failure. Although, the analysis may be most efficient in terms of affecting the design decisions, it should also be conducted during the entire life cycle of the system. The results are also useful for developing test plans and for increasing the reliability of the system. [12]

3.3.2 Failure Mode

In order to define a failure mode the meaning of a functional failure must be clear. Hence, two definitions are made, according to [13, p.71], where a function of an item can be defined as“the work that an item is designed to perform”, where an item can be a unit, for 12

(27)

3.3. RISK-BASED ANALYSIS

instance a component. Thus, a functional failure can be defined as“the inability of an item to carry-out the work that it is designed to perform within specified limits of performance”.

The last definition yields that there are two types of functional failures. One where the function cannot perform any of its intended work, i.e. a complete loss, and another where it do not fulfill the specified requirements, i.e. a partial loss. Considering a failure mode as either a functional failure or a potential failure it could be explained as follows:

A mode in which a complete or a partial loss of a function occurs or where a functional failure could arise. [13]

3.3.3 Failure Effect

A failure effect is, according to [13, p.140], defined as “the immediate results produced by failure” and can easily be mistaken for another term, failure consequences. However the difference is that a failure effect initially starts at component level whereas the failure consequences are the eventual results. The failure consequences can among others be safety, economically or environmentally related. The safety related refers to that the failure affects the operational or physical functions of the system which could result in severe incidents. When a failure leads to loss in production or any other situation such as a carriage company losing money, it is economically related. For instance, a produced failure which triggers an corrective action in a truck could force the driver to seek service, i.e. valuable time is lost. Environmentally consequences could for example regard a truck exceeding the emission levels. [13]

3.3.4 Types of FMEA

Two of the approaches in FMEA which are applicable in engineering design are described below.

The functional FMEA: This approach looks at the system as it is designed to perform certain functions classified as outputs. Losses of important inputs are evaluated regarding their effects on the performance of the system.

The equipment/assembly FMEA: The individual equipment are listed and the effects of their failure modes in a system performance perspective are analyzed. [13]

Furthermore FMEA may be divided into three classifications.

Design-level FMEA: This type of FMEA is applicable for validating certain design parameters chosen for a functional performance requirement. The benefits are the ability of identifying potential design related failure modes and asess design alternatives during the preliminary phases of the design process.

(28)

System-level FMEA: The highest level of the FMEA which is performed in a system’s hierarchy in order to prevent failure modes related to the subsystems in the early design phase. Additionally, one benefit is that potential failure modes that occur in a complex system structure, i.e. integrated systems, are identified.

Process-level FMEA: Using this type facilitates the identification and pre- vention of failures related to the manufacturing process for equipment. It is performed in the design phase, where potential failure modes are identified among the equipment, which helps the engineers to change their design.

3.3.5 Implementing FMEA

Prior performing FMEA, a hierarchical description should be generated describing the layers of the system. A system is defined, according to [13, p.135], as“a complete whole of a set of connected parts or components with functionally related properties that links them together in a system process”.

The topmost layer is the system-level and further down major assemblies and sub- assemblies etc. This decomposition of the system continues until the lowest layer is reached, where the number of levels is determined by the complexity of the system. The lowest level, at which the analysis ends, needs to be recognized. A general rule is that the lowest layer is one level below the level where control of the design exists. For instance for a Printed Circuit Board (PCB), the signals are controllable but the components itself, e.g. capacitors, are not. In that case the lowest level concerns the understanding of the failure modes of the capacitor. Taking these failure modes into account during the design of the circuit board may prevent these to occur. [12]

At the lowest level, the physical functions and their functional relationships should be defined. A functional relationship of a component should be described using only two words, a verb and a noun. For instance, an injector in an engine could be described as, inject-fuel. If the relationship cannot be described with only two words, then more than one relationship exists. [13]

Proceeding to the next step of the FMEA, the functional requirements of each item in the system should be listed. The functional analysis is performed on each item at each level in the hierarchy, which includes the function of the item and its attribute, meaning its purpose respectively its characteristics. [12]

After the functional requirements and the functional relationships have been determined, the next step is to consider the failure modes and their failure effects. Since engi- neered systems are designed to fulfill certain performance criteria, a failure mode is only considered to have occurred when the behavior of equipment changes with respect to its performance criteria. When the failure modes and effects have been determined, the severity (S) of the failure effect, the probability (P) of the failure to occur and the likelihood (D) of detecting the cause should be listed. [13] The grading is between 1-10, where 10 is the most severe. Generally the effects of the failure modes which are deemed to be safety critical are considered severe. [12] In order to rank which failure modes and effects that 14

(29)

3.3. RISK-BASED ANALYSIS

have the highest risk a RPN could be calculated. The RPN is the product of S, P and D and the purpose of it is to decide on what failure modes that need corrective actions. There are limitations using the RPN since it is formed out of subjective ratings. It should not alone be used for risk assessment. Sometimes it is preferable to calculate the RPN only taking the severity and the occurrence rate into account, since a less severe failure mode still can have a high RPN due to a high detection rate. Therefore high severity should always be addressed as the highest risk.

3.3.6 Advantages and Disadvantages

Analyzing the failure modes of the system highlights those in need of corrective actions.

Low-level faults and single-points of failure are identified which may propagate into the system, causing it to crash and may put the user into danger. Besides evaluating possible failures in a system, FMEA also encourages cooperation at an early stage between the participated departments in the product development. [10] One disadvantage with FMEA is that it typically does not cover failure modes related to human and software errors. Fur- thermore, in order to apply FMEA on a complex system when considering the contribution of system-level effects, all the stakeholders of the system are required to participate. [3]

3.3.7 Test Case Design

At Scania, FMEA is performed during the design phase in order to identify the failure modes of the system which are in need of corrective actions. This is done in order to guarantee that safety critical situations do not occur. When the corrective actions have been implemented, that prevents the error from propagating into a system failure, the severity of the failure modes and the effects of these are graded. The parts of the system which are deemed to be safety critical, i.e. high severity, are included in the safety test, in which they are exposed for rigorous and accurate testing until they are considered flawless. In a common test case a fault is introduced into the system and the response of it is observed. The response refers to DTCs, internal states and the overall behavior of the vehicle. In tests as the safety test for full-vehicle, where an actuator or sensor is short-circuited to supply voltage, one purpose is partially to test the redundancy of the system and that there does not exist a single-point of failure which could lead to safety critical situations.

(30)

(31)

Chapter 4

Testing Techniques

This chapter describes different types of testing techniques. These techniques are widely adapted into all sorts of testing; however, the focus here is how to utilize these techniques within software testing. In software, one common way to classify testing techniques is to divide them into static and dynamic testing, see Figure 4.1. Static testing means that the software is not operating, whereas dynamic refers to that the code is being executed during the test. This study is done in order to investigate if the methods used in the safety tests, of the software in the EMS, are appropriate or if different methods would be preferable.

Testing Techniques

Review

Dynamical Testing

Black-Box (Specification)

White-Box (Structural)

Statement Coverage

Decision Coverage

LCSAJ

Equivalence Partition

Boundry Value Analysis

Risk Based Testing Informal

Review

Technical

Review Inspections Walkthroughs

Equivalence

Class Variance Class

Analysis Experience

Based

Exploratory Testing

Error Guessing Finding Defects Measure

Data Flow Control Flow Syntax Flow Static Testing

Dynamic Analysis

Combinatorial Testing

Figure 4.1. The classification tree of testing techniques. [14]

(32)

CHAPTER 4. TESTING TECHNIQUES

4.1 Static Testing

Static testing is generally conducted in the form of reviews or analysis. These types of techniques are ways for the author of the software to improve and adjust code based upon criticism from the reviewers. The reviews can take many forms as can be seen in Figure 4.1. The most formal technique within the review branch is called a walkthrough.

This is a way of allowing the author to explain how the structure of the code is intended to work. All formal reviews are well documented and followed up. There are also informal reviews which usually are carried out under more casual circumstances.

For the inspection, which is less formal than a walkthrough, all faults found are logged and followed up by one of the attending moderators. The second branch of static testing is analysis, which emphasizes the flow of the data and syntax. This branch is more of an integration testing technique that makes sure that the testing is consistent with how external functions are supposed to use the functions or system under test.

The goals of static testing differ depending on what technique is used. For instance a technical review has the goals of ensuring that technical concepts are implemented in a way that is consistent with the functionality needed from the document under revision.

The goal of a walkthrough is to establish a common understanding of the document, at the same time as it forces the author to actually inspect the code of the document and think it through. [15]

4.2 Dynamic Testing

In dynamical testing, the system under test is being observed while the code is running.

4.2.1 White-Box and Black-Box Testing

A major part of dynamical testing is white-box and black-box testing, where the box refers to the system and the color is a descriptor of how the system is being tested.

A white-box refers to that the full system is known and gives the possibility to test software in a more systematic and intrusive way. Since the system is known, it is easier to design tests for states and transitions of the software. In practice, testing all states and transitions can be difficult to realize due to the fact that complex code yields more possible states than what is reasonable to test. White-box testing is often called structural based testing.

The idea behind black-box testing is to verify that the system behaves according to its specification. This differs from white-box testing since only the output of the system is of interest and not how the output was produced. [3] This technique is a way to confirm that pre-designed system functions are working as expected. Black-box testing is a good technique to use if an outside aspect of the system is wanted since the tester does not need to be aware of the implementation of the system, only its output. Black-box testing is often called specification based testing.

As often in reality, these classifications can be hard to follow since many tests demand knowledge both about the inside and the outside of the implementation of the system.

18

(33)

4.3. POSITIVE AND NEGATIVE TESTING

Therefore a combination of both white- and black-box testing called grey-box testing was developed. In reality, the tester has a good idea of how the system is designed and is able to alter the data repository. For the test to be called grey it is essential that the tester affects or has knowledge about both the inside and outside of the system. [16]

4.2.2 Combinatorial Testing

The combinatorial testing is an analytical method for revealing unintended interactions between functions in a system. Test cases using this technique usually create tuples of different types of variables which are used as input to the system under test. In order to do this a combinatorial strategy is needed. A common strategy is to couple the variables in pairs, for all possible permutations of input parameters. The technique is good at reducing unnecessary test cases due to the pair wise coupling. Thereby, the perceptual outcome of the executed test cases are improved. [17]

4.2.3 Experience Based Testing

Another common way to find bugs is to use experience based testing which is more of an approach than an actual testing technique. It is based upon previous experience of commonly occurring software bugs. For instance, inexperienced software engineers tend to do a number of basic mistakes such as missing double assignments in logical comparisons.

An experienced programmer knows about the high occurrence rate of these mistakes and can therefore create test cases to eliminate these bugs.

One technique within experienced based testing is called exploratory testing which is a common technique used when new functionality is released. For instance, when a new function in a truck is released, an experienced tester starts to try it out and is free to interact with it in order to verify without any preconceived restrictions. [18]

4.3 Positive and Negative Testing

Another attribute of each technique is whether the test is positive or negative. Testing if a system meets certain requirements according to a test specification is called positive testing. The primary purpose for these tests is validation, i.e. is this system working correctly according to its specification. During these tests only valid data and wanted behavior are tested. On the contrary, negative testing refers to testing outside the specification, with the purpose to obtain falsification, i.e. testing that certain occasions are not handled by the system. [5]

To create new test cases the tester should trigger failure modes, identified in the FMEA in Chapter 3, in order to verify that the corrective actions are implemented correctly.

Further, the tester could also use a negative testing approach, where failures in the system, outside the test specification, are tried to be found. A common way to find these failures is to use black-box testing, this since the output of the system is often easier to analyze.

Combining these two methods yields additional valuable test cases.

(34)

CHAPTER 4. TESTING TECHNIQUES

4.4 Automatic Testing

To assure quality of a product that continuously increase in complexity, such as a vehicle, increased testing is required. This increase can in some cases be more extreme than others.

One way to produce test results in a faster rate is to automate tests. This is especially true when tests need to be repeated multiple times. In the case of the safety test for the EMS, that this handles, the test is required to be executed for each new release of the software.

Automatic tests are always executed in a precise way which provides the possibilities to detect minor changes of the test results. Automatic testing generates test reports and the results can afterwards be inspected by a human before approval. This is one way to maintain high quality assurance.

Automatic testing is not applicable in all cases and even if it is, it does not mean that it will become cost effective. Since automation of testing in many cases introduces a new system there is a potential risk to insert faults into the testing process. This implies that the automated test system has to be tested as well. Thus, the cost will increase. It is also essential to ensure that the testing equipment is not affecting the tested system in any significant way; otherwise there is a possibility that the test results are invalid.

Instead of drastically increase the amount of test vehicles the focus is put on performing the tests in a higher rate. Partially this is executed through automation of previously manual test cases that do not require human supervision. Furthermore by automating tests it is possible to run them during night as well which provides the test vehicles to be utilized in a more efficient way.

The sort of tests this thesis is focusing on is safety critical regression tests that will ensure that new versions of the EMS software will not alter the reliability of the vehicle.

Hence trying to eliminate software faults as early as possible in the development process is important. Regression tests concern testing that the older functions still fulfills their specifications when new functions are added in the software. The safety critical test is similar for each version of software and each configuration of vehicle, except for some additional extensions of the tests for more complex vehicles.

4.4.1 Hardware-in-the-Loop

To test components and subsystems of the system they can be connected to a computer that provides the tested item with a simulation of the environment it is designed for.

This is a practical way to perform tests since it is possible to isolate errors to one single component. In practice the HIL configuration can differ from case to case, but the main idea is to run a model of the system that is to be developed and then replace a part of the model with the actual component. Since a large proportion of the model is accessible it is possible to implement automatic testing in the HIL environment, as follows in Figure 4.2.

With a HIL environment it is possible to simulate electrical faults, such as short- circuiting of connectors on the ECU. However, without the actual system it is hard to guarantee that the overall behavior of the vehicle is safe. The real components can be hard to model and predict. Thereby, short-circuiting or simulating a bad signal on the ECU may not end up with the same result as it would with a complete vehicle. For in- 20

(35)

4.4. AUTOMATIC TESTING

Figure 4.2. Hardware-in-the-Loop schematic.

stance, short-circuiting a fuel injector could lead to a critical situation, where it constantly injects fuel into the engine. This could in turn result in, if not handled correctly by the ECU, that the engine starts to rush in a non-controllable manner.

The HIL environment is suitable when it comes to testing the behavior of the ECU in different environments since it is relatively easy to simulate ambient conditions, such as low air pressure and low temperatures etc. The testing of the ECUs could be done using boundary value or exhaustive testing techniques which in a real truck may be hard to perform. Though, to ensure that the behavior of the ECU is safe it is also tested in full-vehicle tests. [19] The safety test for the EMS is performed according to the grey box testing technique. This since the tester needs to change both variables and data repositories while observing the outcome of the test.

(36)

(37)

Chapter 5

Implementation of the Test System

The implementation chapter of this thesis aims to create an electronically controllable test system. With this system it should be possible to fully automate the safety tests for heavy-duty vehicles that are standing still. The obtained theory from Chapters 2-4 is the basis of the implementation of the automated test system. Chapter 3 has led to an understanding of how safety critical the safety tests actually are. In fact, an incorrect implementation of the automated test system could have devastating consequences. Some of the identified failure modes during the implementation of the automated test system are documented, see Appendix B. These are the basis for the safety functionality implemented in the automated test system. For instance when ambiguous test results occur, it is better to categorize them as incorrect rather than passing them. Further, VVT thinking will be applied throughout the development of the automated test system. This since it is crucial that the system is testable towards the stakeholder requirements in all phases in the V- model, see Section 5.2 for the system requirements.

5.1 Project Description

The safety test in question is about to induce electrical malfunctions to an ECU in a controlled way. This is done while observing the variables of the system, this in order to make sure that the ECU behaves according to its specification. The manual way of performing these test cases are done with help of a BOB, see Figure 5.1 for the BOB for the EMS. It provides an easy access to the cables that are connected between the ECU, the actuators and the sensors of the vehicle.

At the bottom in Figure 5.1 two connector houses where the cables from the actuators, sensors and other peripheral units can be connected. Each cable is routed through a jumper which can be seen on top of the BOB. The other side of the jumper is then routed through four cables entries which are located in the top of Figure 5.1, these entries con- tain cables can connected to the ECU. Thus, if a disconnection of a cable is wanted then the corresponding jumper is removed. Furthermore, if a test requires a cable to be short- circuited, the wanted voltage source is connected to the junction on top of the cable’s corresponding jumper.

(38)

CHAPTER 5. IMPLEMENTATION OF THE TEST SYSTEM

Figure 5.1. The BOB for the EMS at Scania.

5.2 Requirements

Some of the requirements on the automated test system are that it should be able to create all types of electrical faults that can be performed by the BOB manually in the safety test. It is crucial that an arbitrary actuator or sensor can be manipulated one at a time.

That includes disconnection and short-circuiting to a variable voltage source in the range of 0 − 24V with a resolution of 0.1V . Furthermore the system should fit inside the cabin of the truck and be portable, since it is going to be utilized and moved between different trucks. It should also be designed in such a way that it can be adaptable to work with other ECUs. The system should be able to induce faults on actuators, sensors and other peripheral units such as communication buses.

In order to efficiently utilize the automated test system it is required to provide a software based interface which must allow full control of the fault induction. The software interface should also be able to read DTCs and observe variables that are of interest.

The software should also create a report of the test result so that any deviations from the specified requirements are documented. For a list of the requirements on the ABOB, see Appendix A.

5.3 System Overview

The automated test system developed in this thesis is furthermore referred as an Auto- mated Breakout-Box (ABOB). The ABOB contains relays which provide the same functionality as the BOB with the significant difference that the ABOB is electronically controllable. The controllability comes from General Purpose Input/Output (GPIO) pins attached to a Micro Controller Unit (MCU). The MCU is interfaced to a computer through 24

(39)

5.4. HARDWARE ARCHITECTURE

serial communication with a set of programmed commands that indirectly controls the relays. The safety test is divided into test cases which are implemented in the script pro- gramming language Python on a computer. In parallel, VCIs are utilized to read internal variables and DTCs to the computer. The gathered information is automatically compared with the test specification in the script and a test report is generated. This is visualized in Figure 5.2.

Internal variables

ECU Peripheral

units DTCs

Relays Transistors

MCU Python Test report

Figure 5.2. System overview.

5.4 Hardware Architecture

When designing a system that should induce electrical faults, such as short-circuiting, it is crucial that neither the test system nor the system tested is affected in such a way that it may falsify the test results, which is one of the failure modes in Appendix B. To prevent this from happening the ECU and the MCU are separated by electromechanical relays. The relays provide a galvanic isolation between the different systems, given that the power supplies are not connected, at the same time as it can conduct high currents which occur in the case of short-circuit.

(40)

It is preferable that the relays are configured in such a way that will minimize their amount and at the same time allow all the electrical faults to be carried out. The GPIO of the MCU is operating at Transistor-Transistor Logic (TTL) level which does not provide the required power to supply the relays used in this application. Therefore transistors are used to amplify the power to a sufficient level.

In the following sections the subsystems within the ABOB, see Figure 5.2, are described. They are divided into four types of PCBs, one for the MCU, the transistors and two for the relay configuration.

5.4.1 Induction of Fault

The amount of cables of the components attached to the ECU is varying. For instance, some actuators are supplied with a Pulse Width Modulation (PWM) signal that can provide a high current. These components have only two cables connected, one for supply and one for ground. Temperature sensors usually act like a resistive load that varies with the temperature which alternates the voltage drop over the sensor. These sensors utilize only two pins of the ECU. Furthermore, some peripheral units utilize three or more pins where for instance one pin is for supply, one for ground and the third for the output of the component. However, more types of components might exist for other ECUs. Therefore a method has been chosen that will provide the possibility to conduct faults regardless of the pin configuration of the component.

The types of faults that are desirable to induce are disconnection of cables and the ability of short-circuiting to the Battery anode or cathode (BAT+,BAT-) of the vehicle or a variable voltage source such as a Potentiometer (POT), see Figure 5.3. The two last mentioned faults should be possible to do either with or without load. The load can be any component that is attached to the ECU, for instance an actuator.

ECU LOAD ECU LOAD

BAT+, BAT- or POT

Figure 5.3. The manual faults.

26

(41)

5.4. HARDWARE ARCHITECTURE

5.4.2 Relay Configuration

In order to accomplish the faults represented in Figure 5.3 for a load with two cables, a configuration of relays is made according to Figure 5.4. The figure can be separated into three subparts which consist of the relaysA-D (the left relays) the rail and the relays E- H (the right relays). The rail acts as a voltage distributor to the left relays. The voltage level of the rail is determined by the right relays. What also is illustrated are that the left relays come in pairs of two, for instanceA and B, one pair for each cable. Thus, this setup of relays is independent of the amount of cables of the load. Simply add another pair of relays for each additional cable.

L O A D

ECU

R A I L

BAT-

BAT+

DAC

A B

D C

E F

G H

3 1

POT

4 2

Figure 5.4. The relay configuration which is exemplifying how one load is connected to the ABOB.

The faults that are possible to induce with the relay configuration in Figure 5.4 and how to achieve them for node3 are exemplified in Table 5.1. These faults never concern the load separately since the safety test is dedicated to ensure the reliability of the ECU.

For the normal state, i.e. no faults, no power is needed since relayA and D normally conducts current. If a cable disconnection is wanted eitherA or D is powered, meaning that they will not conduct. If node3 in Figure 5.4 is to be connected to the rail, relay B should be powered. If the load should not be attached while short-circuiting the ECU, relay A should also be powered. Further, in order to supply the rail with either BAT+, BAT-, Digital-to-Analog-Converter (DAC) or a manual potentiometer, the states of relays E-H should be altered according to Table 5.1.

(42)

Table 5.1. The faults for node 3 visualized in Figure 5.4. The numbers 1 and 0 denote whether the relay is powered or not and the letter x means an independent state. For applying the same faults for node4, column D, A and C, B are switched.

Fault for node 3 Relays

A B C D E F G H

None 0 0 0 0 x x x x

Disconnect LOAD from ECU 1 0 0 0 x x x x

Short-circuit BAT+ with load 0 1 0 0 0 1 1 0 Short-circuit BAT+ without load 1 1 0 0 0 1 1 0 Short-circuit BAT- with load 0 1 0 0 0 1 0 x Short-circuit BAT- without load 1 1 0 0 0 1 0 x Short-circuit to DAC with load 0 1 0 0 0 1 1 1 Short-circuit to DAC without load 1 1 0 0 0 1 1 1 Short-circuit to POT with load 0 1 0 0 1 x x x Short-circuit to POT without load 1 1 0 0 1 x x x

5.4.3 Electronic Control Units

In a Scania truck there are more than 20 ECUs handling everything from brakes to air conditioning which all are linked via a common coordinating ECU. Needless to say the layouts of the ECUs differ. The ABOB should be adaptable to fit the whole range of ECUs with only minor adjustments. To prove the concept, the cabling of the ABOB was routed for half of the EMS which consists of 70 pins. That means that the required amount of relays is twice as many plus four additional for the rail. The reasons why the EMS is the selected unit for this prototype are as follows: It is one of the most safety critical units since it is responsible for the control of the engine where a potential failure could result in a harmful situation. Another reason is that the EMS controls a wide range of components with various characteristics which will provide sufficient testing in order to validate the ABOB.

When designing safety critical systems, a lot of effort must be put on the robustness aspect. No errors in the system should lead to devastating failures. Therefore a failure of a component or a system must be detected on time.

The EMS shall be able to detect loose cables of components and withstand short- circuiting. These aspects are tested in the safety test at Scania. Correct DTCs shall appear if for instance an actuator is short-circuited to BAT+, and the ECU should disconnect from the dangerous currents, in order to not harm it. The most obvious way of protecting electrical components involves having a fuse. Though, sometimes it may be preferable to limit the power temporarily. In that case, a current limiter integrated in the circuit may be a good solution. An example of how a current limiter can be implemented can be seen in Figure 5.5. The reason why this is brought up is that it determines the required size of the copper traces and the components of the PCBs in the ABOB. This since the ECU can detect and avert short-circuits.

28

Automation of Electrical Fault Induction for Safety Testing of the Power Train Software in Heavy Vehicles

Automation of Electrical Fault Induction for Safety Testing of the Power Train Software in Heavy Vehicles

DANIEL FRYKMAN, HENRIK WEMMERSTEN

Automation of Electrical Fault Induction for Safety Testing of the Power Train Software in

Heavy Vehicles

Sammanfattning

Abstract

Preface

Abbreviations

List of Figures

List of Tables

Contents

Chapter 1

Introduction

1.1 Purpose

1.2 Research Question

1.3 Method

1.4 Testing Environments

1.5 Project Delimitations

1.6 Thesis Outline

Chapter 2

The Testing Procedure

2.1 Verification, Validation and Testing

Chapter 3

Rationale for testing

3.1 Engine Components Overview

3.2 Official Legislations

3.3 Risk-Based Analysis

Chapter 4

Testing Techniques

4.1 Static Testing

4.2 Dynamic Testing

4.3 Positive and Negative Testing

4.4 Automatic Testing

Chapter 5

Implementation of the Test System

5.1 Project Description

5.2 Requirements

5.3 System Overview

5.4 Hardware Architecture

L O A D

ECU

R A I L