WO2014060272A1 - Restbus-simulation eines flexray kommunikationsnetzwerkes - Google Patents

Restbus-simulation eines flexray kommunikationsnetzwerkes Download PDF

Info

Publication number
WO2014060272A1
WO2014060272A1 PCT/EP2013/071108 EP2013071108W WO2014060272A1 WO 2014060272 A1 WO2014060272 A1 WO 2014060272A1 EP 2013071108 W EP2013071108 W EP 2013071108W WO 2014060272 A1 WO2014060272 A1 WO 2014060272A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
flexray
network
network nodes
parameters
Prior art date
Application number
PCT/EP2013/071108
Other languages
English (en)
French (fr)
Inventor
Allan TENGG
Peter Priller
Original Assignee
Avl List 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 Avl List Gmbh filed Critical Avl List Gmbh
Publication of WO2014060272A1 publication Critical patent/WO2014060272A1/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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • 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

Definitions

  • the subject invention relates to a method and an arrangement for restbus simulation of a FlexRay communication network.
  • a communication network typically includes a plurality of network nodes that exchange data with each other according to a predetermined communication protocol.
  • a part of the communication network that is, a number of network nodes, is simulated, while the remaining part of the communication network is actually present.
  • communication controllers are often used, wherein for each network node to be simulated a communication controller (physically as hardware or logically as software) is present, which simulates the behavior of the network node.
  • a communication controller physically as hardware or logically as software
  • several network nodes can be simulated on a communication controller.
  • the challenge lies in the methodology of how the functions of the actually existing n network nodes to be simulated are placed on m communication controllers, where as a rule m ⁇ n. That is, usually a communication controller needs to simulate more than one network node. In this case, the communication parameters of the n network nodes must be merged in a specific manner in order to achieve as accurate as possible replication of the behavior of the overall network on m communication controllers.
  • This object is achieved according to the invention by assigning first of all n network nodes with a startup capability to a communication controller of the n network nodes to be simulated, the remaining ns network nodes allocated to the m communication controllers so that the message memories of the m communication controllers are used uniformly, and For each of the m communication controllers, a FlexRay parameter set is created, the FlexRay parameter MicroTick being set in dependence on the hardware clock of the communication controller and the FlexRay parameter SamplesPerMicroTick being set to achieve the given data transmission rate in the FlexRay communication network.
  • a reliable residual bus simulation of a FlexRay communication network can be realized with fewer communication controllers than network nodes to be simulated.
  • the stability of the residual bus simulation can be improved if the parameter set of each communication controller contains parameters for the secure startup of the FlexRay communication network, which are determined from the parameters of the network nodes to be simulated on the respective communication controller in order to ensure a safe startup of the communication network. Likewise, if the parameter set of each communication controller contains parameters for the maintenance of the function of the FlexRay communication network, which are determined from the parameters of the network nodes to be simulated on the respective communication controller in order to configure the communication network as fault tolerant as possible.
  • Parameters for which a calculation rule is specified in the FlexRay specification are preferably calculated by using the parameters previously selected for the communication controller as parameters for the calculation specification.
  • Fig.1 a FlexRay communication network
  • a FlexRay communication network 1 which comprises k (here ten) network nodes F1... F10.
  • n network nodes here the network nodes F1, F2, F3, F5, are to be simulated by means of a residual bus simulation, the remaining network nodes F4, F6 ... F10 are still real.
  • the network nodes F1, F2, F3, F5 are here simulated in a residual bus simulation on two communication controllers CC1, CC2, as shown in Figure 2.
  • the communication controllers CC1, CC2 are implemented on suitable simulation hardware 2, such as a computer, and could be implemented either as hardware components, for example in the form of plug-in cards, or in the form of software.
  • the network topology must first be modified for the residual bus simulation.
  • the network nodes F1, F2, F3, F5 to be simulated are physically separated from the communication network 1 and the simulation hardware 2 is physically added to the communication network.
  • the n (here four) to be simulated network nodes F1, F2, F3, F5 on the m (here two) communication controllers CC1, CC2 those with startup capability must be treated with priority.
  • a number of network nodes must be equipped with a so-called startup capability. Only these network nodes can initiate the start of the FlexRay communication network by trying to send a so-called collision avoidance symbol (CAS).
  • CAS collision avoidance symbol
  • the network node that was able to send a collision avoidance symbol can send messages within the next four cycles after the CAS startup. Thereafter, the other network nodes send with startup capability and only then the remaining network nodes.
  • the s (here two) network nodes F1, F3 startup capability are therefore assigned to different communication controllers CC1, CC2.
  • the number s of network nodes with startup capability in the communication network 1 should not change. Therefore, if possible, all s network nodes with startup capability are assigned to their own communication controllers CC1, CC2.
  • the network node F1 is here assigned to the communication controller CC1 and the network node F3 to the communication controller CC2.
  • the available FlexRay communication connec- CC1, CC2 have only a limited number or size of message memory, given by the simulation hardware 2 available. This assignment therefore takes place in such a way that the available message memories of the communication controllers CC1, CC2 are utilized as evenly as possible.
  • known optimization methods such as simulated annealing, genetic optimization algorithms, etc., can be used.
  • the preferred must criterion is that the message memory does not overflow in any of the m communication controllers CC1, CC2 during the residual bus simulation.
  • a local FlexRay parameter set must be defined for all the communication controllers CC1, CC2 available to the simulation hardware 2.
  • the FlexRay parameters are to be selected such that the simulation of the simulated network nodes F1, F2, F3, F5 on the communication controllers CC1, CC2 reflects the reality as well as possible. Due to the peculiarities of FlexRay, only one FlexRay parameter set can be defined for each communication controller CC1, CC2, which is used for all simulated network nodes F1, F2 and F3, F5.
  • the starting point is the hardware clock (or the quartz frequency of the hardware clock) of the corresponding communication controller CC1, CC2, which determines the parameter MicroTick.
  • a data transmission rate (bit rate in Mbit / s) is preset or set, which must be observed by all network nodes F1... F10 and thus also by the communication controllers CC1, CC2.
  • the FlexRay specification is missing only certain data transfer rates, namely 2.5Mbps, 5Mbps and 10Mbps, too.
  • the parameter SamplesPerMicroTick must now be set in such a way that the prescribed data transmission rate is maintained, whereby it should be noted that the bit length is specified or adjustable as an integer multiple of the parameter SamplesPerMicroTick on the communication controllers CC1, CC2.
  • SamplesPerMicroTick 8xSamplesPerMicroTick, the SamplesPerMicroTick parameter thus results in SamplesPerMicroTick ⁇ .
  • the starting point for the preferred definition of the remaining required FlexRay parameters of the communication controllers CC1, CC2 are the parameters of the associated network nodes F1, F2, F3, F5 to be simulated. It should be noted that these parameters can also be configured differently for the residual bus simulation, but the subsequent configuration enables a safe and reliable residual bus simulation of the FlexRay communication network. Here one can distinguish between different parameters:
  • Parameters for the safe startup of the FlexRay communication network 1 Here, a combination of the individual parameters must be selected so that a secure startup of the network is ensured. This applies in particular to the AllowPassiveTo Active, AcceptedStartupRange, WakeupPattern, KeySlotld, KeySlotUsedForStartup, KeySoldUsedForSync, and SingleSlotEnabled parameters.
  • All temporally relevant parameters of the FlexRay communication controllers CC1, CC2 are to be designed in such a way that the greatest possible time margins are available on the network in order to prevent collisions on the bus and as fault-tolerant as possible about the bus configure. This affects the FlexRay parameters HaltDueToCIock, ClusterDriftDamping, DelayCompensation, LatestTx, OffsetCorrectionOut and RateCorrectionOut.
  • the DelayCompensation parameter depends on the network topology used. For locally distributed networks with greater line length between the network nodes is due to the limited propagation speed v p of the signals ( ⁇ 2/3 speed of light in FlexRay cables) a perfect clock synchronization alone based on transmitted data packets difficult.
  • the DelayCompensation parameter helps.
  • each node can be given the distance d as far as it is from the fictitious center of the network. The distance is either known from the network topology or is estimated. Distant nodes can thus send away their data frames earlier so that they arrive in time in the fictitious center of the network. In the case of received frames, the far-off node can also correct the arrival time of the frames and thus perfectly keep the time frame from the point of view of the other network nodes.
  • Parameters of the FlexRay communication network 1 with calculation rule are some parameters which are derived from the other parameters by means of the calculation rule according to the FlexRay specification, ie can not be freely selected. These include MicroPerCycle, MicrolnitialOffset, MacrolnitialOffset, MaxDrift, DecodingCorrection, and ListTimeout.
  • the parameters of the network nodes F1, F2, F3, F5 to be simulated on the communication controller CC1, CC2 are used on each communication controller CC1, CC2 as selected above. Since these calculation instructions are part of the FlexRay specification and thus known, these calculation rules are not specifically mentioned here.
  • the FlexRay parameters of a communication controller CC1, CC2 could be set as follows in order to enable a residual bus simulation:

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Um eine Restbus-Simulation eines FlexRay Kommunikationsnetzwerkes (1) zu ermöglichen, ist vorgeschlagen, von den n zu simulierenden Netzwerkknoten (F1, F2, F3, F5) zuerst alle s Netzwerkknoten (F1, F3) mit einer Startup-Fähigkeit je einem Kommunikationskontroller (CC1, CC2) zuzuteilen, die verbleibenden n-s Netzwerkknoten (F2, F5) den m Kommunikationskontrollern (CC1, CC2) derart zuzuteilen, dass die Nachrichtenspeicher der m Kommunikationskontroller (CC1, CC2) gleichmäßig genutzt werden, und für jeden der m Kommunikationskontroller (CC1, CC2) ein FlexRay Parameterset zu erstellen, wobei der FlexRay Parameter MicroTick in Abhängigkeit von der Hardwareclock des Kommunikationskontrollers (CC1, CC2) eingestellt wird und der FlexRay Parameter SamplesPerMicroTick eingestellt wird, um die vorgegebene Datenübertragungsrate im FlexRay Kommunikationsnetzwerk (1) zu erreichen.

Description

Restbus-Simulation eines FlexRay Kommunikationsnetzwerkes
Die gegenständliche Erfindung betrifft ein Verfahren und eine Anordnung zur Restbus- Simulation eines FlexRay Kommunikationsnetzwerkes.
Ein Kommunikationsnetzwerk umfasst in der Regel eine Mehrzahl von Netzwerkknoten, die untereinander Daten nach einem vorgegebenen Kommunikationsprotokoll austauschen. Bei einer an sich bekannten Restbus-Simulation wird ein Teil des Kommunikationsnetzwerkes, also eine Anzahl von Netzwerkknoten, simuliert, während der verbleibende Teil des Kommunikationsnetzwerkes real vorhanden ist. Dazu werden häufig Kommunikationskontroller eingesetzt, wobei für jeden zu simulierenden Netzwerkknoten ein Kommunikationskontroller (physisch als Hardware oder logisch als Software) vorhanden ist, der das Verhalten des Netzwerkknotens simuliert. Dabei können auch mehrere Netzwerknoten auf einem Kommunikationskontroller simuliert werden. Im Idealfall ist es für die anderen Netzwerkteilnehmer nicht erkennbar dass Teile des Kommunikationsnetzwerkes durch eine Simulation ersetzt worden sind. Die Herausforderung besteht dabei in der Methodik, wie die Funktionen der real existierenden, zu simulierenden n Netzwerkknoten auf m Kommunikationskontroller platziert werden, wobei in der Regel m < n ist. D.h., dass in der Regel ein Kommunikationskontroller mehr als einen Netzwerkknoten simulieren muss. Dabei müssen die Kommunikationsparameter der n Netzwerkknoten auf eine bestimmte Weise zusammengeführt werden, um auf m Kommunikationskontroller eine möglichst akkurate Nachbildung des Verhaltens des Ge- samtnetzwerkes zu erreichen.
Bei einem FlexRay Kommunikationsnetzwerk (ein bekanntes, serielles, deterministisches und fehlertolerantes Kommunikationsnetzwerk, das über eine zugehörige Spezifikation genau festgelegt ist und hauptsächlich für den Einsatz in Fahrzeugen entwickelt wurde), ist eine Restbus-Simulation aber nur sehr schwierig zu realisieren, da ein FlexRay Kommunika- tionsnetzwerk einmal parametrisiert bzw. konfiguriert wird und danach an der Parametrisie- rung im laufenden Betrieb nichts mehr geändert werden kann. Für Änderungen müsste das gesamte Kommunikationsnetzwerk gestoppt werden, neu konfiguriert werden und wieder gestartet werden, was sehr aufwendig ist. Während des Betriebs des Kommunikationsnetzwerkes kann die Konfiguration bzw. die Parametrierung der Netzwerkknoten nicht geändert werden. Das ist natürlich ein großes Problem für eine Restbus-Simulation, bei der mehr Netzwerkknoten simuliert werden sollen, als dafür Kommunikationskontroller zur Verfügung stehen, da ein Kommunikationskontroller deshalb nicht einfach zwischen verschiedenen Parametersets hin- und herschalten kann. Es ist daher eine Aufgabe der gegenständlichen Erfindung, ein Verfahren und eine Anordnung anzugeben, mit der eine Restbus-Simulation bei einem FlexRay Kommunikationsnetzwerk möglich wird.
Diese Aufgabe wird erfindungsgemäß dadurch gelöst, indem von den n zu simulierenden Netzwerkknoten zuerst alle s Netzwerkknoten mit einer Startup-Fähigkeit je einem Kommunikationskontroller zugeteilt werden, die verbleibenden n-s Netzwerkknoten den m Kommunikationskontrollern zugeteilt werden, sodass die Nachrichtenspeicher der m Kommunikationskontroller gleichmäßig genutzt werden, und für jeden der m Kommunikationskontroller ein FlexRay Parameterset erstellt wird, wobei der FlexRay Parameter MicroTick in Abhängigkeit von der Hardwareclock des Kommunikationskontrollers eingestellt wird und der FlexRay Parameter SamplesPerMicroTick eingestellt wird, um die vorgegebene Datenübertragungsrate im FlexRay Kommunikationsnetzwerk zu erreichen. Mit dieser Konfiguration kann eine zuverlässige Restbus-Simulation eines FlexRay Kommunikationsnetzwerks mit weniger Kommunikationskontroller als zu simulierende Netzwerkknoten realisiert werden. Die Stabilität der Restbus-Simulation kann verbessert werden, wenn das Parameterset jedes Kommunikationskontrollers Parameter für den sicheren Hochstart des FlexRay Kommunikationsnetzwerkes enthält, die aus den Parametern der auf dem jeweiligen Kommunikationskontroller zu simulierenden Netzwerkknoten ermittelt werden, um ein sicheres Hochfahren des Kommunikationsnetzwerkes sicher zu stellen. Ebenso, wenn das Parameterset jedes Kommunikationskontrollers Parameter für die Aufrechterhaltung der Funktion des FlexRay Kommunikationsnetzwerkes enthält, die aus den Parametern der auf dem jeweiligen Kommunikationskontroller zu simulierenden Netzwerkknoten ermittelt werden, um das Kommunikationsnetzwerk möglichst fehlertolerant zu konfigurieren.
Parameter für die in der FlexRay Spezifikation eine Berechnungsvorschrift vorgegeben ist, werden vorzugsweise berechnet, indem die für den Kommunikationskontroller vorher ausgewählten Parameter als Parameter für die Berechnungsvorschrift herangezogen werden.
Die gegenständliche Erfindung wird nachfolgend unter Bezugnahme auf die schematischen, beispielhaften und nicht einschränkenden Figuren 1 und 2 näher erläutert. Dabei zeigt
Fig.1 ein FlexRay Kommunikationsnetzwerk und
Fig.2 eine beispielhafte Restbus-Simulation dieses FlexRay Kommunikationsnetzwerks.
Fig.1 zeigt ein FlexRay Kommunikationsnetzwerk 1 , welches k (hier zehn) Netzwerkknoten F1 ... F10 umfasst. Davon sollen n Netzwerkknoten, hier die Netzwerkknoten F1 , F2, F3, F5, mittels einer Restbus-Simulation simuliert werden, wobei die verbleibenden Netzwerkknoten F4, F6 ... F10 weiterhin real vorhanden sind. Die Netzwerkknoten F1 , F2, F3, F5 werden hier in einer Restbus-Simulation auf zwei Kommunikationskontrollern CC1 , CC2 simuliert, wie in Fig.2 gezeigt. Die Kommunikationskontroller CC1 , CC2 sind hierzu auf einer geeigneten Simulationshardware 2, wie z.B. ein Computer, implementiert und könnte dazu entweder als Hardwarebauteile, z.B. in Form von Steckkarten, oder in Form von Software realisiert sein.
Für die Restbus-Simulation muss zunächst natürlich die Netzwerk Topologie modifiziert werden. Dazu werden die zu simulierenden Netzwerkknoten F1 , F2, F3, F5 physisch vom Kommunikationsnetzwerk 1 getrennt und die Simulationshardware 2 dem Kommunikationsnetzwerk physisch hinzugefügt. Bei der Abbildung der n (hier vier) zu simulierenden Netzwerkknoten F1 , F2, F3, F5 auf die m (hier zwei) Kommunikationskontroller CC1 , CC2 müssen jene mit Startup-Fähigkeit mit Vorrang behandelt werden. In einem FlexRay Kommunikationsnetzwerk müssen eine Anzahl von Netzwerkknoten mit einer sogenannten Startup-Fähigkeit ausgestattet sein. Ausschließlich diese Netzwerkknoten können den Start des FlexRay Kommunikationsnetzwerkes an- stoßen, indem diese versuchen ein sogenanntes Kollisionsvermeidungssymbol (collision avoidance symbol CAS) zu senden. Nur der Netzwerkknoten, der ein Kollisionsvermeidungssymbol senden konnte, kann innerhalb der nächsten vier Zyklen nach dem CAS Star- tup Nachrichten versenden. Danach senden die anderen Netzwerkknoten mit Startup- Fähigkeit und erst danach die restlichen Netzwerkknoten. Im gezeigten Beispiel weisen z.B. die s (hier zwei) Netzwerkknoten F1 , F3 Startup-Fähigkeit auf und werden daher verschiedenen Kommunikationskontrollern CC1 , CC2 zugeordnet. Normalerweise sollte sich die Anzahl s der Netzwerkknoten mit Startup-Fähigkeit im Kommunikationsnetzwerk 1 nicht ändern. Daher werden wenn möglich alle s Netzwerkknoten mit Startup-Fähigkeit auf eigene Kommunikationskontroller CC1 , CC2 zugeordnet. Der Netz- werkknoten F1 wird hier dem Kommunikationskontroller CC1 und der Netzwerkknoten F3 dem Kommunikationskontroller CC2 zugeordnet. Im Falle s > m, wenn also mehr Netzwerkknoten mit Startup-Fähigkeit als Kommunikationskontroller CC1 , CC2 vorhanden sind, ist keine perfekte Restbus-Simulation möglich. Dieser Fall kann nur durch Hinzufügen weiterer Kommunikationskontroller perfekt gelöst werden. In den meisten Fällen wird der Betrieb des FlexRay Kommunikationsnetzwerkes 1 jedoch auch mit einer reduzierter Anzahl von Netzwerkknoten mit Startup-Fähigkeit F1 , F3 einwandfrei funktionieren, sodass trotzdem eine Restbussimulation möglich ist.
Nachdem die s Netzwerkknoten mit Startup-Fähigkeit F1 , F3 zugeteilt wurden, werden die verbleibenden n-s Netzwerkknoten F2, F4 den verfügbaren Kommunikationskontrollern CC1 , CC2 zugeordnet. Hier gilt zu beachten, dass die verfügbaren FlexRay Kommunikationskon- troller CC1 , CC2 nur eine begrenzte Anzahl bzw. Größe von Nachrichten-Speicher, vorgegeben durch die Simulationshardware 2, zur Verfügung haben. Diese Zuordnung erfolgt daher derart, dass die verfügbaren Nachrichtenspeicher der Kommunikationskontroller CC1 , CC2 möglichst gleichmäßig ausgenutzt werden. Zu diesem Zweck können bekannte Opti- mierungsverfahrens, wie z.B. Simulierte Abkühlung (simulated annealing), Genetische Opti- mier-Algorithmen, etc., verwendet werden. Dabei ist das bevorzugte Muss-Kriterium, dass der Nachrichtenspeicher während der Restbus-Simulation bei keinem der m Kommunikationskontroller CC1 , CC2 überläuft. Weitere Rahmenbedingungen dieser Optimierung können die Gleichverteilung der zu übertragenden Nachrichten auf die m Kommunikationskontroller CC1 , CC2 sein, damit die ankommenden/ausgehenden Nachrichten möglichst parallel bearbeitet werden können und so die Latenzzeiten niedrig gehalten werden. Auch hinsichtlich späterer Erweiterungen der Restbus-Simulation ist eine möglichst gleichverteilte Auslastung der zur Verfügung stehenden Kommunikationskontroller CC1 , CC2 vorteilhaft.
Für jeden Netzwerkknoten F1 ... F10 im Kommunikationsnetzwerk 1 existiert ein FlexRay Parameterset, die die fehlerfreie Kommunikation der Netzwerkknoten F1 ... F10 untereinander gewährleisten. Die benötigten Parameter sind dabei durch die FlexRay Spezifikation vorgegeben, wobei bei der Konfiguration des Kommunikationsnetzwerkes 1 die Werte dieser Parameter festgelegt werden. Diese können als Eigenheit eines FlexRay Kommunikationsnetzwerkes während des Betriebs des Kommunikationsnetzwerkes 1 nicht mehr geändert werden.
Für alle der Simulationshardware 2 zur Verfügung stehenden Kommunikationskontrollern CC1 , CC2 muss daher ein lokales FlexRay Parameterset festgelegt werden. Dabei sind die FlexRay-Parameter so zu wählen, dass die Simulation der darauf simulierten Netzwerkknoten F1 , F2, F3, F5 auf den Kommunikationskontrollern CC1 , CC2 möglichst gut die Realität widerspiegelt. Aufgrund der Eigenheiten von FlexRay kann für jeden Kommunikationskontroller CC1 , CC2 aber nur ein FlexRay Parameterset festgelegt werden, das für alle darauf simulierten Netzwerkknoten F1 , F2 und F3, F5 zur Anwendung kommt.
Kritisch dabei sind die hardwareabhängigen Parameter MicroTick und SamplesPerMicroTick, die die zeitliche Bit-Länge einer FlexRay-Nachricht festlegen. Ausgegangen wird dabei von der Hardwareclock (bzw. von der Quarzfrequenz der Hardwareclock) des zugehörigen Kommunikationskontrollers CC1 , CC2, womit der Parameter MicroTick festgelegt ist. Bei einer Hardwareclockfrequenz des Kommunikationskontrollers CC1 , CC2 von z.B. 80MHz ergibt sich folglich als Zeitbasis der Parameter MicroTick zu 1/80MHz = 12,5ns. Ebenfalls ist im FlexRay Kommunikationsnetzwerk 1 eine Datenübertragungsrate (Bitrate in MBit/s) vor- gegeben bzw. eingestellt, die von allen Netzwerkknoten F1 ... F10 und damit auch von den Kommunikationskontrollern CC1 , CC2 einzuhalten ist. Die FlexRay Spezifikation lässt dabei nur bestimmte Datenübertragungsraten, nämlich 2,5MBit/s, 5MBit/s und 10MBit/s, zu. Der Parameter SamplesPerMicroTick ist nun so einzustellen, dass die vorgegebene Datenübertragungsrate eingehalten wird, wobei zu beachten ist, dass auf den Kommunikationskontrollern CC1 , CC2 die Bitlänge als ganzzahliges Vielfaches des Parameters SamplesPerMicro- Tick vorgegeben oder einstellbar ist. Bei einer einzustellenden Datenübertragungsrate von 10MBit/s, einer Hardwareclockfrequenz von 80MHz und einer Bitlänge von
8xSamplesPerMicroTick ergibt sich der Parameter SamplesPerMicroTick folglich zu SamplesPerMicroTick^ . Mit SamplesPerMicroTick=2 würde man eine Datenübertragungsrate von 5MBit/s einstellen und mit SamplesPerMicroTick=4 eine Datenübertragungsrate von
2,5MBit/s.
Ausgangspunkt für die bevorzugte Festlegung der restlichen benötigten FlexRay Parameter der Kommunikationskontroller CC1 , CC2 sind die Parameter der zugeordneten, zu simulierenden Netzwerkknoten F1 , F2, F3, F5. Hierzu ist anzumerken, dass diese Parameter für die Restbus-Simulation auch anders konfiguriert werden können, die nachfolgende Konfiguration aber eine sichere und zuverlässige Restbus-Simulation des FlexRay Kommunikationsnetzwerkes ermöglicht. Dabei kann man zwischen verschiedenen Parametern unterscheiden:
Parameter für den sicheren Hochstart des FlexRay Kommunikationsnetzwerkes 1 : Hier gilt es eine Kombination der einzelnen Parameter zu wählen, damit ein sicherer Hochstart des Netzwerkes gewährleistet wird. Dies betrifft insbesondere die Parameter AllowPassiveTo Active, AcceptedStartupRange, WakeupPattern, KeySlotld, KeySlotUsedForStartup, KeySlo- tUsedForSync und SingleSlotEnabled.
Parameter für die Aufrechterhaltung der Funktion des FlexRay Kommunikationsnetzwerkes 1 : Alle zeitlich relevanten Parameter der FlexRay Kommunikationskontroller CC1 , CC2 werden so ausgelegt werden, damit möglichst große zeitliche Spielräume am Netzwerk verfüg- bar sind, um Kollisionen am Bus vorzubeugen und um den Bus möglichst fehlertolerant zu konfigurieren. Dies betrifft die FlexRay Parameter HaltDueToCIock, ClusterDriftDamping, DelayCompensation, LatestTx, OffsetCorrectionOut und RateCorrectionOut.
Der Parameter DelayCompensation ist abhängig von der verwendeten Netzwerktopologie. Bei örtlich verteilten Netzwerken mit größerer Leitungslänge zwischen den Netzwerkknoten ist durch die begrenzte Ausbreitungsgeschwindigkeit vp der Signale (~ 2/3 Lichtgeschwindigkeit bei FlexRay Kabeln) eine perfekte Uhren-Synchronisation alleine auf Basis von gesendeten Datenpaketen schwierig. Hier hilft der DelayCompensation-Parameter. Damit kann jedem Knoten die Distanz d mitgeteilt werden wie weit er vom fiktiven Zentrum des Netzwerks entfernt ist. Die Distanz ist entweder aus der Netzwerktopologie bekannt oder wird abgeschätzt. Weit entfernte Knoten können so ihre Datenframes etwas früher wegschicken damit sie im fiktiven Zentrum des Netzwerkes rechtzeitig eintreffen. Im Falle von empfangenen Frames kann der weit entfernte Knoten die Ankunftszeit der Frames ebenfalls korrigieren und so aus Sicht der anderen Netzwerkknoten das Zeitraster perfekt einhalten. Ein Wert für DelayCompensation lässt sich mit folgender Formel abschätzen: DelayCompensation =
vp ■ MicroTick
Parameter des FlexRay Kommunikationsnetzwerkes 1 mit Berechnungsvorschrift: Letztendlich gibt es einige Parameter, die mittels Berechnungsvorschrift laut FlexRay Spezifikation von den anderen Parametern abgeleitet werden, also nicht frei wählbar sind. Hierzu zählen MicroPerCycle, MicrolnitialOffset, MacrolnitialOffset, MaxDrift, DecodingCorrection und Lis- tenTimeout. Für die Berechnungsvorschriften werden dabei auf jedem Kommunikationskontroller CC1 , CC2 die Parameter der auf dem Kommunikationskontroller CC1 , CC2 zu simulierenden Netzwerkknoten F1 , F2, F3, F5 verwendet, so wie sie oben beschrieben ausgewählt wurden. Da diese Berechnungsvorschriften Teil der FlexRay Spezifikation und damit bekannt sind, werden diese Berechnungsvorschriften hier nicht eigens angeführt. Die FlexRay Parameter eines Kommunikationskontrollers CC1 , CC2 könnten erfindungsgemäß wie folgt gesetzt werden, um eine Restbussimulation zu ermöglichen:
Figure imgf000008_0001
setztem Flag„KeySlotUsedForStartup"
KeySlotUsedForStartup ODER Verknüpfung (boolsche Variable)
KeySlotUsedForSync ODER Verknüpfung (boolsche Variable)
ListenTimeout Berechnungsvorschrift FlexRay Spezifikation
SingleSlotEnabled UND Verknüpfung (boolsche Variable)

Claims

Patentansprüche
1 . Verfahren zur Restbus-Simulation eines FlexRay Kommunikationsnetzwerkes (1 ) mit einer Mehrzahl von k Netzwerkknoten (F1 bis F10), wobei n<k Netzwerkknoten (F1 , F2, F3, F5) des Kommunikationsnetzwerkes (1 ) auf m<n Kommunikationskontrollern (CC1 , CC2) simuliert werden, dadurch gekennzeichnet, dass
a) von den n zu simulierenden Netzwerkknoten (F1 , F2, F3, F5) zuerst alle s Netzwerkknoten (F1 , F3) mit einer Startup-Fähigkeit je einem Kommunikationskontroller (CC1 , CC2) zugeteilt werden,
b) die verbleibenden n-s Netzwerkknoten (F2, F5) den m Kommunikationskontrollern (CC1 , CC2) zugeteilt werden, sodass die Nachrichtenspeicher der m Kommunikationskontroller (CC1 , CC2) gleichmäßig genutzt werden, und
c) für jeden der m Kommunikationskontroller (CC1 , CC2) ein FlexRay Parameterset erstellt wird, wobei der FlexRay Parameter MicroTick in Abhängigkeit von der Hardwareclock des Kommunikationskontrollers (CC1 , CC2) eingestellt wird und der FlexRay Parameter SamplesPerMicroTick eingestellt wird, um die vorgegebene Datenübertragungsrate im FlexRay Kommunikationsnetzwerk (1 ) zu erreichen.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass das Parameterset jedes Kommunikationskontrollers (CC1 , CC2) Parameter für den sicheren Hochstart des FlexRay Kommunikationsnetzwerkes (1 ) enthält, die aus den Parametern der auf dem jeweiligen Kommunikationskontroller (CC1 , CC2) zu simulierenden Netzwerkknoten (F1 , F2 und F3, F5) ermittelt werden, um ein sicheres Hochfahren des Kommunikationsnetzwerkes (1 ) sicher zu stellen.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Parameterset jedes Kommunikationskontrollers (CC1 , CC2) Parameter für die Aufrechterhaltung der Funktion des FlexRay Kommunikationsnetzwerkes (1 ) enthält, die aus den Parametern der auf dem jeweiligen Kommunikationskontroller (CC1 , CC2) zu simulierenden Netzwerkknoten (F1 , F2 und F3, F5) ermittelt werden, um das Kommunikationsnetzwerk (1 ) möglichst fehlertolerant zu konfigurieren.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das
Parameterset jedes Kommunikationskontrollers (CC1 , CC2) Parameter enthält, die anhand von Berechnungsvorschriften aus den Parametern der auf dem jeweiligen Kommunikationskontroller (CC1 , CC2) zu simulierenden Netzwerkknoten (F1 , F2 und F3, F5) ermittelt werden.
5. Anordnung zur Restbus-Simulation eines FlexRay Kommunikationsnetzwerkes (1 ) mit k Netzwerkknoten (F1 bis F10), von denen n<k Netzwerkknoten (F1 , F2, F3, F5) in der Restbus-Simulation simuliert werden, wofür auf einer Simulationshardware (2) m<n Kommunikationskontroller (CC1 , CC2) vorgesehen sind, die die n Netzwerkknoten (F1 , F2, F3, F5) simu- lieren, und die Anordnung derart konfiguriert ist, dass
a) alle s Netzwerkknoten (F1 , F3) mit einer Startup-Fähigkeit jeweils einem Kommunikationskontroller (CC1 , CC2) zur Simulation zugeteilt sind,
b) die verbleibenden n-s Netzwerkknoten (F2, F5) den m Kommunikationskontrollern (CC1 , CC2) zur Simulation zugeteilt sind, sodass die Nachrichtenspeicher der m Kommuni- kationskontroller (CC1 , CC2) gleichmäßig genutzt sind, und
c) jeder der m Kommunikationskontroller (CC1 , CC2) mit einem FlexRay Parameterset konfiguriert ist, bei dem der FlexRay Parameter MicroTick in Abhängigkeit von der Hard- wareclock des Kommunikationskontrollers (CC1 , CC2) konfiguriert ist und der FlexRay Parameter SamplesPerMicroTick konfiguriert ist, um die vorgegebene Datenübertragungsrate im FlexRay Kommunikationsnetzwerk (1 ) zu erreichen.
6. Anordnung nach Anspruch 5, derart konfiguriert, dass das Parameterset jedes Kommunikationskontrollers (CC1 , CC2) Parameter für den sicheren Hochstart des FlexRay Kommunikationsnetzwerkes (1 ) enthält, die aus den Parametern der auf dem jeweiligen Kommunikationskontroller (CC1 , CC2) zu simulierenden Netzwerkknoten (F1 , F2 und F3, F5) ermittelt worden sind, um ein sicheres Hochfahren des Kommunikationsnetzwerkes (1 ) sicher zu stellen.
7. Anordnung nach Anspruch 5 oder 6, derart konfiguriert, dass das Parameterset jedes Kommunikationskontrollers (CC1 , CC2) Parameter für die Aufrechterhaltung der Funktion des FlexRay Kommunikationsnetzwerkes (1 ) enthält, die aus den Parametern der auf dem jeweiligen Kommunikationskontroller (CC1 , CC2) zu simulierenden Netzwerkknoten (F1 , F2 und F3, F5) ermittelt worden sind, um das Kommunikationsnetzwerk (1 ) möglichst fehlertolerant zu konfigurieren.
8. Anordnung nach einem der Ansprüche 5 bis 7, derart konfiguriert, dass das Parameterset jedes Kommunikationskontrollers (CC1 , CC2) Parameter enthält, die anhand von Be- rechnungsvorschriften aus den Parametern der auf dem jeweiligen Kommunikationskontroller (CC1 , CC2) zu simulierenden Netzwerkknoten (F1 , F2 und F3, F5) ermittelt worden sind.
PCT/EP2013/071108 2012-10-17 2013-10-10 Restbus-simulation eines flexray kommunikationsnetzwerkes WO2014060272A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA50457/2012A AT511988A3 (de) 2012-10-17 2012-10-17 Restbus-Simulation eines FlexRay Kommunikationsnetzwerkes
ATA50457/2012 2012-10-17

Publications (1)

Publication Number Publication Date
WO2014060272A1 true WO2014060272A1 (de) 2014-04-24

Family

ID=48222569

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/071108 WO2014060272A1 (de) 2012-10-17 2013-10-10 Restbus-simulation eines flexray kommunikationsnetzwerkes

Country Status (2)

Country Link
AT (2) AT511988A3 (de)
WO (1) WO2014060272A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106549711A (zh) * 2016-10-27 2017-03-29 中国航空无线电电子研究所 一种用于机载光纤通道的混合触发调度方法
CN110865960A (zh) * 2018-08-28 2020-03-06 上海天王星智能科技有限公司 在网络上模拟PCIe总线

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007002312A1 (de) * 2007-01-16 2008-09-04 Bayerische Motoren Werke Aktiengesellschaft Restbussimulation

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007002312A1 (de) * 2007-01-16 2008-09-04 Bayerische Motoren Werke Aktiengesellschaft Restbussimulation

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BRAUN T D ET AL: "A Comparison of Eleven Static Heuristics for Mapping a Class of Independent Tasks onto Heterogeneous Distributed Computing Systems", JOURNAL OF PARALLEL AND DISTRIBUTED COMPUTING, ELSEVIER, AMSTERDAM, NL, vol. 61, no. 6, 1 June 2001 (2001-06-01), pages 810 - 837, XP004408216, ISSN: 0743-7315, DOI: 10.1006/JPDC.2000.1714 *
FLEXRAY CONSORTIUM ET AL: "FlexRay Communications System Protocol Specification Version 3.0.1", 31 October 2010 (2010-10-31), pages 1 - 268, XP055022829, Retrieved from the Internet <URL:http://www.scribd.com/doc/73436081/FlexRay-Protocol-Specification-V3-0-1> [retrieved on 20120326] *
THOMAS WAGGERSHAUSER ET AL: "Restbussimulation für FlexRay-Netzwerke", 15 December 2011 (2011-12-15), XP055092157, Retrieved from the Internet <URL:http://www.ixxat.de/download/artikel_20084_flexray-rest-bus-simulation_d.pdf> [retrieved on 20131209] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106549711A (zh) * 2016-10-27 2017-03-29 中国航空无线电电子研究所 一种用于机载光纤通道的混合触发调度方法
CN106549711B (zh) * 2016-10-27 2019-01-15 中国航空无线电电子研究所 一种用于机载光纤通道的混合触发调度方法
CN110865960A (zh) * 2018-08-28 2020-03-06 上海天王星智能科技有限公司 在网络上模拟PCIe总线

Also Published As

Publication number Publication date
AT511988A2 (de) 2013-04-15
AT16095U1 (de) 2019-01-15
AT511988A3 (de) 2013-11-15

Similar Documents

Publication Publication Date Title
EP1388238B1 (de) System und verfahren zur parallelen übertragung von echtzeitkritischen und nicht echtzeitkritischen daten über schaltbare datennetze, insbesondere ethernet
DE102014108455A1 (de) Verfahren zum Betreiben eines Netzwerks
DE10211281B4 (de) Verfahren und Vorrichtung zur Synchronisation der Zykluszeit von mehreren Bussen sowie entsprechendes Bussystem
EP3091714B1 (de) Verfahren zur bereitstellung eines namensdienstes innerhalb eines industriellen automatisierungssystems und kommunikationsgerät
DE102010041223A1 (de) Verfahren und Vorrichtung zur seriellen Datenübertragung mit umschaltbarer Datenrate
DE102010063797A1 (de) Verfahren und Vorrichtung zur seriellen Datenübertragung mit zusätzlich eingefügten Daten
DE102007048860A1 (de) Vorrichtung und Verfahren zur Manipulation von Kommunikations-Botschaften
DE102007047248A1 (de) Verfahren und Vorrichtung zur Manipulation von Kommunikations-Botschaften
EP3556058A1 (de) Teilnehmerstation für ein bussystem und verfahren zur datenübertragung in einem bussystem
EP3618384B1 (de) Verfahren zur simulation einer verarbeitung von reservierungsanfragen für multicast-datenströme in kommunikationsnetzen und simulationssystem
EP1702245B1 (de) Verfahren, Knoten und Netzwerk zum zyklischen Versenden von Ethernet-Telegrammen
EP1639758A2 (de) Verfahren, vorrichtung und system zum austausch von daten über ein bussystem
WO2014060272A1 (de) Restbus-simulation eines flexray kommunikationsnetzwerkes
AT514714A1 (de) Verfahren zur Übertragung von Nachrichten in einem Computernetzwerk sowie Computernetzwerk
EP2466406A1 (de) Verfahren zur automatischen Erzeugung von Dynamic Frame Packgruppen
EP3172869B1 (de) Verfahren zur nachbildung von laufzeiten in netzwerken, sowie entsprechendes gateway
DE102019125545B3 (de) Datenübertragungsverfahren, segment-telegramm und automatisierungskommunikationsnetzwerk
EP3151473B1 (de) Verfahren zur isochronen datenkommunikation in einem echtzeitfähigen ethernet-datennetzwerk
DE112016006244T5 (de) Zeitsynchrone slave-vorrichtung und kommunikationssteuerverfahren
EP3758310A1 (de) Verfahren zur datenkommunikation, netzwerksteuereinrichtung, netzwerk, computerprogramm und computerlesbares medium
EP2741453B1 (de) Verfahren zum betreiben eines busgeräts einer gebäudeautomatisierungseinrichtung, sowie entsprechendes konfigurationsgerät und entsprechendes computerprogrammprodukt
DE10216920A1 (de) Verfahren und Vorrichtung zur Überprüfung einer Überwachungsfunktion eines Bussystems und Bussystem
DE102010036456B4 (de) Verfahren und Optimierungskontrolleinheit zur Optimierung eines Kommunikationsablaufs für ein zeitgesteuertes Kommunikationssystem in einem Kraftfahrzeug
EP2232782B1 (de) Verfahren zur konfiguration von adressen in einem kommunikationsnetzwerk
DE10231424B4 (de) Vorrichtung und Verfahren zur Datenkommunikation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13774660

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13774660

Country of ref document: EP

Kind code of ref document: A1