CAN signal quality analysis and development of the signal processing on a FPGA

LiU-ITN-TEK-A-14/012--SE CAN signal quality analysis and development of the signal processing on a FPGA Jakob Uhlin 2014-05-28 Department of Science and Technology Linköping University SE-601 74 Norrköping, Sweden Institutionen för teknik och naturvetenskap Linköpings universitet 601 74 Norrköping

LiU-ITN-TEK-A-14/012--SE CAN signal quality analysis and development of the signal processing on a FPGA Examensarbete utfört i Elektroteknik vid Tekniska högskolan vid Linköpings universitet Jakob Uhlin Handledare Qin-Zhong Ye Examinator Allan Huynh Norrköping 2014-05-28

Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/ Jakob Uhlin

Abstract LINKÖPING UNIVERSITY Faculty of Institute of Technology ITN-Department of Science and Technology Supervisor: Qin-zhong Ye, Mattias Hovebro Author: Jakob Uhlin This master thesis report is a part of the thesis project conducted by Jakob Uhlin at Syntronic R&D, Stockholm Sweden. The objective of this thesis is to develop a way to process the signal being sent on a CAN-bus and subsequently analyse its quality and its source in the network. A process of gathering appropriate theories and data has been done, parallel with the development of the analyzer module. The intelligence is implemented in an FPGA through the hardware description language VHDL. In this way, the algorithms can process the data in a real-time domain. The central findings and conclusions have been that is possible to analyze the signal quality of a CAN message properly on a FPGA. Key words: FPGA, CAN-bus analyzer, CAN, signal theory

Contents Abstract i List of Figures List of Tables v vi 1 Introduction 3 1.1 Introduction... 3 1.2 Background... 3 1.3 Purpose... 4 1.4 Method... 5 1.4.1 Literature review... 5 1.4.2 Market study... 5 1.4.3 Tools... 6 1.4.4 Quality... 6 1.4.5 Reliability... 6 1.4.6 Validity... 7 1.4.7 Coherence & Consistency... 7 1.5 Limitations... 8 1.6 Requirement specification... 9 1.6.1 Pre-study knowledge... 9 1.6.1.1 Critical... 9 1.6.1.2 Important... 9 1.6.1.3 Extra... 10 1.6.2 ican requirements... 10 1.6.2.1 Critical... 10 1.6.2.2 Important... 10 1.6.2.3 Extra feature... 11 1.6.3 Project requirements... 11 1.6.3.1 Critical... 11 1.7 Risk analysis... 11 2 Theory 13 ii

Contents iii 2.1 CAN standards... 13 2.2 Layers... 14 2.2.1 Physical layer... 14 2.2.2 Object layer... 14 2.2.3 Transfer layer... 14 2.3 Message management... 15 2.4 Error management... 15 2.4.1 Bit stuffing... 16 2.5 Bit timing... 17 2.6 Analysis techniques... 18 2.6.1 Measuring quality... 18 2.6.2 Edge steepness... 19 2.6.3 Disturbance-free voltage... 20 2.6.4 Reflection... 20 2.6.5 CAN controller output vs analogue... 20 3 Market analysis 21 3.1 CAN-bus tester 2... 21 3.2 CAN BUS Analyzer Tool... 23 3.3 CANwatch... 24 3.4 Summary market analysis... 25 4 Hardware and tools 26 4.1 Interface board... 26 4.1.1 Power supply... 27 4.1.2 Signal conditioning... 27 4.1.3 Digital CAN interface... 28 4.2 Flashy-D... 28 4.3 Xylo-LM FPGA... 29 4.3.1 Cypress FX2... 29 4.3.2 Xilinx Spartan 3E FPGA... 29 4.4 LCD screen KNJN... 30 5 Implementation 32 5.1 Overview of functionality... 32 5.1.1 System 1 - Analogue analyzer... 32 5.1.2 System 2 - Analogue and digital analyzer... 33 5.1.3 System 3 - User interface... 33 5.2 Setup test-bench... 33 5.2.1 Added hardware... 33 5.2.2 FPGA logic... 34 5.2.3 PC software... 35 5.3 System 1 - Analogue analyzer... 37

Contents iv 5.3.1 Emulating CAN-signal... 37 5.3.2 FPGA logic... 39 5.3.3 PC software... 41 5.4 System 2 - Analogue and digital analyzer... 42 5.4.1 FPGA logic... 42 5.4.2 PC software... 43 5.5 System 3 - User interface... 44 6 Results and verification 45 6.1 General discussion results... 45 6.2 Test-bench result... 45 6.3 System 1 - Analogue analyzer... 47 6.4 System 2 - Analogue and digital analyzer... 48 6.4.1 Bus rate: 1 Mbit/s... 49 6.4.2 Bus rate: 800 kbit/s calibration... 49 6.4.3 Bus rate: 500 kbit/s... 50 6.4.4 rate: 250 kbit/s calibration... 52 6.4.5 Bus rate: 125 kbit/s... 53 6.5 Market analysis comparison... 54 7 Conclusion and discussion 55 7.1 General discussion and analysis of the results... 55 7.1.1 LCD screen... 56 7.2 Project discussion... 56 7.3 Future development... 57 7.4 Ethical and social aspects... 57

List of Figures 2.1 Bit timing.... 17 2.2 Overview of analyze methods for a single emulated CAN-bit signal.. 19 4.1 Picture of hardware board... 26 4.2 Overview of existing interface hardware... 27 4.3 Entire equipment... 31 5.1 Test-bench overview of embedded functionality in the FPGA... 34 5.2 Emulator software form... 38 5.3 System 1 overview of embedded functionality in the FPGA... 39 5.4 Analyze values... 40 6.1 First request command.... 45 6.2 Requesting a mirrored send package from the FPGA by sending a 8-bit value.... 46 6.3 ADC data written to a text file and shown in excel.... 46 6.4 Computer analysis of the signal in Figure 6.3.... 46 6.5 Result of an analysis for system 1.... 47 6.6 Verifiedanalysismaximumvalue, minimumvalueandlocalmaximum and minimum as the marks seen in Figure 5.4.... 48 6.7 Rise-time ADC values.... 48 6.8 Digital and analog analysis.... 49 6.9 Before calibration for the sampling rate.... 49 6.10 After calibration for the sampling rate.... 50 6.11 Oscilloscope measurement comparison.... 50 6.12 Digital and analog analysis.... 51 6.13 Verified analysis maximum value, minimum value and local maximum and minimum as the marks seen in Figure 5.4.... 52 6.14 Before calibration for the sampling rate.... 52 6.15 After calibration for the sampling rate.... 53 6.16 Digital and analog analysi.s... 53 6.17 Verified analysis maximum value, minimum value and local maximum and minimum as the marks seen in Figure 5.4.... 54 v

List of Tables 3.1 Market analysis comparison... 25 4.1 Characterstics of Spartan 3E.... 30 5.1 Bit rates... 38 6.1 Market analysis comparison with results.... 54 vi

Definitions 1 Definitions BIT Basic unit that can have two values, 0 and 1, for information in digital communication. CANopen: CANopen is a communication protocol and a device profile specification for systems of CAN used in automation. DeviceNet: DeviceNet is a network system for interconnecting devices for data exchange used in automation. Examer: Lecturer Allan Huynh Ph.D at department of science and technology Linköping University Campus Norrköping, Sweden. Heavy machinery: Meaning all types of heavy vehicles, cars, derricks etc, utilizing CAN. ican: Project name of this thesis, stands for Intelligent Controller Area Network. IP core: Intellectual property core, generated functionality from Xilinx. OP-AMP: Operational amplifier Transceiver: Transmission and receiving enabled on the same unit SAE J1939: Arecommendedpracticeintermsofvehiclebusforcommunication and diagnostics of vehicle components. Supervisor: Qin-zhong Ye at Linköping University, Mattias Hovebro at Syntronic in Kista, Stockholm Sweden. 0x66 Example of a hexadecimal digit, in decimal it is 102.

Abbreviations 2 Abbreviations ADC Analog Digital Converter CAN Controller Area Network CRC Cyclic Redundancy Check EEPROM Electrical Erasable Programmable Read Only Memory FIFO First In First Out FPGA Field Programmable Gate Array LNA Low Noise Amplifier LiU Linköping University TQ Time Quantum SNR Signal Noise Ratio SPI Serial Peripheral Interface USB Universal Serial Bus

Introduction In this section will the project be introduced. The reason for this project in terms of background, purpose and methodology will be discussed and thoroughly depicted. 1.1 Introduction Each day there are new forms of technology flourishing our society. With every new type of technology follows a certain need of control. To control a system something that observes the system is needed. The lack of physical space in a system, together with the need of instant control of processes, alarms and their priorities within the system, have provided the contemporary foundation of networking standards. Today s technology is in a certain need of communication, hence, systems need to easily be able to communicate and affect each others input and output. One way of doing this is through the CAN vehicle bus standard. 1.2 Background CAN Controller Area Network is a standard, designed originally for the automotive industry. The standard is a multi-master broadcast networking technology, with a bus network topology for connecting electronic control units (ECU). Each system (node), is connected to a serial line, being able to simultaneously receive and transmit messages. A message consists of up to 8 data bytes, hence it is optimized for transceiving small packages. The message consists primarily of a data frame for which an ID is embedded in the data. When a conflict occurs between several CAN messages that are being transmitted, the message with highest priority in its ID will succeed in sending its message in contrast to a message with low priority. That will wait until the highest priority message has been sent. 3

Purpose 4 Wherever the CAN system is implemented (often in heavy machinery), when the system starts to behave unpredictably, CAN failures are often found to be one of the causes. When one of the nodes connected to this system breaks, the error frame is supposed to indicate this. However, some failures are due to signal quality issues. For instance, if a signal is suppressed in some manner, the signal might not be interpreted by the CAN controller as a logical 1. Nonetheless, the task to control and observe the CAN system require certain electronic knowledge and in particular knowledge about CAN protocol troubleshooting. This is time-consuming for repairmen with insufficient methods to analyse methods for the breakdown, nor enough knowledge about it and therefore the repair can be costly. Moreover, there are ways to control the CAN systems today through certain equipment found on the market. This objective of this project is to investigate a solution that could detect failures in the CAN system. Simply by being able to analyze the signal quality and interpret the signal, potential failures can be identified. This is done by both comparing digital data from the CAN controller with the pure analogue signal and analyzing the analogue signal with specific signal theoretical concepts found in the theory section of this report. The project is built upon an existing hardware at Syntronic that includes some of the necessary components to analyze a digitalized signal of the CAN signal. Some of the components named are a FPGA, an ADC, a CAN-transceiver and controller, and some operational amplifier circuits to shift and amplify the analogue signal. 1.3 Purpose The general aim of this study and the project in general is to develop an analyzer for a CAN network, to find suitable algorithms and investigate the markets supply of similar solutions. It is aimed, as well, to find solutions that make it possible to interpret the signal quality in an easy way for a repairman, and finally to implement an analysis model that in some way complements already existing technology. This can be stated through two key terms of purpose: How can one interpret errors through the analysis of a signal?

Method 5 How does one develop a signal analysing system on a FPGA? The algorithm needs to partly be able to analyze the analogue signal quality described in section 2.6 and partly to interpret the ID in the data frame to see which node that has the error. 1.4 Method The study and project will mainly be conducted at the office of Syntronic in Stockholm and partly at home through report writing. The author of this study has a background of 9 semesters of engineering and 3 semesters of business administration. During this project a triangulation through empirical data and theory will be used to determine substantial information. In this way, it is possible to strengthen the facts derived through this investigation and project. 1.4.1 Literature review During the project a critical literature review and theories regarding the purpose will be examined. Information will be examined and sorted to its reliability when it comestohowitisusedintheproject. Forexample, ifanarticlestatessometheories, the source of the statement is tried to be found. Therefore, it often comes down to theories and empirical data found on reliably publishing journals. In regard to the objectives of the reviews, it is to gain knowledge about CAN networks, common problems and signal theoretical analysis models. 1.4.2 Market study Amarketstudywillshowcommoninterferencesinthefieldorinalaboratory environment. It is sought to gain insight of the demands and its opportunities.

Method 6 1.4.3 Tools The project will mainly be based on the already existing hardware prototype for CAN analysis at Syntronic. However, the main focus will be to implement a method to analyze the CAN signal on the FPGA on the hardware. To do this, several software programs are needed for the development process. The initiation, the emulating of CAN signal, the development of the FPGA firmware, are all developed in software tools on the computer. 1.4.4 Quality Bryman & Bell [4]statethateveryresearchdesignhassometypeoflimitation.To argue for the quality of this qualitative research in the literature review, two main criteria are used: reliability and validity. Justesen & Mik-Meyer (2011) state further that coherence and consistency are two important criteria in order to ensure the quality of a study. 1.4.5 Reliability Bryman &Bell [4] describes reliability as some results that are consistent or that havethepossibilityforadifferentresearchertorepeattheresultsofastudy. Bryman &Bell[4] further state that qualitative research receives criticism for being hard to replicate due to the lack of transparency. In order to facilitate the replicability of the study, it has been in written with a certain transparency in mind. The study is divided into different sections such as background, literature review, theories, implementation and results in order for the reader to become acquainted with these concepts. The author of this thesis argues that the study is replicable in the sense that is written with transparency in mind and that it welcomes any other interests to acquire the information necessary to solve the project s purpose. Internal reliability is referred to inter-observer consistency or that the researcher and tutor agree on the observations made in the study (Bryman & Bell, 2003). The author argues that the study has a high level of internal reliability due to mutual

Method 7 understanding of electronics and how to interpret possible solutions to problems, into the context of the study. 1.4.6 Validity External validity is described bybryman & Bell [4] as to what extent the findings could be generalized across the social setting. The study is an in-depth study which has been convenience sampled due to internet findings and therefore does not represent the whole possibilities of solutions, so the results could not be generalized due to the lack of external reliability Bryman & Bell [4]. The author is aware that the results could have been different with another way of gathering information and if aslightlydifferentresearchdesignhadbeenused. 1.4.7 Coherence & Consistency Coherence is described by Justesen & Mik-Meyer [6] asanoverallcontextofthe thesis. The study is written so that different parts of the study are perceived in a rational order. The author has tried to see the study from a readers point of view and therefore restructured the thesis several times. The reader should be given the possibility to see an overall context of the thesis. The thesis is thus structured like afunnelwheretheintroductionisthewideopeningandtheresultisthenarrowed outcome of the work. Consistency is linked to both precision and expressions. This thesis is written with consistency in mind: definitions are described and the synonym for the definition is used with consistency throughout the thesis in order to reduce misunderstandings for the reader. As an example, FPGA is used consistently instead of the entire definition of it. When a certain type of information is repeated but in different settings as in the introduction with the CAN protocol or the theory section, the same structure and language has been used. This facilitates the task for the reader to extract the information in the same way in each section.

Method 8 1.5 Limitations Although the project is meant to be suited for the duration of 20 weeks, several issues along the way may occur. Stated below are some limitations of the project in terms of what will be examined and more project-based limitations. The time of this project is limited to 20 weeks. The quality and amount of empirical data that can provide the foundation for the signal processing algorithm, i.e. verification tests. The amount of theories applicable for analysing typical CAN signals. The project will not develop any new hardware more than simple additions. The analyzer will not be evaluated and verified in several different environments due to the company.

Method 9 1.6 Requirement specification This section states the requirements for the ican project analyser. The requirements are divided into critical, important and extra features, meaning that the critical steps are those that need to be accomplished in order for the analyzer to work properly. The important steps make the prototype more user-friendly and are built on the critical steps. The extras steps and important steps will be implemented first when the critical steps are achieved. However, in the project requirements there are only critical steps. 1.6.1 Pre-study knowledge Following tables in this section are the lore the author try to acquire after the prestudy of this thesis has been concluded. 1.6.1.1 Critical ID Requirement PC1 Appropriate CAN-network knowledge PC2 CAN controller PC3 VHDL coding and FPGA design PC4 CAN technology PC5 Analog measuring techniques PC6 Basic analog electronics 1.6.1.2 Important ID Requirement PI1 Know implementation steps of a Graphical User Interface PI2 Knowledge of CANopen PI3 FFT on a FPGA

Method 10 1.6.1.3 Extra ID Requirement PE1 Code a OS PE2 Touchscreen implementation 1.6.2 ican requirements Following tables in this section are the requirements of the project ican which is the product developed in this project. 1.6.2.1 Critical ID Requirement IC1 To sample the data in a measurable way IC2 Analyze the edge steepness, disturbance free voltage and peak-to-peak IC3 Detect the node ID for the analyzed signal IC4 Compare error of the digital signal with the analogue IC5 Show analysis result in the prompt 1.6.2.2 Important ID Requirement II1 Implement a FFT analysis of the sampled signal II2 Include the FFT result in the quality measure II3 Create a GUI to see the quality, error node and possible interferences II4 Analyze transmission impedances

Method 11 1.6.2.3 Extra feature ID Requirement IE1 Create a portable device for the operators with the algorithm 1.6.3 Project requirements Following tables in this section are the requirements of the project-based terms. 1.6.3.1 Critical ID Requirement PC1 Deliver a thesis report when the project and goals are met. PC2 Write a pre-study report PC3 Do a schedule of each moment during the project PC4 Each week write a weekly report for the tutor at Syntronic PC5 Presentthethesisresultsandprojectfor Syntronic and at school. 1.7 Risk analysis The risk analysis is made on this project to keep awareness of certain loop-holes and how to meet some potential issues. The higher the risk value is, the higher the effect of this threat affects the project.

Method 12 Risk Probability Action (P)*Consequence(C)= Risk Value(R) 1. Illness 1*2=2 Work with the report at home 2. Non substantial data 2*4=8 Base the project primary on theories from laboratory 3.Cleaved opinions regarding the project 3*1=3 Have a meeting and discuss a solution suitable 4.Hardware breaks 2*4=8 Test it and repair it. 5.Softwarebugs 3*2=6 Use version-log and restore it. Bughunting. 6.Data loss due to computer/server breakdown 2*4=8 Try to recover lost data. Each risk is identified with a integer value between 1-4 where 1 is low and 4 is high.

Theory In this section the theoretical background of this project will be explained. The section is mainly adapted from CAN specification by Robert BOSCH GmbH [1] unless stated otherwise. In 1986, Bosch GmbH introduced the serial bus system, CAN. The protocol was created to fulfill the requirements of the automotive industry for which there was no network protocol existing which supported the engineers requirements. The main purpose of the protocol was simply to add new functionality to the existing automotive industry, not only solve the wiring harness in the vehicle. The development of CAN has been a complete success and revolutionized the technology used in more than 700 million CAN nodes as of today. Almost every new passengercarmanufacturedineuropehasacannetworkinthecar. TheCANprotocol has also found itself appropriate to several other applications such as industrial machinery, ships and aircraft. 2.1 CAN standards The latest version in Bosch standard specification is divided into two standards with themaindifferencebeingthatinthemessageframe, theidentifierlengthdiffers. The extended CAN (2.0B) is back compatible i.e. it can receive standard CAN messages. However the standard CAN (2.0A) cannot do this in most cases but in some it may skip the rest of the extended identifiers. Standard CAN (Version 2.0A). Uses 11 bit identifiers. Extended CAN (Version 2.0B). Uses 29 bit identifiers. Moreover, there are two ISO standards for CAN. The technical difference is in the physical layer. ISO 11898 up to 1 Mbit/s whereas ISO 11519 has an upper limit of 125 kbit/s. CAN ranges between a voltage 3.5 V and 1.5 V where CAN H ranges between 3.5 V down to 2.5 V and CAN L ranges between 1.5 V up to 2.5 V. 13

Theory 14 2.2 Layers As many other network protocols, in order to make it more flexible in an implementational point of view and a certain transparency, CAN has been divided into several abstraction layers. Those are by all means not a physical property, but just awayofviewingthecharacteristicsandcertainparametersinadefinedway. 2.2.1 Physical layer The physical layer defines how signals are actually transmitted. It is also the specified medium through which the signals propagate. It is a ISO-standard, ISO-11898. Where specific standard definitions of mechanics, electrical properties have been defined within the ISO-11898 standard. Electrical aspects are defined in ISO 11898-2:2003 such as connectors, voltages, transmission resistance. Moreover, in the ISO standard the signals should be carried in twisted pair wires of CAN L and CAN H, in a shielded cable to minimize some RF emission and in order to reduce some interference. 2.2.2 Object layer All the message and status handling as well as the filtering is made here. The scope includes being able to find which messages that are to be transmitted through its ID, as well as deciding which messages received in the transfer layer are going to be used. In this way, the object layer pose a interface between the application layer and the transfer layer. 2.2.3 Transfer layer The transfer layer receives the messages from the physical layer, as it receives messagesfromtheobjectlayerthatareyettobetransmitted. Thetransferlayerhandles bit timing, error detection and signalling, synchronization, acknowledgement, message framing, arbitration and fault confinement.

Theory 15 2.3 Message management In CAN, data is transceived using message frames. A frame is a sequence of bits, making it possible for a receiver to detect the start and the end of the sequence. Those frames are used when a node wants to transmit data to the network and when receiving data. Start of Frame (SOF) field, indicates a message with a recessive, logic 0. Inside the second field, the Arbitration field, there is for example the remote bit. This bit determines whether or not the message is a remote frame or a data frame. If it is set, it is a remote frame, meaning that the transmitting node request for a certain information from the node given and determined in the identifier. In the Control field the length of the data is found, as are two reserved bits for future development of CAN. The following Data field, contains 0-8 bytes of the very data message that is yet to be interpreted. TheCyclicredundancycode(CRC)fieldcontainsfifteenbitCRCfordetecting errors and a recessive delimiter bit. The Acknowledgement field is used to send acknowledgements to the sender or receiver, for instance, a receiver that has received a valid message report this by setting one of the bits in the field, the ACK SLOT dominant, logic 1. EveryDataframeandRemoteframeareintheendfollowedbyaEndofframe, containing seven recessive bits. 2.4 Error management There are 5 different digital error types defined in the protocol. Those are bit errors, stuff errors, CRC errors, form errors and acknowledgement errors.

Theory 16 Bit errors occur when some bit has been changed. This can been seen because a unit that sends a bit also monitors the bus at the same time, controlling the bits. Stufferrorsaredetectedwhena6thconsecutiveequalbitisfoundonamessage field that is coded through bit stuffing, which is the principle of insertion of non data bit in data. When the received CRC sequence differs from the calculated at the receiver or transmitter a CRC error is detected. Form errors, when one or more bits contain one or more different bits. When the ACK SLOT in the acknowledgement field is not dominant, the acknowledgement error is detected. Hence, a unit may be in three different states during error handling; error active, error passive and bus off where the unit cannot influence any process. There is a specific error frame controlling the nodes when a error has occurred in different ways stated in Section 2.4. However, the Error frame consists of two fields, error flag and error delimiter. There are two forms of error flag, active error flag and passive error flag. The active error flag consists of six consecutive dominant bits in contrast to the passive which has six recessive bits. A node with an error shows this through the transmission of an active error flag on a error frame. When a node which doesn t have aerrordetectsanderroritsignalsthisthroughthepassiveerrorflag. Thoseare triggered through the conditions in Section 2.4. 2.4.1 Bit stuffing If the transmitter logic detects five consecutive bits of the same level, i.e. recessive or dominant, the logic will insert a sixth bit into the transmitted bit stream to assert the phase-locked bit timing is being synchronized with the message bit stream. This process is called bit stuffing and is a common way to try synchronize several

Theory 17 channels. Furthermore, when a CAN device receives five identical consecutive bits it will automatically remove the sixth one in a process called bit destuffing. This process sets up a rather complex amount of scenarios generating errors in the CAN system, for instance, when a bit error occurs in the last two bits in a message, where it is supposed to show the end-of-frame bits, generating multiple messages. For example, at a bit error rate (ber) of 1/10 4 and a node failure rate of 1/10 3, there are 2840 inconsistent message omissions that occur per hour and 3.94 x 10 6 inconsistent message duplicates that occur per hour. [5] 2.5 Bit timing In CAN, every bit itself is divided in to several sub-parts. Seen in Figure 2.1 there is an overview of one bit in CAN. The length of these sub-parts are determined by atimequantum.timequantumisdeterminedthroughequation(2.2), where M is is the value of the prescaler, where minimum time quantum is just a starting point. TIME QUANTUM = M*MINIMUM TIME QUANTUM (2.1) Figure 2.1: Bit timing. At the synchronisation part, that is the time it take for various node on the bus to synchronise, also an overshoot is expected here.

Theory 18 2.6 Analysis techniques Data analysis is a process of inspecting and transforming data with the objective to discover useful information, suggestions for conclusions and support troubleshooting. How one chooses to analyze a analog signal will have a significant effect on the results. If a signal is under-sampled, peaks will be unnoticed and for instance a peak-to-peak value, will not be accurate. Moreover will the chosen methodssometimesshowandindicatedifferentoutcomes. Outcomesandresultsinterms of possible reasons for the shown error. 2.6.1 Measuring quality Quality has two aspects in this project. First there is the quality of the measurement, how well the data is measured. Second is the quality of the data. Data is not equal to measurement and will always differ in a minimized uncertainty. However, the quality of the measurement is determined through the analog hardware components, how the signal is shifted and amplified and possibly interfered on the board, and the sampling of the ADC. However, the quality of the data is the quality aspect this project targets to value which would represent all the disturbances and interferences arising on the CAN-bus. Quality is in many ways rather subjectively defined. The quality of this analogue signalwillbedeterminedthroughthreedifferentmeasurements, allweightedequally, that is the edge steepness, the disturbance free voltage and reflections. Each analysis methods and its definition is shown in the Figure 2.2,wherethexavisarethe amount of samples and y-axis is the resolution of 8-bit.

Theory 19 Figure 2.2: Overview of analyze methods for a single emulated CAN-bit signal. 2.6.2 Edge steepness Edge steepness is measured through calculating the rise time for when the logical 0 becomes a logical 1. This is defined as 10 percent more of the value for where the signal just starts to increase, for instance if it is 10 the value x is 11, i.e. 10 percent more. However, the maximum value for where the signal starts to decrease to its steady state, is multiplied with a factor 0.9, i.e. 10 percent less than its original signal making a maximum value of 20 become effectively 18. However, this would give us a difference of 7, which is defined as the rise time of a signal. However, in the quality aspect, this value itself has to be put against some optimum value of rise time versus a worst case scenario value. Hence, the bit time will be taken in consideration. Each bit is sampled a certain amount of times, so obviously one has to compute the analysis for one bit logical 1. The times each bit are sampled set the way the rise time is determined. In the test bench of this project, one bit includes different amount samples of data due to the different baudrates. Hence, the edge steepness worst rise time is when 100 samples have passed to the maximum value is found. which gives the equation of edge steepness in percentage as (100-rise time)/100. However, the sought adapting system description would be:

Theory 20 Percentage = Amount of samples 2 (perbit) rise time Amount of samples 2 (perbit) (2.2) 2.6.3 Disturbance-free voltage Disturbance free voltage is measured through comparing the amount of free space betweenthesignals worstoscillation. Basicallyitisthevoltagewherenooscillations occur. This value is weighted and calculated in relation to the signal level, that is in a optimum square-wave output, which means no rise-time and no oscillation. This means that 0% quality measurement is almost impossible, because then the disturbance free voltage will be 0 and there will be no visual waves, or just high oscillations. 2.6.4 Reflection Reflection is measured as the ratio between the Disturbance-free voltage and the peak-to-peak value, where peak-to-peak is the maximum and minimum value of a bit. 2.6.5 CAN controller output vs analogue The digital information is used to control which node in the distributed CAN network that had the quality displayed through the analyze measurements. It connects the analog data, to the node on the network.

Market analysis In this section a market analysis will be described for which several similar products found are examined in order to evaluate the criteria for the analyzer made in this project, to view what techniques that are already used and the price setting of them. The market analysis was conducted through searches on the internet accordingly to Section 1.4.6. Products most similar to the requirements of this project have been searched for. 3.1 CAN-bus tester 2 CAN-bus tester 2 (CBT2) is a universal diagnosis tool for the CAN bus, in terms of monitoring, troubleshooting, analysing quality of the signal, looking for faults. Typical errors that occur during transmission can be detected through this tool and according to the developer of CAN-bus tester 2 there are often physical layer issues that supply the reason for several common faults in a CAN network. CBT2 is found marketed both by IXXAT and GEMAC brands, however IXXAT is one of GEMACs distributors and the manual is GEMACs. Functional features: Monitor, troubleshoots the CAN bus traffic both sending and receiving Automatically detects and adjusts to the networks baud rate Automatically finds the nodes on the network Supports CAN, CANopen, DeviceNet and SAE J1939 Software features: Measure quality, edge steepness, disturbance free voltage and reflection of the analogue part 21

Market analysis 22 Connect quality measurement of the analogue signal to the digital signal and its node Detects transmission line mismatches Real-time monitoring of CAN signals, bus status, etc, on the computer Abuilt-indigitaloscilloscopeoftheframesbeingsent Functional description: The manual states that the CBT2 has a sample rate of approximately 64 MS/s due to its sampling of each bit 64 times and having a bit rate of 1 Mbit/s. The module uses a general quality aspect of the analogue signal, evaluating measurements of the edge steepness, disturbance free voltage, signal level, overshoot and reflection. It weight three measurement of disturbance-free voltage in relation to a perfect CAN voltage reference, as well with the reflection and edge steepness. Those are compared to a value that is seen to be a 100 percent quality level respectively 0 percent. Those three measurements are weighted equally to a general quality measurement giving in the spectrum 0-100 %. Observed weaknesses: All the functionality is based on examination and troubleshooting with a computer. It is also necessary to have the right knowledge about CAN in order to fully understand the product s analysis. Moreover the price is rather high, more than 30 times the price of CAN bus analyzer that at least has the functionality of monitoring and transmission of the CAN messages. Some comments on the way to measure the signal quality is that those concepts don t reflect all possible ways to determine the signal quality. Measurements such as overshoot and undershoot is interesting as an example. Price and availability: CBT2 is sold at IXXATs web shope for 5700 USD and according to the manual it is also necessary to have the additional licences purchased in order to use CANopen, DeviceNet or SAEJ1939. [8]

Market analysis 23 3.2 CAN BUS Analyzer Tool The CAN bus analyzer is intended to be a easy-usage low cost CAN message monitor made and primarily sold by Microchip. It supports CAN 2.0B and high-speed CAN with transmission rates up to 1 Mbit/s. It can be used to monitor and debug a CAN network with a graphical user interface. Features: Mini USB connector Status,trigger,error and transmission LEDs Access to the CAN high,low, RX and TX pins through a screw terminal. DB9 connector for the CAN BUS. Software features: Monitor the CAN bus traffic Transmit single shots onto the bus Transmit a list of CAN messages in order to the bus Configure visibility on the trace window of each message Save CAN bus traffic Functional description: The user interface can be used to transmit and receive messages in various form of a rolling window, filtering on ID, DLC or Data. There is also given an appendix with troubleshooting messages that the CAN bus analyzer gives the user. For instance, an error number 1.00.x would say that there is a trouble reading the USB firmware version or 3.20.x states that the data field is empty. Observed weaknesses: There doesn t seem to be any analysis of the CAN signal, nor quality attributes of

Market analysis 24 the signal. The module seems to be used more as a logging tool and can be used as a test node to test the behaviour of the CAN bus and all that is connected, troubleshooting the messages being sent, i.e. the digital interpretation from each node CAN controller. Price and availability The module is sold on microships website for 99.99 USD. It can also be found on RS electronics website for 950 SEK.[9] 3.3 CANwatch CANwatch is an easy-usage analyzer tool for recognition of errors in a CAN network with display LEDs manufactured and sold by EMS Thomas Wuensche There is no need for specific CAN knowledge in order to use this product, which is mainly because it only analyzes the analogue signal quality of messages being sent on the CAN line. Features: Mini USB Connector Status, trigger,error and transmission LEDs Access to the CAN high,low, RX and TX pins through a screw terminal. DB9 connector for the CAN bus. Fast recognition of errors Scanning the analogue signal and evaluating signal quality Functional description: CANwatch analyzes the CAN network through only the analog signals shape such as overshoot, invalid levels, slow edge steepness and short circuits within the signal line in a digital signal processor. It is sampled at a frequency of 16 Mhz with a 8-bit resolution. Simply working as a node in the CAN network, the CANwatch is connected in the line of the CAN bus or, primarily used for the overall signal quality of a network.

Market analysis 25 Observed weaknesses: In a bigger CAN network, this module wouldn t help the user anything in troubleshooting more than giving an indication on the general health of the CAN network. Due to the neglected analysis of the digital signal, CANwatch can not predict which node that contributes with a bad signal quality. Price and availability CANwatch can be ordered directly from EMS Dr. Thomas Wuensches either a hand held or a racked mounted version. On the website, there is no specifed price.[7] 3.4 Summary market analysis Following Table 4.1 is a comparison of the described products found on the market, this will later be used as a comparison with the results from this thesis and the existing products on the market. Table 3.1: Market analysis comparison Functionality CAN-bus CAN BUS CANwatch tester 2 Analyzer Tool Userinterface in computer x x x Userinterface without computer Indicating LEDS for troubleshooting x Analogue analysis of the signal x x Digital controller to find ID x x 8-bit resolution sampling x Support up to 1mbit/s sampling x x x

Hardware and tools In this section all the hardware tools that the platform are being developed on will be explained. In Figure 4.1 isthereal equipment used, seen to theleft ofthepicture is the interface board created by an earlier thesis. Figure 4.1: Picture of hardware board 4.1 Interface board Figure 4.2 shows ageneral overview of the existinginterfaceboard. 26

Hardware and tools 27 Figure 4.2: Overview of existing interface hardware 4.1.1 Power supply Theinterfaceboardoperatesona5Vwallwartadapterandincludesseveralfiltering and decoupling stages in order to make sure that a stable power is delivered to the components on the board. The power to the analogue and the digital components is divided in order to avoid noise from the other components. The interface board also contains an ADR130 voltage reference to provide a 0.5 V voltage to the operational amplifier in the signal conditioning circuit. 4.1.2 Signal conditioning The signal conditioning network strives to match the ADC board s input range. It filters, shifts and scales the analogue CAN signals to range 0 to 1 V. Basically the network begins with a impedance increasing voltage follower and then a simple two resistance voltage divider followed by a shifting circuit, built upon the same operational amplifiers as the first voltage follower, but this is fed on the inverting input with a 0.5 V signal. It has a feedback circuit of a resistor and a capacitor

Hardware and tools 28 in order to match the range of 0-1 V output and collateral stability. This network board is developed by a previous thesis. 4.1.3 Digital CAN interface The CAN interface consists of two major components, a CAN transceiver and a controller. The CAN controller is a chip, MCP2515, that implements the CAN version 2.0B which makes it compatible with 2.0A as well and is hence capable of receiving and transmitting both standard and extended data frames and remote frames. The MCP2515 consists of mainly three blocks; the CAN module which handles the CAN protocol engine, receives and transmits buffers, filters and masks, the control logic that initializes and configures the device, and the interface with microcontrollers through a standard SPI interface. The CAN module handles all the functions for receiving and transmitting messages. When a message is being received, the message is checked for errors by reading appropriate registers, and will be removed if the user-defined is initialized in that manner, or moved into one of the two received buffers. The Transmitting procedure works basically the other way around by first loading the appropriate message buffer and control register to make sure that the message is defined correctly and not a incomplete message is to be transmitted, and furthermore the transmission is initiated by using control register bits via the SPI interface. The control logic module controls the setup and the operation by interfacing to the other blocks, passing information and control. It is connected to several pins, including ones used for interrupt. This in order to check if a message has been received correctly in to a buffer or for example that a transmission is initiated. [10] 4.2 Flashy-D The FlashyD board is a 3.3 V powered 8-bit sampling ADC module, commonly used to create a digital oscilloscope. On the board is two ADC08200 which is a low power, 8 bit single input ADC. It is designed to work between 20-200 MS/s and has a 44

Hardware and tools 29 db Signal-to-Noise Ratio (SNR). The device uses a technique that achieves over 7 effective bits at input frequencies up to and even beyond 100 Mhz. Data is acquired at every rising edge of the clock and as long as the clock is present and the power down pin is low, the module will constantly digitize data. The board also consists of a switched capacitor bandgap which makes the ADC08200 have a power consumption that is proportional to the frequency so that it limits he power to the clock rate utilized.[11] 4.3 Xylo-LM FPGA Xylo-LM is a development board for FPGA and microcontroller projects. The board includes a Xilinx Spartan 3E FPGA, an ARM7 processor, an USB controller, and circuitry for driving and controlling those components. The FPGA is configured through the USB link but can also be booted through an EEPROM on the board. [12] 4.3.1 Cypress FX2 The USB controller is a cypress EZ-USB FX2LP. It is a single chip low power USB 2.0 microcontroller which has full configurable general purpose interface. Henceforth the module is termed as Cypress FX2. The Cypress FX2 has a master/slave configuration working with either a 8-bit or 16-bit wide bidirectional data bus, however in this project it is used with a 8-bit wide data bus and the USB controller in slave setting and the FPGA as master.[13] 4.3.2 Xilinx Spartan 3E FPGA The Spartan 3E field-programmable gate array builds on the earlier Spartan-3 family bymainlyincreasingtheamountoflogicperi/o.thespartan3eisideallysuitedfor awiderangeofconsumerelectronicsasofthisproject.itisbuilton90nmprocess technology. Important characteristics of Spartan 3E that will be in consideration during this project are found in Table 4.1 [14]

Hardware and tools 30 Table 4.1: Characterstics of Spartan 3E. Characteristic Value Configurable logic blocks(clb) 4,656 Maximum user I/O 232 Number of RAM blocks 20 Block RAM bits 360k Digital clock manager(dcm) 4 Dedicated multipliers 20 4.4 LCD screen KNJN The LCD screen is a monochrome display, 480x320 pixels with an included adapter board including an EPM3032A PLC. According to distributor of the LCD screen is all logic to control the LCD made on the FPGA. The LCD screen is controlled by on data pin, a clk pin, ground and Vcc. The reference design included by the product was obsolete. No user-guide was included. Seen in Figure 4.3 isthedevelopment hardware.

Hardware and tools 31 Figure 4.3: Entire equipment

Implementation In this section the implementation steps of this project purposes will be explained. It will use empirical tested data together with theory in order to develop the system required. The text will try to explain how and what is going to be implemented, what has been implemented and what the appearance of the result should be. 5.1 Overview of functionality The objective to realize the purpose of this study is, to analyze the signal quality, and relate quality to digital interpreted messages at the CAN controller. The signal sent from the CAN-bus is shifted and amplified in order to have the specified range of voltage defined by the ADC. The sampled data is then sent to the FPGA for signal processing. The FPGA will process the signal by the analysis techniques found in Section 2.6. The analyze result will be evaluated on the FPGA. This is the very foundation of the system and it is adhered functionality additionally to this that will create different systems. The project has several objectives that are sought to be met, hence the functionality of the analyzer will be different systems in terms of code produced. The systems will be developed consecutively, System 1 first, when it works, System 2 and lastly System 3, in this way those systems is more seen as a development process and subgoal. 5.1.1 System 1 - Analogue analyzer System 1 is a computer to machine working analyzer. It will analyze the analogue signal s quality, which includes the USB interface code for FPGA to computer, FPGA communication, analyzer and the ADC sampling and computer host script. The result will be shown on the computer as a percentage in the command prompt. 32

Implementation 33 5.1.2 System 2 - Analogue and digital analyzer This is where the analysis of the digital data comes into consideration. The system should perform as the previous system with the addition that it should interpret the identifier data and present the quality measurement in relation to the digital data. This should be presented on the command prompt with a communication link that makes the user able to choose what data that should be shown. For example, the user can choose to only see the sampled ADC data, or see the analyzed data and the message id to the message analyzed. 5.1.3 System 3 - User interface System 3 is to completely take System 1 and 2 and present the information on a LCD graphic display. All the analysis will be presented as fast as the analyser has done it and send it to the LCD. 5.2 Setup test-bench To create and implement the systems there are some major first steps that have to be taken during the process. One of them is to create a test bench where it is easy creating an emulated CAN signal, and that it is user-friendly to measure the signal and that it doesn t take to long to setup for a demonstration. The test-bench should pose a foundation for all systems. However, as System 3 is in many parts, built on System 1 and 2, the evaluation will be done on the PC through a script analyzing data from the FPGA interfacing via an USB. 5.2.1 Added hardware Some of the hardware needed to be revised in order to get the test bench working properly. One major step has been to utilize a proper terminated cable, so this cable was built in order to get the signal ground normally in the test bench. Also one

Implementation 34 operational amplifier didn t work on the interface board properly and had a shortcut between inverting and non-inverting line but this was fixed. 5.2.2 FPGA logic OnthecodeimplementedontheFPGA,therearemainly4blocksormodules. These are a FIFO memory, USB Interface, Interpretator and an ADC Interface. The major design has been with a reference to a clock, building up some processes in VHDL and some different states. Every state is controlled by the clocks but, however, some of the processes happen simultaneously, which means that as soon as any signal in its body or sensitivity list is changed, the process and action is updated. This basicallymakesthedesignpartlydependentontheclock,butalsosomesimultaneously. A sum up of the entire test-bench, is exemplified through Figure 5.1 with the main signals. Figure 5.1: Test-bench overview of embedded functionality in the FPGA

Implementation 35 The chosen design is based on a FIFO memory block to keep track. It is triggered to start its saving on a falling edge of the sampled data from the ADC. The acquired samples from the ADC are stored at a speed of 100 Mhz. However, from the FIFO the samples are read at a speed of 24 Mhz. The FIFO fills up quite fast but has a depth on 16384 bytes and a width of 8 bit and a pre-stored output value of 0x66 to secure any output mistakes. The USB interface is built to interface with the Cypress FX2 module with the bits for reading, writing, enabling, full, empty and data in/out bus. It has a 8-bit data link for which data is both sent through and received. The module implemented basically reads the data sent from the PC via the data bus, it examines the action and sets some control bits and then sends it to the interpretator. It is also the interface for all transmission from the FPGA to the computer, i.e. all the data from the ADC. Those are only let through on some certain conditions that endorse and make sure that the data sampled is the correct data. The interpretator does all the bit setting for controlling the internal flow. This means that it decides whether or not the data should be read from the FIFO modules and hence erased from it. It has the functionality to interpret the data from the USB, the command, and set the readenable to the ADC FIFO, if that is requested. The ADC interface is basically just connected to the Flashy-D breakout board for the ADC08200. The ADC module just connects the incoming data from the ADC to the ADC FIFO when a trigger from the ADC values is set, indicating that a CAN message is being received and under condition that the FIFO doesn t contain any data and stops as soon the FIFO is full. 5.2.3 PC software Theprogramthatrunsonthecomputerforthetestbenchhasbasicallyonepurpose, and that is to initiate the right requested transmission through sending it via the USB. However, more functionality is added to the software test-bench to be able to evaluate the data in the best manner possible. For this, the functionality of analyzing the complete data package of the analogue data has been implemented in C++ code.

Implementation 36 So not only can the test-bench request data from the FPGAs sampled analogue ADC input, butcanalsoanalyzeitasacomparisonforfurtherdevelopmentonthefpga. In C++ it is much easier to compile and test the functionality of an algorithm and the program. For that, mathematical calculations are more simply developed and tested, for instance calculating the rise time, disturbance free voltage and reflection. The entire extracted data can be handled through a dynamic array, saved into it and then stepped through by algorithms to compute the requested calculations. The program starts by setting a register for an USBdevice object, opening and searching for the specific device connected to the computer. It creates an USBdevice object from which it reads and writes data. The program starts by executing an incoming request, asking the user to ask the FPGA for some data through a command window. In the test bench case, it is a simple letter A that is required for initiating transmission and calculation. A stands for the ADC sampling and initiates ADC sampling on the FPGA. Of course will this user interface be more user-narrowed in a further development tool, but as a test bench it includes all the general functionality needed as a foundation to create extra functionality built on this. As soon the proper command has been written in the command window, the program calculates through several different functions: the rise-time, the disturbance free voltage, the signal level, the reflection and furthermore a general quality measurement based on those functions. How those measurements are specified is found in Section 2.6.

Implementation 37 5.3 System 1 - Analogue analyzer When the test bench was working properly, functioning the sampled ADC data and displaying it in new made plain text file, the development of the analogue analyzer was started. The program needed some small changes from the test bench idea, but mainly just some additional modules in the FPGA firmware. The analogue analyzer is based on a program running on the computer, converting known USB data to CAN frames to the FPGA module, in order to emulate the signal. The data is further processed on the FPGA and, when requested, sent back to the PC for a result show. 5.3.1 Emulating CAN-signal In order to send data in to the FPGA at different bit rates and to have a stable connection, a software program was developed. This program sends data to the USB port into the CANUSB module that converts USB data in to CAN messages. The program on the computer sends a standard CAN frame(11 bit). However, at first there are some setups. All setups ends with [CR], that is ascii 13, for showing the end of the message. At first, the USB port opens through sending the letter O. The desired bit rate is sent to the USB port through the command of Sx, where x is between 0 and 8 seen in Table 5.1.

Implementation 38 Table 5.1: Bit rates Chosen message Bit-rate 0 10 kbit/s 1 20 kbit/s 2 50 kbit/s 3 100 kbit/s 4 125 kbit/s 5 250 kbit/s 6 500 kbit/s 7 800 kbit/s 8 1Mbit/s The message is sent by an identifier in hex(000-7ff) followed by the amount of data bytes(0-8) and then the byte value(00-ff). A typical message sent to the CANUSB modulecouldlooklike: t10021133[cr],tisinitiatingthetransmission. Thismessage is with the identifier 100 and 2 bytes of data that is 11 33.[15]Theportclosesby sending the command CR. In Figure the interface form is shown. Figure 5.2: Emulator software form

Implementation 39 5.3.2 FPGA logic In addition to the logic implemented in the test bench, the analogue analyzer has more advanced ADC interface to filter disturbances and an entire analyze module respectively a FIFO memory to it. It also has a divider IP core implemented. The system is shown in Figure 5.3. Figure 5.3: System 1 overview of embedded functionality in the FPGA In order to get all the sampling data saved somehow, regardless of the speed the CAN bus was sending at, a calibration algorithm was developed. This is embedded in the ADC module interface and by a external push of a button, the user of the analyzer can force the analyzer to not sample so often, in order to fill the FIFO memory with an entire message and not just a half. This algorithm is based on the knowledge of the ADC sampling at 133 Mhz and through counting the amount of samples per bit. By doing so, the amount of samples per bit range between 133 samples per bit on a 1 Mbit/s bit-rate, down to 1064 samples per bit with a 125 kbit/s bit-rate. A message length can also vary depending on the amount of data that is being sent. However, the design asserts that at least one entire message is being saved in the modules respectively FIFO. The modulation of the sampling rate is done by division of the writing clock to the ADC FIFO giving the functionality to basically jump over some values that have been sampled in the saving process. However, this is only in order to receive a fully received package from the ADC

Implementation 40 module, the analyzer doesn t utilize this functionality. Moreover the main development in this system was to develop the analyzing algorithm, to find the necessary values to be able to use the analyze techniques in Section 2.6. However, the analyzing block did need the idea of a perfectly timed triggered data from the ADC, asserting that it was an entire bit that was to be analyzed. This was done in the ADC interface module, timing the analyze module to only get data when a new bit was coming. However there could be several bits in a row, but it doesn t matter because the values interesting in investigating in are found right after the first positive edge and right after the negative edge of the bit. The major functionality for the analyzer module is to find four different values in a signal, in order to determine the analyze techniques. The module starts by looking for a new maximum value and when the highest value is found, the value is saved as a new maximum and the local maximum is searched for. Due to the oscillations, the local maximum of the disturbance free range has been empirically proved to be found right after the maximum value. This is graphically shown in Figure 5.4. Figure 5.4: Analyze values The maximum value is found as marked with a marker 1 in the Figure 5.4,the minimum value 2 the local disturbance free range maximum. As seen in the figure

Implementation 41 the signal level is between those two values. As soon as the values start to decrease more rapidly, the minimum value is searched for. When the minimum is found, as the local disturbance free range maximum is found, the next peak after the minimum, seen in Figure 5.4 as value number 4 is the local lowest disturbance free range value. Through these values the peak-to-peak value, disturbance free range, signal level and also the rise-time can be determined. The rise-time is however not ideally calculated. It is determined by actually counting the amount of times a new maximum is found. This is how it works: when the analysing module starts, it is certain that the data-flow is in a low-state, i.e. not rising or falling. As soon as the values starts increasing more rapidly, the amount of samples are counted until the first value decreasing from the previous comes. Hence, the value given from the analyzer is more of a guideline for the true rise-time value due to the neglection of the 10 and 90 percentage intervals. 5.3.3 PC software The major addition in contrast to the test-bench is the calculation of the different measurements. Those are sent from the FPGA to the PC as values as these four points in Figure 5.4 plus the rise-time. In order to present the values as described in Section 2.6, with a quality measurement and certain percentages, several dividing rings needed to be done and those were much easier implemented with the language C++ than straight on the FPGA, mainly because the FPGA could only send an 8-bit message through the USB to the FPGA, representing only integers. Moreover, small changes with the sending lengths to the FPGA via the USBdevice were necessary, as well as the choices for requested data. This time, the letter B stood for requesting the analyzed data from the FPGA.

Implementation 42 5.4 System 2 - Analogue and digital analyzer Built on the same system as System 1, the interpretation of the digital spectra of the CAN signal could be added on the FPGA logic by three modules: the CAN interface, SPI transceiver and a responding FIFO memory module. The emulation of the CAN signal was done in the same way as System 1. 5.4.1 FPGA logic In order to communicate with the CAN controller, a SPI transceiver between the FPGA and the controller needed to be implemented. The CAN controller initiates the data frame and generates the clock signal for the SPI interface to control the data in and out from the FPGA. The major part of the development was to set the controllers registers correctly for receiving the CAN-bus messages in a proper way. Several registers were written to. The RXB0CTRL register decided for the controller how it should trigger on messages being received and where to save it. It was decided to trigger on any message, regardless if it had extended identifier or standard, SOF bit or not. The BFPCTRL register set that one of the pins will be used when a complete message is loaded into one of the buffers, as an interrupt pin. In order to synchronize and to be able to interpret messages at any nodes, all nodes have to have the same nominal bit rate, i.e. the length of a bit, in a time perspective. And as described in Section 2.5 and seen in Figure 2.1,thenominalbittimeisbuilt on a synchronization part, a propagation part, phase 1 and phase 2. Those states have to be decided for the CAN controller in respect to a TQ. The synchronization width is set to 1 times TQand the baud-rate prescaler (BRP) to 0, giving Equation (5.1). TQ = 2 BRP +1 F osc (5.1)

Implementation 43 TQ = 2 6 10 = 10 6 3 10 7 s (5.2) The bus line is sampled one time with a normal sample point, and the phase 1 is 5 TQwith a propagation of 2 TQand a phase 2 of 4 TQ.Thisgivesatotal bit-time of 12 TQ which is 40 10 7 s. Those setups are set accordingly to the datasheet [10] and for a high bit-rate of 1 Mbit/s. Any lower bit-rate will make it hard to interpret each bit and under 800 kbit/s it won t work with this static design and hence it is necessary for the FPGA to sense the baud rate before this value is set. 5.4.2 PC software The additional software was only a new command for requesting the data from the CAN controllers FIFO memory and read it as a hexadecimal digit and save it to the.txt file.

Implementation 44 5.5 System 3 - User interface The LCD screen should show the information as soon as it was processed by the FPGA through typical letters and numbers. The first objective with controlling the LCD was thus to create a character generator, and create two embedded RAM memory. One that holds all the characters information for the LCD screen to show one of them, and one RAM that pointed to the right information in the character RAM memory in order to send request through a 8-bit value that pointed to that particular ascii representation. However, the LCD screen was bought in consideration of time restraints and that HDL reference design was attached to the product. Unfortunately, the reference design couldn t be used at all and a deep e-mail conversation with the sales responsible ended with no user-guides nor nothing of how to control the LCD.

Results and verification This section contains the results and the verification of the project findings and solutions. It includes measurements of various subsystems in the development of the project. The section tries to emphasize the validity of the results and pose the foundation for further analysis. 6.1 General discussion results The result and verification measurements are done in a laboratory environment during different periods of the development process. The measurement setups have been connected with an oscilloscope to secure the information processed. 6.2 Test-bench result Figure 6.1 showsthe prompt application with the first step in the send procedure, a letter A for requesting the sampled ADC data and automatically doing a analysis of the data on the computer. Figure 6.1: First request command. 45

Results and verification 46 Figure 6.2 shows the example of writing a 8-bit value (letter A ) to the FPGA which acts as a request for the FPGA to mirror the message and send it back to the computer in the data out bus. Figure 6.2: Requesting a mirrored send package from the FPGA by sending a 8-bit value. This was the very foundation for the bidirectional communication between PC and FPGA. Figure 6.3 shows the results of the sampled ADC data and associated signal analysis as described in Section 5.2. Figure 6.3: ADC data written to a text file and shown in excel. Figure 6.4: Computer analysis of the signal in Figure 6.3.

Results and verification 47 However, the test-bench system was developed with a different emulator of the CANsignal and when the interface board still was shorted on the CANH signal. As this problem was solved along the way of development, no more verification is done on this functionality. Nevertheless, in the following systems, both the ADC data and the analysed sequence will be verified. 6.3 System 1 - Analogue analyzer Seen in Figure 6.5 is the user interface of the analyzer, in command prompt. The result of an analysis of the first message is shown accordingly to the analysis Section 2.6. Figure 6.5: Result of an analysis for system 1. In Figure 6.6 is the verification of the maximum, minimum, local maximum and local minimum value found. These values are from textfile, written from the A letter that was sent to the FPGA, requesting the ADC data followed by the analysis request.

Results and verification 48 [Max and local max value.] [Min and local min value.] Figure 6.6: Verified analysis maximum value, minimum value and local maximum and minimum as the marks seen in Figure 5.4. The rise-time is found to be 30 ns due to that the first peak is found after just three samples, seen in Figure 6.7.Atasamplingratioof100Mhz,threesamplesrepresent 30ns rise-time. Figure 6.7: Rise-time ADC values. 6.4 System 2 - Analogue and digital analyzer In Figure 6.8 is both an analogue analysis of the signal quality, the message ID and data is also digital interpreted and verified to be the very message that was sent.

Results and verification 49 6.4.1 Bus rate: 1 Mbit/s At a bus rate of 1 Mbit/s is the following Figure 6.8 result. Figure 6.8: Digital and analog analysis. 6.4.2 Bus rate: 800 kbit/s calibration Figure 6.9and 6.10 areexamples ofthe sampling calibrationdone at aspeed of 800 Kbit/s. Seen in Figure 6.9 is the entire message not included in the transferred ADC data to the computer but after calibration it is, shown in Figure 6.10. X-axis are the 8-bit resolution and the y-axis are the amount of samples. Figure 6.9: Before calibration for the sampling rate.

Results and verification 50 Figure 6.10: After calibration for the sampling rate. As a reference was the signal plotted on a oscillscope, before the interface board had set the range between 0 to 1 V for the ADC modules, i.e. the real CAN bus signal. Figure 6.11: Oscilloscope measurement comparison. 6.4.3 Bus rate: 500 kbit/s Following Figures 6.12 and 6.13 are shown forthe analysis of500 kbit/s.

Results and verification 51 Figure 6.12: Digital and analog analysis.

Results and verification 52 [Max and local max value] [Min and local min value] Figure 6.13: Verified analysis maximum value, minimum value and local maximum and minimum as the marks seen in Figure 5.4. 6.4.4 rate: 250 kbit/s calibration Figure 6.14 and 6.15 are examples of the sampling calibration done at a speed of 800 Kbit/s. Seend in Figure 6.14 is the entire message not included in the transferred ADC data to the computer but after calibration it is, shown in Figure 6.15. X-axis are the 8-bit resolution and the y-axis are the amount of samples. Figure 6.14: Before calibration for the sampling rate.

Results and verification 53 Figure 6.15: After calibration for the sampling rate. 6.4.5 Bus rate: 125 kbit/s Figure 6.16: Digital and analog analysi.s

Results and verification 54 [Max and local max value.] [Min and local min value.] Figure 6.17: Verified analysis maximum value, minimum value and local maximum and minimum as the marks seen in Figure 5.4. 6.5 Market analysis comparison Following Table 6.1 is the comparison between this project ican and the found analyzers on the market. Table 6.1: Market analysis comparison with results. Functionality CAN-bus CAN BUS CANwatch ican tester 2 Analyzer Tool Userinterface in computer x x x x Userinterface without computer x Indicating LEDS for troubleshooting x x Analogue analysis of the signal x x x Digital controller to find ID x x x 8-bit resolution sampling x x Support up to 1mbit/s sampling x x x x Sampling data over 100Mhz and realtime based 24Mhz design x

Conclusion and discussion 7.1 General discussion and analysis of the results The purpose of this study and project to develop an analyzer for a CAN network, find a solution to interpret the signal quality and in some way complement already existing technology. This has all been successfully done. An analyzer has been developed and tested for one emulated CAN network, i.e. a CAN network. The solution of interpreting the quality aspects is made by using the analyse techniques existing in a product out on the market, the CAN-bus tester 2. Those analyse techniques are the disturbance free voltage, the rise-time and the reflection. The signal analysis was developed on a FPGA but could have been developed on a digital signal processor aswell or in different systems optimal for analog-to-digital converting, hence the second key term of purpose in this project is implemented. Known bugs and limitation are obviously that it has only been verified by one CAN emulator and not by a real car, heavy-machinery or likewise. It would have been really rewarding to do so. Because Syntronic is a consultancy firm, the lack of real laboratory equipment and a company to evaluate the product at has restricted this verification process of the analyzer. Because the module is a computer-to-machine device it is necessary to have proper driver routines to drive the configuration of the FPGA in a right manner. The FPGA needs to be configured with a file emptying the buffers of the USB module to work properly when it s first powered up, then it can be used with re-configuration. The digital information from the CAN controller can be programmed to behave differently than it is default to do in this project. Once again, if more testing equipment would have been able, the setup for a true CAN network would have made this project much more adaptable in terms of development towards real issues and with a real CAN bus and not just an emulator. The digital interface will receive any messages regardless if it is in extended or standard formatting, it triggers at the SOF bit and start the sampling afterwards. 55

Conclusion and discussion 56 The analysis had the same behaviour regardless if the bus rate was 125 kbit/s, 1Mbit/sorinbetween,theresultswerewithinarangeof2percentage.Thiserror margin was mainly due to small interferences and because it was impossible to verify the analyser with the very same message that was sent on the CAN bus so obviously the results shouldn t be the same, this range of error proved the sensitivity of this product rather than errors in the analysis. 7.1.1 LCD screen Due to the time frame of the project and to the lack of guide-lines from the distributor there wasn t enough time to pursue the System 3- User interface objectives. 7.2 Project discussion The project was well planned and the planning has been a helpful tool during the development. The planning and writing process in the beginning of the project gave me enough knowledge to enter a development phase with sufficient confidence and lore. Ibelievethatwhatcouldhavebeenbetterinthisprojectistheorderingofthe necessary components. If the LCD screen would have arrived a few weeks earlier the development of the user-interface would have been more likely successful. However, as this was an extra feature for the tool and along the development I wasn t sure that I would get that far, the ordering was postponed. Obstacles along the project has mainly been software related and the development plattform(the computer, the FPGA breakout board, the signal conditioning network). I have been having computer problems with the signed driver routines that didn t work for the FPGA module and unexplainable bugs with the software development tool that has inhibited my development. This postponed my development phase by several days because focus was to get everything up and running.

Conclusion and discussion 57 I think it is really hard to accomplish better results and smarter product without a real development environment including testing objects, expertise of the area and in particular a development team. To continue this project the testing objects and in-house knowledge of the requirements have to be higher and available at place. 7.3 Future development To adapt the analyser to the LCD screen would be the next step in the development process of this analyser. As well as developing a completely handheld device, however, this require a new power management solution, that in turn requires a new developed interface board. I would have liked to develop a way to diagnose breaks in the line and where it might be. The solution made in this project can only use the digital information from the node in terms of identification. 7.4 Ethical and social aspects Developing analyzers and finding traction in the market with them, enhances the probability to diagnose issues in a faster and more proper way, in this case for the serviceman of the CAN protocol troubleshooting. This, in turn, can create a dispatch for how their work is done. Servicemen might not need the same discussion between the personnel to diagnose the issue which can lead to a highly digitalized job that might not appeal every one in an employment procedure. Socially, electrical control instruments such as this analyzer will put people previous working with diagnosis in a rather idle position due that the logic and intelligence is in the unit. In turn, does this open up a market for personnel with a different qualification and knowledge. The knowledge of diagnosing errors is no longer needed, hence, a more neighbouring operator job is born in contrast to the potentially engineering qualified job before. However, the analyzer made in this project is not something that contributes the market with some new technique impossible to find in today s market. Hence, the relationship with this projects analyzer and the social effects in terms jobs is none.

Conclusion and discussion 58 Working with this type of developing technology that is sought to be an instrument that others can trust, restrains the developer to only work with theories learned in school or in the developers area of competence. Commonly this is known as the engineering ethic, which is a part of the applied ethics as a philosophical background. This project will not make such affection due to it will be used as an in-house project at the company developed at.

Bibliography [1] CAN specification : CAN specification by Robert BOSCH GmbH. http://esd.cs.ucr.edu/webres/can20.pdf,read:14-03-18. [2] CAN message : CAN message data frame from Micropchip AN713. http://ww1.microchip.com/downloads/en/appnotes/00713a.pdf,read:14-03-18. [3] Bit timing : Bit timing illustration. http://en.wikipedia.org/wiki/file:can_bit_timing.png,read: 14-03- 18. [4] Bryman, A. & Bell, E 2003, Business Research Methods. NY:Oxford University Press Inc, New York. [5] Jose Runo et. al Fault-Tolerant Broadcasts in CAN, Proceedings of the 28th International Symposium on Fault-Tolerant Computing Systems, Munich, Germany, June 1998, pp. 150-159. [6] Justesen, L. & Mik-Meyer, N 2011, Kvalitativa Metoder: Från vetenskap till praktik.studentlitteratur,lund. [7] CANwatch http://www.ems-wuensche.com/product/datasheet/html/ can-physical-layer-analyzer-error-diagnostics-canwatch.html Read: 14-03-18. [8] CAN-bus tester 2 http://www.gemac-chemnitz.de/en/products/ can-diagnostic-systems/can-bus-tester Read: 14-04-15 [9] CAN bus analyzer http://www.microchip.com/developmenttools/ ProductDetails.aspx?PartNO=apgdt002 Read: 14-04-15 59

Bibliography 60 [10] CAN controller mcp2515 http://www.microchip.com/wwwproducts/ devices.aspx?ddocname=en010406 Read: 14-04-15 [11] Flashy-D KNJN http://www.knjn.com/docs/knjn%20flashy%20boards.pdf Read: 14-04-15 [12] Xylo-LM http://www.knjn.com/docs/knjn%20fx2%20fpga%20boards.pdf Read: 14-04-15 [13] Cypress-FX2 USB http://www.cypress.com/?id=193 Read: 14-04-15 [14] Spartan 3e FPGA http://www.xilinx.com/support/documentation/data_ sheets/ds312.pdf Read: 14-04-15 [15] CANUSB module http://elmicro.com/files/lawicel/canusb_manual.pdf Read: 14-04-18