The MxDPRS Transform is used to generate Chrysler and FIAT Diagnostic Test Scenarios and TestCases for a selected module based on 7_Z0059, 7_Z0059_01 and 7_Z0145 specifications. The Scenarios can be executed with MxSuite to perform automated testing.

The main purpose of this tool is to generate test cases dynamically based on the selected DUT (Device Under Test) from a DBC file, with the help of a generic input test case template file. This template file is created based on standard test specification requirements (7_Z0059, 7_Z0059_01 and 7_Z0145). In the generic input template file, the generic test case is provided for DTC (Diagnostic Trouble Codes), RDI (Record Data Identifier), IOC (IO Control), RC (Routine Control)and MW (Memory Write) and Supported Services. The DPRS Transform generates the expanded test case dynamically for all the supported diagnostic data from the user selected ODX file.

The template MxVDev project for FIAT or KL model is supplied with the package. Select the appropriate template project and generate the test cases for the specific desired DUT and the MxVDev project is ready to be executed for the device under test. The MxTransit harness required by this tool is already built into the template MxVDev project.

After regression test execution of all the generated test cases from MxVDev, the regression reports are generated in the specific folder in native MxSuite format. You can use this tool to convert the MxSuite native test report format to the Excel test reports as per the Chrysler test report format.

Prerequisites

A Lookup table file - a mapping of TestCases to Scenarios and TestCase groups:

oThe Lookup table file should be named “LookupTable.xlsx” and placed in the MxVDev project folder

An input Excel file (Test Report File) - the TestCases definition for each specific section

The DBC file of the corresponding vehicle

ODX (Open Diagnostic Data Exchange) file for the specific module

A configured MxVDev template project

To select a Regression Report, a Regression Script File (.mxreg) is required. This file is produced by MxVDev.

TestCase Generation

1.Ensure the template project corresponding to the Fiat/Chrysler specification is installed on your PC.

2.Open the template project. (File->Open->Project from the main menu.)

3.Click the “Edit Harness” (EditHarness-btn) button to start MxTransIt.

4.In MxTransIt, click on the MxDPRS Transform to select it and display its Properties:

DPRS1

Properties of MxDPRS Transform

5.Expand the Generator Configuration tree in the Properties box.

6.Select the DBC file corresponding to the selected module type.

7.Select the ODX file corresponding to the selected module which was generated using cdd (candela file) in properties view of MxDPRS Transform.

Note : To Generate the ODX file from a CDD file:
 
a. Open the corresponding cdd file (for example: RADIO-CMCM.cdd) using CANdelaStudio.
 
b. Select File-> Export -> Open Diagnostic DataExchange (ODX) to generate the ODX file.

DPRS2

MxDPRS TestCase Generation Tool

8.Click the “Launch TestCase Generation Tool” Verb in the Properties box.

9.Select the DUT to be tested from the drop-down box.

10.Select the Wake Up DUT which will contain the signals to wake up the Device Under Test (DUT). Based on the selected DUT and selected Wakeup DUT, ECU signals are loaded in combo box for user selection in Configuration tab.

  DPRS3

Signal Selection in Configuration

11.Select the spreadsheet file that contains the TestCases to be generated.

12.Select the appropriate MxVDev project folder (directory).

13.Go to Configuration Tab.

DPRS4

Timeout and Wakeup Signal Configuration

14.Configured timeout values are saved automatically without clicking “Save Configuration”.

15.Default messages are loaded from wakeup configuration file if saved for the selected DUT and wakeup DUT. You can edit them as applicable based on the ECU under test.

P2CANTimeout (sec) – Tolerance value for normal response messages

P2*CANTimeout (sec) – Tolerance value if NRC 78 message is received.

16.Select the appropriate wake-up signals and their values which are used to wake-up the DUT and to continue ECU communication.

17.Click “Save Configuration” to save the configuration.

Note: The WakeupConfiguration file path is same as the selected MxV Project folder path in the TestCase Generation tab.

Sample Wakeup Configuration file

Sample Wakeup Configuration file

18.Click the Generate TestCase button to create Scenario and TestCase files.

19.After observing the “Successfully Generated Scenarios and TestCases” message on the DPRS TestCase Generation Tool, click the Close button to close the tool and save the Transform.

Test Report Generation

DPRS6

MxDPRS Test Report Generation Tool

20.In the MxDPRS Transform's Properties box, select the ODX file corresponding to the selected module which was generated using a CDD (candela) file.

Note : To Generate the ODX file from a CDD file:
 
a. Open the corresponding cdd file (for example: RADIO-CMCM.cdd) using CANdelaStudio
 
b. Select File-> Export -> Open Diagnostic Data Exchange (ODX) to generate the ODX file.

21.Click the Launch MxDPRS Test Report Generation Tool Verb to open the tool.

22.Select the spreadsheet file that contains the TestCases to be generated.

23.In “Select Regression Report,” browse for Regression Script (.mxreg) file.

24.Click Generate Test Report.

Note: To create a Regression Script file, use MxVDev to run a Regression Test for the generated Scenarios.

An Excel file named "InputExcelFileName_<SelectedDUTname>" with all the signals changed from generic (e.g. TRANSPORT_REQUEST) to specific ECU (e.g. DIAG_REQ_ETM) was generated previously when the Generate TestCase button was clicked.

Before clicking the Generate Test Report button, make sure to select the input file (e.g. InputExcelFileName_<SelectedDUTname>) so that the report is generated with the signal names specific to that ECU.

Sample Input Test Case Template

Sample Input Test Case Template

 

Sample Test Report

Sample Test Report

 

TestCase Message Formats

This section describes the message formats used in the Input file.

Note: Every message should end with newline("\r\n") for our parsing technique.

1) Request Message

Example:

Physical Request Message:

TRANSPORT_REQUEST  Tx d 8 02 10 01 00 00 00 00 00

Functional Request Message:

TRANSPORT_FUNC_REQUEST  Tx d 8 02 10 01 00 00 00 00 00

2) Response Message

Example:

TRANSPORT_RESPONSE Rx d 8 02 10 01 00 00 00 00 00

3) Wait

Format:

Wait:<Time in seconds>

Example:

Wait:5.00

4) To Repeat block of messages for certain time

Format:

REPEAT:<TotalPeriodTime>

<Block of messages>

REPEAT END

5) Ignore Length feature

Example:

TRANSPORT_REQUEST  Tx d 2 10 01

TRANSPORT_RESPONSE  Rx d 3 50 01 **

** indicates bytes to be ignored.

6) For NRC $78 response create transform with appropriate response and add the signal to MxSuite

TRANSPORT_REQUEST           Tx         d 2       11 01

Service $51 Rsp            Rx        d 1       01

7) Mask Byte Feature

An XX in a response message indicates that a byte is required, but its contents are ignored.

Here is an example of a message pair that uses a mask:

TRANSPORT_REQUEST     Tx  d 2 10 03

TRANSPORT_RESPONSE     Rx  d 6 50 03 XX XX XX XX

8) Response Signal with no data

Example:

TRANSPORT_RESPONSE

9) Adding Wake/Sleep signals to TestCase

SignalName   Sig   SignalValue  

“Sig” is the term used by our parsing tool for this type of message

Example:

CBC_I4.CmdIgnSts  Sig   4

10) Generic DTC TestCase

TRANSPORT_REQUEST      Tx  d 6 19 06 dd dd dd FF

TRANSPORT_RESPONSE    Rx  d 3 59 06 **

Here “dd dd dd“ represents DTC and Symptom

11) Generic DID TestCase

TRANSPORT_REQUEST      Tx  d 3 22 dd dd

Service $62 Rsp    Rx  d 3 dd dd **

Here “dd dd” represents DID number

12) Generic IO Control TestCase

TRANSPORT_REQUEST     Tx  d 5 2F dd dd dd

Service $6F Rsp     Rx  d 3 dd dd

Here “dd dd” represents IO control Identifier.

dd dd dd” represents IO Control Identifier and parameter

13) Generic Routine Control TestCase

TRANSPORT_REQUEST     Tx  d 4 31 dd dd dd

Service $71 Rsp    Rx  d 3 dd dd dd

Here “dd dd dd” represents Routine Identifier and Routine parameter

14) Generic Write Operations TestCase

TRANSPORT_REQUEST     Tx  d 4 2E dd dd dd

Service $6E Rsp    Rx  d 2 dd dd

Here “dd dd dd” represents RDI Identifier and the data to be written into particular RDI

“dd dd” represents RDI Identifier

TRANSPORT_REQUEST     Tx  d 3 22 dd dd

Service $62 Rsp    Rx  d 3 dd dd dd

Here “dd dd dd” represents RDI Identifier and the data

“dd dd” represents RDI Identifier

15) Non DBC message format

RAW_CAN   d   CanId     data

RAW_CAN   d   18DA87F1  2   10 03

Here RAW_CAN is a signal name used for transmitting non DBC message

'd' is used for our parsing technique

Lookup Table File Format

For an example of a Lookup Table, see “LookupTable.xlsx”

This Lookup Table is designed to work with the data in “Fiat Diagnostic TestCases r2_4_KL.xlsx

The Lookup table contains 12 columns:

Sheet ID: Sheet Name.

Requirement section: The section number only from the sheet name .

Tag: Whether the line is a ‘Testcase’ , ’ Teststep’ , ‘Scenario’ , ‘Scenario End’, ’Testcase End’, or ‘Cannot be automated’ (For the tests which we cannot generate tests using tool).

Note: All tags are case sensitive

Test Step Num Column: Optional.

Test Step Name Column: Optional.

TestCase Name: The Scenario and TestCase name.

Note: TestCase Names should follow some standard keywords for generating test cases dynamically using ODX documents.

For example:

TestCase Name for sample DTC TestCase should be “DTC” for identification of the TestCase Generation Tool.    

TestCase Name for sample RDI TestCase should be “RDI” for identification of the TestCase Generation Tool.      

TestCase Name for sample IOC TestCase should be “IOC” for identification of the TestCase Generation Tool.      

TestCase Name for sample RI TestCase should be “RI” for identification of the TestCase Generation Tool.      

TestCase Name for sample MW TestCase should be “MW” for identification of the TestCase Generation Tool.      

Addressing: Whether addressing is physical or functional.

If it is physical, enter “Phy” in the lookup table.

If it is functional, enter “Func” in the lookup table.

Testdata Row: The row number in the spreadsheet (such as, “Fiat Diagnostic TestCases r2_4_KL.xlsx”) from which TestCase data is taken.

Testdata Column: The column number in the spreadsheet (such as, “Fiat Diagnostic TestCases r2_4_KL.xlsx”) from which TestCase data is taken.

Parsing Type: For z0059-01, z0059 and z0145, the parsing type is ‘Tx/Rx’.

Result: The column number in the spreadsheet (such as, “Fiat Diagnostic TestCases r2_4_KL.xlsx”) in which the TestCase result is updated.

Comments (Update Test Data): The column number in the spreadsheet (such as, “Fiat Diagnostic TestCases r2_4_KL.xlsx”) in which the TestCase Comments(Log Data) is updated.

Sections

Each Section of the Lookup table represents one Scenario. If the section has subsections, they can be converted to one scenario or multiple scenarios based on the tag names.

Example:

If Section 8.2 (z0059-01) is one Section and Section 8.2.1 (z0059-01), Section 8.2.2 (z0059-01) are sub sections, then “Section 8.2 (z0059-01) “ is one scenario.

The Lookup Table is filled as follows:

Sheet Id: Section 8.2.1 (z0059-01)

Requirement section: 8.2

Tag: Scenario

Test case Name: Protocol Timing

The TestCase is filled as follows:

Tag: Testcase

Testcase Name: TestCase name

Addressing: Physical or Functional

Testdata Row: 6 (Corresponding TestCase row number that contains Test Result, Comments (log data for each TestCase))

Result: 7 (Corresponding column that contains Test Result)

Comments (Update Test Data): 6 (corresponding column number that contains Comments (log data for each TestCase))

Note: It is not necessary to fill the other columns for TestCase.

Rows

In each row based on the data in the columns, each cell is considered as one test step. If there are multiple data columns, then each data column is a test step.

Example:

In Section 8.2.1(z0059-01) of “Fiat Diagnostic TestCases r2_4_KL.xlsx”, the 6th row is one TestCase and it contains test data in the 4th column, so, it is one test step.

The lookup table is filled as follows:

Tag: Teststep

Testdata Row: 6

Testdata Column: 4

Parsing Type: Tx/Rx

Note: There is no need to fill other columns for test step.

End Tags

After all the test steps of one TestCase, “Testcase End” indicates the end of the TestCase.

After all the TestCases of one Scenario “Scenario End” indicates end of the Scenario.

Note: Each Row or Combination of  rows based on requirement “Fiat Diagnostic TestCases r2_4_KL.xlsx” can be converted to one TestCase.

List of Automated Tests Supported

z0059-01

8.2.1, 8.2.2, 8.3.1, 8.3.2

8.3.3 (TestCases for all supported DTCs can be “created dynamically”(i.e., sample TestCase format of DTC will be listed in input excel file and list of DTCs will be taken from ODX document and test cases for each DTC will be generated and can be seen in “Scenarios and Test cases” folder of the corresponding MxSuite project using our tool.)

8.3.4 (TestCases for all supported DIDs only for physical addressing can  be “created dynamically”(i.e., sample test case format of DID will be listed in input excel file and list of DIDs will be taken from ODX document and test cases for each DID will be generated and can be seen in “Scenarios and TestCases” folder of the corresponding Mx Suite project using our tool.)

8.3.4 (Test cases for all supported DIDs only for functional addressing can be created dynamically)

8.3.5 (Test cases for all IO controls can be created dynamically)

8.4 (Test is automated but actual data from the test tool is not copied to comments column as it increases the size of reports file (.xlsx)

 

z0059

8.1 (TestCases for all supported DIDs for physical addressing can be created dynamically)

8.1 (TestCases for all supported DIDs for Functional addressing can be created dynamically)

8.2 (Test is automated but Key On/OFF and Comparing values cannot be automated, Key On/OFF values need to be entered in test case input file and this should match with the ECU Wakeup Signals which user enters in “Configuration” tab of the Test case generation tool)

8.3

8.5.1, 8.5.2, 8.6.8 (Test cases for all supported DTCs can be created dynamically)

 

z0145

7.9.1.1, 7.9.1.2, 7.9.1.3, 7.9.1.4, 7.9.1.5, 7.9.1.6, 7.9.1.7, 7.9.1.8, 7.9.1.9, 7.9.1.10, 7.9.1.11, 7.9.1.12, 7.9.1.13, 7.9.1.14, 7.9.1.15, 7.9.1.16, 7.9.1.17, 7.9.2.1, 7.9.2.2, 7.9.2.3, 7.9.2.4, 7.9.2.5, 7.9.2.6, 7.9.3.1, 7.9.3.2, 7.9.3.3, 7.9.3.4, 7.9.4.1