DE10000997A1 - Elektronisches Steuersystem - Google Patents

Abstract

Es wird ein elektronisches Steuersystem zur Steuerung der Funktion eines Verarbeitungssystems zur Verfügung gestellt, insbesondere für die Verwendung in einem Auto, wobei das Steuersystem eine Vielzahl logischer Steuerelemente enthält, von denen jedes so beschaffen ist, dass es spezielle Aufgaben ausführt, wobei jedes der Steuerelemente mit jedem anderen Steuerelement kommunizieren kann.

Description

Bereich der Erfindung

Die vorliegende Erfindung bezieht sich auf ein elektronisches Steuersystem zur Steuerung der Funktion eines Verarbeitungssystems. Im Besonderen bezieht sich die Erfindung auf solch ein Steuersystem, das in einem Kraftfahrzeug genutzt werden kann.

Hintergrund der Erfindung

Das Erscheinen elektronisch gesteuerter Fahrzeuge, die durch sogenannte "elektronische Steuereinheiten" (electronic control units (ECU)) gesteuert werden, die einen Mikrocomputer enthalten, hat in den letzten Jahren drastisch zugenommen. Zusätzlich zur Steuerung der Drehzahl des Verbrennungsmotors, zur Steuerung des Gangwechsels in einem Getriebe und zur Steuerung der Kupplung haben diese Fahrzeuge auch verschiedene Zusatzvorrichtungen, die von einer ECU gesteuert werden. Auf der Grundlage von Signalen von verschiedenen Sensoren, die an einer Vielzahl von Stellgliedern bereitgestellt werden, die die zu steuernden Einheiten betätigen, berechnet die ECU Steuervariable für die verschiedenen Stellglieder, die gesteuert werden, und gibt dann die entsprechenden Signale an diese Stellglieder aus, um die Arbeitsweise jeder Einheit zu steuern.

Steuersysteme dieses Typs werden zum Beispiel in Kraftfahrzeugen zum Ausführen von Steuerungsfunktionen benutzt, die typischerweise in Fahrzeugen vorkommen. In herkömmlichen Systemen sind die Steuerungseinheiten speziell für eine oder mehrere Anwendungsfunktionen konstruiert. Die Realisierung einer neuen Fahrzeugfunktion erfordert die Entwicklung einer neuen geeigneten Steuerungseinheit. Zusammen mit einer neuen Sensor- und Stellglied- Konfiguration muss diese Steuerungseinheit dann in das Fahrzeug eingebaut werden.

Obgleich die Steuerungseinheiten in modernen Konfigurationen vernetzt sind, zum Beispiel über einen CAN-Bus, ist keine definierte Schnittstelle als Zugang zu einzelnen Funktionsbestandteilen vorhanden. Infolgedessen erscheint der Steuerungseinheit die gesamte jeweilige Anwendungsfunktion. Zur Realisierung neuer, sogenannter rekombinierter Funktionen, die aus vorhandenen Funktionen zusammengesetzt sind, muss die besondere Schnittstelle deshalb manuell mit bestehenden Funktionen verbunden werden, was zu hohen Kosten führt. Dies wird zum Beispiel durch Definieren oder Ändern entsprechender CAN-Nachrichten (messages) erreicht. Weiterhin unvorteilhaft ist, dass manchmal das Ändern aller anderen Steuerungseinheiten erforderlich ist, um eine einzige neue Funktion hinzuzufügen.

Mit dem Trend zu immer mehr elektronisch ausgeführten Funktionen in Kraftfahrzeugen und ihrer zunehmenden gegenseitigen Verknüpfung geht ein deutlicher Anstieg in der Komplexität und den damit verbundenen Schwierigkeiten in der Entwicklung und Beherrschung des gesamten elektronischen Systems des Fahrzeuges einher. Zusätzlich führt das zu einer steigenden Nachfrage nach Rechnerleistung und Speicherplatz. Mehr noch wird verlangt, dass, infolge der steigenden Komplexität - und weil es gleichzeitig immer mehr Serien sowie kürzere Entwicklungszeiten für diese Serien gibt - die Bestandteile immer mehr serienübergreifendend verwendbar sein müssen.

Beschreibung der verwandten Technik

Elektronische Steuerungseinheiten (ECU), die eingebettete Steuerungen und Verarbeitungssysteme nutzen, zeigen typischerweise eine verteilte Hardware-Gestaltung (HW- Layout). Das bedeutet, die Systemtopologie der Mehrheit der eingebetteten ECUs - und die sich ergebende funktionelle HW- Gestaltung sowie die erforderlichen Bestandteile - werden "anwendungsspezifisch" definiert. Das heißt, dass Standardverarbeitungs-Systemlösungen, wie sie in der Mehrzahl der eingebetteten Systeme genutzt werden, eine typische Systemarchitektur mit einer Topologie zeigen, die eine zentrale Verarbeitungseinheit (CPU) aufweist, die mit den verschiedenen Untersystemen verbunden ist, die durch die Zielanwendung des Gesamtsystems definiert sind. Die einzelnen Untersysteme sind so gestaltet, dass sie "spezialisierte" Anwendungssegmente unterstützen, die alle zusammen die Zielanwendung(en) des Gesamtsystems ausführen.

Unter diesen Voraussetzungen spiegeln sich die Lösungen entsprechend den Grundregeln der typischen Systemarchitektur in sehr unterschiedlichen HW-Realisierungen wider, die einzelne HW-Baugruppen für die verschiedenen Untersysteme benutzen.

Fig. 1 zeigt ein Blockschaltbild eines solchen typischen Systemlayouts, wie es für eine große Zahl eingebetteter Systeme gemäß dem Stand der Technik genutzt und umgesetzt wird. Es ist zu sehen, dass die ECU-Funktionalität über das ganze System verteilt ist, wodurch Redundanzen und eine Menge einzelner Kommunikationspfade geschaffen werden. Demzufolge sind die Funktionen nicht fehlertolerant, weil die vorhandenen verbundenen Teile wegen der aktuellen Topographie nicht zum vollen Vorteil ausgenutzt werden können. Zusätzlich sind diese Systeme nicht kostengünstig, weil sie einen Hardwaremehraufwand benötigen, um die jeweiligen Funktionen zu realisieren. Die vielfältige Umsetzung identischer Funktionalität in diversen Untersystemen - als Beispiel sei "Energiemanagement" erwähnt - führt zu erhöhter physischer Größe der Einheit und erhöht als weitere negative Konsequenz den Gesamtenergieverbrauch des Systems und hat einen abträglichen Effekt auf die Systemzuverlässigkeit (eine größere Zahl eingebundener elektronischer Teile reduziert das MTBF des Systems).

Typische mit der CPU verbundene kooperierende Elemente sind Einheiten wie: eine Echtzeituhr (Real Time Clock (RTC)), Schaltungen für das Rücksetzen beim Einschalten der Stromversorgung (power-up-reset) und die Hochlaufsteuerung (boot control), Systemumweltsensoren (zum Beispiel Temparatursensoren, Luftfeuchtigkeitssensor usw.) und von der CPU unabhängige Systemüberwachungsfunktionen und - zeitgeber.

Hauptsächliche funktionelle Anwendungs-/Lösungs-Gebiete werden gewöhnlich durch ganze Untersysteme repräsentiert:

• - Stromversorgungs-Untersystem (für alle ECU- Stromversorgungseinheiten und externe, allgemeine Stromversorgungssysteme)
• - Speicher-Untersystem (Speichereinheiten in Siliziumtechnik und gegebenenfalls externe Massenspeichergeräte wie Festplatten und optische Geräte)
• - Echtzeit-Untersystem(e) für direkt verbundene Echtzeitgeräte (DIO) und Echtzeit-Busschnittstellen, die mit externen Echtzeiteinheiten verbunden sind
• - Telematische Untersystem(e) wie Radiosender und - empfänger, Radarsensoren, Modem und Telefon und andere Geräte, die drahtlose Kommunikation und Zugang zu Fern- (WAN) Netzwerken erlauben
• - das Schnittstellensystem für den Menschen (oder "Mensch-Maschine-Schnittstelle", MMI) - mechanische E/A-Einheiten wie Schalter, Drehknöpfe, Joysticks; graphische Schnittstellen wie einfache Anzeiger, alphanumerische Anzeigen, LCD-Anzeigen usw.; akustische Einheiten wie einfache Signalgeräte, zum Beispiel Pieper, Hupen oder Plattenspieler - die zu komplexen SprachSteuersystemen mit Spracherkennung und Sprachausgabe führen.

Zusätzlich zu der Bereichsfunktion des jeweiligen Untersystems deckt jedes der angegebenen Untersysteme normalerweise die Funktionalität des Stromversorgungsmanagements, die Initialisierungsroutinen, das Speichermanagement, die spezielle Kommunikation zwischen CPU und Untersystemen sowie das Fehlermanagement ab - die Funktionalität wird redundant abgedeckt - ein Umstand, der von der Standardsystemarchitektur vorgegeben ist.

Als ein Zugeständnis an das verteilte HW-Layout und die verschiedenen einzelnen, internen Untersystemlösungen gibt es keine nützliche HW/SW-Gemeinsamkeiten unter den diversen ECU-Vorrichtungen - auch wenn einer "ähnlichen" Umsetzung der Standardarchitektur gefolgt wird.

Als weitere Konsequenz werden die grundlegenden Systemsteuerfunktionen, das Stromversorgungsmanagement, die Systemunterstützungsfunktionen und die Systemschnittstellenfunktionen sowie die spezifischen systeminternen Kommunikationsverbindungen wiederholt durch identische Hardwaregeräte dargestellt, die sich in den Untersystemen befinden oder in die Haupt-CPU oder den unterstützenden Chipsatz integriert sind.

Charakteristisch für die betrachteten Standard-HW- Architekturen und -Systeme ist die vollständig unterschiedliche Art der ECU-Kommunikation und der entsprechenden Untersystem-Kommunikation.

Fig. 1 ist repräsentativ für eine große Auswahl von eingebetteten Systemen, beispielhaft beginnend mit einfachen Steuerungen, die wohl in Konsumprodukten wie Geschirrspülern, Mikrowellenherden, Waschmaschinen eingesetzt werden - bis hin zu komplexeren Systemen, wie sie zum Beispiel genutzt werden für die große Palette von Produkten, die durch die Welt der allgegenwärtigen Computertechnik (pervasive computing) abgedeckt werden, wie Set-Top-Boxen und Multimediageräte. Ein ganzes neues Feld des "pervasive computing" eröffnet sich durch das massive Eindringen von vielerlei Verarbeitungssystemen in die heutigen Automobile. Die Verarbeitungsplattformen werden als Erweiterung genutzt, um neue Anwendungen für Client- und entfernte Serverdienste (server service) zu unterstützen, und konzentrieren sich nicht nur auf Fahrzeugfunktionen. Bereits heute bzw. in der nahen Zukunft greifen moderne Fahrzeuge auf externe Netzwerke zu, die es erlauben, Dienste wie Ferndiagnose und Wartung, intelligente Navigation unter Nutzung von Verkehrsinformationen, Fax, Email und nicht zuletzt Internetzugang und -dienste bereitzustellen, wobei diese Aufzählung nicht vollständig ist und in den kommenden Jahren dramatisch ausgeweitet werden wird.

Bemerkenswert bei allen behandelten Systemen ist die Tatsache, dass die Mehrheit der Anwendungen, die das System nutzen, selbst wenn sie hauptsächlich durch die einzelnen Untersysteme innerhalb der ECU ausgeführt werden, den Hauptprozessor in einem gewissen Maße - oder in einigen Fällen beträchtlich - belasten. Um nur ein Beispiel zu nennen - alle Echtzeitfunktionen und ebenso die Nichtechtzeitfunktionen, wie die vom MMI bewirkten Routinen und die Untersystem-Stromversorgungsmanagement-Funktionen, belasten den Hauptprozessor. Zusätzlich sind die verschiedenen ECU-internen und systemexternen Kommunikationsverbindungen (wie die vom Bus ausgelösten Echtzeit-Unterbrechungen, die LAN- und die WAN- Anschlussmöglickeiten), die direkt an den Hauptprozessor "melden", weitere Nachfrager für mehr Prozessorleistung.

Als Konsequenz muss der Entwickler ausreichende Verarbeitungsleistung (CPU MIPS) sicherstellen - überhöht im Vergleich zu der erforderlichen MIPS-Rate, die durch die Systemanwendungen vorgegeben wird - um eine ordnungsgemäße Arbeit des Systems zu gewährleisten, die die meisten der möglichen erwarteten Belastungsspitzen abdeckt.

Fig. 2 zeigt ein Systembus-Kommunikationsschema, wie es normalerweise in der Mehrheit der Verarbeitungssysteme genutzt wird (zum Beispiel auf Intel basierende Personalcomputer). Die Busstruktur ist hierarchieorientiert. Der lokale Bus der CPU stellt normalerweise den Bus mit der höchsten Bandbreitenleistung dar. Die CPU und eng verbundene Einheiten und Untersysteme sind mit diesem Bus verbunden. Eine Busbrücke stellt die Verbindung (gateway) zum Bussystem der nächstniedrigeren Ebene her. In Personalcomputersystemen ist dies normalerweise der PCI-Bus.

Die Vorteile, die durch diese Architektur erhalten werden, sind simultane, ungestörte Kommunikation der Einheiten auf ihrer Busebene.

Jedoch müssen alle Kommunikationen, die fordern, dass Einheiten von der höheren Busebene auf Einheiten zugreifen, die sich auf anderen Busebenen befinden (oder umgekehrt), einen "Pfad" über die Verbindung passieren, die von der jeweiligen Brückeneinheit gebildet wird.

Der Nachteil dieses Engpasses, auf den die Standard- Busstruktur trifft, ist offensichtlich und braucht nicht erklärt zu werden. Ein weiterer Nachteil entsteht durch die "einzelne zeitliche Nutzung" für diese Busstruktur. Zum Beispiel wird, wenn zwei Bus-Teilnehmer auf der gleichen Ebene kommunizieren, nicht nur die Kommunikation für andere Einheiten dieses Busses behindert, sondern es ist in dieser Zeit für andere Einheiten, die auf anderen Busebenen angeordnet sind, unmöglich, irgendeine Einheit dieses Busses zu kontaktieren.

Spezielle SW- und HW-Module werden genutzt, um erweiterte Bus-Protokolle zu erlauben, die erforderlich sind, um die verschiedenen Kommunikationstypen wie M/S-(Master/Slave-) Methoden und DMA (Direct Memory Access) zu verwalten und zu steuern.

In der japanischen Anmeldung Nr. 60-217471 ist ein Steuersystem dargestellt, in dem das beschriebene elektronisch gesteuerte Fahrzeug nicht nur eine ECU (Hauptsteuerungseinheit) zur Steuerung der verschiedenen Stellglieder umfasst, es ist auch mit Notfall-Stellgliedern für Reservezwecke in dem Fall, dass an irgendeinem Stellglied oder der Hauptsteuerungseinheit selbst eine Abnormalität, wie Drahtbruch oder Kurzschluss, auftritt, mit einer Notfall-ECU zur Steuerung der Notfall-Stellglieder ausgerüstet.

Die US-Patentschrift A-4 910 494 zeigt ein Steuersystem für ein Kraftfahrzeug mit Fehlererkennungmitteln, die in der Haupt-ECU bereitgestellt werden, zur Diagnose von Fehlern bei der Überwachung der Notfall-ECU.

In EP-A-0 862 296 wird ein Datenkommunikationssystem beschrieben, das eine Vielzahl von dort genutzten ECUs umfasst, wobei jede einen Hauptprozessor zur Steuerung einer elektronischen Einheit besitzt und jede der ECUs mit anderen ECUs unter einem vorher bestimmten Datenübertragungsprotokoll kommuniziert.

Zusammenfassung der Erfindung

Es ist deshalb eine Aufgabe der vorliegenden Erfindung, ein elektronisches Steuersystem bereitzustellen, das es erlaubt, ein außerordentlich leistungsfähiges eingebettetes Verarbeitungssystem mit hoher Zuverlässigkeit und Fehlertoleranz aufzubauen.

Es ist eine weitere Aufgabe der vorliegenden Erfindung, solch ein System bereitzustellen, das vorteilhaft in Verarbeitungsplattformen ist, die die Ausführung von Echtzeitanwendungen zusammen mit Nicht-Echtzeitanwendungen erfordern.

Es ist noch eine weitere Aufgabe der vorliegenden Erfindung, eine Steuersystemarchitektur zu liefern, die vorteilhaft für eine Anzahl von Anwendungen der Art "pervasive computing" ist.

Diese und andere Aufgaben werden durch ein elektronisches Steuersystem zur Steuerung der Funktion eines Verarbeitungssystems gelöst, das eine Vielzahl von logischen Steuerelementen umfasst, wobei jedes speziell für die Ausführung von Spezialaufgaben geeignet ist und wobei jedes der Steuerelemente in der Lage ist, mit jedem anderen Steuerelement zu kommunizieren.

Die vorliegende Erfindung, genannt Tetrahedron Control Element Topology (TCET) (Tetraeder-Steuerelement-Topologie), beschreibt ein Prinzip und eine Systemtopologie für computergestützte Verarbeitungssysteme, die es vorteilhaft ermöglichen, Elektronische Steuereinheiten (ECU) zu bauen, die sich durch erstklassige Systemleistung und Systemverfügbarkeit auszeichnen. Das vorgeschlagene System umfasst die Eigenschaften der Bereitstellung eines grundlegenden Fehlertoleranzverhaltens, der Unterstützung des wirksamen Aufbaus von ausgedehnten fehlertoleranten Systemen, der Fehlerbeseitigung oder von Mechanismen zum Rückgängigmachen von Fehlern.

Das TCET-Prinzip benötigt einen minimalen Systemaufwand (system overhead) bezüglich der Hardware- und der Softwareressourcen, um eine Grundfehlertoleranz zu gewährleisten. Das Prinzip nutzt die Systemhardware- Ressourcen mit maximaler Effizienz und erlaubt somit grundlegend Systemrealisierungen mit minimalen Kosten.

Die vorgeschlagene Architektur reduziert die Gesamtsystemkomponenten und Untersysteme auf eine Kernmenge von vier einzelnen logischen Hauptsteuerelementen, die in einer einzigartigen Verarbeitungstopologie organisiert sind. Jedes der Steuerelemente ist einzeln definiert, um scharf umrissene funktionelle Verantwortungsbereiche abzudecken - Vorbedingung für spezielle Lösungen, um optimal die spezifizierte Gruppe von Aufgaben zu lösen. Die Steuerelemente arbeiten in einem einzigartigen Kommunikationsschema zusammen, vermeiden dabei funktionales "Überlappen" in HW-Gebieten oder SW-Modulen innerhalb des Gesamtsystems, wie sie normalerweise von Ausführungen angeboten werden, die Standardlösungen für die System- /Untersystem-Architektur nutzen.

Ein wichtiger Schlüssel zu der vorgeschlagenen Idee ist, die gekennzeichneten Steuerelemente in einer zusammenwirkenden Tetraeder-Geometrie zu organisieren, was zur Verfügung stellt:

• a) simultane Multipfad-Kommunikation der jeweiligen Elemente
• b) Echtzeitvermögen aller hardwarenahen Komponenten, Untersysteme und Netzwerke der ECU
• c) sicherer Zugang zu systemexternen Einheiten (die sich in LAN und WAN befinden oder drahtlos).

Das TCET-Prinzip für die Kombination von elektronischer Schaltkreisanordnung und Softwareaufteilung erlaubt es, sehr leistungsfähige eingebettete Verarbeitungssysteme mit hoher Systemzuverlässigkeit und Systemverarbeitungsfähigkeit aufzubauen. Leistungsfähigkeit durch - in direktem Vergleich zu Lösungen mit "Standard"-Verarbeitungsystemlösungen - eine deutlich reduzierte Menge an elektronischen Schaltkreisen und an Systemkomplexität, die erforderlich ist, um die Zielanwendung(en) der jeweiligen Systeme zu erreichen. Weiterhin liefert das Prinzip eine optimale Basisstruktur, die den Aufbau von fehlertoleranten Systemen mit minimalem Aufwand unterstützt.

TCET wird vorteilhaft bei Verarbeitungsplattformen eingesetzt, die die Ausführung von Echtzeitanwendungen in Übereinstimmung mit Nichtechtzeitanwendungen erfordern.

Weiterhin ist die Architektur vorteilhaft für eine Vielzahl von Anwendungen der Art "pervasive Computing".

Zusätzlich kann diese Lösung für große Rechnersysteme genutzt werden, aber auch für Standard-Bürorechnersysteme, z. B. "Personalcomputer", für eingebettete Systeme mit geringer Leistung und geringen Kosten sowie für Spielcomputer. Diese Liste ist nur beispielhaft und nicht begrenzt.

Detaillierte Beschreibung der Erfindung

Es ist von wesentlicher Bedeutung, die Systemtopologie neu zu definieren und eine neue Systemorganisation sowie eine neue interne Struktur mit reduzierten Überschneidungen und redundanter Funktionalität in der Zentraleinheit und den entsprechenden Untersystemen zu finden, um die angestrebten Merkmale der Erfindung zu erreichen. Als eine Orientierungslinie muss jedes Untersystem so definiert werden, dass es ein spezifisches, scharf umrissenes Aufgabenspektrum abdeckt. Auf diese Weise ist es möglich, optimierte funktionale Unterelemente zu bauen, die perfekt die Anforderungen der speziellen Aufgabenteile erfüllen. Um schließlich die Ziele zu erreichen, ist es unerlässlich, die Unterelemente in einer Topologie anzuordnen, die eine sehr leistungsfähige Kommunikation zwischen den kooperierenden Elementen erlaubt.

Drei Hauptregeln werden genutzt, um zu dem vorgeschlagenen neuen ECU-Prinzip und der neuen Architektur zu gelangen.

• 1. Organisiere die HW-Untersysteme und die funktionalen HW-Elemente und kennzeichne neue logische Elemente neu, die auf spezielle und miteinander verbundene Aufgaben konzentriert sind. An dieser Stelle ist es wichtig zu verstehen, dass logische Elemente nicht notwendigerweise durch HW repräsentiert sein müssen, die besagte Aufgaben und Anwendungen ausführt. Aufgabe ist es, eine funktionale Überschneidung der neu definierten logischen Elemente - nachfolgend Steuerelemente (C1 . . . Cn) genannt - und eine redundante Funktionalität zu vermeiden, die sich über die Steuerelemente Cn ausbreitet.
• 2. Definiere eine neue Hardware- und Software- Systemtopologie, die auf den gekennzeichneten logischen Steuerelementen aufbaut. Jedes Steuerelement muss einzigartig sein und unabhängig arbeitende Software mit Hilfe von einzeln maßgeschneiderten Betriebssystemen, SW-Ebenen (layers) und Treibern und gegebenenfalls spezifischen Steuerelement-Anwendungen, erlauben und unterstützen.
• 3. Definiere ein Schema der Kommunikation zwischen Steuerelementen, das wirksam, sicher und verlässlich für die Kommunikation des ECU-Systems intern und auch für alle jeweiligen externen Kommunikationsverbindungen ist. Aufgabe ist, Einschränkungen, wie sie von Standard-Architekturanwendungen bekannt sind (wie oben beschrieben), zu vermeiden. Der Kommunikationspfad von jedem Steuerelement zu jedem anderen Steuerelement muss für die Gesamt-ECU-Anwenderprogramme unsichtbar sein. Als eine Grundregel gilt, dass es wichtig ist, spezielle, auf eine Aufgabe zugeschnittene Kommunikationsverbindungen, die die einzelnen Steuerelemente verbinden, zu vermeiden.

Zusätzlich zu dem ECU-internen Kommunikationsschema muss eine sichere Lösung geliefert werden, die den Zugang zu den ECU-bezogenen Echtzeitnetzwerken und -untersystemen sowie die Kommunikation mit systemexternen Erweiterungen, auf die Standardnetzwerke (LAN, WAN und Funk) zugreifen, erlaubt. Typisch für diese externe Netzwerkverbindung ist die "Plug- and-play"-Fähigkeit (Anschließen und Spielen) und die Möglichkeit für externe Nutzer und Systeme, unautorisiert zuzugreifen.

Die drei oben erwähnten Hauptregeln sollen nun ausführlicher beschrieben werden.

Regel 1: Kennzeichne logische Steuerelemente Cn

Fig. 1 wird genutzt, um die verteilte Funktionalität in einem System zu analysieren, das gemäß der Standardsystemarchitektur ausgeführt ist, und um die neuen Steuerelemente, wie in Regel 1 gefordert, zu definieren.

Die erste Aufgabe ist, Funktionen in Kategorien einzuteilen und hiernach direkt verbundene Funktionen einem spezifischen logischen Steuerelement zuzuordnen. Diese konzentrierte Sammlung von verbundenen und möglicherweise direkt kommunizierenden Funktionen innerhalb eines logischen Steuerelementes erlaubt es, eine sehr leistungsfähige Lösung anzugeben.

Eine detaillierte Untersuchung des "Standardsystems" legte eine minimale Anzahl von vier Hauptfunktionsgebieten offen. Jedes deckt ein spezielles Feld von Anwendungen und Diensten ab. Die Grundidee ist, einzelne, maßgeschneiderte zugeschnittene Steuerelemente (C1, C2, C3 und C4) zu bestimmen, die genau die von jedem Feld geforderte Funktionalität liefern.

Im nächsten Schritt werden die vier gekennzeichneten Felder als Steuerelemente C1 bis C4 definiert. An diesem Punkt ist es wichtig festzustellen, dass die gekennzeichneten Steuerelemente die logischen Funktionen, die den einzelnen Steuerelementen zugeordnet sind, definieren, und nicht notwendigerweise durch Hardware darzustellen sind.

Funktionale Zusammenfassung der Steuerelemente C1 bis C4

Im Folgenden werden die funktionalen Aufgaben von jedem der vier Steuerelemente behandelt.

Steuerelement C1 "SysMon" (System-Überwachung)

• - Stromversorgungsmanagement (Abschalten ungenutzter Stromquellen, Steuerspannungen)
• - Steuerung des Einschaltens der Systemstromversorgung (Stromversorgungsfolge, Stromversorgung in Ordnung (power good))
• - Erzeugung der Systembootfolge und Überwachung (Fehlerüberwachung und Steuerung einer Reservelösung (fallback solution control))
• - Überwachung der Systemvitalität (Temperatur und Feuchtigkeit erfassen, die Anzeigeelemente für die funktionale Vitalität der anderen Steuerelemente abfragen)
• - Systembereitschaft und Ruhesteuerung
• - Systemfehlerbehandlung

Steuerelement C2 "ComPro" (Kommunikationsprozessor)

• - Echtzeitanwendungen
• - Echtzeitnetzwerkzugang und -steuerung
• - Verbindung zu Nichtechtzeit-Untersystemen und - Netzwerken
• - Systemfehlerbehandlung

Steuerelement C3 "MMI/A" (Mensch-Maschine-Schnittstelle und allgemeine Anwendung)

• - Hauptanwendungen des ECU-Systems
• - Schnittstellenanwendungen zum Menschen und E/A- Funktionen (mechanische E/A, visuelle E/A, Sprach- /Ton-E/A)
• - Multimedia-Anwendungen (Video- und Audio- Verarbeitung)
• - Systemfehlerbehandlung

Steuerelement C4 "CAP" (Allgemeiner Zugangspunkt (Common Access Point))

• - Konzentrierter Zugangspunkt für systeminterne Kommunikation
• - Systemerweiterungsverbindung für externe Kommunikation
• - Systemfehlerbehandlung

Regel 2: Aufteilung des logischen Systems

Aus der Definition des TCET-Prinzips heraus ist jedes Steuerelement dazu bestimmt, unabhängig zu arbeiten und sein eigenes, spezielles Feld von Anwendungen auszuführen. Um sich an die unterschiedliche Art von Anwendungen anzupassen und um die bezeichneten Systemziele zu erreichen, muss es die Steuerelemente unter Verwendung individueller Lösungen realisieren, die durch Hardware (HW) und/oder Software (SW) dargestellt werden, die genau definiert sind, um die speziellen Anforderungen am besten zu erfüllen.

Wie schon vorher erklärt wurde, müssen die logischen Steuerelemente nicht notwendigerweise durch getrennte Prozessoren und/oder Hardwareeinheiten dargestellt werden. In Abhängigkeit von der Funktionalität des Gesamtsystems ist es genauso möglich, die vorgeschlagene TCET-Architektur durch die Ausführung der logischen Steuerelemente auf einem einzelnen Prozessor zu realisieren. In diesem Fall können die funktionalen Steuerelemente durch integrierte HW- Erweiterungen gelöst werden oder sogar durch gleichwertige Software ersetzt werden.

Das Konzentrieren auf ein gekennzeichnetes, einzelnes Spektrum von Funktionalität für jedes Steuerelement führt zu einer speziell zugeschnittenen Lösung, die perfekt dem speziellen Operationsgebiet dient. Redundante Elemente, wie sie beim Stand der Technik bekannt sind, werden auf ein Minimum beschränkt. Der Vorteil für das gesamte TCET-System ist ein minimaler Aufwand an Hardware und Software - ein wichtiger Faktor bei der Erreichung der Kosten-, Leistungs- und Funktionsziele des Gesamtsystems.

HW/SW-Lösungen für typische, eingebettete Systeme können wie folgt beschaffen sein:

Steuerelement C1 (SysMon) Hardwarelösung

Ein typischer Aufbau wäre ein einfaches 8-Bit-Steuerelement (controller) oder in einigen Fällen eine spezielle Abfolge-Steuerung in einem ASIC. Eine Lösung, die perfekt den Anforderungen der Mehrzahl der Systeme genügt, könnte zum Beispiel ein einfacher µControllerchip aus der "PIC"- Controller-Familie von Microchip sein.

Betriebssystem und Anwendungssoftware

Die bevorzugte Lösung erfordert kein Betriebssystem. Die Anwendung wird in einer HW-Sprache der niedrigsten Ebene programmiert. Dies führt zu einem sehr kompakten und leistungsfähigen Code, der direkt von der HW ausgeführt wird. Die SysMon-Algorithmen, programmiert in µ- Code, werden als "Firmware" in einem ROM oder einem EEPROM gespeichert und sind normalerweise in die SysMon-Komponente integriert.

Normale Softwareumsetzung

Die SysMon-Funktionen werden durch SW-Module dargestellt, die entweder durch C2 oder C3 ausgeführt werden. Diese Lösung würde normalerweise für sehr kleine eingebettete Systeme gewählt werden.

Steuerelement C2 (ComPro) Hardware Lösung

Die Betonung für den ComPro liegt auf minimaler Unterbrechungslatenz und auf minimaler Ausführungszeit der Unterbrechungsroutine (interrupt handler). Das ist wichtig für die Hardware (Microcontroller und beteiligtes Speichersystem) und auch für die Software, die durch die SW ausgeführt wird (Unterbrechungshandler-Stack). Abhängig vom Umfang und der Komplexität der bereitzustellenden Echtzeitanwendungen kann der ComPro bei Billigprodukten durch eine spezielle programmierbare Ablaufsteuereinheit realisiert werden, bei anspruchsvollen Ausführungen durch einen Standard- 32-Bit-Microcontroller. Für die Mehrzahl der Systeme würde man einen 8- oder 16-Bit-Controller benutzen.

Betriebssystem und Anwendungssoftware

• a) Echtzeitbetriebssystem (RTOS), mikrocontroller-spezifisch (zum Beispiel OSEK, QNX und andere)
• b) Kostengünstige Lösung: Direkt programmierte Echtzeit- Abfolgesteuerung (als Hardware oder Firmware).
• c) Das Betriebssystem OSEK - ein neuer Standard in Europa - wird vorgeblich von der Mehrheit der Fahrzeughersteller genutzt. Eine sehr leistungsfähige OSEK-Lösung, entwickelt von IBM und AR/OS (Automotive Real-time Operating System) genannt, wurde entwickelt, die PowerPC-Architektur auszunutzen. AR/OS ist konfigurierbar und umfasst eine voll ausgestattete Echtzeitausführung und eine reiche Sammlung optionaler Bibliotheken, die offene Netzwerkschnittstellen liefern sowie eine Erweiterung, die ANSI-C- und POSIX-Standards unterstützt. Die Echtzeit- Ausführung liefert die Basisdienste, die in dem Entwurf POSIX Echtzeit definiert sind und erfüllt die Bedürfnisse von speicherbeschränkten, tief eingebetteten Systemen. Die Kombination, die einen PowerPC und AR/OS nutzt, versetzt den ComPro in die Lage, eine großes Spektrum von Anwendungen zu unterstützen.

Reine Softwarelösung

Da TCET ECU-Realisierungen

• a) eine sehr hohe Leistung erfordern, die für die Anwendungen des Steuerelementes C3 bereitzustellen ist und
• b) nur geringe Nachfrage nach Echtzeit-Funktionen und -Schnittstellen besteht, ist es wichtig, die ComPro Funktionen in SW-Modulen zu realisieren, die von dem C3-Mikroprozessor ausgeführt werden. Bei dieser Art von Umsetzung muss der C3- Mikrocontroller eine Speicher- Management-Einheit (MMU) bereitstellen, die es erlaubt, den C2-Code vom C3-Code und den Anwendungen zu trennen.
  Dies ist grundlegend, um die Realisierung von Softwaremodellen zu erlauben, die einen sicheren Betrieb garantieren (Trennen der Echtzeitwelt von den "unsicheren" Plug-and-play- Systemen, die möglicherweise an das C3-Element angeschlossen sind).

Steuerelement C3 Hardwarelösung

C3 ist das Steuerelement, das typischerweise mit Komponenten der Schnittstellen zum Menschen und Multimedia-Einheiten arbeitet und höchste Arbeitsleistung (hohe MIPS- Rate) innerhalb der TCET ECU erfordert. Unterbrechungslatenz und minimale Ausführungszeit für die Unterbrechungsverarbeitung sind normalerweise nicht kritisch. Aus diesem Grund wird C3 für die Mehrzahl der Systeme durch Standard-32-Bit-Mikroprozessoren umgesetzt. Jedoch kann eine 16- Bit- oder 8-Bit-Microcontroller- Lösung für einfache Systeme, die nur einfache MMI-Unterstützung erfordern, ausreichend sein.

Betriebssystem und Anwendungssoftware

Das Steuerelement C3 läuft normalerweise auf Standard-Betriebssystemen (wie zum Beispiel QNX, WIN-CE und andere), die Grafikunterstützung geben. Im Falle von Anwendungen, die mit Internetzugang und Email-Funktionen verbunden sind, kann die bevorzugte Lösung ein RTOS mit einer integrierten JVM (Java Virtual Machine) sein. Bei dieser Lösung würden die C3- Anwendungen in Javaprogrammen und Applets ausgeführt sein.

Normale Softwarelösung

Normalerweise nicht anwendbar -
sehr anspruchslose Systeme mit nur wenigen Schnittstellenfunktionen zum Menschen und einer höheren Betonung von Echtzeitverbindung und -anwendungen können jedoch durch eine leistungsfähigere C2-Lösung umgesetzt werden, die es erlaubt, auch C3- Softwareanwendungen auszuführen. Aus dem gleichen Grund, wie für die normalen Softwarelösungen für C2 erklärt wurde, sollte der gewählte Mikrocontroller für diesen Typ der logischen C3-Lösung eine MMU bereitstellen.

Steuerelement C4 Hardwarelösung

Das Steuerelement C4 wird typischerweise als reine Hardwarelösung ausgeführt. In den meisten Fällen kann ein Standard- Netzwerkcontroller genutzt werden. In ASIC-Lösungen für die TCET ECU führt eine spezielle Lösung für C4 zur besten und kostengünstigsten Umsetzung. Für billige Lösungen kann ein Field Programmable Gate Array (FPGA) von Vorteil sein, der kleinere Standard-Bus-Controller ergänzt, um die C4-Funktionalität aufzubauen.

Betriebssystem und Anwendungssoftware

Da der C4 normalerweise eine reine Hardwarelösung ist, werden C4- Algorithmen durch spezielle Mikroprogramme bereitgestellt, die von der Hardware ausgeführt werden. Der in der Firmware realisierte Code wird in ROM oder EEPROM gespeichert - normalerweise in der C4-Einheit integriert.
Das C4-Element liefert keine TCET- ECU-Anwendungsfunktionen und ist aus diesem Grund "unsichtbar" für die Systemanwendungssoftware. Die Treibersoftware, die für einen Netzwerkzugang möglicherweise erforderlich ist, wird zu den jeweiligen für C2 und/oder C3 genutzten Betriebssystemen hinzugefügt.

Normale Softwarelösungen

Diese Art von Umsetzung würde als untypische TCET Realisierung 'betrachtet' werden - jedoch kann das, wenn nützlich, getan werden. Die C₄-Funktionalität würde in diesen Fällen von SW-Modulen und Hardwareerweiterungen auf entweder C2 oder C3 bereitgestellt werden.

Regel 3: Betrieb unter Zusammenwirken von TCET- Steuerelementen C_n

Im allgemeinen kann zwischen zwei verschiedenen Kommunikationsarten des TCET-Systems und der Gesamtsystemumgebung unterschieden werden. Um mit der TCET- ECU-internen Kommunikation zu beginnen: dort müssen Verbindungen bereitgestellt werden, die es den Steuerelementen C1 bis C4 erlauben, miteinander zu kommunizieren. Die zweite Kommunikationsart zieht alle Wechselwirkungsverbindungen, die zur Welt außerhalb von TCET ECU führen, in Betracht.

Als Konsequenz aus dem TCET-Prinzip, wie in Regel 1 und 2 definiert, werden die TCET-ECU-externen Kommunikationsverbindungen dem jeweiligen auf diesen Kommunikationstyp spezialisierten Steuerelement zugeordnet. Das ist ein wichtiger Umstand, der zu den angestrebten TCET- Eigenschaften von Systemsicherheit und -zuverlässigkeit führt, und er ist vernünftig nach dem Verstehen der Eigenheiten der TCET-"Außen-Verbindungen".

Die TCET-"Außen-Verbindungen"

Die Verbindungen zur echtzeitbezogenen Welt (Fig. 3 Kommunikationspfad i) wird durch ComPro (C2) bereitgestellt. Alle Anwendungen, die mit Echtzeitfunktionalität zu tun haben, werden von diesem Steuerelement ausgeführt.

Das SysMon (C1) ist mit dem externen Stromversorgungs- Untersystem und allgemeinen systemunterstützenden Einheiten verbunden (Fig. 3, Pfad k). Beide Verbindungen i) und k) behandeln stark ECU-bezogene und Hardwareunterstützungsfunktionen. Ein Beispiel, um das Wesen dieses Kommunikationstyps zu veranschaulichen: in Autos ist dieses System mit sicherheitsrelevanten und kritischen System-Funktionselementen wie dem Bremssystem, dem Getriebe, der Lichtsteuerung und anderen verbunden.

Das in die sogenannte "unsichere" Welt reichende CAP (C4) liefert die Kommunikationsverbindung zu Systemerweiterungen und führt Zugang zu LAN, WAN und drahtlos herbei (Fig. 3, Pfad m und p). "Unsichere Welt" mit Hilfe von Netzwerken ermöglicht es dem Systemnutzer (z. B. Fahrzeugführer oder Passagier), neue Geräte anzuschließen ("Plug-and-play"- Geräte wie ein PDA, CD-Spieler, Modem und andere) und liefert auch den Eintritt in weit entfernte Systeme, inklusive Internetzugang.

Diese Trennung, die echtzeitbezogene Anwendungen auf den ComPro beschränkt und die "unsichere" Plug-and-play-Welt auf den MMI/A (C3) und den CAP (C4) konzentriert, liefert die perfekte Vorbedingung, die die Realisierung von sicheren Verbindungen (gateways) unterstützt und demzufolge die kritischen Anwendungen isoliert.

Die "inneren TCET-Verbindungen"

Die TCET-internen Verbindungen (Fig. 3, Pfade a, b, c, d, g und f) verbinden die Steuerelemente C1 bis C4 miteinander. Alle diese Verbindungen werden genutzt, um verschieden Arten von Kommunikationsaufgaben zu unterstützen. Eine Art von Aufgabe, die alle internen Verbindungen betrachtet, kann als "systeminterne Management- und Steuer"-Funktion zusammengefasst werden. Typische interne Managementfunktionen sind: Stromversorgungsmanagement, Boot- Steuerung, Systemtest und Vitalitätsprüfung, und nicht zuletzt das Bereitstellen von Kommunikationsfähigkeit, um fehlertolerante Strategien zu unterstützen.

Die Kommunikationsverbindung b) wird hauptsächlich genutzt, um Datenaustausch zwischen den ComPro und den MMI/A- Steuerelementen zu erlauben. Abhängig vom Umfang der Anwendungen, die von den beiden erwähnten Steuerelementen ausgeführt werden müssen, hat diese Verbindung eine Übertragungsbandbreite bereitzustellen, die bei 1 MB/s für normale Systeme beginnt, und falls zum Beispiel grafische Informationen ausgetauscht werden müssen, kann die erforderliche Bandbreite leicht bis zu 20 oder mehr MB/s ansteigen.

Die Verbindungen d), f) und g) verbinden die Steuerelemente C1 bis C3 mit dem CAP (C4) und erlauben demzufolge den Zugang zu ECU-Systemerweiterungen. Die Bandbreite, die für diese Verbindungen bereitgestellt werden muss, ist hauptsächlich durch anzuschließende externe Einheiten definiert und typischerweise wenigstens so hoch wie die für Pfad b) erforderliche Bandbreite.

Als eine Richtlinie für die Umsetzung des TCET-Prinzips ist es vorteilhaft, alle TCET-"internen Verbindungen" mit gleicher Leistung und Entscheidungsfähigkeit zu realisieren. Dies liefert vielfältige Wahlmöglichkeiten für die verschiedenen Kommunikationsarten, die ausgeführt werden müssen, und führt demzufolge zu den Zielen hoher Systemverfügbarkeit und -leistungsfähigkeit. Weiterhin stellt die Fähigkeit einer Verbindung mit mehreren Pfaden, die durch "Fehlerbehebungsalgorithmen" - optional von C1 bis C4 geliefert - unterstützt und genutzt wird, ein grundlegendes fehlertolerantes Verhalten dar und ermöglicht leistungsfähige Realisierungen für weiteres Fehlermanagement.

Die TCET-ECU-interne Kommunikation kann weiter unterteilt werden in Verbindungen, die ECU-intern bleiben, mit Hilfe von Informationsaustausch ausschließlich innerhalb der TCET- Elemente, und in Verbindungen, die ein Teil eines größeren Kommunikationspfades sind und das ECU durch ein externes Netzwerk verlassen.

Zur weiteren Erklärung sind diese Verbindungen mit iL (immediate link, direkte Verbindung) für die internen Verbindungen und aL (arbitrated link - Entscheidungsverbindung) für die ECU-externen Verbindungen bezeichnet.

Direkte Verbindung (iL)

Die Steuerelemente C1, C2 und C3 sind durch die Verbindungen a, b und c verbunden. Entsprechend dem TCET-Prinzip sind diese Verbindungen als bidirektionale Punkt-Punkt- Verbindungen definiert. Jede dieser Verbindungen bedeutet ein Maximum von zwei Kommunikationsteilnehmern.

Als Richtlinie für die Umsetzung des TCET-Prinzips ist es erforderlich, unabhängige Zugangspunkte an jedem Ende der aufgezählten Kommunikationspfade einzurichten - ungeachtet des Modells der Gesamtsystemlösung (HW- und SW-Aufteilung).

Im Falle der physischen Darstellung für ein Steuerelement (HW-Lösung) würde dies einzelne, unabhängige Sender/Empfänger-Einheiten für jede Verbindung bedeuten - in SW-Lösungen entsprechende unabhängige Treiberelemente.

Die Realisierung dieses Typs von Kommunikationspfad(en) ist sehr einfach - für beide Arten, SW und/oder HW. Unterbrechungsgesteuerte Lösungen werden normalerweise bevorzugt, jedoch können, abhängig vom Gesamtsystem, Abfragetechniken ebenfalls nützlich sein. Da nur zwei Punkte angewählt werden müssen, beeinflusst höhere Nachfrage nach Übertragungsgeschwindigkeit (für die typische interessierende Bandbreite) die HW-Kosten nur unwesentlich.

Entscheidungsverbindung (aL)

Die Kommunikationspfade d, f und g verbinden den CAP (C4) und sind über C4 in der Lage, sich in externe Netzwerke einzubinden. Externe Netzwerke können durch LAN und WAN dargestellt sein - und für beide Netzwerktypen ist drahtlose Anschlussmöglichkeit eine gültige Lösung. Normalerweise werden diese externen Kommunikationspfade als Multidrop- Netzwerke dargestellt, die eine Entscheidung erfordern, die es erlaubt, Buszugangs- und Kommunikationsrechte zu erlangen und zu steuern.

Für die betrachteten ECUs, zum Beispiel in allgemeinen eingebetteten Systemen und Einheiten des "pervasive computing", ist es offensichtlich, dezentralisierte Bus- Zugangsschemata anzuwenden. Standard-Bus-Zugangstechniken wie CSMA/CD (Carrier Sense Multiple Access/Collision Avoidance) oder CSMA/CD (Carrier Sense Multiple Access- /Collision Detect) und zugehörige Prozeduren repräsentieren die typischerweise benutzten Bus-Zugangsmethoden.

Abhängig von dem Gebiet der TCET-ECU-Anwendung muss Transportvermögen für IP-Rahmen-basierte Kommunikation, asynchronen, synchronen und isosynchronen Datentransfer geschaffen werden.

Das Folgende trifft im Allgemeinen auf alle TCET-internen Verbindungen zu:

Aus Gründen der Kompatibilität und Einfachheit der Umsetzung wird die Transportfähigkeit des IP-Rahmen-basierten Informationsaustauschs bevorzugt und ist vorteilhaft für die Mehrheit der Systeme, die Zugang zu Standard-LAN, -WAN und Internet erfordern - das gilt für alle TCET-ECU-internen Verbindungen.

Die TCET-ECU-Verbindungen (Zusammenfassung der Eigenschaften, der Anforderungen und der typischen Darstellung) TCET-System C1 . . C4 interne Kommunikation

a), b), d)	SysMon-aufgabenbezogene Kommunikation Anforderung: Daten geringer Menge, geringe Geschwindigkeit
c)	Anwendungsgesteuerte Kommunikation/Firewall-Datenaustausch (d. h. IP-Rahmen) Anforderung: Daten mittleren bis hohen Umfangs und mittlerer bis hoher Geschwindigkeit
g), f),	Kommunikation zu externen Erweiterungseinheiten

a)	SysMon-aufgabenbezogen (Stromversorgungsmanagement, Vitalitätsüberwachung, Test) Anforderung: Daten geringer Menge, geringe Geschwindigkeit

TCET-System C1 . . C4 externe Kommunikation

i)	Echtzeit-'nahe' HW-Kommunikation (d. h. CAN-VAN-Netzwerke) Anforderung: 10 KB/s bis 1 MB/s, deterministisches Verhalten
k)	SysMon/ Kommunikation des Stromversorgungsuntersystems/Stromversorgungsmanagement (IIC-Bus, SPI und andere) Anforderung: Daten geringer Menge, geringe Geschwindigkeit (typischerweise 100 KB/s)
l)	Kommunikation des MMI/Anwendungs-Untersystems (lokale Einheiten) Anforderung: anwendungsabhängig, E/A graphischer Daten, beispielsweise 10 MB/s
m)	Systemerweiterungsbus (LAN; entfernte Einheiten) Anforderung: anwendungsabhängig, typischerweise 10 . . 100 MB/s (und mehr)

TCET-interne Grundregeln der Kommunikation

Die Verwendung der folgenden zusammengefassten Grundregeln als eine Richtlinie wird zu vorteilhaften Eigenschaften bei den Lösungen entsprechend dem TCET-Prinzip führen. Nichtsdestoweniger könnte auf Abweichungen, die nicht allen Punkten folgen, getroffen werden, abhängig von den Forderungen eines zu entwickelnden Systems. Wenn man aber die Kompromisse und Beschränkungen versteht, wird die TCET- Ausführung immer noch ihre allgemeinen vorteilhaften Eigenschaften bereitstellen.

• - Einzelne Zugangsanschlüsse (access ports) für jede Verbindung, die für jedes Steuerelement bereitzustellen ist
• - Keine direkte elektrische Verbindung (oder optische, im Falle einer optischen Verbindung) zwischen den internen Kommunikationsanschlüssen eines Steuerelementes
• - Einzelne SW-Treibermodule für jeden Verbindungsanschluss von jedem Steuerelement
• - Bereitstellung identischer Bandbreite für alle TCET- inneren Verbindungen (spezifiziert durch die höchste erforderliche Datenrate)
• - Fähigkeit zu simultaner bidirektionaler Kommunikation für jede innere Verbindung
• - Bereitstellung der Eigenschaft von asynchronem, synchronem und isochronem Datentransport
• - Bereitstellung einer programmierbaren Nachrichtenrahmen-Struktur (z. B. Unterstützen des IP- Rahmen-basierten Informationsaustauschs)
• - Bereitstellung programmierbarer Prioritätstabellen für alle Arten der TCET-Kommunikation (bevorzugt zugänglich für alle Steuerelemente) - inklusive eine Leitung (routing) und Behandlung von Ausnahmenachrichten, zum Beispiel für Notfallkommunikation.

Detaillierte Beschreibung der Steuerelemente C1 bis C4 Steuerelement C1 'SysMon' (System-Überwachung)

Fig. 4 zeigt die Funktion von Steuerelement C1 (SysMon).

Der SysMon wird den ECU-internen Funktionen zugeordnet und ist eine wichtige Komponente, die das Fehlertoleranzverhalten des Gesamtsystems möglich macht. Hauptpflichten sind Stromversorgungs-Management, inklusive Ruhe-(sleep) und Aktivier-(wakeup) Steuerung, Zeitüberwachungs-(watchdog) Funktionen und Beobachten der Vitalität der CSE-Systemkomponenten. Die Kommunikationsverbindung, die erforderlich ist, um das Stromversorgungs-Management zu ermöglichen, kann durch eine langsame Standard-SIO-Verbindung zum Hauptstromversorgungs- Untersystem hergestellt werden, wie zum Beispiel SPI oder I²C.

Die Steuerung der Fehlerbehebungs-(fault recovery) Elemente kann die Hauptaufgabe für SysMon werden, in Abhängigkeit von einzeln festgelegten Systemanforderungen für Fehlerbehebungsmechanismen. Die Leistung, die durch dieses Steuerelement geliefert werden muss, wird in einem großen Umfang durch die Umsetzung dieser Aufgabe definiert.

Die Kommunikationsverbindungen, die an die übrigen Steuerelementen angeschlossen sind, und die Algorithmen zum Festlegen des Fehlerverhaltens und der Fehlerbehebungsfunktionen sind in Übereinstimmung mit der TCET-Architektur vorteilhafterweise identisch für alle Steuerelemente umgesetzt.

Genau wie C2 und C3 beobachtet der SysMon die internen/externen 3-Wege-Kommunikationsverbindungen. Er ist in der Lage, automatisch den ECU-internen Pfad des Informationstransports bei Fehlerverhalten neu zu organisieren.

Steuerelement C2 "ComPro" (Kommunikationsprozessor (Communication Processor))

Fig. 5 zeigt die Funktion des Steuerelementes C2 (ComPro).

Die Hauptaufgabe des ComPro ist das Bearbeiten aller Echtzeitanwendungen der TCET ECU. Aus diesem Grund ist ComPro das zentrale Kommunikationselement, verbunden mit allen TCET-ECU-internen und ECU-erweiternden Echtzeit- Netzwerken. Zusätzlich verbindet die TCET-ECU mit "nahe verwandten" Hardwareeinheiten. Diese Art von Einheiten wird durch spezielle E/A-Ausgänge unterstützt wie: digitale E/A (DIO), analoge E/A (AIO), Infrarot- Kommunikationsverbindungen (IrDA), Chipkarten und andere Schnittstellen. Einige dieser Funktionen, sofern nicht stark echtzeit-betroffen, können immer noch durch das Steuerelement C3 geliefert werden - demzufolge immer noch in Übereinstimmung mit der TCET-Architektur.

Der konzentrierte Zugang zu allen Echtzeitnetzwerken in Verbindung mit der Kommunikationsmöglichkeit innerhalb dieses Steuerelementes macht den ComPro zum "Element der Wahl", um Brücken-, Leitungs- und Verbindungs-(gateway-) Funktionen bereitzustellen. In diesem Anwendungsszenario kann der ComPro aufgebaut werden, um komplexes Nachrichtenfiltern und Nachrichten-Morphing zu unterstützen, was dementsprechend beträchtliche Verarbeitungslast vom Steuerelement 4 nimmt.

Weiterhin hat der ComPro Zugang, bereitgestellt von der TCET-internen Kommunikationsarchitektur, zu allen zusätzlichen Kommunikationspfaden wie Multimedia- Verbindungen und alle Arten von LAN- und WAN-Verbindungen.

Typische Vertreter dieser Echtzeit-Verbindungen sind Feldbusse wie CAN, J1939, VAN und andere. Die Hardwarelösung für den ComPro muss echtzeitfähige Elektronik mit Konzentration auf minimale Unterbrechungslatenz und Unterstützung einer Unterbrechungsbehandlung mit hoher Geschwindigkeit bereitstellen. Die Wichtigkeit allgemeiner Verarbeitungsleistung ist zweitrangig.

Beispielsweise kann die Verbindung zu drei einzelnen CAN- Netzwerken und zusätzlich das Einbinden in Funktionsverbindungen und E/A-Einheiten von Substeuerungselementen Unterbrechungsraten von mehr als 15000 Unterbrechungen/Sekunde verursachen, die von dem ComPro-Verarbeitungssystem bearbeitet werden müssen.

Das Kommunikationsverbindungs-Untersystem und die Fehlerverhaltensalgorithmen und -funktionen sind, in Übereinstimmung mit der TCET-Architektur, vorteilhaft identisch umgesetzt für alle Steuerelemente.

Genau wie C2 und C3 beachtet der SysMon interne/externen 3- Wege-Kommunikationsverbindungen. Er ist in der Lage, bei Fehlverhalten den ECU-internen Pfad der Informationsübertragung automatisch neu zu organisieren.

Steuerelement C3 "MMI/A" (Mensch-Maschine- Schnittstelle/Anwendung)

Die Funktion von Steuerelement C3 ist in Fig. 6 gezeigt.

Das Steuerelement C3 deckt die anspruchsvollsten TCET-ECU- Systemanwendungen ab. Zusätzlich sind die Operationen der Schnittstelle zu Menschen und damit verbundene E/A- Unterstützung wesentliche Funktionen, die von diesem Element ausgeführt werden müssen. Die MMI-Schnittstellen decken mechanische E/As (wie Sensoren und Stellglieder), visuelle E/A (wie Kameras und Anzeigen) und nicht zuletzt Sprache/Audio-E/A (wie Mikrophone und Lausprecher) ab. Die konzentrierte Sammlung dieser Arten von E/A-Geräten zeichnet das MMI/A als das dominierende Element zum Ausführen des steigenden Spektrums an Multi-Media-Anwendungen und Telematik-Anwendungen aus, inklusive Video und Audio- Verarbeitung.

Zukünftige MMI-Systeme erfordern sehr hohe Rechnerleistung, mehr noch als Multi-Media- und Telematik-Systeme:
Dreidimensionales Anzeigen und ergonomisches Sichtbarsein in Situationen mit dynamischem Licht, wie sie zum Beispiel bei Fahrzeugen in Bewegung auftreten, verstärkt sehr hohe 2D/3D- Grafikleistung. Insbesondere neue E/A-Einheiten, wie innovative "einhändig" bedienbare Steuerungen, geeignete "tolerante" Bildschirmberührungs-Oberflächen für Kraftfahrzeuge, oder Einheiten, die nicht mit der Hand bedient werden, sondern Spracherkennung und -generierung nutzen, bestimmen die Nachfrage nach hoher Computerleistung für dieses Steuerelement.

Typische 300 MIPS, die für Standard-MMI/MM-Systeme bereitgestellt werden müssen, lassen sich schon heute vorhersehen. Die unterste Grenze für "stark kostenbeschränkte Eingabesysteme" (highly cost constrained entry-systems) wird auf 100 MIPS geschätzt.

Zahlreiche Prozessoren auf dem Markt sind in der Lage, die Nachfrage nach Rechnerleistung zu befriedigen. Jedoch reduzieren Systemkostenbeschränkungen in der eingebetteten Welt und hohe Zuverlässigkeit, wie sie zum Beispiel für in Autos genutzte ECU erforderlich ist, die Anzahl der Wahlmöglichkeiten beträchtlich.

Das Untersystem der Kommunikationsverbindung und die Fehlerverhaltensalgorithmen und -funktionen sind, in Übereinstimmung mit der TCET-Architektur, vorteilhafterweise für alle Steuerelemente identisch umgesetzt.

Genau wie C2 und C3 beachtet der SysMon die internen/externen Drei-Wege-Kommunikationsverbindungen. Er ist in der Lage, bei Fehlerverhalten automatisch den ECU- internen Pfad des Informationstransportes neu zu organisieren.

Steuerelement C4 "CAP" (Gemeinsamer Zugangspunkt)

Fig. 7 zeigt die Funktion des Steuerelementes C4.

Das Steuerelement C4 konzentriert sich auf die Kommunikationsverbindungen, die die innere ECU-Welt mit der Außenwelt verbinden. Indem er als Allgemeiner Zugangspunkt fungiert, ist der CAP der einzige Punkt, der externe Systeme befähigt, die TCET ECU zu betreten und mit ihr zu kommunizieren. Dieser einzige Zugangspunkt, der externen "ungeschützten" Geräten erlaubt, mit der TCET ECU zu kommunizieren, ist ein wichtiges Merkmal für die vorgeschlagene Architektur, das es unterstützt, fehlertolerante Systeme und, in Verbindung mit der bei C2 und C3 beschriebenen Aufgabenzuordnung, kostengünstige, sichere Verbindungen (gateways) aufzubauen. Das Zusammenwirken aller Steuerelemente ist der Schlüssel zu den vorteilhaften Eigenschaften des TCET-Prinzips.

Drei Kommunikationsanschlüsse d), g) und f) werden an der Primärseite des CAP bereitgestellt, die die Kommunikationsverbindungen mit den ECU-internen Steuerelementen aufbauen. Die internen Kommunikationsanschlüsse sind vorzugsweise gegeneinander elektrisch isoliert durch einzelne physische Sender- Empfänger-Einheiten, die sie mit den anderen TCET- Steuerelementen verbinden.

Der sekundäre Kommunikationsanschluss m) verbindet die TCET ECU über LAN und/oder WAN mit der 'Außenwelt'. Der Kommunikationspfad m) ist normalerweise ausgelegt für "Plug- and-play"-Operationen, um dem Systemnutzer oder -bediener zu erlauben, neue Geräte zur Erweiterung der Systemfunktionen hinzuzufügen. Aus Gründen der Fehlertoleranz kann dieser Anschluss durch eine Vielzahl physischer Sender-Empfänger- Einheiten dargestellt werden.

Die externen Netzwerke (LAN, WAN) sind gewöhnlich Multi­ drop-Netzwerke, die es erfordern, dass C4 Entscheidungsfähigkeit (arbitration capability) bereitstellt, um Busrechte für C1/C2/C3-Kommunikation mit dem externen Netz zu erlangen.

Der CAP isoliert die externen Einheiten von den "inneren CSE"-Elementen. Aus der Sicht der Software ist die CAP- Funktion vergleichbar mit einem Leistungsverstärker, und sie ist deshalb unsichtbar.

TCET-Lösung - Zusammenfassung des Funktionsprinzips

Im Folgenden werden die Regeln definiert, wie gemäß den obigen Erläuterungen einzelne maßgeschneiderte logische Steuerelemente bestimmt und definiert werden, so dass sie genau die Funktionalität bereitstellen, die von jedem Anwendungs-/Aufgabengebiet erforderlich ist.

In Abhängigkeit von den Anforderungen des Zielsystems bilden die Steuerelemente C1, C2 und C3 die Funktionalität des Kernsystems. Diese Elemente werden typischerweise durch spezielle einzelne Prozessoren und/oder spezielle HW- Elemente und/oder Softwaremodule dargestellt. Das Steuerelement C4 funktioniert als 'Gemeinsamer Zugangspunkt' (CAP). C4 ist mit allen TCET-ECU-internen Steuerelementen auf der internen (primären) Seite verbunden und stellt Kommunikationsverbindungen zu ECU-externen Systemen und Erweiterungseinheiten auf der Sekundärseite zur Verfügung. In dieser Ausführung konzentriert das Steuerelement C4 die gesamte externe Systemkommunikation auf diesen einzelnen Zugangspunkt, was die möglicherweise unsichere Plug-and- play-Welt und die Risiken des Internetzuganges mit sich bringt.

Fig. 8 zeigt eine Zusammenfassung der vier Hauptsteuerelemente C1 bis C4 für die logische Darstellung und die physische Realisierung der speziellen Aufgaben, die zur Verfügung zu stellen sind.

Der SysMon (C1), der ComPro (C2) und der MMI/A (C3), die die allgemeine ECU-Funktionalität bereitstellen, sind in einem Kommunikationsdreieck angeordnet. Jedes Steuerelement ist einzeln mit den beiden jeweiligen Nachbarsteuerelementen verbunden.

Wenn man die externe ECU-Anschlussmöglichkeit herstellt, verbindet eine einzelne Kommunikationsverbindung, die jeweils für C1, C2 und C3 vorhanden ist, die TCET-internen Elemente über das CAP (C4) mit der Außenwelt, wodurch ein miteinander verbundenes Steuerelementsystem aufgebaut wird, das die Geometrie eines Tetraeders aufweist.

Diese Struktur ist wesentlich für die vorteilhaften Eigenschaften des TCET-Prinzips. Die Systemarchitektur konzentriert verwandte Aufgaben und Anwendungen auf spezifische optimierte Steuerelemente. Diese Aussage ist ein wichtiger Schlüssel, der es erlaubt, kostengünstige, außerordentlich leistungsfähige Systeme aufzubauen und funktionellen Aufwand zu vermeiden, was zu redundantem Code und Schaltungsaufbau führt. Weiterhin ist die TCET- Organisation für die ECU-interne und -externe Kommunikation wesentlich, die den Aufbau von Hochleistungssystemen unterstützt. Die TCET-Topologie ergibt die Möglichkeit einer simultanen Multipfad-Verbindung und überwindet somit Kommunikationsengpässe und liefert grundlegendes Fehlerbeseitigungspotential.

Zusätzlich ist diese Systemtopologie eine fundamentale Voraussetzung, die Ausführungsvarianten mit fehlertolerantem Systemverhalten bei Bedarf unterstützt.

Behandlung von Systemfehlern

Das Steuerelement C1 (SysMon) überwacht im Allgemeinen die Systemvitalität und steuert das Fehlerbeseitigungsverhalten des Systems. Die TCET-Systemarchitektur ist eine ideale Voraussetzung, die es erlaubt, eine umfassende Logistik für das Fehlerbeseitigungsverhalten zu realisieren. Da es bereits mit einer fehlertoleranten Kommunikationsstruktur ausgestattet ist, kann das Fehlerverhalten des Gesamtsystems sehr wirkungsvoll erweitert werden.

In einem weiten Bereich kann dies erreicht werden, indem möglicherweise kleine "Systemfehlerbehandlungs"-Testroutinen und Fehlerbeseitigungsroutinen zu jedem Steuerelement hinzugefügt werden, was es erlaubt, eine sehr wirksame Strategie für die Systemfehlerbeseitigung zu realisieren.

Techniken wie das Hinzufügen von redundanten Elementen und Untersystemen, wie sie ganz allgemein in Standard- Systemausführungen benutzt werden, werden durch das TCET- Prinzip auch unterstützt. Bei dieser Art fehlertoleranter Realisierungen ist die TCET-Topologie für kostengünstige Realisierungen noch vorteilhaft.

Ein Beispielszenario, das eine grundlegende fehlertolerante TCET-Ausführung zeigt, stellt sich wie folgt dar:
Der Kommunikationspfad iL_3, der ComPro mit MMI/A verbindet, ist aus irgendeinem Grund für einen gewissen Zeitraum unterbrochen oder blockiert.

Um diese Systemausfall-Situation zu überwinden, kann ein Algorithmus definiert werden, der alternative Kommunikationspfade benutzt, die vom TCET-Prinzip bereitgestellt werden. Dieses nachfolgende Bestimmen eines neuen Weges wird automatisch im Hintergrund eingeleitet und ist somit unsichtbar für die Grundanwendung, die zu diesem Zeitpunkt von dem ComPro und dem MMI/A ausgeführt wird.

Die alternativen Kommunikationspfade für dieses Beispiel sind:

iL_1 - iL_2 (1) oder iL_1 - aL3 - aL2 (2)

Bei dieser Art der Ausführung ist es am günstigsten, die Logistik für diese Routinen für alle einbezogenen Steuerelemente identisch zu realisieren.

Die Hauptvorteile sind ein sehr kostengünstiger Systemrahmen, der unterstützt und ermöglicht:

• - Kostenvorteil bei reduzierter Menge von Gesamthardware- Komponenten,
• - Reduzierte physikalische Größe,
• - Minimaler Leistungsverbrauch,
• - Grundlegende fehlertolerante Systemstruktur als Vorbedingung für die Unterstützung der Realisierung und von Fehlerbeseitigungsmechanismen,
• - Hohe Leistungsfähigkeit des Gesamtsystems durch reduzierte 'unkoordinierte' Systemredundanz,
• - Hohe Systemverfügbarkeit, kein typischer Systembus- Engpass blockiert das System,
• - Hohe Systemzuverlässigkeit,
• - Perfekte Hardware-Voraussetzung, die "Firewall"- Realisierungen unterstützt.

Im Allgemeinen kann die TCET-Architektur auch in den nachfolgend aufgelisteten Anwendungen benutzt werden, aber das System ist nicht sofort kompatibel zu de-facto- Standards, wie sie zum Beispiel aus der heutigen Personalcomputerwelt bekannt sind, da sie eine neue Art Systemarchitektur darstellt. Demzufolge müssten bestehende Betriebssysteme und Anwendungen (Software) portiert und übersetzt werden:

• - Hochleistungs-Computersysteme
• - Standard-Bürocomputersysteme (z. B. "Personal Computer")
• - sehr einfache/billige eingebettete Systeme
• - Spielcomputer

Fig. 9 zeigt als ein Beispiel ein Gesamtelektroniksystem, wie es typischerweise in heutigen Autos der oberen Klasse realisiert wird. Das Blockschaltbild zeigt eine TCET ECU, vernetzt/verbunden mit acht externen ECUs.

Die durch dieses Beispielsystem gelieferten Anwendungen sind Funktionen der Schnittstelle zum Menschen, Multimedia- Unterstützung sowie Funktionalität aus dem Fahrzeugbereich wie Fahrgastraum-Steuerfunktionen (Lichtsteuerung, Klimasteuerung, Motor- und Bremsenüberwachung und andere).

Die TCET ECU, gekennzeichnet als Kern-ECU (Core ECU), stellt dementsprechend typischerweise die Hauptverarbeitungsfunktionalität in diesem Systemszenario bereit.

An den Echtzeit-Zugriffsanschlüssen ist die TCET ECU (über ComPro, C2) mit den Echtzeitnetzwerken des Fahrzeugs verbunden, wie CAN_1 (z. B. Netzwerk im Fahrgastraum), CAN_2 (z. B. Diagnosenetzwerk), CAN_3 (z. B. Motornetzwerk) und anderen Bussen. Die von diesen Netzwerken gesammelten und gesteuerten Informationen sind beispielsweise die Motortemperatur, der Öldruck, der Ausfall des Bremslichtes und andere, die von HW-nahen ECU-Einheiten geliefert werden.

An der 'ungeschützten' Seite greift die TCET ECU auf die Systemkommunikationsverbindung über CAP (C4) zu. In diesem Beispiel ist die Verbindung durch zwei Bereiche gekennzeichnet. Der Bereich der 'lokalen Einheiten' sind ECUs in direkter physikalischer Nachbarschaft der Kern-ECU miteinander verbunden. Aus Kostengründen benutzt diese Netzwerkart billiges Kupfermaterial. Die Einheiten 1 bis 3 sind zum Beispiel Anzeigen, das Radiosystem oder ein Telefon.

Durch die 'sys-link Xtender'-Einheit wird dieses lokale System durch Verbindungen zu entfernten Systemeinheiten (wie CD-ROM-Player oder anderen, die sich beispielsweise im Kofferraum des Fahrzeugs befinden) erweitert. Die Netzwerkmedien, die die lokalen und die entfernten Einheiten verbinden, würden typischerweise eine optische Verbindung sein.

Claims (16)

1. Elektronisches Steuersystem für die Steuerung der Funktion eines Verarbeitungssystems, speziell in einem Automobil, dadurch gekennzeichnet, dass das elektronische Steuersystem eine Vielzahl von logischen Steuerelementen enthält, von denen jedes speziell so beschaffen ist, dass es spezielle Aufgaben erfüllt, wobei jedes Steuerelement mit jedem anderen Steuerelement kommunizieren kann.

2. Steuersystem nach Anspruch 1, worin vier logische Steuerelemente verwendet werden.

3. Steuersystem nach Anspruch 1, worin die Steuerelemente durch einzelne Prozessoren dargestellt sind.

4. Steuersystem nach Anspruch 1, worin die Steuerelemente durch spezifische Hardware-Elemente, nämlich Standard- µController, programmierbare oder firmware-gesteuerte Ablaufsteuerungen und Folgesteuereinheiten oder kombinatorische oder sequenzielle Boolesche logische Schaltkreise dargestellt sind.

5. Steuersystem nach Anspruch 1, worin die Steuerelemente durch eine einzelne CPU dargestellt sind.

6. Steuersystem nach Anspruch 1, worin die Steuerelemente durch Software dargestellt sind.

7. Steuersystem nach Anspruch 1, worin eines der logischen Steuerelemente als ein gemeinsamer Zugangspunkt funktioniert.

8. Steuersystem nach Anspruch 2, worin die Steuerelemente in einer Tetraedergeometrie angeordnet sind.

9. Steuersystem nach Anspruch 7, worin drei Steuerelemente direkte Verbindungsanschlüssen und einen Entscheidungs- Verbindungsanschluss besitzen, die mit dem Steuerelement verbunden sind, das als gemeinsamer Zugangspunkt funktioniert.

10. Steuersystem nach Anspruch 9, worin die Verbindungsanschlüsse vorzugsweise ein identisches Datenverbindungsprotokoll und/oder dessen physische Darstellung benutzen.

11. Steuersystem nach Anspruch 1, worin das Steuerelement 1 die spezifische Funktionalität von Systemunterstützungsanwendungen darstellt, Element 2 alle Anwendungen mit Echtzeitnetzwerken und direkten Hardwaresteuerungen abdeckt, Element 3 alle Anwendungen der Schnittstelle zum Menschen und die ECU-spezifischen Funktionalitäten ausführt und Element 4 als ein Netzwerkzugangspunkt zu ECU-externen Erweiterungseinheiten und zu lokalen Netzwerken (LAN) oder Weitnetzen (WAN) funktioniert.

12. Steuersystem nach Anspruch 11, worin die Systemunterstützungs-Anwendungen aus der Gruppe ausgewählt werden, die aus Stromversorgungs-Management, Aktivier- und Ruhesteuerung, Systemvitalitätsüberwachung und Systemfehlerbehandlung besteht.

13. Steuersystem nach Anspruch 11, worin die direkte Hardware aus der Gruppe gewählt ist, die aus Motoren, Relais und anderen Echtzeit-ECUs besteht.

14. Steuersystem nach Anspruch 11, worin die Anwendungen mit Schnittstelle zum Menschen aus der Gruppe gewählt sind, die aus physischer E/A, visueller E/A und Sprach- E/A besteht.

15. Steuersystem nach Anspruch 9, wobei die Entscheidungsverbindung die Standard-Buszugriffstechnik 'Collision Sense Multiple Access (CSMA)' verwendet.

16. Benutzung des Steuersystems aus einem der vorhergehenden Ansprüche in einem Automobil.