iCC 2005
`
`CAN in Automation
`
`Comparison of CAN Gateway Modules for
`Automotive and Industrial Control Applications
`
`Jan Taube1,2, Florian Hartwich1, Helmut Beikirch2
`1Robert Bosch GmbH Reutlingen, 2University of Rostock
`
`Bus architectures with up to five independent CAN channels are used in today's auto-
`motive and industrial control systems. Caused by the rising numbers of sensors, actu-
`ators and electronic control units over the last years, modern control concepts demand
`devices supporting cross-linking of these channels. This interconnection is realized
`with a CAN gateway that connects several CAN buses between sub networks at differ-
`ent speeds.
`
`Current gateway implementations are based on one of two concepts. The one concept
`is an application-specific multi-channel CAN controller with shared message object
`memory. This concept is inflexible regarding the gateway structure, especially the
`number of CAN channels, but it enables the transfer of messages between the net-
`works without causing a high load on the host CPU. The other concept is a set of single
`channel CAN controllers served by a message handling software on the host CPU. This
`implementation is more flexible regarding the gateway structure, but the load on the
`CPU depends on the combined bus traffic of all connected CAN networks. Starting
`from these two solutions, a new concept has been developed, combining the advan-
`tages of a flexible structure with a low CPU load.
`
`In this paper, the three concepts are compared and advantages/disadvantages are
`shown. In addition, problems in the design of gateways are discussed.
`
`Introduction
`The increased complexity of automotive and
`industrial networks and the need for data
`transparency and information exchange
`within the overall system led to the introduc-
`tion of gateways.
`
`Theoretically, the term gateway is not quite
`correctly used in automotive applications. In
`the literature, the term „gateway” is used for
`a network node of a communication network
`equipped for interfacing with another network
`that uses different protocols. It may contain
`devices such as protocol
`translation, rate
`converters and signal translators to provide
`system interoperability.
`
`In that context, the term „bridge” is used to
`describe a device of a communication sys-
`tem that links or routes signals from one bus
`or network to another, to extend the distance
`span and the capacity of a single network. It
`does not modify packets or messages, it only
`reads them and forwards those with destina-
`tions not on the same segment of the net-
`work as the transmitter.
`
`In automotive and industrial control applica-
`tions,
`the term gateway is preferred even
`though the data is transferred between net-
`works using the same protocol, because
`these gateways perform more functions than
`the forwarding of messages.
`
`These functions [5] can/must be message fil-
`tering (to prevent
`the overload of a low-
`speed network when transferring messages
`from a high-speed network), message trans-
`fers with identifier translation, message inte-
`gration (combining parts of
`the data of
`several messages into a new message), and
`the synchronisation of
`time-triggered net-
`works (when implemented) to guarantee that
`the information is updated on time.
`
`In general, the gateway functionality could be
`implemented in software, as long as several
`CAN modules are available in the ECU. But a
`large amount of messages would cause a
`high load on the CPU, leaving less perform-
`ance for the ECU control applications until
`real-time operation can no longer be guaran-
`teed.
`
`06-1
`
`Petitioner's Exhibit 1015
`Page 1 of 8
`
`

`

`iCC 2005
`
`CAN in Automation
`
`tion and received message objects over the
`peripheral bus from one CAN module and
`then writes the same data over the periph-
`eral bus to some other CAN module(s). Con-
`current message transfer
`requests from
`different CAN channels are served sequen-
`tially.
`
`Tx
`Rx
`
`Tx
`Rx
`
`Tx
`Rx
`
`CAN Core
`
`Message
`RAM
`
`CAN Core
`
`Message
`RAM
`
`...
`
`CAN Core
`
`Message
`RAM
`
`CPU Interface
`
`CPU Interface
`
`CPU Interface
`
`CPU Peripheral Bus
`
`CPU
`
`Figure 1: Structure of discrete channel gateway
`modules
`
`The number of CAN channels connected to
`the CPU’s peripheral bus can easily be
`adapted to actual requirements, but a rising
`number of CAN channels will
`increase the
`CPU load even if the CAN bus-load remains
`unchanged.
`
`Complex Channel Gateway
`
`Tx
`
`Rx
`
`Tx
`
`Rx
`
`Tx
`
`Rx
`
`CAN 1
`
`CAN 2
`
`...
`
`CAN n
`
`Link
`Control
`
`Shared
`Message
`Object
`Memory
`
`CAN Control
`
`CPU Interface
`
`Control
`
`Address
`
`Data
`
`Figure 2: Structure of complex channel gateway
`modules
`
`The complex channel gateway, which was
`designed in the last years, is a concept to
`
`Therefore dedicated gateways have to be
`developed with the objective of reducing the
`demands on the CPU performance. How-
`ever, there is not one single solution fitting for
`all applications; a concept is required that
`can be easily adapted to different demands.
`
`This paper wants to compare available gate-
`way implementations with a new innovative
`structure that combines the advantages of
`both gateway concepts.
`
`1 Gateway Implementations
`
`Gateway implementations which can be
`found in present-day automotive and indus-
`trial applications are based on one of two
`concepts. The first concept is a set of dis-
`crete channel CAN controllers served by a
`message handling software on the host
`CPU. This concept is flexible regarding the
`number of CAN channels, but a high-per-
`formance host CPU is required to ensure
`real-time operation at full bus-load.
`
`The second concept is an application spe-
`cific complex channel CAN controller. This
`concept is inflexible regarding the gateway
`structure, especially the number of CAN
`channels. Furthermore such gateways need
`elaborate control mechanisms. However, this
`structure supports the transfer of messages
`to other networks without causing a high
`load on the host CPU.
`
`A third concept is the new modular gateway.
`These gateway concepts will be described in
`the following text.
`
`Discrete Channel Gateway
`
`The most distributed gateway concept is the
`discrete channel gateway. This gateway con-
`sists of the components CPU, CPU Periph-
`eral Bus and several single channel CAN
`modules (Figure 1).
`
`There are different implementations of this
`gateway concept available, depending on the
`preferences of the manufacturers. The CPU
`may be a CISC or RISC machine. In most
`applications, its software controls not only
`the gateway function, but may also include
`some other tasks. Each CAN module is con-
`nected to the CPU via the CPU’s peripheral
`bus. During the gateway operation, the CPU
`needs to read all necessary control informa-
`
`06-2
`
`Petitioner's Exhibit 1015
`Page 2 of 8
`
`

`

`iCC 2005
`
`CAN in Automation
`
`is expanded with a gateway interface (Figure
`4). Several instances of this adapted single
`channel CAN module may be combined and
`be turned into a gateway controlled by an
`application specific Gateway Unit (Figure 5).
`
`CAN Core
`
`CAN-Message
`
`CAN_TX
`
`CAN_RX
`
`Message Handler
`
`Message RAM
`(single ported)
`
`CPU IFC Register 1
`
`CPU IFC Register 2
`
`Module Interface
`
`Clock
`Reset
`Control
`
`Address
`
`DataIN
`
`DataOUT
`
`Wait
`
`Interrupt
`
`Figure 3: CAN Module w/o Gateway Interface
`
`The single channel CAN module (in this
`case, Bosch’s C_CAN IP, Figure 3) com-
`prises the components CAN Core, Message
`Handler, Message RAM and CPU IFC Regis-
`ters. The CAN Core performs the serial com-
`munication on the CAN bus.
`Individual
`messages can be (pre-)configured in the
`Message RAM and are managed by the
`Message Handler. This includes the transfer
`of messages between the CAN Core and
`Message RAM, acceptance filtering and the
`handling of transmission requests and inter-
`rupts. Two sets of CPU Interface Registers
`are used for the data transfer between the
`CPU’s peripheral bus and the Message
`RAM. They consist of
`the complete data,
`header and control
`information, which are
`moved as one single word on the internal
`data bus.
`
`Cascade-Input
`
`CAN-Message
`
`CAN Core
`
`CAN-Message
`
`CAN_TX
`
`CAN_RX
`
`CPU IFC Register 1
`
`In-Mux
`
`Message Handler
`
`CPU IFC Register 2
`
`Out-Mux
`
`Message RAM
`(single ported)
`
`Module Interface
`
`Clock
`Reset
`Control
`
`Address
`
`DataIN
`
`DataOUT
`
`Wait
`
`Interrupt
`WR_Sel
`
`RD_Sel
`Com. Mask
`Com. Rqst
`
`GWMode
`
`Cascade-Output
`Figure 4: CAN Module with Gateway Interface
`
`reduce the demand for CPU performance. It
`is more elaborate than the discrete channel
`gateway and consists of a shared Message
`RAM, several CAN Cores and an internal
`Control Unit (CAN Control). In some imple-
`mentations, a Link Control is added to pro-
`vide a basic gateway functionality without
`causing any CPU load (Figure 2).
`
`The system design is comparable to a single
`channel CAN module with two or more CAN
`protocol controllers. A CAN protocol control-
`ler performs the serial communication in a
`CAN bus system according to the CAN pro-
`tocol specification. The CAN Control unit
`manages the data flow between the CAN
`protocol controllers, the Message RAM and
`the CPU Interface,
`respectively the CPU
`itself. It also controls the access of the differ-
`ent instances to the Message RAM and pre-
`vents data corruption. The Message RAM is
`implemented as shared memory, the mes-
`sages for all CAN channels are combined in
`the same RAM block to reduce the need for
`internal data transfer and therefore to reduce
`the CPU load. The optional Link Control unit
`is configured with the fundamental routing
`rules. These rules are checked when a new
`message is received. If a rule for a message
`is defined, it will be performed by the CAN
`Control unit without any need for CPU action.
`Different functions may be provided, depend-
`ent on the complexity of the Link Control and
`CAN Control units. This can be a simple
`copy of the complete message, a transfer of
`the message data with a translated identifier,
`up to message integration, where data of
`several messages is combined into a new
`one.
`
`This concept, especially when it includes a
`Link Control unit, reduces the CPU load sig-
`nificantly. Its disadvantage is that it is compli-
`cated to change the number of CAN
`channels. This would require major changes
`in the Link Control unit and in the CAN Con-
`trol unit, especially in the arbitration of con-
`current accesses to the shared Message
`RAM. Up to now, there is no complex chan-
`nel gateway available which supports more
`than 5 CAN channels.
`
`Modular Gateway
`
`The modular gateway is based on a proven
`single channel CAN module (Figure 3) which
`
`06-3
`
`Petitioner's Exhibit 1015
`Page 3 of 8
`
`

`

`iCC 2005
`
`CAN in Automation
`
`interconnection with several other protocol
`interfaces (e.g. FlexRay, LIN, MOST, etc.).
`For the system designers, these parameters
`may be the flexibility in programming the
`gateway functionality, access time for read/
`transfer of messages, or the required CPU
`performance. In general, a compromise has
`to be found between these parameters,
`especially the system structure/module size
`and the needed CPU performance.
`
`Discrete channel gateways are solutions
`optimized for modularity and module size.
`Several CAN cells can be connected to the
`CPU bus, only the address space has to be
`adapted. No semaphores or additional flags
`are necessary to control concurrent requests
`to a message buffer by several
`instances,
`because only the CPU can access the cells.
`This allows
`the interconnection of an
`unspecified number of CAN channels.
`
`The simple system structure without any
`additional interconnecting logic reduces the
`module size to a minimum. The lack of hard-
`ware support for gateway functions however
`increases the need for CPU performance. All
`data transfers between two or more cells,
`data manipulations, and insertions need to
`be executed by the CPU. Especially the
`sequential read and write cycles for a mes-
`sage transfer between cells cause high CPU
`burdens. In summary, a high number of CPU
`cycles is unavoidable. This number of cycles
`is increased by the interrupt handling or by
`the polling of the connected cells (to check
`for receptions), and by special functions like
`the already named data manipulation or the
`combination of several messages.
`
`Even regarding the high CPU burden, this
`gateway model provides the most flexibility in
`programming, since the gateway functional-
`ity is implemented in software. Such a gate-
`way model meets the requirements of a wide
`range of gateway applications.
`
`In automotive and industrial control applica-
`tions, where the numbers of interconnected
`CAN cells and routed messages cause a
`very high CPU load, gateway models are
`needed that provide additional
`functions.
`One such gateway model
`is the complex
`channel gateway that
`implements a wide
`range of functions in hardware, its central
`component
`is the shared Message RAM.
`
`The existing single channel CAN module is
`expanded by several
`functional blocks to
`adapt it into a gateway cell. These functional
`blocks are an input multiplexer In-Mux and
`an output-multiplexer Out-Mux together with
`the necessary control signals to direct the
`data flow (Figure 4).
`
`The two multiplexers give access to the inter-
`nal data bus, making it possible to load the
`complete CPU IFC Register in parallel from
`a wide input port (Cascade-Input) and to
`export the contents of the CPU IFC Register
`over an equally wide output port (Cascade-
`Output). The Cascade-Input may also be
`routed directly to the Cascade-Output.
`
`These two wide ports allow the transfer of a
`complete CAN message and necessary con-
`trol information in one step directly from one
`CAN cell to other CAN cells, avoiding the
`bottleneck of the CPU’s peripheral bus.
`
`C_CAN 1
`
`CAN_TX
`
`CAN_RX
`
`C_CAN 2
`
`CAN_TX
`
`CAN_RX
`
`C_CAN n
`
`CAN_TX
`
`CAN_RX
`
`...
`
`CPU_IFC
`
`CPU_IFC
`
`CPU_IFC
`
`Gateway
`Unit
`Control signals
`GW Mode[1n]
`Write Enable[1n]
`Cmd Rqst[1n]
`Cmd Msk[1n]
`Write Sel[1n]
`Read Sel[1n]
`
`CPU-Bus
`
`Figure 5: Structure of modular gateway module
`
`Cascade-Ring
`
`When several instances of this adapted sin-
`gle channel CAN module are cascaded into
`a gateway module, the wide input and output
`ports are connected to the cascade ring bus.
`This allows the transfer of a complete mes-
`sage and control signals to all connected
`cells in one clock cycle. The data flow
`between the CAN cells is controlled by an
`application specific Gateway Unit that pro-
`vides the control signals for the multiplexers
`and the information to load/store a message
`from/to the Message RAMs.
`
`2 Comparison of Gateway Concepts
`
`Semiconductor manufacturers and system
`designers will use different parameters when
`they compare the advantages of gateway
`modules. For semiconductor manufacturers,
`these parameters may be the module’s gate
`count, its adaptability to different numbers of
`CAN channels, as well as the possibility of
`
`06-4
`
`Petitioner's Exhibit 1015
`Page 4 of 8
`
`

`

`iCC 2005
`
`CAN in Automation
`
`The messages for all connected CAN chan-
`nels are configured and stored in the same
`RAM block. A message that is to be received
`on one channel and to be transmitted on
`another channel will occupy only one seg-
`ment of the RAM block. This feature reduces
`the CPU load, because it supersedes the
`transfer operations of
`the message from
`CAN cell(n) to the CPU and then from the
`CPU to CAN cell(m). Automatic transmis-
`sions of received messages on other net-
`works can be started if a Link Control
`is
`implemented. The CAN Control Unit detects
`the reception of a message and checks the
`routing rules in the Link Control. If a rule is
`defined, it is executed by the CAN Control
`Unit. Several functions can be implemented,
`dependent on the complexity of
`the Link
`Control and CAN Control Units. This can be
`the simple copy of a message onto another
`network up to the merger of several mes-
`sages into a new one, combined with cycli-
`cally updated transmissions.
`
`The reduction of the CPU load is paid with
`less flexibility in the system design. A compli-
`cated control system is needed to transfer
`the messages between the CPU, the CAN
`cells, and the RAM, arbitrating between pos-
`sibly concurrent requests by several cells to
`the shared message RAM, requiring flags
`and semaphores to assure data consistency.
`A priorisation of all modules is required to
`define which unit gets access to the RAM.
`When a specific application of the gateway
`needs new transfer functions or a different
`number of CAN channels, this will require a
`redesign of
`the whole gateway structure
`(especially link control and CAN control).
`
`The modular gateway is a merger of discrete
`channel and complex gateway, combining
`the advantages of both concepts. The opti-
`mized structure allows a fast data transfer
`between several cells without causing a high
`CPU load [4]. If an internal state machine is
`provided, the CPU load can be reduced to a
`minimum. The transfer of messages from
`one Message RAM over the cascade ring to
`one other Message RAM takes more time
`then in a complex channel gateway with Link
`Control unit where no data transfer between
`two CAN cells is necessary. However, the
`transfer over the cascade ring takes less
`then two CAN bit times and the cascade ring
`
`has another advantage: It allows the transfer
`of a message to one, several or all con-
`nected cells simultaneously with nearly the
`same effort.
`
`The modular structure allows also a flexible
`programming of the gateway function. Even
`when the gateway function is controlled by a
`finite state machine,
`the CPU keeps full
`access to all functions of each CAN cell. For
`example, it can write or read messages and
`can start their transfer. Concurrent requests
`of the CPU and of the FSM to the same cell
`are solved in a deterministic way, sema-
`phores and flags are not necessary. This
`maximises the flexibility of
`the module.
`If
`additional functions beyond a simple mes-
`sage transfer/copy are required (e.g.
`the
`merging of messages), special modules that
`implement this features can be inserted into
`the cascade ring.
`
`Different applications need quite different
`solutions. A modular structure allows to
`design a new gateway by combining compo-
`nents of a library, speeding up the design
`time significantly. The size of such a module
`is marginally larger than that of a discrete
`channel gateway structure, it is increased by
`the Gateway Unit and the optional message
`manipulation functions.
`
`The modular gateway structure is not
`restricted to the CAN protocol, it is possible
`to add several other protocol interfaces to the
`cascade ring. These can be different bus
`systems like TTCAN, FlexRay or LIN. When
`implementing the time-triggered variant of
`CAN, the gateway structure (incl. gateway
`control unit) can be the same. Only the con-
`cerned CAN cells have to be replaced by the
`time-triggered ones. A different
`interface
`structure then the cascade ring might be
`used for the implementation of bus systems
`transferring multimedia data (e.g. MOST,
`IEEE 1394, Bluetooth) because of different
`requirements regarding higher data rates on
`the one hand and less emphasis on trans-
`mission reliability, security, and time sched-
`ules on the other hand.
`
`An exemplary implementation of the modular
`gateway structure was tested to demonstrate
`the functionality of the cascaded ring struc-
`ture.
`It consists of
`three CAN nodes,
`enhanced by a data integration unit (mes-
`
`06-5
`
`Petitioner's Exhibit 1015
`Page 5 of 8
`
`

`

`iCC 2005
`
`CAN in Automation
`
`sage combination, message comparison),
`controlled by a set of special function regis-
`ters. The control software runs on a Motorola
`HC08 CPU. The gateway was synthesized
`into an FPGA. In total, the module needs an
`additional gate count of nearly 10% com-
`pared to the same number of discrete chan-
`nel CAN modules. The functionality of the
`test structure could be demonstrated in a
`small application [4].
`
`A short summary of important parameters
`for the gateway models is shown in the fol-
`lowing table (Table 1).
`
`Com-
`plex
`Channel
`
`Discrete
`Channel
`
`Modular
`Gateway
`
`low
`
`high
`
`high
`
`high
`
`low
`
`middle
`
`Design
`Flexibility
`Module Size
`(Chip area)
`Expandability
`Hardware
`Functionality
`Required CPU
`Performance
`Time for internal
`Mess. Transfer
`Table 1 : Overview of important parameters for
`gateway design
`
`difficult
`
`easy
`
`high
`
`low
`
`low
`
`low
`
`high
`
`high
`
`easy
`
`high
`
`low
`
`low
`
`plex automotive and industrial control appli-
`cations. Real-time information exchange and
`real-time ECU control structures can no
`longer be guaranteed.
`
`Available solutions that require less CPU
`performance for data transfers are complex
`channel gateways. With the module-internal
`data handling, the requirement for CPU per-
`formance can be reduced dramatically. How-
`ever,
`the system structure is inflexible
`regarding the number of CAN channels as
`well as regarding the possibility to implement
`additional functions.
`
`The new modular gateway structure, which is
`presented in this paper, solves the problem
`of CPU performance, gives flexibility in sys-
`tem design, and allows real-time operation.
`
`3 Advanced CAN Gateway Architecture
`
`The differentiation of the application areas,
`combined with increased pricing pressure,
`led to the implementation of specialised bus
`systems, e.g. LIN, TTCAN, and FlexRay.
`
`A gateway connecting these bus systems to
`the CAN channels has to fulfil
`the same
`requirements of limited CPU load and flexible
`system structure as well as some additional
`requirements, e.g. when connecting time-
`triggered networks, networks with different
`message length, or with different data rates.
`
`It was possible to show that discrete channel
`gateways are no longer applicable in com-
`
`Time-Triggered Network A
`
`Ref
`
`258
`
`Ref
`
`050
`
`12D
`
`09A
`
`09A…
`
`Ref
`
`Time-Triggered Network B
`
`Ref
`
`09A
`
`355
`
`Ref
`
`258
`
`050
`
`…
`
`12D
`
`12D
`
`Ref
`
`09A
`
`Basic Cycle 1
`
`Basic Cycle 2
`
`Matrix Cycle
`
`Synchronization
`Reference Point
`Figure 6: Predefined data transfer between time-triggered networks
`
`Basic Cycle 1
`
`Matrix Cycle
`
`Synchronization
`Reference Point
`
`A message transfer between two unsynchro-
`nised time-triggered networks is possible,
`but time-triggered systems need to work on
`a predefined schedule, otherwise it would
`not be assured that the processed data is up
`to date. In the worst case, caused by phase
`shifts and differing time bases on the unsyn-
`chronised networks, a time delay of an entire
`cycle time could occur.
`
`Therefore, all participants have to be syn-
`chronised in order to achieve a predefined
`data transfer (Figure 6).
`
`The synchronisation between TTCAN net-
`works, where the global time is provided by a
`single time master, is quite easy. It can be
`implemented in a simple hardware state
`machine, when the gateway cells connected
`to the (time-) slave networks are time mas-
`
`06-6
`
`Petitioner's Exhibit 1015
`Page 6 of 8
`
`

`

`iCC 2005
`
`CAN in Automation
`
`ters of that networks. The gateway cell con-
`nected to the (time-) master network may be
`time slave, potential time master or actual
`time master in that network. It is not neces-
`sary that all TTCAN networks operate with
`the same basic cycle length; they may use
`different cycle length and may operate on dif-
`ferent CAN bit times.
`
`A simple hardware state machine is not suffi-
`cient
`to synchronize FlexRay networks,
`because FlexRay is a multi-master bus sys-
`tem where the global time is calculated on
`signals coming from up to 15 nodes, the syn-
`chronisation will be done by software. The
`synchronisation of TTCAN networks with a
`FlexRay network follows the same principle
`as the synchronisation of two TTCAN net-
`works.
`In this case the FlexRay network
`would be the master network and all
`inter-
`connected TTCAN networks would be con-
`sidered as (time-) slave networks.
`
`CAN applications uses data rates up to
`1000 kBit/s. Specialised routing algorithms
`are necessary when connecting CAN with a
`bus system that uses higher data rates (e.g.
`FlexRay 2x10 MBit/s), to prevent an overload
`of the „slower” network. A possible solution is
`the usage of message filtering, which is pro-
`vided by the most modules. This means that
`only predefined messages will be routed in
`the gateway. However, some messages need
`to be transferred only fractionally to another
`network. In this case, it is applicable to inte-
`grate several messages.
`
`Multimedia components have become stand-
`ard in the upper car class (e.g. navigation
`and entertainment systems). The data com-
`munication between multimedia compo-
`nents
`and
`automotive
`bus
`systems
`increased significantly in the last years (e.g.
`adapting the sound volume to the driving
`speed). The communication between the two
`domains with their different
`requirements
`needs a dedicated interface. The communi-
`cation between both network domains must
`not interfere with the communication reliabil-
`ity of the automotive networks, while multi-
`media applications are less critical. Another
`aspect are the different timing requirements.
`Automotive networks have to work at a pre-
`defined schedule; most multimedia systems
`cannot
`guarantee
`timing
`requirements.
`Security is also an important factor to be
`
`considered when interconnecting automotive
`and multimedia bus systems. When such a
`gateway is implemented in hardware, struc-
`tures have to be implemented that prevent
`the unintended data transfer between the
`domains. Possible concepts are hardware
`firewalls and data encryption.
`
`4 Summary and Conclusion
`
`Currently, the gateways provided by semi-
`conductor manufacturers are discrete chan-
`nel gateways or complex channel gateways.
`Complex channel gateways have an inflexi-
`ble application specific system structure
`whereas discrete channel gateways need
`control software that causes a CPU load that
`depends on the combined bus traffic of all
`connected CAN networks.
`
`This paper has shown and compared the
`structure as well as the advantages and dis-
`advantages of both implementations. Also it
`was shown that it is possible to adapt proto-
`col interface cells to use it in a modular gate-
`way. This modular gateway combines the
`advantages of discrete and complex gateway
`implementations.
`It
`is flexible in system
`structure and reduces the load of the host
`CPU or the Gateway Control Unit signifi-
`cantly. First implementations and evaluation
`results of an exemplary gateway were dem-
`onstrated.
`
`Future challenges are the enhancement of
`the CAN gateway with TTCAN modules for
`networks using a time-triggered architecture
`and the integration of a finite state machine
`to allow CPU-independent operation. A con-
`cept for this control unit is in development.
`
`References
`1. Bosch: C_CAN User’s Manual, Revision 1.2; Robert
`Bosch GmbH; http://www.can.bosch.com/docu/…
`Users_Manual_C_CAN.pdf; 08.01.2005
`2. Bosch: C_CAN Module Integration Guide, Revision
`1.2; Robert Bosch GmbH; 21.01.2002
`3. Bosch: TTCAN User’s Manual, Revision 1.6; Robert
`Bosch GmbH; http://www.can.bosch.com/docu/…
`Users_Manual_TTCAN.pdf; 08.01.2005
`4. J. Taube, F. Hartwich, H. Beikirch: C_CAN Gateway
`Module - A New Approach for CAN Gateways -;
`embedded world 2005 Conference, Nuremberg
`(Germany)
`5. V. Nieten: Gateway Development Support for Multi-
`Channel CAN with Event-Processor; 7th interna-
`tional CAN Conference,
`iCC 2000, Amsterdam
`(Netherlands)
`
`06-7
`
`Petitioner's Exhibit 1015
`Page 7 of 8
`
`

`

`iCC 2005
`
`CAN in Automation
`
`6. U. Kelling: The MultiCAN module - Two CAN were
`not enough; CAN Newsletter June 2004; p16-p18
`7. Freescale Semiconductor, Inc.: XGATE Block Guide;
`http://www.freescale.com/files/microcontrollers/…
`doc/ref_manual/S12XGATEV2.pdf; 08.01.2005
`8. NEC Corporation: Preliminary User’s Manual
`V850E/CA1TM ATOMIC;
`http://www.ee.nec.de/…
`_pdf/U14913EE1V0UM00.PDF; 08.01.2005
`
`Contact
`___________________________________
`Jan Taube
`Robert Bosch GmbH, AE/EIS3
`P.O.Box 13 42
`72703 Reutlingen
`Germany
`Phone: +49 7121 35-4570
`Fax:
`+49 7121 35-1746
`E-mail: Jan.Taube@de.bosch.com
`___________________________________
`Florian Hartwich
`Robert Bosch GmbH, AE/EIS3
`P.O.Box 13 42
`72703 Reutlingen
`Germany
`Phone: +49 7121 35-2594
`Fax:
`+49 7121 35-1746
`E-mail: Florian.Hartwich@de.bosch.com
`___________________________________
`Prof. Helmut Beikirch
`University of Rostock
`Faculty of Computer Science and Electr. Eng.
`Albert-Einstein-Str. 2
`18051 Rostock
`Germany
`Phone: +49 381 498-3514
`Fax:
`+49 381 498-3608
`E-mail: Helmut.Beikirch@etechnik.uni-rostock.de
`___________________________________
`
`Additional Sources
`http://www.can.bosch.com/
`
`Definitions, Acronyms, Abbreviations
`CAN Controller Area Network
`CPU
`Central Processing Unit
`GW Gateway
`FSM Finite State Machine
`SFR
`Special Function Register
`ECU
`Electronic Control Unit
`ASIC Application Specific Integrated Circuit
`ASµC Application Specific Microcontroller
`IP
`Intellectual Property
`CISC Complex Instruction Set Computer
`RISC Reduced Instruction Set Computer
`
`06-8
`
`Petitioner's Exhibit 1015
`Page 8 of 8
`
`