Analysis of the SAE J1708 Protocol Raine Saastamoinen

Volvo Construction Equipment AB Component Division

Analysis of the SAE J1708 protocol Raine Saastamoinen

Bachelor thesis report May - Juli 2008

School of Innovation Design and Engineering Mälardalen University, Västerås, Sweden Supervisor and Examiner: Johan Stärner Supervisors at company: Nils-Erik Bånkestad and Jarmo Talvén

“ Engineers does’nt buy solutions they create them” LeCroy comersial

2 Abstract

Component Division at Volvo Construction Equipment, develops electronic control units (ECU) to be used in entrepreneur machines. In an operating vehicle there are several ECU’s communicating with each other to make everything work as a complete. There are two main network protocols in use to solve different communication needs. One of them is using the SAE J1708 physical layer protocol in transmitting of the actual bits when exchanging information. Manufacturing of the units are made by external suppliers.Up to date, there is a lack of good tools, to verify that delivered components conforms to the J1708 specifications. WaveRunner 104 MXi, is an advanced digital oscilloscope with scripting possibilities. It has been used in this thesis work to find out, whether suitable or not to solve this problem. This thesis shows that analysis is possible and most important of all, in future potential of being a great tool for verification.

3 Acknowledgements

Thanks to my supervisors Nils-Erik Bånkestad and Jarmo Talvén at VCE Component Division for professional guidance. Pushing me in the right direction when stumbeling into difficulties (especially after that important meeting the very first week). My supervisor at Mälardalen University, Johan Stärner, a friendly professional for support and important advices. Despite having summer vacation, taking time to read and comment my report. Annika Nerén and Peter Sävström for aid and patience shown in the laboratory environment. Magnus Åkesson, always giving a helping hand when needed and for having many good ideás. Also special thanks to Mikael Back, making this opportunity possible, to finish my studies at this interesting and challenging company. Toni Riutta for being a god friend with the heart at right place, I wish you all the best.

A special thought to my family and belowed ones. Being there, listening, supporting, encouraging and all to help me to the finishing line.

And last but not the least to all the people at location, showing that, despite all serious work dealt with, there is always room for laughter. Surrounded by a great atmosphere it has been a delightful experince to work here.

Thank you all! Raine Saastamoinen

4 Contents

1 Introduction …….….….…………………………………………………….……………..6 2 Background ...……………………………………………………………….……………..6 3 Problem formulation.……………………………………………………….…………..….7 4 Thesis outline……………………………………………………………….…………..….8 5 The SAE J1708 protocol………………………………………………….…………..……8 6 TheWaveRunner 104 MXi DSO ..……………………………………….…………..…….8 6.1 WaveScan, an advanced search and analysis tool……. .………….…………..……..11 6.2 LabNotebook ..………………………………………………………………..……..12 6.3 Custom DSO…. . ……………………………………………………………….……13 7 Requirements on analysis…….……………………………………………………….…..13 7.1 Voltage levels on the bus..………….………………………………………………...14 7.1.1 Bus state levels..……....………………………………………………………….14 7.1.2 Bits and voltage differences ……………………………………………………..15 7.2 Single bits………………………………………………………………………….…15 7.2.1 Verify bit time….…………………………………………………………….…..15 7.2.2 Low-to-high delay…. ……………………………………………………….…..15 7.2.3 High-to-low delay .. ….. ………………………………………….....……….…..15 7.2.4 Higher frequecies………………………………………...……………………….15 7.3 Characters……………….……………………………………………… ……….…..16 7.3.1 Interpretation………………. …………………………………… ………….…..16 7.3.2 Character time duration………………………………………….………….……16 7.4 Messages………………………….…………………………………………….……16 7.4.1 Idle state…………………………………………………………………….……16 7.4.2 Inter byte delays…………………………………………………………….……16 7.4.3 Message lengths ………………. ………………………………………….…….17 7.5 Further analysis……………………. .……………………………………….………17 7.5.1 Unknown-zone…………………..……………………………………….………17 7.5.2 Traffic load on bus………………… ………………..….….….………….. ……17 7.5.3 Count collisions………………………………………………………………….17 7.5.4 Monitor communication………………….……………………….. ……………17 7.5.5 Decode messages……………………………………………….. ………………17 8 Method ………………………………………..………. .. ………….. …………………18 8.1 Workplace simulation equipment……….……………. ………….. ………………..18 8.2 Laboratory simulation equipment……….………………. …….. …………………..18 8.3 Measurement to be done for voltage levels. ………... ….. .. …….. ………………..18 8.4 Measurement to be done for single bits .…….…….….……..... ……………………19 8.5 Measurement to be done for characters .……….……..……. ………………………20 8.6 Measurement to be done for messages..…………..………….. ……………………..20 8.7 Measurement to be done for further analysis ………. .….….……………………….20 9 Results…………………………………………………….. .……………………………..20 9.1 Analysis of results …..……………………….. ……………………………………..22 10 Future work/recommendations.. …………….. ………………....………………....……34 11 Summary and conclusions ……..………..…...…..………………………………………36 References…………………………….….…….……………..…...………..……………37 Appendix A… …….…….…….…………………………………………………………38 Technical data……..…………………………………………………………………38 Sample code………………………….….….………………………………………..39

5 1. Introduction

Volvo Construction Equipment (VCE) is one of the leading manufacturers of construction machines on the world market. Wheel-, and backhoe loaders, excavators and articulated haulers are some of the products (see fig.1). This big company is divided into several divisions responsible for specific areas. One of them, Component Division has the global responsibility for developing and manufacturing powertrains and electronic systems. This thesis work is made at a department, within Component Division in Eskilstuna. In here development take place in making new hardware and software solutions for the electronic control units (ECU), used by the machines. Software is developed on both platform and application level. The hardware is devoloped together with external suppliers, which by the end makes the actual manufacturing of the ECU’s.

Figure 1. Wheel-, and backhoe loaders, excavators, articulated haulers, motor graders and road machinery are products developed by VCE.

2. Background

First of all, a very brief explanation to what an ECU is doing. An ECU, electronic control unit, is a small embedded computer that has specific behaviour implemented in it to take care of certain parts of a vehicle. Engine, transmission, hydraulics, cabin, instrument and so on have their own ECU’s. A real-time operating system is in use to schedule and decide on which task (a small piece of program), may execute what and when. Different tasks read sensor values, others make decisions upon that and some make actuators to react accordingly. The beaty of this is having the possibility to tune in some small specific details or change of characteristics and behaviour of a vehicle with changes in software (of cource with limitations). The trend is with increasing count of modules per vehicle.

In an operating vehicle there are several ECU’s communicating with each other to make everything work as a complete. Communication between these autonomous nodes that the ECU’s represent, make the use of network protocols a necessity. There are two main protocols in use to solve different communication needs. First there is the CAN (Controller Area Network) according to J1939 standard in use for most of the data communication [8],[9]. With CAN being the primary bus, it allows critical interchange at high speeds among the connected modules. The second alternative in use is a protocol following the SAE (Society of Automotive Engineers) J1587 standard [12],[14]. A rather old standard, yet offering the advantages of a proven by use, reliable but rather slow communication service, used mainly for secondary or less urgent data exchange in the form of…

• loading new software to the platform • dataset loading • on-vehicle test • diagnosis / faultcodes

Figure 2: The electronic system

J1587 describes the application level in a protocol suite according to the OSI Model1. It defines format of the messages and data to be sent that is of general value. It describes a standard to use for...

“ electronic data interchange between microcomputer systems in heavy-duty vehicle applications” [12].

This application layer protocol is to be used together with the SAE J1708 standard [13][15]. In a protocol suite, this one defines the data link-, and physical layer.

3. Problem formulation

How well does the ECU’s implement the recommended practice when data interchanged? The main objective of this thesis work is to make measurements and analysis of the SAE J1708 physical layer protocol in use. Up to date there has been a lack of good supporting tools to verify such things easily.VCE having a vision, invested in an advanced digital signal oscilloscope with scripting possibilities. LeCroy’s WaveRunner 104 MXi has been used in this thesis work to find out, whether suitable or not to solve the aforementioned problem.

1 The OSI Model describes a layered, abstract description for communications and computer network protocol design

7 4. Thesis outline

To solve this thesis work, a logical work flow has been identified. 1. First of all getting deeper knowledge of the SAE J1708 protocol. 2. Studying the WaveRunner 104 MXi oscilloscope with focus on sorting out different alternatives for measurement and analysis. 3. Establish a specification of requirements on what to analyse. 4. Do the required measurement needed for analysis. 5. Make analysis of gathered material and present results.

5. The SAE J1708 protocol

One of the protocols in use is the SAE J1708. A standard that implements a bidirectional, serial communication link among modules containing microcomputers [13]. Like aforementioned with an application layer protocol on top of it, this one defines the data link-, and physical layer and is paired with EIA-485 (also formerly known as RS-485), giving the electrical specifications to it [10]. Here the primary concerns are the actual transmitting of the bits when ECU’s exchange information on the bus. Among other things the standards describe…

• voltage levels • timing constraints • defining format of characters • bus access mechanisms • error detection and handling • hardware interface with cables, allowed lengths, number of units and so on.

Later in the report, when presenting the requirements on what to analyse, deeper explanations will be given to why certain measurement are required in verification of correct behaviour.

6. The WaveRunner 104 MXi DSO

The purpose of this topic is to give data on the WaveRunner 104 MXi digital signal oscilloscope (hereafter refered as DSO). This quite extensive information, with intensions of having the reader to get a feeling of the power of this instrument. Many things are ready in the DSO to make life simpler to an engineer, but the real strength comes with the ability to develop custom solutions with scripts. Following information in here is more or less gathered from the company homesite, product commercials and accessible manuals on this site [1].

“ A single-shot acquisition is a series of digitized voltage values sampled on the input signal at a uniform rate. It is also a series of measured data values associated with a single trigger event. The acquisition is typically stopped a defined number of samples after this event occurs: a number determined by the selected trigger delay and measured by the timebase.” [2]

The DSO is delivered with windows XP operating system installed, presenting a well known, easy to use environment. It is possible to attach common peripherals such as mouse and

8 keyboard to use the instrument simply as a ordinary computer. If the built-in display of the DSO feels too small, it may be connected to another screen. There is three different solutions when navigating within the DSO menus. By a touch sensitive screen, a mouse or simply use physical buttons and knobs on front panel of the intrument.

Figure 3. LeCroy WaveRunner 104 MXi [3].

The DSO has 4 input channels in where to connect appropriate probes for measurement. These are called C1, C2, C3 and C4 when navigating within the instrument. Other channels to display traces and do work on when specific functions applied on are identified as...

Parameters (P1-P8) Memory channels (M1-M4) Math channels (F1-F4) Zooming channels (Z1-Z4) and (Q1-Q4) used for pass/fail testing

Parameters are measurement tools that determine a wide range of waveform properties. Use them to automatically calculate many attributes captured signals. Some examples could be rise-time, rms voltage, base, top and peak-to-peak voltage. Result is presented in one of the specified P1 – P8 traces available. There are completely ready to use parameter modes to perform maesurement on waveforms in the typical amplitude (vertical) and time (horisontal) domains. Custom parameter groups with possibility to make own choises from the built-in functions to apply and finally by programming in VBScript to add, what ever, new own custom functionality. Any of the parameters and their values may be presented together with statistical values such as their average, high, min and max values if desired.

Memory channels M1-M4 are there to use when saving acquired waveforms. Easy to recall when further analysis has to be done (a principle used in this thesis, more on this later).

The DSO has built-in mathematical functions to apply on acquired waveforms. This to perform math on them and displaying the result in one of the four math traces F1- F4. The easy-to-use graphical interface simplifies setup of up to two operations on each function trace. Math traces can be chained together to perform math-on-math. If this is not enough, possible

9 to implement own functionality by coding in VBScript, JScript or MATLAB. This makes the DSO so powerful.

Although the DSO offers a lot of functionality in standard mode, VCE have purchased some additional hardware and software options as well. It has been upgraded with…

• More memory added, 512 MB

• A Master Analysis Package (XMAP), that includes…

o Advanced Math Package (XMATH). Allowing math on waveforms from input channels (C1 - C4), memories (M1 - M2) or other math channels (F1 - F4)

o Customisation Package (XDEV). If Analysis, Custom DSO and plug-in choosen in instrument menu topics, it is possible to create own graphical user interfaces (GUI). An interface with buttons connected to macros that activate some described ActiveX control. If Custom DSO in Basic mode activated. This will enable easy to use access to own instrument set-ups to be launced with defined buttons.

o Jitter and Timing Analysis Package(JTA2). Enabling math and parameter selections in Math and Measure menus

• CANbus TDM. An external Trigger, Decoding and Measurement module. With this module monitor and verify that operation, reliability and performance of CAN-nodes take place as they should. This is adding a set of tools for simultaneous testing of both physical-, and data link layer.

• Built-in serial data decoders available in the DSO are: CAN, UART, LIN, SPI, I2C, FlexRay and RS-232.

In the bottom line this is an oscilloscope. A digital one making all the things expected but also capable of many things beyond that of an ordinary oscilloscope. One special feature comes with the rapid signal processing power and large memory when acquiring waveforms. Waveforms that can be further processed with software if desired when having JTA2 and/or XMATH packages installed. This possibility to make additional things to the normal hardware triggers and applying software processing on measured waves is one of the things that makes this DSO so special.

“The high 10 GS/s maximum sampling rate and extremely long 25 Mpts memory guarantee you are capturing all of the details in your signals.” [3]

The speed is there to get all the details. How about the quality and how accurate are the digitized readings? Following statements makes one realize the very high demands that could be set upon the precision of the measurements.

10 • Let the instrument adjust it self to surrounding room temperature. • Adjust measuring probes with aid of a built-in, adjustable calibration signal. • Deskew whenever need of compensating for different lengths of cables, probes, or anything else that might cause timing mismatches between signals.

There exist many alternative settings to choose from when displaying captured signals. If not happy with the standard plot, change colour, change to persistence mode and view in a 3D mode. Possible to change plotting between line or punctuation mode, splitting windows to separate different channels and if in monochromatic persistence mode, possible to simulate the look of sweeps as they were in the old analog oscillocopes. Some other features in short…

• Use of cursors to manual measurements, still useful in many cases. Descriptive labels may be turned on, showing what parts of a signal that is measured and how. • Zooming in and out wanted parts of one or more particular channels... • ...automatically done when applying filtering criterias used by WaveScan software. It can be used to scan and search either on saved waveforms or making it during live acquisitions with highlighting areas when features of interest found. • With ScanHisto, show statistical distribution of found events. Find out how values of parameters are distributed over many measurements. Once a histogram is defined and generated, measurements can be performed on the histogram itself (see fig.4). • Fast Fourier Transforms (FFT). For a large class of signals, one could gain greater insight by looking at spectral representation rather than time description. • Reporting and documenting results is important. It is made easy with the included LabNotebook software. • The additional XDEV package make it possible to set-up the instrument and making of own GUI’s to launch macros that run own ActiveX2 content. • If not enough with the more than 250 built-in functions covering lots of mesurement needs, then the DSO offers scripting possibilities to create own solutions in case needed (XMATH and/or JTA2 packages required)

Figure 4. Histicons provide a fast, dynamic view of parameters and wave shape characteristics [2].

2 ActiveX components is a term used to denote reusable software components that are based on Microsoft Component Object Model (COM). ActiveX controls provide encapsulated reusable functionality to programs and in this case it can be described with Visual Basic to set-up the instrument.

11 Some of the software to use with the DSO and mentioned above, deserves a closer look. This is because they enable exciting possibilities for analysis in searching for a solution to this thesis. Remembering that following information is more or less gathered from the company homesite product commercials and accessible manuals in here [1]. Let us start with…

6.1 WaveScan, an advanced search and analysis tool

This software is a powerful tool when working with acquisitions and deeper analysis of captured waveforms. First WaveScan enables the user to trigger on unusual events to capture and then offering scanning of special events of interest. Fast processing of data, gives possibility to scan and monitor millions of events. Make a selection from available measurement modes and filters or implement own solutions by coding in VBScript, JScript, MATLAB or Mathcad. This may be done on any input-, math channel or memory trace. Search criteria may be selected from several modes such as frequency, pulse width, amplitude, etc.

“WaveScan provides the ability to locate unusual events in a single capture (i.e., capture and search). It also “scans” for an event in many acquisitions over a long period of time. Select from more than 20 search modes (frequency, rise time, runt, duty cycle, etc.), apply a search condition and begin scanning.” [4]

When using software triggering (enabling WaveScan functionality), one must select what kind of action to take on events found…

• None • Audible Beep • Stop Acquisition • Save Waveform(s) • Pulse AUX Output • Print (Save) Screen Image • Save to LabNotebook

Identified events are highlighted and surrounded by a red box. There exist a user selectable table to be displayed with found features and their values. All found events are individually time stamped and indexed in the table from which one can select them for further view/analysis.

“Since the scanning modes are not simply copies of the hardware triggers, but "software triggers," the capability is much greater.” [2]

6.2 LabNotebook

LabNotebook is there to extend documentation capabilities of the DSO.

12 “LeCroy's LabNotebook feature extends the documentation capabilities of your oscilloscope. It allows you to create an annotated notebook entry containing all displayed waveforms, the setup of the DSO, and user-supplied annotation.” [2]

These savings can then be converted to pdf, rtf or html and printed or emailed. If the default report layout lack something, configure your own (with own company logo in the header!). All notebook entries are stored in an internal database. Besides storing the waveform having 16-bit resolution for integer or floating point data, LabNotebook also stores panel setups (the setup of the DSO) and parameter measurements in the database.

“LabNotebook is a unique inter-active measurements database and report generator that can be of inestimable value in the day-to-day use of your LeCroy oscilloscope. “ [7]

With the flashback feature all data is available for recall at any time. Recall the state of the DSO, including the saved waveforms and the DSO setup, and proceed with additional measurements. This makes it easy to continue work where last finished. In case needed, LabNotebook offers capability to back up the database to external media.

6.3 Custom DSO

“The instrument provides powerful capability to add your own parameters, functions, display algorithms, or other routines to the oscilloscope user interface without having to leave the instrument application environment. You can customize the instrument to your needs by using the power of programs such as Excel™, Mathcad™, and MATLAB™, or by scripting in VBS. Whichever method you use, the results appear on the instrument's display together with the signals that you started with. This ability offers tremendous advantages in solving unique problems for a large range of applications…” [2]

CustomDSO, in its Basic mode, allows creation of DSO setups that can be called by the touch of a single button. Basic mode may also recall own functionality implemented in VBScripts that can set up all or part of the oscilloscope and do many other things. Another more powerful feature is the PlugIn, which allows adding of ActiveX controls to a setup. These controls are powered by routines written in Visual Basic. With ActiveX controls it is possible to create own graphical user interfaces (GUI:s) to suit desired preferences. [2]

7. Requirements on analysis

The main objective of this thesis work is to make measurements and analysis of the SAE J1708 physical layer protocol in use. Having thoroughly studies on the protocol, made it possible to pinpoint important things to measure. There is a logical structure to work with that follow from the basic voltage levels on the bus, interpreting the ones and zeros transmitted, to finally end up with describing complete messages.

13 1. voltage levels 2. bits 3. characters 4. messages 5. further analysis

Further analysis part was included here as well, although not possible to solve everything. Mainly because this makes one to think further in possible development. At this state, positive if being able to decide whether this could be done or not with this instrument in the future (obviously of major interest for VCE). Some experimenting here but primary effort put on measuring and verifying the first four levels of requirements.

The requirements to measure will be numbered to be refered to later in the thesis. Also the reader should note that enclosed section numbers do reference to the specifications given in SAE J1708 Revised OCT93 and that words in bold face letters are there to highlight important ones used in the standard.

7.1 Voltage levels on the bus

7.1.1 Bus state levels

Verify differences for bus state levels greater than or equal to 0,2 V. (4.2).

The information is transmitted on a differential bus e g. a bit is interpreted as in a difference of voltage levels between the twisted pair of wires. A logical ’1’ when point A is at least 0.2 V more positive than point B. ’0’ when the opposite is the case, B > A

Figure 5: Points to be measured, A and B, are given by this picture from the SAE J1708 Revised Oct93 [13].

14 7.1.2 Bits and voltage differences

Verify that received bits follow differences in voltage levels between the wires (point Rx to be measured in fig.5).

7.2 Single bits

7.2.1 Verify bit time

Verify that the duration of one bit time, high and low logic levels, do not exceed stated limits (104,17 µs ± 0,5 %). (6.1)

This specific pulse width complies to 9600 baud, e g. maximum count of analog signal transitions per second given by the frequency formula

f = 1/(104,17*10^-6) = 9599,69 Hz.

This frequency, and how content of one character is represented, is consistent with standard universal asynchronous receiver/transmitter (UART) communication. More in 7.3.1

7.2.2 Low-to-high delay

Verify that low-to-high transition delays at the receiver do not exceed 10 µs. (A.6).

Active low-to-high transition delay, is a delay on the transmitted signal, due to added capacitance by nodes connected to the serial bus. This delay between sending and receiving of bits should remain at the same value regardless of number of nodes in the system. Upper limit in the recommended practice is a maximum count of 20 nodes.

7.2.3 High-to-low delay

Passive high-to-low transition delay. A delay that do increase with the load. It should not be more than 2,3 µs for 20 connected nodes.

Verify high-to-low transition delays within 0,6 – 2,3 µs. (A.5).

7.2.4 Higher frequencies

Verify that measurements, as done in 7.2.1 – 7.2.3, also is valid for higher frequencies used with standard UART communication in the system [16].

15 7.3 Characters.

A character is consistent with standard universal asynchronous receiver/transmitter (UART) communication. A character shall consist of 10 bits. Starting with one low logic level bit, followed by 8 bits of data and ending the character with a high logic level bit. A low logic level bit has the opposite level of a bus in idle state according to 7.4.1

7.3.1 Interpretation

Verify that a character is interpreted correctly. A logic ’0’ start bit indicating the beginnig of a new character. This followed by 8 bits of data, least significant bit (LSB) first and by having the most significant bit (MSB), logic level ’1’ ending the character. (6.2).

7.3.2 Character time duration

Verify total amount of time for one character within 10 * bit time. (6.2).

7.4 Messages.

A message consist of 3 – 21 characters in length. A message identifier (MID), followed by 1 - 19 characters of data and ending up with a checksum. The total length of a message is limited to 21 characters when vehicle running. If speed = 0 and engine RPM = 0, longer messages are allowed to be exchanged. (6.3.5).

7.4.1 Idle state

Verify prior sending of a new message, that the communication link has remained at a high logic level (e.g no other message on the bus), for a duration of at least 12 * bit time. This is true if the transmitting node is able of distinguishing a stop bit from other high-logic, idle line bits. If not, this should count to 19 * bit time. (5.2).

Accessing the bus is made in a random manner. This is based on among other things, the specified priority for that message, resulting in a value called bus access time. This bus access time tells how long the bus should have been in an idle state before a specific message is allowed accessing the communication channel. (5.2.1.1).

7.4.2 Inter byte delays

Verify that delays between characters inside a message, interbyte delay, do not exceed 2 * bit time. (6.3.1).

16 7.4.3 Message lengths

Verify length of messages in between 3 – 21 characters when measuring in a system that simulates a running vehicle.

7.5 Further analysis

7.5.1 Unknown-zone

Study duration of ’unknown-zone’ prior sending of a new message.

Prior transmitting of a new message, following requirements must be met:

• The bus must have been in an continuous idle state, for a time duration of at least a bus access time specific to this message and • then finally confirm that immediately prior attemt to send, still having the bus in idle state.

This ’unknown-zone’ is the time between meeting all requirements and the actual transmitting of the first byte. (5.2.1).

7.5.2 Traffic load on bus

Make presentation of traffic load on the bus.

7.5.3 Count collisions

Make presentation of number of collisions.

7.5.4 Monitor communication

Make the instrument to monitor and notify, or log, events of interest not following the recommended practice in the SAE J1708 standard [13].

7.5.5 Decode messages

Decode messages on the bus. If having the possibility to decode messages and presenting this i plain text, one would gain lot of useful insight when confirming functionality and behaviour of a system. With aid of decoded messages it would be straight forward to find answers to questions such as…

• If collisions are common, who is most often involved? • Does a specific message have right settings in priority? • What specific bus access time a message has?

17 • How often do some node access the bus? • Do we have correct checksum count?

8. Method

To start with the first measurements to be done with the DSO is to get familiar with it. Learning by doing. At my service there is (in the beginning), a single ECU connected thru devices to a PC. I shall call this ‘test-bench’environment, the Workplace simulation equipment. Access to the ‘real-world’ simulation measurements (hereafter Laboratory simulation equipment) on a complete system in use will be done at a later phase. Both systems will be used to gather data to analyse and compare. There are different things accessible from one and/or both systems when collecting important data to this thesis work. One example of this could be, having delays in mind, that measures are expected to give different results/data depending on the total number of connected ECU’s that do communicate.

8.1 Workplace simulation equipment

This equipment makes it possible to edit and send own messages to a single connected ECU at the other end. A computer having the J1587 Navigator program may communicate by sending messages having UART format, passing a converter and when reaching connected ECU, having data interpreted according to the physical layer J1708 protocol (the UWA in between is required for serial communication thus converting UART characters to J1708 standard sent). This is something to remember because measurements made here will differ from the ’real-world’ simulated environment measurements in the laboratory. One big advance of this is however that it was possible to solder physically contacts to otherwise unreachable Tx and Rx on the ECU. This made it possible to gather information and make further conclusions on how to make alternative measurements in a system at operating mode (without physical Tx and Rx available).

8.2 Laboratory simulation equipment

Here newly developed electronic equipment is tested thouroughly. The ’measurement-rigs’ environment is meant to simulate a complete running vehicle, in my case a wheel loader. (Wow! It was an exiting experience to see all this, at the leading edge of technology).

Measurement is done by connecting probes to the bus on the fly (point A and B, figure 5) Several connected nodes communicating will have influence on bits of information travelling. There is expected to be transition delays due to added capacitance when several nodes connected. The added capacitance comes from transmit/receive filters that is in use for electro magnetic interference (EMI) suppression. This will influence the shape of square waves to stretch out and has to do with releasing charge in capacitors.

8.3 Measurement to be done for voltage levels

Work is to be done from the basic physical requirements and up, according to the analysis topics. Starting with the voltage levels on the bus …

18 7.1.1 Measurement to be done both at the Workplace and Laboratory environments. Use of own settings, chosen from the parameter functions in the DSO. Functions are for the waveforms in the typical amplitude (vertical) domains. Acquire longer sequence to verify same behavior over long time. Sample rate not of primary concern.

7.1.2 The vision of a powerful tool for verification of ECU’s behaviour, has to operate on the only accessible points A and B on the bus. The only place to hook probes to, just to minimize work and time on preparations. The laboratory is in tight scheduled use and if in future wanting to verify on a vehicle in the field, then this criteria must be met. No mixing with the ECU’s prior to measurement. This leads us to difficulties when trying to measure things where physical access to Rx is a necessity to get exact answers (1.2, 2.2 and 2.3. switching levels at right differences and transition delays in mind). This was the case for the ‘real’ measurements to be done at the Laboratory simulation equipment. The single ECU unit in use at Workplace, however gave permissions to solder physical attachments to both Tx and Rx. From measurements made on the physically available points, conclusions and ideas can be made for alternative approximative measurements for verification of Laboratory settings.

Nevertheless, measurement made on physically available Tx and Rx at Workplace with one connected node. Send the message 085 127 001 with having a calculated checksum of 043 added by the J1587Navigator program. This script gives an easy to understand waveform to analyse. From this it is possible to measure a lot of information. Bit times for ones and zeros, interbyte delays and interpretation of a character. Same answers from complete system in use can to some extent be done with built-in functionality of the oscilloscope, namely with WaveScan with proper settings.

8.4 Measurement to be done for single bits.

At the Workplace it is straightforward to verify delays between transmitting and receiving. Set high sample rate to obtain high quality in measurement, though we are talking about actions that are expected to take place in times around and less than a millionth of a second. In Laboratory, by using WaveScan once again for 7.2.1 but better accuracy manually for 7.2.2 and 7.2.3. Trig on whatever message on the bus and save for analysis.

The Laboratory environment is in heavy use when development of new products take place. Tight scheme and not wanting to interfere with ‘real’ work going on made a change in strategy. Don’t sit in the Laboratory more than just hooking on probes on the bus and acquire waveforms at different sample rates and save them in the instrument with the LabNotebook feature. Analyse material at other location in calm.

A short explanation to why not use maximum rates all the time. Remembering that…

“The high 10 GS/s maximum sampling rate and extremely long 25 Mpts memory guarantee you are capturing all of the details in your signals.” [3]

…although having memory enough to store this 25 Mpts in 16 bit resolution, be sure of that a samplerate of 10 GS/s fills this up in just 2.5 ms. So very high quality samples of a waveform gets only that short trace of information. A single character is supposed to be

19 around 10*104,17 µs = 1.04 ms, hence able of capturing about two characters. Obviously thought in sample rates has to be accordingly to how long sequences interested in.

7.2.4 Communication is done at speeds of 9600 baud accordingly to the standard. There is although a possibility to speed things up when using the same protocol while loading new software to an ECU. Making some acquisitions once again at different rates. This is made in Laboratory and saved with LabNotebook for future analysis.

8.5 Measurement to be done for characters.

7.3.1 For Workplace environment, earlier measurement from 7.1.2 can be used. For Laboratory, where physical attachements to Tx and Rx are simply not available this has to be solved with some other method. This I will present later, revealing that once again WaveScan offers a quick answer when setting up with search criteria and filters.

7.3.2 Methods used in 7.3.1 works here as well.

8.6 Measurement to be done for messages.

7.4.1 WaveScan feature makes things simpler to an engineer once again.

7.4.2 Measurement to be done at both Workplace and Laboratory. This time with higher settings in sample rates. Expecting very short delays. Acquisitions made on several different ECU’s to reveal specifics for each and all.

7.4.3 Make assumptions based on the large amount of aqcuisitions made when analysing. More work to be done here if wanting automatic measurement. Conclusions have been made, returning to this topic later.

8.7 Measurement to be done for further analysis.

Most effort to be put into solving earlier stated requirements. Some reflections and conclusions made at this exciting topic comes later.

9. Results

Following table show a very brief summation of what has been possible to view/measure with the DSO at this state. Some values presented together with picture numbers in where to find specific data. Much more measuring and monitoring to make on existing systems before giving guarantees of behaviour. So far everything looks accordingly to the specifications. Custom made scripts should be able solve problems concerning 7.5.1 - 7.5.5. WaveScan feature of the DSO, with proper settings, offers a very useful software tool in search for some events of interest.

20 Requirement nr Result Comment Figure

7.1.1 Bus state levels X 3.6 - 4.0 V 6-9, 20, 22-26 7.1.2 Bits and voltage differences X 10, 12

7.2.1 Verify bit time X 104 μs 13, 14 7.2.2 Low-to-high delay X 5.61 μs 12 7.2.3 High-to-low delay X 91 ns 15 7.2.4 Higher frequecies X 16-19

7.3.1 Interpretation X 11, 14 7.3.2 Character time duration X 1.0399 ms 11, 14

7.4.1 Idle state X 20 7.4.2 Inter byte delays X 0–104.7 μs 21 7.4.3 Message lengths X 22-26

7.5.1 Unknown-zone --- 7.5.2 Traffic load on bus (X) (WaveScan) 20 7.5.3 Count collisions --- 7.5.4 Monitor communication (X) (WaveScan) 27 7.5.5 Decode messages --- (test of script)

Table 1: Results in brief

Having used LabNotebook features offered by the DSO throughout the work when saving interesting waveforms, makes it easy to present result. A picture contains so much information. This method of presenting results will be used and commented demand after another. Let us begin with having analysis to be done on bus state levels...

21 9.1 Analysis of results

Figure 6: Voltage levels on bus, workplace

Voila! This is how things can be presented with this LabNotebook feature of the DSO. Display with colours if desired, markers with descriptive labels on what is measured and the parameters P1 – P8 with values obtained by DSO parameter functions. In the lower left corner, boxes Z1(yellow) and Z2(blue) indicates that a zoom of a trace has been performed on the original waveform to have a closer look at details. Of cource the displayed waveforms accordingly to respective colours. The small arrow at the lower left of the grid, just above the ‘Measure’ text, indicates that the actual trigger that captured the original waveform did occure earlier in time. Time is intuitively elapsing from left to right in the picture. From within the ‘Z-boxes’ data is given on how the displayed waveforms and grid relate in time (horizontal) and voltage (vertical) scales. In this case 415 μs * 10 grids make it a total of 4150 μs that has ‘ticked’ when leaving the left side and reaching the opposite side of the screen. Hence this picture displays at least three characters captured when travelling on the bus. This is how it works. There exists a lot of other built-in features to use. Having in mind that there is a lot of possibilities in customizing looks and functionality if not enough. What a fantastic Instrument this is!

Please note that ‘Tbase’ and ‘Trigger’ boxes in lower right corner are used when setting up the instrument prior to acquiring desired action. Tbase have settings, most importantly, on sample rates and thus length of captured data in time. Trigger-box, when opened, enables trigger settings to change. Trigger condition met is the thing that starts the acquisition of data. Readings inside the Tbase-box tells that the acquisition was made with 25 M samples per second and with the time/div setting of 20 ms, the original displayed waveform contained of 5 M points of data. (Be aware of following. If working on saved waveform data that has been uploaded to the instrument, then one must not trust on the values shown in the boxes. These are then simply content of earlier captures done).

That was a lot of information from one single picture! Lets continue with the work…

Figure 7: Voltage levels on bus, laboratory equipment

This capture (fig.7) made on the Laboratory equipment with a live system consisting of several ECU’s communicating. Analysis of revealed data tell us that everything is nice. What is shown here are two channels M2 and M3, by that we know this being saved waveforms uploaded into DSO memory. In the parameter P1 – P4 readings, values are for the red trace. P5 – P8 have data on the blue trace. The red trace is point A measured on the bus, this because it toggles at higher voltage levels than the blue. The blue one is a probe attached onto point B. At least possible to make these conclusions just by hooking probes on the bus on the run. More information shall follow. Before finishing this one.Voltage levels are toggeling between top and base readings with 4.772 V and 875 mV for the measured point A on the bus and 4.097 V – 102 mV at point B (for A and B see fig.5).

Conclusion to make, the analysis on this requirement is proven. Measurements to be read in the P1 – P8 values, clearly show that bus state levels according to standards are met.

Next to follow, an additional trace from laboratory environment that spans over a very long period of time. According to M3 data it is a 200 ms * 10 = 2 second long trace. This is made on a single channel. Because majority of the values are at high voltage levels, a conclusion of that , point A is measured and displayed here. How do we know that? Remembering that the bus have to be in an idle state before bus access is allowed. Idle state exist when logical high level. Those peaks that point down are separate messages exchanged on the bus. Also note that some peaks are longer than others, reaching negativ potential at some occations. According to P6, -384 mV. More on this later…

Figure 8: Very long trace from bus A with voltage levels

Below, measurement on communication at point B on the bus at Lab. Trace (red) from same instant as the (blue) A bus above.The yellow pillars show histogram – statistical data together with parameter measurements. Note that this looks more stable, the peaks are smaller here, 4.8 volts according to P4 : pkpk(M2).

Figure 9: Very long trace from bus B with voltage levels

Figure 10: High sample rate acquisition

Workbench measurement having physical connections to Tx and Rx available. This acquisition (fig.10) is captured at very high sample rate to get the details. The memory traces show a lot of information. Besides the data needed to verify that receiving bits follow the differences between bus state levels >= 0.2 V. Persistence mode with colour on displayed traces helps to sort out when this change in state for Rx occurs. Manual measurement with cursors. Value that confirms valid behaviour in the M-boxes. Δy = 201 mV.

Figure 11: Measurement with WaveScan

Physical Rx with WaveScan features applied on. Once again a picture that many things can be read from. This time with annotations included with the LabNotebook. WaveScan gives highlighted areas on features found and table ldx on left hand side. This (fig.11) show all ‘1’ in a message. Values in table measures the marked areas in the trace, pulse after another.

25 Left most marking shown at the first row in ldx-table. It is easy to make the feature to show zeros instead, or why not both. With this kind of data is also possible to verify requirements in 7.3.1 and 7.3.2

Figure 12: Low-to-high transition delay

Low-to-high transition delay as it looks with physical TX and Rx available at Workbench environment with one single ECU connected. Applying manual measurement with cursors show Δx = 5.610 μs in lower right corner. This is well within acceptable 10 μs according to the SAE J1708 standard. Returning to the question of how to search for an answer at ‘real’ measurement on the bus when physical Tx and Rx simply is not there? It is reasonable to get a very good approximisation when observing the fact that, at the very instant Tx (yellow) drops in level, the A (blue) shall begin rising. Activate WaveScan with the criteria to measure between base level of the A bus and when reaching level that is 0.2 V more positive than the one on B. This will enable automatic measurement to be performed by the WaveScan software. If not accurate enough, stop and make manual measurement with same assumptions.

Figure 13: Bit times and WaveScan

26 Here WaveScan is in use at the Laboratory (fig.13). Automatically and quickly presenting data on bit times from the bus. Zoom in and let the software reveal even better readings if the original waveform acquired at high sample rate.

Figure 14: One character

Of cource there is the possibility to measure manually, now that the interesting features have been captured. Here one character displayed with highlighted areas. With this kind of data it is also possible to verify requirements 7.2.1, 7.3.1, 7.3.2 and 7.4.2 on ‘real’ systems. Hence verified from now on that this particular character consist of…

• One low level startbit (0) • 8 data bits to follow ( 1101 1010 ). • Ended by one stop bit (1), with possibly added time for interbyte delay.

Comparing ldx values 6 and 8 from the table, tells us that no interbyte delay noticed. If still not satisfied make another even more detailed acquisition. Manual use of cursors to measure time duration of this character gives Δx = 1.0399 ms. According to the standard, within 10 * 104,17 µs = 1.0417 ms ± 0.5 %. This is now verified.

Figure 15: High-to-low transition delay

High-to-low transition delay as it looks with physical TX and Rx available in the Workbech environment with one single ECU connected. Use of very high sample rate. Δx = 91 ns. This value is expected to grow with connected units. 0.6 - 2.3 µs or below acceptable. The interested reader should also have noticed the numerous alternatives to present waveforms on the screen.

This and following page shall reveal content from measurements done when communicating at higher baud rates. Traces are shown in following order, 9600, 38 400, 57 600 and finally at 115 200 baud (figures 16, 17, 18 and 19).

Figure 16: 9.600 baud

Figure 17: 38.400 baud

Figure 18: 57.600 baud

Figure 19: 115.200 baud

Top and base levels at 38.400 baud are getting shorter. Differences in voltage levels may no longer be interpreted as they should at rates 57k and 115k. New changes in bus state levels between A and B happens before they even have the state of the previous one. These traces were catched when flashing ECU with new software in Laboratory. It did not succeed. Uploading failed, leaving ECU in a corrupted state because some vital data was already saved in memory before crashing.

Figure 20: Idle state times on bus

WaveScan highlighting events from Lab on a trace that spans over 200 ms. Features found show time for bus in idle state. Sections with peaks are different messages accessing the bus when fulfilling bus access time based on priority of the message to be sent. Easy to confirm length of messages with use of cursors. Table show 9 events, a conclusion that 9 – 1 = 8 complete messages displayed. Once again there is some unit sending messages having peaks larger than usual. Who could this be?

Figure 21: MID, Message Identifier

30 A closer look at messages 1, 2, 4 and even the longer message nr 7 (fig.20). They all show the same bit pattern in first character. This message identifier (MID) manually decoded to (0000 0001) equals to 128, identifies a specific ECU. The zoom at this wave (fig.21) clearly shows the negative overshoot deviating from normal base level. This ECU also differs from the others in use by having an interbyte delay. Compare bit times for a usual (1) at row 6 in table, with a stopbit and delay found at row 10. Interbyte delay of this unit counts approximately, thus obtained with WaveScan, to 104,7 µs.

Next to be presented are several different identified units exchanging data in the Laboratory. An alternative way of viewing traces here. Some original waveform loaded into DSO memory and at the same time zoomed in for further analysis. Both visualized at the same time. I leave comparison of values to the interested reader (figures 22, 23, 24, 25 and 26).

Figure 22: Unit to identify

Figure 23: Unit to identify

Figure 24: Unit to identify

Figure 25: Unit to identify

Figure 26: Unit to identify

10. Future work/recommendations

• Use of EXCEL to add idle state times in ldx table gained with functionality offered by WaveScan. It might give easy calculation of bus utilization.

• Study use of Histograms in more detail to present statistical distribution of events. It might give easy calculation of bus utilization.

• Study found collisions closer. Visualised in this capture by having short pulses and strange wobbeling at top levels in the beginning (2:nd pulse width < 72 μs in fig.27 ).

Figure 27: Collision

• Develop a ‘J1708 DECODER’ with VBScript that monitors and decodes messages in real- time traffic, highlighting when search criteria met. Further development on tested scripts with promising result. Let’s have a look…

Figure 28: VBScript and simulated RX vs. real physical RX

Above, F1-box shows that VBScript is in use having yellow colour in the trace. It follows the physical ‘the real’ Rx information very nice (waveform in green colour).

Figure 29: Simulated RX and WaveScan in laboratory environment

VBScript that simulates the missing physical Rx in Laboratory environment. Presented together with WaveScan having appropriate set-up (fig.29). Simulated Rx follows this nice too (the yellow trace follow the edges of highlighted features that indicate approximative times of changes in state calculated by WaveScan). This is propably good enough for decoding purposes. No need to follow precisely though use of simulated Rx in decoding

35 would be by reading values somewhere in the middle of pulses… Still much work to be done especially not knowing how use of script slows down acquisitions. A rule of thumb states that sample rates should be minimum 4 * bit rate. Preferably 10 * bit rate to be able to alert on some transients as well [5],[6]. This would give sample rates 10 * 9600 = 96kS/s. Sample rate settings offered by the DSO range from 250 S/s…100 kS/s, 250kS/s, 500kS/s, 1MS/s, 2,5MS/s…5 GS/s (max. 10 GS/s if 2 channel mode in use). One might also expect trouble with sychronization issues if dealing with several scripts.

11. Summary and conclusions The main questions made in the problem formulation part of this thesis was 1. how do delivered ECU’s implement the recommended practice when interchanging data… 2. …and how about the WaveRunner 104 MXi, is it capable of answering this? If so, show wether it is a suitable tool or not for verification and analysis From now on this should stay clear! Measured units do behave accordingly and yes, most important of all, this is a great tool to use. By offering that much, easy to use, built-in functionality to apply on measurements, makes it a great joy to work with this instrument. Wether performing live monitoring of communication or analyzing parts of saved acquisition data. Document and share results in an easy way with the LabNotebook feature of the DSO. Create reports and annotate captures if desired. Launch prepared set-up’s to get started quickly with measurements. Load/save own settings having different functions activated when measuring or analysing data. This feature makes it possible for a person less involved to make some measuring as well. WaveScan offers easy to use functionality to quickly find many events of interest or monitor and alert when something deviates from the expected. It might not always deliver exact values but nevertheless capable of finding events that may be further analysed manually in detail. A tip! Use lower sample rates when searching (faster processing when limiting the amount of data), when or if found features of interest, make a quick analysis and perform another acquisition, this time with higher sample rate settings to get all the details. And finally, custom functionality offered by scripting. Only imagination, processing speed and memory put limit on what is possible to solve. Concerning this thesis work, additional information/achievements would be offered if able to make monitoring and decoding of ongoing communication. With decoded messages it would be straightforward to confirm stated behavior of a complete system in use, and this only by connecting probes to a running system. This would make it possible to measure on an operating machine out on the field. It seems possible to solve complicated problems by adding custom functionality with further development of scripts. The possibility to insert scripting in the processing chain of the DSO, gives immense power to this fantastic instrument.

To all the involved people at the VCE Component Division I would say, ‘Congratulations to money well invested!’

36 References

[1] http://www.lecroy.com [2] LeCroy, Xi Series Oscilloscopes Operator´s Manual, LeCroy Technical Reference Manual, pages 49-, 109-, 147-, 160-, 167-, 227-, Feb. 2008, http://www.lecroy.com/tm/library/manuals/WRXi/OperatorsManual/WRXi_OM_REVB.PDF [3] LeCroy, WaveRunner Mxi Datasheet, LeCroy Corporation, page 2, http://www.lecroy.com/tm/products/scopes/MType/WaveRunner_MXi/WRMXi.pdf [4] LeCroy, WaveScan Datasheet, LeCroy Corporation, http://www.lecroy.com/tm/products/Utilities/WaveScan/wavescan.pdf [5] LeCroy, How Fast Must I Sample?, LeCroy Application Brief, No.LAB429, http://www.lecroy.com/tm/library/LABs/PDF/LAB429.pdf [6] LeCroy, Electronics And DSO Applications, LeCroy Technical Writing, http://www.lecroy.com/tm/library/AppNotes/HighSpeedElectronics/ [7]LeCroy, LabNotebook, LeCroy Application Brief, No.LAB_WM823A, http://www.lecroy.com/tm/Library/LABs/PDF/LAB_WM823A.pdf [8] http://sv.wikipedia.org/wiki/Controller_Area_Network [9] http://en.wikipedia.org/wiki/J1939 [10] http://en.wikipedia.org/wiki/RS485 [11] http://www.wikipedia.org [12] Society of Automotive Engineers (SAE) J1587 Recommended Practice, rev February 2002 http://www.sae.org [13] Society of Automotive Engineers (SAE) J1708 Recommended Practice, rev October 1993 http://www.sae.org [14] http://en.wikipedia.org/wiki/J1587 [15] http://en.wikipedia.org/wiki/J1708 [16] http://sv.wikipedia.org/wiki/UART

37 Appendix A

Technical data

Technical data for the WaveRunner 104 MXi

Aqcuisition modes for measurements Normal, Auto, Single, and Stop

• Pre-trigger Delay: 0 to 100% of memory size (adjustable in 1% increments or 100 ns) • Post-trigger Delay: 10,000 divisions in real time mode; limited at slower time/div settings • Holdoff by Time or Events: 1 ns to 20 s or from 1 to 99,999,999 events

Basic Triggers

• Edge/Slope/Line: Triggers when the signal meets the slope and level condition. • Width: Triggers on positive or negative pulse widths. Selectable from 500 ps to 20 s or on intermittent faults (subject to bandwidth limit of oscilloscope). • Pattern: Logic combination (AND, NAND, OR, NOR) of 5 inputs, triggers acquisition. • State or Edge Qualified: Triggers on any input source only if a defined state or edge occurred on another input source. Delay between sources is selectable by time or events.

SMART Triggers

• Dropout: Triggers if signal drops out for longer than a selected time-out , 1 ns- 20 s. • Glitch: Triggers on positive or negative glitches with selectable widths from 500 ps to 20 s or on intermittent faults (subject to bandwidth limit of oscilloscope). • Signal or Pattern Interval: Triggers on intervals selectable from 1 ns to 20 s. • Runt: Positive or negative runts defined by voltage and time limits, 1 ns - 20 s. • Slew Rate: Activates a trigger when the rising or falling edge of a pulse crosses two threshold levels.

Rapid Signal Processing

• Processor: Intel® 2.0 GHz or better with MS Windows® XP Pro Platform • Processing Memory: 512 MB with VL options

Internal Waveform Memory

Waveform: M1, M2, M3, M4 (Store full-length waveforms with 16 bits/data point.) Or save to any number of files (limited only by data storage media).

• Trigger Rate: 1,250,000 waveforms per second

Maximum Acquisition Points 2 Ch/4 Ch VL Memory Option 12.5M/25M

Acquisition System All Channels 5 GS/ • 2 Channel Max.: 10 GS/s

Acquisition Processing • Time Resolution (minimum, single-shot): 200 ps (5 GS/s); 100 ps (10 GS/s)

38 Sample code

‘Sample code written in VBScript to simulate physical Rx

Function Update()

'VBS code

startData = 0 endData = InResult.Samples - 1

ReDim simulRxArray(InResult.Samples) scalarData1 = InResult1.DataArray(false) scalarData2 = InResult2.DataArray(false) ' InResult.DataArray(False) provides integer data from -32768 to 32767. ' InResult.DataArray(True) provides real data ' in the same unit as the vertical scale of the trace.

For i = 0 To endData if scalarData1(i) > (scalarData2(i) + 800 )then simulRxArray(i) = 16700 else simulRxArray(i) = 350 end if Next

OutResult.DataArray(false) = simulRxArray ' integer data

End Function