WO2006015913A1 - Flexray-kommunikationsbaustein - Google Patents

Flexray-kommunikationsbaustein Download PDF

Info

Publication number
WO2006015913A1
WO2006015913A1 PCT/EP2005/053083 EP2005053083W WO2006015913A1 WO 2006015913 A1 WO2006015913 A1 WO 2006015913A1 EP 2005053083 W EP2005053083 W EP 2005053083W WO 2006015913 A1 WO2006015913 A1 WO 2006015913A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
message
data
flexray
buffer memory
Prior art date
Application number
PCT/EP2005/053083
Other languages
English (en)
French (fr)
Inventor
Florian Hartwich
Christian Horst
Franz Bailer
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP05756826A priority Critical patent/EP1776805B1/de
Priority to DE502005008586T priority patent/DE502005008586D1/de
Priority to JP2007524317A priority patent/JP2008508826A/ja
Priority to AT05756826T priority patent/ATE450102T1/de
Priority to US11/659,558 priority patent/US7769906B2/en
Publication of WO2006015913A1 publication Critical patent/WO2006015913A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/417—Bus networks with decentralised control with deterministic access, e.g. token passing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40013—Details regarding a bus controller
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40026—Details regarding a bus guardian
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40241—Flexray
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Definitions

  • the invention relates to a FlexRay Konimunikationsbaustein for coupling a FlexRay communication link with a, the FlexRay Kommunikalionsbaustein associated participants in a FlexRay network, over which messages über ⁇ wear.
  • the networking of control devices, sensors and actuators with the help of a communication system and a bus system, ie a communication link has increased dramatically in recent years in the construction of modern motor vehicles or in mechanical engineering, especially in the field of machine tools as well as in automation. Synergy effects can be achieved by distributing functions over several control units. This is called distributed systems.
  • the communication between different stations takes place more and more via a bus system, ie a communication system.
  • the communication traffic on the bus system, access and reception mechanisms as well as error handling are regulated by a protocol.
  • a well-known protocol for this is the FlexRay protocol, which is currently based on the FlexRay protocol specification v2.0.
  • the FlexRay is a fast, deterministic and fault-tolerant bus system, especially for use in one
  • the FlexRay protocol operates according to the method of Time Division Multiple Access (TDMA), whereby the components are thus assigned to subscribers or to the messages to be transmitted fixed time slots in which they have exclusive access to the communication connection.
  • TDMA Time Division Multiple Access
  • the time slots repeat themselves in a fixed cycle, so that the point at which a message about the bus is transmitted, can be predicted exactly and the bus access is deterministic.
  • FlexRay divides the cycle into a static and a dynamic part.
  • the fixed time slots are located in the static part at the beginning of a bus cycle.
  • the time slots are allocated dynamically. In this case, exclusive bus access is only possible for a short time, so-called minislots.
  • FlexRay communicates via two physically separate lines with a maximum data rate of 10 MB / s.
  • the two channels correspond to the physical layer, in particular the OSI (Open System Architecture) layer model. These are now mainly used for the redundant and thus fault-tolerant transmission of messages, but can also transmit different messages, which would then double the data rate. FlexRay can also be operated at lower data rates.
  • OSI Open System Architecture
  • Synchronization messages are transmitted in the static part of the cycle for unsynchronization, the local time of a component being corrected by means of a special algorithm in accordance with the FlexRay specification, so that all local clocks run synchronously to one global clock.
  • a FlexRay network node or FlexRay subscriber or host contains a subscriber processor, that is to say the host processor a FlexRay controller or communication controller and, in the case of bus monitoring, a bus guardian.
  • the host processor that is to say the subscriber processor, supplies and processes the data which is transmitted via the FlexRay communication controller.
  • messages can be sent with e.g. up to 254 data bytes can be configured.
  • the task now is to provide a FlexRay communication module that optimally supports communication in a FlexRay network.
  • a FlexRay communication module for coupling a FlexRay communication connection as a physical layer to a subscriber assigned to the FlexRay communication module in a FlexRay interface.
  • the FlexRay communication module advantageously contains a first arrangement for storing at least a portion of the messages transmitted and a second arrangement for connecting the first arrangement with the subscriber, and a third arrangement for connecting the FlexRay communication connection, ie the physical Layer with the first arrangement.
  • the first arrangement advantageously contains a message manager, ie message handler and a message memory, wherein the message administrator adopts the control with respect to the data paths of the first and second arrangement with respect to a data access with respect to the message memory.
  • the message memory of the first arrangement is expediently divided into a header segment and a data segment.
  • FlexRay participants or the host processor an input buffer memory and an output buffer memory, wherein either the input buffer memory or the output buffer memory or preferably both memories are in a preferred Ausbowungs ⁇ form each divided into a sub-buffer memory and a shadow memory, each read alternately only and / or described, whereby the integ ⁇ rity is ensured.
  • the alternate reading or writing of the respective partial buffer memory and associated shadow memory can advantageously be achieved by exchanging the respective access or by exchanging the memory contents.
  • each partial buffer memory and each shadow memory is designed such that one data area and / or one header area of two FlexRay messages can be stored.
  • the second arrangement contains an interface module which consists of a subscriber-specific sub-module and a subscriber-independent sub-module, so that only the subscriber-specific sub-module has to be changed for subscriber adaptation and so overall the flexibility of the FlexRay communication module is increased ,
  • the sub-modules can also be realized within the one interface module in software, ie each sub-module as a software function.
  • the third arrangement advantageously contains a first interface module and a second interface module and is in turn divided into two data paths each having two data directions.
  • the third arrangement also contains a first and a second buffer memory in order to take into account the two data paths and the two data directions.
  • the first and second buffer memories are designed such that at least one data area of two FlexRay messages can be stored.
  • each interface module of the third arrangement includes a shift register and a FlexRay protocol state machine.
  • the FlexRay protocol specification in particular v2.0
  • a flexibly configurable message memory results for the storage of a different number of message objects depending on the size of the respective data field or delivery date of the message, thus advantageously embassies or message embassies Configuring message objects that have different lengths of data fields
  • Each message or message object in the memory can be configured as a receive memory object (receive buffer), transmit memory object (transmit buffer) or as part of the configurable receive FIFO.
  • acceptance filtering is based on Frame ID, Channel ID and
  • FIG. 1 shows a schematic representation of the communication module and des ⁇ sen connection to the physical layer, ie the communication connection and the communication or host participants.
  • FIG. 2 shows, in a specific embodiment, a communication component from FIG. 1 and its connection in more detail.
  • FIG. 3 shows the structure of the message memory.
  • FIGS. 4 to 6 schematically describe the architecture and the process of data access in FIG.
  • FIGS. 7 to 9 schematically describe the architecture and process of the data access in the direction from the message memory to the subscriber.
  • FIG. 10 the message manager and the finite-state machines contained therein are shown schematically.
  • FIG. 11 once more schematically shows the components of the communication module as well as the subscriber and the corresponding data paths controlled by the message administrator.
  • FIG. 12 describes the access distribution with respect to the data paths in FIG. 11.
  • FIG. 1 schematically shows a FlexRay communication module 100 for connecting a subscriber or host 102 to a FlexRay communication connection 101, that is to say the physical layer of the FlexRay. This is the FlexRay communication block
  • a first arrangement 105 serves for storing, in particular clipboard, at least part of the messages to be transmitted.
  • a second arrangement 104 is connected via the connections 107 and 108.
  • a third arrangement 103 is connected between the subscriber 101 and the first arrangement 105 via the connections 106 and 109, as a result of which very flexible inputting and outputting of data as part of messages, in particular FlexRay messages, into or out of the first arrangement 105 is achievable with guaranteed data integrity at the optimum speed.
  • the second arrangement 104 contains an input buffer memory or input buffer memory 201 (Thedput Buffer IBF), an output buffer memory or output buffer memory 202 (Output Buffer OBF) and an interface module consisting of two Parts 203 and 204, wherein the one partial block 203 teilne nehrneruntouch and the second partial block 204 is subscriber-specific.
  • the subscriber-specific sub-module 204 (Customer CPU Interface CIF) connects a subscriber-specific host CPU 102, that is to say a customer-specific subscriber, to the FlexRay communications module.
  • a bidirectional data line 216, an address line 217 and a control input 218 are provided. It is also provided with
  • the subscriber-specific sub-module 204 is connected to a subscriber-independent sub-module 203 (Generic CPU Interface, GIF), ie the FlexRay communications module or the FlexRay-IP module has a generic, ie general, CPU interface, to which corresponding subscriber-specific Submodules, ie Customer CPU Interfaces CEF connect a large number of different customer host CPUs. As a result, depending on the subscriber, only the partial module 204 has to be varied, which means a significantly lower outlay.
  • the input buffer memory or input buffer memory 201 and the output buffer memory or output buffer memory 202 may be formed in a memory module or else in separate memory modules.
  • the input buffer memory 201 is used for buffering messages for transmission to the message memory 200.
  • the input buffer module is preferably designed such that it has two complete messages each consisting of a header segment or header segment, in particular with configuration data and a data segment or payload Can save segment.
  • the input buffer memory is formed in two parts (partial buffer memory and shadow memory), whereby the transmission between subscriber CPU 102 and message memory 200 can be accelerated by alternately writing the two parts of the input buffer memory or by access change.
  • the output buffer or output buffer serves for the buffering of messages for the transmission from the message memory 200 to the subscriber CPU 102.
  • the output buffer 202 is also designed so that two complete messages consisting of header segment, in particular with configuration onsquel and data segment, so payload segment, can be stored.
  • the output buffer memory 202 is divided into two parts, a partial buffer memory and a shadow memory, whereby the transfer between subscriber or host CPU 102 and message memory also occurs here by alternately reading the two parts 200 speeds.
  • This second arrangement 104 consisting of the blocks 201 to 204 is connected to the first arrangement 105 as shown.
  • the arrangement 105 consists of a message handler 200 (message handler MHD) and a message memory 300 (message RAM).
  • the message manager controls or controls the data transfer between the input buffer memory 201 and the output buffer 202 and the message memory 300. Likewise, it controls or controls the data transmission in the other direction via the third arrangement 103.
  • the message memory is preferably designed as a single-ported RAM , This RAM memory stores the messages or message objects, ie the actual data, together with configuration and status data. The exact structure of the message memory 300 is shown in more detail in FIG.
  • the third arrangement 103 consists of the blocks 205 to 208. According to the two channels of the FlexRay Physical Layer, this arrangement 103 is divided into two data paths with two data directions each. This is illustrated by the connections 213 and 214, in which the two data directions for the channel A, RxA and TxA for reception (RxA) and transmission (TxA) as well as for channel B, RxB and TxB are shown. Connection 215 denotes an optional bidirectional control input.
  • the connection of the third arrangement 103 takes place via a first buffer memory 205 for channel B and a second buffer memory 206 for channel A. These two buffer memories (transient buffer RAMs: RAM A and RAM B) serve as buffer memories for the data transmission of or to the first arrangement 105.
  • these two buffer memories 205 and 206 are each connected to an interface module 207 and 208, which comprise the FlexRay protocol controller or bus protocol controller consisting of a transmit receive register and the shift register FlexRay protocol Finite State Machine, included.
  • the two buffer memories 205 and 206 thus serve as intermediate memories for the data transmission between the shift registers of the interface modules or FlexRay protocol controllers 207 and 208 and the message memory 300.
  • the data fields, ie the payload segment are advantageously provided by each buffer memory 205 or 206 or data segment of two FlexRay messages.
  • GTU Global Time Unit
  • the fault-tolerant clock synchronization of the cycle counter and the control of the time sequences in the static and dynamic segments of the FlexRay are regulated.
  • Block 210 represents the general system control (System Universal Control SUC) by means of which the operating modes of the FlexRay communication controller are controlled and controlled. These include wakeup, startup, reintegration or integration, normal surgery and passive surgery.
  • Block 211 shows the network and error management (Network and Error Management NEM) as described in FlexRay protocol specification v2.0.
  • Block 212 finally shows the interrupt control (interrupt control INT), which manages the status and error interrupt flags (status and error interrupt flags) and controls the interrupt outputs 219 to the subscriber CPU 102.
  • the block 210 represents the general system control (System Universal Control SUC) by means of which the operating modes of the FlexRay communication controller are controlled and controlled. These include wakeup, startup, reintegration or integration, normal surgery and passive surgery.
  • Block 211 shows the network and error management (Network and Error Management NEM) as described in FlexRay protocol specification v2.0.
  • Block 212 finally shows the interrupt control (interrupt control INT), which manages the status and error interrupt flags
  • 212 also includes an absolute and a relative timer or timer for Er ⁇ generation of time interruptions or timer interrupts.
  • message objects or messages can be configured with up to 254 data bytes.
  • the message memory 300 is, in particular, a message RAM, which can be used e.g. up to a maximum of 64 message objects. All functions which relate to the treatment or administration of the messages themselves are implemented by the message manager or message handler 200. These are e.g. Acceptance filtering, transfer of messages between the two FlexRay protocol controllers-
  • Blocks 207 and 208 and the message memory 300 so the message RAM and the control of the transmission order and the provision of configuration data or status data.
  • An external CPU that is to say an external processor of the subscriber processor 102, can access the registers of the FlexRay communication module directly via the subscriber interface with the subscriber-specific part 204. It uses a variety of registers. These registers are used to control the FlexRay protocol controllers, ie the interface modules 207 and 208, the message handler (message handler MHD) 200, the global time unit (GTU) 209, the general system controller (system universal controller SUC). 210, the network and error management unit (NEM) 211, the interrupt controller (interrupt controller INT) 212 as well as the access to the message RAM, ie the message memory 300 to configure and control and also the corresponding Status. At least parts of these registers are still in the
  • FIG. 3 the division of the message memory 300 is described in detail.
  • a message memory is required for the provision of messages to be sent (transmit buffer) as well as the storage of messages received without errors (receive buffer).
  • a FlexRay protocol allows messages with a data range, ie a payload range from 0 to 254 bytes. As shown in FIG. 2, the message memory is part of the FlexRay communication module 100.
  • the method described below and the corresponding message memory describe the storage of messages to be sent as well as received messages, in particular using a random access memory (RAM).
  • RAM random access memory
  • the number of storable messages is dependent on the size of the data areas of the individual messages, whereby on the one hand the size of the required memory can be minimized without restricting the size of the data areas of the messages and on the other hand an optimal utilization of the memory takes place.
  • this va ⁇ riable allocation of a particular RAM-based message memory for a Flex-Ray Communication Controller will be described in more detail.
  • an embassy memory with a defined
  • the message memory 300 is divided into two segments, a header segment or header segment HS and a data segment DS (payload section, payload segment).
  • a header area HB and a data area DB are created per message.
  • header areas or header areas HB0, HB1 to HBk and data areas DB0, DB1 to DBk are thus created.
  • first and second data the first data corresponding to configuration times and / or status data relating to the FlexRay message and each stored in a header area HB (HBO, HB1, ..., HBk).
  • the second data which correspond to the actual data that is to be transmitted, are stored correspondingly in data areas DB (DBO, DB1,..., DBk).
  • the division between the header segment HS and the data segment DS is now variable in the message memory 300, ie there is no predetermined boundary between the domains.
  • the division between the header segment HS and the data segment DS is dependent on the number k of messages and the second data range, ie the extent of the actual data, of a message or of all k messages together.
  • a pointer element or data pointer DPO, DPI to DPk is in each case assigned directly to the configuration data KDO, KD1 to KDk of the respective message.
  • each header area HBO, HB1 to HBk is assigned a fixed number of memory words, here two, so that always a configuration data KD (KDO, KD1, KDK) and a pointer element DP (DPO, DPI,
  • the data segment DS includes for storing the actual message data DO, Dl to Dk.
  • This data segment (or dalensection) DS depends in its data scope on the respective data volume of the stored message data, here, for example, six words in DBO, DBl one word and DBk two words.
  • the respective pointer elements DPO, DPI to DPk thus always point to the beginning, ie to the start address of the respective data area DBO, DB1 to DBk, in which the data DO, D1 to Dk of the respective messages 0, 1 to k are stored.
  • the distribution of the message memory between header segment HS and data segment DS is therefore variable and depends on the number of messages themselves as well as the respective data volume of a message and thus on the entire second data volume. If fewer messages are configured, the header segment becomes smaller and the freed area in the message memory can be used as an addition to the data segment DS for the storage of data. As a result of this variability, optimum memory utilization can be ensured, with which the use of smaller memories is also possible.
  • the free data segment FDS "in particular its size, also abpatin ⁇ gig of the combination of the number k of the stored messages and the respective second data volume of the messages is minimal and can be even 0th
  • the message memory is assigned a soupkennungserzeu- ger, in particular a parity bit generator element and a Jamaicakennungsprüfer, insbe ⁇ special a parity bit check element to ensure the correctness of the stored data in HS and DS in that a checksum, in particular as a parity bit, can also be stored per memory word or per area (HB and / or DB).
  • Other control identifiers e.g. a CRC (cyclic redundancy check) or higher-value identifiers such as ECC (Error Code Correction) are conceivable.
  • CRC cyclic redundancy check
  • ECC Error Code Correction
  • the user can decide in programming whether to use a larger number of messages with a small data field or whether he wants to use a smaller number of messages with a large data field.
  • In the configuration of messages with under ⁇ different large data area of the available space is optimally utilized.
  • the user has the option of using a data storage area in common for different messages.
  • the size of the message memory can be adapted to the needs of the application by adapting the memory depth of the memory used, without changing the other functions of the communication controller.
  • the host CPU access that is to say the writing and reading of configuration data or status data and the actual data via the buffer memory arrangement 201 and 202, will now be described in more detail with reference to FIGS. 4 to 6 and 7 to 9.
  • the goal here is to produce a decoupling with regard to the data transmission in such a way that the data integrity can be ensured and at the same time a high transmission speed is ensured.
  • the control of these processes takes place via the message manager 200, which will be described in more detail later in FIGS. 10, 11 and 12. 4, 5 and 6, the write accesses to the Botschdentsate 300 by the host CPU of the subscriber CPU 102 via the input buffer 201 are first explained in more detail.
  • Figure 4 again shows the communication module 100, wherein for reasons of clarity, only the relevant parts of the Medunikationsbau- stone 100 are shown.
  • the message manager 200 responsible for controlling the processes
  • two control registers 403 and 404 which as illustrated can be accommodated outside the message manager 200 in the communications module 100, but can also be contained in the message administrator 200 itself.
  • 403 represents the input request register (Ihput Buffer Command Request Register)
  • 404 the input mask register (Input Buffer Command Mask Register).
  • Write accesses of the host CPU 102 to the message memory 300 (message RAM) thus take place via an intermediate input buffer 201 (input buffer).
  • This input buffer 201 is now divided or doubled, specifically as a partial buffer memory 400 and a shadow memory 401 associated with the sub-buffer memory.
  • Access is controlled via the input request register 403 and via the input mask register 404.
  • the register 403 with the numbers from 0 to 31, the respective bit positions in 403 are exemplified here for a width of 32 bits. The same applies to register 404 and bit positions 0 to 31 in 404.
  • the bit positions 0 to 5, 15, 16 to 21 and 31 of the register 403 receive a special function with respect to the sequence control.
  • an identifier IBRH (biput Buffer Request Host) can be entered as the message identifier.
  • an identifier IBRS Input Buffer Request Shadow
  • register 15 of 403 IBSYH and register 31 of 403 lists IBSYS as access identifiers.
  • the host CPU 102 writes the data of the message to be transferred into the input buffer memory 201.
  • the host CPU 102 can only transmit the configuration and header data KD of a message for the header segment HS of the message memory or only the actual one to be transmitted Write data D of a message for the data segment DS of the message memory or both.
  • Which part of a message so configuration data and / or the actual data is to be transmitted is determined by the special data identifiers LHSH and LDSH in the input marker register 404.
  • LHSH Load Header Section Host
  • LDSH Load Data Section Host
  • STXRS Set Transmission X Request Shadow
  • STXRS Set Transmission X Request Shadow
  • the host CPU 102 When the host CPU 102 writes the message identifier, in particular the number of the message object in the message memory 300 into which the data of the input buffer memory 201 is to be transferred to the bit positions 0 to 5 of the input request register 403, ie after EBRH, the partial buffer memory is written 400 of the input buffer memory 201 and the associated shadow memory 401 reversed or it is the respective access of the host CPU 102 and message memory 300 to the two sub-memories 400 and 401 reversed, as interpreted by the semicircular arrows an ⁇ .
  • the data transfer ie the data transfer to the message memory 300, is also started.
  • the data transmission to the message memory 300 itself takes place from the shadow memory 401.
  • IBRH and IBRS are exchanged. Likewise exchanged LHSH and LDSH against LHSS and LDSS.
  • STXRH is exchanged with STXRS.
  • IBRS thus shows the identification of the message, that is to say the number of the message object that is being transmitted, ie a transfer from the shadow memory 401 or which message object, ie which area in the message memory is the last data (KD and / or D) has been obtained from the shadow memory 401.
  • the identifier here again, for example, 1 bit
  • IBSYS Input Buffer Busy Shadow
  • This bit IBSYS is set, for example, by writing IBRH bits 0 to 5 in register 403 to indicate that a transfer between the shadow memory 401 and the message memory 300 is in progress. After completing this data transfer to message memory 300, IBSYS is reset.
  • the host CPU 102 may write the next message to be transferred into the input buffer 400.
  • IBSYH Input Buffer Busy Host
  • the identification can be further refined. Writes the host CPU 102 just IBRH, so the
  • the mechanism thus described allows the host CPU 102 to continuously transfer data to the message memory embedding objects consisting of the header area HB and the data area DB, provided the access speed of the host CPU 102 to the input buffer memory is less than or equal to the internal data transfer rate of the FlexRay. IP module so the communication block 100th
  • FIG. 7 once again shows the communication module 100, with only the rele ⁇ vant parts of the communication module 100 being shown here for reasons of clarity.
  • the message manager 200 responsible for controlling the processes as well as two control registers 703 and 704 which, as shown, can be accommodated outside the message manager 300 in the communication module 100, but can also be contained in the message administrator 200 itself.
  • 703 represents the output request register
  • Output Buffer Command Request Register and 704 the Output Buffer Command Mask Register.
  • Read accesses of the host CPU 102 to the message memory 300 thus take place via the intermediate output buffer 202 (output buffer).
  • This output buffer memory 202 is now likewise divided or doubled, specifically as a partial buffer memory 701 and a shadow memory 700 belonging to the buffer memory.
  • the accesses are controlled via the output request register 703 and via the input mask register 704. Also in the register 703, with the numbers from 0 to 31, the respective bit positions in
  • bit positions 0 to 5, 8 and 9, 15 and 16 to 21 of the register 703 receive a special function with respect to the sequence of the read access control.
  • an identifier OBRS Output Buffer Request Shadow
  • OBRH Output Buffer Request Host
  • an identifier OBSYS Output Buffer Busy Shadow
  • RDSS Read Data Section Shadow
  • RHSS Read Header Section Shadow
  • Further data identifiers are provided, for example, in the bits 16 and 17 with RDSH (Read Data Section Host) and RHSH (Read Header Section Host). These data identifications are here also exemplary in the simplest form, namely each formed as a bit.
  • REQ Read Data Section Host
  • a switch-over identifier VIEW is provided, which is entered as an example in position 8 of register 703.
  • the host CPU 102 requests the data of a message object from the message memory 300 by writing the identifier of the desired message, that is to say in particular the number of the desired object, according to OBRS in the bit positions 0 to 5 of the register 703.
  • the host CPU can either read only the status or configuration and header data KD of a message from a header area or only the data D actually to be transmitted from the data area or both , Which part of the data is to be transmitted from the header area and / or the data area is thus set comparable to the opposite direction by RHSS and RDSS. That means RHSS indicates whether the
  • Header data should be read and RDSS indicates whether the actual data should be read.
  • a start identifier serves to start the transmission from the message memory to the shadow memory 700. That is, when a bit is used as the identifier as in the simplest case, the transmission from the message memory 300 to the shadow memory 700 is started by setting bit REQ in bit position 9 in the output request register 703. The ongoing transmission is again indicated by an access identifier, here again in the simplest case by a bit OBSYS in the register 703. In order to avoid collisions, it is advantageous if the bit REQ can only be set if OBSYS is not set. is set so is currently no ongoing transfer. The actual sequence could then be controlled on the one hand comparable to the opposite direction as described under FIGS.
  • read accesses of the host CPU 102 to the message memory 300 are made via an intermediate output buffer 202.
  • This output buffer like the input buffer, is designed in duplicate or in two parts for continuous access by the host CPU 102 to the message objects in the message memory 300 are to ensure. Again, the benefits of high data integrity and accelerated transmission are achieved.
  • the data transmission is performed by the message administrator 200 (message handler MHD).
  • the message manager 200 is shown in FIG.
  • the message administrator can be represented by several state machines or state machines, ie finite state machines, so-called finite state machines (FSM).
  • FSM finite state machines
  • a first fi The state machine is the IOBF FSM and designated 501 (Inpu Buffer State Machine).
  • This IOBF-FSM could also be divided into two finite-state machines per transmission direction with respect to the input buffer memory or the output buffer memory.
  • IBF-FSM I ⁇ put Buffer FSM
  • OBF-FSM Output Buffer FSM
  • AFSM AFSM
  • a finite-state machine is divided into two blocks 502 and 503 and serves the two channels A and B with respect to the memories 205 and 206, as described with reference to FIG.
  • a finite-state machine can be provided to operate both channels A and B or, as in the preferred form, designates a finite-state machine TBF1-FSM as 502 (transient buffer 1 (206, RAM A) state machine).
  • TBF2-FSM 503 Transient Buffer 2 (205, RAM B) State Machine).
  • Exemplary embodiment is an arbiter finite-state machine, the so-called AFSM, which is designated 500.
  • the data (KD and / or D) are in one by a Taktmit ⁇ tel, such as. a VCO (Voltage Controlled Oscillator), a quartz oscillator, etc. Generate th or transmitted from this adapted clock in the communication module.
  • the clock T can be genereirt in the block or externally, e.g. be given as a bus clock.
  • This arbiter finite state machine AFSM 500 alternately gives access to the message memory to one of the three finite state machines 501-503, in particular for one clock period T in each case. That The available time is divided according to the access requirements of the individual state machines 501, 502, 503 to these requesting state machines. If there is an access request from only one
  • Finite-state machine this receives 100% of the access line, ie all clocks T. If ei ⁇ ne access request from two state machine, each finite state machine receives 50% of the access time. Finally, if an access request from three state machines takes place, then each of the finite-state machines receives 1/3 of the access time. This optimally utilizes the available bandwidth.
  • the first finite-state machine labeled 501 ie IOBF-FSM executes the following actions as needed:
  • the state machine for channel A 502, ie TBFlFSM, performs the following actions: Data transfer from the selected message object in the message memory 300 to the buffer memory 206 of channel A.
  • Message is sought in the context of acceptance filtering and when sending the next message on channel A to be sent message object (transmit buffer).
  • TBF2-FSM ie the finite state machine for channel B in block 503.
  • This performs the data transfer from the selected message object in the message memory 300 to the buffer 205 of channel B and the data transfer from the buffer 205 to
  • the search function is analogous to TBF1-FSM for a matching message object in the message memory, whereby the message object (receive buffer) for storing a message received on channel B is searched during acceptance filtering and upon transmission the next message or message object to be sent on channel B (transmit buffer).
  • FIG. 11 shows again the processes and the transmission paths.
  • the three state machines 501 - 503 control the respective data transfers between the individual parts.
  • the host CPU is shown again at 102, the input buffer memory at 201 and the output buffer memory at 202.
  • the message memory is represented by 300 and the two buffer memories for channel A and channel B are shown as 206 and 205.
  • the interface elements 207 and 208 are also shown.
  • the first state machine IOBF-FSM, designated 501 controls the data transfer ZlA and
  • the data is transmitted via data buses having a word width of, for example, 32 bits, whereby any other bit number is possible.
  • This data transmission is performed by TBF1-FSM, So 502 the state machine for channel A, controlled.
  • the transmission Z3 between message memory 300 and buffer memory 205 is controlled by the state machine TBF2-FSM, ie 503.
  • the data transfer takes place via data buses with an exemplary word width of 32 bits, whereby here too every other bit number is possible.
  • the transfer of a complete message object via the said transmission paths requires several clock periods T.
  • Time can be exchanged only on one of the paths shown so ZlA and ZlB and Z2 and Z3 at the same time data.
  • FIG 12 shows an example of how the available system clocks T are divided by the arbiter, ie the AFSM 500, into the three requesting state machines.
  • access requests are made by state machine 501 and state machine 502, that is, half of the time is shared between the two requesting state machines.
  • the access is done only by the state machine 501, so that every three clock periods, ie 100% of the access time from T5 to T7 to IOBF-FSM omitted.
  • access requests are made to all three state machines 501 to 503, so that a third of the total access time takes place.
  • the arbiter AFSM then distributes the access time, for example, so that in the clock periods T8 and Tl 1, the finite state machine 501, in the clock periods
  • La Phase 4 is accessed by two state machines 502 and 503 on the two channels A and B of the communication module, so that an access distribution of the clock periods T14 and T16 to finite state machine 502 and in T15 and T17 to finite state -Machine 503 takes place.
  • the arithmetic state machine AFSM 500 thus ensures that, if more than one of the three state machines makes a request for access to the message memory 300, the access is split in cycles and alternately to the requesting accessory state machines.
  • This procedure represents the integrity of the memory memory stored message objects, so the data integrity, safe. If, for example, the host CPU 102 wants to read out a message object via the output buffer 202 while a received message is being written to this message object, then either the old state or the new state will be read out, irrespective of which request was first started Accesses in the message object collide in the message memory itself.
  • the described method allows the host CPU to read or write any message object in the message memory during operation without the selected message object being affected by the data exchange on both channels of the FlexRay for the duration of the access of the host CPU Bus would be blocked (Buffer Locking). At the same time, the integrity of the data stored in the message memory is ensured by the intermittent interleaving of the accesses, and the transmission speed is increased, even by utilizing the full bandwidth.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Information Transfer Systems (AREA)
  • Small-Scale Networks (AREA)
  • Details Of Aerials (AREA)
  • Transceivers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

FlexRay ist ein schnelles, deterministisches und Felhertolerantes Bussystem, das in Kraftfahrzeugen verwendet wird. Daher ist eine einfache Kopplung von verschiedenen Einrichtungen notwendig. Diese wird erreicht durch einen FlexRay-Kommunikationsbaustein (100), der zur Kopplung einer FlexRay-Kommunikationsverbindung (101) mit einem zugeordneten Teilnehmer (102) in einem FlexRay-Netzwerk benützt wird, über welches Botschaften übertragen werden, wobei der FlexRay-Kommunikationsbaustein (100) folgende Bestandteile enthält: eine erste Anordnung (105) zur Speicherung wenigstens eines Teils der übertragenen Botschaften und eine zweite Anordnung (104) zur Verbindung der ersten Anordnung (105) mit dem Teilnehmer (102) sowie eine dritte Anordnung (103) zur Verbindung der FlexRay-Kommunikationsverbindung (101) mit der ersten Anordnung (105).

Description

FlexRay-Kommunikationsbaustein
Stand der Technik
Die Erfindung betrifft einen FlexRay-Konimunikationsbaustein zur Kopplung einer FlexRay-Kommunikationsverbindung mit einem, dem FlexRay-Kommunikalionsbaustein zugeordneten Teilnehmer in einem FlexRay-Netzwerk, über welches Botschaften über¬ tragen werden.
Die Vernetzung von Steuergeräten, Sensorik und Aktuatorik mit Hilfe eines Kommunika- tionssystems und eines Bussystems, also einer Kommunikationsverbindung hat in den letzten Jahren beim Bau von modernen Kraftfahrzeugen oder auch im Maschinenbau, insbesondere im Werkzeugmaschinenbereich als auch in der Automatisierung, drastisch zugenommen. Synergieeffekte durch Verteilung von Funktionen auf mehrere Steuergerä¬ te können dabei erzielt werden. Man spricht hierbei von verteilten Systemen. Die Kom- munikation zwischen verschiedenen Stationen findet mehr und mehr über ein Bussystem, also ein Kommunikationssystem statt. Der Kommunikationsverkehr auf dem Bussystem, Zugriffs- und Empfangsmechanismen sowie Fehlerbehandlung werden über ein Protokoll geregelt. Ein bekanntes Protokoll hierzu ist das FlexRay-Protokoll, wobei im Augenblick die FlexRay-Protokollspezifikation v2.0 zugrunde liegt. Der FlexRay ist ein schnelles, deterministisches und fehlertolerantes Bussystem, insbesondere für den Einsatz in einem
Kraftfahrzeug. Das FlexRay-Protokoll arbeitet nach dem Verfahren des Time Division Multiple Access (TDMA), wobei den Komponenten also Teilnehmern bzw. den zu über¬ tragenden Botschaften feste Zeitschlitze zugewiesen werden, in denen sie einen exklusi¬ ven Zugriff auf die Kommunikationsverbindung haben. Die Zeitschlitze wiederholen sich dabei in einem festgelegten Zyklus, so dass der Zeitpunkt, zu dem eine Botschaft über den Bus übertragen wird, exakt vorausgesagt werden kann und der Buszugriff determinis¬ tisch erfolgt. Um die Bandbreite für die Botschaftsübertragung auf dem Bussystem opti¬ mal zu nutzen unterteilt FlexRay den Zyklus in einen statischen und einen dynamischen Teil. Die festen Zeitschlitze befinden sich dabei im statischen Teil am Anfang eines Bus- zyklusses. Im dynamischen Teil werden die Zeitschlitze dynamisch vergeben. Darin wird nun der exklusive Buszugriff jeweils nur fiir eine kurze Zeit, sogenannte Minislots, er¬ möglicht Nur wenn innerhalb eines Minislots ein Buszugriff erfolgt, wird der Zeitschlitz um die benötigte Zeit verlängert. Damit wird Bandbreite also nur verbraucht, wenn sie auch tatsächlich benötigt wird. Dabei kommuniziert FlexRay über zwei physikalisch ge- trennte Leitungen mit einer Datenrate von je maximal 10 MByte/s. Die beiden Kanäle entsprechen dabei der physikalischen Schicht, insbesondere des OSI (Open System Ar- chitecture) Schichtenmodells. Diese dienen nun hauptsächlich der redundanten und damit fehlertoleranten Übertragung von Botschaften, können jedoch auch unterschiedliche Bot¬ schaften übertragen, wodurch sich dann die Datenrate verdoppeln würde. FlexRay kann aber auch mit niedrigeren Datenraten betrieben werden.
Um synchrone Funktionen zu realisieren und die Bandbreite durch kleine Abstände zwi¬ schen zwei Botschaften zu optimieren benötigen die verteilten Komponenten im Kom¬ munikationsnetzwerk, also die Teilnehmer, eine gemeinsame Zeitbasis, die sogenannte globale Zeit. Für die Unsynchronisation werden Synchronisationsnachrichten im stati¬ schen Teil des Zyklus übertragen, wobei mit Hilfe eines speziellen Algorithmus entspre¬ chend der FlexRay-Spezifϊkation die lokale Uhrzeit einer Komponente so korrigiert wird, dass alle lokalen Uhren zu einer globalen Uhr synchron laufen.
Ein FlexRay-Netzknoten oder FlexRay-Teilnehmer oder Host enthält einen Teilnehmer¬ prozessor, also den Host-Prozessor einen FlexRay-Controller oder Kommunikationscont¬ roller sowie bei einer Busüberwachung einen Busguardian. Dabei liefert und verarbeitet der Host-Prozessor, also der Teilnehmerprozessor die Daten, die über den FlexRay- Kommunikationscontroller übertragen werden. Für die Kommunikation in einem Flex- Ray-Netzwerk können Botschaften bzw. Botschaftsobjekte mit z.B. bis zu 254 Daten¬ bytes konfiguriert werden.
Aufgabe ist es nun, einen FlexRay-Kommunikationsbaustein zur Verfügung zu stellen, der in optimaler Weise die Kommunikation in einem FlexRay-Netzwerk unterstützt. Vorteile der Erfindung
Diese Aufgabe wird gelöst durch einen FlexRay-Kommunikationsbaustein zur Kopplung einer FlexRay-Kommunikationsverbindung als physikalische Schicht mit einem, dem FlexRay-Kommunikationsbaustein zugeordneten Teilnehmer in einem FlexRay-
Netzwerk, über welches Botschaften übertragen werden. Dabei enthält der FlexRay- Kommunikationsbaustein vorteilhafter Weise eine erste Anordnung zur Speicherung we¬ nigstens eines Teils der übertragenen Botschaften und eine zweite Anordnung zur Ver¬ bindung der ersten Anordnung mit dem Teilnehmer, sowie eine dritte Anordnung zur Verbindung der FlexRay-Kommunikationsverbindung, also der physikalischen Schicht mit der ersten Anordnung.
Dabei enthält die erste Anordnung vorteilhafter Weise einen Botschaftsverwalter, also Message Handler und einen Botschaftsspeicher, wobei der Botschaftsverwalter die Steue- rang bezüglich der Datenpfade der ersten und zweiten Anordnung bezogen auf einen Da¬ tenzugriff bezüglich des Botschaftsspeichers übernimmt. Dabei ist der Botschaftsspeicher der ersten Anordnung zweckmäßiger Weise in ein Kopfsegment und ein Datensegment aufgeteilt ist.
Vorteilhafter Weise enthält die zweite Anordnung zur Aribindung an den Host, also den
FlexRay-Teilnehmer bzw. den Host-Prozessor einen Eingangspufferspeicher und einen Ausgangspufferspeicher, wobei entweder der Eingangspufferspeicher oder der Aus¬ gangspufferspeicher oder am besten beide Speicher in einer bevorzugten Ausfuhrungs¬ form jeweils in einen Teilpufferspeicher und einen Schattenspeicher aufgeteilt sind, die jeweils wechselweise nur gelesen und/oder beschrieben werden, wodurch die Dateninteg¬ rität gewährleistet wird. Das wechselweise Lesen bzw. Beschreiben des jeweiligen Teil¬ pufferspeichers und zugehörigen Schattenspeichers kann vorteilhafterweise durch Ver¬ tauschen des jeweiligen Zugriffs erzielt werden oder durch Vertauschen des Speicherin¬ halts.
Dabei ist es vorteilhaft, wenn jeder Teilpufferspeicher und jeder Schattenspeicher derart ausgelegt ist, dass je ein Datenbereich und/oder ein Kopfbereich zweier FlexRay- Botschaften speicherbar ist. Zur problemloseren Anpassung an unterschiedliche Teilnehmer oder Hosts enthält die zweite Anordnung einen Schnittstellenbaustein, der aus einem teilnehmerspezifischen Teilbaustein und einem teilnehmerunabhängigen Teilbaustein besteht, so dass zur Tei- nehmeranpassung lediglich der teilnehmerspezifische Teilbaustein geändert werden muss und so insgesamt die Flexibilität des FlexRay-Kommunikationsbausteins erhöht wird.
Dabei können die Teilbausteine auch innnerhalb des einen Schnittstellenbausteins jeweils in Software, also jeder Teilbaustein als Softwarefunktion realisiert werden.
Entsprechend der redundanten Übertragungswege bei FlexRay enthält die dritte Anord- nung vorteilhafter Weise einen ersten Schnittstellenbaustein und einen zweiten Schnitt¬ stellenbaustein und ist ihrerseits in zwei Datenpfade mit jeweils zwei Datenrichtungen aufgeteilt. Zweckmäßiger Weise enthält die dritte Anordnung auch einen ersten und einen zweiten Pufferspeicher, um den beiden Datenpfaden und den jeweils zwei Datenrichtun¬ gen Rechnung zu tragen. Dabei sind auch hier der erste und zweite Pufferspeicher derart ausgelegt, dass wenigstens j e ein Datenbereich zweier FlexRay-Botschaften speicherbar ist. Vorteilhafter Weise enthält jeder Schnittstellenbaustein der dritten Anordnung ein Schieberegister und eine FlexRay-Protokoll-Zustandsmaschine.
Durch den erfindungsgemäßen FlexRay-Kommunikationsbaustein kann die FlexRay- Protokollspezifikation, insbesondere v2.0, vollständig unterstützt werden und es sind da¬ mit z.B. bis zu (A Botschaften bzw. Botschaftsobjekte konfigurierbar. Dabei ergibt sich ein flexibel konfigurierbarer Botschaftsspeicher für die Speicherung einer unterschiedli¬ chen Anzahl von Botschaftsobjekten abhängig von der Größe des jeweiligen Datenfeldes bzw. Dateribereicb.es der Botschaft. Somit sind also vorteilhafter Weise Botschaften- oder Botschaftsobjekte zu konfigurieren, die unterschiedlich lange Datenfelder besitzen. Der
Botschaftsspeicher ist dabei vorteilhafter Weise als FIFO (first in-first out) ausgebildet, so dass sich ein konfigurierbarer Empfangs-FIFO ergibt. Jede Botschaß bzw. jedes Bot¬ schaftsobjekt im Speicher kann als Empfangsspeicherobjekt (Receive-Buffer), Sende¬ speicherobjekt (Transmit-Buffer) oder als Teil des konfigurierbaren Empfangs-FIFOs konfiguriert werden. Ebenso ist eine Akzeptanzfilterung auf Frame-ID, Channel-ID und
Cycle-Counter im FlexRay-Netzwerk möglich. Zweckmäßiger Weise wird somit das Netzwerkmanagement unterstützt Vorteilhafter Weise sind außerdem maskierbare Mo¬ dulinterrupts vorgesehen.
Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus den Merkmalen der Ansprüche ebenso wie aus der Beschreibung. Zeichnung
Die Erfindung wird anhand der nachfolgenden Figuren der Zeichnung näher erläutert.
Dabei zeigt Figur 1 in schematischer Darstellung den Kommunikationsbaustein und des¬ sen Anbindung an die physikalische Schicht, also die Kommunikationsverbindung und den Kommunikations- oder Host-Teilnehmer.
Figur 2 stellt in einer speziellen Ausführungsform Kommunikationsbaustein aus Figur 1 sowie dessen Anbindung detaillierter dar.
Ih Figur 3 ist die Struktur des Botschaftsspeichers dargestellt.
Figur 4 bis 6 beschreibt schematisch die Architektur und den Prozess des Datenzugriffs in
Richtung vom Teilnehmer zum Botschaftsspeicher.
Figur 7 bis 9 beschreibt schematisch Architektur und Prozess des Datenzugriffs in Rich¬ tung vom Botschaftsspeicher zum Teilnehmer.
Ih Figur 10 ist der Botschaftsverwalter und die darin enthaltenen Finit-State-Maschinen schematisch dargestellt.
Figur 11 zeigt noch einmal schematisch die Bauteile des Kommunikatinsbausteins sowie den Teilnehmer und die entsprechenden, durch den Botschaftsverwalter gesteuerten Da¬ tenpfade.
Figur 12 beschreibt die Zugriffsverteilung bezogen auf die Datenpfade in Figur 11.
Die Erfindung wird nachfolgend anhand der Ausfuhrungsbeispiele näher erläutert. Ausführungsbeispiele
Figur 1 zeigt schematisch einen FlexRay-Kommiinikationsbaustein 100 zur Anbindung eines Teilnehmers oder Hoste 102 an eine FlexRay-Kommunikationsverbindung 101, also die physikalische Schicht des FlexRay. Dazu ist der FlexRay-Kommunikationsbaustein
100 über eine Verbindung 107 mit dem Teilnehmer bzw. Teilnehmerprozessor 102 und über eine Verbindung 106 mit der Kommunikationsverbindung 101 verbunden. Zur prob¬ lemlosen Anbindung zum einen bezogen auf Übertragungszeiten und zum anderen bezo¬ gen auf die Datenintegrität sind schematisch im Wesentlichen drei Anordnungen im FlexRay-Kommunikationsbaustein unterschieden. Dabei dient eine erste Anordnung 105 zur Speicherung, insbesondere Zwischenablage, wenigstens eines Teils der zu übertra¬ genden Botschaften. Zwischen dem Teilnehmer 102 und dieser ersten Anordnung 105 ist über die Verbindungen 107 und 108 eine zweite Anordnung 104 geschaltet. Ebenso ist zwischen Teilnehmer 101 und die erste Anordnung 105 eine dritte Anordnung 103 über die Verbindungen 106 und 109 geschaltet, wodurch ein sehr flexibles Eingeben und Aus¬ geben von Daten als Teil von Botschaften, insbesondere FlexRay-Botschaften in bzw. aus der ersten Anordnung 105 mit Gewährleistung der Datenintegrität bei optimaler Ge¬ schwindigkeit erzielbar ist.
In Figur 2 ist dieser Kommunikationsbaustein 100 in einer bevorzugten Ausführungsform noch einmal detaillierter dargestellt. Ebenso detaillierter dargestellt sind die jeweiligen Verbindungen 106 bis 109. Die zweite Anordnung 104 enthält dabei einen Eingangspuf¬ ferspeicher oder Eingabepufferspeicher 201 (Thput Buffer IBF), einen Ausgangspuffer¬ speicher oder Ausgabepufferspeicher 202 ( Output Buffer OBF) sowie einen Schnittstel- lenbaustein bestehend aus zwei Teilen 203 und 204, wobei der eine Teilbaustein 203 teil- nehrnerunabhängig und der zweite Teilbaustein 204 teilnehmerspezifisch ist. Der teil¬ nehmerspezifische Teilbaustein 204 (Customer CPU Interface CIF) verbindet eine teil¬ nehmerspezifische Host-CPU 102, also einen kundenspezifischen Teilnehmer mit dem FlexRay-Kommunikationsbaustein. Dazu ist eine bidirektionale Datenleitung 216, eine Adressleitung 217 sowie ein Steuereingang 218 vorgesehen. Ebenso vorgesehen ist mit
219 ein Interrupt- oder Unterbrechungs-Ausgang. Der teilnehmerspezifϊsche Teilbaustein 204 steht in Verbindung mit einem teilnehmerunabhängigen Teilbaustein 203 (Generic CPU Interface, GIF), d. h. der FlexRay-Kommunikationsbaustein oder das FlexRay-IP- Modul verfügt über ein generisches, also allgemeines, CPU-Interface, an das sich über entsprechende teilnehmerspezifische Teilbausteine, also Customer CPU Interfaces CEF eine große Anzahl von unterschiedlichen kundenspezifischen Host CPU's anschliessen lassen. Dadurch muss abhängig vom Teilnehmer nur der Teilbaustein 204 variiert wer¬ den, was einen deutlich geringeren Aufwand bedeutet.
Der Eingäbepufferspeicher oder Eingangspufferspeicher 201 und der Ausgangspuffer¬ speicher oder Ausgäbepufferspeicher 202 können in einem Speicherbaustein oder aber in getrennten Speicherbausteinen ausgebildet sein. Dabei dient der Eingabepufferspeicher 201 für die Zwischenspeicherung von Botschaften für die Übertragung zum Botschafts¬ speicher 200. Dabei ist der Eingabepufferbaustein vorzugsweise so ausgebildet, dass er zwei vollständige Botschaften bestehend aus jeweils einem Kopfsegment oder Header¬ segment, insbesondere mit Konfigurationsdaten und ein Datensegment oder Payload Segment speichern kann. Dabei ist der Eingabepufferspeicher zweiteilig (Teilpufferspei¬ cher und Schattenspeicher) ausgebildet, wodurch sich durch wechselweises Schreiben der beiden Teile des Eingabepufferspeichers bzw. durch Zugriffewechsel die Übertragung zwischen Teilnehmer-CPU 102 und Botschaftsspeicher 200 beschleunigen lässt. Ebenso dient der Ausgabepufferspeicher oder Ausgangspufferspeicher (Output-Buffer OBF) für die Zwischenspeicherung von Botschaften für die Übertragung vom Botschaftsspeicher 200 zur Teilnehmer-CPU 102. Dabei ist auch der Ausgabepuffer 202 so gestaltet, dass zwei komplette Botschaften bestehend aus Kopfsegment, insbesondere mit Konfigurati- onsdaten und Datensegment, also Payload Segment, gespeichert werden können. Auch hier ist der Ausgabepufferspeicher 202 in zwei Teile, einen Teilpufferspeicher und einen Schattenspeicher aufgeteilt, wodurch sich auch hier durch wechselweises Lesen der bei¬ den Teile die Übertragung bzw. durch Zugriffswechsel die Übertragung zwischen Teil¬ nehmer- bzw. Host-CPU 102 und Botschaftsspeicher 200 beschleunigen lässt. Diese zweite Anordnung 104 bestehend aus den Blöcken 201 bis 204 ist mit der ersten Anord¬ nung 105 wie dargestellt verbunden.
Die Anordnung 105 besteht aus einem Botschaftsverwalter 200 (Message Handler MHD) und einem Botschaftsspeicher 300 (Message RAM). Der Botschaftsverwalter kontrolliert bzw. steuert den Datentransfer zwischen dem Eingabepufferspeicher 201 sowie Ausgäbe¬ pufferspeicher 202 und dem Botschaftsspeicher 300. Gleichermaßen kontrolliert bzw. steuert er die Datenübertragung in der anderen Richtung über die dritte Anordnung 103. Der Botschaftsspeicher ist vorzugsweise als single-ported RAM ausgeführt. Dieser RAM- Speicher speichert die Botschaften bzw. Botschaftsobjekte, also die eigentlichen Daten, zusammen mit Konfigurations- und Statusdaten. Die genaue Struktur des Botschaftsspei¬ chers 300 ist in Figur 3 näher dargestellt.
Die dritte Anordnung 103 besteht aus den Blöcken 205 bis 208. Entsprechend den beiden Kanälen des FlexRay Physical Layer ist diese Anordnung 103 in zwei Datenpfade mit je zwei Datenrichtungen aufgeteilt. Dies wird durch die Verbindungen 213 und 214 deut¬ lich, worin die beiden Datenrichtungen für den Kanal A, RxA und TxA für Empfangen (RxA) und Senden (TxA) sowie für Kanal B, RxB und TxB dargestellt sind. Mit Verbin¬ dung 215 ist ein optionaler bidirektionaler Steuereingang bezeichnet. Die Anbindung der dritten Anordnung 103 erfolgt über einen ersten Pufferspeicher 205 für Kanal B und ei¬ nen zweiten Pufferspeicher 206 für Kanal A. Diese beiden Pufferspeicher (Transient Buf¬ fer RAM's: RAM A und RAM B) dienen als Zwischenspeicher für die Datenübertragung von bzw. zu der ersten Anordnung 105. Entsprechend der beiden Kanäle sind diese bei¬ den Pufferspeicher 205 und 206 mit jeweils einem Schnittstellenbaustein 207 und 208 verbunden, die die FlexRay-Protokoll-Controller oder Busprotokoll-Controller bestehend aus einem Sende-ZEmpfangs-Schieberegister und der FlexRay Protokoll Finite State Ma¬ schine, enthalten. Die beiden Pufferspeicher 205 und 206 dienen somit als Zwischenspei¬ cher für die Datenübertragung zwischen den Schieberegistern der Schnittstellenbausteine oder FlexRay Protokoll Controller 207 und 208 und dem Botschaftsspeicher 300. Auch hier werden vorteilhafter Weise durch jeden Pufferspeicher 205 oder 206 die Datenfelder, also das Payload Segment oder Datensegment zweier FlexRay-Botschaften gespeichert.
Weiterhin dargestellt im Kommunikationsbaustein 100 ist mit 209 die globale Zeiteinheit (Global Time Unit GTU), welche für die Darstellung der globalen Zeitraster im FlexRay, also den Mikrotick μT und den Makrotick MT zuständig ist. Ebenso wird über die globa¬ le Zeiteinheit 209 die fehlertolerante Uhrensynchronisation der Zykluszähler (Cycle Counter) und die Kontrolle der zeitlichen Abläufe im statischen und dynamischen Seg¬ ment des FlexRay geregelt.
Mit Block 210 ist die allgemeine Systemsteuerung (System Universal Control SUC) dar¬ gestellt, durch welche die Operationsmodi des FlexRay-Kommunikationscontrollers kon¬ trolliert und gesteuert werden. Dazu gehören der Wakeup, der Startup, die Reintegration bzw. Integration, Normaloperation (normal Operation) und passive Operation (passive Operation). Block 211 zeigt das Netzwerk und Fehlermanagement (Network- und Error Management NEM), wie in der FlexRay-Protokollspezifikation v2.0 beschrieben. Block 212 schlie߬ lich zeigt die Unterbrechungssteuerung (Interrupt Control INT), welche die Status- und Fehlerunterbrechungsflaggen (status and error interrupt flags) verwaltet und die Unter- brechungsausgänge 219 zur Teilnehmer-CPU 102 kontrolliert bzw. steuert. Der Block
212 enthält außerdem einen absoluten und einen relativen Timer bzw. Zeitgeber zur Er¬ zeugung der Zeitunterbrechungen oder Timerinterrupts.
Für die Kommunikation in einem FlexRay-Netzwerk können Botschaftsobjekte bzw. Botschaften (Message Buffer) mit bis zu 254 Datenbytes konfiguriert werden. Der Bot¬ schaftsspeicher 300 ist insbesondere ein Botschafts-RAM-Speicher (Message RAM), welcher z.B. bis zu maximal 64 Botschaftsobjekten speichern kann. Alle Funktionen, die die Behandlung bzw. Verwaltung der Botschaften selbst betreffen, sind dem Botschafts¬ verwalter oder Message Handler 200 implementiert. Dies sind z.B. die Akzeptanzfilte- rung, Transfer der Botschaften zwischen den beiden FlexRay-Protokoll-Controller-
Blöcken 207 und 208 und dem Botschaftsspeicher 300, also dem Message RAM sowie die Kontrolle der Sendereihenfolge und das Bereitstellen von Konfigurationsdaten bzw. Statusdaten.
Eine externe CPU, also ein externer Prozessor der Teilnehmerprozessor 102 kann über die Teimehmerschnittstelle, mit dem teilnehmerspezifischen Teil 204 direkt auf die Re¬ gister des FlexRay-Kommunikationsbausteins zugreifen. Dabei wird eine Vielzahl von Registern verwendet. Diese Register werden eingesetzt, um die FlexRay Protokoll Cont¬ roller, also die Schnittstellenbausteine 207 und 208 den Botschaftsverwalter (Message Handler MHD) 200, die globale Zeiteinheit (Global Time Unit GTU) 209, den allgemei¬ nen Systemcontroller (System Universal Controller SUC) 210, die Netzwerk- und Feh- lermanagementemheit (Network und Error Management Unit NEM) 211, den Unterbre¬ chungscontroller (Interrupt Controller INT) 212 sowie den Zugriff auf das Message RAM, also den Botschaftsspeicher 300 zu konfigurieren und zu steuern und ebenso den entsprechenden Status anzuzeigen. Zumindest auf Teile dieser Register wird noch in den
Figuren 4 bis 6 und 7 bis 9 näher eingegangen. Ein solch beschriebener, erfindungsgemä- ßer FlexRay-Kommunikationsbaustein ermöglicht die einfache Umsetzung der FlexRay- Spezifikation v2.0, wodurch einfach ein ASIC oder ein MikroController mit entsprechen¬ der FlexRay-Funktionalität generiert werden kann. Ia Figur 3 ist detailliert die Aufteilung des Botschaftsspeichers 300 beschrieben. Für die nach der FlexRay-Protokollspezifikation geforderte Funktionalität eines FlexRay- Kommunikationscontrollers wird ein Botschaftsspeicher für das Bereitstellen von zu sen¬ denden Botschaften (Transmit Buffer) sowie das Abspeichern von fehlerfrei empfange- nen Botschaften (Receive Buffer) benötigt. Ein FlexRay-Protokoll erlaubt Botschaften mit einem Datenbereich, also einem Payload-Bereich von 0 bis 254 Bytes. Wie in Figur 2 dargestellt ist der Botschaftsspeicher Teil des FlexRay-Kommunikationsbausteins 100. Das nachfolgend beschriebene Verfahren sowie der entsprechende Botschaftsspeicher be¬ schreiben die Speicherung von zu sendenden Botschaften sowie von empfangenen Bot- Schäften, insbesondere unter Verwendung eines Random Access Memory (RAM), wobei es durch den erfindungsgemäßen Mechanismus möglich ist in einem Botschaftsspeicher vorgegebener Größe eine variable Anzahl von Botschaften zu speichern. Dabei ist die Anzahl der speicherbaren Botschaften abhängig von der Größe der Datenbereiche der einzelnen Botschaften, wodurch zum einen die Größe des benötigten Speichers minimiert werden kann ohne die Größe der Datenbereiche der Botschaften einzuschränken und zum anderen eine optimale Ausnutzung des Speichers erfolgt. Im Folgenden nun soll diese va¬ riable Aufteilung eines insbesondere RAM-basierten Botschaftsspeichers für einen Flex- Ray Communication Controller näher beschrieben werden.
Zur Implementierung wird nun beispielhaft ein Botschaftsspeicher mit einer festgelegten
Wortbreite von n Bit, beispielsweise 8, 16, 32 usw., sowie einer vorgegebenen Speicher¬ tiefe von m Worten vorgegeben (m,n als natürliche Zahlen). Dabei wird der Botschafts- speicher 300 in zwei Segmente aufgeteilt, ein Header Segment oder Kopfsegment HS und ein Datensegment DS (Payload Section, Payload Segment). Pro Botschaft wird somit ein Headerbereich HB und ein Datenbereich DB angelegt. Für Botschaften 0, 1 bis k (k als natürliche Zahl) werden somit Headerbereiche oder Kopfbereiche HBO, HBl bis HBk und Datenbereiche DBO, DBl bis DBk angelegt. In einer Botschaft wird also zwischen ersten und zweiten Daten unterschieden, wobei die ersten Daten Konfϊgurationsdalen und/oder Statusdaten bezüglich der FlexRay Botschaft entsprechen und jeweils in einem Headerbereich HB (HBO, HBl, ..., HBk) abgelegt werden. Die zweiten Daten, die den ei¬ gentlichen Daten entsprechen, die übertragen werden sollen, werden entsprechend in Da- teribereichen DB (DBO, DBl, ... , DBk) abgelegt. Somit entsteht für die ersten Daten pro Botschaft ein erster Datenumfang (in Bit, Byte oder Speicherworten gemessen) und für die zweiten Daten einer Botschaft ein zweiter Datenumfang (ebenfalls in Bit, Byte oder Speicherworten gemessen), wobei der zweite Datenumfang pro Botschaft unterschiedlich sein kann. Die Aufteilung zwischen Kopfsegment HS und Datensegment DS ist nun im Botschaftsspeicher 300 variabel, d. h. es existiert keine vorgegebene Grenze zwischen den Bereichen. Die Aufteilung zwischen Kopfsegment HS und Datensegment DS ist er¬ findungsgemäß abhängig von der Anzahl k der Botschaften sowie dem zweiten Datenum- fang, also dem Umfang der eigentlichen Daten, einer Botschaft bzw. aller k Botschaften zusammen. Erfindungsgemäß wird nun den Konfigurationsdaten KDO, KDl bis KDk der jeweiligen Botschaft ein Zeigerelement oder Datapointer DPO, DPI bis DPk jeweils di¬ rekt zugeordnet. In der speziellen Ausgestaltung wird jedem Kopf bereich HBO, HBl bis HBk eine feste Anzahl von Speicherworten, hier zwei, zugeordnet, so dass immer ein Konfigurationsdatum KD (KDO, KDl, ..., KDk) und ein Zeigerelement DP (DPO, DPI,
..., DPk) zusammen in einem Headerbereich HB abgelegt sind. An diesem Kopfsegment HS mit den Headerbereichen HB, dessen Größe bzw. erster Datenumfang abhängig von der Anzahl k der zu speichernden Botschaften ist, schließt das Datensegment DS zur Speicherung der eigentlichen Botschaftsdaten DO, Dl bis Dk an. Dieses Datensegment (oder Dalensection) DS hängt in seinem Datenumfang vom jeweiligen Datenumfang der abgelegten Botschafttsdaten ab, hier z.B. in DBO sechs Worte, DBl ein Wort und DBk zwei Worte. Die jeweiligen Zeigerelemente DPO, DPI bis DPk zeigen somit immer zum Beginn, also auf die Anfangsadresse des jeweiligen Datenbereichs DBO, DBl bis DBk, in denen die Daten DO, Dl bis Dk der jeweiligen Botschaften 0, 1, bis k abgelegt sind. Da- mit ist die Aufteilung des Botschaftsspeichers zwischen Kopfsegment HS und Datenseg¬ ment DS variabel und hängt von der Anzahl der Botschaften selbst sowie dem jeweiligen Datenumfang einer Botschaft und damit dem gesamten zweiten Datenumfang ab. Werden weniger Botschaften konfiguriert, wird das Kopfsegment kleiner und der frei werdende Bereich im Botschaftsspeicher kann als Zusatz zum Datensegment DS für die Speiche- rung von Daten verwendet werden. Durch diese Variabilität kann eine optimale Spei¬ cherausnutzung gewährleistet werden, womit auch die Verwendung kleinerer Speicher möglich ist. Das freie Datensegment FDS »insbesondere dessen Größe, ebenfalls abhän¬ gig von der Kombination aus Anzahl k der gespeicherten Botschaften und dem jeweiligen zweiten Datenumfang der Botschaften ist somit minimal und kann sogar 0 werden.
Neben der Verwendung von Zeigerelementen ist es auch möglich, die ersten und zweiten Daten, also die Konfigurationsdaten KD (KDO, KDl, ..., KDk) und die eigentlichen Da¬ ten D (D=, Dl, ... ,Dk) in einer vorgebbaren Reihenfolge abzulegen, so dass die Reihen¬ folge der Kopfbereiche HBO bis HBk im Kopfsegment HS und die Reihenfolge der Da- tenbereiche DBO bis DBk im Datensegment DS jeweils identisch ist. Dann könnte unter Umständen sogar auf ein Zeigerelement verzichtet werden.
In einer besonderen Ausgestaltung ist dem Botschaftsspeicher ein Fehlerkennungserzeu- ger, insbesondere ein Parity-Bit-Generator-Element und ein Fehlerkennungsprüfer, insbe¬ sondere ein Parity-Bit-Prüf-Element zugeordnet, um die Korrektheit der gespeicherten Daten in HS und DS zu gewährleisten, indem pro Speicherwort oder pro Bereich (HB und/oder DB) eine Priifsumme eben insbesondere als Parity-Bit mit abgelegt werden kann. Andere Kontrollkennungen, z.B. ein CRC (Cyclic redundancy check) oder auch Kennungen höherer Mächtigkeit wie ECC ( Error Code Correction) sind denkbar. Damit sind gegenüber einer festgelegten Aufteilung des Botschaftsspeichers folgende Vorteile gegeben:
Der Anwender kann bei der Programmierung entscheiden, ob er eine größere Anzahl von Botschaften mit kleinem Datenfeld oder ob er eine kleinere Anzahl von Botschaften mit großem Datenfeld verwenden möchte. Bei der Konfiguration von Botschaften mit unter¬ schiedlich großem Datenbereich wird der vorhandene Speicherplatz optimal ausgenutzt. Der Anwender hat die Möglichkeit einen Datenspeicherbereich gemeinsam für unter¬ schiedliche Botschaften zu nutzen.
Bei der Implementierung des Cominunication Controllers auf einer integrierten Schaltung kann die Größe des Botschaftsspeichers durch Anpassung der Speichertiefe des verwen¬ deten Speichers an die Bedürfhisse der Applikation angepasst werden, ohne die sonstigen Funktionen des Communication Controllers zu ändern.
Im Weiteren wird nun anhand der Figuren 4 bis 6 sowie 7 bis 9 der Host-CPU-Zugriff, also Schreiben und Lesen von Konfigurationsdaten bzw. Statusdaten und der eigentlichen Daten über die Pufferspeicheranordnung 201 und 202 näher beschrieben. Dabei ist es das Ziel, eine Entkopplung bezüglich der Datenübertragung derart herzustellen, dass die Da- tenintegrität sichergestellt werden kann und gleichzeitig eine hohe Übertraglingsge¬ schwindigkeit gewährleistet ist. Die Steuerung dieser Vorgänge erfolgt über den Bot¬ schaftsverwalter 200, was später noch näher in den Figuren 10, 11 und 12 beschrieben wird. In den Figuren 4, 5 und 6 werden zunächst die Schreibzugriffe auf den Botschaßsspeicher 300 durch die Host-CPU der Teilnehmer-CPU 102 über den Eingangspufferspeicher 201 näher erläutert. Dazu zeigt Figur 4 noch einmal den Kommunikationsbaustein 100, wobei aus Gründen der Übersichtlichkeit nur die hier relevanten Teile des Kommunikationsbau- Steins 100 gezeigt sind. Dies ist zum einen der für die Steuerung der Abläufe verantwort¬ liche Botschaftsverwalter 200 sowie zwei Kontrollregister 403 und 404, die wie darge¬ stellt außerhalb des Botschaftsverwalters 200 im Kommunikationsbaustein 100 unterge¬ bracht sein können, aber auch im Botschaftsverwalter 200 selbst enthalten sein können. 403 stellt dabei das Eingangs- Anforderungsregister (Ihput Buffer Command Request Re- gister) dar und 404 das Eingangs-Maskierungsregister (Input Buffer Command Mask Re¬ gister). Schreibzugriffe der Host-CPU 102 auf den Botschaftsspeicher 300 (Message RAM) erfolgen also über einen zwischengeschalteten Eingangspufferspeicher 201 (Input Buffer). Dieser Eingangspufferspeicher 201 ist nun geteilt bzw. gedoppelt ausgelegt, und zwar als Teilpufferspeicher 400 und einem zu dem Teilpufferspeicher zugehörigen Schat- tenspeicher 401. Damit kann wie nachfolgend beschrieben ein kontinuierlicher Zugriff der Host-CPU 102 auf die Botschaften bzw. Botschaftsobjekte respektive Daten des Bot¬ schaftsspeichers 300 erfolgen und damit Datenintegrität und beschleunigte Übertragung gewährleistet werden. Die Steuerung der Zugriffe erfolgt über das Eingangs- Anforderungsregister 403 und über das Eingangs-Maskierungsregister 404. Im Register 403 sind mit den Zahlen von 0 bis 31 die jeweiligen Bitstellen in 403 hier beispielhaft für eine Breite von 32 Bit dargestellt. Gleiches gilt für das Register 404 und die Bitstellen 0 bis 31 in 404.
Erfindungsgemäß erhalten nun beispielhaft die Bitstellen 0 bis 5, 15, 16 bis 21 und 31 des Registers 403 bezüglich der Ablaufsteuerung eine besondere Funktion. So ist in die Bit¬ stellen 0 bis 5 des Registers 403 eine Kennung IBRH (biput Buffer Request Host) als Botschaftskennung eintragbar. Ebenso ist in die Bitstellen 16 bis 21 des Registers 403 ei¬ ne Kennung IBRS (Input Buffer Request Shaddow) eintragbar. Ebenso sind in Register¬ stelle 15 von 403 IBSYH und in Registerstelle 31 von 403 IBSYS als Zugriffskennungen eingetragen. Ausgezeichnet sind auch die Stellen 0 bis 2 des Registers 404, wobei in 0 und 1 mit LHSH (Load Header Section Host) und LDSH (Load Data Section Host) weite¬ re Kennungen als Datenkennungen eingetragen sind. Diese Datenkennungen sind hier in einfachster Form, nämlich jeweils als ein Bit ausgebildet. In Bitstelle 2 von Register 404 ist mit STXRH (Set Transmission X Request Host) eine Startkennung eingeschrieben. Im Weiteren wird nun der Ablauf des Schreibzugriffs auf den Botschaftsspeicher über den Eingangspuffer beschrieben.
Die Host-CPU 102 schreibt die Daten der zu transferierenden Botschaft in den Eingangs- Pufferspeicher 201. Dabei kann die Host-CPU 102 nur die Konfigurations- und Header¬ daten KD einer Botschaft für das Headersegment HS des Botschaftsspeichers oder nur die eigentlichen, zu übertragenden Daten D einer Botschaft für das Datensegment DS des Botschaftsspeichers oder beide schreiben. Welcher Teil einer Botschaft also Konfigurati¬ onsdaten und/oder die eigentlichen Daten übertragen werden soll, wird durch die speziel- len Datenkennungen LHSH und LDSH im Eingangs-Markierungsregister 404 festgelegt.
Dabei wird durch LHSH (Load Header Section Host) festgelegt ob die Headerdaten, also die Konfigurationsdaten KD, übertragen werden und durch LDSH (Load Data Section Host) festgelegt, ob die Daten D übertragen werden sollen. Dadurch, dass der Eingangs¬ pufferspeicher 201 zweiteilig mit einem Teil des Pufferspeichers 400 und einem dazuge- hörigen Schattenspeicher 401 ausgebildet ist und ein wechselseitiger Zugriff erfolgen soll sind als Gegenstück zu LHSH und LDSH zwei weitere Datenkennungsbereiche vorgese¬ hen, die nun auf den Schattenspeicher 401 bezogen sind. Diese Datenkennungen in den Bitstellen 16 und 17 des Registers 404 sind mit LHSS (Load Header Section Shadow) und LDSS (Load Data Section Shadow) bezeichnet. Durch diese wird somit der Übertra- gungsvorgang bezüglich des Schattenspeichers 401 gesteuert.
Ist nun das Startbit bzw. die Startkennung STXRH (Set Transmission X Request Host) in Bitstelle 2 des Eingangs-Maskierungsregisters 404 gesetzt, so wird nach erfolgtem Trans¬ fer der jeweils zu übertragenden Konfigurationsdaten und/oder eigentlichen Daten in den Botschaftsspeicher 300 automatisch eine Sendeanforderung (Transmission Request) für das entsprechende Botschaftsobjekt gesetzt. D. h. durch diese Startkennung STXRH wird das automatische Senden eines übertragenden Botschaftsobjekts gesteuert, insbesondere gestartet.
Das Gegenstück hierzu entsprechend für den Schattenspeicher ist die Startkennung
STXRS (Set Transmission X Request Shadow) welches beispielhaft in Bitstelle 18 des Eingangs-Markierungsregisters 404 enthalten ist und auch hier im einfachsten Fall eben als ein Bit ausgebildet ist. Die Funktion von STXRS ist analog der Funktion von STXRH, lediglich bezogen auf den Schattenspeicher 1. Wenn die Host-CPU 102 die Botschaftskennung, insbesondere die Nummer des Bot- schafisobjekts im Botschaftsspeicher 300 in welches die Daten des Eingangspufferspei¬ chers 201 transferiert werden sollen in die Bitstellen 0 bis 5 des Eingangs- Anforderungsregisters 403, also nach EBRH schreibt werden der TeilpufFerspeicher 400 des Eingangspufferspeichers 201 und der zugehörige Schattenspeicher 401 vertauscht bzw. es wird der jeweilige Zugriff von Host-CPU 102 und Botschaftsspeicher 300 auf die beiden Teilspeicher 400 und 401 vertauscht, wie durch die halbkreisförmigen Pfeile an¬ gedeutet. Dabei wird z.B. auch der Datentransfer, also die Datenübertragung zum Bot¬ schaftsspeicher 300 gestartet. Die Datenübertragung zum Botschaftsspeicher 300 selbst erfolgt aus dem Schattenspeicher 401. Gleichzeitig werden die Registerbereiche IBRH und IBRS getauscht. Ebenso getauscht werden LHSH und LDSH gegen LHSS und LDSS. Gleichermaßen getauscht wird STXRH mit STXRS. IBRS zeigt somit die Ken¬ nung der Botschaft, also die Nummer des Botschaftsobjektes iSr das eine Übertragung, also ein Transfer aus dem Schattenspeicher 401 im Gange ist bzw. welches Botschaftsob- jekt, also welcher Bereich im Botschaftsspeicher als letztes Daten (KD und/oder D) aus dem Schattenspeicher 401 erhalten hat. Durch die Kennung (hier wieder beispielsweise 1 Bit) IBSYS (Input Buffer Busy Shadow) in Bitstelle 31 des Eingangs- Anforderungsregisters 403 wird angezeigt ob gerade eine Übertragung mit Beteiligung des Schattenspeichers 401 erfolgt. So wird beispielsweise bei IBSYS=I gerade aus dem Schattenspeicher 401 übertragen und bei IBSYS=O eben nicht. Dieses Bit IBSYS wird beispielsweise durch das Schreiben von IBRH also Bitstellen 0 bis 5 in Register 403 ge¬ setzt, um anzuzeigen, dass ein Transfer zwischen dem Schattenspeicher 401 und dem Botschaftsspeicher 300 im Gange ist. Nach Beendigung dieser Datenübertragung zum Botschaftsspeicher 300 wird IBSYS wieder zurückgesetzt.
Während der Datentransfer aus dem Schattenspeicher 401 gerade läuft kann die Host- CPU 102 die nächste zu transferierende Botschaft in den Eingangspufferspeicher bzw. in den Teilpufferspeicher 400 schreiben. Mit Hilfe einer weiteren Zugriffskennung IBSYH (Input Buffer Busy Host) beispielsweise in Bitstelle 15 von Register 403 kann die Ken- nung noch weiter verfeinert werden. Schreibt die Host-CPU 102 gerade IBRH, also die
Bitstellen 0 bis 5 von Register 403 während eine Übertragung zwischen dem Schatten¬ speicher 401 und dem Botschaftsspeicher 300 läuft, also IBSYS=I ist, so wird IBSYH im Eingangs-Anforderungsregister 403 gesetzt. Sobald der laufende Transfer also die lau¬ fende Übertragung abgeschlossen ist, wird der angeforderte Transfer (Anforderung durch STXRH siehe oben) gestartet und das Bit IBSYH zurückgesetzt. Das Bit IBSYS bleibt während der ganzen Zeit gesetzt, um anzuzeigen, dass Daten zum Botschaftsspeicher transferiert werden. Alle verwendeten Bits aller Ausfiihrungsbeispiele können dabei auch als Kennungen mit mehr als einem Bit ausgebildet sein. Vorteilhaft ist die Ein-Bit Lösung aus Speicher- und verarbeitungsökonomischen Gründen.
Der so beschriebene Mechanismus erlaubt es der Host-CPU 102 kontinuierlich Daten in die im Botschaftsspeicher befindlichen Botschaftsobjekte bestehend aus Headerbereich HB und Datenbereich DB zu transferieren, vorausgesetzt die Zugriffsgeschwindigkeit der Host-CPU 102 auf den Eingangspufferspeicher ist kleiner oder gleich der internen Datentransferrate des FlexRay-IP-Moduls also des Kommunikationsbausteins 100.
In den Figuren 7, 8 und 9 werden nun die Lesezugriffe auf den Botschaftsspeicher 300 durch die Host-CPU oder Teilnehmer-CPU 102 über den Ausgangspufferspeicher oder Ausgabepufferspeicher 202 näher erläutert. Dazu zeigt Figur 7 noch einmal den Kommu- nikationsbaustein 100, wobei aus Gründen der Übersichtlichkeit auch hier nur die rele¬ vanten Teile des Kommunikationsbausteins 100 gezeigt sind. Dies ist zum einen der für die Steuerung der Abläufe verantwortliche Botschaftsverwalter 200 sowie zwei Kontroll¬ register 703 und 704, die wie dargestellt außerhalb des Botschaftsverwalter 300 im Kommunikationsbaustein 100 untergebracht sein können, aber auch im Botschaftsverwal- ter 200 selbst enthalten sein können. 703 stellt dabei das Ausgangs- Anforderungsregister
(Output Buffer Command Request Register) dar und 704 das Ausgangs- Maskierungsregister (Output Buffer Command Mask Register). Lesezugriffe der Host- CPU 102 auf den Botschaftsspeicher 300 erfolgen also über den zwischengeschalteten Ausgangspufferspeicher 202 (Output Buffer). Dieser Ausgangspufferspeicher 202 ist nun ebenfalls geteilt bzw. gedoppelt ausgelegt, und zwar als Teilpufferspeicher 701 und ei¬ nem zu dem Teüpufferspeicher zugehörigen Schattenspeicher 700. Damit kann auch hier wie nachfolgend beschrieben ein kontinuierlicher Zugriff der Host-CPU 102 auf die Bot¬ schaften bzw. Botschaflsobjekte respektive Daten des Botschaftsspeichers 300 erfolgen und damit Datenintegrität und beschleunigte Übertragung nun in der Gegenrichtung vom Botschaftsspeicher zum Host gewährleistet werden. Die Steuerung der Zugriffe erfolgt über das Ausgangs- Anforderungsregister 703 und über das Eingangs-Maskierungsregister 704. Auch im Register 703 sind mit den Zahlen von 0 bis 31 die jeweiligen Bitstellen in
703 hier beispielhaft für eine Breite von 32 Bit dargestellt. Gleiches gilt für das Register
704 und die Bitstellen 0 bis 31 in 704. Erfindungsgemäß erhalten nun beispielhaft die Bitstellen 0 bis 5, 8 und 9, 15 und 16 bis 21 des Registers 703 bezüglich der Ablaufsteuerung des Lesezugriffs eine besondere Funktion. So ist in die Bitstellen 0 bis 5 des Registers 703 eine Kennung OBRS (Output Buffer Request Shadow) als Botschaftskennung eintragbar. Ebenso ist in die Bitstellen 16 bis 21 des Registers 703 eine Kennung OBRH (Output Buffer Request Host) eintragbar.
Als Zugriff skennung ist in Bitstelle 15 von Register 703 eine Kennung OBSYS (Output Buffer Busy Shadow) eintragbar. Ausgezeichnet sind auch die Stellen 0 und 1 des Aus¬ gabe-Maskierungsregisters 704, wobei in den Bitstellen 0 und 1 mit RDSS (Read Data Section Shadow) und RHSS (Read Header Section Shadow) weitere Kennungen als Da- tenkennungen eingetragen sind. Weitere Datenkennungen sind beispielsweise in den Bit¬ stellen 16 und 17 mit RDSH (Read Data Section Host) und RHSH (Read Header Section Host) vorgesehen. Diese Datenkennungen sind auch hier beispielhaft in einfachster Form, nämlich jeweils als ein Bit ausgebildet. In Bitstelle 9 des Registers 703 ist eine Starfken- nung REQ eingetragen. Weiterhin ist eine Umschaltkennung VIEW vorgesehen die bei- spielhaft in Bilstelle 8 von Register 703 eingetragen ist.
Die Host-CPU 102 fordert die Daten eines Botschaftsobjekts aus dem Botschaftespeicher 300 an, indem sie die Kennung der gewünschten Botschaft, also insbesondere die Num¬ mer des gewünschten Botechaftsobjektes, nach OBRS also in die Bitstellen 0 bis 5 des Registers 703 schreibt. Auch hierbei kann die Host-CPU wie in der Gegenrichtung ent- weder'nur die Status- bzw. Konfigurations- und Headerdaten KD einer Botschaft also aus einem Headerbereich oder nur die eigentlich zu übertragenden Daten D einer Botschaft also aus dem Datenbereich oder auch beide lesen. Welcher Teil der Daten also aus Hea¬ derbereich und/oder Datenbereich übertragen werden soll wird hierbei vergleichbar mit der Gegenrichtung durch RHSS und RDSS festgelegt. Das heißt RHSS gibt an, ob die
Headerdaten gelesen werden sollen und RDSS gibt an, ob die eigentlichen Daten gelesen werden sollen.
Eine Startkennung dient dazu die Übertragung vom Botschaftsspeicher zum Schatten- Speicher 700 zu starten. D.h. wird als Kennung wie im einfachsten Fall ein Bit verwendet, wird durch Setzen von Bit REQ in Bitstelle 9 im Ausgabe- Anforderungsregister 703 die Übertragung vom Botschaftsspeicher 300 zum Schattenspeicher 700 gestartet. Die lau¬ fende Übertragung wird wieder durch eine Zugriffskennung, hier wieder im einfachsten Fall durch ein Bit OBSYS im Register 703 angezeigt. Um Kollisionen zu vermeiden ist es vorteilhaft, wenn das Bit REQ nur dann gesetzt werden kann, wenn OBSYS nicht ge- setzt ist also gerade keine laufende Übertragung erfolgt. Hier erfolgt dann auch der Bot¬ schaftstransfer zwischen dem Botschaftsspeicher 300 und dem Schattenspeicher 700. Der eigentliche Ablauf könnte nun einerseits vergleichbar zur Gegenrichtung wie unter den Figuren 4, 5 und 6 beschrieben gesteuert werden (komplementäre Registerbelegung) und erfolgen oder aber in einer Variation durch eine zusätzliche Kennung, nämlich eine Um- schaltkennung VEEW in Bisteile 8 des Registers 703. D.h. nach Äbschluss der Überfra¬ gung wird das Bit OBSYS zurückgesetzt und durch Setzen des Bits VEEW im Ausgabe- Anforderungsregister 703 werden der Teilpufferspeicher 701 und der zugehörige Schat¬ tenspeicher 700 getauscht bzw. es werden die Zugriffe darauf getauscht und die Host- CPU 102 kann nun das vom Botschaftsspeicher angeforderte Botschaftsobjekt also die entsprechende Botschaft aus dem Teilpufferspeicher 701 auslesen. Dabei werden auch hier vergleichbar mit der Gegenübertragungsrichtung in den Figuren 4 bist 6 die Regis¬ terzellen OBRS und OBRH getauscht. Gleichermaßen werden RHSS und RDSS gegen RHSH und RDSH getauscht. Als Schutzmechanismus kann auch hier vorgesehen werden, dass das Bit VIEW nur dann gesetzt werden kann, wenn OBSYS nicht gesetzt ist, also keine laufende Übertragung stattfindet.
Somit erfolgen Lesezugriffe der Host-CPU 102 auf den Botschaftsspeicher 300 über ei¬ nen zwischengeschalteten Ausgangspufferspeicher 202. Dieser Ausgangspufferspeicher ist ebenso wie der Eingangspufferspeicher doppelt bzw. zweiteilig ausgelegt um einen kontinuierlichen Zugriff der Host-CPU 102 auf die Botschaftsobjekte die im Botschafts¬ speicher 300 abgelegt sind zu gewährleisten. Auch hier werden die Vorteile der hohen Datenintegrität und der beschleunigten Übertragung erzielt.
Durch die Verwendung der beschriebenen Eingangs- und Ausgangspuffer wird sicherge¬ stellt, dass eine Host-CPU trotz der modulinternen Latenzzeiten unterbrechungsfrei auf den Botschaftsspeicher zugreifen kann.
Zur Sicherstellung dieser Datenintegrität wird die Datenübertragung, insbesondere die Weiterleitung im Kommunikationsbaustein 100 durch den Botschaftsverwalter 200 (Mes¬ sage Handler MHD) vorgenommen. Dazu ist in Figur 10 der Botschaftsverwalter 200 dargestellt. Der Botschaftsverwalter ist in seiner Funktionalität durch mehrere Zustands- maschinen oder Zustandsautomaten, also endliche Automaten, sogenannte Finite-State- Maschinen (FSM) darstellbar. Dabei sind wenigstens drei Zustandsmaschinen und in ei- ner besonderen Ausführungsform vier Finite-State-Maschinen vorgesehen. Eine erste Fi- πit-State-Maschine ist die IOBF-FSM und mit 501 bezeichnet (Inpu</Ouiput Buffer State Machine). Diese IOBF-FSM könnte auch je Übertragungsrichtung bezüglich des Ein¬ gangspufferspeichers oder des Ausgangspufferspeichers in zwei Finite-State-Maschinen aufgeteilt sein IBF-FSM (Iαput Buffer FSM) und OBF-FSM (Output Buffer FSM), womit maximal fünf Zustandsautomaten (IBF-FSM, OBF-FSM, TBFl-FSM, TBF2-FSM,
AFSM) denkbar wären. Bevorzugt ist aber eine gemeinsame IOBF-FSM vorzusehen. Ei¬ ne wenigstens zweite Finite-State-Maschine ist hier im Zuge des bevorzugten Ausfüh¬ rungsbeispiels in zwei Blöcke 502 und 503 aufgeteilt und bedient die beiden Kanäle A und B bezüglich der Speicher 205 und 206, wie zu Fig. 2 beschrieben. Dabei kann eine Finite-State-Maschine vorgesehen sein um beide Kanäle A und B zu bedienen oder aber wie in der bevorzugten Form eine Finit-State-Maschine TBFl-FSM mit 502 bezeichnet (Transient Buffer 1 (206, RAM A) State Machine) für Kanal A und für Kanal B eine TBF2-FSM mit 503 bezeichnet (Transient Buffer 2 (205, RAM B) State Machine).
Zur Steuerung des Zugriffs der drei Finite-State-Maschinen 501 -503 im bevorzugten
Ausführungsbeispiel dient eine Arbiter-Finite-State-Maschine, die sogenannte AFSM, die mit 500 bezeichnet ist. Die Daten (KD und/oder D) werden in einem durch ein Taktmit¬ tel, wie z.B. ein VCO (Voltage controlled Oszillator), einen Schwingquarz usw. generier¬ ten oder aus diesem angepassten Takt im Kommunikationsbaustein übertragen. Der Takt T kann dabei im Baustein genereirt werden oder von außen, z.B. als Bustakt vorgegeben sein. Diese Arbiter-Finite-State-Maschine AFSM 500 gibt abwechselnd einer der drei Fi- nit-State-Maschinen 501-503, insbesondere jeweils für eine Taktperiode T Zugriff auf den Botschaftsspeicher. D.h. die zur Verfügung stehende Zeit wird entsprechend den Zugriffsanforderungen der einzelnen Zustandsautomaten 501, 502, 503 auf diese anfor- dernden Zustandsautomaten aufgeteilt. Erfolgt eine Zugriffsanforderung von nur einer
Finite-State-Machine, so erhält diese 100% der Zugriffszeil, also alle Takte T. Erfolgt ei¬ ne Zugriffsanforderung von zwei Zustandsautomaten, erhält jede Finite-State-Machine 50% der Zugriffszeit. Erfolgt schließlich eine Zugriffsanforderung von drei Zustandsau¬ tomaten so erhält jede der Finite-State-Maschinen 1/3 der Zugriffszeit. Dadurch wird die jeweils zur Verfügung stehende Bandbreite optimal genutzt.
Die erste Finite-State-Machine mit 501 bezeichnet, also IOBF-FSM führt bei Bedarf fol¬ gende Aktionen aus:
- Datentransfer vom Eingangspufferspeicher 201 zum ausgewählten Botschaftsobjekt im Botschaflsspeicher 300. - Datentransfer vom ausgewählten Botschaftsobjekt im Botschaftsspeicher 300 zum Aus¬ gangspufferspeicher 202.
Die Zustandsmaschine für Kanal A 502, also TBFlFSM, führt folgende Aktionen aus: -Datentransfer vom ausgewählten Botschaftsobjekt im Botschaßsspeicher 300 zum Puf¬ ferspeicher 206 von Kanal A.
- Datentransfer vom Pufferspeicher 206 zum ausgewählten Botschaftsobjekt im Bot- schaftsspeicher 300.
- Suche nach dem passenden Botschaftsobjekt im Botschaftsspeicher, wobei bei Empfang das Botschaftsobjekt (Receive Buffer) zum Abspeichern einer auf Kanal A empfangenen
Botschaft im Rahmen einer Akzeptanzfilterung gesucht wird und beim Senden das nächs¬ te auf Kanal A zu sendende Botschaftsobjekt (Transmit Buffer).
Analog dazu ist die Aktion von TBF2-FSM, also der Finit-State-Machine für Kanal B in Block 503. Diese führt den Datentransfer vom ausgewählten Botschaftsobjekt im Bot¬ schaftsspeicher 300 zum Pufferspeicher 205 von Kanal B aus und den Datentransfer vom Pufferspeicher 205 zum ausgewählten Botschaftsobjekt im Botschaftsspeicher 300. Auch die Suchfunktion ist analog zu TBFl-FSM nach einem passenden Botschaftsobjekt im Botschaftsspeicher, wobei bei Empfang das Botschaftsobjekt (Receive Buffer) zum Ab- speichern einer auf Kanal B empfangenen Botschaft im Rahmen einer Akzeptanzfilterung gesucht wird und beim Senden die nächste auf Kanal B zu sendende Botschaft oder Bot¬ schaftsobjekt (Transmit Buffer).
In Figur 11 sind nun noch einmal die Abläufe und die Übertragungswege dargestellt. Die drei Zustandsmaschinen 501 -503 steuern die jeweiligen Datenübertragungen zwischen den einzelnen Teilen. Dabei ist mit 102 wieder die Host-CPU dargestellt, mit 201 der Eingangspufferspeicher und mit 202 der Ausgangspufferspeicher. Mit 300 ist der Bot¬ schaftsspeicher dargestellt und die beiden Pufferspeicher für Kanal A und Kanal B mit 206 und 205. Die Schnittstellenelemente 207 und 208 sind ebenfalls dargestellt. Der erste Zustandsautomat IOBF-FSM, mit 501 bezeichnet steuert den Datentransfer ZlA und
ZlB, also vom Eingangspufferspeicher 201 zum Botschaftsspeicher 300 und vom Bot¬ schaftsspeicher 300 zum Ausgangspufferspeicher 202. Die Datenübertragung erfolgt da¬ bei über Datenbusse mit einer Wortbreite von beispielsweise 32 Bit wobei auch jede an¬ dere Bitzahl möglich ist. Gleiches gilt für die Übertragung Z2 zwischen dem Botschafts- Speicher und dem Pufferspeicher 206. Diese Datenübertragung wird durch TBFl-FSM, also 502 die Zustandsmaschine für Kanal A, gesteuert. Die Übertragung Z3 zwischen Botschaftsspeicher 300 und Pufferspeicher 205 wird durch den Zustandsautomaten TBF2-FSM, also 503 gesteuert. Auch hier erfolgt der Datentransfer über Datenbusse mit einer beispielhaften Wordbreite von 32 Bit, wobei auch hier jede andere Bitzahl möglich ist. Normalerweise benötigt der Transfer eines kompletten Botschaftsobjektes über die genannten Übertragungswege mehrere Taktperioden T. Daher erfolgt eine Aufteilung der Übertragungszeit bezogen auf die Taktperioden T durch den Arbiter, also die AFSM 500. In Figur 11 sind also die Datenpfade zwischen denen vom Message Handler kontrollier¬ ten Speicherkomponenten dargestellt. Um die Datenintegrität der im Botschaftsspeicher gespeicherten Botschaftsobjekte sicherzustellen, sollten vorteilhafterweise zur gleichen
Zeit nur auf einem der dargestellten Pfade also ZlA und ZlB sowie Z2 und Z3 gleichzei¬ tig Daten ausgetauscht werden.
In Abbildung 12 ist an einem Beispiel gezeigt, wie die zur Verfügung stehenden System- takle T vom Arbiter, also der AFSM 500, auf die drei anfordernden Zustandsautomaten aufgeteilt werden. In Phase 1 erfolgen Zugriffsanforderungen von Zustandsautomat 501 und Zustandsautomat 502, d.h., dass die gesamte Zeit jeweils zur Hälfte auf die beiden anfordernden Zustandautomaten aufgeteilt wird. Bezogen auf die Taktperioden in Phase 1 bedeutet dies, dass Zustandsautomat 501 in den Taktperioden Tl und T3 Zugriff erhält und Zustandsautomat 502 in den Taktperioden T2 und T4. In Phase 2 erfolgt der Zugriff nur durch die Zustandsmaschine 501, sodass alle drei Taktperioden, also 100% der Zugriffszeit von T5 bis T7 auf IOBF-FSM entfallt. In Phase 3 erfolgen Zugriffsanforde¬ rungen aller drei Zustandsautomaten 501 bis 503, sodass eine Drittelung der Gesamt¬ zugriffszeit erfolgt. Der Arbiter AFSM verteilt dann die Zugriffszeit beispielsweise so, dass in den Taktperioden T8 und Tl 1 die Finit-State-Maschine 501, in den Taktperioden
T9 und T12 die Finite-State-Maschine 502 und in den Taktperioden TlO und T13 die Fi¬ nit-State-Maschine 503 Zugriff erhält. La Phase 4 schließlich erfolgt der Zugriff durch zwei Zustandsautomaten, 502 und 503 auf den beiden Kanälen A und B des Kommunika¬ tionsbausteins, sodass eine Zugriffsverteilung der Taktperioden T14 und T16 an Finite- State-Machine 502 und in T15 und T17 an Finite-State-Machine 503 erfolgt.
Der Arbiterzustandsautomat AFSM 500 sorgt also dafür, dass für den Fall wenn mehr als eine der drei Zustandsmaschinen eine Anforderung für einen Zugriff auf den Botschafts¬ speicher 300 stellt, der Zugriff taktweise und abwechselnd auf die anfordernden Zu- Standsmaschinen aufgeteilt wird. Diese Vorgehensweise stellt die Integrität der im Bot- schaftsspeicher abgelegten Botschaftsobjekte, also die Datenintegrität, sicher. Will zum Beispiel die Host-CPU 102 über den Ausgangspufferspeicher 202 ein Botschaftsobjekt auslesen während gerade eine empfangene Botschaft in dieses Botschaftsobjekt geschrie¬ ben wird, so wird abhängig davon welche Anforderung zuerst gestartet wurde entweder der alte Stand oder der neue Stand ausgelesen, ohne das die Zugriffe im Botschaftsobjekt im Botschaftsspeicher selbst kollidieren.
Das beschriebene Verrfahren ermöglicht der Host-CPU im laufenden Betrieb jedes belie¬ bige Botschaftsobjekt im Botschaftsspeicher zu lesen oder zu schreiben, ohne dass das ausgewählte Botschaftsobjekt für die Dauer des Zugriffs der Host-CPU von der Teilnah¬ me am Datenaustausch auf beiden Kanälen des FlexRay Busses gesperrt wäre (Buffer Locking). Gleichzeitig wird durch die taktweise Verschachtelung der Zugriffe die Integri¬ tät der im Botschaftsspeicher abgelegten Daten sichergestellt und die Übertragungsge¬ schwindigkeit, auch durch Ausnutzung der vollen Bandbreite erhöht.

Claims

Ansprüche
1. FlexRay-Kommunikationsbaustein (100) zur Kopplung einer FlexRay- Kommunikationsverbindung (101) mit einem, dem FlexRay- Kommunikationsbaustein zugeordneten Teilnehmer (102) in einem FlexRay- Netzwerk über welches Botschaften übertragen werden, dadurch gekennzeichnet, dass der FlexRay-Kommunikationsbaustein (100) folgende Bestandteile enthält:
- eine erste Anordnung (105) zur Speicherung wenigstens eines Teils der übertrage- nen Botschaften und
- eine zweite Anordnung (104) zur Verbindung der ersten Anordnung (105) mit dem Teilnehmer (102) sowie
- eine dritte Anordnung (103) zur Verbindung der FlexRay- Kommunikationsverbindung (101) mit der ersten Anordnung (105).
2. FlexRay-Kommunikationsbaustein (100) nach Ansprach 1, dadurch gekennzeichnet, dass die erste Anordnung (105) einen Botschaftsverwalter (200) und einen Bot¬ schaftsspeicher (300) enthält.
3. FlexRay-Kommunikationsbaustein (100) nach Ansprach 1, dadurch gekennzeichnet, dass die erste Anordnung (105) einen Botschaftsspeicher (300) enthält, wobei der Botschaftsspeicher in ein Kopfsegment (HS) und in ein Datensegment (DS) aufge¬ teilt ist.
4. FlexRay-Kommunikationsbaustein (100) nach Ansprach 1, dadurch gekennzeichnet, dass die zweite Anordnung (104) einen Eingangspufferspeicher (201) und einen Ausgangspufferspeicher (202) enthält.
5. FlexRay-Kornmunikationsbaustein (100) nach Anspruch 4, dadurch gekennzeichnet, dass der Eingangspufferspeicher (202) in einen Teilpuiferspeicher (701) und einen Schattenspeicher (700) aufgeteilt ist, wobei der Zugriff auf den Teilpufferspeicher und den Schattenspeicher vertauscht wird.
6. FlexRay-Kommunikationsbaustein (100) nach Anspruch 4, dadurch gekennzeichnet, dass der Eingangspufferspeicher (201) in einen Teilpufferspeicher (400) und einen Schattenspeicher (401) aufgeteilt ist, deren Inhalt miteinander vertauscht wird.
7. FlexRay-Kommunikationsbaustein (100) nach Anspruch 4, dadurch gekennzeichnet, dass der Ausgangspufferspeicher (202) in einen Teilpufferspeicher (701) und einen Schattenspeicher (700) aufgeteilt ist, wobei der Zugriff auf den Teilpufferspeicher und den Schattenspeicher vertauscht wird.
8. FlexRay-Kommunikationsbaustein (100) nach Anspruch 4, dadurch gekennzeichnet, dass der Ausgangspufferspeicher (202) in einen Teilpufferspeicher (701) und einen Schattenspeicher (700) aufgeteilt ist, deren Inhalt miteinander vertauscht wird.
9. FlexRay-Kommunikationsbaustein (100) nach einem der Ansprüche 5 bis 8, dadurch gekennzeichnet, dass jeder Eingangspufferspeicher (400, 401) und jeder Ausgangs¬ pufferspeicher (700, 701) derart ausgelegt ist, dass ein Dateribereich und ein Header¬ bereich zweier FlexRay-Botschaften speicherbar ist.
10. FlexRay-Kommunikationsbaustein (100) nach Anspruch 1, dadurch gekennzeichnet, dass die zweite Anordnung (104) einen Schnittstellenbaustein enthält, der aus einem teilnehmerspezifϊschen Teilbaustein (204) und einem teihiehmerunabhängigen Teil¬ baustein (203) besteht.
11. FlexRay-Kommunikationsbaustein (100) nach Ansprach 1, dadurch gekennzeichnet, dass die dritte Anordnung (103) einen ersten Schnittstellenbaustein (207) und einen zweiten Schnittstellenbaustein (208) und in zwei Datenpfade mit jeweils zwei Daten¬ richtungen aufgeteilt ist.
12. FlexRay-Kommunikationsbaustein (100) nach Anspruch 1, dadurch gekennzeichnet, dass die dritte Anordnung (103) einen ersten Pufferspeicher (206) und einen zweiten Pufferspeicher (205) enthält und in zwei Datenpfade mit jeweils zwei Datenrichtun¬ gen aufgeteilt ist.
13. FlexRay-Kommunikationsbaustein (100) nach Anspruch 12, dadurch gekennzeich¬ net, dass jeder der beiden Pufferspeicher (205, 206) derart ausgelegt sind, dass ein Datenbereich zweier FlexRäy-Botschaften speicherbar ist.
14. FlexRay-Kommunikationsbaustein (100) nach Anspruch 11, dadurch gekennzeich¬ net, dass jeder der Schnittstellenbausteine (207, 208) ein Schieberegister und eine FlexRay-Protokoll-Zustandsmaschine enthält.
PCT/EP2005/053083 2004-08-05 2005-06-29 Flexray-kommunikationsbaustein WO2006015913A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP05756826A EP1776805B1 (de) 2004-08-05 2005-06-29 Flexray-kommunikationsbaustein
DE502005008586T DE502005008586D1 (de) 2004-08-05 2005-06-29 Flexray-kommunikationsbaustein
JP2007524317A JP2008508826A (ja) 2004-08-05 2005-06-29 ＦｌｅｘＲａｙ通信モジュール
AT05756826T ATE450102T1 (de) 2004-08-05 2005-06-29 Flexray-kommunikationsbaustein
US11/659,558 US7769906B2 (en) 2004-08-05 2005-06-29 FlexRay communication module

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004038212.3 2004-08-05
DE102004038212A DE102004038212A1 (de) 2004-08-05 2004-08-05 FlexRay-Kommunikationsbaustein

Publications (1)

Publication Number Publication Date
WO2006015913A1 true WO2006015913A1 (de) 2006-02-16

Family

ID=34971661

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/053083 WO2006015913A1 (de) 2004-08-05 2005-06-29 Flexray-kommunikationsbaustein

Country Status (10)

Country Link
US (1) US7769906B2 (de)
EP (1) EP1776805B1 (de)
JP (1) JP2008508826A (de)
KR (1) KR101028898B1 (de)
CN (1) CN100566276C (de)
AT (1) ATE450102T1 (de)
DE (2) DE102004038212A1 (de)
ES (1) ES2335509T3 (de)
RU (1) RU2380841C2 (de)
WO (1) WO2006015913A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8484383B2 (en) 2004-08-05 2013-07-09 Robert Bosch Gmbh FlexRay communication controller
US8778022B2 (en) 2004-11-02 2014-07-15 E-Vision Smart Optics Inc. Electro-active intraocular lenses
US9801709B2 (en) 2004-11-02 2017-10-31 E-Vision Smart Optics, Inc. Electro-active intraocular lenses
CN111699707A (zh) * 2018-02-05 2020-09-22 硅实验室公司 用于在通信***中进行安全唤醒的***和方法

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7849284B2 (en) * 2003-05-21 2010-12-07 Nxp B.V. Message memory for a communication protocol and method
DE102004008910A1 (de) * 2004-02-24 2005-09-08 Robert Bosch Gmbh Verfahren und Kommunikationssystem zur Übertragung von Informationen in einem Kraftfahrzeug
US7548551B2 (en) * 2005-08-19 2009-06-16 Gm Global Technology Operations, Inc. System and method of optimizing the bandwidth of a time triggered communication protocol with homogeneous slot sizes
DE102005048581B4 (de) * 2005-10-06 2022-06-09 Robert Bosch Gmbh Teilnehmerschnittstelle zwischen einem FlexRay-Kommunikationsbaustein und einem FlexRay-Teilnehmer und Verfahren zur Übertragung von Botschaften über eine solche Schnittstelle
EP2036262A1 (de) * 2006-06-20 2009-03-18 Freescale Semiconductor, Inc. Verfahren zum senden eines datenelements aus einem zeitabhängigen datenspeichermittel
EP2038744B1 (de) * 2006-06-22 2018-08-08 NXP USA, Inc. Verfahren und system zum gruppieren von interrupts aus einem zeitabhängigen datenspeichermittel
KR100930931B1 (ko) * 2007-12-12 2009-12-10 현대자동차주식회사 플렉스레이통신 고장 강건을 위한 플렉스레이 시스템
DE102007061986A1 (de) * 2007-12-21 2009-06-25 Bayerische Motoren Werke Aktiengesellschaft Kommunikationssystem
DE102009041435A1 (de) * 2009-09-16 2011-03-24 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aufwecken von Teilnehmern eines Bussystems und entsprechender Teilnehmer
US8898408B2 (en) * 2011-12-12 2014-11-25 Dell Products L.P. Memory controller-independent memory mirroring
DE102012207014B4 (de) 2012-04-27 2018-03-15 S-Y Systems Technologies Europe Gmbh Schnittstelle für einen kabelbaum
RU2691886C1 (ru) * 2018-08-15 2019-06-18 Общество с ограниченной ответственностью "ТЕКОН Микропроцессорные технологии" Сложно-функциональный блок для СБИС типа система на кристалле
CN110519377B (zh) * 2019-08-29 2022-05-27 北京经纬恒润科技股份有限公司 一种通信数据传输方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1179920A2 (de) * 2000-08-12 2002-02-13 Bayerische Motoren Werke Aktiengesellschaft Datenbus für mehrere Teilnehmer
WO2003053010A2 (en) * 2001-12-17 2003-06-26 Siemens Transportation Systems, Inc. Packet efficient tdma with flow control

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4333143A (en) * 1979-11-19 1982-06-01 Texas Instruments Input process sequence controller
US4805094A (en) * 1986-08-27 1989-02-14 American Telephone & Telegraph Company Multi-channel memory access circuit
US5195182A (en) * 1989-04-03 1993-03-16 Eastman Kodak Company Frame buffer architecture for storing sequential data in alternating memory banks
US5458404A (en) 1991-11-12 1995-10-17 Itt Automotive Europe Gmbh Redundant wheel sensor signal processing in both controller and monitoring circuits
SE514348C2 (sv) * 1995-06-09 2001-02-12 Saab Dynamics Ab Minnesstruktur anpassad för lagring och hämtning av vektorer
JPH09261226A (ja) 1996-03-26 1997-10-03 Meidensha Corp プログラマブル・コントローラ
JP3843667B2 (ja) 1999-10-15 2006-11-08 セイコーエプソン株式会社 データ転送制御装置及び電子機器
DE20121466U1 (de) 2001-07-26 2003-02-27 Motorola Inc Taktsynchronisation in einem verteilen System
DE10138066A1 (de) 2001-08-03 2003-02-20 Siemens Ag Teilnehmer für ein Netzwerk
DE10200201A1 (de) 2002-01-04 2003-07-24 Daimler Chrysler Ag Zyklusbasiertes zeitgesteuertes Kommunikationssystem
DE10215719A1 (de) 2002-04-10 2003-10-30 Philips Intellectual Property Datenspeicher
EP1355456A1 (de) 2002-04-16 2003-10-22 Robert Bosch Gmbh FlexRay Kommunikationsprotokoll
EP1355460B1 (de) * 2002-04-16 2005-10-05 ROBERT BOSCH GmbH Verfahren zur Überwachung einer Zugriffsablaufsteuerung für ein Kommunikationsmedium einer Kommunikationssteuerung eines Kommunikationssystems
JP3750636B2 (ja) 2002-07-11 2006-03-01 株式会社デンソー データ中継装置および多重通信システム
US7337241B2 (en) 2002-09-27 2008-02-26 Alacritech, Inc. Fast-path apparatus for receiving data corresponding to a TCP connection
EP1588275A1 (de) 2002-12-17 2005-10-26 Systemauto System, verfahren und computerprogrammprodukt zur gemeinsamen nutzung von informationen in einem verteilten framework
JP2004260484A (ja) 2003-02-25 2004-09-16 Sumitomo Electric Ind Ltd 車両内通信システム及びゲートウェイ装置
JP2005149203A (ja) 2003-11-17 2005-06-09 Toshiba Corp データ取り込み装置及びデータ取り込み方法
JP4404619B2 (ja) 2003-12-19 2010-01-27 パナソニック株式会社 通信装置、通信制御方法及び通信制御プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1179920A2 (de) * 2000-08-12 2002-02-13 Bayerische Motoren Werke Aktiengesellschaft Datenbus für mehrere Teilnehmer
WO2003053010A2 (en) * 2001-12-17 2003-06-26 Siemens Transportation Systems, Inc. Packet efficient tdma with flow control

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BERWANGER J ET AL: "FLEXRAY - THE COMMUNICATION SYSTEM FOR ADVANCED AUTOMOTIVE CONTROL SYSTEMS", SAE TECHNICAL PAPER SERIES, SOCIETY OF AUTOMOTIVE ENGINEERS, WARRENDALE, PA, US, vol. 2001-1-676, 5 March 2001 (2001-03-05), XP009023349, ISSN: 0148-7191 *
GO: "FlexRay fuer verteilte Anwendungen im Fahrzeug", ELEKTRONIK AUTOMOTIVE, May 2001 (2001-05-01), pages 40 - 43, XP002216067 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8484383B2 (en) 2004-08-05 2013-07-09 Robert Bosch Gmbh FlexRay communication controller
US8778022B2 (en) 2004-11-02 2014-07-15 E-Vision Smart Optics Inc. Electro-active intraocular lenses
US9801709B2 (en) 2004-11-02 2017-10-31 E-Vision Smart Optics, Inc. Electro-active intraocular lenses
US10729539B2 (en) 2004-11-02 2020-08-04 E-Vision Smart Optics, Inc. Electro-chromic ophthalmic devices
CN111699707A (zh) * 2018-02-05 2020-09-22 硅实验室公司 用于在通信***中进行安全唤醒的***和方法

Also Published As

Publication number Publication date
CN1993936A (zh) 2007-07-04
US20080140949A1 (en) 2008-06-12
EP1776805A1 (de) 2007-04-25
ES2335509T3 (es) 2010-03-29
DE102004038212A1 (de) 2006-03-16
KR20070037634A (ko) 2007-04-05
JP2008508826A (ja) 2008-03-21
RU2007108064A (ru) 2008-10-20
RU2380841C2 (ru) 2010-01-27
ATE450102T1 (de) 2009-12-15
CN100566276C (zh) 2009-12-02
KR101028898B1 (ko) 2011-04-12
US7769906B2 (en) 2010-08-03
EP1776805B1 (de) 2009-11-25
DE502005008586D1 (de) 2010-01-07

Similar Documents

Publication Publication Date Title
WO2006015913A1 (de) Flexray-kommunikationsbaustein
EP1776807B1 (de) Verfahren und vorrichtung zum zugriff auf daten eines botschaftsspeichers eines kommunikationsbausteins
EP1787204B1 (de) Botschaftsverwalter und verfahren zur steuerung des zugriffs auf daten eines botschaftsspeichers eines kommunikationsbausteins
EP1846827B1 (de) Verfahren zum übertragen von daten in botschaften über eine kommunikationsverbindung eines kommunikationssystems, sowie kommunikationsbaustein, teilnehmer eines kommunikationssystems und kommunikationssystem zur realisierung dieses verfahrens
EP1941674B1 (de) Teilnehmer und kommunikationscontroller eines kommunikationssystems und verfahren zur realisierung einer gateway-funktionalität in einem teilnehmer eines kommunikationssystems
EP1940654B1 (de) Verfahren zur Anbindung eines FlexRay-Teilnehmers mit einem Mikrocontroller an eine FlexRay-Kommunikationsverbindung über eine FlexRay-Kommunikationssteuereinrichtung, und FlexRay-Kommunikationssystem zur Realisierung dieses Verfahrens
EP1941377A2 (de) Teilnehmerschnittstelle zwischen einem mikrocontroller und einem flexray-kommunikationsbaustein, flexray-teilnehmer und verfahren zur übertragung von botschaften über eine solche schnittstelle
EP1776808B1 (de) Verfahren zur speicherung von botschaften in einem botschaftsspeicher und botschaftsspeicher
DE102005048581B4 (de) Teilnehmerschnittstelle zwischen einem FlexRay-Kommunikationsbaustein und einem FlexRay-Teilnehmer und Verfahren zur Übertragung von Botschaften über eine solche Schnittstelle
EP2030117B1 (de) Gateway zum datentransfer zwischen seriellen bussen
DE102005060085B4 (de) Verfahren, Kommunikationsnetzwerk und Steuereinheit zum zyklischen Übertragen von Daten
EP2030118A1 (de) Mehrprozessor-gateway
WO2007010024A1 (de) Flexray-kommunikationsbaustein, flexray-kommunikationscontroller und verfahren zur botschaftsübertragung zwischen einer flexray-kommunikationsverbindung und einem flexray-teilnehmer
EP1820111A1 (de) Kommunikationsbausteinanordnung mit einem schnittstellenmodul und schnittstellenmodul
WO2007039628A1 (de) Teilnehmer und kommunikationscontroller eines kommunikationssystems und verfahren zur datenübertragung in einem teilnehmer des kommunikationssystems
DE19846914C2 (de) Datenbus und Verfahren zum Kommunizieren zweier Baugruppen mittels eines solchen Datenbusses

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2005756826

Country of ref document: EP

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1020077002680

Country of ref document: KR

Ref document number: 2007524317

Country of ref document: JP

Ref document number: 200580026248.4

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 512/CHENP/2007

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2007108064

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 1020077002680

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2005756826

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11659558

Country of ref document: US