Chrysler Group LLC Document Number: LP-384D-27

Laboratory Procedure Date Published: 2010-05-04

Category Code: L-2 Change Level: C
Restricted: No

CAN 125/500 ECU TEST PROCEDURE***

1.0 GENERAL

1.1 Purpose

This document defines the test procedures for Electronic Control Units (ECU) that use the CAN
(Controller Area Network) bus communications protocol. The test procedure is to be performed on
isolated ECUs at the bench level to verify conformance with the VMM, network management functions,
basic diagnostic functions, and selected hardware features. ISO 11898, ISO 17356-5 and CS-11738 are
followed for designing this test procedure. This test procedure determines the minimum requirements for
the ECU to go on a plywood buck. This test procedure does not validate all the requirements stated in
the above documents. The supplier of the ECU is still responsible to meet all the requirements of these
documents.

1.2 Coverage of this Standard

This procedure applies to all ECUs that are designed to meet CS-11738 (CAN NETWORKING
PERFORMANCE SPECIFICATION FOR 125KBD/500KBD NETWORKS). Chrysler suppliers are
required to run this test on their ECUs and upon successful completion, submit the results to Chrysler
along with the ECU, schematics and jumper harness for possible re-run of the tests. At the discretion of
Chrysler Core Networking an audit and/or re-run of the breadboard test may be performed. For any
hardware and/or software modification the supplier shall release a new HW/SW version, re-run the test
and provide the test results along with a sample of the modified ECU.

1.3 Limitations on Usage

This document is used for performing component level test of CAN I-H/S, CAN AT and CAN C ECUs.

2.0 SPECIAL TEST EQUIPMENT & MATERIALS

Special test equipments required for this test are listed in TABLE 1. The main analysis and monitoring
tool typically used at Chrysler for this test is CANoe. CANoe configurations (commonly referred to as
CANoe models) are provided by Chrysler Core Networking that contain CAPL programs and/or panels to
automate some of the tests described in this document. Additional CAPL scripts can be developed by the
individual performing this test on an as needed basis. A variety of CAN analysis tools are available from
other vendors as well, and can be used to perform this test procedure.

TABLE 1: SPECIAL TEST EQUIPMENT

Name Of Item Description Make/Model
Bench level test area with available
ECU test workbench connections to power, ground, and N/A
CAN lines
Real ECUs and/or simulated nodes
CAN ECUs Various
used to verify network function

LP-384D-27, Change C, 2010-05-04, Page 1

Copyright Chrysler Group LLC

 TABLE 1: SPECIAL TEST EQUIPMENT
Name Of Item Description Make/Model
A PC based program for simulation 1
CANoe software Version 6.0+, Vector CANtech
and analysis of CAN bus
CANcardXL/CANcardXLe/ A hardware interface between CANoe
Vector CANtech
CANcaseXL and the CAN bus
Cable housing for the CAN transceiver
1050, 251 or 1041 opto; Vector
CANcab that connects the CANcardX to the
CANtech
CAN bus
A PC driven hardware tool to introduce
CANstressDR box Vector CANtech
various disturbances on the CAN bus
PC needed to run CANoe and Minimum of 1 GHz CPU, 2 GB
Personal Computer(s)
CANstress RAM and WINDOWS 2000
Used to measure various voltage
Voltmeters Voltmeter range: 0 - 24V
levels
Used to investigate waveforms/signal Store a minimum of 1 sec at 5
Digital Storage Oscilloscope
transitions ms/div
NOTE: Make and model may vary; the items listed in the table are representative of the equipment used
within the validation teams at Chrysler.

3.0 SUMMARY OF METHOD

This procedure outlines tests that are designed to verify the basic bus communications for a given ECU.
The general areas that are tested are listed above in section 1.1.

The test results shall be recorded on the prescribed ECU Verification Form (EVF) provided in Appendix A.
Suppliers are required to conduct all tests, including long-hour testing, unless otherwise noted on the EVF
or in the test procedure description.

The following sections describe the test procedure in detail and outline the method for recording results
on the EVF.

4.0 SAFETY PRECAUTIONS

Care shall be exercised when using any AC or DC powered test equipment. DUT damage and/or bodily
harm are possible when using this equipment on a bench. When using CANoe to perform bus
operations, the possibility also exists to unexpectedly actuate motors or other moving parts and cause
injury.

5.0 PROCEDURE

5.1 CANoe Setup

A. Install Chrysler add on package to your CANoe from Chrysler CAN mailbox.
B. Download the appropriate CANoe Model from CAN mailbox and unzip it. Read the ReadMe.txt file.
C. Load the CANoe application on your PC by following the directions provided with the software.

1
If you would like to use the Vector CANtech supplied automated tester to run this test procedure, you
need CANoe version 7.2+ (with service pack 3 when available) and a Vector item “VH1100”. The latter
allows the test modules to be fully automatic without requiring the user to turn the ignition and battery
power on and off.

LP-384D-27, Change C, 2010-05-04, Page 2

Copyright Chrysler Group LLC

D. Open up the configuration file (.cfg) from the main directory where the unzipped CANoe model
resides.
E. Refer to Appendix D for instructions on setting up CANoe to perform the measurements outlined in
this procedure

5.2 Standard Test Setup

A. Unless otherwise mentioned Vbat (Vign) shall be set at 13.0V +/- 10%
B. Throughout this document wherever it is stated to “turn the ignition to run”, the following shall be
carried out
1. If the DUT receives a hardware input from the ignition and transmits the ignition message on the bus
then turn the hardware ignition input to RUN
2. If the DUT does not receive a hardware input from the ignition, (while CANoe running) (i) turn the
simulated ignition ECU ON using the “Sim. Node ON/OFF panel” on CANoe, (ii) turn the ignition key on
the CANoe panel to RUN and (iii) ensure by monitoring the trace window that the ignition signal is
changed to run.
3. If the DUT is an ECU that receives hardware input from the ignition but does not transmit the ignition
message on the bus then do both of the above.
4. If you are running a test on a DUT that belongs to the Audio and Telematics bus in the Powernet
architecture, (while CANoe running) (i) turn the simulated TGW ECU ON using the “Sim. Node ON/OFF
panel” on CANoe and (ii) select an appropriate Power Master status on the CANoe panel that wakes up
the DUT. While submitting the test report to Chrysler, please describe in detail the power master
behavior of the DUT.
C. All DUTs for I-H/S and AT buses shall be tested on channel 1. While all DUTs for chassis bus shall be
tested on channel 2.
D. Throughout the document, whenever the test asks to add 50% extra busload do the following
1. If you are using an older CANoe panel showing a button for 50% busload, hit the button to turn the
generator ON
2. If you have a CANoe simulation with newer panels having a slider to change busload do the following:
a. From the VMM find the lowest message ID that the DUT is receiving. Do not select the diagnostic
message or any of the NM messages. Also do not select messages transmitted by the ignition ECU
with the following exception
■ If the DUT receives only the ignition message, then for all tests that require turning the ignition to
ON, select a message not present in the VMM (such as ID 018h).
■ For the tests that do not require turning the simulated ignition ON, select the ignition message ID.
b. Throughout the document we will refer to the above message ID as DUT_Recv_Lowest_ID. Enter this
ID either at the “Main Control panel” or at “Message Cycle Statistics” panel under the text “Enter Gen
Msg ID”. Hit the “Extra Busload” button. Make sure that it turns green indicating that the message
generator is on. It will not turn green, unless a massage Id is entered under “Enter Gen Msg ID”.
c. Select appropriate CAN1/CAN2 button. Selection of CAN1 causes the generator to assume a 125Kb
CAN bus while selection of CAN2 causes the generator to assume a 500 Kb CAN bus, which generates
the appropriate busload. Slowly move the slider under change extra busload until the total busload
becomes more than 50%.

5.3 Test Audit Requirements

In order to facilitate the Chrysler test audit, the supplier and/or releasing engineer must provide the
following at test time:

- Bench test breakout harness – This harness consists of the factory harness on the ECU side, and
banana plugs on the bench side that break out at a minimum CAN H, CAN L, VBat and GND for
connection to the bench. Other hard-wired inputs shall be terminated with banana plugs if manipulation

LP-384D-27, Change C, 2010-05-04, Page 3

Copyright Chrysler Group LLC

 of those inputs is necessary.

- Labeled ECU – The ECU provided to Chrysler for the ECU Level test audit shall be labeled properly
with the information listed in Appendix C. The part shall also carry some sort of identification number
from the supplier so that the test results can be traced back to a specific part if necessary.

- Supplier test results – The supplier shall perform this test procedure and furnish results to the individual
performing the test audit at Chrysler prior to coming in for the audit. The Chrysler audit will only be
performed if the supplier provides results showing passes for all tests.

- CAN circuit schematic – A schematic must be provided at test time that shows the CAN circuit for the
ECU under test. This schematic will be reviewed for each ECU to ensure proper layout. At a minimum,
the schematic shall show the CAN transceiver, microcontroller, in-line components, and connectivity.

5.3.1 DUT Data

Fill up section 5.3.1 in Appendix A, DUT Data with the relevant information from the ECU label.

5.4 Power On Message Transmission

Turn on the DUT power and verify that all supported cyclic messages from the VMM are being sent. For
the start up of a battery fed DUT transmission of a wakeup message from CANoe may be required. Any
NM message would wake up a battery-fed ECU However, to avoid message collision during some tests in
this document, an NM message not listed in the VMM shall be used. In order to transmit such a message
do the following

A. Add an interactive generator in CANoe.

B. Add an NM message with ID in the range as given in Table 2 but not assigned to any ECU as per the
VMM.
C. Set the DLC to 8
D. Assign a unique keystroke to transmit this message
E. Type in that key while CANoe is running
F. Record your observation in section 5.4 of Appendix A

TABLE 2: NM ID RANGE
Architecture TIPM/IPM PowerNet
Bus CAN I-H/S CAN C CAN AT CAN I-H/S CAN C
NM ID Range 400h – 43Fh 700h – 71Fh 400h – 43Fh 400h – 43Fh 400h – 43Fh

Pass: All “cyclic” and “cyclic on change” messages listed in the appropriate VMM are transmitted at least
once upon DUT initialization and no other unintended messages are transmitted.

Fail: One or more cyclic or cyclic on change messages are not transmitted at least once upon DUT
initialization or DUT transmitted any unintended message.

Results Recording: Note all messages that are present on the bus upon initialization. Also make note of
any cyclic and/or cyclic on change messages that are in the VMM but not on the network with the reason
that they are missing (not supported due to shared DUT, etc.)

5.5 Basic Diagnostic Function

In the Basic Diagnostic Function testing, the data on the ECU label is checked against ECU identification
and software information that is obtained through a diagnostics session. The ECU is also tested for
proper sleep functionality following a diagnostic session. The diag panel provided by the downloaded

LP-384D-27, Change C, 2010-05-04, Page 4

Copyright Chrysler Group LLC

CANoe network configuration can be used for this test.

5.5.1 ECU Information and Development Data

2
A. Open the appropriate diagnostic panel (KWP 2000 / UDS) in the CANoe simulation
B. Start CANoe application; click the CAN1/CAN2 button appropriately on the diagnostic panel. Click the
appropriate radio button for the DUT and click the "Diagnosis On/Off" button on the panel. This button
toggles between diagnostic On and Off. The green color of the diagnostic display indicates diagnosis
session is Off whereas the yellow color indicates diagnosis session is On.
C. For KWP, click the ECU information button and ECU Dev Data button on the panel. For UDS, click the
following buttons: ECU Part Number, Hardware Version, Software Version, H/W Supplier, S/W
Supplier, Active Diag Info, ECU Origin, Diag. Specs, Physical Layer Info, ECU Serial Number and
Versions.
D. Check the content of the diagnostic response and record results in the evaluation form.
E. Verify that the content of the request matches the ECU label.

Pass: The DUT responds properly to a diagnostic request for both “ECU Identification” and “ECU Dev
Data” information. The information provided in the response must match the label on the ECU.

Fail: The DUT fails to respond to the diagnostic request, or gives incorrect or invalid information in
response.

Results Recording: Record values for the following items where appropriate: Supplier, H/W Supplier,
S/W Supplier, Diagnostic version, Hardware version, Software version, ECU Origin,
ECU Part Number, Active Diag Info, UDS version, Flash version, DPRS version,
XCVR, Choke, Termination resistor, BTR 0, BTR 1, Frequency, Osc. Type, Channel
Type, ECU serial Number, Microcontroller, VMM version, CAN driver version,
Network Management driver version, UDS/Keyword Protocol 2000 driver version,
Transport Protocol driver version, DBKOM version, FLEXkom version (supported
only up to KWP 2.2 version) and OS version.

5.5.2 Sleep functionality after a diagnostics session (Applies to any ECU with Network Management
Implemented)

In this test, it is verified that the DUT sleeps properly after a diagnostic session.

A. Turn the diagnosis session Off. Verify that the DUT sleeps properly following a diagnostic session
while alone on the bus without having to perform a power reset.
B. Verify that the DUT sleeps properly following a diagnostic session with other ECUs on the bus without
having to perform a power reset. The other ECUs may be those simulated on CANoe. You need to
turn them On, but the ignition key shall be at Off.

Pass: The DUT sleeps properly following an extended diagnostic session while no wake inputs are
active.

Fail: The DUT fails to sleep properly following an extended diagnostic session with no wake inputs
active.

5.5.3 Check for DUT reset in Diagnostic mode (Applies to any ECU with Network Management
Implemented)

In this test, it is verified that the DUT does not reset during and after a diagnostic session.
2
Gateway ECUs are diagnosed from one of the buses, IPM is diagnosed from CAN Diag, CBC is
diagnosed from CAN C and Radio is diagnosed from CAN I-H/S

LP-384D-27, Change C, 2010-05-04, Page 5

Copyright Chrysler Group LLC

A. Make sure that log file is setup to capture the bus log while this test is in progress.
B. Turn the ignition key to "RUN", this will prevent the DUT from going to sleep.
C. Select the DUT from the selection buttons on the left side of the diagnostic panel.
D. On the diagnosis panel click the "Diagnosis On/Off" button to start a diagnosis session. For KWP click
the ECU information button and ECU Dev Data button. For UDS click the following buttons: ECU Part
Number, Hardware Version, Software Version, H/W Supplier, S/W Supplier, Active Diag Info, ECU
Origin, Diag. Specs, Physical Layer Info, ECU Serial Number and Versions.
E. Stop the simulation, go to the log file, and analyze the DUT NM message during this test.
F. Verify that the DUT did not reset by verifying that at any time the first byte of NM message did not
reset to “xE”, where x denotes a don‟t care nibble.

Pass: First byte of NM message of the DUT did not reset to “xE”.

Fail: DUT resets during diagnostic session by setting the first byte of its NM message resets to “xE”.

Results Recording: Check pass or fail in the appropriate section of appendix A. Make specific notes for
any abnormal behavior in the comments section.

5.6 Network Management (Applies to any ECU with Network Management Implemented)

These tests verify conformance with ISO 17365-5 (OSEK NM) and CS-11738. The network management
messages are described in Appendix E. If Network Management is not implemented on the ECU being
tested, proceed directly to section 5.7.

5.6.1 Network Management Startup

A. Allow the bus to reach a steady sleeping state with only the DUT connected (DUT is alone on the
bus).
B. Wake the bus up and observe the sequence of Network Management messages sent on the bus. The
bus can be awoken by following the procedure outlined in section 5.4
C. Verify that the DUT sends 4 ½ cycles of alternating alive and ring messages followed by one or more
3
limp-home messages as shown below and that it eventually sleeps :
Alive – Ring – Alive – Ring – Alive – Ring – Alive – Ring – Alive – Limp-home…
D. Turn the ignition key from Off to Run and back to Off again.
E. Verify that the DUT wakes up on the key transition to Run and consequently sleeps again with the
transition to Off.
F. Skip this item of the test if DUT is the ECU that reads the hardwired ignition status and transmits it
over the CAN bus. Turn the key to Run and drop off the simulated ignition ECU. Verify that the DUT
recognizes the missing ignition ECU and seeing itself alone on the bus sleeps following a timeout
period during which the ignition status over the bus is missing.

Pass: DUT follows alive-ring sequence outlined above and sends one or more limp-home messages, the
last of which has sleep indication set and allows the network to sleep. DUT also follows correct
strategy as outlined above with respect to ignition status and interaction with the ECU that
transmits the ignition status (i.e. the DUT wakes up properly on a key transition to Run, it sleeps
properly following a key transition from Run to Off, and the DUT times out and goes to sleep upon
the ignition ECU drop off).

Fail: DUT does not follow the startup message sequence outlined above, or does not interact correctly
with the ECU that transmits the ignition status (i.e. the DUT does not wake up properly on a key

3
Some ECUs such as the cluster may not sleep for minutes due to the Power Accessory Delay (PAD)

LP-384D-27, Change C, 2010-05-04, Page 6

Copyright Chrysler Group LLC

 transition to Run, the DUT does not sleep properly following a key transition from Run to Off, or the
DUT does not timeout and go to sleep upon dropping off the simulated ignition ECU without sending
the ignition off status.)

Results Recording: Check pass or fail for the following items: Bus wakeup, NM sequence, Bus sleep,
Sleep indication behavior with key transition, and NM timeout with lost ignition status.
Make specific notes for any abnormal behavior in the comments section.

5.6.2 Network Management Timings

A. Bring up the NM timings panel to measure the key Network Management timings.
B. Enter the DUT_Recv_Lowest_ID (in Hex) at the NM Timings panel under the text “Enter Gen Msg
4
ID”.
C. Select appropriate CAN1/CAN2 button
D. If the DUT is for CAN C TIPM vehicle, activate the appropriate button on the NM Timing panel.
E. Click the Go button and when the bus sleeps record the timings T CANInit, TRingTyp, TRingMax, TLimpHome and
TStartupSleepDelay.
F. Click the Go button again and as soon as the bus sleeps as indicated on the “NM_TIMINGS” panel at
5
the Network Status field, within 1.5 sec click “GO” again to test for “WaitBusSleepCancel” . The bus
shall wake up.
G. After the bus sleeps again, hit the 10 ms generator button. Make sure that it turns green indicating
that the 10 ms generator is on. If it does not turn green enter the DUT_Recv_Lowest_ID as described
in step B above and hit the 10 ms generator button again. Observe the TWaitBusSleep timing.
6 5
Pass: TCANInit , TRingTyp, TRingMax, TLimpHome, TStartupSleepDelay , and TWaitBusSleep all agree with the values
specified in CS-11738 or in “Chrysler Specific Implementation of OSEK Network Management.
”Also the bus wakes up again with the procedure outlined in step E (i.e. “WaitBusSleepCancel”
test) as required by CS-11738.

Fail: Any NM timing mentioned above does not agree with the specified values outlined in General
Requirements of CS-11738 or in “Chrysler Specific Implementation of OSEK Network Management.”

Results Recording: Record values for the following timings: TCANInit, TRingTyp, TRingMax, TLimpHome,
TStartupSleepDelay and TWaitBusSleep. Make specific notes for any abnormal behavior in the
comments section.

5.6.3 NM with another ECU

Tests in this section verify the ECU‟s NM ring building functionality as outlined in ISO 17356-5. The
TStartUpSleepDelay requirement is outlined in detail in General Requirements in CS-11738.

5.6.3.1 NM with ECU having NM message ID less than 420h

This test verifies the ring building, sleep and wakeup functionality, and the TStartupSleepDelay of the DUT with
a simulated ECU on the bus that has a NM message ID less than 420h (71Fh for CAN C on TIPM
vehicles).

4
The older NM Timings panel does not allow putting a message ID.
5
After the bus sleeps there is a 1.5 second period in which the ECU shall only wakeup by an NM
message. This test verifies that an NM message would wake up the ECU within that time.
6
If you are using a CANoe simulation with one of the older NM Timings panel, measure T CANInit on the
trace window from the very first generated error frame to the first valid message acknowledged by the
DUT under test. Also TStartupSleepDelay is equal to TSleepAlone.

LP-384D-27, Change C, 2010-05-04, Page 7

Copyright Chrysler Group LLC

A. Start CANoe measurement.
B. Turn on one of the appropriate simulated ECUs with a NM message ID < 420h (71Fh for CAN C on
TIPM vehicle). (Do not use a simulated ECU with the same NM ID as the ECU under test).
C. On the EVF, note which simulated ECU was used for this test. Write down whether the DUT and the
simulated ECU together are capable of ring building, sleep and wake up functions. Check for ring
stability (i.e. No toggling sleep indication bits, abnormal NM message sequences, no reset, no new
ring building etc.).
D. While both the DUT and the simulated ECU are in sleep mode, wake the bus by transmitting the NM
message that you configured in section 5.4.
E. Using a trace window configured to show Network Management traffic, find the time difference
between the first valid bus message from the DUT and the time it takes for the DUT to set its sleep
indication bit. This time is TStartupSleepDelay.

Pass: The bus wakes up properly, the correct sequence of Network Management messages is observed,
and TStartupSleepDelay agrees with the value outlined in General Requirements in CS-11738.

Fail: The bus does not wake up properly, the Network Management message sequence is incorrect, the
bus does not sleep properly, or T StartupSleepDelay is outside of the tolerance specified in General
Requirements in CS-11738.

Results Recording: Check pass or fail for the following categories: Bus wakeup, NM sequence, and Bus
sleep. Record the value for T StartupSleepDelay and check pass or fail for this value.
Make specific notes for any abnormal behavior in the comments section.

5.6.3.2 NM with ECU having NM message ID greater than 420h

Skip this test if the DUT belongs to TIPM-based CAN C. This test verifies the ring building, sleep, wake
up functions and TStartupSleepDelay of the DUT with a simulated ECU on the bus that has a NM message ID
greater than 420h

A. Turn on one of the appropriate simulated ECUs with a NM message ID > 420h. (Do not use a
simulated ECU with the same NM address as the DUT ).
B. On the EVF, note which simulated ECU was used for this test. Write down whether the DUT and the
simulated ECU together are capable of ring building, sleep and wake up functions. Check for ring
stability (i.e. No toggling sleep indication bits, abnormal NM message sequences, no reset, no new
ring building etc.).
C. While both the DUT and the simulated ECU are in sleep mode, wake the bus by transmitting the NM
message that you configured in section 5.4..
D. Using a trace window configured to show Network Management traffic, find the time difference
between the first valid bus message from the DUT and the time it takes for the DUT to set its sleep
7
indication bit . This time is TStartupSleepDelay.

Pass: The bus wakes up properly, the correct sequence of Network Management messages is observed,
and TStartupSleepDelay agrees with the value outlined in General Requirements in CS-11738.

Fail: The bus does not wake up properly, the Network Management message sequence is incorrect, the
bus does not sleep properly, or T StartupSleepDelay is outside of the tolerance specified in General
Requirements in CS-11738.

Results Recording: Check pass or fail for the following categories: Bus wakeup, NM sequence, and Bus
sleep. Record the value for T StartupSleepDelay and check pass or fail for this value. Make

7
Sleep indication in NM messages is designated at the third byte and has binary content of 10xxxxxx,
where x represents a don‟t care nibble

LP-384D-27, Change C, 2010-05-04, Page 8

Copyright Chrysler Group LLC

 specific notes for any abnormal behavior in the comments section.

5.6.3.3 NM with another real ECU

This test verifies the ring building, sleep and wake up functions of the DUT with another real ECU on the
bus. The additional real ECU must have been already tested for correct NM implementation and have a
different NM address than the ECU under test. This test is not required where additional CAN ECUs are
not available (e.g. for supplier test).

A. Connect another real ECU to the bus, making the bus connections first and the power connections
last.
B. On the EVF, note which other real ECU was used for this test (at a minimum, note the NM ID of the
additional real ECU). Write down whether the DUT and the additional real ECU together are capable
of ring building, sleep and wake up functions. Check for ring stability (i.e. No toggling sleep indication
bits, abnormal NM message sequences, etc.).
C. While both the DUT and the additional real ECU are in sleep mode, wake the bus by transmitting the
NM message that you configured in section 5.4..
D. Using a trace window configured to show Network Management traffic, find the time difference
between the first valid bus message from the DUT and the time it takes for the DUT to set its sleep
indication bit. This time is TStartupSleepDelay.

Pass: The bus wakes up properly, the correct sequence of Network Management messages is observed,
and TStartupSleepDelay agrees with the value outlined in General Requirements in CS-11738.

Fail: The bus does not wake up properly, the Network Management message sequence is incorrect, the
bus does not sleep properly, or T StartupSleepDelay is outside of the tolerance specified in General
Requirements in CS-11738.

Results Recording: Check pass or fail for the following categories: Bus wakeup, NM sequence, and Bus
sleep. Record the value for TStartupSleepDelay and check pass or fail for this value. Make
specific notes for any abnormal behavior in the comments section.

5.6.4 NM with all controllers

A. Put only the DUT on the bus, simulate all of the other ECUs in the network, and allow the bus to sleep.
B. The following steps will subtract ECUs and add them back in order such that communication can be
established between the DUT and all other ECUs:
1. Look on a network trace and determine which node shall logically come directly before the ECU under
test
2. Turn that node off, and wake the bus by transmitting the NM message that you configured in section
5.4..
3. Verify that the DUT is found by its new predecessor and that the bus sleeps properly.
4. Look on a network trace and determine which node shall logically follow the ECU under test
5. Turn that node off, and wake the bus by transmitting the NM message that you configured in section
5.4..
6. Verify that the DUT finds its new successor and that the bus sleeps properly.
7. Repeat the steps above alternating between predecessors and successors until the DUT is alone on
the bus to verify a stable ring regardless of the ECUs that are present on the bus.
8. Add the simulated ECUs back one-by-one alternating between logical predecessors and successors
until the bus is back to the original configuration. Remember to allow the bus to sleep following the
addition of each new simulated ECU.

Pass: All other ECUs on the bus recognize the DUT (i.e. they address it when it is a logical successor),

LP-384D-27, Change C, 2010-05-04, Page 9

Copyright Chrysler Group LLC

 and the DUT recognizes all other ECUs (i.e. it addresses each ECU as a logical predecessor).

Fail: The DUT fails to recognize one or more other ECUs, or one or more other ECUs fail to recognize
the DUT. An unstable ring would also be considered a failure mode for this test.

Results Recording: Check and/or list each simulated ECU that was used for this test. Check pass or fail
for the following items: Bus wakeup, NM sequence, Bus sleep. Make specific notes
for any abnormal behavior in the comments section.

5.7 Identifier-specific wakeup test

A. Put only the DUT on the bus.

B. Within the interactive generator block that you setup in section 5.4, add the ignition message and the
global diagnostic message from the VMM. The message IDs for these messages are given in Table 3.
C. Assign unique different keystrokes to each of these messages. Make sure that they are different from
the keystroke that you assigned in section 5.4.

TABLE 3: IGNITION STATUS AND DIAGNOSTIC MESSAGE IDS

Architecture TIPM/IPM PowerNet
Bus CAN I-H/S CAN C CAN AT CAN I-H/S CAN C
Ignition Stat 20Bh 248h 12Bh 122h 112h
Global Diag (KWP) 01Ch 7DFh 01Ch 01Ch 7DFh
Global Diag (UDS) 441h 441h 441h 441h 441h

D. Make sure that the bus is sleeping and that the interactive generator block is active, and press the key
assigned to the Ignition status message one time only.
E. Observe the following behavior on the bus and record your results for test 5.6.2 of the EVF in
Appendix A.
1. Ensure that the bus is waking up without any noticeable delay and that the network management
activity appears normal – watch for flickering on the NM panel.
2. Calculate the value for T CANINIT. This shall be measured from the very first errorframe (the errorframe
is generated due to the initialization delay of the ECU) to the first valid message acknowledged by the
ECU under test.
3. Ensure that the bus sleeps after T StartUpSleepDelay following the first message came out of the DUT after
wakeup and that the bus does not quickly wake back up following a sleep.
F. Repeat (d) and (e) with a single press of the key that is assigned to the global diagnostic message.

Pass: Observed TCANINIT values are within spec (see CS-11738). These values shall hold for network
wakeup by any means. TStartUpSleepDelay values are also within spec (see CS-11738).

Fail: DUT fails to wake up, or TCANINIT values lie outside of the acceptable range or T StartUpSleepDelay times
lie outside of the acceptable range.

Results Recording: Record values for T CANINIT for each wakeup with the message IDs mentioned above.
Record values for TStartUpSleepDelay for each wakeup with the message IDs mentioned
above. Make specific notes for any abnormal behavior in the comments section.

5.8 Message Initialization

This test verifies the timing requirements of an ECU at initialization. Specifically, the T MessageStart
parameter is tested for compliance in this section.

For ignition-fed (Clamp 15, 87) DUTs, refer to Figure 1 below for the test setup and perform the following
steps:

LP-384D-27, Change C, 2010-05-04, Page 10

Copyright Chrysler Group LLC

A. Connect channel 1 of the scope to the DUT‟s VBat line but do not apply power to this line..
B. Connect channel 2 of the scope to the CAN L line.
C. Configure the scope so that channel 1 is at 10 V per division. This will facilitate observing the
transition from 0 V to VBat upon applying power to the DUT. Also set the scope to trigger on the rising
edge in channel 1.
D. Configure the scope so that channel 2 is at 2 V per division. This will facilitate observing the CAN
waveforms on the CAN lines representing message traffic.
E. Set the scope at 50 ms per division on the horizontal axis.
F. Set the scope to catch a single trigger on 50% of the transition from 0 V to VBat on Channel 1.
G. Open up a trace window that will display all messages transmitted from the DUT, NM or otherwise.
Clear all messages from this window
H. Apply power to DUT‟s VBat line
I. Bring up a pair of cursors and measure the delta time from the rising edge of VBat to the first waveform
seen on the CAN L line (representing the first message traffic). This value represents T CANInit.
J. The first message captured on the trace window shall correspond to the first pulse observed on the
CAN L line. Record this message on the first blank in the table for this section in the EVF. The time
that this message was observed corresponds to the T CANInit time given above.
K. Subsequent message timings can be derived based on delta times from the first message. Record
timings until all cyclic and cyclic on change messages are observed for at least once. This time is
TMessageStart.

DUT
Switch
Channel 1
CAN_H
CANoe Vbatt Power supply Scope
CAN_L
Channel 2

FIGURE 1: CONFIGURATION FOR MESSAGE INITIALIZATION TEST

For battery-fed (Clamp 30) DUTs, follow the steps below:

A. Open a trace window that includes all messages transmitted from the ECU under test
B. Clear the trace window display
C. Wake up the DUT by following the procedure outlined in section 5.4
D. The time from the first errorframe to the first valid message received by the DUT corresponds to
TCANInit that is observed on the NM trace window.
E. Timing of subsequent messages can be derived based on delta times from this first message. Record
timings until all cyclic and cyclic on change messages are observed for at least once. This time is
TMessageStart.

Pass: TMessageStart agrees with General Requirements in CS-11738.

Fail: TMessageStart is not within the range of acceptable values outlined in General Requirements in CS-
11738.

Results Recording: List the messages in the order that they appear with the corresponding timings that
were gathered using the method outlined above. Record value(s) T MessageStart. Make
specific notes for any abnormal behavior in the comments section.

LP-384D-27, Change C, 2010-05-04, Page 11

Copyright Chrysler Group LLC

5.9 Message Cycle Time

In this test, message transmission tpe, cycle time and message DLC are verified to the requirements set
in the VMM. The cycle time statistics panel may be used to conduct this test. This test verifies
conformance with the VMM as outlined in CS-11738.

5.9.1 Message Cycle Time Without Added Load

8
A. Turn the ignition key to Run .
B. Refer to the VMM and identify the messages that the DUT transmits with attribute Cyclic and
Cyconchg (Cyclic on change).
C. Click the “Cycle Time Stat” button in the CANoe main panel. This will open a new panel entitled
“Message Cycle Statistics” Enter one at a time, the ID of the above messages in the appropriate field
on this panel and hit go.
D. Allow the message to cycle for approximately 1 minute and hit stop.
E. Alternate Procedure: There is a feature in CANoe that lets you compute the statistics of all messages.
To activate this feature while CANoe is not running, right-click on the statistics window and select
Configuration. Check boxes for both “Activate” and “Automatic output of statistics report”. Click Ok.
Start CANoe. After approximately 2 minute stop CANoe. You will observe the statistics of messages in
the write window only after you stop CANoe. Ignore the statistics of messages with attribute other than
cyclic and Cyconchg messages. This procedure is convenient, but less accurate as it will include the
transients as well.

Pass: Average tz, tzmin and tzmax for Cyclic and Cyclic on change messages conform to CS-11738.

Fail: Any of the average tz, tzmin or tzmax for Cyclic and Cyclic on change messages do not conform to CS-
11738.

Results Recording: List all the cyclic and cyclic on change messages that the DUT is sending along with
the required information from the VMM – Message name, message ID, launch type,
cycle time, and DLC. List the appropriate cycle time from the VMM. Check pass or
fail for each message based on the criteria listed above. Make specific notes for any
abnormal behavior in the comments section.

5.9.2 Message Cycle Time With 50% Bus Load

9
A. Add 50% extra busload .
B. Repeat section 5.9.1 above to test the message transmission under this busload.

Pass: Average tz, tzmin and tzmax for Cyclic and Cyclic on change messages conform to CS-11738.

Fail: Any of the average tz, tzmin and tzmax for Cyclic and Cyclic on change messages do not conform to
CS-11738.

Results Recording: Record the results in the EVF section for “Message Transmission” in the column “50%
added load“. Check pass or fail for each message based on the criteria listed above.
Make specific notes for any abnormal behavior in the comments.

5.9.3 Message Cycle Time with Diagnostic ON

A. Turn OFF the extra 50% bus load.

8
See Section 5.2 item B for explanation
9
See section 5.2 item D

LP-384D-27, Change C, 2010-05-04, Page 12

Copyright Chrysler Group LLC

B. Select the DUT from the selection buttons on the left side of the diagnostic panel.

C. Click the "Diagnosis On/Off" button on the panel. The status window located at the right-bottom of the
diagnostic panel shall respond "Ok". The green "Diagnose" display on the panel shall change to
yellow indicating that the diagnostics are on. For KWP click the ECU information button and ECU Dev
Data button. For UDS click the following buttons: ECU Part Number, Hardware Version, Software
Version, H/W Supplier, S/W Supplier, Active Diag Info, ECU Origin, Diag. Specs, Physical Layer Info,
ECU Serial Number and Versions.

D. Repeat 5.9.1 above to test the message time deviation during diagnostic is ON

Pass: Average tz, tzmin and tzmax for Cyclic and Cyclic on change messages conform to CS-11738.

Fail: Any of the average tz, tzmin and tzmax for Cyclic and Cyclic on change messages do not conform to
CS-11738.

Results Recording: Record the results in the EVF section for “Message Transmission” in the column
“cycle time ms with Diagnostic ON“. Check pass or fail for each message based on
the criteria listed above. Make specific notes for any abnormal behavior in the
comments.

5.10 Hardware Features

5.10.1 Glitch Detection (Applies to any ECU with Network Management Implemented)

The purpose of this test is to ensure that DUT doesn‟t wake up on electrical noise on the bus

A. Connect the DUT and CANoe on the bus.

B. Start CANoe.

C. Within CANoe, turn off all simulated ECUs using the “SM.NODE ON/OFF” panel.

D. Turn the DUT on.

E. Let the DUT go to “bus sleep”.

F. Momentarily (at least for 10 bit time) short (a) CAN-L to GND, then (b) CAN-H to GND, then (c) CAN-L
to VBat and finally (d) CAN-H to VBat.

Pass: DUT doesn‟t transmit any message in each of the items in step F.

Fail: DUT wakes up and start transmitting messages in any of the above faulted condition.

Results Recording: Check for Pass or Fail criteria.

5.10.2 Bus-Off

The CANstress hardware is introduced to the bus for this section of the test. It will be used to generate
bus errors and ensure that the bus off feature works for the DUT. Connect it as shown in figure 2.

LP-384D-27, Change C, 2010-05-04, Page 13

Copyright Chrysler Group LLC

 PC Test ECU
ECU 1 ECU 3
nm:xx nm:xx

Virtual CAN bus CANcardX

Real CAN bus
ECU 2
nm:xx
….
CANoe
PC with
simulation
CANoe Simulation Setup CANstress
on the PC Hardware CANstress
Software

FIGURE 2: NETWORK CONFIGURATION FOR BUS OFF TEST

A. If the DUT supports network management, let it go to sleep. If the DUT does not support network
management turn its power off.
B. In the CANstress setup, make sure that the correct bus speed is chosen. Set the bit timing registers
to the appropriate values for either the highspeed or lowspeed bus depending on the ECU being
tested.
C. Associate the appropriate .dbc file that corresponds to the VMM level of the DUT.
D. Pick the first message that the DUT transmits after waking up or after power up.
E. Clear out all message information except for the ID and Control Field.
F. For ECUs with standard bus-off procedure, set up the CANstressDR hardware to send 1 cycle of 32
disturbances on the bus with the disturbance defined as a 1. This will cause a group of 32 consecutive
error frames caused by bit-stuffing violations.
G. For ECUs with accelerated bus-off procedure, set up the CANstressDR hardware to send unlimited
number of disturbances:
H. Click on the lightning bolt on the CANstress application to generate the error frames and observe the
bus traffic.
10
I. For DUT supporting network management, turn the ignition key to Run to keep the bus awake. For
DUT not supporting network management, apply power.
J. Refer to the pass/fail criteria and results recording instructions.

Pass: Meets requirements outlined in General Requirements of CS-11738.

Fail: Bus off sequence and/or timing is not as specified in Operation during bus-off of CS-11738.

Results Recording: Check pass or fail based on the following items: DUT goes bus off following 32 error
frames, DUT remains bus off for the correct period of time (see Operation during bus-
off CS-11738 ), DUT returns to normal communication, and the If NM – limp-home
message transmitted properly. If the DUT implemented accelerating bus off
behavior, ensure that Phase A and Phase B have the correct timings as outlined in
Operation during bus-off of CS-11738. Make specific notes for any abnormal
behavior in the comments section.

5.10.3 Interframe Space Disturbance Test

The purpose of this test is to ensure that the ECU under test is not sending erroneous messages if the

10
See Section 5.2 item B for explanation

LP-384D-27, Change C, 2010-05-04, Page 14

Copyright Chrysler Group LLC

IFS Interframe Space is disturbed.

A. Connect the CANstress to the bus as shown in Figure 2. Only the DUT shall be on the bus.
B. In CANoe, configure to transmit the DUT_Recv_Lowest_ID every 10ms. No other messages shall be
transmitted by CANoe.
C. In CANstress, setup the Bit Field Trigger tab to trigger on the above message ID, IDE field to 0, and
all other message fields set to “x”. Set the Disturb and External drop-down combo box to “Bit Field
Trigger”. Under the Disturbance tab, select “Unlimited Number of Disturbances” for the Disturbance
Mode drop-down combo box, and type “110” as the Disturbance Sequence. Make sure that the Bit
Times radio-button is selected.
D. Set up for a bus log, start CANoe,
E. Turn the ignition to run
F Start the CANstress application. Stop it after one minute.
G. Analyze the messages in the bus log for invalid message cycletime, message IDs, and message DLC.

Pass: The DUT transmits only its own messages with proper message IDs, proper DLC and proper cycle
time.

Fail: Either the DUT transmits the wrong message ID(s) or DLC, or that the message(s) are not
transmitted with proper cycle time.

Results Recording: Check for Pass or Fail criteria, if fail detail the erroneous behaviors.

Results Recording: Check for Pass or Fail criteria, if fail detail the erroneous messages IDs and DLCs.

5.10.4 BUS voltage with the DUT alone on the Bus

A. Turn off all simulated nodes so that only the DUT is connected to the bus.
B. Set VBat to 13 V.
C. Connect a scope and adjust the settings to observe the waveform of CAN-L and CAN-H of the DUT
D. Reconnect the CANcab and if the DUT supports network management, wake up the bus by any
means (by transmitting an NM message)
E. While the bus is awake, quickly disconnect the CANcab from the bus and observe the recessive and
dominant voltages on the CAN-L and CAN-H line at the DUT end using the scope.

Skip steps F, G and H if the DUT does not support network management

F. Reconnect the CANcardXL as quickly as possible, trying to reconnect it before the bus sleeps.
G. When the DUT sets its sleep indication (shall take approximately TStartupSleepDelay seconds), quickly
disconnect the CANcab once again.
H. Verify that the DUT sleeps (Both CAN-H and CAN-L voltages become near zero) within 15 seconds of
Network Sleep, and record the voltages on both CAN-H and CAN-L. This is the sleep voltage. Make
note in the comments section if the DUT sleep timing is outside of what is given above (Gateway may
take up to 20 seconds).
I. Repeat steps (d) through (h) with VBat at 9V.
J. Repeat steps (d) through (h) with VBat at 16V.

Pass: Results agree with the values and timings outlined in General Requirements of CS-11738

Fail: One or more values or timings do not agree with the values outlined in General Requirements of
CS-11738

LP-384D-27, Change C, 2010-05-04, Page 15

Copyright Chrysler Group LLC

Results Recording: Record the following items: VBat as outlined in step (b) above, CAN-L voltage at
sleep as outlined in step (c) above, CAN-L voltage with bus awake as outlined in step
(e) above, CAN-L voltage with the bus asleep as outlined in step (h) above and the
various values from performing steps (I) and (J) above. Make specific notes for any
abnormal behavior in the comments section.

5.10.5 BUS termination resistance

This test determines the DUT termination resistance

A. Using an ohm meter find out the termination resistance between CAN-H and CAN-L of the DUT after
disconnecting its power supply and rest of the CAN bus settings.
B. Record your observation on the data sheet.

Pass: DUT has appropriate termination resistance consistent with the vehicle line and model year.

Fail: Otherwise

5.11 Long-hour tests

The tests in this section are designed to check the long-hour durability of the ECUs. ECUs are operated
for long hours and subjected to different kinds of bus stress. The DUT shall operate normally throughout
the duration of the long-hours tests.

These tests shall be conducted only after the ECU passes all earlier tests.

5.11.1 Weekend sleep test (Applies to any ECU with Network Management Implemented)

A. Place the DUT on the bus and simulate all other ECUs (real ECUs can be used as well, but must have
already passed all of the tests in this document).
B. Allow the bus to sleep and leave it untouched over a weekend or for approximately 48 hours.
C. Upon returning, wake the bus up using any desired method (Using the method described in Section
5.4)
D. Check the basic function of the ECU including ring building, message transmission, Network
Management timings (by turning all simulated ECU off and hitting the “go” button on the NM timings
panel), etc. without disconnecting power to the ECU.

Pass: Bus wakes up properly, the proper Network Management message sequence is observed, and the
bus sleeps properly. The range of Network Management timings all agree with the values
specified in CS-11738.

Fail: Any of the items mentioned above do not occur as specified.

Results Recording: Check pass or fail for the following items: Bus wakeup, NM sequence, and Bus
sleep. Record values for the following timings: T CANInit, TRingTyp, TRingMax, TLimpHome,
TStartupSleepDelay and TWaitBusSleep. Make specific notes for any abnormal behavior in the
comments section.

5.11.2 Overnight sleep/wakeup test under load (Applies to any ECU with Network Management
Implemented)

A. Place the DUT on the bus and simulate all other nodes except the transmitter of
DUT_Recv_Lowest_ID.
B. Add 50% extra busload. DO NOT turn the ignition to run

LP-384D-27, Change C, 2010-05-04, Page 16

Copyright Chrysler Group LLC

C. Start the simulation, and observe the sleep and wakeup cycle on the bus. The presence of the
DUT_Recv_Lowest_ID message will cause the bus to sleep and then wake back up after TWaitBusSleep
seconds. This will repeat as long as the DUT_Recv_Lowest_ID message is being generated on the
bus.
D. Allow the sleep and wakeup cycles to continue for at least 8 hours.
E. Upon returning, check to make sure that the DUT is still communicating properly.
F. Stop the simulation, disconnect the generator block in the Simulation Setup, and restart the simulation.
G. Verify basic network communications such as sleep, wakeup, Network Management timings, etc.
H. If the ECU is not communicating properly, it may be necessary to do a power cycle and perform this
test again with logging blocks activated so that the problem can be diagnosed.

Pass: ECU is still operating and communicating properly (i.e. no abnormal wakeup delays, no abnormal
NM message sequences, etc) following the 8 hour time period.

Fail: ECU is behaving improperly as mentioned above following the 8 hour time period.

Results Recording: Check pass or fail for the following item: ECU continues to behave properly following
test. List NM timings in table. Make specific notes for any abnormal behavior in the
comments section.

5.11.3 Overnight Bus stress test

In this test the bus is loaded to around 50% during an overnight stress test. This test is similar to the test
described in 5.10.2, but the key will be in the run position. The ECU‟s Network Management shall
continue to function properly and all communication shall continue to proceed as normal.

A. Place only the DUT on the bus and connect the CANcardXL.
B. Add 50% extra busload.
C. Turn the ignition to run in order to prevent the DUT from sleeping.
D. Leave the setup operating for at least eight hours.
E. At the end of this eight-hour period, check a trace window to ensure that the DUT is still operating
normally.
F. Turn the ignition to Off. Due to the 50% bus load DUT will sleep & wake up periodically.
G. Stop CANoe application.. Restart CANoe. 50% busload generator shall stay off
H. Check for normal operation of the DUT transmitting all cyclic messages.
I. If the DUT supports network management, it may require a wakeup message as outlined in Section
5.4. In this case ensure that the DUT wakes up and sleeps properly
J. Disconnect the ECU‟s power feed, wait for a few seconds, and then reconnect power. Repeat steps h
and i above

Pass: ECU is still operating and communicating properly (i.e. no abnormal wakeup delays, no abnormal
NM message sequences, etc) following the 8 hour time period.

Fail: ECU is behaving improperly as mentioned above following the 8 hour time period.

Results Recording: Check pass or fail for the following item: ECU continues to behave properly following
test. Make specific notes for any abnormal behavior in the comments section.

5.11.4 Message spacing test

The purpose of this test is to check that the DUT is not transmitting its cyclic messages back-to-back and
it is satisfying the requirement that different cyclic messages shall have a minimum spacing of

LP-384D-27, Change C, 2010-05-04, Page 17

Copyright Chrysler Group LLC

TBACKTOBACK. You need an oscilloscope for this test

A. Connect a scope to see the waveforms on CAN-L and CAN-H

11
B. If the DUT supports network management turn the ignition key to Run . Otherwise apply power.
C. DUT will start transmitting the cyclic messages. Observe the spacing of these messages on the scope
for at least one minute
D. If you have a CANoe version 7.0 or higher, you may not need a scope and perform this test using
CANoe. Right click on the trace window column title bar and select Field Chooser…Drag one at a time
the “Bus idle” and “Frame Duration” fields to the trace window column title bar. Next, click
Configuration on the CANoe toolbar window, select Options, expand Configurations and Settings and
select CAN Settings. Check the box entitled “Calculate Start-of-frame timestamp for CAN frames”.
With this setting CANoe will display the calculated frame duration and bus idle time before the start of
the current frame. Observe the spacing of the messages.

Pass: All the message spacing are equal or higher than that specified in CS-11738

Fail: Any of the message spacing is lower than that specified in CS-11738

Results Recording: Check pass or fail for the following item:

6.0 DEFINITIONS/ABBREVIATIONS/ACRONYMS

APPLICATION Application software for the ECU

CAN Controller Area Network: A protocol for message communication in motor
vehicles
(1)
CANcab Cable housing the CAN transceiver that connects the CANcardX and the CAN
bus
(1)
CANcardX A hardware interface on the PC, between CANoe and the CAN transceiver
(1)
CANoe A software program for simulation and analysis of CAN bus
(1)
CANstress A PC driven hardware tool to add disturbance to the CAN bus.
DBKOM: Data Base Communication: Software module that assembles (disassembles)
message from (into) signals.
DTC Diagnostic Trouble Code
DUT Device Under Test
DUT_Recv_Lowest_ID The lowest message ID (other than the diagnostic message, NM message and
messages transmitted by the ignition ECU) that the DUT is receiving. If DUT is
receiving only the ignition message then for all tests that does not require the
ignition key to run position this is the ignition message otherwise this is a
message not present in the VMM.
CCM Chrysler Communication Matrix: The database containing the message data for
the entire vehicle (same as VMM)
ECU Electronic Control Unit: Any microprocessor driven interface between a load
module for the vehicle and the CAN bus that is capable of sending and/or
receiving messages.
FLEXKom Flexible Communication: An enhanced DBKom having Flash capability
KWP2000 Key Word Protocol 2000: A protocol for vehicle diagnostic messages.
Logical successor A logical successor of one ECU is another ECU having the next higher NM
address. If there are no other ECUs that have a higher NM address, then the
logical successor becomes the ECU having the lowest NM address. ECUs with
NM addresses are listed on the NM display panel.
Highspeed Used in this document to refer to the 500 kBd network
Lowspeed Used in this document to refer to the 125 KBd network
11
See Section 5.2 item B for explanation

LP-384D-27, Change C, 2010-05-04, Page 18

Copyright Chrysler Group LLC

Ignition ECU ECU that reads the ignition switch position and transmits the ignition signal on
the bus.
NM Network Management: Software module to perform ECU sleep and wake up
functions
Simulated ECU Chrysler provided CANoe simulation of an ECU
TP Transfer Protocol: Software module to perform data transfer, primarily used by
the diagnostics.
TRingTyp This is the time from ECU alive to ring messages.
TRingMax This is the time from ring back to alive-message when the ECU is alone on the
bus.
TLimpHome Time between last alive message to limp-home message or between two limp-
home messages.
TStartupSleepDelay This is the time from the ECU wakeup to Network sleep.
tmin This timing outlines the minimum spacing between message transmission.
Values are given in CS-11738 for both the lowspeed and highspeed bus.
tz This is the cycle time for a given message transmitted by the DUT.
n This parameter is associated with messages of BAF send type and refers to the
number of times that the message is sent with its default value when the active
function becomes inactive and message transmission stops.
tz2 This parameter is associated with messages of Fast send type and refers to the
second cycle time that applies to the message when a given stimulus is applied.
m This parameter is associated with messages of On Change send type and refers
to the number of times the message is sent when a given stimulus is applied. It
is globally defined in the .dbc file.
TCANInit With the ECU in sleep state this is the time between first bus activity and ECU
acknowledging the receipt of a valid CAN message
TStartupSleepDelay Time between first message on bus following wakeup and when the sleep
rd
indication bit is set in an NM ring message (3 byte becomes BF)
VMM Vehicle Message Matrix: The database containing the message data for the
entire vehicle (Legacy name for CCM)

NOTE 1: These tools are available from Vector CANtech; Tel: (248) 449-9290

7.0 GENERAL INFORMATION

Three asterisks “***” after the section/paragraph header denotes single or multiple technical changes to
the section/paragraph. Specific technical changes within a section, subsection, table, or figure may be
highlighted in yellow.

Certain important information relative to this Laboratory Procedure has been included in separate
standards. To assure the materials submitted meet all of Chrysler requirements, it is mandatory that the
requirements in the following standards be met.

CS-9800 - Application of this procedure, the subscription service, and approved sources
CS-9003 - Regulated substances and recyclability

For specific information on this document, please refer to the contact person shown in the "Publication
Information" Section of this document. For general information on obtaining Engineering Standards and
Laboratory Procedures, see CS-9800 or contact the Engineering Standards Department at
engstds@chrysler.com.

LP-384D-27, Change C, 2010-05-04, Page 19

Copyright Chrysler Group LLC

8.0 REFERENCES

Chrysler ASTM ISO SAE Federal

Standards Standards Standards Standards Standards
CS-9800 ISO 11898 (FIRST EDITION)
CS-9003 ISO 17356-5 (OSEK NM)
CS-11738 ISO 15765 (KWP 2000)
Quality and Reliability Documents

Other Documents

9.0 PUBLICATION INFORMATION

Contact/Phone Number: Shahgir Ahmed / 248-576-5800

Alternate Contact/Phone Number: Tim Potochick/ 248-576-2063
department Name & Department Number.: E/E Systems Architecture/. 6860
Date Procedure Originally Published: 2004-10-01
Date Published: 2010-05-04
Change Notice:
Description of Change:
- Section 1.1: ISO specs are referred. It is further stated that this test procedure does not validate all the
requirements.
- Section 1.2: It is stated that suppliers need to re-run this test procedure at every release of HW and
SW versions and provide reports to Chrysler
- Section 1.3: Usage of this document is modified
- Section 2.0: TABLE 1 Special Test HW/SW versions are updated
- Section 2.0: TABLE 1 Note regarding version 6.1+ of the CANoe software
- Section 5.1: Installation of Chrysler add-on package is stated
- Section 5.2: Terms used in this document are clarified
- Section 5.3: Inserted Fill up section 5.3 in Appendix A, DUT Data with the relevant information
- Section 5.4 Wake-up message for the DUT is explained
- Section 5.4: TABLE 2 NM ID range is given
- Section 5.5 Use of diagnostic panel and the diagnostic related tests are clarified
- Section 5.6 Network management related tests are clarified
- Section 5.7 Separate section is made for identifier specific test and the test is clarified
- Section 5.7: TABLE 3 Ignition status and global diagnostic message IDs are provided
- Section 5.8 Initialization test is clarified
- Sections 5.9, 5.9.1, 5.9.2 Test titles are modified from Message Transmission to Message Cycle Time
- Section 5.9 Message cycle time tests are modified, Only cyclic and cyclic + on change messages are
needed to be verified in the breadboard level
- Section 5.10.1: Glich detection test is clarified
- Section 5.10.2: Bus-off test is clarified
- Section 5.10.3: Interframe Space Disturbance test is modified
- Section 5.10.4: Bus voltage with DUT alone on the bus is modified
- Section 5.10.5: BUS termination test is added
- Section 5.11.1 – 5.11.3: Long hour tests are clarified
- Section 5.11.4: Message spacing test is modified
- Section 7.0: Added definition for DUT_Recv_Lowest_ID, CCM, Simulated ECU and TStartupSleepDelay,
- Appendix A: All the relevant data entry tables are modified appropriately
- Appendix B: External Termination added
- Appendix D: Steps are modified to reflect new CANoe version
#####

LP-384D-27, Change C, 2010-05-04, Page 20

Copyright Chrysler Group LLC

 APPENDIX A: ECU VERIFICATION FORM

ECU Level Network Test Results Packet

□ Pass □ Fail

5.3.1 DUT Data

ECU Name: Carline(s): Build Phase: Date:

ECU Part Number:

Supplier:
Hardware Version:

Software Version: Diagnostic Version:

Microprocessor: VMM:

CAN Driver: Network Management:

Keyword Protocol: Transport Protocol:

DBKom Version: FLEXKom Version:

Sample Point: Bus Speed:

Crystal and Tolerance: PLL used for CAN clock?? Yes / No

5.4 - Power On Message Transmission

Test to verify that cyclic messages listed in the VMM are present
Pass / Fail / Skip
when DUT initializes

Comments:

LP-384D-27, Change C, 2010-05-04, Page 21

APPENDIX A
Copyright Chrysler Group LLC
5.5 Basic Diagnostic Function
Pass / Fail / Skip Test for basic diagnostic functionality

5.5.1 ECU Information and Development Data

ECU Info
Supplier:
Diag: HW:
ECU Origin: SW:
Part Number:

Dev. Data

CPU: VMM: CAN: NM:

KWP: TP: DBK: Flex:
OS:

5.5.2 Sleep functionality after a diagnostics session

Sleeps alone following

diagnostic session: □ Yes □ No
Sleeps with others following
diagnostic session: □ Yes □ No
5.5.3 Check for DUT reset in Diagnostic mode

DUT did not reset during the diagnostic session yes:  no: 
Comments:

5.6 Network Management

5.6.1 - Network Management Startup
Test to ensure that Network Management message sequence at
Pass / Fail / Skip
startup is acceptable – also tests for ignition on/off behavior

Comments:

LP-384D-27, Change C, 2010-05-04, Page 22

APPENDIX A
Copyright Chrysler Group LLC
5.6.2 - Network Management Timings
Pass / Fail / Skip Test for proper Network Management timings

Value as
Parameter
Measured
TCANInit ms
TRingTyp ms
TRingMax ms
TLimpHome ms
TStartupSleepDelay sec
TWaitBusSleep ms
Comments:

5.6.3.1 - 5.6.3.2 - 5.6.3.3 - NM with another ECU

Pass / Fail / Skip Test for ring building with other ECUs, simulated and real
† ‡
NM < 420h / 71Fh NM > 420h Real ECU
ECU Name:
Wakeup
Correct? □ Yes □ No □ Yes □ No □ Yes □ No
Sleep Correct? □ Yes □ No □ Yes □ No □ Yes □ No
TStartupSleepDelay sec sec sec
†
For CAN C in TIPM vehicles
‡
Does not apply to CAN C TIPM vehicles

Comments:

5.6.4 - NM with all controllers

Pass / Fail / Skip Test for ring building with a simulated network

Comments:

LP-384D-27, Change C, 2010-05-04, Page 23

APPENDIX A
Copyright Chrysler Group LLC
5.7 - Identifier-specific Wakeup Test

Pass / Fail / Skip Test for proper bus wakeup with a range of different identifiers

Message TCANINIT TStartupSleepDelay

Ignition Status

Global Diag

Comments

LP-384D-27, Change C, 2010-05-04, Page 24

APPENDIX A
Copyright Chrysler Group LLC
5.8 - Message Initialization
Pass / Fail / Skip Test for the TMessageStart parameter

Message ID Message Name Time Observed

ms
ms
ms
ms
ms
Lowspeed: ms
ms
ms
ms
ms
ms
ms

Message ID Message Name Time Observed

ms
ms
ms
ms
Highspeed: ms
ms
ms
ms
ms
ms
ms

Lowspeed: TMessageStart: ms
Highspeed: TMessageStart: ms

Comments:

LP-384D-27, Change C, 2010-05-04, Page 25

APPENDIX A
Copyright Chrysler Group LLC
5.9 Message Cycle Time
Pass / Fail / Skip
Cyclic / Cyclic on change messages From VMM

Cycle Time - tz Cycle Time - tz Cycle Time - tz

Launch Type

Cycle Time
Name

DLC
ID (50% Added cycle time ms with
(No Added Load)
Load) Diagnostic ON

Pass: □ Min: Min: Min:

Fail: □ Max: Max: Max:

Skip: □ Avg: Avg: Avg:

Pass: □ Min: Min: Min:

Fail: □ Max: Max: Max:

Skip: □ Avg: Avg: Avg:

Pass: □ Min: Min: Min:

Fail: □ Max: Max: Max:

Skip: □ Avg: Avg: Avg:

Pass: □ Min: Min: Min:

Fail: □ Max: Max: Max:

Skip: □ Avg: Avg: Avg:

Pass: □ Min: Min: Min:

Fail: □ Max: Max: Max:

Skip: □ Avg: Avg: Avg:

Comments:

LP-384D-27, Change C, 2010-05-04, Page 26

APPENDIX A
Copyright Chrysler Group LLC
5.10.1 - Glitch detection
DUT doesn‟t wake up when CAN-L is shorted to GND, VBat
Pass / Fail / Skip and CAN-H shorted to GND, VBat.

Comments:

5.10.2 - Bus Off

Pass / Fail / Skip Test for bus off recovery

DUT goes bus off after

causing 32 consecutive Yes / No
error frames?
DUT stays bus off for 1
Yes / No
second ±10%?
Standard Busoff: DUT returns to
communication with a
Yes / No
NM limp-home message
as first message?
DUT returns to normal
communication following Yes / No
bus off recovery?

During Phase A and

Phase B, the DUT goes
bus off after causing 32 Yes / No
consecutive error
frames?
During Phase A, the
DUT stays bus off for
Accelerated Busoff: 200 ms ± 10% (for CAN Yes / No
I-H/S) / 50 ms ± 10% (for
CAN C)?
Phase A lasts for 1
Yes / No
second ± 10%?
During Phase B, the
DUT stays bus off for 1
second ± 10% and
Yes / No
repeats this until the
error frames are no
longer being sent?

Comments:

LP-384D-27, Change C, 2010-05-04, Page 27

APPENDIX A
Copyright Chrysler Group LLC
5.10.3 - Interframe Space Disturbance
Pass / Fail / Skip Test for erroneous messages if Interframe Space is disturbed.
Comments:

5.10.4 - BUS Voltage with DUT Alone on the Bus

Pass / Fail / Skip Test for proper BUS voltage levels with an isolated DUT

Sleep
VBat LINE Recessive Dominant
CAN-L V V V
13V
CAN-H V V V
CANcardXL CAN-L V V V
connected and 9V
CAN-H V V V
then disconnected CAN-L V V V
16V
CAN-H V V V

Comments:

5.10.5 - BUS termination resistance RTerm =

Pass / Fail / Skip

Comments:

LP-384D-27, Change C, 2010-05-04, Page 28

APPENDIX A
Copyright Chrysler Group LLC
5.11.1 - Weekend Sleep Test
Pass / Fail / Skip Test for stability following an extended period of bus sleep

Pass / Fail Bus wakes up properly following weekend test??

Pass / Fail NM sequence correct following weekend test??
Pass / Fail Bus sleeps properly following wakeup after weekend test??

Value as
Parameter
Measured
TCANInit ms
TRingTyp ms
TRingMax ms
TLimpHome ms
TStartupSleepDelay sec
TWaitBusSleep ms

Comments:

5.11.2 - Overnight Sleep/Wakeup Test Under Load

Pass / Fail / Skip Test for proper communication following sleep/wakeup test

Bus continues to communicate normally following test

Pass / Fail
without any kind of ECU reset??

Value as
Parameter
Measured
TCANInit ms
TRingTyp ms
TRingMax ms
TLimpHome ms
TStartupSleepDelay sec
TWaitBusSleep ms

Comments:

LP-384D-27, Change C, 2010-05-04, Page 29

APPENDIX A
Copyright Chrysler Group LLC
5.11.3 - Overnight Bus Stress Test
Test for proper communication following an overnight key-in-run
Pass / Fail / Skip
test

Bus communication is normal following overnight key-in-run

Pass / Fail
test prior to hard ECU reset (w/added bus load)?
Bus communication is normal following overnight key-in-run
Pass / Fail
test after a hard ECU reset (w/added bus load)?

Comments:

5.11.4 – Message Spacing Test

Pass / Fail / Skip Test for proper peak bus loading and message transmit spacing

All the message spacing are equal or higher than that

Pass / Fail
specified in CS-11738

Comments:

LP-384D-27, Change C, 2010-05-04, Page 30

APPENDIX A
Copyright Chrysler Group LLC
 APPENDIX B: EXTERNAL TERMINATION

During the test setup, a non-dominant ECU having no (or non-dominant) internal termination requires two
external dominant terminations as shown in Figure B-1. A dominant ECU having 120 Ω internal
termination requires only a second dominant external termination as shown in Figure B-2 (i.e. total bus
termination for the test setup shall be 60 Ω).
.

DUT

CAN-H

60Ω 60Ω

60Ω 60Ω

CAN-L

FIGURE B-1: TEST SETUP FOR A NON-DOMINANT ECU

CAN-H

60Ω
DUT

60Ω

CAN-L

FIGURE B-2: TEST SETUP FOR A DOMINANT ECU

LP-384D-27, Change C, 2010-05-04, Page 31

APPENDIX B
Copyright Chrysler Group LLC
 APPENDIX C: ECU LABEL

An ECU brought to Chrysler for a test audit shall have a label containing the following information:

TABLE C-1: PERTINENT ECU INFORMATION

Items Description Format Example
Part No. Standard part no. n nn nnn nn XY 0 19 595 56 AB
ECU: Name of the ECU as identified in the VMM XYZ CCN
Nr. ECU Number: suppliers own number (if any) nn 47
VMM: Vehicle Message Matrix Date yyww 0343
Micro Microprocessor used XYXnnn STAR12
nn.nn
HW: ECU HW version 01.04
(major.minor)
nn.nn.nn
SW: ECU Software version 02.01.06
(major.mid.minor)
(1) nn nn nn
DIAG: Diagnostics information 81 12 FF
(high low resv)
Trans: CAN transceiver used Make - Model Philips TJA 1041
Make - Model- Siemens 51μH
Choke Type of Common Mode Choke used
Current rating 0.5A
Termination resistance value and tolerance
RTerm: n.nn KΩ n% 4.70 KΩ 1%
(No more than 1% tolerance is acceptable)
(2)
CAN: CAN driver version n.nn 2.10
(2)
NM: Network Management version n.nn 2.03
(2)
KWP2000 KWP2000 version n.nn 2.01
(2)
TP Transport (TP) Layer version n.nn 2.02
(2)
DBKOM DBKOM version n.nn 2.02
Supplier Supplier name XYZ TEMIC
Baud Rate 125 KBd or 500 KBd (highspeed or XXX KBd 125 KBd
Sample Indicates chosenlowspeed)
sample point for the ECU
XX % 81%
Point being tested
Indicates whether ECU uses PLL to
PLL Yes or No No
generate CAN clock
Crystal Indicates which crystal the ECU uses XX MHz ± X ppm 16 MHz ± 30 ppm
NOTE 1: Supplier may add other items for their own use
NOTE 2: For DUTs on the highspeed bus, some items do not apply and therefore can be left blank

LP-384D-27, Change C, 2010-05-04, Page 32

APPENDIX C
Copyright Chrysler Group LLC
ECU-LABEL TEMPLATE (You may fill in the following template, print, cut and paste to your ECU)

ECU: P/N:
HW: SW:
DIAG: NM:
CAN: VMM:
Micro: DBKOM:
Trans.: KWP:
Flxcom: TP:
Choke: Supplier:
RTerm : Sample Point:
Crystal and
Baud Rate:
Tolerance:
PLL used for
:
CAN clock?

LP-384D-27, Change C, 2010-05-04, Page 33

APPENDIX C
Copyright Chrysler Group LLC
 APPENDIX D: WORKING WITH CANOE

Some variations on the methodologies below may exist depending on the version of CANoe being used

When new configurations are opened or new CAPL programs are incorporated into the configuration it
may be necessary to do a global compile before the measurement starts in order to make sure that all
nodes compile properly.

D-1.0 The bus must be set to real mode in order to perform measurements on a real ECU. Simulated
ECUs may also be added to the bus along with the real ECU in this mode. Set the bus to real mode as
follows;

STEPS:
1. In menu „Configure | Options | Simulation‟, make sure the “Real bus” radio button is selected.

D-1.1 The bit timing registers must be set to the correct values in order to connect to the bus using a
CANcardXL and CANoe.

STEPS:
1. In menu 'Configure | Network Hardware | CAN1/CAN2 | Setup', set the sample point as follows:
- For CAN I-H/S ECU testing, set Bus Timing Register0 to 43, and Bus Timing Register1 to 2B
resulting in a baud rate of 125 kBd and a sample point of 81%.
- For CAN C ECU testing, set Bus Timing Register0 to 40, and Bus Timing Register1 to 2B resulting
in a baud rate of 500 kBd and a sample point of 81%.

D-1.2 The acceptance filter must be configured to accept all CAN messages. This can be figured as
follows:

- In menu 'Configure | Network Hardware | CAN1/CAN2 | Filter' ensure that the ID field is filled in with all
X‟s for standard and extended messaging for each CAN channel, thereby opening the acceptance filter
for all possible CAN messages.

D-1.3 Trace windows can be figured in the CANoe measurement setup that allow a user to observe bus
traffic on the bus that the CANcardXL is connected to.

STEPS:
1. In the “View” menu, select the Measurement Setup
2. Right click on any existing trace window block, select “Insert trace window,” and select either “CAN
settings” or “Standard settings.” Selecting CAN settings will add columns to the new trace window that
are useful when looking at CAN message traffic such as message ID, data content, DLC, etc.
3. Once the trace window is inserted, it will be given a generic name by CANoe such as “Trace 1,” “Trace
2,” etc. This name can be changed by right clicking on the trace window block in the measurement
setup and selecting “Name.”
4. To bring up the trace window so that message traffic can be observed, double-click on the trace
window block in the measurement setup.
5. If other columns are necessary, right click on the trace window itself and pick “Configuration.” Click on
the columns tab and add the desired columns to the trace window.
6. Other features of the trace window can be altered in the configuration such as number format (hex,
decimal, etc.) and window buffer size (given in number of messages).

D-1.4 Filters can be added to the measurement setup so that only the desired bus traffic for a given
measurement is passed through to the measurement block. These filters can be used for any of the
measurement blocks including trace windows, data windows, graphic windows, logging blocks, statistics
blocks, etc.

LP-384D-27, Change C, 2010-05-04, Page 34

APPENDIX D
Copyright Chrysler Group LLC
STEPS:
1. Right click on a connection in the branch that you wish to filter (represented by a small solid black
square).
2. A number of filter types can be inserted including filters based on message IDs, environment variable
filters, and filters for a given channel on the CANcardXL.

D-1.5 Generator blocks can be added to the simulation setup that allow CANoe to send message traffic
on the bus that the CANcardX is connected to. With a generator block, these messages can either be
sent at a cyclic rate or just a single time, and the message content cannot be altered explicitly.

STEPS:
1. Click on “View | Simulation setup.”
2. Right click on the bus wires (represented by red and black trunk lines) and select “Insert generator
block.”
3. Double click the generator block and choose the method for launching the generated traffic.
4. In the right-hand column in the simulation setup, double-click on the line under the “generators”
heading that corresponds to the generator that you want to configure.
5. Add all desired traffic to the sendlist and click “Okay.”
6. Activate the generator block by clicking once on it in the simulation setup and pressing the spacebar or
right-clicking and selecting “Block active.” The block can be deactivated in the same manner, but only
if the simulation is stopped by clicking on the button labeled with a stop sign.
7. Upon starting the simulation by clicking on the button labeled with a lightning bolt, the generator block
will be active and will launch the generated messages by following the method chosen in step (c).

D-1.6 Interactive generator blocks can also be added to the simulation setup to allow CANoe to send
message traffic on the bus that the CANcardXL is connected to. Unlike a generator block, the interactive
generator block can be used to send out messages with specific message content. Individual signals
within the message can be changed to perform specific tasks.

STEPS:
1. Click on “View | Simulation setup.”
2. Right click on the bus wires (represented by red and black trunk lines) and select “Insert interactive
generator block.”
3. Double-click the interactive generator block and choose the desired messages to add to the sendlist.
4. Signals within a given message can be altered in the bottom half of the interactive generator block
setup window. Signals can also be altered by changing the values in the data field section for a given
message. Other send parameters can be chosen such as cycle times, DLCs, and the channel that the
message is to be sent on.

LP-384D-27, Change C, 2010-05-04, Page 35

APPENDIX D
Copyright Chrysler Group LLC
 APPENDIX E: NETWORK MANAGEMENT MESSAGES

The following are characteristics of network management messages:

ID  Between 400-43F (hex).
BYTE 1  xEh: Alive message, xCh: Limp-home message, XDh: Ring message
BYTE 2  ECU‟s own NM address for alive and limp home messages; NM address of its logical
successor for ring message; NM address of its desired logical successor for skipped alive
messages.
BYTE 3  00xxxxxxb: Not ready to sleep, 10xxxxxxb: Sleep Indication, 11xxxxxxb: Sleep
acknowledgement

LP-384D-27, Change C, 2010-05-04, Page 36

APPENDIX E
Copyright Chrysler Group LLC