PMS Device Tester

 System Specification

 

 

 

 

 

 

 

 

 

 

 

 

Project:                      Device Tester

Author:                      Dipl. Ing. Uwe Prahm

Kontakt:                     info@prahm-ms.de

Version:                    2.0

Last modification:    10.01.2020

Prahm Microcomputer Systems

  Gätgensstrasse 6

82587 Hamburg

 

 


 

Inhaltsverzeichnis

 

1        Introduction.. 4

1.1       The purpose of the device tester 4

1.1.1       Test of requirements. 4

1.1.2       Stress tests. 4

1.1.3       Long term tests running in loops. 4

1.2       Document history. 5

1.3       Reference documents. 5

1.4       Contents of pictures. 6

1.5       Content of tables. 6

1.6       Abbreviations. 6

2        System overview.. 7

2.1       Device Tester overview.. 7

2.2       The components of the Device Tester 8

3        The test specification.. 9

3.1       Introduction to test specifications. 9

3.2       Principal build-up of a test specification.. 10

3.2.1       Test module. 10

3.2.2       Test group. 10

3.2.3       Test case. 11

3.2.4       Test step. 11

3.2.5       CAN message. 11

3.3       PMS-Test Driver calls in the test specification.. 12

3.4       The PMS Test Driver routines. 13

3.4.1       Addressing an IO card. 13

3.4.2       PMS Test Driver CAN or SPI routines. 13

3.4.3       Test procedures. 14

3.4.4       Common CAN and backplane message structure. 15

3.4.1       PMS-Test Driver test specification routines. 16

3.5       A test step example. 17

4        The Device Tester Rack. 18

4.1       The advanced features of the Device Tester 18

4.2       The 19” rack system.. 19

4.3       The main board. 19

4.4       The IO boards. 19

5        The Backplane Bus. 20

5.1       Description of the backplane bus signals. 20

6        Power supply. 20

 


1      Introduction

1.1       The purpose of the device tester

The purpose of the device tester hardware is the verification of all of the requirements for the device as well as to prove the functional safety of the system.

1.1.1              Test of requirements

Each item of the requirement specification must be counter tested as specified in the AutoSAR specification. The test specification must strive to test all possible combinations of states, which are possible for the system. A 100% test coverage is the target, although very often not practicable.

1.1.2               Stress tests

Stress tests shall prove that all requirements are met also on harsh conditions. To test this, the system is tested if it can withstand for example excessive temperatures, forces, voltages and currents up to the required limits and thereby still fulfils all requirements.

1.1.3               Long term tests running in loops

Many errors only occur after longer terms. So longer tests are running in loops until a predefined time has run out or a certain number of loops have been passed.


1.2       Document history

Version

Datum

Bearbeiter

Kommentar

1.01

27.03.2017

Prahm

Initial version with ARM Cortex M3

2.00

10.01.2020

Prahm

B1-Sample with ARM Cortex M4, changes on the backplane bus

 

1.3       Reference documents

 [EMV-1]:        Richtlinie 2004/108/EG des europäischen Parlaments UND DES RATES vom 15. Dezember 2004 zur Angleichung der Rechtsvorschriften der Mitgliedstaaten über die elektromagnetische Verträglichkeit und zur Aufhebung der Richtlinie 89/336/EWG

[EMV-2]:         Gesetz über die elektromagnetische Verträglichkeit von Betriebsmitteln (EMVG) vom 26.02.2008.

[EMV-3]:         DIN EN 61000-6-4: Elektromagnetische Verträglichkeit (EMV), Teil 6.4: Fachgrundnormen – Fachgrundnorm Störaussendung  für Industriebereiche. September 2007.

[EMV-4]:         DIN EN 61000-6-2: Elektromagnetische Verträglichkeit (EMV), Teil 6.2: Fachgrundnormen – Fachgrundnorm Störfestigkeit für Industriebereiche März 2006.

[EMV-5]:         DIN EN 61000-6-3: Elektromagnetische Verträglichkeit (EMV), Teil 6.3: Fachgrundnormen – Fachgrundnorm Störaussendung - Wohnbereich, Geschäfts- und Gewerbebereich sowie Kleinbetriebe. September 2007.

 [SI-1]:             Richtlinie 2006/95/EG des Europäischen Parlaments und des Rates vom 12. Dezember 2006 zur Angleichung der Rechtsvorschriften der Mitgliedsstaaten betreffend elektrische Betriebsmittel zur Verwendung innerhalb bestimmter Spannungsgrenzen.

[SI-2]:              DIN EN 60950-1: Einrichtungen der Informationstechnik – Sicherheit. Teil 1: Allgemeine Anforderungen. Ausgabe 11/2006.

 

1.4       Contents of pictures

Figure 1 - Device Tester Overview.................................................................................... 7

Figure 2 - Principal build-up of a test specification......................................................... 10

Figure 3 - Easy short and disruption tests........................................................................ 18

 

1.5       Content of tables

Table 1 - The PMS-Test Driver CAN routines...................................................................13

Table 2 – Principal structure of Device Tester messages.............................................. 15

Table 3 - PMS-Test Driver test specification routines..................................................... 16

 

1.6       Abbreviations

DTC                                       Diagnostic Trouble Code (error memory)

DUT                                       Device under test, the device, which shall be tested

ECU                                      Electronic Control Unit

Self diagnose                      Self test of the system by the ECUs

EOL                                       End of life

MO                                         message object

Node                                     Fieldbus, CAN node

OCV                                      Off current voltage

OC                                         Over current, excessive high current

OT                                          Over temperature, excessive high temperature

RC                                         Residual Capacity

SID                                        Service ID, node address

SOH                                      State of Health

SOF                                       State of Functioning

TBD                                       To be defined

UT                                          Under temperature, excessive low teperature

UV                                         Under voltage, excessive low voltage

 

2      System overview

2.1       Device Tester overview

Figure 1 - Device Tester Overview

The test is controlled by the test specification written in MS-Word. The PMS-Test Driver software is stepping through the test specification. In a dedicated column the PMS-Test Driver finds routine calls, which creates respective CAN bus messages and sends them to either the DUT (Device Under Test) or to one or more 19” Device Tester rack systems.

On the Device Tester racks the main board receives the CAN messages and delegates the write or read information via the backplane bus to the IO boards. For example after the reception of a write voltage message on one of the DAC cards, this voltage can be read from the DUT and then be read by the PMS-Test Driver by a respective read voltage CAN message.

2.2       The components of the Device Tester

The Device Tester consists of the following components:

  1. The test specification written by the user in MS-Word
  2. The PMS-Test Driver software running in the test specification and controlled by buttons in MS-Word
  3. The CAN bus communication between the PC, the Device Tester(s) and the DUT
  4. One or more Device Tester units with the private backplane busses
  5. The main board communicating with the test specification via CAN
  6. The backplane bus(ses) for the communication between the main card and the IO cards
  7. Digital and analog IO connections between the Device Tester(s) and the DUT

 

Each Device Tester rack consists of the following hardware components:

  1. A 19” rack system for single Euro cards
  2. A main board
  3. A number of IO boards doing the analog and digital IOs
  4. A power supply for all Device Tester cards
  5. A backplane bus card
  6. CAN bus interface
  7. LIN bus interface

 

3      The test specification

3.1       Introduction to test specifications

All automotive tests are black box tests. The ECU is the item for testing, so the ECU (Electronic Control Unit) is the DUT (Device Under Test). Black box tests mean testing the ECU as a whole, while all or part of the external sensors, actors and interfaces are simulated by the Device Tester.

 

The black box test is also an integration test. The complete hardware and software of the ECU is tested, so a successful software integration for a complete ECU is mandatory.

 

All tests are organised in a hierachical order. Several test modules describe the tests of a system in different  compositions. A tests group is a composition of test cases, while the test step is on the lowest order of testing, doing the direct controls to the hardware to be tested. Via CAN are UDS messages sent to the Device Tester and the DUT to actually implement the tests in the Device Tester and the DUT.

 

3.2       Principal build-up of a test specification

2 - Principal build-up of a test specification

3.2.1     Test module

The test modules differ by the different composition of the component to test. Each test module is normally described in its own test specification. Test modules could for example be:

·        Master test via CAN. All parts are simulated via CAN

·        Slave test 1 to 5 via CAN bus and Device Tester simulating the respective sensors and actors

·        Complete system test with via CAN bus and Device Tester simulating all sub busses and all sensors and actors

3.2.2     Test group

A test group is a collection of tests, which have a common initialisation and  a common post processing. Examples:

·        Voltage tests

·        Temperature tests

·        Current tests

3.2.3     Test case

A test case is an individually test of a test group. For example:

·        Voltage test in transport state

·        Voltage test in the sleep state self diagnosis

·        Voltage test in the drive state

·        Voltage test while charging the battery

3.2.4     Test step

A test step is the most direct executed  test unit. For example:

·        Voltage test- preparation – set up amplifier

·        Voltage test- preparation – set up mux

·        Voltage meassurement

·        Data processing

3.2.5     CAN message

Each test step needs one or more CAN messages. For example:

Voltage meassurement:

·        Wait for valid flag in ADC

·        Read ADC value

 

3.3       PMS-Test Driver calls in the test specification

For each test step certain preconditions must be done. For example before  testing the self diagnosis for overcharging  a Lithium Ion battery cell, the Device Tester must simulate an overvoltage on the battery cell under test. In the MS Word test specification in a dedicated table column the PMS-Test Driver macro  reads the overvoltage to be set. The macro then sends a respective UDS message with the overvoltage to the Device Tester to simulate the overvoltage error.

 

After a debounce time the PMS Test Driver will in the dedicated  test step read  the environment variable of the measured overvoltage in the DUT and store it in the respective environment column. Then an UDS message read the DTC entry for the overvoltage error. When the cell voltage meassured by the DUT is above the threshold value and the DTC is set, the test step is recognised as passed, otherwise a failed test is detected. The passed/failed information is finally written into the test specification by the PMS-Test Driver software.

3.4       The PMS Test Driver routines

3.4.1     Addressing an IO card

PMS Test Driver routines

Description

SELIO(CAN_ID, TargetCardID);

Select an IO card with the unique TargetCardID on the DeviceTester unit with CAN_ID

UNSEL_ALLIO(CAN ID);

Unselect all IO cards on the DeviceTester unit with CAN_ID

 

3.4.2     PMS Test Driver CAN or SPI routines

PMS Test Driver routines

Description

WR_BIT(CAN ID, TargetCardID, IoName, 0/1);

Set or reset bit IoName

WR_BYTE(CAN ID, TargetCardID, IoName, byte_value);

Set byte value IoName

WR_WORD(CAN ID, TargetCardID, IoName, word_value);

Set word value on IoName

WR_DWORD(CAN ID, TargetCardID, IoName, double_word_value);

Set double word value on IoName

bit_value = RD_BIT(CAN ID, TargetCardID, IoName);

Read bit IoName

byte_value = RD_BYTE(CAN ID, TargetCardID, IoName);

Read byte value IoName

word_value = RD_WORD(CAN ID, TargetCardID, IoName);

Read word value IoName

double_word_value = RD_DWORD(CAN ID, TargetCardID, IoName);

Read double word value IoName

WR_TestProc(CAN ID, TargetCardID, TestProcName);

Download test procedure into main or IO card

WR_StartProc(CAN ID, TargetCardID, TestProcName);

Start test procedure in main or IO card

WR_StopProc(CAN ID, TargetCardID, TestProcName);

Stop test procedure in main or IO card

WR_Sync(CAN ID, TargetCardID, SyncNumber);

Set sync in main or IO card

WR_WaitForSync(CAN ID, TargetCardID,  SyncNumber);

Wait for sync in main or IO card

Table 1 - The PMS-Test Driver CAN routines

 

3.4.3     Test procedures

Because all PMS Device Tester cards are intelligent with own microcontrollers the user can write test procedures for a dedicated master or IO card, consisting of the PMS Test Driver write and read routines. The procedures are written into a text file named for example TestProcName.txt. The PMS Test Driver will download the test procedure into the addressed main or io card.

 

With “WR_TestProc” a test procedure can be downloaded into a main or IO card. The “WR_StartProc” and  “WR_StopProc” routines starts and stops the indicated test procedures.

 

The “WR_WaitForSync” routine sets synchronisation points in the test routines. When a “WR_Sync” routine will send a synchronisation via CAN and the backplane to the IO cards all IO cards which are waiting for this synchronisation will commence its test from the Wait-For-Sync point on.

 

3.4.4     Common CAN and backplane message structure

Hex numbers

Description

0000 - FFFF

CAN ID for target Device Tester unit

4 bytes

Target ID of master or IO card

0000 – 07FF

Message length

0000 - FFFF

Service ID (SID)

XX

Data

0000 – FFFF

Overall checksum

Table 2 – Principal structure of Device Tester messages

 

The PMS Test Driver build messages for the CAN bus of the above shown structure. The message length and the service ID are generated by the syntax. The overall checksum is calculated by the main board and is then used for the backplane communication.

 

Each message is completely returned to the sender. When the receiver has processed the data successfully, the service ID in the returning message will allways have the uppermost bit set, by or-ing the SID by 0x8000. In case of an error, the SID will be overwritten by 0x7F.

 

3.4.1     PMS-Test Driver test specification routines

PMS-Test Driver routines

Description

SET_ENVIR_COL( column );

Set the column into which all environment variable values are written

SET_PF_COL( column );

Set the passed/failed column into which all test results are written

ENTER_ENVIR( Ucell1 );

Write environment variable value and time into dedicated environment variable column

CHECK( val1, val2, MET, TH);

Compare val1 and val2 with method MET and threshold TH and set P (passed) or F (failed) in dedicated PF column

DELAY(time);

Wait for “time” in msec

LABEL:

Entry point for jumps in the test specification

JMP( LABEL);

Absolute Jump to entry point inside the test specification

JMPCOND( COND, LABEL);

Conditional Jump to LABEL, when the condition COND is true

Table 3 - PMS-Test Driver test specification routines

 

The PMS-Test Driver test specification routines only run in the test specification. They will not cause a CAN communication.

 

3.5       A test step example

This short example shows the test module of a Lithium Ion battery BMS (Battery Management System) with its hirachy of test group, test case, test step and PMS-Test Driver calls generating the UDS diagnosis messages:

 

10 Test group cell check

This test group checks the voltages, temperatures and the current of the 12 cells of the 48 V battery module.

 

10.1 Test case cell voltage check

This test case checks the voltages of the 12 cells of the 48 V battery module. The Device Tester here simulates the cell voltages. Then also the cells are tested for short to VCC, short to ground and for disrupted connection.

 

10.1.1 Test step ceck voltage of cell 1

Here the voltage of cell1 is tested for different voltages, starting with a 2V test.

Preconditions

Description

PMS Test Driver call

Remarks

Deactivate relay disrupt

WR_BIT(CanID,TarID,SoID,RDIS5,0);

Connect AOUT5 to DUT

Deactivate relay IO/short

WR_BIT(CanID,TarID,SoID,RSH5,0);

No short test

Debounce relays

DELAY(100);

Wait for relays contacts for 100 msec

 

Test Step

Description

PMS Test Driver call

Remarks

Set cell1 voltage = 2V

WR_WORD(CanID,TarID,SoID,AOUT5,2000);

DAC2 AOUT5 = 2V

 

Post processing

Description

PMS Test Driver call

Environ val

P/F

Remarks

Debounce input driver

DELAY(100);

 

 

Wait 100ms for drivers

Read volt from DUT

UCell1=RD_WORD(CanID,TarID, SoID,DUT,UCell1);

 

 

Read DUT UCell1

Save environment var.

ENTER_ENVIR( Ucell1 )

2006, 120648

 

 

Check with threshold

CHECK( Ucell, 2000, GT, 10);

 

P

Threshold = 10

 

 

4      The Device Tester Rack

4.1       The advanced features of the Device Tester

Figure 3 - Easy short and disruption tests

 

The Device Tester system offers a number of very advanced build-in test features:

  1. The tests can run a given number of loops or till a given stop time
  2. Tests can be single stepped through the MS-Word document
  3. Featuring the hardware for easy short-to-VCC, short-to-ground and disrupted connection tests for all digital and analog IOs
  4. All IO cards are intelligent, each having an own powerfull microcontroller.
  5. All IOs can be calibrated for top exactness
  6. All IO cards can run very fast test scripts
  7. All IO cards can make real-time traces of all environment variables
  8. All real-time traces also save the event times, enabling real time trends
  9. At the end of each test an error tree is generated automatically
  10. A click on an error in the error tree will direct the cursor in the MS-Word document to the place where the error had been detected

4.2       The 19” rack system

The PMS Device Tester is a single Europa Card system with 100 x 160 sized cards. The tests system fits into 19” rack systems. The 19” rack system can for example be a desktop system or a full-sized cupboard system.

4.3       The main board

The PMS Device Tester Main board is the master card in the test system. It receives UDS CAN messages and delegates the control and measurement tasks via the backplane bus to the IO cards.

 

The main board also features serial interface as SPI, UART and LIN to simulate the functionality of external sensors and actors. The main board features the easy and interactive setup of serial interface messages on the main board. The messages can repeatedly be startet by timers or by PMS-Test Driver commands.

4.4       The IO boards

The following IO boards are available:

 

5      The Backplane Bus

5.1       Description of the backplane bus signals

Each PMS Device Tester unit has its private backplane bus with the following signals and power lines:

 

6      Power supply

The +12V power supply is converted to +5V and 3,3V by the on board LDOs.