Vehicle Network Gateway (VNG)

Vehicle Network Gateway (VNG) (With emphasis on the j1850 interface) Fetah Basic (Spencer Volmar and Marc Oliver Co-Workers)

Abstract The Vehicle Network Gateway or VNG (pronounced ving ) is a small embedded microcontroller system that is utilized by a host computer as an interface to the different types of in-vehicle networks that are integrated on today s electronic engines. The Vehicle Network Gateway multiplexes SAE J1708, J1939, and J1850 vehicle networks on a single asynchronous serial channel to reduce the hardware overhead of a host system. A simple and easy to use interface eliminates the complexities of dealing with each protocol and their timing constraints. Below is a basic description of the J1708, J1939 and J1850 protocols. A complete description can be found in the SAE J1708, SAE J1939 and SAE J1850 publications found at http://www.sae.org. The VNG is envisioned for the big and ever growing OBD (On-Board Diagnostics) market that encompasses both the private and commercial sector of vehicles from compact cars to freightliners. The VNG interfaces to the OBD through the Engine/Electronic Control Unit (ECU). On- Board Diagnostics are used to communicate to a vehicles engine, transmission, brakes and other electronic components and monitor there performance. These standards and protocols have been regulated by the US government and they have been required by federal law since 1996 for passenger vehicles and even earlier for medium to heavy duty vehicles. The J1708 and J1939 protocols are for medium to heavy duty vehicles while the J1850 is for passenger cars. OBD is most commonly associated with car mechanics that use OBD technology to diagnose engine troubles. But the often forgotten sector of this industry is the fleet management market. This enormous market is comprised of Fleet Companies, Countless Trucking Companies, First Responders (e.g., Ambulance, Police,

etc), etc. These OBD capabilities are usually integrated in some sort of fleet management system that trucking companies use to monitor their drivers. The common measurements utilized by the Trucking Companies are: odometer, fuel spent, RPM, brakes, engine idle, engine time (time engine has been running) and some other similar driving, on duty, resting or off duty. This is used to regulate the driver s driving time and resting time to help prevent accidents from fatigue, and help trucking companies with the pay role. 1. General (For Block Diagram and Data Flow Diagram see Diagram 1 and Diagram 2 respectfully) measurements. These companies use the engine measurements provided by the OBD along with the fleet management systems to find out if the drivers are speeding, hard braking, over idling, over RPM, etc. They also monitor when the truck is moving, when it is stopped, when it is idling, the miles traveled, miles traveled per gallon, etc. These measurements are very important in compiling the Hours of Service (HOS) reports for the drivers required by federal law, and also figuring out the fuel tax reports for each state traveled through also required by federal law. HOS is the driver s weekly report on how long they have been

Diagram 1. VNG Block Diagram Diagram 2. VNG Data Flow (Red my Responsibility)

1.1 The SAE J1708 Protocol J1708 protocols support communication The one character MID field ranges from 0 to 255. A MID value in the field is a unique among devices installed on a transit vehicle identifier. It pertains to a device or (e.g., bus, truck). The physical connection of SAE J1708 Protocol is a modification of the ISO EIA/RS 485 standard for electrical characteristics of generators and receivers for use in balanced digital multipoint systems. It defines a small entity transmitted on a physical communications channel as a character of 10 bits. The format of the character is: transmitter and indicates the characteristics of the data following the MID value. MID values ranging between 128 and 255 are reserved by SAE J1587 for devices or components which may be installed in a bus or other heavy-duty vehicle. Data characters convey the meaning of a message that is embedded from higher layers. They conform to the definition of a character structure described in Figure 2. SAE J1708 does not impose any modifications or constraints on In addition to this character structure, J1708 also defines messages. A message consists of Message Identification (MID) character, a set of data characters, and a checksum (see Figure 1). the data characters transferred during data transmission. The checksum is a specific character generated from the two s complement of the sum of the MID value and the data characters for a message. It is used to verify error-free transmission. Each message in SAE J1708 is limited to 21 Figure 1. Message Structure in SAE J1708 characters including MID and checksum. This means that an application cannot

generate a message, which contains more device has gained control of the network, the than 19 characters. Further, messages transmission of the character stream is in an assigned by different MID values have different message priorities. These priorities represent different levels of importance based on transmitter categories. J1708 compliant-components are allowed to access the vehicle network simultaneously. This causes network contention or conflicts. In order to solve this problem, J1708 assigns a delay that determines the time when the device may re-access the network. The delay is based on the priority of the message content and device. Clearly, the communications configuration depicted by the SAE J1708 protocol is a peer-to-peer (or balanced) communications configuration. Under this configuration, devices attempt to transmit whenever they have a message to send; the protocol employs a contention mechanism to determine which device is allowed to send if two or more devices attempt to send simultaneously. Once a asynchronous mode. The start and stop bits control the transmission process. 1.1.1 The SAE J1587 Protocol SAE J1587 protocol is an extension of SAE J1708, which defines data and message identifiers. It expands SAE J1708 to handle messages created and used by components in a heavy-duty vehicle like class 8 trucks. The messages defined in SAE J1587 include: 1. Vehicle and component information which pertains to the operational status and performance of the vehicle 2. Routing and scheduling information which relates to the planned or actual route of the vehicle, current vehicle location, and estimated time of arrival 3. Driver information which relates to driver activity 4. Freight information that pertains to freight status and billing activities.

specified for connection management and Currently, the SAE J1587 protocol is limited to the formats for basic vehicle and component identifiers, and performance data. The SAE J1587 functions on the data link layer as the addressing or routing service. Instead of using the term data characters, it organizes an address by parameters. A parameter consists of a Parameter Identification (PID) character and a series of data characters (see Figure 2). Currently, data transfer. The connection management includes connection requesting and closing, message acknowledgments, and flow control. The data transfer includes operations used for transferring user-defined (proprietary control) data. SAE J1587 protocol can act as an application-level protocol, however application-level messages (or protocol data units) that can be passed down to the data link layer to form parameters are not SAE J1587 uses 511 parameters to specify defined. In addition, application-level various activities associated with a heavyduty vehicle. network services used to create and map the messages into lower level protocols are also not clearly defined. Figure 2. Message Structure in SAE J1587 The SAE J1587 protocol acts not only as a protocol on the data link layer but also as network services on the transport layer. It incorporates a set of the transport-level services and organizes them by two parameters. These two parameters are 1.2 The SAE J1939 Protocol J1939 is a high speed communications network designed to support real-time closed loop control functions between Electronic Control Units (ECU s) physically distributed throughout the vehicle. J1939 is capable of performing all of the functions of

J1708/J1587 as well as the control system support. J1939 uses the CAN protocol which permits any ECU to transmit a message on the network when the bus is idle. Every message contains an identifier that defines the message priority, who sent it, and what data is contained within it. Collisions are avoided due to the arbitration process that occurs while the identifier is transmitted (using a non-destructive arbitration scheme). Such a scheme assures that the highest priority message will be transmitted on the bus first, even if multiple ECU s are attempting to transmit at the same time. The J1939 protocol supports only the CAN 2.0B 29 bit identifier/arbitration field. J1939 messages are broken up into Protocol Data Units (PDU s) which can be transmitted onto the CAN bus. Each PDU contains information about message priority, type, and content. Figure 1 shows the three required fields of a J1939 PDU. Figure 1. PDU Structure in SAE J1939 The priority field is used by the CAN controller chip and CAN protocol. This field is not used by the J1939 protocol. The PGN (Parameter Group Number) uniquely identifies each parameter group. This field is similar to the J1708 MID/PID fields. This number uniquely identifies the type of message and type of data that is being transmitted. There are five message types currently supported by the J1939 protocol. These types are: Commands, Requests, Broadcasts, Acknowledgment, and Group Functions. More information about the specific PGN assignments can be obtained in Appendix A of the SAE J1939 documentation. The source address field of the PDU contains the address of the ECU transmitting the message. For a given network, every address must be unique (254 available).

Two different ECUs cannot use the same address at the same time. The PGNs are independent of the Source Address, thus any ECU can transmit any message. Each J1939 message is limited to 1785 data bytes. Messages greater than eight bytes in length are too large to fit into a single CAN data frame. They must therefore be broken into several smaller packets, and those packets transmitted in separate message transmitted correctly. Messages are received from the CAN bus by waiting for the CAN controller to send an interrupt signifying that it has received a message and then reading the message from the CAN controller s registers. The CAN controller ensures that messages are transmitted according to the message priority and at the specified rate of the network. 1.3 The SAE J1850 Protocol frames. At the destination end, the The SAE J1850 On-Board Diagnostics individual message frames must be received, parsed, and the original message reassembled from the received packets. The Transport Protocol Message is used to transmit these multiple packet messages. Transmitting and Receiving messages is accomplished with the help of an integrated CAN controller. Messages are transmitted on the CAN bus by writing the appropriate information into the registers of the CAN controller and waiting for an interrupt response signifying that the message was standard used in On and Off-Road vehicles is an Open Architecture protocol that is low cost, intended for masterless bus control, and it is a single level bus topology. J1850 has two main operation methods, Pulse Width Modulation (PWM) at 41.6 Kb/s, and a Variable Pulse Width (VPW) at 10.4 Kb/s approach. The VNG will support both approaches. J1850 has three main classifications, A, B, C class. The performance or data-rate increases respectfully for each class. VNG will

primarily be utilizing the B class. The B class usually supports intermodule, non-real time control and communication. In class B the high speed PWM uses two wire differential approach and the 10.4 Kb/s VPW uses single wire approach. VPW supports General Motors (GM) and Chrysler, while PWM supports Ford. J1850 is an intermodule data communication network for sharing information passed in frames between all vehicle electronic components that are connected on the J1850 bus. Communication of digital signals between these electronic components can be achieved using multiplexing. The two types of multiplexing are frequency division and time division. Frequency division sends two or more frames at the same time on a single channel. Time division sends two or more signals with fixed or variable time delays or buffers in-between, also on a single channel. to all network nodes to access the network. Because in J1850 the transmitting node broadcasts its message, all the other nodes see the message including the transmitting node itself. Because of its asynchronous nature some kind of arbitration scheme needs to be in place to offer a non-colliding environment that supports the peer-to-peer equal access protocol. Before a node transmits a frame it first listens to the bus for some pre set amount of time. If the bus is not busy then the message is transmitted, otherwise if the bus is busy transmitting another message then the listing node waits for the current message to finish transmitting before it sends its. Collision Resolution allows multiple transmitting nodes to talk at the same time, and it resolves the issue of who controls the bus by utilizing a message prioritization scheme. Checking is done using a bit-by-bit arbitration. J1850 is an asynchronous, masterless, peerto-peer protocol that gives equal opportunity

Beginning of every frame start with a pre-set high potential nominal period of 200us called the Start of Frame (SOF). This is followed by bit symbols representing data bytes. Anywhere between one byte to eleven bytes can be transmitted. The field following the SOF is the Header Field. The HF can either be one or three bytes in length. HF contains critical information about what a receiving node should expect in the proceeding frame, such as how many bytes are in the HF or how many data bytes the frame contains. For more information on the header byte bit definition, a bit by bit break down of the header field and the meaning refer to the SAE J1850 manual. The Data Field consists of ones and zeros. A passive 1-bit symbol is 128us long low potential, and a dominate 1-bit symbol is 64us long high potential. The zero bit symbol is the opposite, passive is 64us long low potential and dominate is 128us long high potential. Only one transition is required per bit. At the end of the data field is the CRC (or Cyclical Redundancy Check) byte. The CRC divides the entire message excluding the SOF, by a special polynomial. The 1 s complement result of the polynomial is appended to the frame after the data field. The receiving nodes do a similar polynomial calculation to the received frame and if no errors occurred the result will always be the same (C4 in hex). After the CRC byte, comes the End of Data (EOD) which is a 200us low potential. The receiving nodes after this symbol can immediately respond with an In-Frame Response (IFR) message which is a form of error handling that J1850 supports. Otherwise if no IFR is needed by the receiver then the EOD extends into an End of Frame (EOF) symbol. These to combined make the EOF which is 280us long low potential. There are much more detailed explanations, tables and definitions of the J1850 protocol in the SAE J1850 manual.

2. Tasks/Interface/Parts 2.1 Tasks components that will be needed to make the project a success. Most all of my tasks are going to involve coding C and Assembly (Maybe). I estimate ninety five percent of coding will be done in C and zero to five percent will be done in assembly. Other tasks will involve learning the protocols. Finally my last task will be integrating the J1850 capability on to the VNG board. 2.2 Interface The interfacing will be between the vehicle Electronic Control Unit and the microcontroller (J1850, VPW, PWM). In that interface there will be an interface between the different processes and there protocols (RS232, RS422 or 5v buffered). Semaphores will be the major part of task scheduling and flow control. 2.3 Parts The most important and central part of the project is the microcontroller. The Motorola MC9S12DJ256 offers the necessary Its multiple network modules support CAN/J1850-based ECU environment by enabling highly efficient communications

between different network buses. This microcontroller will be running on the ucos-ii (microcos-ii) operating system. This is a real time operating system. The Real-Time Kernel is a highly portable, ROMable, very scalable, preemptive realtime, multitasking kernel (RTOS) for microprocessors and microcontrollers. µc/os-ii can manage up to 63 application tasks and provides the following services: Semaphores Mutual Exclusion Semaphores (to reduce priority inversions) (added in V2.04) Event Flags (added in V2.51) Message Mailboxes Message Queues Task Management (Create, Delete, Change Priority, Suspend/Resume etc.) Fixed Sized Memory Block management Time Management Also the ucos-ii has a great real time compiler and debugger, meaning when you step through the code you are stepping through the physical chip in real time. Besides these two integral components everything else is taken care of since my two co-workers have already done the J1708 and J1939 long time ago. The VNG board is almost finished with the exception of my part the J1850 capability. I may need few more small electronic parts (caps, resisters, etc) but nothing big. I have all the parts needed for this project to be completed. 3. Testing/Demo 3.1 Testing Testing will be done through the process of writing and debugging the code. Testing will also be done by simulating ECU input and checking for corresponding output. Output data will be captured using the Dearborn, a device that captures the output data and can play it back in a meaningful structure. 3.2 Demo

The Demo will be done by simulating Vehicle ECU output, which will be hooked up to the VNG. If time permits I will write an application in C# or C++ to take what appears like meaningless data to the average observer, and display it in a meaningful way such as a RPM gage, or Odometer or Speedometer found in a car. So for example when the gas pedal is being pressed the RPM gage mirrors this by increasing or decreasing accordingly. 4. Schedule/Plans/BOM 4.1 Schedule 4.1.1 Summer Research the subject and familiarize myself with the different protocols and standards. Have all the material needed for the project. 4.1.2 September Begin writing the procedures and processes for J1850. 4.1.3 October Finish up writing the code, interface the 4.1.4 November Tie up any looses ends left over. Finalize all the components. Test the finished product and prepare for the Demo. Finish the Report. 4.1.5 December Everything has tested fine. The project is ready for demonstration. 4.2 Plans Have project assessment get together every week. Review the progress of the project. Adjust according to the progress. 4.3 BOM All the parts are present, ready and available. 5. Conclusion I am looking forward to doing this project and completing my undergraduate capstone. I believe that having the precedence of the already completed J1708 and J1939 protocols will help me and aid me in adding the J1850 capability to the VNG board. 6. References code components. Finish the board.

[1] SAE On-Board Diagnostics for Light and Medium Duty Vehicles Standards manual [2] www.sae.org [3] http://www.ucos-ii.com/contents /products/ucos-ii/benefits.html [4] http://www.freescale.com/files/ microcontrollers/doc/prod_breif/ MC9S12DJ256FS.pdf