DE60220669T3

DE60220669T3 - System und verfahren zum vorladen einer bussteuerung mit einem befehlsplan

Info

Publication number: DE60220669T3
Application number: DE60220669.3T
Authority: DE
Inventors: Philip ELLERBROCK; Daniel KONZ; Marshall Watts
Original assignee: Boeing Co
Current assignee: Boeing Co
Priority date: 2001-04-26
Filing date: 2002-04-26
Publication date: 2020-11-19
Anticipated expiration: 2022-04-27
Also published as: WO2002088965A1; KR100656977B1; EP1390856B2; DE60220669D1; EP1390856A4; JP4236936B2; KR20040015153A; EP1390856B1; JP2005500593A; US7617330B2; DE60220669T2; US20040158616A1; EP1390856A1

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich im Allgemeinen auf Systeme und Verfahren zur Reduzierung der Arbeitslast eines Hostcomputers und insbesondere auf Systeme und Verfahren zum Vorladen einer Bussteuerung mit einem Befehlsplan, der ohne Unterbrechung des Hostcomputers, typischerweise in einer sich wiederholenden Weise ausgeführt werden kann und durch den Hostcomputer, wenn gewünscht, aktualisiert werden kann.
Hintergrund der Erfindung
Da Systeme wie z.B. Multimediaunterhaltungssysteme, Kommunikationssysteme, Prozesssteuerungssysteme und Diagnosesysteme, die in der Automobil- und Luftfahrtindustrie verwendet werden, immer komplexer werden, entsteht eine Notwendigkeit für zusätzliche Geräte entweder mit sich selbst oder mit einer Zentralsteuerung oder etwas Ähnlichem zu kommunizieren. Historisch gesehen umfassen diese Systeme eine dedizierte Verdrahtung, die sich zwischen den verschiedenen Bauteilen erstreckt, um die Kommunikation zwischen den Bauteilen zu unterstützen. Da Systeme immer stärker integriert worden sind und die Kommunikationsanforderungen angestiegen sind, kann die Menge der dedizierten Verdrahtung, die erforderlich wäre, schnell übermäßig groß werden. Dies gilt sowohl in Bezug auf den benötigten Raum zur Verdrahtung als auch in Bezug auf die Kosten der Verdrahtung und der damit einhergehenden Installation. Da sich die Menge der dedizierten Verdrahtung vergrößert, vergrößert sich darüber hinaus im Allgemeinen auch die Gesamtkomplexität des Systems und auch die Wahrscheinlichkeit, dass ein Teil der Verdrahtung möglicherweise während oder nach der Installation beschädigt oder gebrochen wird.
Netzwerkbusse als solche sind entwickelt worden, um einen gemeinsamen Kommunikationsweg zwischen einer Vielzahl von Geräten bereitzustellen. In Automobil- und Luftfahrtanwendungen zum Beispiel kann ein Netzwerkbus dazu verwendet werden, um verschiedene Komponenten zu überwachen und um Diagnose und Statusinformationen zu sammeln. In dieser Hinsicht können Diagnose- und Statusinformationen gesammelt und analysiert werden, die sich auf eine Beanspruchung, eine Beschleunigung, einen Druck und/oder eine Temperatur beziehen, denen die verschiedenen Komponenten ausgesetzt sind. Durch ein weiteres Beispiel wird nun eine Netzwerkbusarchitektur entwickelt, die die Kommunikation und die Versorgung mit Multimediainformationen der Insassen eines Fahrzeugs, wie z.B. ein Automobil, ein Minivan, ein SUV (Sport Utility Vehicle), ein Flugzeug, ein Boot oder Ähnliches, unterstützt. Vorteilhafterweise würde dieser Netzwerkbus die Audiosignale, umfassend fließende Audiosignale (Streaming-Audiosignale), die von einem Radio, einem Kassettenspieler, einem Kompaktdiskspielers und/oder Ähnlichem stammen, zu ausgewählten Lautsprechern oder zu Kopfhörerbuchsen überall im Fahrzeug transportieren. In ähnlicher Weise kann der Netzwerkbus Sprach- und Datenkommunikationen mit einem Zelltelefon unterstützen, das von einem Insassen des Fahrzeugs getragen wird, genauso wie Kommunikationen mit einem Laptop, einem tragbaren Rechengerät oder Ähnlichem. Ebenso kann der Netzwerkbus Videosignale, umfassend fließende Videosignale (Streaming-Videosignale), von einem Fernsehempfänger, einem Videokassettenspieler oder einer anderen Videoquelle zu einem oder zu mehreren Videomonitoren senden. Zusätzlich kann der Netzwerkbus Sensor- und Aktuatorsignale hin zu und weg von Bauteilen, wie z.B. Antriebsbauteile, passive Anschnallbauteile, Unfallvermeidungsbauteile, Drive-By-Wire-Bauteile oder Ähnlichem, senden.
Zusätzlich zu der Vielfalt der Bauteile, die mit einem Netzwerkbus verbunden sind, sind im Allgemeinen auch eine oder mehrere Kontrolleinheiten mit dem Netzwerkbus verbunden, um Daten von verschiedenen Bauteilen zu empfangen und um Befehle an die Bauteile zu senden. Unter anderem spezifizieren diese Befehle eine Weise, in der die verschiedenen Bauteile funktionieren, umfassend eine Weise, in der die verschiedenen Bauteile Informationen über den Netzwerkbus senden. Zusätzlich kann die Kontrolleinheit(en) Eingaben von einem Benutzer, wie z.B. einem Insassen des Fahrzeugs, empfangen. Diese Eingaben können z.B. einen Hinweis auf die Quelle(n) von den Signalen, die über den Netzwerkbus zu senden sind, als auch auf das Ziel der Signale umfassen.
In einem System arbeiten eine oder mehrere Bussteuerungen unter der Kontrolle eines oder in Verbindung mit einem Hostcomputer, der auch als Hostprozessor bekannt ist. Der Hostcomputer stellt typischerweise der Bussteuerung(en) die Befehle bereit, die über den Netzwerkbus zu übertragen sind. Im Gegenzug erhält der Hostcomputer eine Antwort der Netzwerkbauteile von der Bussteuerung(en). Der Hostcomputer kann die Aktivitäten von der Bussteuerung(en), die auf der zeitlichen Koordinierung der Befehle basiert, die von dem Hostcomputer zu der Bussteuerung(en) ausgegeben werden, koordinieren oder synchronisieren. Zusätzlich führt der Hostcomputer die Prozesskontrollalgorithmen durch, die eine Anzahl von systemweiten Operationen leiten, während er ebenfalls eine beträchtliche Menge an Datenanalysen und Datengewinnung durchführt, die von den Netzwerkbauteilen bereitgestellt werden. WO 94/08298 offenbart eine Methode zur Verbesserung von SCSI-Kontrolloperationen durch aktives Korrigieren der SCSI-Prozessorinstruktionen.
Wegen der verschiedenen Funktionen, die der Hostcomputer durchführen muss, kann der Hostcomputer im Ergebnis manchmal unfähig sein, der Bussteuerung(en) Befehle im Einklang mit dem gewünschten Plan bereitzustellen. In dieser Hinsicht werden die systemweiten Operationen, die von dem Hostcomputer durchgeführt werden, typischerweise als Operationen mit hoher Priorität gekennzeichnet, die durchgeführt werden müssen, auch wenn andere Funktionen abgeschaltet werden, die die Bereitstellung von Befehlen für die Bussteuerung(en) umfassen. Die Schwierigkeiten, die sich einem Hostcomputer stellen, werden von Systemen mit einer großen Bandbreite erschwert, da von dem Hostcomputer erwartet wird, häufiger mit der Bussteuerung(en) zu interagieren. Zusätzlich ist eine Anzahl von Systemen derart ausgebildet, dass sie zeitdeterministisch sind in der Hinsicht, dass die Netzwerkbauteile getriggert sind, eine Funktion durch Befehle auszuführen, die von der Bussteuerung(en) ausgegeben wurden. Da es häufig für ein Netzwerkbauteil wünschenswert ist, eine bestimmte Funktion auszuführen, so wie beispielsweise Probedaten zu einer bestimmten Zeit zu erhalten, gibt die Bussteuerung(en) vorzugsweise Befehle zu bestimmten Zeiten aus, um auch das Netzwerkbauteil für die Durchführung einer bestimmten Funktion zu triggern. Wenn die Arbeitslast des Hostcomputers mit größerer Bandbreite anwächst, wird es jedoch weniger wahrscheinlich sein, dass der Hostcomputer fähig ist, die Ausgabe von Befehlen an die Bussteuerung zeitlich zu koordinieren, so dass die Bussteuerung wiederum die Befehle auf dem Netzwerkbus in einer zeitdeterministischen Weise platzieren kann.
Z.B. kann das System ausgebildet sein, um Daten von einer Vielzahl von Sensoren mit einer vorbestimmten Abtastfrequenz zu sammeln. Da das Sammeln von Daten von den Befehlen getriggert ist, die von der Bussteuerung ausgegeben werden, müssen die Befehle, die von der Bussteuerung ausgegeben werden, mit derselben vorbestimmten Abtastfrequenz ausgegeben werden. Wenn der Hostcomputer unfähig ist, die Bussteuerung anzuweisen, die Befehle mit derselben vorbestimmten Abtastfrequenz auszugeben, wird das System als solches unfähig sein, Daten in Übereinstimmung mit dem gewünschten Plan zu beschaffen und daher werden die Daten eine signifikante Menge an Instabilitäten bezüglich der zeitlichen Koordination (Timing Jitter) enthalten, die in Amplituden- und Phasenverzerrungen resultiert.
In einem Versuch diese Nachteile zu behandeln, sind Hostcomputer mit schnelleren Prozessoren benutzt worden, die einen eingebetteten Software-Prozess oder ein Echtzeitoperationssystem enthalten. Während dieser Ansatz in einer zeitdeterministischen Art operieren kann, muss der Hostprozessor noch immer den Netzwerkverkehr zusammen mit der Durchführung seiner anderen Funktionen planen. Zusätzlich enthalten einige Systeme Protokoll-Kodierer und Dekodierer als einen Versuch, diese Nachteile zu bewältigen, aber diese Systeme erfordern noch immer die Planung des Netzwerkverkehrs. Daher erleichtert keiner dieser Ansätze den Hostcomputer um die Notwendigkeit den Netzwerkverkehr über die Bussteuerung(en) zu leiten. Es wäre daher wünschenswert die Arbeitslast des Hostcomputers zu verringern, so dass der Bussteuerung(en) Befehle in einer besser vorhersagbaren Art bereitgestellt werden können, wobei der Bussteuerung(en) erlaubt ist, Befehle in einer zeitdeterministischen Art auszugeben.
Zusammenfassung der Erfindung
Angesichts des zuvor genannten Hintergrundes stellt die vorliegende Erfindung ein verbessertes System und Verfahren zur Kommunikation mit mindestens einem Netzwerkbauteil über einen Netzwerkbus bereit. Das System und Verfahren der vorliegenden Erfindung verringert die Arbeitslast eines Hostcomputers, indem es der Bussteuerung erlaubt ist, Befehle in Übereinstimmung mit einem Befehlsplan (manchmal als ein Operationsplan bezeichnet) auszugeben, in einer Weise, die unabhängig von einem Hostcomputer ist. Dementsprechend kann der Hostcomputer eine Serie von Instruktionen zu der Bussteuerung übertragen, so dass die Bussteuerung mit einem Befehlsplan vorgeladen ist. Entsprechend einem Aspekt der vorliegenden Erfindung enthält das System einen Hostcomputer und eine Bussteuerung, die sich in elektrischer Kommunikation mit sowohl dem Hostcomputer als auch mit dem Netzwerkbus befindet. Die Bussteuerung enthält ein Speicherbauteil zur Speicherung einer Serie von Instruktionen und ist angepasst die Serie von Instruktionen, typischerweise wiederholend, in einer Weise unabhängig von dem Hostcomputer auszuführen, um die Kommunikation zu steuern, die über den Netzwerkbus geführt wird.
Daher wird eine Serie von Instruktionen zunächst von dem Hostcomputer zu der Bussteuerung übertragen, so dass die Bussteuerung mit einem Befehlsplan vorgeladen ist. Anschließend wird die Serie von Instruktionen typischerweise wiederholend, auf eine Art, die unabhängig von dem Hostcomputer ist, ausgeführt, um die Kommunikation zu kontrollieren, die über den Netzwerkbus zwischen der Bussteuerung und den Netzwerkbauteilen geführt wird. Da die Bussteuerung die Serie von Instruktionen ohne weitere Unterbrechung des Hostcomputers ausführen kann, ist es dem Hostcomputer erlaubt, andere Operationen gleichzeitig mit der Ausführung der Serie von Instruktionen von der Bussteuerung durchzuführen. Z.B. kann der Hostcomputer eine Datenanalyse und Systemoperationen durchführen, ohne dass er die Bussteuerung anweisen muss Befehle auszugeben. Zusätzlich kann die Bussteuerung durch das Vorladen der Bussteuerung mit einem Befehlsplan die Befehle in einer zeitdeterministischen Art ausgeben, um die Beschaffung von Daten und anderen Arten der Kommunikation über den Netzwerkbus in Übereinstimmung mit einem gewünschten Plan zu unterstützen.
Wie oben illustriert und diskutiert stellen die Systeme und Verfahren der vorliegenden Erfindung die Funktion bereit, deterministische Netzwerkprozesse ohne die Verwendung des Hostprozessors auszuführen. Insbesondere identifizieren die Systeme und Verfahren der vorliegenden Erfindung Instanzen, bei denen die Befehle, die von der Bussteuerung ausgegeben werden, netzwerkprotokollspezifisch und periodisch wiederholend sind (das ist eine Serie von Protokollbefehlen, die in periodischer Folge wiederholt wird). Die Systeme und Verfahren der vorliegenden Erfindung entfernen diese sich wiederholende Serie von Befehlen von den Operationen, die der Hostprozessor durchführen muss und laden die Befehle und Daten typischerweise in der Form von einer Serie von Instruktionen in einen Befehlsplan. Wie bisher beschrieben laden die Systeme und Verfahren der vorliegenden Erfindung jedoch nur Befehlspläne vor, die Serien von Befehlen und Daten enthalten, die sich während der Operation des Netzwerksystems nicht ändern. Es existieren allerdings einige Instanzen, bei denen eine dynamische Veränderung der Befehle oder Daten, die während der Durchführung des periodischen Befehlsplans in den Befehlplan gelistet werden, vorteilhaft ist, um dem Netzwerksystem zu erlauben, eine bessere Prozesskontrolle zu erreichen. Mit anderen Worten, es wäre vorteilhaft, einen vorgeladenen Befehlsplan mit Befehlen und Daten bereitzustellen, die während der Operation, basierend auf dem Prozess der mit dem Netzwerksystem verbunden ist, verändert oder aktualisiert werden können.
Vor diesem Hintergrund stellen das System und die Verfahren der vorliegenden Erfindung in einigen Ausgestaltungen Prozeduren bereit, die dem Hostprozessor erlauben, den Inhalt und die Ausführung des eingebetteten Befehlsplanes zu ändern und dabei eine bessere Prozesskontrolle bereitzustellen. Die Systeme und Verfahren der vorliegenden Erfindung ermöglichen der Hostkontrolleinheit Daten von dem Netzwerk zu empfangen und zu analysieren, analytische Ergebnisse zu berechnen und angemessene Prozessveränderungen zu produzieren, die wiederum als Befehle oder Argumente in den Befehlsplan eingefügt werden können. Obwohl der Hostprozessor die vorgeladenen Befehle und Daten des Befehlsplans in diesen Ausgestaltungen periodisch evaluieren und verändern muss, ist der Hostprozessor frei, Verarbeitungen höherer Level durchzuführen, da der Großteil der Verarbeitung in Übereinstimmung mit dem Befehlsplan durch die Bussteuerung durchgeführt wird.
Figurenliste
Nachdem nun die Erfindung mit allgemeinen Begriffen beschrieben wurde, werden nun die angehängten Zeichnungen referenziert, die nicht notwendigerweise maßstabsgetreu sind und wobei:

1 eine schematische Darstellung eines Systems entsprechend einer Ausgestaltung der vorliegenden Erfindung ist, die ein Paar von Bussteuerungen enthält, die mit gegenüberliegenden Enden eines Netzwerkbusses verbunden sind;
2 ein Blockdiagramm eines Systems entsprechend einer Ausgestaltung der vorliegenden Erfindung ist, welches einen Befehlsplan abbildet, der in eine Bussteuerung vorgeladen ist;
3 ein Blockdiagramm eines Systems entsprechend einer weiteren Ausgestaltung der vorliegenden Erfindung ist, in welcher die Bussteuerung, in der der Befehlsplan vorgeladen ist, unter der Kontrolle eines externen Takts operiert, die verwendet werden kann, um die Operationen der mehreren Bussteuerungen zu synchronisieren; und
4 eine schematische Darstellung eines Systems entsprechend einer weiteren Ausgestaltung der vorliegenden Erfindung ist, die eine Einzelbussteuerung enthält;
5 ein Blockdiagramm eines Systems entsprechend einer Ausgestaltung der vorliegenden Erfindung darstellt, welche die Operation des Sende-Daten-vom-Register-Befehls (Send-Data-From-Register-Befehls) gemäß einer Ausgestaltung der vorliegenden Erfindung abbildet; und
6 ein Blockdiagramm eines Systems entsprechend einer Ausgestaltung der vorliegenden Erfindung darstellt, welche die Operation des Absoluter-Sprung-vom-Register-Befehls (Absolute-Jump-From-Register-Befehls) gemäß einer Ausgestaltung der vorliegenden Erfindung abbildet.

Detaillierte Beschreibung der Erfindung
Die vorliegende Erfindung wird nun hiernach ausführlich mit Bezug zu den begleitenden Zeichnungen beschrieben, in welchen bevorzugte Ausgestaltungen der Erfindung dargestellt sind. Diese Erfindung kann allerdings auf viele verschiedene Arten ausgestaltet werden und sollte nicht als zu den Ausgestaltungen limitiert interpretiert werden, die im Folgenden dargestellt sind; diese Ausgestaltungen sind eher beschrieben, damit diese Offenbarung genau und vollständig ist und damit sie den Rahmen der Erfindung den Fachleuten vollständig übermittelt. Gleiche Bezugszeichen beziehen sich durchweg auf gleiche Elemente.
Bezugnehmend auf 1 wird nun ein System 10 gemäß einer ersten Ausgestaltung der vorliegenden Erfindung dargestellt. Während mehrere Ausgestaltungen des Systems dargestellt sind und nun mit der Absicht ein Beispiel zu geben beschrieben werden, können andere Systemtypen die vorliegende Erfindung nutzen. Darüber hinaus wird das System und Verfahren der vorliegenden Erfindung zunächst im Zusammenhang mit Automobil- und Luftfahrtanwendungen beschrieben. Beispielsweise sind Automobil- und Luftfahrtanwendungen ausgebildet, Kommunikationen und die Bereitstellung von Multimediainformationen an die Insassen eines Fahrzeugs zu unterstützen und/oder verschiedene Komponenten zu überwachen und Diagnose- und Statusinformationen zu sammeln und/oder für Prozesskontrollanwendungen wie sie bei Motorsteuerungen, Getriebesteuerungen, Drive-or-Brake-by-Wire-Systemen, etc., Anwendung finden. Allerdings kann das System und Verfahren der vorliegenden Erfindung in Verbindung mit einer Vielzahl von anderen Anwendungen in den Automobil- und/oder Luftfahrtindustrien und/oder außerhalb dieser Industrien verwendet werden. Z.B. kann das System und Verfahren in der industriellen Automation und in Bodenprüfungen verwendet werden.
Wie in 1 gezeigt umfasst das System 10 einer Ausgestaltung einen Netzwerkbus 12, der eine erste Bussteuerung 14, eine zweite Bussteuerung 16 und eine Vielzahl von Netzwerkbauteilen 18. Die Bussteuerungen sind mit dem Netzwerkbus elektrisch verbunden. In der illustrierten Ausgestaltung sind die erste und zweite Bussteuerung zusammen platziert, so dass der Netzwerkbus einen Kreis zwischen dem Paar von Bussteuerungen bildet. Es ist ersichtlich, dass die Bussteuerungen an verschiedenen Positionen im Netzwerk platziert werden können. Das in 1 abgebildete System enthält ebenfalls eine Vielzahl von Netzwerkbauteilen 18, die an verschiedenen Punkten entlang des Netzwerkbusses mit dem Netzwerkbus elektrisch verbunden sind und damit auch mit den Bussteuerungen. Damit unterstützt der Netzwerkbus die Kommunikation zwischen den Bussteuerungen und den Netzwerkbauteilen genau so wie die Kommunikationen zwischen den Netzwerkbauteilen selbst.
Die Bussteuerungen 14 und 16 sind so ausgebildet, dass sie Befehle an jeweilige Netzwerkbauteile 18 ausgeben und in zumindest einigen Fällen Daten von Netzwerkbauteilen empfangen. Zum Beispiel können die Befehle vorschreiben, dass ein Netzwerkbauteil einen bestimmten Datentyp bereitstellt wie z. B. Statusdaten oder andere Diagnosedaten. Andererseits können die Befehle, die von den Bussteuerungen ausgegeben werden eine oder mehrere der Netzwerkbauteile anweisen Signale eines vorbestimmten Typs, wie z. B. Audiosignale, Videosignale oder Ähnliche, bereitzustellen und für ein oder mehrere der anderen Netzwerkbauteile Signale zu empfangen. Obwohl verschiedene Typen von Bussteuerungen verwendet werden können, ist eine vorteilhafte Art einer Bussteuerung die Netzwerksteuerung, die in der US-Patentanmeldung, Nummer 09/736,878 , mit dem Titel „Network Controller for digitally controlling network devices via a common bus“, angemeldet am 14. Dezember 2000, beschrieben ist.
Wie in der US-Patentanmeldung, Nummer 09/736,878 , beschrieben und wie in 1 illustriert, befinden sich die Bussteuerungen 14 und 16 im Allgemeinen ebenfalls in elektrischer Kommunikation mit einem Hostcomputer 20, der auch als Hostprozessor bezeichnet wird, der im Allgemeinen die Operation der Bussteuerungen leitet. Zum Beispiel leitet der Hostcomputer in einem konventionellen System die Ausgabe von Befehlen der Bussteuerungen genauso wie die zeitliche Koordination der Befehle. Zusätzlich kann der Hostcomputer die Daten, die die Bussteuerungen von den Netzwerkbauteilen empfangen, gewinnen oder auch analysieren und er kann eine Zahl von anderen systemweiten Operationen mit hoher Priorität durchführen. Zusätzliche Einzelheiten, die sich auf die Interaktion und entsprechende Funktionen der Bussteuerungen und des Hostcomputers beziehen, werden nun beschrieben.
Während einer gewöhnlichen Operation des Systems 10, das in 1 dargestellt ist, dient die erste Bussteuerung 14 typischerweise als Mastersteuerung und ist verantwortlich für die Ausgabe von Befehlen über den Netzwerkbus 12. Die erste Bussteuerung arbeitet ebenfalls als erster Monitor des Netzwerkbusses und kann Antworten empfangen, die von den Netzwerkbauteilen 18 bereitgestellt werden.
Verschiedene Typen von Netzwerkbussen 12 können verwendet werden. Typischerweise enthält der Netzwerkbus eins, zwei, drei oder mehr Drahtpaare, wie z. B. differentielle, verdrillte Kupferdrahtleitungen, zur Übertragung von Befehlen, Daten oder anderen Signalen. Der Netzwerkbus als solcher kann so ausgestaltet sein, dass er entweder eine Standardhalbduplexkonfiguration über ein Drahtpaar oder eine Vollduplexkonfiguration über zwei Drahtpaare unterstützt. In einigen Ausgestaltungen, die für synchronen Betrieb ausgebildet sind, kann eines der Drahtpaare für die Übertragung eines Taktsignals, typischerweise von einer Bussteuerung zu den Netzwerkbauteilen 18, verwendet werden. Weiterhin kann der Netzwerkbus für die Spannungsversorgung ein Drahtpaar und einen gewöhnlichen Erdanschluss für die Netzwerkbauteile umfassen.
Das System 10 kann eine breite Auswahl von Netzwerkbauteilen 18 umfassen; die meisten, wenn nicht alle von ihnen, liegen entfernt von den Bussteuerungen. Zum Beispiel können die Netzwerkbauteile Sensoren umfassen, die den Bussteuerungen und wiederum dem Hostcomputer 20 Daten zur Verfügung stellen, wie z. B. Status- oder Diagnosedaten, so dass die Funktionsfähigkeit und/oder die Operation von was immer die Sensoren wahrnehmen überwacht werden kann. Zum Beispiel können in einer Automobilanwendung die Netzwerkbauteile Sensoren für die Überwachung der Drosselposition, des Öldrucks, der Wassertemperatur, des Übertragungsflüssigkeitsdrucks, der Sitzposition, des Antiblockierbremssystems, der Aufhängung, des passiven Rückhaltesystems und des Lenksystems, um nur ein paar wenige zu nennen, umfassen. Um dem Benutzer eine Rückmeldung zu geben, können die Netzwerkbauteile ebenso ein oder mehrere Displays umfassen, wie z. B. das Armaturenbrettdisplay in einem Fahrzeug, um Status- oder Diagnosedaten entweder direkt oder nach zweckmäßiger Verarbeitung darzustellen. Andererseits können die Netzwerkbauteile einen Aktuator umfassen, der eine bestimmte Funktion als Antwort zu einem Befehl der Bussteuerung durchführt.
In der Automobilanwendung z. B. können die Netzwerkbauteile Aktuatoren zur Kontrolle der Drosselposition, des Antiblockierbremssystems, der Aufhängung, des passiven Rückhaltesystems und des aktiven Aufhängungssystems, um nur ein paar zu nennen, umfassen. Weiterhin können die Netzwerkbauteile eine Audio- oder Videoquelle umfassen. Dementsprechend können die Netzwerkbauteile Radioempfänger, Kassettenspieler, Kompaktdiskspieler, zellulare Telefonempfänger oder andere Audioquellen umfassen, um Kontrollsignale und Audiosignale, die in einigen Fällen fließende Audiosignale umfassen, dem Netzwerkbus bereitzustellen. Entsprechend können die Netzwerkbauteile Lautsprecher, Kopfhörerbuchsen oder Ähnliches für den Empfang von Audiosignalen von dem Netzwerkbus und für die Bereitstellung einer entsprechenden hörbaren Ausgabe umfassen. Genauso können die Netzwerkbauteile einen Fernsehempfänger, einen Videokassettenspieler oder andere Videoquellen umfassen, um dem Netzwerkbus Videosignale, umfassend fließende Videosignale, bereitzustellen. Entsprechend können Netzwerkbauteile einen Videomonitor oder Ähnliches zum Empfang von Videosignalen und zur bildbasierten Darstellung von Videosignalen umfassen.
Während die Netzwerkbauteile 18 direkt mit dem Netzwerkbus 12 verbunden sein können, sind die Netzwerkbauteile einer vorteilhaften Ausgestaltung mit den jeweiligen Netzwerkbauteilschnittstellen 22 verbunden, wie beschrieben durch die US-Patentanmeldung, Nummer 09/735,146 , mit dem Titel „Network Device Interface for Digitally Interfacing Data Channels to a Controller via a Network“, angemeldet am 12. Dezember 2000. In dieser vorteilhaften Ausgestaltung ist die Netzwerkbauteilschnittstelle für das Übertragen von Signalen zu dem Netzwerkbus und für den Empfang von Signalen von dem Netzwerkbus in elektrischer Kommunikation mit dem Netzwerkbus angeordnet. Jede Netzwerkbauteilschnittstelle befindet sich ebenso über entsprechende Datenkanäle in Kommunikation mit einem oder mit mehreren Netzwerkbauteilen. Während jede Netzwerkbauteilschnittstelle entsprechend 1 mit einem einzelnen Netzwerkbauteil verbunden ist, könnte eine Netzwerkbauteilschnittstelle mit zwei oder mehreren Netzwerkbauteilen verbunden werden, wenn gewünscht. Wie beschrieben in der US-Patentanmeldung, Nummer 09/735,146 , führt eine Netzwerkbauteilschnittstelle verschiedene Funktionen aus, um Kommunikationen des Netzwerkbauteils über den Netzwerkbus zu ermöglichen. Zum Beispiel kann eine Netzwerkbauteilschnittstelle Daten speichern, die von dem verbundenen Netzwerkbauteil(en) gesammelt wurden, so dass die gespeicherten Daten den Bussteuerungen 14 und 16 bei einer Anfrage über den Netzwerkbus zur Verfügung gestellt werden können. Wenn das Netzwerkbauteil ein analoges Bauteil ist, kann die Netzwerkbauteilschnittstelle die Signale zwischen dem digitalen Format, das von dem Netzwerkbus unterstützt wird, und dem analogen Format umwandeln, das von dem Netzwerkbauteil unterstützt wird.
Nach der Initialisierung des Systems 10 inventarisiert die erste Bussteuerung 14 die Netzwerkbauteile 18, die mit dem Netzwerkbus 12 verbunden sind, und ordnet jedem Netzwerkbauteil eine eindeutige, logische Adresse zu, so dass die Bussteuerungen mit einem bestimmten Netzwerkbauteil oder einer bestimmten Gruppe von Netzwerkbauteilen kommunizieren können. Eine breite Auswahl von Techniken zur Inventarisierung der Netzwerkbauteile, die mit dern Netzwerkbus verbunden sind und zur Zuordnung von eindeutigen logischen Adressen zu den Netzwerkbauteilen kann verwendet werden. Eine vorteilhafte Technik für das Inventarisieren der Netzwerkbauteile und das Zuordnen von eindeutigen, logischen Adressen ist die Bittkonkurrenztechnik (Bit Competition Technique), die durch die US-Patentanmeldung, Nummer 09/735,146 , genauso wie durch die provisorische US-Patentanmeldung, Nummer 60/286,793 , mit dem Titel „Systems and Methods for Assigning an Address to a Network Device Added to an Existing Network“, angemeldet am 26. April 2001, und die PCT-Patentanmeldung, Nummer , mit dem Titel „Systems and Methods for Assigning an Address to a Network Device Added to an Existing Network“, die gleichzeitig mit dieser Anmeldung angemeldet wurde, beschrieben ist.
Im Betrieb gibt die erste Bussteuerung 14 verschiedene Befehle aus und die jeweiligen Netzwerkbauteile 18 antworten basierend auf diesen Befehlen. Die Bussteuerung und die Netzwerkbauteile können entsprechend verschiedener Protokolle kommunizieren. Wie z. B. in der US-Patentanmeldung, Nr. 09/736,878 , beschrieben, können die Bussteuerungen und die Netzwerkbauteile entsprechend einem Manchester-kodiertem Zweiphasen-Sensor-und-System-Protokoll (BiSenSys) kommunizieren. Alternativ können die Bussteuerungen und die Netzwerkbauteile entsprechend einem Protokoll, das kompatibel mit einer universellen, asynchronen physikalischen Empfänger-Sender-Schicht (UART, universal asynchronous receiver transmitter pysical layer) kommunizieren. Vorzugsweise jedoch wird das Protokoll ausgewählt, um den Aufwand zu minimieren und die Datentransferfähigkeit entsprechend zu maximieren. Weiterhin wird das Protokoll vorzugsweise so ausgewählt, dass es relativ einfach ist, so dass weder die Netzwerkbauteile noch die Netzwerkbauteilschnittstellen 22 einen Prozessor auf hoher Ebene benötigen. Stattdessen können die Bussteuerungen und der verbundene Hostcomputer 20 den Großteil der Verarbeitungsleistung beinhalten und die Netzwerkbauteilschnittstellen können Logik beinhalten, die fertig in Hardware, Software oder Firmware implementiert ist. Die Kommunikationen, die von dem System 10 unterstützt werden, können auch entweder synchron oder asynchron sein und können die Übertragung von verschiedenen Arten von Nachrichten involvieren. Wie z. B. in der US-Patentanmeldung, Nr. 09/736,878 , beschrieben basiert eine vorteilhafte Kommunikationstechnik auf der Übertragung von Nachrichtenrahmen, die Befehlsrahmen und Datenrahmen enthalten, die jeweils eine vorbestimmte Länge oder Größe haben.

Abhängig von dem Protokoll kann das System auch verschiedene Befehlssätze unterstützen. So wie das Protokoll ist der Befehlssatz vorzugsweise so auszuwählen, dass der Aufwand minimiert wird, der über den Netzwerkbus übertragen werden muss, und dass es relativ einfach ist. Ein Beispiel eines geeigneten Befehlssatzes ist in der US-Patentanmeldung, Nr. 09/735,146 , beschrieben und ist unten nachgebildet.

Befehl (hex)	Befehlsbeschreibung
Servicebefehle
00	Keine Operation (No Op)
01	Eingebauter Test (Built in Test) -
02	Zurücksetzen (Reset)
03	Lies-Status-Register (Read Status Register)
04	Bauteil-Inventarisierung-Ein (Device Inventory Enable)
05	Bauteil-Inventarisierung (Device Inventory)
06	Kontroll-Übergabe (Control Pass)
07	Wach-auf (Wake)
08	Schlaf (Sleep)
09	E-Kallibrierung (E-Calibration)
0A	Z-Kallibrierung (Z-Calibration)
0B	Synchroniziere (Synchronize)
0C	Baud-Auswahl (Baud Select)
0D	Setze-Quelle (Set Source)
0E	Füge-Terminierung-ein (Insert Terminator)
0F	Reserviert (reserved)

Datenbefehle
20	Trigger (Trigger)
21	Trigger-und-Impuls (Trigger and Pip)
22	Trigger-und-Lesen (Trigger and Read)
23	Lese-Eingangsdaten-Register- Wort (Read In-Data Register Word)
24	Lese- Eingangsdaten-Stapel-Wort (Read In-Data Stack Word)
25	Lese-Eingangsdaten-Stapel-Doppel-Wort
	(Read In-Data Stack Double Word)
26	Lese- Eingangsdaten-Stapel- Block-ein (Read In-Data Stack Block)
2.7	Abfrage-Eingangsdaten-Ausgangsdaten-Stapeltiefe (Query In-Data/ Out-Data Stack Depth)
28	Schreibe-Ausgangsdaten-Stapelwort (Write Out-Data Stack Word)
29	Schreibe-Ausgangsdaten-Stapelwort / Beschaffen-zu-Eingangsdaten-Register (Write Out-Data Stack Word / Acquire to In-Data Register)
2A	Schreibe-Ausgangsdaten-Stapel- Block (Write Out-Data Stack Block)
2B-2F	Reserviert (Reserved)

Speicherbefehle
30	Setze-Speicher-Pfeil (Set Memory Pointer)
31	Lese-Speicher- Wort-mit-aktuellem-Pfeil (Read Memory Word with Current Pointer)
32	Lese-Speicher- Block-mit-aktuellem-Pfeil (Read Memory Block with Current Pointer)
33	Schreibe-Speicher-Wort-mit-aktuellem-Pfeil (Write Memory Word with Current Pointer)
34	Schreibe-Speicher-Block -mit-aktuellem-Pfeil (Write Memory Block with Current Pointer)
35	Lese-Speicher-Wort-mit-übergebenem-Pfeil (Read Memory Word with Passed Pointer)
36	Lese-Speicher- Block-mit-übergebenem-Pfeil (Read Memory Block with Passed Pointer)
37	Schreibe-Speicher- Wort-mit-übergebenem-Pfeil (Write Memory Word with Passed Pointer)
38	Schreibe-Speicher- Block-mit-übergebenem- Pfeil (Write Memory Block with Passed Pointer)
39-7F	Reserviert (Reserved)

Eine Ebene von Befehlen sind die Servicebefehle. Servicebefehle werden für die Netzwerkorganisation, den Netzwerkbauteilschnittstellenstatus, die Leistungskontrolle, die Kalibrierung und die Entscheidung des Busmasters verwendet. Eine zweite Art von Befehlen sind die Datentypenbefehle. Diese Befehle sind für die zeitdeterministische Datenbeschaffung und die Kontrolle zugeschnitten. Netzwerkeffizienz wird maximiert, indem den Netzwerkbauteilen erlaubt wird, eine oder mehrere Datenpunkte oder mehr als ein Datenpunkt als Blockübertragung mit definierter Länge direkt zu bewegen. Beispielsweise wird der Trigger-Befehl von den Bussteuerungen verwendet, um eine ankommende Datenmessung eines Sensors zu veranlassen oder um eine Datenumwandlung einer physikalischen Größe für einen Aktuator zu verursachen.
Zusätzlich zu den Service- und Datentypenbefehlen enthält der Befehlssatz in diesem Beispiel auch Speicherbefehle. Diese Befehle erlauben den Zugriff auf spezifisch definierte Speicherplätze oder Funktionen, auf die Daten geschrieben oder aus denen Daten ausgelesen werden können. Diese erlaubt, dass zufällige Zugriffsdatenblöcke effizient zwischen einem und einem anderen System mit geringem Aufwand übertragen werden können. Das erlaubt ebenfalls den direkten Speicherzugriff und/oder das Bewegen von einem oder von mehreren Datenpufferblöcken. Weitere Einzelheiten bzgl. des Befehlssatzes werden in der US-Patentanmeldung, Nummer 09/735,146 , genauso wie in der provisorischen US-Patentanmeldung, Nummer 60/286,644 , mit dem Titel „System and Method for Reestablishing the Impedance Stability of a Network Bus“, in der provisorische US-Patentanmeldung, Nummer 60/286,759 , mit dem Titel „System, Methods and Bus Controllers for Creating an Event Trigger on a Network Bus“, beide angemeldet am 26. April 2001, und in der PCT-Patentanmeldung, Nummer PCT/US 02/13367, mit dem Titel „Systems and Methods for Maintaining Network Stability“ und in der PCT Patentanmeldung, Nr. PCT/US 02/13303, mit dem Titel „Systems, Methods and Bus Controllers for Creating an Event Trigger on a Network Bus“, die beide gleichzeitig hiermit angemeldet sind, bereit gestellt. Die Inhalte von all diesen Anmeldungen sind in ihrer Gesamtheit ebenfalls hier eingebunden.
Entsprechend der vorliegenden Erfindung wird die Bussteuerung 14 und insbesondere ein Speicherbauteil 24, das mit der Bussteuerung verbunden ist, mit einer Serie von Instruktionen vorgeladen, die als Mikrocode bezeichnet wird, wobei ein Befehlsplan (manchmal bezeichnet als ein Operationsplan) gebildet wird (siehe z. B. 2). Während die Serie von Instruktionen auf verschiedene Arten bereit gestellt werden kann, lädt der Hostcomputer 20 typischerweise das Speicherbauteil der Bussteuerung mit der Serie von Instruktionen vor. Die Bussteuerung kann danach die Serie von Instruktionen ohne weitere Unterbrechung oder Anleitung durch den Hostcomputer ausführen. Es ist dem Hostcomputer entsprechend erlaubt einen größeren Prozentsatz seiner Verarbeitungszeit und Leistung für andere Funktionen zu verwenden, die systemweite Operationen und Datenanalyse beinhalten. Darüber hinaus kann die Bussteuerung durch das Vorladen einer Serie mit Instruktionen (das ist der Befehlsplan) in die Bussteuerung sicherstellen, dass verschiedene Befehle auf dem Netzwerkbus zu vorbestimmten Zeiten platziert werden, wobei die zeit-deterministische Operation des Systems 10 erlaubt wird.
Während jede Serie von Instruktionen in die Bussteuerung 14 vorgeladen werden kann, lädt das System 10 einer vorteilhaften Ausgestaltung eine Serie von Instruktionen vor, die wiederholt ausgeführt wird. Deshalb kann eine relativ kleine Serie von Instruktionen in die Bussteuerung vorgeladen werden und von der Bussteuerung wiederholt ausgeführt werden, um die Kommunikation über den Netzwerkbus 12 für eine substanzielle Zeitdauer zu kontrollieren, wobei der Hostcomputer 20 für andere Funktionen befreit wird. Obwohl eine wiederholende Serie von Instruktionen in die Bussteuerung vorgeladen wird und von der Bussteuerung wiederholt ausgeführt wird, muss der Hostcomputer möglicherweise gelegentlich zusätzliche Instruktionen bereitstellen, um die Bussteuerung anzuweisen, Funktionen auszuführen, die anders als jene sind, die in der vorgeladenen Serie von Instruktionen aufgenommen sind. Sogar in diesem Beispiel wird jedoch die Arbeitslast des Hostcomputers substanziell verringert und die Zuverlässigkeit, mit der die Bussteuerung auf eine zeitdeterministische Art operieren kann, ist vergrößert.
Typischerweise wird die Serie von Instruktionen in die Bussteuerung 14 entweder vor oder während der Laufzeit der Bussteuerung vorgeladen. In Ausgestaltungen, bei denen das Speicherbauteil 24, welches die Serie von Instruktionen speichert, nicht flüchtiger Speicher ist, kann die Bussteuerung beginnen die Befehle auf Einschalten oder auf Anweisung des Hostcomputers 20 ausführen. Alternativ muss in Ausgestaltungen, bei denen das Speicherbauteil flüchtiger Speicher ist, der Computer die Serie von Instruktionen nach dem Einschalten und bevor die Bussteuerung mit der Ausführung der Befehle beginnt in die Bussteuerung laden.
Die Serie von Instruktionen kann eine Vielfalt von Mikrocode-Befehlen enthalten, von denen einige entsprechende Datenfelder haben können. Beispielhaft wird jedoch ein Satz von Mikrocode-Befehlen nachfolgend beschrieben. In dieser exemplarischen Ausgestaltung beinhalten die Mikrocode-Befehle einen Zurücksetzen-Befehl (Reset-Befehl), um die Ausführung der Serie von Instruktionen zu einer Adresse des Speicherbauteils 24 zurückzusetzen, die mit Null bezeichnet wird. Wie in 2 angedeutet, werden die Serien von Instruktionen im Allgemeinen in das Speicherbauteil geladen, so dass der erste Befehl sich an der Speicheradresse von Null befindet. Damit verursacht der Zurücksetzen-Befehl im Wesentlichen, dass die Ausführung der Serie von Instruktionen erneut mit dem ersten Befehl beginnt. Wie später ersichtlich wird, ist der Zurücksetzen-Befehl nur gültig, wenn dass Speicherbauteil, das mit der Bussteuerung verbunden ist, Mikrocode-Befehle enthält, wobei keine Aktion unternommen wird, wenn das Speicherbauteil keinen Mikrocode-Befehle enthält.
Die Mikrocode-Befehle enthalten auch einen Pause-Befehl für das pausieren der Ausführung der Serie von Instruktionen. Im Anschluss an den Pause-Befehl kann die Operation als Antwort auf den Eingang eines vorbestimmten Signals wieder aufgenommen werden. Ein anderer Mikrocode-Befehl ist der Verzögerung-Befehl (Delay-Befehl), der eine Zeitverzögerung zwischen Mikrocodes einfügt, die über den Netzwerkbus 12 ausgegeben werden. Obwohl weder der Zurücksetzen- noch der Pause-Befehl ein entsprechendes Datenfeld haben, spezifiziert das Datenfeld, das mit dem Verzögerung-Befehl korrespondiert die Menge der Verzögerung, (typischerweise gemessen in Nanosekunden) die einzufügen ist.
Ein anderer Mikrocode-Befehl ist der Antwort-Verzögerung-Befehl (Response-Delay-Befehl). Der Antwort-Verzögerung-Befehl fügt eine Verzögerung zwischen Mikrocodes ein, die über den Netzwerkbus 12 ausgegeben werden, was aus organisatorischen Gründen eine Antwort zu dem unverzüglich vorangehenden Mikrocode erlaubt, die von einem Netzwerkbauteil 18 bereitgestellt wird. Für alle weiteren Verzögerungen wird der Verzögerung-Befehl verwendet. Ein Datenfeld, das mit dem Antwort-Verzögerung-Befehl verbunden ist, spezifiziert die Anzahl von Datenbytes der Verzögerung. Deshalb wird die tatsächliche Verzögerungszeit von der Baud-Rate abhängen, mit der Kommunikationen über den Netzwerkbus durchgeführt werden.
Die Mikrocode-Befehle enthalten auch einen Sende-Befehl, der die Bussteuerung 14 anweist, Befehle über den Netzwerkbus 12 zu übertragen. Der Befehl, der über den Netzwerkbus übertragen wird, ist durch ein Datenfeld definiert, das mit der Senden-Befehlsinstruktion verbunden ist. Wie beispielsweise unten beschrieben ist, kann der Sende-Befehl anweisen, dass ein Lese-Befehl oder ein Schreib-Befehl über den Netzwerkbus gesendet wird. In diesen Beispielen würde das Datenfeld als solches, welches mit dem Sende-Befehl verbunden ist, ebenfalls die Adresse des Netzwerkbauteils 18 identifizieren, an welche der Befehl geleitet wird. Typischerweise ist ein Paritätsbit nicht in dem Datenfeld enthalten, aber es wird von der Bussteuerung nach der Übertragung des Befehls über den Netzwerkbus automatisch berechnet und angehängt. Ebenso enthalten die Mikrocode-Befehle auch einen Sende-Daten-Befehl (Send-Data-Befehl) , um einem Datenrahmen die Übertragung über den Netzwerkbus, typischerweise von einem Netzwerkbauteil zu der Bussteuerung, zu erlauben, wobei der Datenrahmen, der zu übertragen ist, in dem Datenfeld definiert ist, das mit den Sende-Daten-Befehl verbunden ist. Wie bei dem Sende-Befehl ist das Paritätsbit nicht in dem verbundenen Datenfeld enthalten, sondern wird eher automatisch berechnet und durch die Bussteuerung zu der Zeit der Übertragung des Befehls über den Netzwerkbus angehängt.
Der Mikrocode-Befehlssatz dieser exemplarischen Ausgestaltung enthält auch einen Absoluter-Sprung-Befehl (Absolute-Jump-Befehl), der verursacht, dass die Ausführung der Serie von Instruktionen zu einer Speicheradresse springt, die durch das verbundene Datenfeld definiert ist. So wie der Zurücksetzen-Befehl ist der Absoluter-Sprung-Befehl nur gültig, wenn das Speicherbauteil 24, das mit der Bussteuerung 14 verbunden ist, Mikrocode-Befehle enthält, wobei keine Aktion auftritt, wenn das Speicherbauteil keine Mikrocode-Befehle enthält. Zum Schluss können die Mikrocode-Befehle einen Echo-Daten-Befehl (Echo-Data-Befehl) enthalten, der einen Datenrahmen über den Netzwerkbus 12 unter Verwendung von Daten überträgt, die sich aktuell in einem Empfangspuffer der Bussteuerung befinden (nicht gezeigt). Wenn der Empfangspuffer keine Daten enthält oder wenn die Daten in dem Puffer nicht gültig sind, wird der Echo-Daten-Befehl ausgelassen und keine Daten werden über den Netzwerkbus übertragen. Wie zuvor wird das Paritätsbit automatisch berechnet und durch die Bussteuerung während der Übertragung von dem Datenrahmen über den Netzwerkbus angehängt.

Obwohl der Mikrocode-Befehlssatz dieser exemplarischen Ausgestaltung oben beschrieben wurde, wird eine Zusammenfassung des Mikrocodebefehlssatzes und der verbundenen Datenfelder in der folgenden Tabelle bereit gestellt:

Mikrocode-Befehl	Datenfeld
Zurücksetzen (Reset) .	Datenfeld wird nicht verwendet
Pause (Pause)	Datenfeld wird nicht verwendet
Verzögerung (Delay)	Spezifiziert Anzahl von Busdatenbits einer Verzögerung
Antwort-Verzögerung (Response Delay)	Spezifiziert Anzahl von Busdatenbits einer Verzögerung
Sende-Befehl (Send Command)	Daten für zu sendenden Befehlsrahmen (Parität nicht enthalten)
Sende-Daten (Send Data)	Daten für zu sendenden Befehlsrahmen (Parität nicht enthalten)
Absoluter-Sprung (Absolute Jump)	Adresse des Sprungortes
Echo-Daten Echo Data	Datenfeld wird nicht verwendet

Abhängig von den Operationen, die die Bussteuerung 14 durchführt, werden eine vordefinierte Serie von Instruktionen, die aus Mikrocode-Befehlen und verbundenen Datenfeldern bestehen in das Speicherbauteil 24 geladen, das mit der Bussteuerung verbunden ist. Der Einsatz von Mikrocode-Befehlen und Datenfeldem wird in 2 illustriert. Wie gezeigt wird die Serie von Instruktionen beginnend mit der Speicheradresse Null gespeichert, obwohl die Instruktionen an anderen Orten gespeichert werden können, wenn dies gewünscht ist. Nach dem Beginn von Operationen führt die Bussteuerung den ersten Mikrocode-Befehl aus, welcher ein Sende-Befehl ist Der Sende-Befehl hat ein verbundenes Datenfeld, das den Befehl, der über den Netzwerkbus 12 übertragen wird, als einen Trigger-Befehl definiert. Danach wird ein anderer Sende-Befehl, für das verbundene Datenfeld bereit gestellt, das den zu sendenden Befehl als ein Lese-Befehl für das Netzwerkbauteil mit der Adresse 1 definiert (bezeichnet mit N1 in 2), dann wird der Antwort-Verzögerungs-Befehl (Response-Delay-Befehl) ausgeführt, um dem Netzwerkbauteil N1 eine Gelegenheit zu geben, Daten auf den Netzwerkbus 12 zu lesen, die mit w bezeichnet sind, danach wird ein anderer Sende-Befehl mit dem verbundenen Datenfeld ausgeführt, das einen Lese-Befehl bezeichnet, der zu dem Netzwerkbauteil mit der Adresse 2 zu senden ist (bezeichnet N2 in 2). Ein Antwort-Verzögerungs-Befehl wird dann ausgeführt, um dem Netzwerkbauteil N2 eine Zeitperiode bereitzustellen, in der die angefragten Daten, die mit x bezeichnet sind, auf dem Netzwerkbus zu lesen sind.
Nachdem die Daten x auf dem Netzwerkbus gelesen wurden, wird ein Sende-Befehl erneut mit dem verbundenen Datenfeld ausgeführt, das andeutet, dass Daten zu dem Netzwerkbauteil mit Adresse 3 geschrieben werden sollen (bezeichnet mit N3 in 2). Folglich wird ein Sende-Daten-Befehl ausgeführt mit dem Datenfeld, das die Daten identifiziert, die mit y bezeichnet sind und die zu dem Netzwerkbauteil N3 zu senden sind. Zum Schluss wird ein anderer Sende-Befehl mit dem Datenfeld ausgeführt, das spezifiziert, dass Daten zu dem Netzwerkbauteil mit der Adresse 4 geschrieben werden sollen (bezeichnet N4 in 2). Dann wird ein Sende-Daten-Befehl erneut mit dem verbundenen Datenfeld ausgeführt, das die Daten bereitstellt, die auf das Netzwerkbauteil N4 zu schreiben sind. In diesem Beispiel werden die Daten mit z bezeichnet. Um die Serie von Instruktionen zu wiederholen, wird ein Absoluter-Sprung-Befehl mit dem Datenfeld ausgeführt, der bestimmt, dass die Ausführung zu dem Speicherplatz Null springen soll, wobei tatsächlich die Ausführung des Prozesses erneut gestartet wird. Daher liest die Serie von Instruktionen in diesem Beispiel periodisch Daten, die von Netzwerkbauteilen N1 und N2 bereitgestellt werden, wie beispielsweise ein erster und zweiter Sensor, und schreibt Daten periodisch auf die Netzwerkbauteile N3 und N4, die beispielsweise einen dritten und vierten Aktuator darstellen.
Wie auch in 2 gezeigt enthält die Bussteuerung 14 einen Empfänger 26 für den Empfang der Daten, die aus dem Netzwerkbus 12 ausgelesen werden. Diese Daten werden typischerweise dem Hostcomputer 20 zur zusätzlichen Verarbeitung zur Verfügung gestellt. Zum Beispiel kann der Hostcomputer die Daten parsen und kann dann verschiedene Datenanalysen und/oder Datengewinnungsoperationen durchführen, die von der Anwendung abhängen.
Obwohl die Ausführung der Serie von Instruktionen, die in das Speicherbauteil 24 vorgeladen ist, das mit der Bussteuerung 14 der 2 verbunden ist, durch einen internen Takt 28 kontrolliert wird, kann die Ausführung der Serie von Instruktionen durch einen externen Takt kontrolliert werden. In dieser Hinsicht zeigt 3 ein ähnliches System 10, in dem ein externer Takt 30 für. die Bussteuerung und insbesondere für die Speicherbauteile bereitgestellt ist, die die Serie von Instruktionen speichern. Deshalb kann derselbe externe Takt für verschiedene Bussteuerungen bereitgestellt werden, um die Operationen der Bussteuerungen und der jeweiligen Netzwerkbusse zu kontrollieren und zu synchronisieren.
Während ein System 10, das einen Netzwerkbus 12 verwendet, der sich zwischen einem Paar von Bussteuerungen 14 und 16 erstreckt, erläutert und beschrieben worden ist, sind das System und das Verfahren der vorliegenden Erfindung für eine breite Vielfalt von anderen Netzwerkbusarchitekturen geeignet. Zum Beispiel kann das System einen Netzwerkbus beinhalten, der eine einzelne Bussteuerung hat, die mit dem Netzwerkbus entweder an einen Ende des Netzwerkbusses oder an jedem beliebigen Punkt entlang des Netzwerkbusses, wie in der 4 gezeigt, verbunden ist.
Gemäß jedweder Ausgestaltung der vorliegenden Erfindung sind ein System 10 und ein Verfahren für das Vorladen eines Befehlplans typischerweise in der Form einer Serie von Instruktionen in einem Speicherbauteil 24 bereitgestellt, das mit einer Bussteuerung 14 verbunden ist. Danach kann die Bussteuerung die Serie von Instruktionen ausführen, um geeignete Befehle auf dem Netzwerkbus zu platzieren. Durch das Vorladen der Serie von Instruktionen in die Bussteuerung, wird die Arbeitslast des Hostcomputers 20 reduziert. Die Reduktion der Arbeitslast des Hostcomputers erlaubt dem Hostcomputer andere Funktionen auszuführen, wie z. B. das Ausführen von systemweiten Operationen und/oder Datenanalyse, während die Bussteuerung die vorgeladene Serie von Instruktionen ausführt. Indem der Bussteuerung erlaubt wird, die Ausführung der Serie von Instruktionen zu kontrollieren, kann die Bussteuerung zusätzlich sicherstellen, dass Befehle in einer zeitdeterministischen Art ausgegeben werden, um so geeignet mit verschiedenen Netzwerkbauteilen zu interagieren.
Wie oben illustriert und diskutiert stellen die Systeme und Methoden der vorliegenden Erfindung die Fähigkeit bereit, deterministische Netzwerkprozesse ohne Verwendung des Hostprozessors auszuführen. Insbesondere identifizieren die Systeme und Verfahren der vorliegenden Erfindung Beispiele, bei denen die Befehle, die von der Bussteuerung ausgegeben werden, netzwerkprotokollspezifisch sind und periodisch wiederholend (das ist eine Serie von Protokollbefehlen, die sich in periodischer Folge wiederholt). Die Systeme und Verfahren der vorliegenden Erfindung beseitigen diese wiederholende Serie von Befehlen von den Operationen, die der Hostprozessor durchführen muss, und laden die Befehle und Daten in einen Befehlsplan vor, typischerweise in der Form einer Serie von Instruktionen. Der Befehlsplan wird für die Ausführung des Befehlsplans in der Bussteuerung zusammen mit Codes gespeichert, die als Mikrocode bezeichnet werden. In dem Betrieb werden die wiederholenden Befehle unter Verwendung des periodischen Befehlsplans durch die Bussteuerung anstelle des Hostprozessors durchgeführt.
Wie bisher beschrieben laden die Systeme und Verfahren der vorliegenden Erfindung jedoch den Befehlsplan nur vor, der eine Serie von Befehlen und Daten enthält, die sich während der Operation des Netzwerksystems nicht verändern. Mit anderen Worten enthält der periodische Befehlsplan nur fixe Befehle und Daten, die nicht veränderbar sind. Der periodische Plan als solcher erlaubt nur einen kontinuierlichen Strom von vorprogrammierter Datenbeschaffung oder Ausgaben auszuführen. Während dies für Anwendungen zur Datenbeschaffung oder einfache wiederholende Kontrollsequenzen akzeptabel ist, die keine Modifikation des Prozesses erfordern, existieren einige Beispiele bei denen die dynamische Veränderung der Befehle oder Daten, die in dem Befehlsplan gelistet sind, während der Abarbeitung des periodischen Befehlsplans vorteilhaft ist, um dem Netzwerksystem zu erlauben eine bessere Prozesskontrolle zu erreichen. Mit anderen Worten, es wäre vorteilhaft, einen vorgeladenen Befehlsplan mit Befehlen und Daten, die während der Operation, die auf dem Prozess basiert, der mit dem Netzwerksystem verbunden ist, verändert oder aktualisiert werden können, bereitzustellen.
Zum Beispiel kann das Netzwerksystem in Verbindung mit einem Prozess verwendet werden, der Variablen besitzt, die sich mit der Zeit verändern können. Wenn sich diese Variablen ändern, müssen die Befehle und Daten, die zu den verschiedenen Netzwerkbauteilen übertragen wurden, möglicherweise verändert werden, um sicherzustellen, dass der Prozess im Hinblick auf diese Veränderungen angemessen und präzise kontrolliert wird. In diesen Beispielen sollen einige der Befehle und Daten, die in den Befehlsplan vorgeladen sind, verändert werden, um eine gute Kontrolle bereitzustellen.
Vor diesem Hintergrund stellen das System und die Verfahren der vorliegenden Erfindung in einigen Ausgestaltungen Prozeduren bereit, die es dem Hostprozessor erlauben, den Inhalt und die Ausführung des eingebetteten Befehlsplans zu verändern um dabei eine bessere Prozesskontrolle bereitzustellen. Die Systeme und Verfahren der vorliegenden Erfindung ermöglichen der Hoststeuerung Daten von dem Netzwerk zu empfangen und zu analysieren, analytische Ergebnisse zu berechnen und geeignete Prozessveränderungen zu produzieren, die wieder als Befehle oder Argumente in den Befehlsplan eingesetzt werden können. Obwohl der Hostprozessor die vorgeladenen Befehle und Daten des Befehlsplans in diesen Ausgestaltungen periodisch evaluieren und modifizieren muss, ist der Hostprozessor frei, Verarbeitungen eines höheren Levels durchzuführen, weil der Großteil der Verarbeitung entsprechend dem Befehlsplan von der Bussteuerung durchgeführt wird.
Mit Bezug zu den 5 und 6 ist es bedeutsam, dass die Systeme und Verfahren der vorliegenden Erfindung eine Serie von Registern 40 bereitstellen, die sich in dem Speicherbauteil 24 befinden, das mit der Bussteuerung verbunden ist. Diese Register, die vorzugsweise 17 Bit lang sind, werden benutzt, um Werte von Variablen in dem Befehlsplan zu speichern. Mit anderen Worten, wenn der Hostprozessor Daten von dem Netzwerksystem analysiert, dann berechnet er analytische Ergebnisse und produziert angemessene Prozessveränderungen für diese Variablen des Befehlsplans. Diese Updates werden in Registern gespeichert, wo sie wieder als Befehle oder Argumente in den Befehlsplan eingefügt werden können.

Um die aktualisierten oder modifizierten Werte in den Befehlsplan einzufügen, enthalten die Systeme und Verfahren der vorliegenden Erfindung einen zusätzlichen Satz von Mikrocodes für das Laden von Werten aus der Serie von Registern in den Befehlsplan, um variable Befehle und Daten in dem Befehlsplan zu verändern und dabei eine bessere Prozesskontrolle bereitzustellen. Diese zusätzlichen Mikrocodes sind in der folgenden Tabelle aufgeführt:

Aktion	Datenfeld
Sende-Befel-vom-Register (Send Command From Register)	Adresse eines internen Registers um einen Befehl abzurufen
Sende-Daten-vom-Register (Send Data From Register)	Adresse eines internen Registers um einen Datenwert abzurufen
Verzögerung-vom-Register (Delay From Register)	Adresse eines internen Registers um einen Verzögerungswert abzurufen
Absoluter-Sprung-vom-Register (Absolute Jump From Register)	Adresse eines internen Registers um einen Sprungwert abzurufen

Der Sende-Befehl-vom-Register-Microcode (Send-Command-From-Register-Microcode) ist ähnlich zu dem traditionelleren Sende-Befehl, aber die Daten in dem Datenfeld sind durch den Hostprozessor veränderbar. Insbesondere in den vorherigen Ausgestaltungen, bei denen die Befehle und Daten vorgeladen werden und nicht rekonfigurierbar sind, sendet der Sende-Befehl die Daten in das Datenfeld, welches mit dem Befehl in dem Befehlsplan vorgespeichert ist. Allerdings verwendet das Sende-Befehl-Register (Send-Command-Register) Daten von einem der Register 40 als Daten für den Befehlsrahmen. Das Register ist in dem Datenfeld des Sende-Befehl-vom-Register-Microcode definiert und die Befehle als solche, die von der Bussteuerung ausgegeben werden, wenn die Bussteuerung den Befehlsplan abarbeitet, sind durch den Hostprozessor durch bloßes Verändern der Werte konfigurierbar, die in dem entsprechenden Register 40 gespeichert sind.
Der Sende-Daten-vom-Register-Microcode-Befehl (Send-Data-From-Register-Microcode-Befehl) ist ähnlich zu dem Sende-Befehl-vom-Register-Microcode, allerdings wird er verwendet, um Daten anstelle von Befehlen zu senden. Insbesondere verwendet das Sende-Befehl-Register Daten von einem der Register 40 als Daten für den Datenrahmen. Das Register ist in dem Datenfeld für den Sende-Daten-Befehl definiert und die Daten als solche, die von der Bussteuerung gesendet werden, sind, wenn die Bussteuerung den Befehlsplan abarbeitet, von dem Hostprozessor durch bloßes Verändern des Werts konfigurierbar, der in dem entsprechenden Register 40 gespeichert ist.
Wie vorher diskutiert enthalten die Systeme und Verfahren der vorliegenden Erfindung Verzögerungsmikrocodes, die spezifische Verzögerungen in der Operation erlauben. In den vorherigen Ausgestaltungen, in denen die Befehle und Daten vorgeladen wurden und nicht rekonfigurierbar waren, sind die Daten für den Verzögerungswert mit dem Verzögerungsbefehl in dem Befehlsplan vorgespeichert. Allerdings verwendet der Verzögerung-vom-Register-Befehl (Delay-From-Register-Befehl) Daten von einem der Register 40 als Daten für die Verzögerungszeit. Das Register ist in dem Datenfeld für den Verzögerung-Befehl definiert. Und hier sind wiederum die Verzögerungswerte, die von dem Verzögerung-vom-Register-Befehle gesendet sind, die von der Bussteuerung ausgegeben worden sind, wenn sie den Befehlsplan abarbeitet, von dem Hostprozessor durch bloßes Verändern des Wertes konfigurierbar, der in dem entsprechenden Register 40 gespeichert ist.
Zusätzlich enthalten die Systeme und Verfahren der vorliegenden Erfindung einen Absoluter-Sprung-vom-Register-Microcode-Befehl (Absolute-Jump-From-Register-Microcode-Befehl). Dieser Befehl leistet dieselben Aktionen wie der Absoluter-Sprung-Code (Absolute-Jump-Code), mit der Ausnahme, dass die Daten für den absoluten Sprungwert im Gegensatz zu einem Datenfeld, das mit dem Befehl in dem Befehlsplan gespeichert ist, von den Registern 40 kommt, wobei das Register in dem Datenfeld für den Absoluter-Sprung-Code definiert ist. So wie bei den anderen zugefügten Befehlen, sind die Sprungwerte von dem Hostprozessor durch bloßes Verändern des Wertes konfigurierbar, der in dem entsprechenden Register 40 gespeichert ist, das als Datenfeld für den Befehl verwendet wird. Der Hostprozessor als solcher kann durch Verändern des Wertes in dem Register kontrollieren, wohin die Bussteuerung in dem Befehlsplan springt.
In den 5 und 6 werden Beispiele zur Verwendung der Sende-Daten-vom-Register- und der Absoluter-Sprung-vom-Register-Befehle illustriert. Zum Beispiel werden in 5 die Serien von Instruktionen beginnend mit der Speicheradresse Null gespeichert. Nach Beginn der Operationen führt die Bussteuerung den ersten Mikrocodebefehl aus, welcher ein Sende-Befehl ist. Der Sende-Befehl hat ein verbundenes Datenfeld, das den Befehlsrahmen definiert, der über den Netzwerkbus 12 zu übertragen ist, um ein Trigger-Befehl zu sein. Danach wird einem anderen Sende-Befehl. das verbundene Datenfeld bereitgestellt, was andeutet, dass der zu sendende Befehlsrahmen eine Leseoperation für das Netzwerkbauteil mit der Adresse 1 sein soll (bezeichnet mit N1 in 2). Der Antwort-Verzögerung-Befehl wird dann ausgeführt, um dem Netzwerkbauteil N1 eine Gelegenheit zu geben, Daten bereitzustellen, die mit w bezeichnet sind. Danach wird ein weiterer Send-Befehl ausgeführt und das verbundene Datenfeld weist darauf hin, dass ein zu sendender Befehlsrahmen eine Leseoperation für das Netzwerkbauteil mit der Adresse 2 sein soll (bezeichnet mit N2 in 2). Ein Antwort-Verzögerung-Befehl wird dann ausgeführt, um dem Netzwerkbauteil N2 eine Zeitperiode bereitzustellen, in welcher die angefragten Daten bereitzustellen sind, die mit x bezeichnet sind.
Im Hinblick auf den folgenden Satz von Befehlen enthält der Befehlsplan den Sende-Daten-vom-Register-Befehl, der erlaubt, dass Daten, die mit dem Befehl verbunden sind, von dem Hostprozessor verändert werden. Dieses Verfahren erlaubt der Hoststeuerung Daten asynchron zu den Netzwerkoperationen aber trotzdem in Echtzeit zurück auf das Netzwerk zu legen, so dass Kontrolloperationsdaten, die von Daten berechnet sind, die von dem Netzwerk und anderen Quellen extrahiert sind, auf dem Netzwerk fast in Echtzeit platziert werden können.
Insbesondere wird ein Sende-Befehl mit dem Datenfeld erneut ausgeführt, das mit dem Sende-Befehl verbunden ist, was andeutet, dass Daten zu dem Netzwerkbauteil mit der Adresse 3 geschrieben werden sollen (bezeichnet mit N3 in 2). Die mit dem Befehl verbunden Daten werden von dem Register 40 mit der Adresse 10 unter Verwendung des Sende-Daten-vom-Register-Befehls bereitgestellt. Der Wert y als solcher, der in dem Register mit Adresse 10 gespeichert ist, wird zu dem Netzwerkbauteil mit Adresse 3 gesendet. Weil der Wert y in einem der Register gespeichert ist, ist der Wert y variabel und wird durch den Hostprozessor definiert.
Weiterhin wird ein anderer Sende-Befehl mit dem Datenfeld ausgeführt, das spezifiziert, dass Daten auf das Netzwerkbauteil mit der Adresse 4 geschrieben werden sollen (bezeichnet mit N4 in 2). Danach wird ein Sende-Daten-vom-Register-Befehl mit dem verbundenen Datenfeld erneut ausgeführt, das die Daten breit stellt, die zu dem Netzwerkbauteil N4 von dem Register mit der Adresse 12 geschrieben werden sollen. Die Daten, die mit z bezeichnet sind und die in dem Register mit Adresse 12 gespeichert sind, sind wieder variabel und durch den Hostprozessor, basierend auf der Analyse des Hostprozessors von den Daten aus dem Netzwerk, konfigurierbar. Um diesen Prozess zu wiederholen, wird ein Absoluter-Sprung-Befehl mit dem Datenfeld ausgeführt, das besagt, dass die Ausführung zu dem Speicherort Null springen soll, wobei tatsächlich die Ausführung des Prozesses erneut gestartet wird. Daher liest die Serie von Instruktionen in diesem Beispiel periodisch Daten, die von den Netzwerkbauteilen N1 und N2, beispielsweise ein erster und zweiter Sensor, bereitgestellt werden und schreibt Daten periodisch auf die Netzwerkbauteile N3 und N4, beispielsweise wie ein dritter und vierter Aktuator.
Mit Bezug zu 6 wird der Absoluter-Sprung-vom-Register-Befehl erläutert. Dieser Befehl erlaubt der Hoststeuerung von der Hauptprogrammschleife zu einer anderen Programmschleife zu springen, die einen anderen Codesatz ausführen kann. Wie illustriert, liefert der Hostprozessor insbesondere die Adresse für den Absoluter-Sprung-vom-Register-Befehl. Wie illustriert, kann die Adresse des Codes für den zweiten Prozess (bezeichnet mit Adresse A) in dem Register mit der Adresse 14 gespeichert werden, so dass die Bussteuerung, basierend auf der Analyse des Prozesses, der von dem Hostprozessor durchgeführt wird, zu dem zweiten Satz von Befehlen schaltet. An dieser Stelle muss verstanden werden, dass die 5 und 6 nur illustrative Ausgestaltungen von der Verwendung des zusätzlichen Mikrocodes sind, Die Mikrocodes haben viele denkbare Anwendungen in dem Zusammenhang mit einem Netzwerksystem.
Viele Modifikationen und andere Ausgestaltungen von der Erfindung, zu denen diese Erfindung gehört und die den Nutzen der Lehre haben, die in der vorangegangen Beschreibung und den verbundenen Zeichnungen präsentiert wurde, werden einem Fachmann einfallen. Daher ist zu verstehen, dass die Erfindung nicht zu der speziellen offenbarten Ausgestaltung limitiert ist und dass beabsichtigt ist, Modifikationen und andere Ausgestaltungen im Rahmen der anhängenden Ansprüche zu umfassen. Obwohl hier spezifische Ausdrücke verwendet wurden, werden sie ausschließlich in einem generischen und beschreibenden Sinn verwendet und nicht mit der Absicht zur Eingrenzung.

Claims

System zur Steuerung des Betriebs eines Netzwerkgeräts über einen Netzwerkbus unabhängig von den Operationen eines Host-Computers, das Folgendes umfasst einen Zentralrechner (20); zwei oder mehr Netzwerkgeräte (18); einen Netzwerkbus (12), wobei die zwei oder mehr Netzwerkgeräte in elektrischer Kommunikation mit dem Netzwerkbus stehen; und einen Bus-Controller (14), der in elektrischer Kommunikation sowohl mit dem Netzwerkbus als auch mit dem Host-Computer angeordnet ist, um Befehle an das mindestens eine Netzwerkgerät zu senden, wobei der Bus-Controller eine Speichervorrichtung zum Speichern einer Reihe von Befehlen umfasst, wobei die Befehle mindestens einen Befehl enthalten, der von dem mindestens einen Netzwerkgerät auszuführen ist, wobei die Bussteuerung so ausgelegt ist, dass sie die in der Speichervorrichtung gespeicherte Befehlsserie unabhängig von den Operationen des Host-Computers ausführt, um die mit dem mindestens einen Netzgerät über den Netzwerkbus geführten Kommunikationen zu steuern, wobei der Bus-Controller den mindestens einen Befehl an das Netzwerkgerät sendet und das Netzwerkgerät den Befehl unabhängig von den Operationen des Host-Computers ausführt, wobei der Host-Computer (20) so ausgelegt ist, dass er den Bus-Controller (14) mit einem Befehlsplan vorlädt, der eine Reihe von Befehlen umfasst, so dass der Bus-Controller den Befehlsplan ausführt, um die Kommunikation mit dem mindestens einen Netzwerkgerät zu steuern, wobei mindestens einer der Befehle ein zugeordnetes variables Datenfeld hat, und wobei der Host-Computer dazu ausgelegt ist, Kommunikationen auf dem Netzwerkbus auszuwerten und das variable Datenfeld des mindestens einen Befehls zu ändern, um dadurch die Kommunikationen zwischen dem Bus-Controller und dem mindestens einen Netzwerkgerät auf dem Netzwerkbus zu ändern, dadurch gekennzeichnet, dass der Host-Computer (20) dafür ausgelegt ist, über den Netzwerkbus (12) geführte Kommunikationen auszuwerten, und wobei der Host-Computer dazu ausgelegt ist, die variablen Daten, die dem mindestens einen variablen Datenfeld des mindestens einen Befehls zugeordnet sind, auf der Grundlage der ausgewerteten Kommunikationen zu ändern.
System nach Anspruch 1, wobei der Host-Computer in der Lage ist, die Befehlsserie an die Speichereinheit des Bus-Controllers zu übertragen, so dass der Bus-Controller mit einem Befehlsplan vorgeladen ist.
System nach Anspruch 2, wobei die Speichervorrichtung des Bus-Controllers eine nichtflüchtige Speichervorrichtung aufweist und wobei der Host-Computer in der Lage ist, die Befehlsserie spätestens während der Ausführung der Befehlsserie durch den Bus-Controller in die nichtflüchtige Speichervorrichtung vorzuladen.
System nach Anspruch 2, wobei die Speichereinrichtung des Bus-Controllers eine flüchtige Speichereinrichtung aufweist und wobei der Host-Computer in der Lage ist, die Befehlsserie in die flüchtige Speichereinrichtung vor der Ausführung der Befehlsserie durch den Bus-Controller vorzuladen.
System nach Anspruch 1, wobei der Bus-Controller so ausgelegt ist, dass er die Befehlsserie wiederholt zeitdeterministisch ausführt.
System nach Anspruch 1, wobei die Speichervorrichtung des Bus-Controllers in der Lage ist, die variablen Daten an mindestens einer vordefinierten Adresse zu speichern, wobei das mindestens eine variable Datenfeld, das den variablen Daten zugeordnet ist, in der Lage ist, die mindestens eine vordefinierte Adresse der zugeordneten variablen Daten zu identifizieren, so dass, wenn der Bus-Controller den mindestens einen Befehl ausführt, der das mindestens eine variable Datenfeld enthält, der Bus-Controller die variablen Daten aus der Speichervorrichtung an der mindestens einen vordefinierten Adresse, die durch das entsprechende mindestens eine variable Datenfeld identifiziert wird, abruft.
System nach Anspruch 6, wobei die Speichervorrichtung des Bus-Controllers mindestens ein Register mit der mindestens einen vordefinierten Adresse enthält, wobei das mindestens eine Register in der Lage ist, die variablen Daten an der mindestens einen vordefinierten Adresse zu speichern.
Verfahren zum Steuern des Betriebs eines Netzwerkgeräts über einen Netzwerkbus unabhängig von den Operationen eines Host-Computers, umfassend: Übertragen einer Reihe von Befehlen von einem Host-Computer (20) zu einem Bus-Controller (14), so dass der Bus-Controller mit einem Befehlsplan vorgeladen ist, wobei die Befehle mindestens einen Befehl enthalten, der von dem mindestens einen Netzwerkgerät auszuführen ist; Ausführen mindestens eines der Befehle in einer von den Operationen des Host-Computers unabhängigen Weise, um so die zwischen einem Bus-Controller und mindestens einem Netzwerkgerät über den Netzwerkbus geführten Kommunikationen zu steuern, wobei das Ausführen den mindestens einen Befehl an das Netzwerkgerät überträgt und das Netzwerk-gerät den Befehl unabhängig von der Operation des Host-Computers ausführt, wodurch es dem Host-Computer ermöglicht wird, Operationen gleichzeitig mit der Ausführung des mindestens einen Befehls durch den Bus-Controller auszuführen, wobei der Ausführungsschritt eine Reihe von Befehlen in einer solchen Weise ausführt, dass die zwischen einem Bus-Controller und einer Vielzahl von Netzwerkgeräten über den Netzwerkbus durchgeführten Kommunikationen gesteuert werden, wobei mindestens ein Befehl mindestens ein variables Datenfeld aufweist, das mit variablen Daten verknüpft ist, wobei das Verfahren ferner den Schritt des Änderns der variablen Daten umfasst, die mit dem mindestens einen variablen Datenfeld des mindestens einen Befehls verknüpft sind, um dadurch die Ausführung des jeweiligen Befehls zu ändern, dadurch gekennzeichnet, dass das Verfahren ferner das Auswerten von Kommunikationen umfasst, die über den Netzwerkbus (12) durchgeführt werden, während die Reihe von Befehlen ausgeführt wird, wobei der Änderungsschritt das Ändern der variablen Daten, die dem mindestens einen variablen Datenfeld des mindestens einen Befehls zugeordnet sind, auf der Grundlage der ausgewerteten Kommunikationen umfasst.
Verfahren nach Anspruch 8, wobei das Übertragen der Befehlsserie das Übertragen einer Befehlsserie zu einer nichtflüchtigen Speichervorrichtung der Bussteuerung umfasst und wobei das Übertragen der Befehlsserie spätestens während der Ausführung der Befehlsserie erfolgt.
Verfahren nach Anspruch 9, wobei das Übertragen der Befehlsserie das Übertragen einer Befehlsserie zu einer flüchtigen Speichervorrichtung des Bus-Controllers umfasst.
Verfahren nach Anspruch 10, wobei die Ausführung der Befehlsserie die wiederholte Ausführung der Befehlsserie in einer zeitdeterministischen Weise umfasst.
Verfahren nach Anspruch 8, wobei die variablen Daten an mindestens einer vordefinierten Adresse gespeichert werden können, wobei das mindestens eine variable Datenfeld des mindestens einen Befehls die mindestens eine vordefinierte Adresse der zugehörigen variablen Daten identifizieren kann, und wobei die Ausführung der Befehlsserie die Ausführung mindestens eines Befehls einschließlich des mindestens einen variablen Datenfelds und das Abrufen der variablen Daten auf der Grundlage der mindestens einen vordefinierten Adresse, die durch das mindestens eine variable Datenfeld des jeweiligen mindestens einen Befehls identifiziert wird, umfasst.