DE102020200819A1

DE102020200819A1 - Erweiterung eines Busprotokolls mit Übergabe eines Nutzdatums im Header

Info

Publication number: DE102020200819A1
Application number: DE102020200819.1A
Authority: DE
Inventors: Ingo Lippenberger
Original assignee: ZF Friedrichshafen AG
Current assignee: ZF Friedrichshafen AG
Priority date: 2020-01-23
Filing date: 2020-01-23
Publication date: 2021-07-29

Abstract

Master und Slave, sowie Verfahren zur Datenübertragung zwischen einem Master und wenigstens einem Slave über einen Bus mit einem Protokoll, welches einen Header mit einem ID- oder Adressfeld aufweist. Das ganze oder Teile des ID- oder Adressfelds (PID) werden dazu genutzt, ein Nutzdatum oder Befehl zu übertragen.

Description

Die Erfindung betrifft ein Verfahren zur Erweiterung eines Busprotokolls und einen Master und einen Slave.
Stand der Technik
Im Stand der Technik existieren verschiedene Arten von Feldbussen, die unterschiedliche Anforderungen erfüllen und je nach Anwendung optimiert nach Kosten, Datenübertragungsraten, Echtzeitanforderungen etc. auszulegen sind. Der LIN (Local Interconnect Network) Bus, welcher vom LIN Konsortium spezifiziert wurde, dient insbesondere im Automobilbereich als kostengünstige Lösung, die Übertragungsgeschwindigkeiten bis 20 kbit/s ermöglicht, respektive beschränkt. Eine weitere Beschränkung ist die Verzugszeit von 20 ms zwischen zwei aufeinander folgenden Botschaften.
Falls sich, insbesondere während einer nahezu abgeschlossenen Entwicklung oder dem Betrieb, herausstellt, dass die Datenübertragungsrate nicht ausreicht, so müsste klassischerweise ein anderes Bussystem verwendet werden und ggf. Hardware kostenintensiv getauscht und redesignt werden.
Wie in DE102016105264A1 in [0027] beschrieben, werden Signalisierung/Header üblicherweise getrennt von Nutzdaten übertragen.
Der GSM Standard der Mobilfunkübertragung lehrt ein Durchbrechen dieser Trennung, da SMS-Nachrichten als Bestandteil der Signalisierung übertragen werden. Jedoch trifft dies nicht für paketvermittelte Feldbusse, wie den LIN zu.
Offenbarung der Erfindung
Ein Verfahren zur Datenübertragung zwischen einem Master und wenigstens einem Slave über einen Bus mit einem Protokoll, welches einen Header mit einem ID- oder Adressfeld aufweist und umfasst, dass das ganze oder Teile des ID- oder Adressfelds dazu genutzt werden ein Nutzdatum oder Befehl zu übertragen.
Bus, Protokoll, sowie Master und Slave sind bekannte Begriffe aus der Netzwerktechnik. Vorliegend können Master und Slave die logischen Kommunikationseinheiten bezeichnen, die Bestandteil (jeweils) eines eigenständigen Geräts sind und in diesem entweder integriert, z. B. in dem ein Mikrocontroller des Geräts die Master- bzw. Slavefunktionalität bereitstellt oder als eigenständige Hardwareeinheiten/-module ausgebildet sind.
Der Header ist in vielen Protokollen definiert als Bestandteil eines Frames, der den eigentlichen Nutzdaten vorausgeht und Metadaten insbesondere eine Adresse in einem Adressfeld enthält, die angibt, für welchen Slave der Frame bestimmt ist. Dies ist insbesondere bei einem nicht kollisionsfreien Bus notwendig, auf dem mehrere Slaves gleichzeitig mithören oder senden. Näheres findet sich in der jeweiligen Protokollspezifikation des Busses.
Der Begriff Daten bezeichnet das, was normalerweise (d. h. gemäß Spezifikation des Protokolls) nicht im Header, sondern dem Header folgenden Datenfeldern übertragen wird. Normalerweise dient das ID-/Adressfeld zur Identifikation, Adressierung bzw. dem Ansprechen von Slaves. Sollte die Anzahl von Slaves kleiner sein, als der mit der Größe des ID-/Adressfeld adressierbaren Anzahl an Adressen, dann gibt es sozusagen freie/unbenutzte Adressen, die anderweitig genutzt werden können, nämlich um Daten oder Befehle zu übertragen.
Ein gewöhnliches Adressfeld mit einer bestimmten Anzahl an Bits erlaubt die Adressierung einer maximalen Anzahl an Slaves. Das beschriebene Vorgehen benötigt jedoch freie Adressen, d. h. einen Adressraum des Adressfeldes, welches nicht durch zu adressierende Slaves ausgeschöpft wird. Diese freien Adressen können für das Nutzdatum oder Befehle verwendet werden.
Vorteilhafterweise können unter den beschriebenen Voraussetzungen Nutzdaten bereits im Header übertragen werden, auf die später verzichtet werden kann. Je nach Protokollbeschaffenheit, können so Bitfolgen oder ganze Frames eingespart werden, bei gleicher übertragener Menge an Nutzdaten, was wiederum den effektiven Datendurchsatz, bzw. die Geschwindigkeit des Busses erhöht.
Für die Datenverarbeitung und (Wirtschafts-)Informatik werden Daten als Zeichen (oder Symbole) definiert, die Informationen darstellen und die dem Zweck der Verarbeitung dienen und einen Nutzen bringen. Daher kommt der Begriff Nutzdaten bzw. Nutzdatum. Der Begriff Datum bezeichnet den Singular von Daten und ist synonym verwendbar, da ein Nutzdatum oder Nutzdaten gleichermaßen aus einer Anzahl an Bits bestehen. Erst aufgrund der logischen Zuordnung entsteht eine Unterscheidung. Ein Nutzdatum kann eine bestimmte Anzahl an Bits umfassen, z. B. ein Byte sein, in vorliegenden Ausführungsbeispielen aber auch weniger Bits umfassen. Nutzdaten können mehrere Einheiten eines Nutzdatums umfassen.
Beim Zuordnen des Nutzdatums oder Befehls zu dem Adressfeld kann es, je nach Schichtenmodell und Betrachtungsweise, dazu kommen, dass das Nutzdatum das ursprünglich in einer höheren Schicht (z. B. Anwendungsschicht) übertragen wurde im Master und Slave, auf eine niedrigere Schicht gebracht werden muss, um im Adressfeld verpackt zu werden.
In einer weiteren Ausführungsform umfasst das Verfahren, dass das Adressfeld bitweise aufgeteilt wird und eine Gruppe der Bits für die Adressierung genutzt wird, eine weitere Gruppe von Bits für das Nutzdatum und optional eine sonstige Gruppe für einen Befehl an den adressierten Slave.
Mit anderen Worten: Das ID- oder Adressfeld wird auf Bits aufgeteilt und eine Gruppe dieser derart aufgeteilten Bits für die Adressierung genutzt. Eine weitere Gruppe von Bits wird entweder für das Nutzdatum oder für einen Befehl an den adressierten Slave genutzt. Ggf. kann es auch eine dritte Gruppe geben, so dass eine Gruppe für die Adressierung, eine weitere für das Nutzdatum und eine sonstige für den Befehl vorhanden sind.
Diese Art der Nutzung setzt voraus, dass lediglich maximal die halbe Anzahl der normalerweise maximal möglichen Slaves adressierbar sein darf, um (für diesen Grenzfall) wenigstens ein Bit frei zu bekommen.
Wenn durch die Übertragung des Nutzdatums im Adressfeld slaveseitig bereits klar ist, was mit diesem Nutzdatum geschehen soll, kann vorteilhafterweise ggf. der (vormals) notwendige Befehl zur Verwendung dieses Nutzdatums überflüssig werden. Der Wert für den vormals notwendigen Befehl kann dann für einen anderen Befehl oder Nutzdatum vergeben werden. Das Nutzdatum wäre dann logisch unabhängig von der parallel übertragenen Adresse oder des Befehls.
So kann ein Nutzdatum an einen Slave gerichtet sein, parallel wird aber ein anderer Slave adressiert, an den die Daten im Daten-Feld hinter dem Header gerichtet sind. Alternativ kann ein Slave das Nutzdatum auf eine bestimmte Weise verarbeiten und erhält parallel einen Befehl zu einem weiteren Zweck.
In einer weiteren Ausführungsform umfasst das Verfahren, dass eine Kommunikation zwischen dem Master und genau einem Slave durchgeführt wird.
Dadurch wird eine Peer-to-peer Verbindung (1:1 Beziehung) begründet und die Notwendigkeit einer Adressierung entfällt, da der Empfänger der Nachricht immer eindeutig (derselbe) ist. Für diese Busstruktur ergibt sich der Vorteil, dass alle Adressbits für das Nutzdatum oder Befehl verwendet werden können.
In einer weiteren Ausführungsform umfasst das Verfahren, dass im ID- oder Adressfeld entweder Werte übertragen werden, die Befehle repräsentieren oder andere Werte, die das Nutzdatum repräsentieren.
Hier wird, anders als im vorigen Ausführungsbeispiel nicht mehr auf getrennte Gruppen von Bits abgestellt, die unterschiedliche Dinge beinhalten.
Hier können entsprechend der Länge des Adressfeldes eine bestimmte Anzahl von unterschiedlichen Adressen benannt werden bzw. im Adressfeld eine solche Anzahl an Werten übertragen werden. Vorliegend ist eine Adresse bei einer Peer-to-peer Verbindung nicht notwendig, stattdessen wird der Wertebereich der Werte des Adressfeldes aufgeteilt in einen Wertebereich für Befehle und einen für Daten. Je nach Definition, die in der Konfiguration des Systems technisch umgesetzt wird, ist zwischen Master und Slave vereinbart, was welcher Wert zu bedeuten hat.
Üblicherweise werden die beiden Wertebereiche zusammenhängend gewählt werden, jedoch ist auch eine beliebige Zersplitterung der Wertebereiche denkbar.
Vorteilhafterweise kann so der gesamte Wertebereich des Adressfeldes genutzt werden, auch wenn die beiden Wertebereiche sich nicht mit den Bitgrenzen (2 hoch x) decken.
Das Nutzdatum wird auf Basis des zur Verfügung stehenden Wertebereichs quantifiziert. Entsprechend kann das übertragene Nutzdatum maximal so viel Quantisierungsstufen bzw. verschiedene Datenwerte aufweisen, wie Werte im Adressfeld verfügbar sind, die nicht durch Befehle belegt sind.
Jeder Wert, der nicht einen Befehl darstellt, kann als Datenwert des Nutzdatums verwendet werden. Ein Datenwert entspricht dann dezidiert einem entsprechendem physikalischen Wert oder einem Wert, den der Master senden will. Über eine Transkriptionstabelle oder Umrechnungsformel kann der Datenwert bestimmt werden, der mit einer reziproken Umrechnung im Slave wieder zurücktransformiert wird.
In einer weiteren Ausführungsform umfasst das Verfahren, dass das Nutzdatum einen Wert für eine Drehzahl/Drehzahlvorgabe repräsentiert und der Slave dieses Nutzdatum zur Ansteuerung einer Pumpe für ein hydraulisches Fluid empfängt.
Vorteilhafterweise kann so der Overhead im Header für Nutzdaten zur Übertragung der Betriebspunktanforderung des ersten Steuergeräts an ein zweites Steuergerät für eine elektrisch angetriebene Pumpe genutzt werden, so dass ein höherer Durchsatz der Nutzdaten und eine bessere Dynamik als bisher erreicht wird.
In einer weiteren Ausführungsform umfasst das Verfahren, dass das Nutzdatum häufiger als der Befehl gesendet wird.
Wenn Nutzdatum und ein paralleler Befehl nicht gleichzeitig gesendet werden (können), so müssen Datenübertragungen und Befehlsübertragungen zeitlich geplant (geschedult) werden. Dadurch können vorteilhafterweise anwendungsbezogene Details im Ablauf realisiert werden.
In einer weiteren Ausführungsform umfasst das Verfahren, dass das Nutzdatum für die Drehzahl häufiger übermittelt wird, als ein Befehl zur Abfrage der Diagnosedaten und gleichzeitig dieser Befehl häufiger übermittelt wird, als ein Befehl zur Abfrage der Betriebstemperatur.
So wird eine häufige und zeitnahe Aktualisierung der (Soll-)Drehzahl der Pumpe erreicht, während die seltener notwendigen Diagnosedaten von der Pumpe seltener angefordert werden. Noch seltener bedarf es der Übermittlung der Betriebstemperatur, da diese sich nicht so schnell ändert.
In einer weiteren Ausführungsform umfasst das Verfahren, dass das zugrundeliegende Protokoll das LIN-Protokoll (Local Interconnect Network) ist. Das ID- oder Adressfeld entspricht hierbei dem Protected Identifier Field, wie in der Spezifikation des Busses spezifiziert.
Insbesondere kann das standardisierte LIN-Protokoll wie beschrieben erweitert, bzw. abgeändert werden.
Das LIN-Protokoll ist so aufgebaut, dass die beschriebene Idee vorteilhafterweise gut einsetzbar ist. So kann die Drehzahlvorgabe, die bisher dem Header folgenden Datenfeld übertragen wurde, nun auf die verbleibenden Object IDs als Werte für das Protected Identifier Field, d. h. diejenigen Object IDs bzw. Werte, die nicht von Befehlen belegt sind, aufgeteilt und die Verzugszeit reduziert werden.
Da der Header stets vom Master vorgegeben wird, kann nun nicht mehr nur in jeder zweiten Botschaft, sondern jetzt in jeder Botschaft die Drehzahlvorgabe verändert werden. Dies ist möglich, da ein Nutzdatum nun mit im Header untergebracht werden kann und folglich auf ein Daten-Feld für dieses Nutzdatum verzichtet werden kann. Dies kann vorteilhafterweise bis zur Halbierung der Verzugszeit führen.
Der Vorteil kommt vor allem bei Bussen mit starken Einschränkungen (wie dem LIN mit seinen 20 kbit/s) zum Tragen. Wird während einer Entwicklung die Grenze der Übertragungsfähigkeit erreicht, kann diese mittels der Erfindung noch ausgedehnt werden, ohne einen aufwändigeren Bus, wie den CAN, einzusetzen.
Weiterhin umfasst ein erstes Steuergerät für ein Getriebe einen Master zur Ausführung des beschriebenen Verfahrens.
Vorteilhafterweise weist das Steuergerät einen Master auf, der das beschriebene Verfahren/Protokoll verwirklicht und Header mit Adressfeldern, die ein Nutzdatum beinhalten, verschickt.
Weiterhin weist ein zweites Steuergerät für eine elektrisch angetriebene Pumpe einen Slave zur Ausführung des beschriebenen Verfahrens auf. Die Pumpe kann beispielsweise eine Hydraulikpumpe sein.
Vorteilhafterweise kann der Slave des zweiten Steuergeräts die ID- oder Adressfelder mit Nutzdatum interpretieren.
Nachfolgend werden unter Bezugnahme auf die beigefügten Figuren weitere Ausführungsbeispiele näher beschrieben und erläutert.
Es zeigen:

1 eine Steuergeräteanordnung;
2a eine Netzwerkstruktur eines Busses;
2b eine Aufteilung eines Protected Identifier Fields PID eines ersten Ausführungsbeispiels;
3a eine Netzwerkstruktur eines Busses einer Peer-to-Peer Verbindung;
3b eine Transkriptionstabelle für das Protected Identifier Field PID eines zweiten Ausführungsbeispiels;
3c eine Übersetzungstabelle eines dem Slave zugeordneten Geräts;
4 eine Abfolge von Nachrichten/Frames auf dem Bus.

1 zeigt eine Steuergeräteanordnung mit der Anordnung eines Getriebes G, das ein erstes Steuergerät EGS, z. B. ein Getriebesteuergerät oder Electronic Gear Shift umfasst oder von diesem angesteuert wird. Das Getriebe G, kann in einem Fahrzeug-Antriebsstrang Verwendung finden. Das erste Steuergerät EGS wiederum beinhaltet einen Master M, der für die Kommunikation des ersten Steuergeräts EGS über einen Bus B verantwortlich ist.
Weiterhin zeigt die Anordnung von Steuergeräten eine Pumpe P, die ein zweites Steuergerät SGP umfasst oder von diesem angesteuert wird. Die Pumpe P kann eine elektrisch antreibbare Pumpe P für die Fluidversorgung einer Hydraulik des Getriebes G sein, z. B. eine „Integrierte Elektrische Pumpe (IEP)“ oder eine „Elektromaschine (EM)“ eines „Leistungsverzweigten Pumpenantriebs (LVP)“, wie er z.B. in der Schrift DE102018206287A1 beschrieben ist. Das zweite Steuergerät SGP wiederum beinhaltet einen Slave S, der für die Kommunikation des zweiten Steuergeräts SPG über den Bus B verantwortlich ist.
Über den Bus B wird eine Nachricht bzw. Frame mit einem Header H übertragen, der ein ID- oder Adressfeld ID beinhaltet. In dem ID- oder Adressfeld ID werden Befehle Command X und/oder ein Nutzdatum Data Value X übertragen. Abhängig vom Protokoll findet die Übertragung vom Master M zum Slave S statt.
Die folgenden Ausführungsbeispiele werden anhand der Spezifikation des LIN-Busses gezeigt. Das ID- und Adressfeld ID entspricht dabei dem Protected Identifier Field PID. Beispiele für Befehle Command X sind die Befehle 1-11 Command 1-11 und Beispiele für Nutzdaten Data Value X sind die Nutzdaten 1-53 Data Value 1-53.
Ein erstes Ausführungsbeispiel ist in den 2a und 2b gezeigt. 2a zeigt eine mögliche Netzwerktopologie eines Busses B mit einem Master M und mehreren Slaves S₁-S₄ .
2b zeigt ein Protected Identifier Field PID eines LIN-Busses, wie es z. B. im Standard „LIN Specification Package Revision 2.2A" vom 31.12.2010 im Kapitel 2.3.1.3 beschrieben ist. Standardmäßig werden im LIN-Bus Start-, Stop- und Parity P₀ , P₁-Bits definiert. Die im Standard definierten 6 Bits 100-105, die für den Frame Identifier definiert sind, werden nun, über den Standard hinausgehend, wie folgt definiert:

1. Bits für die Adressangabe A₀ , A₁ . Da gemäß 2a vier Slaves S₁-S₄ angeschlossen sind, genügen zwei Bits für deren Adressierung.
2. Die restlichen Bits können als Datenbits D₀, D₃ zur Verfügung gestellt werden, mit deinen ein Nutzdatum Data Value X übertragen werden kann.

Je mehr Slaves S₁-S₄ vorhanden sind und je mehr Bits daher für die Adressierung A₀ , A₁ vorgehalten werden müssen, desto weniger Bits stehen für das Nutzdatum Data Value X zur Verfügung. Das Beispiel ist analog übertragbar für jede andere Anzahl von Slaves S₁-S₄ . Jedoch dürfen maximal 2^n-1 Slaves (n=6 für das Project Identifier Field PID von LIN) beteiligt sein, damit wenigstens ein Bit frei wird für die Nutzung für Daten.
Dabei ist zu beachten, dass das Protected Identifier Field PID gemäß Spezifikation in der Version 2.2 nicht die verbotenen Werte 0x3C bis 0x3F annehmen darf. Um die Spezifikation einzuhalten, muss funktional sichergestellt sein, dass keine Kombinationen aus Adress- und Datenbits auftauchen, die diese verbotenen Werte ergeben. Um das zu vermeiden, können z. B.:

- Daten- und Adressbits auch in einer anderen Reihenfolge angeordnet werden;
- auf das Bit A₀ verzichtet werden, d. h. dies bleibt immer 0, so dass die verbotenen Werte nie entstehen, dafür kann das Bit aber nicht genutzt werden;
- der LIN, bzw. der Master M so konfiguriert werden, bzw. der Wertebereich des Nutzdatums Data Value X so gewählt werden, dass besagte verbotene Werte nicht entstehen.

Es ist auch möglich, neben Adress- und Datenbits auch Befehlsbits vorzusehen, sprich 3 Gruppen von Bits.
Das Nutzdatum Data Value X kann von einem der Slaves S₁-S₄ direkt weiterverarbeitet werden, z. B. indem es die Entsprechung eines physikalischen Wertes Phys. Value beinhaltet oder dem Wertebereich für den Eingangsparameter des mit dem Slave S verbundenen Gerätes, z. B. einer Pumpe P, oder der verbundenen Funktion entspricht. Alternativ oder zusätzlich kann jedoch auch eine Umsetzung bzw. Umrechnung des Wertes stattfinden, wie in einer Übersetzungstabelle in 3c dargestellt.
Ein zweites Ausführungsbeispiel ist in den 3a bis 3c gezeigt. 3a zeigt eine mögliche Netzwerktopologie eines Busses B mit einem Master M und genau einem Slave S, wodurch eine sogenannte Peer-to-Peer Verbindung gebildet wird.
3b zeigt eine mögliche Transkriptionstabelle für den Inhalt des Protected Identifier Field PID eines LIN-Busses mit standardgemäßen 6 Bit Länge. Die Adressangabe entfällt hier, stattdessen wird ein erster Wertebereich für Befehle Command 1 bis Command 11 an den einen Slave S vorgesehen. Dafür werden beispielhaft die Werte 0x0 bis OxOA verwendet. Weitere Werte 0x0B bis 0x3B repräsentieren beispielhaft einen zweiten Wertebereich, um verschiedene Datenwerte Data Value 1 bis Data Value 53 eines Nutzdatums Data Value X zu übertragen.
So werden in einem Protected Identifier Field PID eines dazugehörigen Frames, anders als beim ersten Ausführungsbeispiel, entweder ein Befehl Command X oder ein Nutzdatum Data Value X übermittelt, nicht jedoch beides parallel im gleichen Frame. Wird gemäß diesem Beispiel ein Nutzdatum Data Value X im Header übertragen, kann auf ein nachfolgendes Data-Feld, wie in Kapitel 2.3.1.4 der o.g. Spezifikation beschrieben, um das Nutzdatum Data Value X zu übermitteln, verzichtet werden, da dies ja schon im Header H per Protected Identifier Field PID geschehen ist. Der Master M kann nach Abschluss des Sendens des Headers H daher sogleich, d. h. gegenüber dem Standard vorzeitig, mit dem Senden eines neuen Frames beginnen.
In 3c ist eine Übersetzungstabelle dargestellt, mit Hilfe derer die Nutzdaten 1-53 Data Value 1-53 in einen Wertebereich übertragen, den das dem Slave S zugeordnete zweite Steuergerät SGP, weiterverarbeiten kann. Diese weiter zu verarbeitenden Werte können z. B. eine physikalische Entsprechung, sprich physikalische Werte Phys. Value 1 - 53 eines Sollwerts, z. B. Betriebs-/Arbeitspunkts, sein oder Bitmuster zur Ansteuerung des Geräts, z. B. Pumpe P, zur Einstellung des durch das Nutzdatum 1-53 Data Value 1-53 repräsentierten Wertes.
Diese Rück-Übersetzung wird im zweiten Steuergerät SGP durchgeführt.
Abhängig von der Anwendung können so viele Bits zur Übertragung, z. B. komplette, normalerweise dem Header H folgende Daten-Felder, wie beschrieben, eingespart werden und das Nutzdatum 1-53 Data Value 1-53 trotzdem übermittelt werden. Dadurch kann die Bandbreite für diese Anwendungen erhöht werden.
Auch ein Hybrid der Ausführungsbeispiele 1 und 2 ist denkbar. So können auch mehr als ein Slave S mittels der Methode aus dem zweiten Ausführungsbeispiel angesprochen werden, indem z. B. bestimmte Werte aus dem Wertebereich des Protected Identifier Fields PID als für einen ersten Slave S₁ bestimmt konfiguriert werden, andere Werte für einen zweiten Slave S₂, usw.
In einer konkretisierten Form des zweiten Ausführungsbeispiels ist der Master M Bestandteil eines ersten Steuergeräts EGS eines Getriebes G, insbesondere eines Getriebes, welches in einem Fahrzeug-Antriebsstrang Verwendung findet. Der Slave S ist Bestandteil eines zweiten Steuergeräts SGP, welches einer elektrisch antreibbaren Pumpe P zugeordnet ist. Der Master M schickt entweder Anfragen zum Zustand bzw. zur Diagnose als Befehle Command X an den Slave S oder Nutzdaten Data Value X, die einer Drehzahlvorgabe für die Pumpe P entsprechen. So muss kein separates, dem Header H folgendes Datenfeld für die Drehzahlvorgabe mehr verwendet werden, sondern Drehzahlvorgaben können häufiger übertragen werden, da der gemäß Standard übliche Teil des Data-Frames entfallen kann. Vorteilhafterweise kann dabei auch der Befehl Command X für das Setzen der Drehzahl entfallen, da das Übertragen des Nutzdatums Data Value X den Befehl impliziert und der dadurch freie Wert für einen anderen Befehl Command X oder Nutzdatum Data Value X verwendet werden kann.
Für dieses Szenario könnte die Transkriptionstabelle des Protected Identifier Fields PID-Feldes wie folgt aussehen:

0x00: Anforderung der Diagnosedaten
0x01: Anforderung der Betriebstemperatur
0x02: Anforderung der aktuellen Drehzahl
0x10: Setzen der Drehzahl auf Stillstand
0x01: Setzen der Drehzahl auf Geschwindigkeit 1
0x02: Setzen der Drehzahl auf Geschwindigkeit 2
0x03: Setzen der Drehzahl auf maximale Geschwindigkeit

Würde die in der konkretisierten Form des zweiten Ausführungsbeispiels verwendete funktionale Anordnung hybrid mit der bitweisen Aufteilung des ersten Ausführungsbeispiels verwendet werden, d. h. der Befehl Command X würde in den Adressbits A₀ , A₁ kodiert werden und das Nutzdatum Data Value X in den Datenbits D₀ bis D₃, so könnten vorteilhafterweise gleichzeitig ein Befehl Command X und ein Nutzdatum Data Value X übertragen werden. Nachteiligerweise können dann aber evtl. nur weniger verschiedene Werte für Nutzdaten Data Value X übertragen werden, da der Wertebereich der für die jeweilige Gruppe genutzten Bits (immer Zweierpotenz) ggf. größer ist, als der tatsächlich genutzte Wertebereich.
In 4 ist eine beispielhafte Abfolge von Frames für die konkretisierte Form des zweiten Ausführungsbeispiels dargestellt, die über den Bus B übertragen werden. Dabei werden die Befehle Command X und Daten Data Value X abhängig von der benötigten Häufigkeit verschickt. Beispielsweise können Diagnosedaten (Diagnose A) relativ häufig (z. B. alle 100 ms) abgefragt werden, während die Betriebstemperatur (Diagnose B) seltener (z. B. alle 1 s) abgefragt wird. Da pro Zeiteinheit (z. B. alle 20 ms) ein Frame verschickt werden kann, können die sonstigen Plätze für Frames zum Setzen der Drehzahl (Set Data) verwendet werden, d. h. diese tauchen dann folglich verhältnismäßig häufig auf. Das genaue anwendungsbezogene Bestimmen des Zeitplans (Scheduling) wird in der Konfiguration festgelegt.
Bezugszeichenliste

EGS: Erstes Steuergerät
SGP: Zweites Steuergerät
H: Header
M: Master
S, S1-S4: Slave(s)
B: Bus
ID: ID- oder Adressfeld
PID: Protected Identifier Field
A0, A1: Gruppe von Bits, Adressbits
D0-D3: Weitere Gruppe von Bits, Datenbits
P0, P1: Paritybits
Command X: Befehl
Data Value X: Nutzdatum
Reserved for LIN: Reserviert gemäß LIN-Protokoll
Command 1-11: Befehle 1-11
Data Value 1-53: Nutzdatum 1-53
Phys. Value 1-53: Physikalischer Wert 1-53
Set Data: Nutzdatumsübermittlung
Diagnose A: Abfrage der Diagnosedaten
Diagnose B: Abfrage der Betriebstemperatur

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102016105264 A1 [0004]
DE 102018206287 A1 [0046]

Zitierte Nicht-Patentliteratur

tandard „LIN Specification Package Revision 2.2A“ vom 31.12.2010 [0050]

Claims

Verfahren zur Datenübertragung zwischen einem Master (M) und wenigstens einem Slave (S, S₁-S₄) über einen Bus (B) mit einem Protokoll, welches einen Header (H) mit einem ID- oder Adressfeld (ID) aufweist, dadurch gekennzeichnet, dass das ganze ID- oder Adressfeld (ID) oder Teile des ID- oder Adressfelds (ID) dazu genutzt werden ein Nutzdatum (Data Value X) oder einen Befehl (Command X) zu übertragen.
Verfahren zur Datenübertragung gemäß Anspruch 1, dadurch gekennzeichnet, dass das ID- oder Adressfeld (ID) auf Bits (A₀-A₁; D₀-D₃) aufgeteilt wird und eine Gruppe dieser derart aufgeteilten Bits (A₀-A₁) für die Adressierung genutzt wird, während eine weitere Gruppe von Bits (D₀-D₃) entweder für das Nutzdatum (Data Value X) oder für einen Befehl (Command X) an den adressierten Slave (S₁-S₄)) genutzt wird.
Verfahren zur Datenübertragung gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass eine Kommunikation zwischen dem Master (M) und genau einem Slave (S) durchgeführt wird.
Verfahren zur Datenübertragung gemäß Anspruch 3, dadurch gekennzeichnet, dass im ID- oder Adressfeld (ID) entweder Werte übertragen werden, die Befehle (Command X) repräsentieren oder andere Werte, die das Nutzdatum (Data Value X) repräsentieren.
Verfahren zur Datenübertragung gemäß einem der vorigen Ansprüche, dadurch gekennzeichnet, dass das Nutzdatum (Data Value X) häufiger als der Befehl (Command X) gesendet wird.
Verfahren zur Datenübertragung gemäß einem der vorigen Ansprüche, dadurch gekennzeichnet, dass das Nutzdatum (Data Value X) einen Wert für eine Drehzahl repräsentiert und der Slave (S) dieses Nutzdatum (Data Value X) zur Ansteuerung einer Pumpe (P) für ein hydraulisches Fluid empfängt.
Verfahren zur Datenübertragung gemäß Anspruch 6, dadurch gekennzeichnet, dass das Nutzdatum (Data Value X) für die Drehzahl häufiger übermittelt (Set Data) wird, als ein Befehl zur Abfrage der Diagnosedaten (Diagnose A) und gleichzeitig dieser Befehl häufiger übermittelt wird, als ein Befehl zur Abfrage der Betriebstemperatur (Diagnose B).
Verfahren zur Datenübertragung gemäß einem der vorigen Ansprüche, dadurch gekennzeichnet, dass das zugrundeliegende Protokoll das LIN (Local Interconnect Network) ist.
Erstes Steuergerät (EGS) für ein Getriebe (G), wobei das erste Steuergerät (EGS) einen Master (M) aufweist, zur Ausführung des Verfahrens nach einem der Ansprüche 1 bis 8.
Zweites Steuergerät (SGP) für eine Pumpe (P), wobei das zweite Steuergerät (SGP) einen Slave (S) aufweist, zur Ausführung des Verfahrens nach einem der Ansprüche 1 bis 8.