DE4229931C2 - Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes - Google Patents

Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes

Info

Publication number
DE4229931C2
DE4229931C2 DE4229931A DE4229931A DE4229931C2 DE 4229931 C2 DE4229931 C2 DE 4229931C2 DE 4229931 A DE4229931 A DE 4229931A DE 4229931 A DE4229931 A DE 4229931A DE 4229931 C2 DE4229931 C2 DE 4229931C2
Authority
DE
Germany
Prior art keywords
bus
application software
bus protocol
protocol chip
driver module
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.)
Expired - Fee Related
Application number
DE4229931A
Other languages
English (en)
Other versions
DE4229931A1 (de
Inventor
Bernd Dipl Ing Haeusler
Thomas Dipl Ing Thurner
Karlheinz Dipl Ing Mueller
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.)
Mercedes Benz Group AG
Original Assignee
Daimler Benz AG
Mercedes Benz 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 Daimler Benz AG, Mercedes Benz AG filed Critical Daimler Benz AG
Priority to DE4229931A priority Critical patent/DE4229931C2/de
Priority to GB9318239A priority patent/GB2270782B/en
Priority to US08/117,838 priority patent/US5444643A/en
Publication of DE4229931A1 publication Critical patent/DE4229931A1/de
Application granted granted Critical
Publication of DE4229931C2 publication Critical patent/DE4229931C2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • 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/901—Buffering arrangements using storage descriptor, e.g. read or write pointers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5691—Access to open networks; Ingress point selection, e.g. ISP selection
    • H04L12/5692—Selection among different networks
    • 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/9057—Arrangements for supporting packet reassembly or resequencing
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/03—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for
    • B60R16/0315—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for using multiplexing techniques
    • 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/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Control By Computers (AREA)
  • Communication Control (AREA)

Description

Die Erfindung betrifft ein Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes in einem Kraftfahrzeug nach der Gattung des Anspruchs 1.
Der vermehrte Einsatz elektrischer und insbesondere elek­ tronisch gesteuerter Aktuatoren, Motoren und Aggregate in Kraftfahrzeugen macht eine immer umfangreichere Verdrah­ tung erforderlich. Die steigende Anzahl von Kontakten und Kabeln bedingt wachsenden Fertigungsaufwand, Platzprobleme innerhalb der Karosserie und eine insgesamt sinkende Zu­ verlässigkeit, bei zunehmenden Kosten. Fehlersuchen wer­ den immer zeitraubender.
Um hier Abhilfe zu schaffen, wurde das CAN (Controller Area Network)-Konzept entwickelt. Es handelt sich dabei um ein serielles Busnetzwerk mit einem speziellen Datenübertra­ gungsprotokoll, in welches alle entsprechenden Komponenten eingebunden werden und welches eine Quasi-Echtzeitanwen­ dung mit sehr hoher Betriebssicherheit erlaubt.
Im Rahmen dieses neuen Konzepts werden alle Steuer- und Betriebsgeräte, die in einem solchen Busnetz betrieben wer­ den sollen, mit entsprechenden Hard- und Softwaremitteln ausgestattet, so daß sie sich dem Busprotokoll gemäß verhal­ ten und ohne gegenseitige Beeinträchtigung angesprochen wer­ den bzw. Daten oder Steuerbefehle vorzugsweise im Broad­ cast-Verfahren über das Netz verbreiten können. In der Praxis wird dies pro Steuergerät durch einen am Bus lie­ genden und diesen bedienenden Bus-Protokollchip, im fol­ genden auch CAN-Controller oder kurz CAN-Chip genannt, realisiert, welcher mit dem/den jeweiligen hierfür ent­ sprechend programmierten Mikrorechner/n des Steuergerä­ tes, d. h. mit der spezifischen Applikation, kommuniziert.
Die Vielzahl von busrelevanten Steuergeräten in einem Fahrzeug und die folgliche Beilieferung von unterschied­ lichen Herstellern hat demnach zur Folge, daß vergleich­ bare Zugriffe bzw. Kommunikationsfunktionen der jeweils steuergerätespezifischen Applikationssoftware auf den Bus je nach verwendetem CAN-Controller von jedem Steuergerä­ tehersteller separat gelöst werden müssen und in der Praxis auch auf jeweils andere Weise gelöst werden. Dies hat nicht nur einen insgesamt erheblichen Zeitaufwand für die jeweils individuelle Programmierung zur Folge. Aus je nach Programmierung unterschiedlichen bzw. streu­ enden Durchgriffszeiten von der Applikation über den CAN-Controller auf den Bus können verdeckte Probleme z. B. beim Echtzeitbetrieb einer großen Zahl von Steuer­ geräten unterschiedlicher Hersteller entstehen, auch wenn alle Geräte jeweils für sich alleine genommen das Bus-Protokoll einhalten.
In der Veröffentlichung "Vom Auto in die Industrie" in der FZ Elektronik 12/1990, S. 109-114, ist angesprochen, daß die controllernahe Programmierung für die Applikations­ programmierung durch Treiberfunktionen transparent gemacht werden kann, welche Steuer-, Verriegelungs- und Überwachungsfunktionen betreffen.
Demgegenüber ist es Aufgabe der Erfindung, ein Verfahren zu schaffen, welches eine einfache, zeitsparende, sichere und die vorgenannten Probleme minimierende Programmierung von unterschiedlichsten Kfz-Steuergeräten für Busbetrieb erlaubt.
Diese Aufgabe wird durch ein gattungsgemäßes Verfahren mit den kennzeichnungsgemäßen Merkmalen des unabhängi­ gen Patentanspruchs 1 gelöst.
Das erfindungsgemäße Verfahren macht den bzw. die in einem Kfz-Steuergerät jeweils einzusetzenden Bus-Proto­ koll-Chip/s (CAN-Controller) für den Programmierer der jeweiligen Applikationssoftware "unsichtbar". Da der bzw. die Bus-Protokollchip/s gegenüber der Applikationssoft­ ware also gewissermaßen "verdeckt" wird/werden, spielt die Art des/der jeweils verwendeten Bus-Protokoll-Chip/s auch keine Rolle mehr.
Diese Verdeckung wird dadurch geleistet, daß im Sinne einer Instruktions- und Kommunikationsoberfläche eine universelle, von dem/den Bus-Protokollchip/s unabhängige Schnittstelle definiert wird, zwecks Kopplung dieser Schnittstelle mit der/den Instruktions- und Kommuni­ kationsoberfläche/n des/der Bus-Protokollchip/s unab­ hängig von der Applikationssoftware ein auf den/die relevanten Bus-Protokollchip/s zugeschnittenes Treiber-Modul mit den Eigenschaften eines Adapters erzeugt wird, die steuergerätespezifische Applikationssoftware bezüglich der Buskommunikation ausschließlich auf die genannte Schnittstelle abgestimmt und ausgerichtet und insoweit unabhängig von dem/den Bus-Protokollchip/s erzeugt wird, die von dem/den Busprotokollchip/s un­ abhängige Applikationssoftware und das applikations­ unabhängige Treiber-Modul mittels eines Linkprozesses miteinander verknüpft werden und der so erhaltene Pro­ grammcode im ROM des wenigstens einen Mikrorechners des Steuergerätes resident abgelegt wird.
Die verknüpfte Niederlegung des CAN-Controller-spezifi­ schen Treiber-Moduls zusammen mit der jeweiligen Appli­ kationssoftware in jedem einzelnen von einer Vielzahl von Steuergeräten erspart so nicht nur unnötige Soft­ ware-Entwicklungszeit für gleichartige oder ähnliche Kommunikationsschritte bzw. -operationen.
Durch Reduktion der applikationsseitig auszuführenden Operationen auf nur wenige, einfache, jedoch leistungs­ fähige Routinen, die von der Applikation kommend auf den Bus gerichtet bzw. vom Bus kommend in die Applikation gerichtet auszuführen sind, kann auch eine sehr hohe Betriebssicherheit und Echtzeit-Verträglichkeit vieler Steuergeräte in einem CAN-Busnetzwerk erreicht werden, zumal entsprechende Treibermodule für unterschiedliche Bus-Protokollchips bzw. CAN-Controller jeweils zentral entwickelt, ausgetestet und verfügbar gemacht werden können.
Weitere Vorteile werden erschlossen, wenn das Treiber-Modul nach Lehre wenigstens eines der Ansprüche 2 bis 6 hergestellt wird. Werden z. B. gemäß Lehre des Anspruchs 4 wenigstens Netzwerk-Managementfunktionen in einem weite­ ren Modul zusammengefaßt und wird dieses weitere Modul analog dem Treiber-Modul der Applikationssoftware bei­ gelinkt, kann der Programmierer der Applikationssoftware von Aufrufen, Adressierungen und/oder Management-Algo­ rithmen befreit werden, die für das Zusammenwirken im Netz des betreffenden Kfz-Steuergerätes mit anderen notwendig sind. Diese und weitere Vorteile, die sich bei Anwendung des erfindungsgemäßen Verfahrens er­ schließen lassen, werden im Zuge der nachfolgenden Beschreibung unter Bezugnahme auf die Zeichnung auf­ gezeigt. Es zeigen:
Fig. 1 ein Strukturschema zur Veranschaulichung der Einbettung des Treiber-Moduls zwischen Bus-Protokollchip und Applikationssoftware;
Fig. 2 eine schematische Veranschaulichung der Adap­ terfunktion des Treiber-Moduls und seiner CAN-chip-spezifischen Austauschbarkeit;
Fig. 3 eine schemtische Veranschaulichung eines entsprechenden Treiber-Moduls zur Adaption dreier CAN-Chips an die Applikation;
Fig. 4 eine schematische Veranschaulichung der Ab­ arbeitung einer Sende-Warteschlange;
Fig. 5 eine Veranschaulichung von Kopierfunktionen des Treiber-Moduls;
Fig. 6 eine schematische Veranschaulichung mehrerer mit unterschiedlichen CAN-Chips ausgerüsteter und zu einer virtuellen Einheit integrierter Steuerge­ räte.
Im folgenden wird unter dem Kurzbegriff des "CAN-Chip" immer der hardwaremäßig zu bestückende Bus-Protokollchip verstanden. Ausdrücklich wird darauf hingewiesen, daß unter "dem" CAN-Chip auch mehrere entsprechende Exempla­ re verstanden werden können, die gewissermaßen einen leistungsfähigeren CAN-Chip substituieren bzw. imple­ mentieren. Des weiteren wird unter "Applikation" die Abwicklung der Applikationssoftware, d. h. der spezi­ fischen Betriebs- und Systemsoftware eines jeweils be­ trachteten Steuergerätes auf seiner (Applikations-) Hardware verstanden, mit der Wirkung der erwünschten Steuerfunktion.
Gemäß Fig. 1 kommuniziert die Applikationssoftware 11 nicht eigenständig über den CAN-Chip 1 mit dem Bus 2. Be­ züglich des Nachrichtenverkehrs mit letzterem stellt vielmehr das verfahrensgemäß herzustellende Treiber-Modul 10 einen intelligenten Adapter dar, über den jeder kommu­ nikative Zugriff auf den Bus 2 bzw. die Applikationssoft­ ware 11 zustande kommt. Hieraus folgt eine entkoppelnde bzw. isolierende Funktion des Treiber-Moduls 10 zwischen CAN-Chip 1 bzw. Bus 2 und Applikationssoftware 11.
Die Herstellung der Applikationssoftware kann in der Regel beim Hersteller bzw. Lieferanten eines Steuergerätes geschehen. Die Herstellung des Treiber-Moduls kann bei­ spielsweise durch den Fahrzeughersteller geschehen, der es dann Zulieferanten von busfähigen Steuergeräten zwecks Generation deren Software zur Verfügung stellt. Auf die­ se Weise kann leicht sichergestellt werden, daß die Her­ stellung und Austestung des Treiber-Moduls mittels dersel­ ben Prüfkriterien geschieht, die auch in Bus-Prüfsyste­ men in Produktion und Service des Fahrzeugherstellers eingesetzt werden. Auf diese Weise werden systematische Softwareunverträglichkeiten ausgeschlossen und es können lokale Fehler und deren Ursache(n) leicht erkannt werden.
Zwischen Treiber-Modul 10 und Applikationssoftware 11 kann noch ein separat zu erzeugendes Netzwerkmanagement-Modul 12 eingebunden werden. Analog dazu kann des weite­ ren noch ein spezielles Kommunikations-Modul 13 erzeugt und zwischen Treiber-Modul 10 und Applikationssoftware 11 eingebunden werden. Jedenfalls verfügt die Applikation 11 aber immer über einen freien Zugang 11′ zum Treiber­ modul 10 über besagte CAN-Treiberschnittstelle 18. Unter bestimmten Voraussetzungen kann es in der Regel aller­ dings vorteilhafter sein, Kommunikationsroutinen in die Applikationssoftware 11 von Anfang an einzubauen, wie dies z. B. der Veranschaulichung gemäß Fig. 6 zugrunde gelegt ist.
Ein besonderes Netzwerkmanagement-Modul 12 kann z. B. Auf­ gaben i.Z. mit der Bedienung weiterer Steuergeräte am Bus oder der Ermöglichung eines Eindraht-Notbetriebs erfüllen, wenn z. B. eine von zwei elektrischen Busadern Masse- oder Versorgungsspannungsschluß hat. Ein besonderes Kommunika­ kations-Modul 13 kann z. B. diejenigen Teile von Kommuni­ kationsroutinen zusammenfassen, die für mehrere Steuer­ geräte identisch sind. Beispielsweise kann es applika­ tionsspezifische Handler-Routinen, oder aber spezielle Kommununikationsfunktionen enthalten, etwa Kopierfunk­ tionen, wie z. B. die noch weiter unten erwähnte Pre- und Postcopy-Funktion in Verbindung mit Elementen zur Empfangsfilterung.
Es sind in der Art von Einhüllenden eine erste Schnitt­ stelle 17, nämlich die Instruktions- und Kommunika­ tionsoberfläche des CAN-Chip, eine zweite Schnittstel­ le, nämlich die erfindungsgemäß zu definierende CAN-Treiber-Schnittstelle 18 und des weiteren noch eine Management-Schnittstelle 19 und eine der Management-Schnittstelle 19 entsprechende und je nach Füllung des Kommunikations-Moduls 13 zu spezifizierende Schnitt­ stelle 19′ der Applikation 11 kenntlich gemacht.
Funktionselemente des verfahrensgemäß zu erzeugenden Treiber-Moduls werden aus Fig. 2 deutlich.
Das Treiber-Modul 10A umfaßt u. a. einen logischen Code 14. Dieser Code 14 übersetzt gewissermaßen den CAN-Chip-typen­ spezifischen Instruktionscode von der Ebene der besagten ersten Schnittstelle 17 in ein standardisiertes Instruk­ tionsformat auf der Ebene der besagten CAN-Treiber-Schnitt­ stellen 18, auf welcher die Applikationssoftware 11 zu­ greift. Der im ROM der Applikation abgelegte logische Code 14 erfüllt dabei eine Funktion vergleichbar der eines Adapters oder Interface auf die einfache, aber leistungsfähige Schnittstelle 18 mit eigener funktio­ naler Intelligenz, die einerseits die Applikation - und damit den Applikationsprogrammierer - von elementaren Kommunikationsaufgaben entlastet und andererseits die korrekte und netzweit einheitliche Programmierung des bzw. der CAN-Chips gewährleistet.
Weiter umfaßt das Treiber-Modul 10 ein Datenfeld 15, das entweder vollständig oder überwiegend im ROM der Steuergerätehardware deponiert wird. Es ist dies wenig­ stens eine Initialisierungsstruktur und eine Kommunika­ tionsstruktur, Initialisierungsobjekte I1 . . . 1y bzw. Kommunikationsobjekten K1 . . . Kx umfassend.
Darüber hinaus beansprucht das Treiber-Modul 10A außer­ dem noch einen (kleinen) RAM-Bereich, um dort in einem flüchtigen Datenfeld 16 z. B. Statusinformationen oder eine Warteschlange zu verwalten oder z. B. Funktions­ rückgabewerte zu führen.
Die Initialisierungsstruktur enthält Daten, mit denen die Register bzw. Speicherzellen des CAN-Chip in Ab­ hängigkeit von der aktuell ausgewählten Initialisie­ rungsvariante geladen werden.
Die Kommunikationsstruktur gliedert sich in Sende- und Empfangsstruktur, jeweils Sende- bzw. Empfangs-Kommunikationsobjekte umfassend. Die Sende- und Empfangsstruk­ turen enthalten Informationen über die zu sendenden bzw. zu empfangenden Daten sowie die erforderlichen Zeiger, welche die zu benutzenden Bereiche im RAM des Steuergerätes bzw. CAN-Register festlegen.
Fig. 2 veranschaulicht weiter, daß es für CAN-Chips 1A, 1B, 1C etc. jeweils ein entsprechendes Treiber-Modul 10A, 10B, 10C . . . gibt. Unterschiedlichen CAN-Chips 1A bis 1C, über End- und Empfangsstufen 3 gleichermaßen an den CAN-Bus 2 angeschaltet, sind also entsprechend unterschiedliche Treiber-Module 10A bis 10C zugeordnet. Entsprechend den unterschiedlichen Eigenschaften verschiedener CAN-Chips 10A . . . 10C variieren jeweils wenigstens der Code 14 und einzelnen Datenobjekte im Datenfeld 15 bei entsprechenden Treiber-Modulen.
Im Sinne von Fig. 3 kann "der" CAN-Chip 1 auch aus mehreren realen Bus-Protokollbausteinen 1.1, 1.2, 1.3, etc. bestehen, die insgesamt wie ein (einheitlicher) Chip zwischen Applikationssoftware 11 und Bus 2 wirken. Ohne Beschränkung der Allgemeinheit realisiert ein entspre­ chend aufgebautes Treiber-Modul 10′ auch hier die Treiber­ schnittstelle 18 und "verbirgt" dann eine entsprechende Mehrzahl von CAN-Chips gegenüber dem Programmierer der Applikationssoftware.
Allen Treiber-Modulen 10A, 10B, 10C gleich ist jedoch eine einheitliche Beschaffenheit der CAN-Treiberschnitt­ stelle 18, so daß der applikationsseitige Funktionsauf­ ruf des Treiber-Moduls stets mit derselben Datenobjekt-Referenz erfolgen kann, d. h. unabhängig vom benutzten CAN-Chip.
Bei der Herstellung des Moduls wird der logische Treiber-Code beispielsweise insgesamt so gebaut, daß er, in Ver­ bindung mit den vorerwähnten Daten, nach der Verknüpfung mit der Applikationssoftware folgende Funktionen leistet:
a. Initialisierung
Vor dem Beginn einer Kommunikation werden die CAN-Kommu­ nikationspfade und der CAN-Controller initialisiert. Dies geschieht durch einfachen Aufruf der Funktion
Init{Zeiger auf Initialisierungsobjekt}.
Hierfür werden in dem als Argument des Initialisierungsaufrufs bezogenen Initialisierungsobjekt alle notwendigen Parameter für die CAN-protokollgemäße Chipinitialisierung abgelegt.
b. Aussenden von Daten
Für die Aussendung von Daten wird ein Sende-Kommunika­ tionsobjekt definiert, in dem unter anderem ein die be­ treffende CAN-Nachricht kennzeichnender Identifier und ein Zeiger auf die RAM-Adresse der auszusendenden Appli­ kationsvariable abgelegt wird. Die Aussendung von Daten wird bewirkt durch einfachen Aufruf der Funktion
Transmit{Zeiger auf Sende-Kommunikationsobjekt}.
Dieser Aufruf bewirkt, daß mittels des Kommunikations­ objekts die relevante Applikationsvariable in den CAN-Chip oder in den Treiber (nämlich z. B. in eine Warte­ schlange, s. u.) kopiert wird. Anschließend erfolgt deren Aussendung auf den Bus vorzugsweise asynchron, was bedeutet, daß die Applikationssoftware nicht auf eine Quittung des erfolgreichen Aussendevorganges wartet. Sie wird jedoch zu einem frühestmöglichen Zeitpunkt darüber informiert. Auch wird die erfolgreiche Übernahme der Applikationsvariable in die Verantwortung des Treiber-Moduls der Applikation angezeigt.
c. Sendeabbruch
Zwecks Abbruch bzw. Nichtausführung eines bereits erfolg­ ten Aufrufs zum Versand einer Nachricht ist die besondere Funktion
Cancel{Zeiger auf Sende-Kommunikationsobjekt}
vorgesehen. Ihr Aufruf bewirkt die Stornierung eines vorausgegangenen Transmit-Aufrufs durch Löschung des Sendeauftrages im Treiber oder - soweit bereits in das Sende-Bufferregister des CAN-Chip eingeschrieben und noch nicht versandt - eben dort.
d. Empfand
Im Gegensatz zu komfortablen CAN-Chips mit eigenem RAM (etwa FULLCAN-Chips) sind einfachere CAN-Chips (etwa BASICAN-Chips) nicht in der Lage, alle Nachrichten, die überhaupt empfangen werden können oder sollen, vollständig selbst zu filtern.
Diese einfacheren CAN-Chips verfügen nur über ein Re­ gister, das zwecks Ladung als "Empfangsfenster" geöff­ net wird, sofern der Identifier einer CAN-Botschaft in eine vorbestimmte Maske fällt. Die Selektion bzw. Akzep­ tanzprüfung aus einer Vielzahl von aus diesem Register holbaren Daten muß also außerhalb eines solchen einfa­ cheren CAN-Chips geschehen.
Vorzugsweise wird das Treiber-Modul so gebaut, daß es auch diese Funktion leistet, indem es den Empfangsbetrieb interruptgesteuert abwickelt. Dazu wird für jeden zu em­ pfangenden Nachrichtentyp ein Empfangs-Kommunikationsob­ jekt definiert. In diesem-wird u. a. der die betreffende CAN-Botschaft kennzeichnender Identifier und ein Zeiger auf die Zielvariable im RAM der Applikation abgelegt. Durch den einfachen Aufruf
Receive{Zeiger auf Empfangs-Kommunikationsobjekt}
werden die Empfangsdaten aus dem Empfangs-Bufferregi­ ster des CAN-Chip in einen für relevante Empfangsdaten vorgesehenen Speicherplatz im RAM der Applikation (Zielvariable) kopiert. Das Treiber-Modul deselektiert insoweit also alle unerwünschten Empfangs-Kommunika­ tionsobjekte.
Auf diese Weise wird - unabhängig vom realen CAN-Protokollchip - z. B. die Funktion eines komfortableren CAC-Chip, etwa eines FULLCAN-Chip, substituiert, welcher aufgrund Ausrüstung mit einem eigenen RAM eine Akzep­ tanzliste für alle überhaupt zu empfangenden und in vorbestimmte RAM-Bereiche des Applikationskontrollers zu schreibenden Nachrichten halten und verwalten kann.
Es wird ersichtlich, daß relevante Identifier nur dem Hersteller des Treiber-Moduls bekannt sein müssen und in der ROM-Liste 15 des Treiber-Moduls verzeichnet sind, die Applikation bzw. der die Applikationssoftware herstellende Programmierer dieselben jedoch nicht zu kennen braucht, weil Empfangsdaten, die weiterverarbeitet werden sollen, immer nur aus vorbestimmten, festliegenden Speicherzellen des Applikations-RAMs abgeholt zu werden brauchen.
e. Precopy und Postcopy
Um einer Applikation bezüglich zu empfangender Daten die Möglichkeit einer Selektion zu bieten (z. B. für Filte­ rungs- und/oder Überprüfungsfunktionen), werden in dem verfahrensgemäß zu erzeugenden Treiber-Modul wenigstens zwei weitere Subroutinen "Precopy" und "Postcopy" einge­ baut, welche es der Applikation erlauben, unmittelbar vor dem Empfang von Daten bzw. unmittelbar nach dem Auslesen empfangener Daten aus dem Empfangs-Bufferregister 21 des CAN-Chip 1 in die Zielvariable (Zielspeicherplatz im RAM der Applikation) Einfluß auf die empfangenen Daten zu neh­ men. Wie diese beiden Funktionen wirken ist in Fig. 5 veranschaulicht.
Mit 21 ist das Empfangs-Bufferregister des am Bus 2 liegenden CAN-Chip 1 bezeichnet, in welches die Empfangs­ botschaften vom Bus geladen werden. Mit 15 ist ein klei­ ner Ausschnitt aus dem ROM und mit 16 ein kleiner Aus­ schnitt aus dem RAM der Applikation bezeichnet. Bei­ spielsweise sind im ROM 15 Speicherbereiche 23.1, 23.2, 23.3, etc. vorgesehen, in welche Identifier, hier bei­ spielsweise x, y, und 49, für Empfangsnachrichten ein­ geschrieben sind. Jedem Identifier sind hier beispiels­ weise acht weitere Speicherplätze 23.1.1 bis 23.1.8, 23.2.1 bis 23.2.8, 23.3.1 bis 23.3.8, etc. zugeordnet, in welche zum jeweiligen Identifier gehörende Parameter abgelegt sind.
Im RAM 16 sind drei verschiedene Speicherplätze 25, 27 und 30 hervorgehoben, in welche eine Empfangsbotschaft ablegbar ist. Dabei ist angenommen, daß der Speicher­ platz 25 zur Ablage der Empfangsbotschaft zwecks deren unmittelbarer Weiterverarbeitung, der Speicherplatz 27 zur Ablage der Empfangsbotschaft zwecks einer wie immer gearteten Bearbeitung vor Weiterverarbeitung, und der Speicherplatz 30 zur Ablage einer Kopie der Empfangsbot­ schaft nach deren Empfangseinschrieb in das RAM 16 vor­ gesehen ist.
Die Funktion ist folgende. Botschaften werden über den Bus 2 im Broadcast-Verfahren versandt, erreichen insoweit also grundsätzlich alle CAN-Chips der einzelnen am Bus liegenden Steuergeräte. Soweit es sich hierbei nicht um CAN-Chips mit 100%iger Akzeptanz-Filterung, also bei­ spielsweise FULLCAN-Chips, handelt, erfolgt wenigstens die Filterung bzw. Diskrimination der Empfangsbotschaf­ ten vermittels des Treiber-Moduls außerhalb des CAN-Chip 1.
Sobald eine beliebige Botschaft im Empfangs-Bufferregister 21 eingeladen ist, greift die Applikation per Interrupt- Service-Routine 22.0 auf das ROM 15 zu und überprüft, beispielsweise durch sukzessives Abfragen 22.1, 22.2 alle dort in Speicherplätzen 23.1, 23.2, 23.3, etc. abgelegten Identifier auf Übereinstimmung mit dem Iden­ tifier der Empfangsbotschaft ab.
U. U. wird keine Übereinstimmung festgestellt, was bedeu­ tet, daß die Empfangsbotschaft nicht ausgewertet wird, weil sie z. B. gar nicht für das betrachtete Steuergerät aus einer bestimmten Kategorie von Steuergeräten, etwa solchen mit einem BASICAN-Chip, bestimmt ist.
Wird jedoch der in das Empfangs-Bufferregister aktuell eingeladene Empfangs-Identifier, hier angenommen "49", beispielsweise im Speicherplatz 23.3 vorgefunden, fragt die Interrupt-Service Routine alle nachfolgenden Spei­ cherplätze 23.3.1 bis 23.3.8. sukzessive 22.3 nach darin enthaltenen Adress-Codierungen für den RAM-Einschrieb be­ sagter Empfangsbotschaft ab. Beispielsweise ist in den Speicherplatz 23.3.1 eine "0" eingeschrieben. Dies be­ wirkt den Einschrieb 24 der Botschaft im Empfangs-Buf­ ferregister 21 in den Speicherplatz 25 im RAM 16 der Applikation, dessen Adresse z. B. im ROM-Platz 23.3.2 abgelegt ist. Ist in den Speicherplatz 23.3.1 hingegen ein von "0" abweichender Wert - hier beispielsweise "10110" - eingeschrieben, so wird dieser Wert als Startadresse einer zwecks Bewertung, Filterung, etc. der Empfangsdaten vorgesehenen Anwenderfunktion inter­ pretiert, die mit dieser Adresse im Speicherplatz 27 des RAMs 16 der Applikation abgelegt ist und der die Botschaft im Empfangs-Bufferregister 21 unterworfen wird (Precopy), bevor sie weiterverarbeitet (und zu diesem Zwecke dann z. B. in den Speicherplatz 25 abge­ legt) wird. Hierzu könnte die Empfangs-botschaft z. B. vorübergehend in einen Zwischenspeicherplatz 28 im RAM 16 geladen werden. Entsprechende Adressen der RAM-Spei­ cherplätze 27 und 28 können im ROM-Speicherplatz 23.3.1 mitabgelegt sein.
Ein bestimmter Wert im letzten Speicherplatz 23.3.8 bewirkt hingegen, daß die zwecks Empfangsverarbeitung bereits ins RAM 16 eingeschriebene Empfangsbotschaft in einen besonderen Speicherplatz 30 des RAMs 16 ko­ piert 29 wird (Postcopy), was z. B. für ein Steuergerät wichtig sein kann, das die zeitliche Änderung einer Meßgröße auswertet und insoweit auf die Festhaltung jeweils wenigstens eines letzten bzw. zurückliegenden Meßwertes angewiesen ist.
Es können so im Zuge des Datenempfangs gezielt kurze, ap­ plikationsspezifische Operationen bezüglich empfangener Daten ausgeführt werden, wie z. B. die Demultiplexierung eines CAN-Datenpakets in einzelne Variable, die Selek­ tion bestimmter Bytes einer Nachricht, Umlenkung empfan­ gener, aber fehlerhafter Daten, zusätzliche bzw. ver­ schärfte Empfangsfilterung, Interpretation oder Klassi­ fikation oder Entschlüsselung von Daten vor deren Ab­ speicherung, etc.
Ersichtlichermaßen erschließen diese zwei Routinen eine sehr differenzierte Verarbeitbarkeit von Empfangsbotschaf­ ten. Sie werden durch den einfachen Aufruf
Precopy{Zeiger auf Empfangs-Kommunikationsobjekt}
oder
Postcopy{Zeiger auf Empfangs-Kommunikationsobjekt} aktiviert.
f. Remote Request Service
Das Treiber-Modul kann auch die Remote-Eigenschaften des CAN-Protokolls unterstützen. Die entsprechende Remote Reguest Service Funktion emuliert bei Anwendungen mit CAN-Chips, die keine automatische Beantwortung eines Remote Reguest unterstützen, die immanente Remote Reguest Funk­ tion von CAN-Chips, die ohne Einschränkung das gesamte CANProtokoll unterstützen und autonom abwickeln können, etwa FULLCAN-Chips. Dabei kann die Transmit-Funktion ver­ mittels eines im CAN-Protokoll designierten Steuer-Flags Remote-Botschaften auf den Bus aussenden. Empfangene Remo­ te-Frames werden entweder durch den FULLCAN-Chip oder durch das Treiber-Modul bearbeitet und beantwortet. Die Applikationssoftware 11 bzw. die Applikation wird hiervon über eine entsprechende Statusinformation unterrichtet, welche in dem schon erwähnten Datenfeld 16 abgelegt wird.
Für die Bearbeitung von schnell aufeinanderfolgenden Sende­ anforderungen und zur Realisierung einer Multitaskingfähig­ keit des Treiber-Moduls ist es vorteilhaft, in diesem ge­ mäß Fig. 4 eine Sende-Warteschlange 20 zu implementieren. Deren Verwaltung und Abarbeitung geschieht vorzugsweise asynchron und vom CAN-Chip aus interruptgesteuert. Der Pro­ grammierer der Applikationssoftware ist dann auch bezüg­ lich Versandabfolgen ungebunden vom CAN-Chip und braucht ihn deshalb nicht zu kennen.
Neben Anforderungen seitens der Applikation können in eine solche Warteschlange auch Sendeanforderungen eines besonderen Netzwerkmanagement-Moduls 12 geladen werden, welches mehr oder weniger fest in die Applikationssoft­ ware 11 eingebunden ist. Die Applikationssoftware wird jedenfalls durch kommunikationsobjektbezogene Statusin­ formation, die in die Statusdatei in das RAM 16 der Applikation geschrieben wird, über den jeweiligen Zustand des Sendeauftrages aktuell informiert.
Die Sendewarteschlange bewirkt eine sehr vorteilhafte zeit­ liche Entkopplung zwischen der Applikationssoftware, den CAN-Busverhältnissen und einzelnen Tasks 11.1, 11.2, 11.3, etc. der Applikationssoftware untereinander.
Da eine solche Warteschlange bezüglich eines aktuellen Sendeaufrufs seitens der Applikationssoftware wegen ihrer busbelegungsabhängig asynchronen Abarbeitung eine gewisse mittlere Mindestdurchsatzverzögerung für Sendeanforderungen involviert, ist für besonders dringende Botschaften eine Erweiterung der Transmit-Funktion vorzusehen, nämlich eine:
g. Bevorzugte Behandlung von auszusendenden Daten
Ein bevorzugter Sofortversand eines Kommunikationsobjekts, welches in die Kommunikationswarteschlange geladen wurde, ist durch den einfachen Aufruf
TransmitFast{zeiger auf Sende-Kommunikationsobjekt} möglich. Dieser Treiberaufruf bewirkt, daß das bezogene Kommunikationsobjekt bei bereits wartenden Sendeaufträgen in den untersten Warteplatz in der Warteschlange geschrieben und wartende Aufträge somit um einen Platz höher geschoben werden, von wo aus das Kommunikationsobjekt somit mit dem nächsten Interrupt sogleich in das Sende-Bufferregister des CAN-Chip transferiert wird.
Die bereits erwähnte Sendeabbruchsfunktion
Cancel{Zeiger auf Sende-Kommunikationsobjekt}
bewirkt i.Z. mit der Sendewarteschlange die Löschung eines in der Warteschlange oder bereits im Chip befindlichen Sendeaufrufs mit der Wirkung, daß alle nach diesem Aufruf in die Warteschlange eingeschriebenen Aufträge in der Priorität um einen Platz nach oben (bzw. nach unten in der in Fig. 4 gewählten Symboldarstellung der Warte­ schlange als FIFO-Register) rücken, von wo aus sie dann um einen Interrupt-Schritt früher abgearbeitet werden.
Diese Funktion erlaubt also z. B., eine bereits für den Versand in die Warteschlange geladene Nachricht, die z. B. wegen hoher Busbelastung aber noch nicht versandt werden konnte und deshalb schon unaktuell geworden ist und durch eine aktuellere ersetzt werden sollte, unwirksam zu machen; mittels der TransmitFast-Funktion kann dann die aktuell verfügbare Nachricht bevorzugt versandt werden (Priority-Boost).
Im Treiber-Modul können noch Standby-Funktionen realisiert werden, so z. B.:
h. Power Down
Mittels des Aufrufs
PowerDown{ }
kann der CAN-Chip generell bzw. in Abhängigkeit von einem Argument in den stromsparenden Standby-Modus gebracht wer­ den.
i. Wake Up
Die Funktion
WakeUp{ }
wird vom Programmierer der Applikationssoftware selbst geschrieben und vom Treiber-Modul nach einem entspre­ chenden Wake-Up-Interrupt des CAN-Chip aufgerufen.
Es ist insoweit ersichtlich, daß das erfindungsgemäße Verfahren der Programmcodeerzeugung zur Programmierung des ROMs eines busfähigen, sich auf wenigstens einen Mikrorechner stützenden Kfz-Steuergerätes zum einen zu einer erheblichen Straffung des Applikationsprogrammes und - sofern jeweils alle Steuergeräte am Bus nur die zentral ausgetesteten Funktionen entsprechender Treiber-Module nutzen - zu einer Effektivierung der Kommunika­ tion im Netz führt.
Fig. 6 veranschaulicht noch, wie eine Vielzahl von ver­ fahrensgemäß programmierten Steuergeräten 4A, 4B, 4C, etc., die mit gänzlich verschiedenen CAN-Chips 1A, 1B, 1C, etc. ausgerüstet sein können, über den Bus 2 miteinander gekop­ pelt werden; es ist hierbei der Sonderfall veranschaulicht, bei dem ein besonderes Kommunikations-Modul 13 entfällt, indem die entsprechenden Routinen jeweils in der geräte­ spezifischen Applikationssoftware 11A, 11B, 11C, etc. integriert sind.
Dabei stellen entsprechende Treiber-Module 10A, 10B, 10C, etc. teils direkt, teils über Teile 12A, 12B, 12C, etc. einer übergeordneten Netzwerkmanagement-Software die Ver­ bindung unter den jeweiligen Applikationsprogrammen 11A, 11B, 11C, etc. in den verschiedenen Steuergeräten 4A, 4B, 4C, etc. her.
Es ist weiter ersichtlich, daß die schraffiert angeleg­ ten Teile ein virtuell einheitliches Informationssystem, d. h. eine virtuelle Funktionseinheit, bilden, welche/s aufgrund der in allen Steuergeräten verteilt unterge­ brachten Netzwerkmanagement-Software sowohl in Rich­ tung der jeweiligen Applikationssoftware als auch in Richtung des Busses 2 identische Funktionalität für alle Steuergeräte 4A, 4B, 4C, etc. bietet, sofern diese nur mit CAN-Chips gleicher Protokollnutzungsbreite ausge­ stattet sind.
Ferner ist ersichtlich, daß bei Verwendung des erfin­ dungsgemäßen Verfahrens zur Programmierung busfähiger elektronischer Steuergeräte in einem Kraftfahrzeug so­ wohl für die Herstellung als auch das Austesten unter­ schiedlichster Applikationssoftware 11A, 11B, 11C, etc. für die einzelnen Steuergeräte 4A, 4B, 4C, etc. - unab­ hängig von dem bzw. den gerätespezifisch eingesetzten CAN-Chip/s - identische Bedingungen vorgebbar und nutz­ bar sind, woraus erhebliche Zeit- und Kosteneinsparun­ gen und Sicherheitsgewinne resultieren.
Schließlich ist ersichtlich, daß sich im Zuge der Anwen­ dung des erfindungsgemäß fortgebildeten Verfahrens die Realisierung des in Fig. 6 veranschaulichten Informa­ tionsübertragungssystems im Sinne einer virtuellen Ein­ heit praktisch von selbst ergibt. Das Informationsüber­ tragungssystem wird von den schraffierten Teilen gebil­ det. Hierfür werden also Netzwerkmanagement-Module 12A, 12B, 12C, etc. vorgesehen, die einerseits mit den je­ weiligen Treiber-Modulen 10A, 10B, 10C, etc. und ande­ rerseits über ebenfalls einheitliche Kommunikations-Schnittstellen 19A, 19B, 19C etc. mit der jeweiligen Applikationssoftware 11A, 11B, 11C, etc. kommunika­ tionsfähig sind.
In der Praxis ergibt sich diese Wirkstruktur durch ein­ faches Beilinken von in analoger Weise zentral ausge­ testeten Netzwerkmanagement-Modulen 12A, 12B, oder 12C zusammen mit dem jeweils CAN-Chip-spezifischen Treiber-Modul 10A, 10B oder 10C zur jeweiligen Applikationssoft­ ware 11A, 11B, 11C in einer Netzwerkfehler somit weit­ gehend ausschließenden Weise.

Claims (6)

1. Verfahren zur Programmierung eines busfähigen elek­ tronischen Kfz-Steuergerätes, welches zur Realisierung seiner Steuerfunktion mit wenigstens einem Mikrorechner (und) mit ROM und RAM zur Aufnahme bzw. Abwicklung der für die Steuerfunktion erforderlichen Applikationssoft­ ware und des weiteren mit wenigstens einem Bus-Protokoll­ chip ausgerüstet ist, und wobei die Programmierung des ROMs in einer Weise geschieht, daß besagte Applikations­ software über den wenigstens einen Bus-Protokollchip und insoweit - im Sinne einer (jeweils) ersten Schnitt­ stelle - über dessen/deren spezifische Instruktions- und Kommunikationsoberfläche/n mit dem Bus kommuniziert, dadurch gekennzeichnet,
  • - daß eine zweite, von dem wenigstens einen Bus-Pro­ tokollchip (1; 1.1, 1.2, 1.3) unabhängige Schnittstelle (18) im Sinne einer weiteren, universellen Instruktions- und Kommunikationsoberfläche definiert wird;
  • - daß zwecks Kopplung besagter erster und zweiter Schnittstellen (17 und 18) unabhängig von der Applika­ tionssoftware (11) ein auf den wenigstens relevanten Bus-Protokollchip (1; 1.1, 1.2, 1.3; 1A, 1B, 1C) zu­ geschnittenes Treiber-Modul (10; 10′: 10A, 10B, 10C) mit den Eigenschaften eines Adapters erzeugt wird;
  • - daß bezüglich der Buskommunikation die steuergeräte­ spezifische Applikationssoftware (11) ausschließlich auf diese zweite universelle Schnittstelle (18) abgestimmt und ausgerichtet und insoweit unabhängig von dem wenig­ stens einen Bus-Protokollchip erzeugt wird;
  • - daß die vom Bus-Protokollchip (1; 1.1, 1.2, 1.3; 1A, 1B, 1C) unabhängige Applikationssoftware (11) und das applikationsunabhängige Treiber-Modul (10; 10A, 10B, 10C) mittels eines Linkprozesses miteinander verknüpft werden, und
  • - daß der als Ergebnis des Linkprozesses erhaltene Programmcode in besagtem ROM resident abgelegt wird.
2. Verfahren gemäß Anspruch 1, dadurch gekennzeichnet,
  • - daß das Treiber-Modul (10; 10′; 16A, 10B, 10C) in der Weise hergestellt wird, daß es nach der Verknüpfung mit der Applikationssoftware (11) wenigstens folgende Funk­ tionen leistet:
  • - die Initialisierung der Bus-Kommunikationspfade und/oder des wenigstens einen Bus-Protokollchip (1; 1.1, 1.2, 1.3) vor dem Beginn einer Kommunikation;
  • - die Abholung von Sendedaten unter wenigstens einer RAM-Adresse, deren Ladung in ein Senderegister des wenig­ stens einen Bus-Protokollchip und die Veranlassung des Auslesens der Sendedaten auf den Bus;
  • - die Abholung von Empfangsdaten aus einem Empfangs­ register (21) des wenigstens einen Bus-Protokollchip (1; 1.1, 1.2, 1.3) und deren Ladung in wenigstens einen vor­ bestimmten Speicherplatz (25) im RAM des Mikrorechners.
3. Verfahren gemäß Anspruch 2, dadurch gekennzeichnet,
  • - daß das Treiber-Modul (10; 10′; 10A, 10B, 10C) in der Weise hergestellt wird, daß es nach der Verknüpfung mit der Applikationssoftware (11) wenigstens folgende weitere Funktionen leistet:
  • - den Aufbau und die Verwaltung einer Warteschlange (20) für Sende-Kommunikationsobjekte;
  • - den bevorzugten Versand von Sende-Kommunikationsobjek­ ten aus der Warteschlange (20) unter Zuweisung der jeweils obersten Priorität;
  • - die individuelle, selektive Unwirksammachung von Sende-Aufträgen, bevor deren Versand erfolgt ist.
4. Verfahren gemäß Anspruch 1, dadurch gekennzeichnet
  • - daß unabhängig von der Applikationssoftware (11) und unabhängig von dem wenigstens einen Bus-Protokollchip (1; 1.1, 1.2, 1.3) noch wenigstens ein weiteres Modul (12, 13), beispielsweise ein Netzwerkmanagement-Modul (NWM; 12), hergestellt wird, und
  • - daß das wenigstens eine weitere Modul (12, 13) mit der Applikationssoftware (11) und/oder dem Treiber-Modul (10; 10′; 10A, 10B, 10C) mittels eines Linkprozesses mit­ einander verknüpft werden, um den im ROM des Steuergerätes ablegbaren Programmcode zu erhalten.
5. Verfahren gemäß Anspruch 2, dadurch gekennzeichnet,
  • - daß das Treiber-Modul (10; 10′; 10A, 10B, 10C) in der Weise hergestellt wird, daß es nach der Verknüpfung mit der Applikationssoftware (11) wenigstens folgende weitere Funktion leistet:
  • - die Unterwerfung der Empfangsdaten aus einem Empfangs­ register (21) des wenigstens einen Bus-Protokollchip (1; 1.1, 1.2, 1.3) einer Bearbeitungsfunktion und die Ladung der so bearbeiteten Empfangsdaten in wenigstens einen vorbestimmten Speicherplatz im RAM (16) des Mikrorech­ ners des Kfz-Steuergerätes.
6. Verfahren gemäß Anspruch 2, dadurch gekennzeichnet,
  • - daß das Treiber-Modul (10; 10′; 10A, 10B, 10C) in der Weise hergestellt wird, daß es nach der Verknüpfung mit der Applikationssoftware (11) wenigstens folgende weitere Funktion leistet:
  • - die Versetzung des wenigstens einen Bus-Protokollchip in einen stromsparenden Standby-Modus.
DE4229931A 1992-09-08 1992-09-08 Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes Expired - Fee Related DE4229931C2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE4229931A DE4229931C2 (de) 1992-09-08 1992-09-08 Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes
GB9318239A GB2270782B (en) 1992-09-08 1993-09-02 Bus-compatible electronic controller
US08/117,838 US5444643A (en) 1992-09-08 1993-09-08 Method for programming a bus-compatible electronic motor vehicle controller

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE4229931A DE4229931C2 (de) 1992-09-08 1992-09-08 Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes

Publications (2)

Publication Number Publication Date
DE4229931A1 DE4229931A1 (de) 1994-03-10
DE4229931C2 true DE4229931C2 (de) 1997-01-23

Family

ID=6467448

Family Applications (1)

Application Number Title Priority Date Filing Date
DE4229931A Expired - Fee Related DE4229931C2 (de) 1992-09-08 1992-09-08 Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes

Country Status (3)

Country Link
US (1) US5444643A (de)
DE (1) DE4229931C2 (de)
GB (1) GB2270782B (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10006970A1 (de) * 2000-02-16 2001-09-20 Infineon Technologies Ag Netzwerk-Controller
DE10059948A1 (de) * 2000-12-02 2002-06-20 Conti Temic Microelectronic Schaltkreis für ein Zentralgerät zur Datenübertragung über ein Bussystem
DE10112950A1 (de) * 2001-03-17 2002-09-26 Infineon Technologies Ag Empfangseinrichtung zum Empfangen von Daten
DE102004062211A1 (de) * 2004-12-23 2006-07-13 Texas Instruments Deutschland Gmbh Modulschnittstellen-Handler für Controller Area Network-(CAN-)Kommunikationsmodul

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07501503A (ja) * 1991-11-26 1995-02-16 シーメンス アクチエンゲゼルシヤフト バスシステム
US5504777A (en) * 1992-10-09 1996-04-02 E-Systems, Inc. Communications system using open architecture bus lines
DE4401891A1 (de) * 1994-01-24 1995-07-27 Bayerische Motoren Werke Ag Verfahren zum Ändern der Arbeitsweise eines Steuergeräts von Kraftfahrzeugen
US5737711A (en) * 1994-11-09 1998-04-07 Fuji Jukogyo Kabuishiki Kaisha Diagnosis system for motor vehicle
JP2816313B2 (ja) * 1994-11-14 1998-10-27 富士重工業株式会社 故障診断装置
DE19527249C2 (de) * 1995-07-26 1999-11-11 Grafotec Gmbh Vorrichtung zum Reinigen von Arbeitsflächen einer Druckmaschine
JP2001527713A (ja) * 1997-03-27 2001-12-25 エラン・シャルテレメンテ・ゲーエムベーハー・ウント・コンパニー・カーゲー 安全性指向の制御システム、ならびにこのシステムを運営する方法
DE19714937A1 (de) * 1997-04-10 1998-10-15 Bayerische Motoren Werke Ag Datenbussystem für Kraftfahrzeuge
FR2766642B1 (fr) * 1997-07-22 1999-11-19 Sextant Avionique Procede et dispositif de reception de messages numeriques assurant un pretraitement de ces messages configurable dynamiquement
FR2766641B1 (fr) * 1997-07-22 1999-12-03 Sextant Avionique Procede et dispositif de reception de messages numeriques assurant un pretraitement de ces messages
US20100030423A1 (en) * 1999-06-17 2010-02-04 Paxgrid Telemetric Systems, Inc. Automotive telemetry protocol
US20020150050A1 (en) * 1999-06-17 2002-10-17 Nathanson Martin D. Automotive telemetry protocol
DE19748181B4 (de) * 1997-10-31 2011-06-01 Continental Teves Ag & Co. Ohg Verfahren zum Prüfen einer Funktion oder Einrichtung eines Fahrzeugs
US6177860B1 (en) * 1997-11-17 2001-01-23 International Business Machines Corporation Method and economical direct connected apparatus for deploying and tracking computers
US6778096B1 (en) * 1997-11-17 2004-08-17 International Business Machines Corporation Method and apparatus for deploying and tracking computers
DE19809726A1 (de) * 1998-03-06 1999-09-09 Sgs Thomson Microelectronics Interface für einen Datenknoten eines Datennetzes
DE19815715C2 (de) 1998-04-08 2003-09-25 Daimler Chrysler Ag Elektronisches, datenbusfähiges Fahrzeugsteuergerät
JP3687373B2 (ja) 1998-12-04 2005-08-24 株式会社日立製作所 高信頼分散システム
DE19849810C2 (de) * 1998-10-29 2003-08-14 Siemens Ag Anordnung zur Übertragung von Betriebsdaten und/oder Betriebsprogrammen
DE50011567D1 (de) 1999-03-22 2005-12-15 Continental Teves Ag & Co Ohg Schaltungsanordnung und verfahren zur konfiguration einer schnittstelle von einer steuerungs- oder regelungseinrichtung
DE19939911C2 (de) * 1999-08-23 2003-03-06 Bosch Gmbh Robert Verfahren zur Datenübertragung
US6715001B1 (en) * 1999-09-15 2004-03-30 Koninklijke Philips Electronics N.V. Can microcontroller that employs reconfigurable message buffers
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
US6434432B1 (en) * 1999-09-15 2002-08-13 Koninklijke Philips Electronics N. V. Method for writing back message ID information to a match ID register and a CAN microcontroller that implements this method
US6615302B1 (en) * 1999-09-15 2003-09-02 Koninklijke Philips Electronics N.V. Use of buffer-size mask in conjunction with address pointer to detect buffer-full and buffer-rollover conditions in a CAN device that employs reconfigurable message buffers
DE19952034A1 (de) 1999-10-28 2001-05-10 Infineon Technologies Ag Verfahren zum Initialisieren oder Konfigurieren einer elektrischen Schaltung
EP1118934A3 (de) * 1999-12-30 2006-08-23 Siemens Aktiengesellschaft Objekt-Echtzeitkommunikation in der Steuerungstechnik
DE10000337B4 (de) * 2000-01-07 2015-03-19 Volkswagen Ag Verwaltungsvorrichtung eines Fahrzeugs und Verfahren zur Parametrierung mindestens einer Steuereinheit der Verwaltungsvorrichtung
WO2002015517A2 (en) * 2000-08-16 2002-02-21 Microchip Technology Incorporated Remote configuration of network node via controller area network messages
GB0100535D0 (en) * 2001-01-09 2001-02-21 Lucas Industries Ltd Method of and apparatus for transmitting data in a distributed processor system
EP1223725B1 (de) * 2001-01-12 2005-06-29 Vector Informatik GmbH Verfahren und Vorrichtung zur Relevanzprüfung eines Kennzeichners
DE10211939A1 (de) * 2002-03-18 2003-10-02 Sick Ag Kopplungsvorrichtung zum Ankoppeln von Geräten an ein Bussystem
DE10230633A1 (de) * 2002-07-08 2004-01-29 Adam Opel Ag Verfahren zum Aktivieren wenigstens eines über einen Datenbus eines Kraftfahrzeuges ansteuerbaren Steuergerätes
DE10243783A1 (de) * 2002-09-20 2004-03-25 Sick Ag Elektronische Vorrichtung für ein Bussystem
DE10243782A1 (de) 2002-09-20 2004-03-25 Sick Ag Parametrier-/Diagnosesystem für Feldgeräte
DE10243781A1 (de) 2002-09-20 2004-03-25 Sick Ag Elektronische Vorrichtung für ein Bussystem
DE102007062114A1 (de) * 2007-12-21 2009-07-23 Opensynergy Gmbh Kraftfahrzeug-Steuervorrichtung
US20090186344A1 (en) * 2008-01-23 2009-07-23 Caliper Life Sciences, Inc. Devices and methods for detecting and quantitating nucleic acids using size separation of amplicons
US7861027B2 (en) * 2008-05-30 2010-12-28 Intel Corporation Providing a peripheral component interconnect (PCI)-compatible transaction level protocol for a system on a chip (SoC)
WO2018002904A1 (en) 2016-07-01 2018-01-04 Cnathanson Martin D System for authenticating and authorizing access to and accounting for wireless access vehicular environment consumption by client devices
DE102022115689A1 (de) 2022-06-23 2023-12-28 Elmos Semiconductor Se Adaptermodul zum Informationsaustausch zwischen zumindest zwei Teilnehmern eines Kommunikationsnetzwerkes und zugehöriges Verfahren, Teilnehmereinheiten eines Kommunikationsnetzwerkes mit einem solchen Adaptermodul, Bereitstellungseinheit, Kommunikationsnetzwerk mit einem solchen Adaptermodul sowie Signalfolge

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4631666A (en) * 1982-10-25 1986-12-23 Burroughs Corporation Data transfer network for variable protocol management
DE3410082A1 (de) * 1984-03-20 1985-09-26 Robert Bosch Gmbh, 7000 Stuttgart Steuergeraet fuer kraftfahrzeuge
US4787028A (en) * 1985-09-03 1988-11-22 Ncr Corporation Multicommunication protocol controller
US5060140A (en) * 1986-01-16 1991-10-22 Jupiter Technology Inc. Universal programmable data communication connection system
JPS62272341A (ja) * 1986-05-21 1987-11-26 Fanuc Ltd マルチプロセツサシステムにおけるブ−トロ−デイング方式
US4739324A (en) * 1986-05-22 1988-04-19 Chrysler Motors Corporation Method for serial peripheral interface (SPI) in a serial data bus
US4739323A (en) * 1986-05-22 1988-04-19 Chrysler Motors Corporation Serial data bus for serial communication interface (SCI), serial peripheral interface (SPI) and buffered SPI modes of operation
US4742349A (en) * 1986-05-22 1988-05-03 Chrysler Motors Corporation Method for buffered serial peripheral interface (SPI) in a serial data bus
US4803623A (en) * 1986-10-31 1989-02-07 Honeywell Bull Inc. Universal peripheral controller self-configuring bootloadable ramware
US4858101A (en) * 1987-08-26 1989-08-15 Allen-Bradley Company, Inc. Programmable controller with parallel processors
US5175845A (en) * 1988-12-09 1992-12-29 Dallas Semiconductor Corp. Integrated circuit with watchdog timer and sleep control logic which places IC and watchdog timer into sleep mode
US5283900A (en) * 1989-10-02 1994-02-01 Spectron Microsystems, Inc. Real-time operating system and virtual digital signal processor for the control of a digital signal processor
US5165022A (en) * 1989-10-23 1992-11-17 International Business Machines Corporation Channel and control unit having a first I/O program protocol for communication with a main processor and a second universal I/O program protocol for communication with a plurality of I/O adapters
CA2034878C (en) * 1990-03-08 2002-04-02 Craig S. Hyatt Programmable controller communication module
DE69117498D1 (de) * 1991-05-31 1996-04-04 Ibm Kommunikationssteuergerät mit Leitungsanpassern die mit Anwenderprogramm ladbar sind
US5323385A (en) * 1993-01-27 1994-06-21 Thermo King Corporation Serial bus communication method in a refrigeration system

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10006970A1 (de) * 2000-02-16 2001-09-20 Infineon Technologies Ag Netzwerk-Controller
DE10006970B4 (de) * 2000-02-16 2006-04-06 Infineon Technologies Ag Netzwerk-Controller
DE10059948A1 (de) * 2000-12-02 2002-06-20 Conti Temic Microelectronic Schaltkreis für ein Zentralgerät zur Datenübertragung über ein Bussystem
DE10112950A1 (de) * 2001-03-17 2002-09-26 Infineon Technologies Ag Empfangseinrichtung zum Empfangen von Daten
US6904472B2 (en) 2001-03-17 2005-06-07 Infineon Technologies Ag Receiving device for receiving data
DE102004062211A1 (de) * 2004-12-23 2006-07-13 Texas Instruments Deutschland Gmbh Modulschnittstellen-Handler für Controller Area Network-(CAN-)Kommunikationsmodul
DE102004062211B4 (de) * 2004-12-23 2007-01-25 Texas Instruments Deutschland Gmbh CAN-Kommunikationsmodul

Also Published As

Publication number Publication date
US5444643A (en) 1995-08-22
GB2270782A (en) 1994-03-23
DE4229931A1 (de) 1994-03-10
GB2270782B (en) 1996-05-08
GB9318239D0 (en) 1993-10-20

Similar Documents

Publication Publication Date Title
DE4229931C2 (de) Verfahren zur Programmierung eines busfähigen elektronischen Kfz-Steuergerätes
EP0730803B1 (de) Vorrichtung zum austauschen von daten
DE69921446T2 (de) Übertragungsstruktur für industrielle prozesssteuerungssysteme
DE69819610T2 (de) Verteiltes Verarbeitungstypensteuerungssystem
EP0555532B1 (de) Verfahren zur Initialisierung eines elektronischen Regelsystems insbesondere in einem Kraftfahrzeug
EP0577919A1 (de) Zugriffssteuerung für gekoppelte maskenprogrammierte Mikrocontroller
EP1908221A1 (de) Verfahren und anordnung zur automatischen konfiguration eines master-slave-feldbussystems
EP2044736A1 (de) Verfahren zum betreiben eines lin-busses
EP1095320B1 (de) Steuerungssystem mit einem personalcomputer
WO1999014643A1 (de) Vorrichtung und verfahren zur steuerung von maschinen, insbesondere webmaschinen
EP1840684A1 (de) Automatisierungsgerät sowie-system, enthält Automatisierungskomponenten die per lösbaren Funkmodulen drahtlos kommunizieren können
EP0799441B1 (de) Verfahren zur steuerung von technischen vorgängen
EP1417469A2 (de) Kommunikationsverfahren und kommunikationsmodul
EP0360135B1 (de) Verfahren zur Interruptverarbeitung in einer Datentverarbeitungsanlage
EP1227379B1 (de) Verfahren und Vorrichtung zur Steuerung einer Maschine in einem Fertigungssystem
DE69836937T2 (de) Verfahren zur Störungsbeseitigung und Kommunikationssystem
DE102018123563A1 (de) Verfahren zur Zwischenkernkommunikation in einem Mehrkernprozessor
DE60004161T2 (de) Schnittstelle zu einem Netzwerkverwaltungssystem eines Kommunikationsnetzes
EP2455831A1 (de) Engineering einer Datenkommunikation
EP1642422B1 (de) Anpassung eines fahrzeugnetzwerks an geänderte anforderungen
EP0740806B1 (de) Verfahren zur steuerung eines technischen prozesses nach dem prinzip des endlichen automaten
DE3853129T2 (de) Direkte Kontrolleinrichtung für Multiprozessornetzwerk.
DE4115498C2 (de) Verfahren zur Übertragung von Daten in einem Netzwerk
EP1046972B1 (de) Softwaremässige Repräsentation von Geräten
DE4414929C1 (de) Kommunikationsanlage

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
D2 Grant after examination
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: DAIMLER-BENZ AKTIENGESELLSCHAFT, 70567 STUTTGART,

8327 Change in the person/name/address of the patent owner

Owner name: DAIMLERCHRYSLER AG, 70567 STUTTGART, DE

8327 Change in the person/name/address of the patent owner

Owner name: DAIMLERCHRYSLER AG, 70327 STUTTGART, DE

8339 Ceased/non-payment of the annual fee