EP1642423A1 - Anordnung und verfahren zur verwaltung eines speichers - Google Patents

Anordnung und verfahren zur verwaltung eines speichers

Info

Publication number
EP1642423A1
EP1642423A1 EP04740006A EP04740006A EP1642423A1 EP 1642423 A1 EP1642423 A1 EP 1642423A1 EP 04740006 A EP04740006 A EP 04740006A EP 04740006 A EP04740006 A EP 04740006A EP 1642423 A1 EP1642423 A1 EP 1642423A1
Authority
EP
European Patent Office
Prior art keywords
data
buffer
sdxx
buffers
identifier
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
EP04740006A
Other languages
English (en)
French (fr)
Other versions
EP1642423B1 (de
Inventor
Markus Buhlmann
Martin Döring
Andreas Krüger
Burkhard Narbe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Audi AG
Volkswagen AG
Original Assignee
Audi AG
Volkswagen AG
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 Audi AG, Volkswagen AG filed Critical Audi AG
Publication of EP1642423A1 publication Critical patent/EP1642423A1/de
Application granted granted Critical
Publication of EP1642423B1 publication Critical patent/EP1642423B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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
    • H04L12/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
    • 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/40169—Flexible bus arrangements
    • H04L12/40176—Flexible bus arrangements involving redundancy
    • H04L12/40182—Flexible bus arrangements involving redundancy by using a plurality of communication lines
    • 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/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6432—Topology
    • H04L2012/6435—Bus

Definitions

  • the invention relates to an arrangement for managing a memory between a communication controller and a host processor of a network node in a network, and a method suitable for this.
  • a network node is essentially formed by a control device.
  • This control unit contains at least one transceiver, by means of which physical signals can be received from the bus or sent to the bus. Sending and receiving can take place in a single component or separate components (receiver and transmitter) exist for sending and receiving.
  • the transceiver is connected to a communication controller which, among other things, extracts the data content from the received messages or converts data to be sent into messages in accordance with the protocol.
  • the extracted data or the data to be sent are stored in a memory block which the communication controller can access.
  • the control device comprises a host processor, which can also access the memory block.
  • This host processor is then connected, for example, to sensors and / or actuators which are assigned to the control device.
  • the host processor carries out the actual data evaluation and calculates from the received data control signals for its actuators and / or, if necessary, generates data for other network nodes to be transmitted in connection with its sensor data.
  • the memory block arranged between the host processor and the communication controller can be designed as a dual-ported RAM.
  • the memory block consists of buffers, with some bus systems having a fixed assignment of identifiable or network nodes and buffers.
  • One such bus system is FlexRay, for example.
  • FlexRay has a static part and a dynamic part, whereby the ratio can be set differently, so that in extreme cases a purely dynamic or purely static transmission takes place.
  • the static part is divided into frames or slots, with a frame or slot being permanently assigned to certain identifiers.
  • a FlexRay requirement is that the frames or slots in the static part must all be the same size.
  • the payload i.e. the user data size in the FlexRay protocol, is currently set to a maximum of 254 bytes / frame. Accordingly, a buffer with 254 bytes of storage capacity must be kept for each ID, regardless of whether these are also used. Since the dual-ported RAM is relatively expensive, this is a not inconsiderable problem.
  • the invention is therefore based on the technical problem of creating an arrangement and a method for memory management by means of which the relationship between payload and buffer costs is improved.
  • control data are stored in the buffers assigned to the identifiers, which contain at least one reference to the payload associated with the identifier, the associated payload being stored in the associated buffer and / or in one or more other buffers and / or in a central memory module are.
  • the basic principle of the invention is therefore to manage the available storage space more effectively despite the fixed allocation. This can be used to reduce the buffers with the same payload or to increase the transferable payload with the same buffer size. This is particularly interesting because if the payload changes, the existing buffer sizes can continue to be used by the memory management. In addition to cost savings, the use will also be more flexible.
  • the memory size of all buffers is the same size.
  • the buffers of the identifiers of the static part are chosen larger than the buffers of the identifiers of the dynamic part.
  • the memory size of the buffers is limited to the control data, with all useful data being stored in at least one central memory.
  • the buffers are subdivided into a part for the control data and a part for the user data or payload, the user data being divided exclusively into the buffers.
  • an additional central storage element is therefore dispensed with.
  • control data comprise at least one status bit, from which the update status of the user data can be determined. This means that both the host processor and the communication controller can quickly determine whether the data is old or new, which in the latter case must be read out. This bit is therefore set when writing data and reset when reading.
  • control data each comprise a status bit from which a current access to the buffer can be ascertained. This prevents the host processor or the communication controller from accessing a buffer while the other is overwriting or reading out the data content.
  • control data comprise a status bit from which the allocation or linkage of the part of the buffer assigned to the useful data can be determined. As a result, the host processor or the communication controller can recognize whether the part for the user data of a buffer is occupied or free.
  • a preferred application of the invention is the use in a FlexRay controller.
  • FIG. 1 shows a schematic block diagram of a FlexRay controller (prior art)
  • FIG. 2 shows a schematic representation of a communication structure according to the FlexRay protocol (prior art)
  • FIG. 3 shows a schematic representation of a message (prior art)
  • 4 shows a first embodiment of the invention with a central memory element
  • FIG. 5 shows a second embodiment with a fixed allocation of buffers and identifiers
  • FIG. 6 shows a third embodiment with only a partially fixed allocation.
  • the FlexRay controller 1 shows a schematic block diagram of a FlexRay controller 1, which is connected to two bus lines 3, 3 'via two transceivers 2, 2', so that redundant communication is realized.
  • the FlexRay controller 1 sends and receives data messages via the transceivers 2, 2 '. Switching between transmit and receive mode takes place by means of bus guardians 4, 4 'assigned to transceivers 2, 2'.
  • the FlexRay controller 1 comprises a communication controller 5, which has various tasks. On the one hand, this compares the redundant data of the transceivers 2, 2 'for agreement. Furthermore, this extracts data content from received data messages or generates the data messages for data to be sent in accordance with the FlexRay protocol.
  • the FlexRay controller 1 comprises a memory 6, which is composed of buffers 7, which are preferably designed as dual-ported RAM. Each message from a FlexRay controller 1, which in each case forms a network node, is assigned at least one unique identifier.
  • the other port of the buffers 7 is connected to the actual host processor 8, which evaluates the received data content and generates or generates the data content to be sent by the FlexRay controller 1. edited.
  • the host processor 8 can then be connected to actuators and / or sensors via data and / or control lines 9.
  • the communication structure according to the FlexRay protocol is shown in simplified form in FIG. 2.
  • the frame structure is such that the length of all frames A - C in the static part is the same size.
  • the frames D1 - D4 are dynamic frames, the size of which can be different.
  • Static means that frame A is always assigned to identifier ID 01. A time slot is thus assigned to it, in which it can send data, but does not have to.
  • frames B and C for identifiers ID 02 and ID 03. All other control units to which no static frame is assigned can send their data in a dynamic frame.
  • An arbitration procedure which differs from that of CAN, then takes place there, analogous to the procedure for CAN.
  • the identifier ID 04 sends first, then ID 05 and then ID 06 and finally ID 09, the identifiers ID 07 and ID 08 having no data to be sent at this time.
  • the illustration in FIG. 2 is highly schematic since, due to the so-called minisloting method, there must be a certain period of time between ID 06 and ID 09 in which certain minimum times are waited for whether the ID 07 or ID 08 is to be sent data want to send over the bus.
  • the schematic structure of a data message is shown in FIG. 3.
  • the data message is composed of a header HD, which also contains the identifier, the actual user data or payload PL, and a trailer TR, which contains, for example, CRC data.
  • the maximum payload per frame is limited to 254 bytes, with the planned next generation FlexRay controllers only being designed for a maximum payload of 32 bytes / frame.
  • the known FlexRay controllers have a memory size for the buffers designed for the maximum payload, i.e. the next generation buffers only have a memory size of 32 bytes, although the FlexRay specification would allow larger frames.
  • the memory 6 comprises a number of buffers 7, a buffer 7 being permanently assigned to each identifier ID01-IDXX. Furthermore, the memory 6 comprises a central memory element 10, which is composed, for example, of a large number of dual-ported RAMs of different sizes. In the assigned to the identifiem Buffers are control data SD01 - SDXX.
  • the memory size of the individual buffers 7 is preferably the same size and designed for the size of the control data SD01-SDXX, whereas the payloads PL of the identifier ID01-IDXX are stored in the memory element 10.
  • the control data SD01-SDXX include, for example, an address, namely where the assigned payload is stored in the memory 10. Further control data can be, for example, status information about the degree of update, the current access and the determination of whether the communication controller 5 or the host processor 8 has registered the payload. Furthermore, information about the length of the payload can be stored in the control data SD01-SD XX, because although a communication controller can always extract the length information from the header when it is received, a reading host or a writing controller has no length information.
  • the procedure is, for example, as follows: Communication controller 5 receives a data message and recognizes, for example, from the header which identifier ID the data message is assigned to and the size of the payload.
  • the communication controller 5 searches the memory element 10 for a free memory space of a suitable size and writes the payload there. Accordingly, the address is written into the control data SD of the associated identifier and the status bit is set for the degree of update.
  • an address or a memory area in the memory 10 can be permanently assigned to the identifiers of the static part, since their frame size is predetermined, so that the memory management could only extend to the identifiers of the dynamic part.
  • the host processor 8 also reads the data accordingly. This first controls the associated buffer 7 of the desired identifier, detects whether it is new data and then reads out the payload from the memory element 10, its address in the control data was deposited.
  • a memory area in the memory element 10 which is adapted to the payload is selected in each case.
  • the memory element 10 is composed of DPRAMs of different sizes, for example 8, 16, 32 and 64 bytes
  • a payload of 254 bytes can be divided, for example, into four 64 byte RAMs, the addresses of which are stored in the control data.
  • the advantage of this embodiment is the great flexibility, but the known structure of the FlexRay controller is changed. In particular, the described FlexRay controller can be used to react flexibly to changed specifications, such as frame sizes.
  • each identifier ID01 - IDXX is fixed a buffer 7 is assigned, the associated payload PL also being at least partially stored in the buffers 7.
  • the memory 6 of a FlexRay controller comprises more buffers 7 that are used as identifier ID, ie there are unused buffers 7, which are designated here with XX01 - XX04. These unused buffers XX01 - XX04 are now used for dynamic memory management.
  • the control data are structured as follows, for example:
  • the communication switch 5 searches for a free buffer XX01 - XX04, the married bit of which is not set.
  • the communication controller 5 then divides the payload, with part of the payload being stored in the buffer 7 assigned to the identifier and the remaining part in the free buffer.
  • the payload PLXX is divided into the payload PL'XX and PU'XX, the latter being stored in the buffer XX04.
  • the control data SDXX or SDXX04 of the two buffers 7 must then be changed accordingly.
  • the update and married bit are set and the busy bit is reset after the process has been completed.
  • the update bit recognizes that the data is new. Recognizes on the basis of the address at next_pointer this further that the payload was divided into at least two buffers. After the data has been read out, the update bit is reset, the busy bit set during reading being reset after the reading process.
  • buffer XX04 After a cycle, the memory in buffer XX04 is then deleted and the married bit is reset so that buffer XX04 is again available for dynamic memory management. Since the payload for the identifiers is fixed in the static part, the control data can be omitted for their assigned buffers if their buffers for the payload are sufficiently large. Otherwise, these buffers are preferably assigned another buffer for the chaining in order to simplify memory management. In addition, it should be noted that the chaining is not limited to two buffers, but if necessary three or even more buffers can be linked to one another, the address of the next buffer in the chain then being in each case next_pointer.
  • control data is stored in the buffer must be specified in advance so that its meaning is clear when reading or writing.
  • the addressing process for the host processor or the communication controller can be simplified by suitably placing the next pointer. This is to be explained in more detail using a few examples, where it is assumed that the control data are a total of two bytes long and the next_pointer is twelve bits long. It should also be noted that the physical addresses of the buffers are numbered consecutively. Assuming further that the buffer size is 16 bytes, the physical addresses of the first buffer are from 0 to 15, the second buffer from 16 to 31, the third buffer from 32 to 47 and so on. By a suitable placement of the next pointer and masking of the status bits, a desired address can then be read directly from the control data without shift operations.
  • a status bit is placed on the first bit of the control data, followed by the twelve bits of the next_pointer and then the remaining status bits. Since only every second byte is to be addressed, the lowest bit of the address is always zero.
  • the 16-bit control data are now routed to 16 AND gates, for example, a fixed zero in the status bits and a logical one in the next_pointer bits at the second input of each AND gate is applied. The status bits are thus masked and the address is at the output at the output of the AND gates. If, for example, only every 4, 8 or 16 byte is to be addressed, the next__pointer must only be placed one bit to the left in the control data.
  • the first four bits of the control data would be the status bits and the last twelve bits the next_pointer, with the first four address bits for the controller by masking the Bits would be 0000.
  • An address generated in this way would therefore allow every 16 bytes to be addressed without having to carry out shift operations in the controllers.
  • FIG. 6 Another possible embodiment is shown in FIG. 6, the memory again consisting of a chain of buffers 7. All identifiers ID01 - ID03 of the static frame are assigned an identifier. If the buffer size is greater than / equal to the payload, there is no need for chaining and only the required status bits, such as update and busy, can be provided. No buffer is permanently assigned to the other identifiers of the dynamic part. Rather, the remaining free buffers are managed dynamically, the assignment of the identifiers ID04-IDXX to the buffers being stored in a table 11. If the communication controller 5 now receives a data message from one of the identifiers ID04-IDXX, the communication controller searches for a free buffer in the table and assigns this to the identifier with its payload.

Landscapes

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

Description

A n o rd n u n g u n d V e rf a h re n z u r V e rw a l t u n g e i n e s S p e i c h e rs
Die Erfindung betrifft eine Anordnung zur Verwaltung eines Speichers zwischen einem Kommunikationscontroller und einem Host-Prozessor eines Netzwerkknotens in einem Netzwerk sowie ein hierfür geeignetes Verfahren.
In der Kraftfahrzeugtechnik nimmt die Anzahl der verbauten Steuergeräte kontinuierlich zu. Aus verschiedenen Gründen werden dabei nicht alle Steuergeräte in einem einzigen Netzwerk angeordnet, sondern funktional zusammenhängende Steuergeräte werden in Teilnetzwerken zusammengefasst, wobei dann die einzelnen Teilnetzwerke mit unterschiedlichen Protokollen und/oder Geschwindigkeiten arbeiten. Ein gegebenenfalls notwendiger Datenaustausch zwischen den Teilnetzwerken erfolgt dann über Gateways. Bekannte Bussysteme in Kraftfahrzeugen sind beispielsweise CAN_LOW_Speed- und CAN_HIGH_Speed-Bussysteme oder MOST-Bussysteme. Ein CAN-Bussystem ist ein ereignisgesteuertes Bussystem, d.h. jeder Netzknoten kann theoretisch jederzeit senden. Wollen dabei mehrere Netzknoten gleichzeitig senden, so führen diese ein Arbitrierungsverfahren durch, wobei sich der Netzknoten mit der höchsten Priorität durchsetzt. Aufgrund des zunehmenden Einsatzes sicherheitsrelevanter Netzknoten kommen verstärkt zeitgesteuerte Bussysteme oder zeit- und ereignisgesteuerte Bussysteme, wie beispielsweise FlexRay, zur Anwendung.
Unabhängig von der Art des verwendeten Bussystems wird ein Netzknoten im Wesentlichen durch ein Steuergerät gebildet. Dieses Steuergerät beinhaltet mindestens einen Transceiver, mittels dessen physikalisch Signale vom Bus empfangen oder auf den Bus gesendet werden können. Das Senden und Empfangen kann dabei in einem einzigen Bauteil erfolgen oder für Senden und Empfangen existieren jeweils separate Bauteile (Receiver und Transmitter). Der Transceiver ist mit einem Kommunikationscontroller verbunden, der unter anderem aus den empfangenen Botschaften den Dateninhalt extrahiert bzw. zu sendende Daten in protokollgerechte Botschaften umwandelt. Die extrahierten Daten bzw. die zu sendenden Daten sind in einem Speicherblock abgelegt, auf den der Kommunikationscontroller zugreifen kann. Des Weiteren umfasst das Steuergerät einen Host-Prozessor, der ebenfalls auf den Speicherblock zugreifen kann. Dieser Host-Prozessor ist dann beispielsweise mit Sensoren und/oder Aktuatoren verbunden, die dem Steuergerät zugeordnet sind. Der Host- Prozessor führt die eigentliche Datenauswertung durch und berechnet aus den empfangenen Daten Stellsignale für seine Aktuatoren und/oder erzeugt hieraus gegebenenfalls in Verbindung mit seinen Sensordaten zu sendende Daten für andere Netzknoten. Der zwischen dem Host-Prozessor und dem Kommunikationscontroller angeordnete Speicherblock kann als Dual-Ported-RAM ausgebildet sein.
Logisch besteht der Speicherblock aus Buffern, wobei bei einigen Bussystemen eine feste Zuordnung von ldentifiem bzw. Netzknoten und Buffern existiert. Ein solches Bussystem ist beispielsweise FlexRay.
Bei FlexRay existiert ein statischer Teil und ein dynamischer Teil, wobei das Verhältnis unterschiedlich festgelegt werden kann, so dass im Extremfall eine rein dynamische oder rein statische Übertragung erfolgt. Der statische Teil ist in Rahmen bzw. Slots unterteilt, wobei bestimmten ldentifiem ein Rahmen bzw. Slot fest zugeordnet ist. Dabei ist eine FlexRay-Anforderung, dass die Rahmen bzw. Slots im statischen Teil alle gleich groß sein müssen. Im dynamischen Teil erlaubt die Spezifikation die Verwendung unterschiedlicher Rahmenlängen. Gegenwärtig ist die Payload, also die Nutzdatengröße im FlexRay-Protokoll mit maximal 254 Byte/Rahmen festgelegt. Entsprechend muss für jede ID daher ein Buffer mit 254 Byte Speichervermögen vorgehalten werden, unabhängig davon, ob diese auch ausgenutzt werden. Da die Dual-Ported-RAM relativ teuer sind, stellt dies ein nicht unbeachtliches Problem dar. Daher sind Überlegungen angestellt worden, die Buffer-Größe zu verkleinern. In der nächsten Generation der FlexRay-FPGA's werden daher nur 32 Byte/Buffer vorgehalten. Dies bedeutet, dass Nachrichten mit einer Maximallänge von 32 Byte übertragen werden können. Sollen dann von einem sicherheitsrelevanten Netzwerkknoten größere Dateninhalte von beispielsweise 64 Byte übertragen werden, so würde vorab der Dateninhalt auf zwei Botschaften aufgeteilt werden, denen jeweils ein Identifier zugeordnet ist. Bei FlexRay kann ein Netzwerkknoten mehrere unterschiedliche Identifier übertragen. Die Buffer-Größe begrenzt aber die maximal übertragbare Payload je Identifier.
Der Erfindung liegt daher das technische Problem zugrunde, eine Anordnung und ein Verfahren zur Speicherverwaltung zu schaffen, mittels derer das Verhältnis zwischen Payload und Bufferkosten verbessert wird.
Die Lösung des technischen Problems ergibt sich durch die Gegenstände mit den Merkmalen der Patentansprüche 1 und 1 1. Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen. Hierzu sind in den den ldentifiem zugeordneten Buffern Steuerdaten abgelegt, die mindestens einen Verweis auf die zum Identifier zugehörigen Nutzdaten (Payload) enthalten, wobei die zugehörigen Nutzdaten im zugehörigen Buffer und/oder in einem oder mehreren anderen Buffern und/oder in einem zentralen Speicherbaustein abgelegt sind. Das Grundprinzip der Erfindung besteht also darin, trotz der festen Zuordnung den vorhandenen Speicherplatz effektiver zu verwalten. Dies kann dazu ausgenutzt werden, um bei gleicher Payload die Buffer zu verkleinern oder bei gleicher Buffergröße die übertragbare Payload zu vergrößern. Dies ist insbesondere deshalb interessant, da dann bei sich ändernder Payload mit den vorhandenen Buffergrößen durch das Speichermanagement weiter gearbeitet werden kann. Also neben einer Kostenersparnis wird auch der Einsatz flexibler.
In einer bevorzugten Ausführungsform ist die Speichergröße aller Buffer gleich groß. Es ist jedoch auch denkbar, dass die Buffer der Identifier des statischen Teils größer als die Buffer der Identifier des dynamischen Teils gewählt werden.
In einer bevorzugten Ausführungsform ist die Speichergröße der Buffer auf die Steuerdaten beschränkt, wobei alle Nutzdaten in mindestens einem zentralen Speicher abgelegt sind.
In einer alternativen Ausführungsform sind die Buffer unterteilt in einen Teil für die Steuerdaten und einen Teil für die Nutzdaten bzw. Payload, wobei die Nutzdaten ausschließlich auf die Buffer aufgeteilt sind. Bei dieser Ausführungsform wird also auf ein zusätzliches zentrales Speicherelement verzichtet. Der Vorteil dieser Anordnung ist, dass dies hardware-technisch weitgehend mit dem Stand der Technik identisch und somit kompatibel ist.
In einer weiteren bevorzugten Ausführungsform umfassen die Steuerdaten mindestens ein Status-Bit, aus dem der Aktualisierungsstand der Nutzdaten erfassbar ist. Somit können sowohl der Host-Prozessor als auch der Kommunikationscontroller schnell erfassen, ob die Daten alt oder neu sind, wobei diese im letzten Fall ausgelesen werden müssen. Daher wird dieses Bit beim Schreiben von Daten gesetzt und beim Lesen zurückgesetzt.
In einer weiteren bevorzugten Ausführungsform umfassen die Steuerdaten jeweils ein Status-Bit, aus dem ein aktueller Zugriff auf den Buffer erfassbar ist. Hierdurch wird vermieden, dass der Host-Prozessor bzw. der Kommunikationscontroller auf einen Buffer zugreift, während der andere gerade den Dateninhalt überschreibt bzw. gerade ausliest. In einer weiteren bevorzugten Ausführungsform umfassen die Steuerdaten ein Status-Bit, aus dem die Belegung bzw. Verknüpfung des den Nutzdaten zugeordneten Teils des Buffers erfassbar ist. Dadurch ist für den Host-Prozessor bzw. den Kommunikationscontroller erkennbar, ob der Teil für die Nutzdaten eines Buffers belegt oder frei ist.
Ein bevorzugtes Anwendungsgebiet der Erfindung ist der Einsatz in einem FlexRay- Controller.
Die Erfindung wird nachfolgend anhand eines bevorzugten Ausführungsbeispieles näher erläutert. Die Fig. zeigen:
Fig. 1 ein schematisches Blockschaltbild eines FlexRay-Controllers (Stand der Technik), Fig. 2 eine schematische Darstellung einer Kommunikationsstruktur nach dem FlexRay-Protokoll (Stand der Technik), Fig. 3 eine schematische Darstellung einer Botschaft (Stand der Technik), Fig. 4 eine erste Ausführungsform der Erfindung mit einem zentralen Speicherelement, Fig. 5 eine zweite Ausführungsform mit fester Zuordnung von Buffern und ldentifiem und Fig. 6 eine dritte Ausführungsform mit nur teilweise fester Zuordnung.
In der Fig. 1 ist ein schematisches Blockschaltbild eines FlexRay-Controllers 1 dargestellt, der über zwei Transceiver 2, 2' mit zwei Busleitungen 3, 3' verbunden ist, so dass eine redundante Kommunikation realisiert wird. Über die Transceiver 2, 2' sendet und empfängt der FlexRay-Controller 1 Daten-Botschaften. Die Umschaltung zwischen Sende- und Empfangsmodus erfolgt dabei mittels den Transceivem 2, 2' zugeordneten Bus-Guardians 4, 4'. Des Weiteren umfasst der FlexRay-Controller 1 einen Kommunikationscontroller 5, der verschiedene Aufgaben hat. Zum einen vergleicht dieser die redundanten Daten der Transceiver 2, 2' auf Übereinstimmung. Des Weiteren extrahiert dieser Dateninhalte aus empfangenen Daten-Botschaften bzw. erzeugt für zu sendende Daten die Daten-Botschaften gemäß FlexRay-Protokoll. Weiter umfasst der FlexRay-Controller 1 einen Speicher 6, der sich aus Buffern 7 zusammensetzt, die vorzugsweise als Dual-Ported RAM ausgebildet sind. Dabei ist jeder Nachricht eines FlexRay-Controllers 1 , der jeweils einen Netzwerkknoten bildet, mindestens ein eindeutiger Identifier zugeordnet. Die Buffer 7 sind mit ihrem anderen Port mit dem eigentlichen Host-Prozessor 8 verbunden, der die empfangenen Dateninhalte auswertet und die vom FlexRay-Controller 1 zu sendenden Dateninhalte generiert bzw. aufbereitet. Der Host-Prozessor 8 kann dann über Daten- und/oder Steuerleitungen 9 mit Aktuatoren und/oder Sensoren verbunden sein.
In der Fig. 2 ist die Kommunikationsstruktur nach dem FlexRay-Protokoll vereinfacht dargestellt. Dabei existiert ein statischer und ein dynamischer Teil, wobei die Rahmen bzw. Slots im statischen Teil fest vorgegeben sind. Dabei ist die Rahmenstruktur derart, dass die Länge aller Rahmen A - C im statischen Teil gleichgroß ist. Bei den Rahmen D1 - D4 handelt es sich um dynamische Rahmen, deren Größe unterschiedlich sein kann. Statisch bedeutet dabei, dass der Rahmen A stets dem Identifier ID 01 zugeordnet ist. Diesem ist somit ein Zeitschlitz zugeordnet, in dem dieser Daten senden kann, aber nicht muss. Gleiches gilt für die Rahmen B und C für die Identifier ID 02 bzw. ID 03. Alle übrigen Steuergeräte, denen kein statischer Rahmen zugeordnet ist, können ihre Daten im dynamischen Rahmen senden. Dort findet dann analog zum Vorgehen bei CAN ein Arbitrierungsverfahren, welches sich jedoch von jenem bei CAN unterscheidet, statt. Im dargestellten Beispiel sendet also zuerst der Identifier ID 04, dann ID 05 und dann ID 06 und letztendlich ID 09, wobei die Identifier ID 07 und ID 08 zu diesem Zeitpunkt keine zu sendenden Daten aufweisen. Dabei ist die Darstellung in Fig. 2 stark schematisiert, da auf Grund des sogenannten Minisloting-Verfahrens zwischen den ID 06 und ID 09 eine gewisse Zeitspanne liegen muss, in der gewisse Mindestzeiten gewartet wird, ob die ID 07 bzw. ID 08 zu sendende Daten über den Bus senden wollen.
Der schematische Aufbau einer Daten-Botschaft ist in Fig. 3 dargestellt. Die Daten-Botschaft setzt sich zusammen aus einem Header HD, der auch den Identifier enthält, den eigentlichen Nutzdaten bzw. Payload PL sowie einen Trailer TR, der beispielsweise CRC-Daten enthält. Nach bisherigen FlexRay-Spezifikationen ist die maximale Payload pro Rahmen auf 254 Byte begrenzt, wobei die geplante nächste Generation FlexRay-Controllern nur noch auf eine maximale Payload von 32 Byte/Rahmen ausgelegt ist. Die bekannten FlexRay- Controller weisen dabei eine auf die maximale Payload ausgelegte Speichergröße für die Buffer auf, d.h. die Buffer der nächsten Generation weisen nur noch eine Speichergröße von 32 Byte auf, obwohl die FlexRay-Spezifikation größere Rahmen erlauben würde.
Erfindungsgemäß erfolgt im Gegensatz hierzu eine flexible Speicherverwa.tung, was nachfolgend an der Fig. 4 in einer ersten Ausführungsform erläutert werden soll. Dabei umfasst der Speicher 6 wie im Stand der Technik eine Reihe von Buffern 7, wobei jedem Identifier ID01 - IDXX ein Buffer 7 fest zugeordnet ist. Des Weiteren umfasst der Speicher 6 ein zentrales Speicherelement 10, das beispielsweise aus einer Vielzahl von Dual Ported RAMs verschiedener Größe zusammengesetzt ist. In den den ldentifiem zugeordneten Buffern sind Steuerdaten SD01 - SDXX. Die Speichergröße der einzelnen Buffer 7 ist dabei vorzugsweise gleich groß und auf die Größe der Steuerdaten SD01 - SDXX ausgelegt, wohingegen die Payloads PL der Identifier ID01 - IDXX im Speicherelement 10 abgelegt sind. Die Steuerdaten SD01 - SDXX umfassen dabei beispielsweise eine Adresse, nämlich wo die zugeordnete Payload im Speicher 10 abgelegt ist. Weitere Steuerdaten können beispielsweise Statusinformationen über den Aktualisierungsgrad, den aktuellen Zugriff sowie die Festlegung, ob der Kommunikationscontroller 5 oder der Host-Prozessor 8 die Payload eingeschrieben hat, sein. Des weiteren kann in die Steuerdaten SD01 - SD XX eine Information über die Länge der Payload abgelegt sein, da zwar ein Kommunikationscontroller die Längeninformation beim Empfang immer aus dem Header entnehmen kann, aber ein lesender Host bzw. ein schreibender Controller keine Längeninformation haben. Der Verfahrensablauf ist dabei beispielsweise wie folgt: Der Kommunikationscontroller 5 empfängt eine Daten-Botschaft und erkennt beispielsweise aus dem Header, welchem Identifier ID die Daten-Botschaft zugeordnet ist sowie die Größe der Payload. Der Kommunikationscontroller 5 durchsucht dann das Speicherelement 10 nach einem freien Speicherplatz geeigneter Größe und schreibt die Payload dort ein. Entsprechend wird in die Steuerdaten SD des zugehörigen Identifiers die Adresse eingeschrieben und das Status-Bit für den Aktualisierungsgrad gesetzt. Dabei kann insbesondere den ldentifiem des statischen Teils eine Adresse bzw. ein Speicherbereich im Speicher 10 fest zugeordnet werden, da deren Rahmengröße vorab festgelegt ist, so dass sich das Speichermanagement ausschließlich auf die Identifier des dynamischen Teils erstrecken könnte. Entsprechend verläuft auch das Lesen der Daten durch den Host- Prozessor 8. Dieser steuert zunächst den zugehörigen Buffer 7 des gewünschten Identifiers an, erkennt ob es sich um neue Daten handelt und liest dann die Payload aus dem Speicherelement 10 aus, deren Adresse in den Steuerdaten hinterlegt war. Variiert nun während des Betriebes die Payload eines Identifiers, so wird jeweils ein an die Payload angepasster Speicherbereich im Speicherelement 10 ausgewählt. Setzt sich das Speicherelement 10 aus DPRAMs unterschiedlicher Größe von beispielsweise 8, 16, 32 und 64 Byte zusammen, so kann eine Payload von 254 Byte beispielsweise auf vier 64 Byte- RAMs aufgeteilt werden, deren Adressen in den Steuerdaten abgelegt sind. Der Vorteil dieser Ausführungsform ist die große Flexibilität, wobei jedoch die bekannte Struktur der FlexRay-Controller geändert wird. Insbesondere kann mit dem beschriebenen FlexRay- Controller flexibel auf geänderte Vorgaben, wie beispielsweise Rahmengrößen, reagiert werden.
In der Fig. 5 ist eine alternative Ausführungsform, die hardwaretechnisch mit bekannten FlexRay-Controilem gemäß Fig. 1 identisch ist. Wieder ist jedem Identifier ID01 - IDXX fest ein Buffer 7 zugeordnet, wobei auch die zugehörige Payload PL zumindest teilweise in den Buffern 7 abgelegt ist. Normalerweise umfasst der Speicher 6 eines FlexRay-Controllers mehr Buffer 7 als Identifier ID verwendet werden, d.h., es existieren ungenutzte Buffer 7, die hier mit XX01 - XX04 bezeichnet sind. Diese ungenutzten Buffer XX01 - XX04 werden nun für ein dynamisches Speichermanagement genutzt. Hierzu sind die Steuerdaten beispielsweise wie folgt aufgebaut:
Empfängt nun der Kommunikationsschalter 5 eine Daten-Botschaft mit einer Payload, die größer als der zugehörige Speicherplatz im zugeordneten Buffer 7 ist, so sucht der Kommunikationscontroller 5 einen freien Buffer XX01 - XX04, dessen married-Bit nicht gesetzt ist. Der Kommunikationscontroller 5 teilt dann die Payload auf, wobei ein Teil der Payload im Identifier zugeordneten Buffer 7 abgelegt wird und der übrige Teil im freien Buffer. Im dargestellten Ausführungsbeispiel wird die Payload PLXX in die Payload PL'XX und PU'XX aufgeteilt, wobei letztere im Buffer XX04 abgespeichert wird. Entsprechend müssen dann die Steuerdaten SDXX bzw. SDXX04 der beiden Buffer 7 geändert werden. In den Steuerdaten SDXX bleibt r/w = 1 , wobei bei next_pointer die Adresse vom Buffer XX04 abgelegt wird. Das update- und married-Bit werden gesetzt und nach erfolgtem Vorgang das busy-Bit zurückgesetzt. In den Steuerdaten des Buffers XX04 muss das Bit r/w = 1 und mindestens das update- und married-Bit = 1 gesetzt werden. Möchte nun der Host-Prozessor 8 die Payload auslesen, so liest dieser die Steuerdaten SDXX aus. Anhand des update-Bits erkennt dieser, dass die Daten neu sind. Anhand der Adresse bei next_pointer erkennt dieser weiter, dass die Payload auf mindestens zwei Buffer aufgeteilt wurde. Nachdem die Daten ausgelesen wurden, wird das update-Bit zurückgesetzt, wobei das während des Lesens gesetzte busy-Bit nach dem Lesevorgang zurückgesetzt wird. Nach einem Zyklus wird dann der Speicher im Buffer XX04 gelöscht und das married-Bit zurückgesetzt, so dass der Buffer XX04 wieder für das dynamische Speichermanagement zur Verfügung steht. Da die Payload für die Identifier im statischen Teil fest ist, kann bei deren zugeordneten Buffern auf die Steuerdaten verzichtet werden, wenn deren Buffer für die Payload ausreichend groß ist. Ansonsten wird diesen Buffern wieder vorzugsweise ein anderer Buffer für die Verkettung fest zugewiesen, um das Speichermanagement zu vereinfachen. Ergänzend sei angemerkt, dass die Verkettung nicht auf zwei Buffer begrenzt ist, sondern gegebenenfalls drei oder noch mehr Buffer miteinander verkettet werden können, wobei dann jeweils bei next_pointer die Adresse des nächsten Buffers der Kette steht.
Wie die Steuerdaten im Buffer abgelegt werden, muss vorab festgelegt werden, damit deren Bedeutungsinhalt beim Lesen bzw. Schreiben eindeutig ist. Dabei kann durch geeignete Plazierung des next_pointers der Adressierungsvorgang für den Host-Prozessor bzw. den Kommunikationscontroller vereinfacht werden. Dies soll anhand einiger Beispiele näher erläutert werden, wo angenommen wird, dass die Steuerdaten insgesamt zwei Byte und der next_pointer zwölf Bit lang sind. Dabei ist weiter anzumerken, dass die physikalischen Adressen der Buffer durchgehend nummeriert sind. Sei nun weiter angenommen, dass die Buffergröße 16 Byte beträgt, so sind die physikalischen Adressen des ersten Buffers von 0 bis 15, des zweiten Buffers von 16 bis 31 , des dritten Buffers von 32 bis 47 und so weiter. Durch geeignete Plazierung des next_pointers sowie Maskierung der Status-Bits kann dann eine gewünschte Adresse ohne Shift-Operationen direkt aus den Steuerdaten ausgelesen werden. Soll nun beispielsweise jedes zweite Byte ansprechbar sein, so wird auf das erste Bit der Steuerdaten ein Status-Bit gelegt, gefolgt von den zwölf Bit des next_pointer und anschließend die restlichen Status-Bits. Da nur jedes zweite Byte angesprochen werden soll, ist das unterste Bit der Adresse immer Null. Um nun die Adresse aus den Steuerdaten direkt auszulesen, werden nun beispielsweise die 16-Bit Steuerdaten auf 16 Und-Gatter geführt, wobei am zweiten Eingang jedes Und-Gatters bei den Status-Bits fest eine Null und bei den next_pointer-Bits eine logische Eins anliegt. Somit werden die Status-Bits maskiert und die Adresse liegt stellengerecht am Ausgang der Und-Gatter an. Soll nun beispielsweise nur jedes 4, 8 oder 16 Byte ansprechbar sein, so muss der next__pointer jeweils immer nur um ein Bit nach links verschoben in den Steuerdaten plaziert werden. Im letzten Beispiel wären dann die ersten vier Bit der Steuerdaten die Status-Bit und die letzten zwölf Bit der next_pointer, wobei die ersten vier Adressbits für die Controller durch die Maskierung der Bits 0000 wären. Eine derart generierte Adresse würde somit das Ansprechen jedes 16 Bytes erlauben, ohne Shift-Operationen in den Controllern durchführen zu müssen.
Dabei sei angemerkt, dass auch eine Ausführungsform möglich ist, wo freie Buffer, die eigentlich fest bestimmten ldentifiem zugeordnet sind, für das Speichermanagement zu verwenden. Hierbei signalisiert dann bei einem Zugriff das married-Bit, dass ein anderer Identifier gerade den Speicher über eine Verkettung benutzt. Dann wird die Payload in einem anderen Buffer abgespeichert und dessen Adresse im next_pointer eingetragen. Dabei muss nur sichergestellt sein, dass nicht beide Identifier im next_pointer eine Verkettung signalisieren möchten, d.h. ein fremder Identifier darf nicht den next_pointer in den Steuerdaten eines anderen fest zugeordneten Buffers benutzen.
In der Fig. 6 ist eine weitere mögliche Ausführungsform dargestellt, wobei der Speicher wieder aus einer Kette von Buffern 7 besteht. Dabei ist allen ldentifiem ID01 - ID03 des statischen Rahmens ein Identifier fest zugeordnet. Ist die Buffergröße größer/gleich der Payload, kann auf eine Verkettungsmöglichkeit verzichtet werden und nur die benötigten Status-Bits, wie beispielsweise update und busy, vorgesehen sein. Den übrigen ldentifiem des dynamischen Teils ist kein Buffer fest zugeordnet. Vielmehr werden die übrigen freien Buffer dynamisch verwaltet, wobei die Zuordnung der Identifier ID04 - IDXX zu den Buffern in einer Tabelle 11 abgelegt ist. Empfängt nun der Kommunikationscontroller 5 eine Daten- Botschaft eines der Identifier ID04 - IDXX, so sucht der Kommunikationscontroller in der Tabelle einen freien Buffer und weist diesen dem Identifier mit seiner Payload zu. Gegebenenfalls findet dann wieder eine Verkettung mehrerer Buffer statt, wobei die Verkettung wieder über die Steuerdaten SD in den Buffern erfolgt. Die erste Zuordnung Identifier - Buffer wird dann in der Tabelle 11 eingetragen. Entsprechend sucht der Host- Prozessor in der Tabelle 1 , welchem Buffer 7 ein bestimmter Identifier zugeordnet ist. Der Vorteil dieses Verfahrens ist das noch effektivere Speichermanagement.

Claims

PATE N TAN S P R Ü C H E
1) Die Erfindung betrifft eine Anordnung zur Speicherverwaltung eines Speichers zwischen einem Kommunikationscontroller und einem Host-Prozessor eines Netzwerkknotens in einem Netzwerk, wobei jeder Daten-Botschaft ein Identifier zugeordnet ist und in dem Speicher eines Netzwerkknotens mindestens eine der Anzahl der relevanten Identifier entsprechende Anzahl von Buffern angeordnet ist, wobei die Zuordnung von Buffer und Identifier fest ist, dadurch gekennzeichnet, dass in mindestens einigen der den ldentifiem (ID) zugeordneten Buffern (7) Steuerdaten (SD01 - SDXX) abgelegt sind, die mindestens einen Verweis auf die zum Identifier (ID) zugehörigen Nutzdaten (PL) enthalten, wobei die zugehörigen Nutzdaten (PL) im zugehörigen Buffer (7) des Indentifiers und/oder in einem anderen Buffer (7) und/oder in einem zentralen Speicherbaustein abgelegt sind.
2) Anordnung nach Anspruch 1 , dadurch gekennzeichnet, dass die Speichergröße aller Buffer (7) gleich ist.
3) Anordnung nach Anspruch 2, dadurch gekennzeichnet, dass die Speichergröße der Buffer (7) auf die Steuerdaten (SD01 - SDXX) beschränkt ist und alle Nutzdaten (PL) in mindestens einem zentralen Speicher abgelegt sind.
4) Anordnung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Buffer (7) in einem Teil für die Steuerdaten (SD01 - SDXX) und einem Teil für die Nutzdaten (PL) unterteilt sind, wobei die Nutzdaten (PL) ausschließlich auf die Buffer (7) aufgeteilt sind.
5) Anordnung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Steuerdaten (SD01 - SDXX) mindestens ein Status-Bit umfassen, aus dem die Kommunikationsrichtung der Nutzdaten zwischen dem Host-Prozessor (8) und dem Kommunikationscontroller (5) erfassbar ist. 6) Anordnung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Steuerdaten (SD01 - SDXX) mindestens ein Status-Bit umfassen, aus dem der Aktualisierungsstand der Nutzdaten (PL) erfassbar ist.
7) Anordnung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Steuerdaten (SD01 - SDXX) mindestens ein Status-Bit umfassen, aus dem ein aktueller Zugriff auf den Buffer (7) erfassbar ist.
8) Anordnung nach einem der Ansprüche 4 - 7, dadurch gekennzeichnet, dass die Steuerdaten (SD01 - SDXX) mindestens eine Status-Bit umfassen, aus dem die Belegung bzw. Verknüpfung des den Nutzdaten (PL) zugeordneten Teils des Buffers (7) erfassbar ist.
9) Anordnung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Steuerdaten (SD01 - SDXX) mindestens eine Information umfassen, aus der die Länge der abgespeicherten Nutzdaten (PL) ermittelbar ist.
10) Anordnung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Adresse der abgelegten Nutzdaten (PL) derart in den Steuerdaten (SD01 - SDXX) platziert ist, dass diese ohne Shift-Operationen durch Maskierung der Status- Bits auslesbar ist.
11 ) Verfahren zur Speicherverwaltung eines Speichers zwischen einem Kommunikationscontroller und einem Host-Prozessor eines Netzwerkknotens in einem Netzwerk, wobei jeder Daten-Botschaft ein Identifier zugeordnet ist und in dem Speicher eines Netzwerkknotens mindestens eine der Anzahl der Identifier entsprechende Anzahl von Buffern angeordnet ist, wobei die Zuordnung von Buffern und ldentifiem fest ist, dadurch gekennzeichnet, dass in mindestens einigen der den ldentifiem (ID) zugeordneten Buffern (7) Steuerdaten (SD01 - SDXX) abgelegt sind, wobei der Kommunikationscontroller (5) beim Empfang der Nutzdaten (PL) eines Identifiers (ID) deren Länge erfasst, die Nutzdaten (PL) in dem den Identifier zugeordneten Buffer (7) und/oder einem anderen Buffer (7) und/oder einem zentralen Speicherbaustein ablegt und in den Steuerdaten (SD01 - SDXX) des dem Identifier (ID) zugeordneten Buffers (7) einen Verweis einschreibt, wo die Nutzdaten (PL) abgelegt sind. 12) Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass der Host-Prozessor (8) zum Auslesen der Nutzdaten (PL) eines Identifiers (ID) zunächst die Steuerdaten (SD01 - SDXX) des zugeordneten Buffers (7) ausliest und entsprechend des hinterlegten Verweises den dort adressierten Speicherbereich ausliest.
13) Verfahren nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass vom Netzwerkknoten zu sendende Nutzdaten (PL) vom Host-Prozessor (8) aufbereitet werden, der Host-Prozessor (8) die Länge der Nutzdaten (PL) erfasst und in dem zugeordneten Buffer (7) des Identifiers (ID) des Netzwerkknotens und/oder in einem anderen Buffer (7) und/oder in einem zentralen Speicherbaustein (10) abspeichert und in den Steuerdaten (SD01 - SDXX) des zugeordneten Identifiers (ID) die Adresse der abgespeicherten Nutzdaten (PL) einschreibt.
14) Verfahren nach einem der Ansprüche 11 - 13, dadurch gekennzeichnet, dass der Host-Prozessor (8) und der Kommunikationscontroller (5) beim Schreiben von Nutzdaten (PL) ein update-Bit setzen und nach dem korrekten Lesen zurücksetzen.
15) Verfahren nach einem der Ansprüche 11 - 14, dadurch gekennzeichnet, dass der Host-Prozessor (8) und der Kommunikationscontroller (5) beim Lesen oder Schreiben in den Steuerdaten (SD01 - SDXX) des Buffers (7) ein Busy-Bit setzen und nach dem Vorgang zurücksetzen.
EP04740006A 2003-06-30 2004-06-17 Netzwerkknoten und verfahren zur speicherverwaltung in einem netzwerkknoten Expired - Lifetime EP1642423B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10329179A DE10329179A1 (de) 2003-06-30 2003-06-30 Anordnung und Verfahren zur Verwaltung eines Speichers
PCT/EP2004/006548 WO2005002145A1 (de) 2003-06-30 2004-06-17 Anordnung und verfahren zur verwaltung eines speichers

Publications (2)

Publication Number Publication Date
EP1642423A1 true EP1642423A1 (de) 2006-04-05
EP1642423B1 EP1642423B1 (de) 2009-09-23

Family

ID=33546702

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04740006A Expired - Lifetime EP1642423B1 (de) 2003-06-30 2004-06-17 Netzwerkknoten und verfahren zur speicherverwaltung in einem netzwerkknoten

Country Status (4)

Country Link
EP (1) EP1642423B1 (de)
AT (1) ATE443954T1 (de)
DE (2) DE10329179A1 (de)
WO (1) WO2005002145A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8660131B2 (en) 2005-06-09 2014-02-25 Nxp B.V. Storage unit for communication system node, method for data storage and communication system node
DE102005048584A1 (de) * 2005-07-21 2007-01-25 Robert Bosch Gmbh FlexRay-Kommunikationsbaustein, FlexRay-Kommunikationscontroller und Verfahren zur Botschaftsübertragung zwischen einer FlexRay-Kommunikationsverbindung und einem FlexRay-Teilnehmer
KR20080055910A (ko) * 2005-09-13 2008-06-19 엔엑스피 비 브이 메시지 송신 방법
DE102005048583A1 (de) * 2005-10-06 2007-04-12 Robert Bosch Gmbh Teilnehmer und Kommunikationscontroller eines Kommunikationssystems und Verfahren zur Datenübertragung in einem Teilnehmer des Kommunikationssystem
DE602006019920D1 (de) 2006-05-09 2011-03-10 Freescale Semiconductor Inc Datenkommunikationseinheit, integrierte schaltung und verfarhen zum puffern von daten
ATE511138T1 (de) 2007-11-14 2011-06-15 Nxp Bv Flexray-system mit effizienter speicherung von anweisungen
JP5451705B2 (ja) * 2011-09-21 2014-03-26 日立オートモティブシステムズ株式会社 自動車用電子制御装置及びデータ通信方法
US8798090B2 (en) * 2011-09-21 2014-08-05 Nxp B.V. System and method for creating a slot table entry address for a communications device

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778414A (en) * 1996-06-13 1998-07-07 Racal-Datacom, Inc. Performance enhancing memory interleaver for data frame processing
DE19758032A1 (de) * 1997-12-29 1999-07-01 Nec Electronics Europ Gmbh Schnittstelle für mehrere CAN-Datenverarbeitungsnetzwerke und Verfahren zum Betreiben einer Schnittstelle
US6493287B1 (en) * 1999-09-15 2002-12-10 Koninklijke Philips Electronics N.V. Can microcontroller that utilizes a dedicated RAM memory space to store message-object configuration information
DE10006970B4 (de) * 2000-02-16 2006-04-06 Infineon Technologies Ag Netzwerk-Controller
DE10218646A1 (de) * 2002-04-25 2003-11-13 Infineon Technologies Ag An einen Bus angeschlossene Einrichtung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005002145A1 *

Also Published As

Publication number Publication date
WO2005002145A1 (de) 2005-01-06
DE10329179A1 (de) 2005-03-17
ATE443954T1 (de) 2009-10-15
EP1642423B1 (de) 2009-09-23
DE502004010113D1 (de) 2009-11-05

Similar Documents

Publication Publication Date Title
DE102006058818B4 (de) Vorrichtung und Verfahren zur Umwandlung von Textmitteilungen
DE102007004044B4 (de) Verfahren und Anlage zur optimierten Übertragung von Daten zwischen einer Steuereinrichtung und mehreren Feldgeräten
DE19750662C2 (de) Prozessoreinheit für ein datenverarbeitungsgestütztes elektronisches Steuerungssystem in einem Kraftfahrzeug
EP1456722B1 (de) Datenübertragungsverfahren, serielles bussystem und anschalteinheit für einen passiven busteilnehmer
EP2030117B1 (de) Gateway zum datentransfer zwischen seriellen bussen
EP3759871B1 (de) Master-slave bussystem und verfahren zum betrieb eines bussystems
EP0848520A1 (de) Bussystem und Verfahren zur Datenübertragung
DE102005048581B4 (de) Teilnehmerschnittstelle zwischen einem FlexRay-Kommunikationsbaustein und einem FlexRay-Teilnehmer und Verfahren zur Übertragung von Botschaften über eine solche Schnittstelle
EP2087647B1 (de) Vorrichtung und verfahren zur manipulation von kommunikations-botschaften
DE102020205765A1 (de) Systemkomponente und Verwendung einer Systemkomponente
WO2022253589A1 (de) Verfahren zum laufzeitbasierten konfigurieren einer geräteinternen signalübertragung in einem steuergerät sowie entsprechend betreibbares steuergerät und kraftfahrzeug
EP1642423B1 (de) Netzwerkknoten und verfahren zur speicherverwaltung in einem netzwerkknoten
DE10131923A1 (de) Unmittelbar konfigurierbare Datenrelaiseinrichtung und Multiplex-Kommunikationssystem
DE69232645T2 (de) Kommunikationsgerät
EP0555456B1 (de) Verfahren zur datenübertragung und datenverarbeitungsanlage mit verteilten rechnerknoten
WO2012110541A1 (de) Verfahren zum übertragen von daten über einen synchronen seriellen datenbus
DE10216674A1 (de) Verfahren und Vorrichtung zur Übertragung von Nachrichten auf einem Bussystem und Bussystem
DE112008002252B4 (de) Sendevorrichtung, Sendeverfahren und Kommunikationssystem
EP3676995B1 (de) Master eines bussystems
DE102018010209A1 (de) Master-Slave Bussystem und Verfahren zum Betrieb eines Bussystems
WO2000003325A2 (de) Can-modul
EP1642422B1 (de) Anpassung eines fahrzeugnetzwerks an geänderte anforderungen
DE19843048C2 (de) Verfahren für einen Softwarezugriffswechsel in einem Netzwerkknoten eines Telekommunikationsnetzwerkes sowie ein zum Durchführen eines solchen Verfahrens geeigneter Netzwerkknoten
DE10360637B4 (de) Programmgesteuerte Einheit
DE19752292C2 (de) Mastereinheit für ein Bussystem zur Datenübertragung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060130

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: NARBE, BURKHARD

Inventor name: DOERING, MARTIN

Inventor name: KRUEGER, ANDREAS

Inventor name: BUHLMANN, MARKUS

17Q First examination report despatched

Effective date: 20070626

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RTI1 Title (correction)

Free format text: NETWORK NODE AND METHOD FOR MANAGING MEMORY IN A NETWORK NODE

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 502004010113

Country of ref document: DE

Date of ref document: 20091105

Kind code of ref document: P

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100125

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100103

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20100624

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091224

BERE Be: lapsed

Owner name: AUDI A.G.

Effective date: 20100630

Owner name: VOLKSWAGEN AG

Effective date: 20100630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100630

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100630

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100630

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100617

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100324

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100617

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090923

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 12

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 14

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 15

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230529

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20230622

Year of fee payment: 20

Ref country code: DE

Payment date: 20230630

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20230620

Year of fee payment: 20

REG Reference to a national code

Ref country code: DE

Ref legal event code: R071

Ref document number: 502004010113

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20240616

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20240616