SAE TECHNICAL
`PAPER SERIES
`
`930005
`
`A Gateway for CAN Specification 2.0
`Non-Passive Devices
`
`Craig Szydlowski
`Intel Corp.
`
`Reprinted from:
`Multiplex Technology Applications in
`Vehicle Electrical Systems (SP-954)
`
`The Engineering Society
`For Advancing Mobility
`Land Sea Air and Space ®
`I N T E R N A T I O N A L
`
`International Congress and Exposition
`Detroit, Michigan
`March 1-5, 1993
`
`400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel:(412)776-4841 Fax:(412)776-5760
`
`Petitioner's Exhibit 1009
`Page 1 of 11
`
`

`

`The appearance of the ISSN code at the bottom of this page indicates SAE’s consent
`that copies of the paper may be made for personal or internal use of specific clients.
`This consent is given on the condition, however, that the copier pay a $5.00 per article
`copy fee through the Copyright Clearance Center, Inc. Operations Center, 27
`Congress St., Salem, MA 01970 for copying beyond that permitted by Sections 107
`or 108 of the U.S. Copyright Law. This consent does not extend to other kinds of
`copying such as copying for general distribution, for advertising or promotional
`purposes, for creating new collective works, or for resale.
`
`SAE routinely stocks printed papers for a period of three years following date
`of publication. Direct your orders to SAE Customer Sales and Satisfaction Depart-
`ment.
`
`Quantity reprint rates can be obtained from the Customer Sales and Satisfaction
`Department.
`
`To request permission to reprint a technical paper or permission to use copyrighted
`SAE publications in other works, contact the SAE Publications Group.
`
`GLOBAL MOBILITY DATABASE
`All SAE papers, standards, and selected
`books are abstracted and indexed in the
`SAE Global Mobility Database.
`
`No part of this publication may by reproduced in any form, in an electronic retrieval
`system or otherwise, without the prior written permission of the publisher.
`
`ISSN 0148-7191
`Copyright 1993 Society of Automotive Engineers, Inc.
`
`Positions and opinions advanced in this paper are those of the author(s) and not
`necessarily those of SAE. The author is solely responsible for the content of the
`paper. A process is available by which discussions will be printed with the paper if
`it is published in SAE transactions. For permission to publish this paper in full or in
`part, contact the SAE Publications Group.
`
`Persons wishing to submit papers to be considered for presentation or publication
`through SAE should send the manuscript or a 300 word abstract of a proposed
`manuscript to: Secretary, Engineering Activity Board, SAE.
`
`Printed in USA
`
`Petitioner's Exhibit 1009
`Page 2 of 11
`
`

`

`A Gateway for CAN Specification 2.0
`Non-Passive Devices
`
`930005
`
`Craig Szydlowski
`Intel Corp.
`
`ABSTRACT
`
`GATEWAY EXAMPLE
`
`The gateway considered in this paper is shown in
`figure 1. The microcontroller in the center, labeled
`‘GATEWAY’, translates messages between the networks
`above and below. The network labelled ‘standard’
`transmits CAN 1.2 standard messages (11 -bit identifier)
`while the network labeled ‘standard/extended’ transmits
`CAN 2.0 both standard and extended messages (11- and
`29-bit identifiers). The standard messages for the CAN
`1.2 and CAN 2.0 networks are bit-wise and electrically
`identical.
`
`The Controller Area Network (CAN) protocol,
`developed by ROBERT BOSCH GmbH, offers a
`comprehensive solution to managing communication
`between multiple CPUs. In September 1991, the CAN
`protocol was revised (CAN Specification 2.0) to add an
`extended message format that increases the number of
`permitted message identifiers. The CAN protocol now
`supports 11- and 29-bit message identifiers allowing
`standard and extended formats, respectively.
`
`CAN Specification 2.0 implements a new message bit,
`the identifier extension bit (IDE bit) which allows CAN
`devices to differentiate standard and extended formats.
`However, most existing CAN implementations are based
`on the previous CAN protocol specification and will not
`recognize extended format messages and will respond
`with an error message. These chips are CAN
`Specification 2.0 non-passive.
`
`Until semiconductor makers develop a variety of chips
`to implement 29-bit message identifiers, CAN users may
`require a gateway to interconnect networks using 29-bit
`message identifiers to existing networks that only use
`CAN 1.2 11-bit message identifiers. In this context, a
`gateway is a system that translates messages in one
`protocol to another and vice versa.
`
`A gateway between two networks is typically designed
`to minimize transmission latency, to minimize lost
`messages (overruns) and to manage bus error issues.
`Following a brief description of the CAN message format,
`general gateway design considerations and performance
`estimates will be addressed. In addition, a method to
`send remote frames across the gateway is discussed.
`
`29
`
`Figure 1: Gateway Example
`
`Petitioner's Exhibit 1009
`Page 3 of 11
`
`

`

`Figure 2: Standard and Extended Formats
`
`The gateway microcontroller communicates with two
`CAN chips, one from each network. Examples of gateway
`functions are:
`
`a) bridging standard messages without translation.
`b) bridging standard and extended messages with
`message identifier translation.
`c) managing re-transmission issues when errors occur.
`
`CAN PROTOCOL MESSAGE FORMATS
`
`The CAN protocol supports two message formats
`which differ in the length of the message identifier field.
`Messages using 11 message identifier bits are called
`standard and those using 29 message identifier bits are
`called extended. Both standard and extended message
`formats support four frame types:
`
`1) Data - carries data
`2) Remote - sent when a node requests data from
`another node
`3) Error - sent when a node detects a message error
`4) Overload - sent when a node requires extra delay
`
`The following describes the standard and extended
`message formats for data and remote frames shown in
`figure 2.
`
`SOF:
`
`Arbitration:
`
`Start Of Frame (dominant bit) marks the
`beginning of a data/remote frame.
`
`One or two fields which contain the
`message identifier bits. The standard
`format has one 11-bit field and the
`extended format has two fields, 11- and
`18-bits wide.
`
`RTR:
`
`SRR:
`
`IDE:
`
`Remote Transmission Request bit is
`dominant for data frames and recessive
`for remote frames. This bit is in the
`arbitration field.
`
`Substitute Remote Request bit is used in
`extended messages and is recessive.
`This bit is a substitute for the RTR bit in
`the standard format. This bit is in the
`arbitration field of the extended format.
`
`Identifier Extension bit is dominant for
`standard format and recessive for
`extended format. This bit is in the
`arbitration field of the extended format
`and in the control field of the standard
`format.
`
`Control Field: Reserved bits r0 and r1 are sent as
`dominant bits. The 4-bit Data Length
`Code (DLC) indicates the number of
`bytes in the data field.
`
`Data Field:
`
`CRC Field:
`
`ACK Field:
`
`The data bytes are located in the data
`frame (0-8 bytes). A remote frame
`contains zero data bytes.
`
`This field is composed of a 15-bit
`Cyclical Redundancy Code error code
`and a recessive CRC delimiter bit.
`
`Acknowledge is a dominant bit sent by
`nodes receiving the data/remote frame
`and is followed by a recessive ACK
`delimiter bit.
`
`30
`
`End of Frame: Seven recessive bits ending the frame.
`
`Petitioner's Exhibit 1009
`Page 4 of 11
`
`

`

`INT:
`
`Intermission is the three recessive bits
`which separate data and remote frames.
`
`The minimum message lengths of standard and
`extended message formats are summarized below for
`data and remote frames. These bit counts will be used to
`assess gateway message transmission latency and
`overrun susceptibility. The actual lengths of these
`messages may differ because 'stuff' bits are added to the
`message. Stuff bits assist synchronization by adding
`transitions to the message. A stuff bit is inserted in the bit
`stream after five consecutive-equal value bits are
`transmitted; the stuff bit is the opposite polarity of the five
`consecutive bits. All message fields are stuffed except the
`CRC delimiter, the ACK field and the End of Frame.
`
`Standard Format
`
`of the receiving CAN chip. Next, the gateway executes
`logical instructions to translate the message. Then the
`gateway executes external writes to the CAN device on
`the second network to program a transmission. Therefore,
`the microcontroller executes external read and write
`operations and translates message identifiers.
`
`READ AND WRITE OPERATIONS - The time
`required to execute read and write operations is
`dependent upon the interface-timing characteristics of the
`gateway microcontroller and the CAN chips. Figure 3
`shows a microcontroller interfaced to two CAN devices.
`This configuration uses a 16-bit address/data bus which
`doubles the communication throughput between the
`microcontroller and the CAN chips. The CAN chips drive
`independent interrupt lines to the microcontroller allowing
`the interrupting CAN device to be easily identified.
`
`Figure 3: Hardware Example
`
`CAN CHIP MESSAGE CONFIGURATION - The CAN
`chips must be configured to receive and transmit
`messages. Typically, CAN chips support 2 to 15 message
`objects that are configured to receive or transmit.
`Message objects consist of RAM bytes which store a
`message identifier, data bytes and control bytes. To
`receive messages more reliably, a CAN chip must be
`able to receive an incoming message while it is still
`processing a previously received message. This may be
`accomplished 1) by using a buffered receive message
`object or 2) by implementing a buffered receive using two
`receive message objects that are alternately validated
`and invalidated (figure 4). It is assumed that all receive
`message objects employ acceptance mask filtering which
`allows all relevant CAN bus messages to be accepted by
`a single buffered receive message object. Without
`acceptance filtering, a prohibitive number of receive
`31 message objects would be required to receive all
`
`11
`1
`
`1
`1
`4
`
`number of bits
`1
`12
`
`6
`
`0-64
`16
`2
`7
`
`44-108 bits
`
`Extended Format
`
`number of bits
`1
`32
`
`6
`
`0-64
`16
`
`27
`
`64-128 bits
`
`29
`
`111 24
`
`Message Field
`SOF
`Arbitration Field
`identifier
`RTR
`Control Field
`IDE
`r0
`DLC
`Data Field
`CRC Field
`ACK Field
`End of Frame
`
`Total
`
`Message Field
`SOF
`Arbitration Field
`identifier
`SRR
`IDE
`RTR
`Control Field
`r1,r0
`DLC
`Data Field
`CRC Field
`ACK Field
`End of Frame
`
`Total
`
`HARDWARE CONFIGURATION
`
`it is assumed both CAN
`For this analysis,
`implementations are stand-alone chips (figure 3). The
`gateway microcontroller reads and writes to the CAN
`chips as if they were smart RAMs. When a message is
`received, the gateway executes external read operations
`
`Petitioner's Exhibit 1009
`Page 5 of 11
`
`

`

`necessary messages. A receive message object must be
`‘valid’ before the last bit of the incoming message is
`received to capture the message.
`
`Figure 4: Receive Buffer
`
`After using one or two message objects per CAN chip
`to receive, the remaining message objects should be
`used to handle remote frames and to transmit messages.
`The gateway must be prepared to store multiple transmit
`messages that may be waiting for CAN bus access
`(figure 5). The number of transmit message objects
`required is dependent on the gateway message traffic
`and the ability of these messages to get on the second
`network. Overall bus loading and the priority of the
`messages crossing the gateway strongly influence the
`number of required transmit message objects.
`
`One method to manage transmit message objects is
`to implement a stack which stores unused message
`objects numbers. When a message transmission is
`needed, a message object number is "popped" from the
`stack. Similarly, when a message transmission is
`completed, its message object number is "pushed" on the
`stack. The gateway may need to manage the order of
`transmit message objects so low priority messages are
`not scheduled to transmit first. The Intel 82527, for
`example, uses the message that is stored in the lowest
`numbered message object for arbitration, regardless of
`whether the other message objects on the chip have
`higher arbitration priority. Therefore, a low priority
`message in message object #1 may delay the
`transmission of the other messages.
`
`GATEWAY MESSAGE TRAFFIC
`
`A gateway must be prepared to translate messages
`from one protocol to the other, and vice versa. A gateway
`for the CAN protocol must be concerned with two of the
`four CAN protocol frame types: data and remote. The
`other two frame types, overrun and error, are handled in
`hardware by the gateway’s CAN chip on the respective
`network. Therefore, the gateway (microcontroller) has no
`added responsibilities. However, the gateway must be
`prepared to act when too many errors occur on either
`network as indicated by warning or busoff status bits. In
`this case, the gateway investigates the bus-status like
`other network nodes do.
`
`DATA FRAMES
`
`The gateway is typically designed to minimize
`transmission latency and to minimize lost messages
`(overruns). Analyzing latency and message overruns with
`respect to data frames must consider the two differences
`in data frames. First, data frames have between zero and
`eight data bytes. Second, the extended format has 20
`more arbitration and control bits than the standard format.
`
`Another issue to be considered is the effect of stuff
`bits. Stuff bits increase transmission latency by increasing
`the duration of a message transmission, a delay seen by
`messages waiting for access to the CAN bus. Stuff bits
`may actually help decrease the probability for message
`overruns by providing additional time for the gateway to
`manage message translation and message object
`programming. Since the number of stuff bits is dependent
`upon the bit patterns of message identifiers, data bytes
`and CRC codes, it is difficult to estimate their effect
`deterministically. Perhaps it is best to estimate an
`average number of stuff bits per message and the
`resulting transmission time.
`
`Figure 5: Transmit Message Objects
`
`TRANSMISSION LATENCY - Message transmission
`latency is the time between a completed message
`transmission on one network to its completed
`transmission on another network. The latency may be
`divided into three parts: gateway access, gateway
`
`32
`
`Petitioner's Exhibit 1009
`Page 6 of 11
`
`

`

`processing and bus transmission delay. Gateway access
`is the time a message must wait to be serviced by the
`gateway microcontroller. The worst case occurs when two
`messages are received simultaneously on both networks
`and one message must wait until the other has been
`processed. Gateway processing refers to the time to read
`the receive message from the first network, translate the
`message, and configure the message for transmission on
`the second network as shown in figure 6. The bus
`transmission delay is the time required to gain access to
`the CAN bus and the following message transmission
`time. The transmission latency will vary based on the time
`required for the message to win arbitration on the second
`network. Low priority messages, will of course, have
`longer transmission latencies than higher priority
`messages.
`
`Figure 6: Gateway Processing
`
`MESSAGE IDENTIFIER TRANSLATION -
`CAN 1.2 and CAN 2.0 network gateways can be used in
`two ways. The simplest implementation is to transfer
`standard messages between the two networks without
`message identifier translation. This performs the task on
`interconnecting CAN 1.2 and CAN 2.0 networks and
`allowing standard message to be shared. A second
`implementation may require message identifiers to be
`translated. Translation is required when messages have
`independent message identifiers on both networks. For
`example, an "engine temperature message" has a
`
`33
`
`dedicated 11-bit standard message identifier on the CAN
`1.2 network and a dedicated 29-bit message identifiers on
`the CAN 2.0 network. Translating between these two
`message identifiers may be implemented algorithmically
`or by using a look-up table. For this analysis, it is
`assumed the message identifier requires no translation
`and only the 11-bit standard identifier messages are
`transmitted across the gateway.
`
`GATEWAY PROCESSING ANALYSIS - This section
`is an analysis of the minimum time required by the
`gateway to respond to a receive message from one
`network and to program a corresponding transmission on
`a second network. This latency analysis assumes the
`gateway microcontroller to be an Intel 16-bit 80C196 chip
`interfaced to an Intel 82527 operating at 16 MHz, using
`three wait-states and a 16-bit address/data bus. This
`assumption results in the execution of read and write
`operations in 1.875uS. The 80C196 responds to
`interrupts in 16 states following the execution of the
`current instruction or about 2.5uS.
`
`The flowchart in figure 7 is an example of the
`minimum number of steps required for a gateway
`processing. The purpose of the following section is to
`estimate the time required to implement the flowchart
`program flow. This calculated time represents the bare
`minimum gateway execution time.
`
`Flowchart 7 is referenced for the following gateway
`processing time estimate.
`
`Flowchart block:
`A message is received by one of the CAN chips.
`A)
`This CAN chip sends an interrupt to the gateway
`after the transmission of the last End of Frame bit
`(1.5uS)
`
`B)
`
`C)
`
`D)
`
`D1)
`
`E)
`
`The microcontroller responds to the interrupt
`request, enters the interrupt service routine
`(3.75uS).
`
`The microcontroller reads the CAN interrupt
`register to get the interrupt pointer (1.875uS).
`
`The microcontroller first determines whether the
`interrupt is from the error status register
`indicating a busoff or warning flag is set
`(1.375uS).
`
`If a busoff or error warning flag is set, the
`gateway should execute an error recovery
`sequence to determine the error source or to
`execute a software reset on get back on the bus.
`
`Next, the microcontroller determines whether the
`interrupt was initiated by a reception or
`transmission.
`
`Petitioner's Exhibit 1009
`Page 7 of 11
`
`

`

`E1)
`
`F)
`
`G)
`
`If the interrupt is the result of a successful
`transmission, the microcontroller responds by
`invalidating the transmit message object and
`perhaps stacking the message object number as
`described previously.
`
`In response to a successful reception, the
`microcontroller executes the bulk of the gateway
`tasks. If a buffered receive message is
`unavailable, the microcontroller should alternate
`valid receive message objects so receptions may
`continue without over-writing the message
`currently in-process. A transmit message object
`must be configured, so the microcontroller must
`find an currently unused transmit message object
`using a stack operation (0.875uS).
`
`The message configuration begins by transferring
`the data bytes from the receiving CAN chip to the
`transmitter. This data transfer may move all eight
`data bytes regardless of the data length code
`value or employ a loop which uses the data
`length code value. This decision to use a loop
`depends on the instruction decrement and jump
`instruction overhead. This analysis assumes all
`eight bytes are always transferred and four reads
`of the receiver (2-byte) and four writes of the
`transmitter are required to transfer the data
`(15uS). The data length is transferred next. This
`is done by reading a receiver control byte
`(1.875uS), toggling a bit to change the message
`object from receive to transmit (0.625uS), and
`writing the byte to the transmitter (1.875uS).
`
`Figure 7: Gateway Flowchart
`
`34
`
`Petitioner's Exhibit 1009
`Page 8 of 11
`
`

`

`H)
`
`I)
`
`J)
`
`The message identifier is transferred next
`assuming an 11-bit identifier and no translation.
`This requires a read of the receiver and a write of
`the transmitter (3.75uS).
`
`The message object control registers are written
`to make the transmit message valid and to set
`the transmit request bit using a write (2-byte)
`instruction (1.875uS).
`
`After setting the transmit request bit, the CAN
`chip is ready to arbitrate and transmit on the
`CAN bus (1.75uS).
`
`The resulting gateway processing time from message
`re-transmission request is
`received to message
`approximately 40uS. This figure is used in the
`transmission latency calculation. The remaining
`operations (flowchart block K) of the interrupt service
`routine are reset the receive message interrupt pending
`bit and depart the interrupt service routine. The total
`interrupt service routine requires 45uS and figure 7 may
`be used to evaluate message overrun susceptibility.
`
`TRANSMISSION LATENCY - A rigorous analysis of
`transmission latency through of a gateway should
`examine best and worst case scenarios. A few sample
`calculations are shown to approximate bare-minimum
`latencies. These latency calculations assume a gateway
`processing time of 40uS as previously demonstrated. This
`processing time is, perhaps, the very shortest realizable
`time and more time may be needed for genuine
`applications. Other assumptions are:
`
`A) The number of stuff bits are estimated.
`B) A message has "immediate" gateway access
`or is required to "wait" for 40uS another
`message to undergo full gateway processing.
`C) CAN bus rates of 1MB/S and 250KB/S.
`D) The second network is idle and the message
`transmission occurs
`immediately.
`E) A 16-bit microcontroller/CAN chip interface.
`An 8-bit interface would add 18.75uS to the
`gateway processing time.
`
`DATA FRAME TRANSMISSION LATENCY
`
`stuff
`CAN data
`bus/S bytes bits
`
`total
`bits
`
`gateway
`access
`
`1MB
`1MB
`1MB
`1MB
`
`1
`1
`8
`8
`
`250KB 1
`250KB 1
`250KB 8
`250KB 8
`
`3
`3
`6
`6
`
`3
`3
`6
`6
`
`55
`55
`114
`114
`
`55
`55
`114
`114
`
`immediate
`wait
`immediate
`wait
`
`immediate
`wait
`immediate
`wait
`
`latency
`time
`
`95uS
`135uS
`154uS
`194uS
`
`260uS
`300uS
`496uS
`536uS
`
`MESSAGE OVERRUNS - A gateway should eliminate or
`minimize the occurrence of message overruns. A
`message overrun occurs when a CAN receive message
`object stores a second message before the first has been
`processed resulting in the corruption of the first message.
`The worst case for overruns is when both CAN chips
`receive messages at the same time. The gateway must
`make one receive message wait while it first processes
`the other receive message.
`
`Message overruns are most likely to occur when both
`CAN networks require back-to-back messages to be
`transferred across the gateway. In this case, two
`messages must be transferred across the gateway in the
`time required for a single message to be transmitted on
`the CAN bus plus three intermission bit times. For
`standard messages with 1 data byte and zero stuff bits,
`this time is 55 bit-times. For CAN buses operating at
`1MB/S, this means two messages must be processed in
`55uS; based on the processing time 40uS per message
`from the prior discussed, this does not appear feasible.
`For a 250KB/S bus, two messages must be processed in
`220uS and this is potentially realizable.
`
`Theoretically, buffered receive message objects do
`not reduce the possibility of message overruns when
`messages are transferred across the gateway at a
`continuous maximum rate. Practically, however, a
`buffered receive message object may allow two back-to-
`back messages to be processed without an overrun; a
`message overrun is deferred until three back-to-back
`messages are transmitted on the CAN bus.
`
`REMOTE FRAMES
`
`A remote frame is used by a node to request another
`node to transmit its data. The remote frame itself contains
`no data. When transmit message objects receive remote
`frames, they will send data after they win bus arbitration.
`
`For gateway applications, remote frames pose a very
`special problem. This problem is that most CAN
`implementation do not save the message identifier of the
`remote message. Unlike a receive message object which
`stores the incoming message identifier, the transmit
`message object responding to a remote frame does not
`store the remote message identifier. If acceptance filtering
`is used, the exact message identifier of the remote frame
`is unknown. Therefore, when the gateway receives a
`remote frame, it cannot readily configure a corresponding
`remote message on the second network.
`
`A way to resolve this remote frame message identifier
`issue is to require all remote frames that cross the
`gateway to be implemented instead with data frame
`referenced here as a ‘substitute remote frame’. This data
`frame should contain two bytes that store the correct
`remote frame message identifier. To simplify matters, this
`data frame should use a specially assigned message
`identifier which informs the gateway that the message is
`
`35
`
`Petitioner's Exhibit 1009
`Page 9 of 11
`
`

`

`a substitute remote frame. If the gateway receives a
`message with this specially assigned message identifier,
`the gateway configures a remote frame on the second
`network using the message identifier designated by the
`data bytes of the substitute remote frame.
`
`This substitute remote frame method is conducted as
`shown in figure 8. First, the message identifiers of
`incoming messages are checked against the specially
`assigned remote message identifier. When a match
`occurs, the gateway configures a remote message on the
`second network using the message identifier stored in the
`matched message. Next, a node on the second network
`should respond to the remote frame by sending a data
`frame. This data frame is handled no differently than any
`other data frame and is transferred to the originating
`network without special regard.
`
`The drawback of this substitute remote frame method
`is the gateway processing tasks increase because the
`message identifier of data frames must be checked
`against the specially assigned remote message identifier;
`this increases latency time. A second drawback is the use
`of data bytes to store message identifiers is inconsistent
`with the CAN protocol philosophy.
`
`TRANSMISSION LATENCY - The minimum
`transmission latency of a substitute remote message is
`two times the latency of a data frame plus the
`transmission time to send a remote frame on the bus.
`After the reception of a substitute remote frame, there is
`1) gateway processing, 2) a remote frame transmission
`(zero data bytes), 3) a data frame transmission in
`response to the remote frame, 4) a second gateway
`processing, and 5) a data frame transmission on the
`originating bus.
`
`Transmission latency examples are shown below. The
`"total bits" refers to the number of bits in the data frame
`which is requested by the remote frame. The gateway
`access time, in the worst case, could occur twice. This
`means that both data frame transfers across the gateway
`must wait for a full gateway access time. Therefore, the
`'wait’ gateway access assumption adds 80uS (2*40uS).
`
`SUBSTITUTE REMOTE FRAME
`TRANSMISSION LATENCY
`
`CAN data stuff
`bus/S bytes bits
`
`total
`bits
`
`gateway
`access
`
`1MB 1
`1MB 1
`1MB 8
`1MB 8
`
`
`
`250KB 1
`250KB 1
`250KB 8
`250KB 8
`
`3
`3
`6
`6
`
`3
`3
`6
`6
`
`55
`55
`114
`114
`
`55
`55
`114
`114
`
`immediate
`wait
`immediate
`wait
`
`immediate
`wait
`immediate
`wait
`
`latency
`time
`
`234uS
`314uS
`352uS
`432uS
`
`696uS
`776uS
`1.17mS
`1.25uS
`
`OVERRUN - The analysis of overruns is practically the
`same as for data frames except substitute remote frames
`only have two data bytes.
`
`GATEWAY MESSAGE HANDLING
`
`To minimize message overruns, message traffic
`across the gateway must be considered. There are two
`ways to manage gateway traffic. First, ensure both CAN
`buses have a transmission rate which allows the gateway
`to transfer two messages in the time required to transmit
`a single message on either bus (see the transmission
`latency section). A second way to manage message
`traffic is to use acceptance filtering to limit the rate that
`message are transferred across the gateway. The CAN
`chips connected to the gateway microcontroller are
`programmed to select a subset of the messages for
`transfer across the gateway using "acceptance masks". In
`this case, both CAN buses may run at 1MB/S as long as
`the message traffic across the gateway is contained to a
`manageable level. It was shown previously (transmission
`latency section) that transferring all messages across the
`gateway when both CAN buses are transmitting at 1 MB/S
`is a difficult task.
`
`36
`
`Figure 8: Substitute Remote Frame
`
`Petitioner's Exhibit 1009
`Page 10 of 11
`
`

`

`CONCLUSION
`
`Most existing CAN 1.2 chips will send error frames
`when CAN 2.0 chips extended frame messages are
`transmitted, because they are CAN 2.0 non-passive. To
`interconnect CAN 1.2 and CAN 2.0 networks together, a
`gateway may be employed1. A gateway should minimize
`transmission latency and lost messages (overruns). A
`simple gateway demonstrates the minimum latency of a
`CAN 1.2 to CAN 2.0 gateway ranges from 95uS to
`1.25mS. To reduce the risk of message overruns, the
`message traffic across the gateway must be limited to
`twice the message transmission time of either CAN bus.
`
`References:
`1. "CAN Specification Version 2.0", Robert Bosch GmbH,
`Postfach 50, D-7000 Stuttgart, 1991.
`2. Fred Phail, "Controller Area Network - An In-Vehicle
`Solution", SAE paper #880588, 1988.
`3. Fred Phail, "In-Vehicle Networking - Serial
`Communications Requirements and Directions", SAE
`paper #860390, 1986.
`4. Craig Szydlowski, "CAN Specification 2.0: Protocol and
`Implementations", SAE paper #921603, 1992.
`5. 82527 CAN Literature Packet, Intel literature phone
`number (1-800-346-3028), order number 272304-001.
`
`Endnote:
`1.
`The Intel 82527 serial communications controller
`implements many of the key gateway features
`discussed in this paper. The 82527 is able to
`interface to both standard and dual
`standard/extended networks. The Intel 82527
`supports the latest CAN 2.0 specification and
`manages both standard and extended format
`messages. The 82527 has 15 message objects
`including a buffered receive message object. Two
`acceptance filters provide added message
`handling flexibility. The 82527 interfaces to
`microcontrollers with 8- and 16-bit multiplexed
`address/data buses, non-multiplexed buses, or
`SPI compatible serial buses.
`
`37
`
`Petitioner's Exhibit 1009
`Page 11 of 11
`
`