-
ZUGEHÖRIGE ANMELDUNGEN
-
Diese Anmeldung ist eine Teilanmeldung
einer ebenfalls anhängigen
Anmeldung Serial Number 08/857725, publiziert als WO-A-98 51991, übertragen
auf die hier genannte Zessionarin, und bezieht sich auf eine Anmeldung
mit dem Titel "System and Method for Distributed Computer Automotive
Service Equipment", hinterlegt am 31. Oktober 1997, Serial Number
08/962,023, publiziert als WO-A-99 23783, die ebenfalls auf die
Zessionarin übertragen
ist.
-
GEBIET DER ERFINDUNG
-
Die vorliegende Erfindung bezieht
sich auf ein System und ein Verfahren für ein verbessertes computergesteuertes
Kraftfahrzeugservice-Watungssystem gemäß dem Oberbegriff von einem
der Ansprüche
1 und 5.
-
STAND DER TECHNIK
-
Computerunterstützte bzw. computergesteuerte
Kraftfahrzeugservice- und Diagnoseeinrichtungssysteme für ein Messen
oder Testen von verschiedenen Parametern und zum Bereitstellen von Wartungs-
und Reparaturverfahrens-Instruktionen an einen Betätiger sind
allgemein bekannt. Derartige Systeme umfassen einen zentralen Steuer-
bzw. Regelprozessor, der in einem Dateneingabecomputer angeordnet
ist, und verschiedene Dateneingabe- und Speichermittel sind mit
diesem Computer verbunden, beispielsweise im Fahrzeug montierte
Instrumente, Sensoren, händische
Dateneingabetastaturen und elektronische Datenbankspeichermittel.
-
Systeme, welche im bzw. am Fahrzeug
montierte Sensoren verwenden, verwenden diese Sensoren, um Rohsignale,
die gemessene Quantitäten bzw.
Größen darstellen,
an einen zentralen Steuer- bzw. Regelprozessor für einen Vergleich mit gespeicherten
Spezifikationsdaten zu übertragen.
Aus diesem Vergleich berechnet der zentrale Prozessor einen Fahrzeugdiagnosezustand.
Zusätzlich
ermöglichen,
um eingegebene oder gemessene Daten zur Verfügung zu stellen, derartige
Sensoren auch dem zentralen Prozessor, eine Echtzeitüberwachung
des Fahrzeugdiagnosezustands durchzuführen. Repräsentative Fahrzeugradausrichtungssysteme
sind beispielsweise in U.S.Patent Nr. 4,383,370 und 5,208,646 geoffenbart.
-
Im Betrieb werden die gemessenen
Daten, die aus den Rohsignalen abgeleitet sind (oder alternativ
gemessene Daten, die von der Betätiger-Tastatureingabe
abgeleitet sind) mit zuvor abgespeicherten Spezifikationsparametern
verglichen. Derartige Spezifikationsparameter entsprechen spezifischen Ausbildungen
und Modellen von Fahrzeugen oder Teilen. Ein Fahrzeugdiagnosezustand
wird aus dem zuvor erwähnten
Vergleich zwischen gemessenen und Spezifikationswerten erhalten
und der zentrale Prozessor gibt eine Ausgabe heraus, die durch einen Betätiger auf
einer Ausgabevorrichtung erkenntlich ist. Derartige Ausgabevorrichtungen
umfassen üblicherweise
eine CRT-Anzeige, jedoch sind zahlreiche Möglichkeiten offensichtlich,
beispielsweise Ton oder Stimmausgabe oder ein Ausdruck als Papier-Hardcopy.
Aus der Information an der Ausgabevorrichtung kann ein Betätiger Probleme
mit dem Fahrzeug oder dem inspizierten Teil diagnostizieren. Bei
einer Fahrzeugserviceeinrichtung im allgemeinen, wie beispielsweise
Motor-Analysiereinrichtungen, Bremsentestvorrichtungen, Aufhängungstestvorrichtungen, Radwuchteinstelleinrichtungen
und dgl., sind Sensoren nicht notwendigerweise an dem Fahrzeug montiert.
-
Zusätzlich zu Diagnoseverfahren
erlauben existierende Systeme Betätigern erlauben, Korrekturen
durchzuführen,
sobald Probleme aus der Fahrzeugdiagnosezustandsausgabe detektiert
wurden. Derartige Systeme können
Instruktionen für
eine schrittweise Einstellung oder ein Reparaturverfahren umfassen,
um bei derartigen Korrekturen zu unterstützen. In derartigen Fällen fungiert
die Ausgabe, um einen Betätiger
oder Techniker durch ein Reparatur- oder Einstellungsverfahren zu
führen
bzw. zu leiten.
-
Zahlreiche Nachteile existieren unter
gegenwärtig
bekannten Systemen der oben beschriebenen Art. Einerseits umfassen
derartige computerunterstützte
Fahrzeugservicesysteme üblicherweise
kundenspezifische geschlossene Computersysteme. Ein Hersteller von
derartigen Systemen investiert üblicherweise
Jahre zur Entwicklung der Software. Der Hersteller hat die Software
anzupassen, um sie auf einem einzigen zugehörigen bzw. bestimmten Computer
laufen zu lassen und das resultierende Produkt hat eine geringe
oder keine Flexibilität,
um unterschiedliche Hardware- oder Softwareelemente auszutauschen
oder zu aktualisieren. Jedes System läuft mit unterschiedlicher Software,
oft auf vollständig
unterschiedlichen Betriebssystemen, die für vollständig unterschiedliche Hardwareplattformen
ausgebildet sind. Jedes individuelle System ist auch unfähig, geeignet
oder einfach aktualisiert zu werden. Wenn eine Neuentwicklung oder
eine Verbessung auftritt, muß der
Hersteller des individuellen System typischerweise eine vollständig neue
Version der Software und/oder der Hardware herausgeben, um diese Verbesserung
auf den Markt zu bringen. Diese Neuherausgabe er fordert eine vollständige Neuschrift. Nicht
nur die neuen Versionen brauchen oft Jahre zu ihrer Komplettierung.
Es ist oft so teuer, ein neues System herauszugeben, daß als eine
praktische Tatsache der Hersteller warten muß, bis ausreichend Verbesserungen
herausgekommen bzw. aufgetreten sind, um die finanziellen Belastungen
einer Herausgabe einer neuen Version zu rechtfertigen. Dies behindert
die Fähigkeit
des Endbenutzers, d. h. des Fahrzeugserviceprofessionisten, die
letzten technologischen Verbesserungen dem Kunden zu bringen bzw.
bereitzustellen, welcher üblicherweise
der Fahrzeuglenker ist.
-
In einigen Fällen wurden Personal Computer (PC's)
in die Fahrzeugserviceanwendungen in einem Versuch implementiert,
um die zuvor erwähnten Nachteile
zu beseitigen. Beispielsweise wurden einige Fahrzeugradausrichtungssysteme,
welche auf IBM basierende Standard-PC's verwenden, in Kombination
mit dem MICROSOFT WINDOWS 3.1 Betriebssystems herausgegeben. Obwohl
derartige Systeme ein Abweichen von den traditionellen, monolithischen,
geschlossenen Systemen der Vergangenheit bedeuten, verbleibt eine
Anzahl von Nachteilen. Beispielsweise unterstützt auf einem Programmierniveau
WINDOWS 3.1 keine 32-Bit Adressierung; es unterstützt lediglich
eine 16-Bit Adressierung unter Verwendung eines 16-Bit segmentierten Adressiermodus.
Dieses Speichermodell ist ein idiosynkratischer Rest des alten DOS
16-Bit segmentierten Adressiermodus. Auch verwendet WINDOWS 3.1
nur eine primitive Form von Multitasking bzw. Mehraufgabenverarbeitung.
WINDOWS 3.1 Multitasking ist Prozeß-basierend. D. h. während mehrere Programme
zur gleichen Zeit auf dem System laufen können, kann das Betriebssystem
nicht mehrere Teile desselben Programms zu einer Zeit laufen lassen. Eine
Folge davon ist, daß es
zuvor unmöglich
war, eine videographische Computeranimation (beispielsweise ein
Instruktionsvideo) auf einem Anzeigeschirm zur selben Zeit anzuordnen,
wie die Echtzeit-Live-Sensorablesungen angezeigt werden. Es war
auch nicht möglich,
spezielle Sensoreingaben als einen Auslöser zu verwenden, um Teile
einer Automobilserviceanwendung zu initiieren und zu exekutieren,
während
der Rest der Kraftfahrzeugsserviceanwendung weiter zur selben Zeit
durchgeführt
wurde.
-
Während
es in einigen Gebieten geschätzt wurde,
die Beschränkungen
eines auf WINDOWS 3.1 basierenden Computersystems mit der Implementierung
bzw. Einführung
neuerer 32-Bit Betriebssysteme,
wie WINDOWS 95, zu überwinden,
kann dasselbe nicht auf dem Gebiet der Kraftfahrzeugserviceausrüstung behauptet
werden. Das WINDOWS 95 Betriebssystem verwendet 32-Bit Flat-Adressierung.
Weiters benützt
WINDOWS 95 nicht nur auf Verfahren basierendes Multitasking, sondern
auch ein "thread based multitasking" (auf einer Kette bzw. Gruppe
basierendes Multitasking). Eine Parallelverarbeitung bzw. ein Multitasking
erlaubt es mehreren Teilen desselben Programms zur selben Zeit zu
laufen. Alle der innewohnenden Fortschritte von WINDOWS 95 gegenüber dem
WINDOWS 3.1 Betriebssystem bleiben in dem noch neueren WINDOWS 98 Betriebssystem
erhalten und sollten auch in zukünftigen
Versionen beibehalten bleiben. Es würde vorteilhaft sein, derartige
Merkmale auf das Kraftfahrzeugserviceausrüstungsgebiet anzuwenden.
-
1 ist
eine stilisierte, schematische Ansicht einer Gesamtübersicht,
wie eine Anwendung mit der Computerhardware in einem WINDOWS 95 oder
WINDOWS NT Betriebssystem zusammenwirkt. Hier wird das zentrale
bzw. Kerninterface der Hardware durch eine Serie von Ringen dargestellt. Ring 0 ist
die Hardware oder der Kern. Beispielsweise kann dies die CPU, Videokarte,
serielle Ports usw. umfassen. In Ring 1 liegt der WINDOWS
Betriebssystemkern und virtuelle Vorrichtungstreiber. Virtuelle
Vorrichtungstreiber bzw. Treiber für virtuelle Vorrichtungen sind
Softwaregegenstände,
die Codes enthalten, welche verstehen, wie sie mit der zugehörigen bzw.
zugrunde liegenden Hardware kommunizieren. Der WINDOWS Kern handhabt
alle Aufrufe und gibt Information hin und her zwischen dem Betriebssystem
und den verschiedenen Anwendungsprogramm-Interfaces aus (API's).
Ring 2 ist dort, wo alle WINDOWS Anwendungsprogramm-Interfaces (API's)
liegen und ausgeübt
werden. Ring 3 ist dort, wo alle alten DOS-Anwendungen
ausgeübt
werden bzw. laufen. In Ring 2 liegen auch in sich abgeschlossene,
wiederverwendbare Softwaregegenstände, die "DLL's" genannt werden.
Ein DLL ("Dynamic Link Library") ist ein kleines Computerprogramm,
das durch verschiedene Prozesse zur selben Zeit geteilt werden kann.
-
Andere Merkmale von 32-Bit Betriebssystemen,
wie WINDOWS 95, waren bis dato in der Kraftfahrzeugserviceeinrichtungstechnik
nicht berücksichtigt.
WINDOWS 95 unterstützt
eine weiterführende
bzw. höhere,
objektorientierte Programmierung und objektorientiertes Design ("OOP/OOD")
. OOP umfaßt
die Ausbildung von Software-"Gegenständen". Softwaregegenstände können als
in sich abgeschlossene Miniprogramme innerhalb eines Programms erachtet
werden. Vor OOP bestanden Programme in erster Linie aus zwei grundsätzlichen Elementen,
Daten und Programminstruktionen. Datenelemente sind Speicherplätze. Programminstruktionen
sind Befehle, denen der Computer folgen wird, um Entscheidungen
durchzuführen
oder Daten zu manipulieren. Ein Datenelement, wie eine Variable, Konstante
oder Struktur hatte nur eine Funktion – Information zu enthalten.
Instruktionen hatten nur eine Funktion – eine gewisse Tätigkeit
durchzuführen.
Mit dem Aufkommen von Softwaregegenständen wird die Linie zwischen
Daten und Instruktionen unklar. Objekte sind Softwareeinheiten,
welche Eigenschaften besitzen. Sie können Tätigkeiten ausführen, wie Instruktionen,
jedoch können
sie auch Daten verwenden. Einer der Hauptvorzüge von Softwaregegenständen ist
ihre inhärente
Wiederverwertbarkeit. Gegenstände,
welche größtenteils
selbstenthaltend bzw. in sich abgeschlossen sind, können gekauft werden,
welche zahlreiche übliche
Funktionen, wie Datenbankroutinen, mathematische Algorithmen und Eingabe/Ausgabefunktionen
ausführen.
Microsoft hat nun eine WINDOWS NT Version und eine WINDOWS 98 Version
entwickelt, welche Hardwaretreiber über die verschiedenen Plattformen
teilen können.
Zahlreiche Objekte sind in dem Microsoft Visual C/C++ 4.2 Entwicklerstudio,
einer integrierten Softwareentwicklungsumgebung zum Schreiben vom Gegenstand-orientierten
Programmen enthalten.
-
Objekt- bzw. Gegenstands-orientierte
Anwendungen sind allgemein einfacher zu erzeugen und zu modifizieren
als nicht Gegenstands-orientierte Anwendungen. Wenn ein Bereich
einer Anwendung verändert
werden muß,
ist alles, was notwendigerweise verändert werden muß, der spezielle
in Frage stehende Softwaregegenstand. Die Modifikation wird für den Rest
der Anwendung transparent sein. Dies ist im Gegensatz zu früheren Systemen,
in welchen eine gesamte Anwendung neu geschrieben werden mußte und
Fehler korrigiert werden mußten, wann
immer eine kleinere Veränderung
an einem einzigen Teil der Anwendung gemacht wurde. Gegenstands-orientierte
Programme müssen
auch nicht vollständig
auf einem Computer liegen. So lange zu dem Gegenstand zugegriffen
werden kann, wird der Computer, der die Hauptanwendungsroutine läuft, fähig sein,
den Gegenstand abzurufen und darauf arbeiten.
-
Eine Konsequenz des Versagens, OOP
in Kraftfahrzeugserviceeinrichtungsanwendungen zu verwenden, ist,
daß es
bisher für
einen Kraftfahrzeugservicetechniker unmöglich war, seine eigene sequentielle
Wartungs- bzw. Serviceroutine auf Geschäftsbasis auszubilden und kundenspezifisch
anzupassen. Mit anderen Worten konnte, während in den Systemen gemäß dem Stand
der Technik ein Techniker auswählen
konnte, welches Serviceverfahren aus einer Auswahl von Menüoptionen
durchgeführt
wurde (zufälliger
Modus), er nicht eine einzige Sequenz von Serviceroutinen programmieren,
welche das Computer-unterstützte
System dazu veranlassen würde,
ihn durch den selben Satz von Routinen Schritt für Schritt jedesmal (sequentieller
Modus) zu leiten.
-
Aus der US-A-4 931 964 ist ein computerunterstütztes Radausrichtungssystem
bekannt, beinhaltend eine Mehrzahl von Sensoren zum Ausführen von
Nachlaufmessungen und einem Unwuchtkompensationsverfahren, welche
nach Drücken
eines Schalters ausgeführt
werden.
-
Es ist das Ziel der vorliegenden
Erfindung, ein neues, verbessertes computerunterstütztes Kraftfahrzeugservicesystem
zur Verfügung
zu stellen, welches die Nachteile und Beschränkungen das oben beschriebenen
Standes der Technik löst
bzw. vermeidet.
-
Dieses Ziel wird durch ein computerunterstütztes Radausrichtungssystem,
wie es in Anspruch 1 beschrieben ist, und durch ein Verfahren zum Durchführen von
Messungen durch ein computerunterstütztes bzw. computergesteuertes
Radausrich tungssystem gelöst,
wie dies in Anspruch 5 definiert ist. Bevorzugte Ausbildungen der
Erfindung sind in den abhängigen
Ansprüchen
beschrieben.
-
Gemäß der Erfindung veranlaßt der Computer
den Beginn einer Serviceroutine nach der Detektion von speziellen
Reizen von den Sensoren. Beispielsweise wird ein Umluftkorrekturverfahren
initiiert, nachdem die Sensoren den Beginn des Verfahrens an dem
Fahrzeugrad detektieren. Andere Merkmale der vorliegenden Erfindung
werden dem Fachmann aus der nachfolgenden, detaillierten Beschreibung
offensichtlich werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist
eine stilisierte, schematische Ansicht, die einen allgemeinen Überblick
zeigt, wie eine Anwendung mit der Computerhardware in einem WINDOWS
95 oder WINDOWS NT Betriebssystem wechselwirkt.
-
2 ist
eine stilisierte, schematische Ansicht, die einen allgemeinen Überblick
zeigt, wie das System unter Verwendung der vorliegenden Erfindung
mit der Computerhardware wechselwirkt.
-
3 ist
eine repräsentative
Schirmanzeige des sequentiellen Kraftfahrzeugserviceverfahrens-Editors
des Systems, das die vorliegende Erfindung verwendet.
-
4 zeigt
ein Flußdiagramm
einer verallgemeinerten, sequenzierten Verfahrenssteuerung bzw. -regelung
gemäß der vorliegenden
Erfindung.
-
DETAILLIERTE
BESCHREIBUNG DER BEVORZUGTEN AUSBILDUNGEN
-
Die detaillierten Beschreibungen
der folgenden, bevorzugten Ausbildungen sind als die beste Art zum
Ausführen
der vor liegenden Erfindungen zu beschreiben gemeint und sind nicht
beabsichtigt, um die darin erteilten Rechte zu beschränken, welche Rechte
durch die anhängigen
Ansprüche
definiert sind.
-
2 ist
eine stilisierte, schematische Ansicht, die einen allgemeinen Überblick
zeigt, wie das Kraftfahrzeugserviceeinrichtungssystem der vorliegenden
Erfindung mit der Computerhardware der vorliegenden Erfindung wechselwirkt.
Während
die hier geführte
Diskussion spezifisch für
ein Fahrzeugradausrichtungssystem ist, wird der Fachmann erkennen,
daß dieselben
Prinzipien auf ein Kraftfahrzeugserviceeinrichtungssystem der allgemeinen
Art anwendbar sind.
-
Das Fahrzeugradausrichtungssystem 100 umfaßt die Hardware
und die Software, die notwendig ist, um die Fahrzeugradausrichtungsverfahren durchzuführen. Die
Software arbeitet auf einem 32-Bit Betriebssystem, wie WINDOWS 95,
WINDOWS 98, WINDOWS NT oder einem äquivalenten Betriebssystem.
Die Hardware 10 umfaßt
einen IBM-kompatiblen Personal Computer der allgemeinen Art, enthaltend
einen Mikroprozessor, der adaptiert ist, um das 32-Bit Betriebssystem
laufen zu lassen, wie ein auf Intel PENTIUM basierendes System. Die
Hardware 10 umfaßt
zusätzlich
einen geeigneten Anzeige- bzw.
Displayadapter (wie eine VGA-Karte), ein serielles Port, wie ein
RS-232-Port und andere I/O Interfaceboards, die üblicherweise in PC's gefunden
werden. Die Hardware 10 liegt in Ring 0.
-
In einer bevorzugten Ausbildung wird
die CPU in der Hardware 10 mit einem BIOS, welches bootbare
CD-ROMs unterstützt,
assoziiert. Auf diese Weise kann das Betriebssystem auf einer CD
beim Einschalten angeordnet werden. Dies eliminiert jedes Erfordernis,
das Betriebssystem von einem PROM, was teuer ist, auf Systeme zu
booten bzw. zu laden, die keine anderen bootbaren Medien, wie einen
Festplattentreiber, aufweisen. Auch eliminiert dies das Erfordernis,
bestehende verdrahtete PROMS zu eliminieren, wenn ein Aktualisieren
bzw. Aufrüsten
notwendig wird.
-
Auch in Ring 0 ist eine
weitere I/O Interfaceplatte, die spezifisch in Fahrzeugradausrichtungsanwendungen
ist, die einfach als eine Hardware-Interfaceplatte (HIB) 20 bekannt
ist. HIB 20 in der Fahrzeugradausrichtungsanwendung ist
die Hardware, die operativ zwischen der Sammlung von am Rad montierten
Ausrichtungssensorköpfen
und dem Computer gekoppelt ist. HIB 20 funktioniert, um
rohe bzw. unbearbeitete Fahrzeugradausrichtungssignale von den Sensorköpfen hindurchzuleiten
und sie der CPU zuzuführen.
-
Ausschließlich mit HIB 20 assoziiert
sind ein HIB-Vorrichtungstreiber 30 und HIB API 50.
HIB-Vorrichtungstreiber 30 und HIB-API 50 sind
selbstenthaltende bzw. in sich geschlossene Softwaregegenstände, welche
die rohen Fahrzeugradausrichtungssignale von der CPU nehmen und
sie in Ausrichtungswinkelsignale verarbeiten, die fähig sind,
stromaufwärts
durch eine Anwendung interpretiert zu werden. HIB-Vorrichtungstreiber 30 ist
ein Softwaregegenstand des VxD-Typs,
das einen virtuellen Vorrichtungstreiber anzeigt. während die
VxD-Art das Treiberformat ist, das für das WINDOWS 95 Betriebssystem
spezifiziert ist, kann jeder geeignete Treibertyp, sofern erforderlich,
verwendet werden, wie diese, die für WINDOWS 98 oder WINDOWS NT
Betriebssysteme spezifiziert sind. HIB API 50 ist auch
ein selbst enthaltener Softwaregegenstand, jedoch einer, der das
DLL-Format verwendet. HIB-Vorrichtungstreiber 30 liegt
in Ring 1, während
HIB API in Ring 2 des allgemeinen Systems liegt.
-
HIB-Vorrichtungstreiber 30 und
HIB API 50 kooperieren mit HIB 20 auf die folgende
Weise, um die spezifische Art von Hardware, die in einem speziellen
Kraftfahrzeugserviceeinrichtungssystem verwendet wird, transparent
zu machen. Jeder HIB-Vorrichtungstreiber 30 und API 50 ist
einzig mit einer einzigen HIB 20 assoziiert. Folglich kann
eine unterschiedliche Abtastung bzw. Erfassung oder I/O-Hardware
auf dem selben Kraftfahrzeugseinrichtungssystem verwendet werden.
Ein Betätiger
muß nur
sicherstellen, daß der
geeignete HIB-Vorrichtungstreiber 30 und die geeignete
HIB API für
die spezielle HIB 20 in dem System vorhanden ist. Die Anwendung
selbst bleibt unbeeinflußt.
Beispielsweise wird, während eine
Marke bzw. Art von Sensorköpfen
für eine
Fahrzeugradausrichtungsanwendung eine erste Art von HIB-Vorrichtungstreiber 30 und
HIB API 50 erfordern wird, um die Fahrzeugradwinkelsignale
an eine Fahrzeugradausrichtungsanwendung zu übertragen, wird eine zweitee
Marke von Sensorköpfen
eine zweite Art von HIB-Vorrichtungstreiber und HIB API erfordern.
Ein Verändern
der HIB 20 wird den HIB-Vorrichtungstreiber 30 und
HIB API 50 für
die darunterliegende Systemanwendung transparent machen, da dieselben
verarbeiteten Ausrichtungswinkelsignale ausgebildet sind, um durch
die HIB API 50 in die Anwendung ausgegeben zu werden, unabhängig davon,
welche HIB 20 verwendet wird. Weiters wird erkannt bzw.
geschätzt
werden, daß HIB-Vorrichtungstreiber 30 und
HIB API 50 physikalisch innerhalb der Ausrichtungssensorköpfe selbst
liegen können,
beispielsweise wenn diese Sensorköpfe adaptiert sind, um über ein
Netzwerk mit der CPU in der Hardware 10 zu kommunizieren.
-
Weiters ist in dem Fahrzeugradausrichtungssystem 100 ein
Windows-Kern 40 vorhanden, welcher in Ring 1,
der Windows-Kernschicht,
liegt. Der Windows-Kern 40 ist das Niedrigniveau-Betriebssystem,
welches die CPU veranlaßt,
mit den verschiedenen Ausübungsanwendungen
und Teilen derselben zu kommunizieren (d. h. "Nachrichten" an diese
zu senden). Der Windows-Kern 40 verwendet zeitunterteilte,
preemptive CPU-Betätigung,
welche garantiert, daß jede
ausführende
Anwendung mit dem Betriebssystem während einem individuellen Betriebssystemzyklus
kommunizieren wird. Dieser Vorrangszugang für die zentrale bzw. Kernverarbeitung
ist eines der Mittel, mit welchem ein Multitasking durchgeführt wird.
Wie dies gezeigt ist, liegt der HIB-Vorrichtungstreiber 30 in
demselben Ring wie der Windows-Kern 40, was zeigt, daß der HIB-Vorrichtungstreiber 30,
wenn er vorhanden ist, die Aufmerksamkeit der CPU zumindest einmal
während
jedem Zyklus des Windows-Kerns 40 erhält. Der Windows-Kern 40 unterstützt auch
die 32-Bit Windows Graphikbenutzer-Interfacemetrik. Er verwendet
auch einen DCOM OLE 2.0 Container und/oder Objektserver, um es dem
Benutzer zu ermöglichen,
Gegenstände
zwischen dem Windows-Kern 40 und anderen Windows-Anwendungen
zu ziehen. Der Windows-Kern 40 unterstützt weiters die Universal Naming
Convention (UNC), welche Pfade umfaßt, die logische Verbindungen
mit Netzwerkvorrichtungen ohne das Erfordernis zum spezifischen
Benennen eines Netzwerktreiberbuchstabens erlaubt, wodurch ein einfacher
Filezugang über
Netzwerkverbindungen ermöglicht
wird.
-
Windows API/MFC 60 ist in
der nächst
höheren
Schicht in dem Fahrzeugradausrichtungssystem 100. Es umfaßt eine
Sammlung von in sich geschlossenen Softwaregegenständen des
32-Bit DLL Formats. Diese DLL's erlauben es mehreren Anwendungen,
dasselbe Verfahren zu verwenden. Aufgrund der Gegenstands orientierten
Natur des Systems kann ein Übertragen
zu anderen Plattformen (d. h. UNIX, XENIX, MacOS usw.) in einer
praktischen Weise durchgeführt
werden. Vorzugsweise umfaßt
Windows API/MFC 60 die Microsoft Foundation Classes Softwarebücherei.
Windows API/MFC 60 umfaßt vorzugsweise auch einen
Satz von in sich geschlossenen Softwaregegenständen, die einzig für Kraftfahrzeugserviceeinrichtungssysteme
erzeugt bzw. generiert werden. Diese beinhalten beispielsweise Gegenstände, die
für diskrete
Funktionen, die durch eine Anwendung auszuführen sind, repräsentativ sind.
Beispiele umfassen Fahrzeuginhaberinformation, Fahrzeugradausrichtungsspezifikationen,
Diagnostik-Computerroutinen, Fahrzeugserviceeinrichtungs-Betätigerinstruktionsroutinen,
Kundenkontoinformation oder jeden Gegenstand, der von einer bestimmten
Verwendung als Daten oder Instruktionsuntersatz eines Kraftfahrzeugsserviceeinrichtungssystems
verwendbar sein kann. Da sie Gegenstände sind, kann jede dieser
Strukturen, die in Windows API/MFC 60 liegt, einfach bzw.
bequem aktualisiert werden, wenn beispielsweise neue Fahrzeugradausrichtungsspezifikationen
ausgegeben werden oder wenn sich Kundeninformation verändert. Wie
Gegenstände
können
sie auch durch verschiedene Verfahren bzw. Prozesse auf demselben
Computer gleichzeitig verwendet werden. Sie haben auch die Eigenschaft,
daß sie
Vorrichtungs-unabhängig
sind, da sie dasselbe Datenkommunikationsprotokoll von den Ring 1-Treibern
erhalten werden, unabhängig
davon, welche Hardwarevorrichtungen in dem System vorhanden sind.
Als Gegenstände
haben sie eine Flexibilität über ledigliche
Datenspeicherung hinaus. Beispielsweise können Fahrzeugspezifikationen
in einer beliebigen Art von Wegen, wenn sie als ein Gegenstand vorliegen,
verknüpft
werden. Zusätzlich
zu der gegenwärtigen
"Herstellungsjahr-Modell"-Verknüpfung
erlauben es Gegenstände,
daß auf
Spezifikationen durch Her stellungsjahr-Betriebsmodell; durch Herstellungsjahr-Modell-Submodell;
durch Herstellungsjahr-Bereich-Modell-Submodell zugegriffen werden
kann.
-
Es sollte festgehalten werden, daß einige dieser
Objekte, z. B. Fahrzeugspezifikationen, Kundeninformation usw. Datenzugangsgegenstände bzw.
-objekte sind, die spezifisch bezeichnet sind, um als Datenbanken
verwendet zu werden. Datenzugangsgegenstände und -sammlungen stellen
ein Netzwerk zur Verwendung von Codes, um Komponenten des Datenbanksystems
auszubilden und zu manipulieren, zur Verfügung. Gegenstände und Sammlungen
haben Eigenschaften, welche die Charakteristika von Datenbankkomponenten
und Verfahren beschreiben, die zum Manipulieren bzw. Handhaben derselben
verwendet werden. Gemeinsam bilden diese Gegenstände und Sammlungen ein hierarchisches
Modell der Datenbankstruktur, welche durch die verschiedenen Programme
gesteuert bzw. geregelt ist.
-
Microsoft Foundation Classes (MFC)
unterstützt
zwei verschiedene Arten von Datenbankzugängen: Zugang über Data
Access Objects (DAO) und die Microsoft Jet Datenbank-Maschine, und
einen Zugang über
Open Database Connectivity (ODBC) und einen ODBC-Treiber. Beide
dieser Zufuhrabstraktionen vereinfachen ein Arbeiten mit Datenbanken,
gemeinsam mit der Geschwindigkeit, Leistung und Flexibilität von C++.
Beide integrieren die Datenzugangsarbeit mit dem MFC-Anwendungs-Netzwerk.
-
Es ist bevorzugt, ODBC-Klassen zu
verwenden, wenn strikt mit ODBC-Datenquellen gearbeitet wird, insbesondere
in Klient/Server-Situationen. Es ist bevorzugt, die DAO-Klassen
zu verwenden, wenn in erster Linie mit Microsoft Jet (.MDB) Datenbanken oder
mit anderen Datenbankformaten gearbeitet wird, die die Microsoft
Jet Datenbankmaschine direkt lesen kann. DAO erlaubt üblicherweise
eine reicheres Datenzugangsmodell aufgrund seines Supports von Data
Definition Language (DDL) ebenso wie von Data Manipulation Language
(DML).
-
Schließlich liegt auch die Anwendungssoftware 70,
welche in dem bevorzugten Fahrzeugradausrichtungssystem 100 als
Pro32 Visualiner Application bekannt ist, in Ring 2. Jedoch
unähnlich
zu HIB API 50 oder Windows API/MFC 60 ist die
Anwendungssoftware 70 ein Satz von Hauptanwendungsroutinen,
welche die Gegenstände
in Ring 2 aufrufen und an diesen betätigen. Die Anwendungssoftware 70 ist
der Hochniveausatz von Routinen, welcher Nachrichten hin und her
zu dem Windows-Kern 40 während jedem Kern-Zyklus verwenden.
Die Anwendungssoftware 70 ist jene Schicht des Programmierens,
welche die Funktionen durchführt,
die am meisten für
den Betätiger
sichtbar sind. Aufgrund der Multitasking-Fähigkeiten des WINDOWS 95 32-Bit
Betriebssystems kann der Windows-Kern 60 die Anwendungssoftware 70 zur
selben Zeit ausüben,
wie er einen anderen Softwareprozeß, der in Ring 2 liegt, ausübt.
-
In gleicher Weise kann der Windows-Kern 60 unterschiedliche
Teile von Anwendungssoftware 70 (d. h. unterschiedliche
Wege) auf einmal ausführen. Die
vorliegende Erfindung verwendet ein Multitasking in der Form von
mehreren bzw. mehrfachen Verfahren und mehrfach verkettete Codes.
Ein Verfahren ist eine Ausführungsanwendung,
die aus einem privaten, virtuellen Adreßraum, Code, Daten und anderen Betriebssystemressourcen,
wie Files, Rohren und Synchronisierobjekten besteht, welche an dem
Verfahren sichtbar sind. Ein Verfahren enthält eine oder mehrere Gruppen
von kleinen Programmbausteinen, welche in dem Kontext der Verfahrens
laufen. Eine Gruppe von kleinen Programmbausteinen ist eine Grundeinheit,
welcher das Betriebssystem CPU Zeit zuweist. Eine Gruppe von kleinen
Programmbausteinen kann jeden Teil des Anwendungscodes ausüben, umfassend
einen Teil, welcher gleichzeitig durch eine andere Gruppe von kleinen
Programmbausteinen ausgeführt
wird. Alle "threads" bzw. Gruppen von kleinen Programmbausteinen
eines Prozesses teilen den virtuellen Adreßraum, globale Variable und
Betriebssystemressourcen des Verfahrens. Dieser Mechanismus bildet
den Effekt einer simultanen Ausübung
von verschiedenen Teilen des Programms. Die Anwendungen sind gegenstandsorientiert
und anlaßgetrieben.
Die Multitasking- bzw. Mehraufgabentechniken verarbeiten bzw. handhaben
mehrere Aktivitäten,
wie gleichzeitige Sensorkommunikationen, Verwendereingaben, Datenmanipulationen,
Programmzustandsmanagement und konvexe, visuelle Kontrollen. Der
Vorteil dieser Technik ist es, mehrere Eingaben gleichzeitig handzuhaben,
was eine Echtzeitinstrumentierung zur Verfügung stellt. Die Programme sind
effizienter und schneller durch ein Verteilen von Aufgaben unter
mehreren Gruppen von kleinen Programmbausteinen für eine unabhängige Verarbeitung.
-
Die Anwendungssoftware 70 der
bevorzugten Ausbildungen ist programmiert, um das WIN32 Anwendungs-Programmier-Interface
(API) zu unterstützen.
Dies ist in der Form eines ausführbaren
Files mit einem 32-Bit Anwendungsgenerator (Compiler) generiert,
welcher ein ausführbares
File des Portable Executable Formats generiert. Der Microsoft Visual C++
Compiler (Version 2.0 oder später),
Microsoft Visual Basic, Borland Delphi und andere 32-Bit Anwendungsgeneratoren
können
verwendet werden. Die Kraftfahrzeugsservicesysteme der vorliegenden
Erfindung verwenden Microsoft Foundation Classes (MFC), um die Entwicklungszeit
zu reduzieren. Diese Klassen stellen eine einfachere Implementierung
des Graphik-Benutzer-Interface (GUI), des Datenzugangs und von allgemeinen
Betriebssystem-Interfaces zur Verfügung. Indem diese vorprogrammierten
Steuerungen bzw. Regelungen verwendet werden, ist weniger menschliche
Anstrengung erforderlich, um ein gut funktionierendes und vermarktbares Kraftfahrzeugservicesystem
zur Verfügung
zu stellen. Die Zeit von der Ausbildung bis zur Vermarktung ist
ebenfalls reduziert. Die Verwendung von gegenstandsorientierter
Programmierung erhöht
die Fähigkeit
der Software, beibehalten und ausgedehnt bzw. erweitert zu werden.
-
In einer Fahrzeugradausrichtungsanwendung
umfaßt
die Anwendungssoftware 70 eine Routine, welche die Signale überwacht,
die durch die Sensorköpfe
erzeugt werden. Wenn die Anwendungssoftware 70 eine Änderung
in dem Lenkwinkel von wenigstens einem lenkbaren Rad durch die Sensorköpfe und
zugehörige
Hardware und Treibersoftware detektiert, generiert bzw. erzeugt
die Anwendungssoftware 70 eine neue Gruppe kleiner Programmbausteine,
welche eine Nachlaufmessung ausführt.
Diese Gruppe von kleinen Programmbausteinen für die Nachlaufmessung werden
gleichzeitig mit der darunterliegenden Hauptroutine, die in der Anwendungssoftware 70 läuft, ausgeführt.
-
In einer weiteren Fahrzeugradausrichtungsausbildung
umfaßt
die Anwendungssoftware 70 eine Routine, welche diese Signale überwacht,
worin die Anwendungssoftware 70 eine neue Gruppe kleiner Programmbausteine
generiert, welche eine Unwuchtkompensationsroutine nach der Detektion
in der Rotation eines Fahrzeugsrads um seine Achse detektiert oder wenn
der Benutzer einen Knopf auf dem Sensorkopf drückt, um ein Unwuchtkompensationsverfahren
zu starten. Dieses Unwuchtkompensationsverfahren wird gleichzeitig
mit der darunterliegenden Hauptroutine in der Anwendungssoftware 70 ausgeführt. Die
zuvor erwähnten,
kleinen Gruppen von Datenbausteinen (Nachlaufmessung und Unwuchtkompensation)
scheinen für
den Betätiger
als "popup"-Schirme auf einer Fahrzeugradausrichtungsanzeige auf.
-
Die Anwendungssoftware 70 kann
eine Routine umfassen, um Echtzeit-Ausgabesignale auf der Anzeige
zu berechnen, beispielsweise graphische Maßstäbe, die Echtzeit-Fahrzeugwinkelmessungen im
Vergleich mit zugehörigen
Fahrzeugradausrichtungs-Spezifikationswerten zeigen. In dieser Ausbildung übt die Anwendungssoftware 70 auch
eine Gruppe von kleinen Programmbausteinen aus, die eine computerananimierte,
videographische Instruktion umfaßt, die dem Betätiger zeigt
und ihn dahingehend führt,
wie ein spezielles Ausrichtungsverfahren zum Korrigieren von jeglicher
Abweichung der Fahrzeugradausrichtungsmessungen vorgegangen werden
soll. Eine derartige Computeranimation kann Computergraphiken oder
ein tatsächliches
Video oder Filmmaterial voraufgezeichnet oder live umfassen. Wenn
sie live sind, kann die Videoabbildung beispielsweise eine Internetwendung
ActiveX Steuerung bzw. Regelung umfassen. Mit einem 32-Bit Betriebssystem
kann die Benutzung eines 1024 × 768 (oder
größer) Bildpunktanzeigefelds,
welches 16-Bit und/oder 24-Bit
(True Type) Farben anzeigt, ermöglicht
werden. Derartige Fähigkeiten
ermöglichen schärfer aussehende
Graphiken und lesbarere Symbol-Buchstabensätze, wie sie erforderlich sind,
um Buchstaben asiatischer Sprachen darzustellen.
-
Die Anwendungssoftware 70 kann
auch eine Routine umfassen, die es einem Betätiger ermöglicht, die Sequenz einzurichten,
in welcher computerunterstützte
bzw. -gesteuerte Kraftfahrzeugserviceverfahren durchgeführt werden.
In Anwendungen gemäß dem Stand
der Technik waren Anwender auf ein oder zwei Arten beschränkt, wie
sie das Kraftfahrzeugserviceeinrichtungsverfahren ausführten. In
einem System gemäß dem Stand
der Technik erforderte das Computerprogramm von einem Betätiger, daß er durch
einen unveränderbaren
Ablauf hindurchgeht, welcher jedes mal in derselben Sequenz bzw.
Reihenfolge durchgeführt
wurde. Beispielsweise kann in Fahrzeugradausrichtungsanwendungen
eine Unwuchtkompensation zuerst durchgeführt werden, gefolgt durch eine
Spurwinkeleinstellung, gefolgt durch Nachlaufschwenkmessungen usw.
Dies hatte den Nachteil, daß es
nicht veränderbar
war, wenn Anforderungen bzw. Erfordernisse des Servicetechnikers änderten.
In dem anderen System gemäß dem Stand
der Technik wurden dem Betätiger
Menüoptionen
(zufälliger
Modus) präsentiert
und der Betätiger
würde eine
oder mehrere dieser Optionen entsprechend den Erfordernissen auswählen. Dies
hatte den Nachteil, daß die
Kraftfahrzeugsserviceverfahren für
die Techniker vewirrend wurden, welche nicht geeignet trainiert
waren, und diese Verfahren entmutigend machten, wenn die Liste von
Menüoptionen
vervielfacht wurde.
-
Die Sequenzauswahl der vorliegenden
Erfindung überwindet
diese Nachteile. 3 zeigt
eine repräsentative
Schirmanzeige 200 des sequentiellen Kraftfahrzeugserviceverfahreneditors
der vorliegenden Erfindung. Die Schirmanzeige 200 umfaßt ein Prozeßquellenfenster 210 und
ein Prozeßsequenzbestimmungsfenster 220.
-
Im Betrieb umfaßt das Prozeßquellenfenster 210 eine
Sammlung von diskreten Kraftfahrzeugserviceeinrichtungsverfahren.
Die Prozeduren bzw. Verfahren können
gleichzeitig Fahrzeugradausrichtungsprozeduren, Motoranalyseverfahren,
Bremsentestverfahren oder jede Sammlung von gesonderten Verfahren
umfassen, für
welche die spezielle Computerhardware und -software des Systems
für eine Ausführung adaptiert
ist. Ein Betätiger
konstruiert, welche Sequenz auch immer erforderlich ist, in dem Prozeßablaufbestimmungsfenster 220,
beginnend mit einem ersten Fahrzeugserviceverfahrensschritt, Wiederholen
der Auswahl der Schritte, bis die gesamte Sequenz von Schritten
ausgewählt
ist, und dann Anzeigen an das System, daß die Sequenz vollständig ist.
In 3 zeigt das Verfahrenssequenzbestimmungsfenster 220,
die Schritte zuerst eines Zentrieren des Lenkwinkels bzw. des Lenkrads
und dann des Überprüfungskalibrierungsfaktorprozesses.
Diese Sequenz wird als ein Gegenstand in dem Windows API/MFC 60 gespeichert.
Auf die Sequenz wird dann durch die Anwendungssoftware 70 zugegriffen, welche
den Sequenzgegenstand verwendet, um die Routinen, umfassend einen
Gegenstand oder Gegenstände,
der bzw. die für
das Verfahren eines Zentrierens des Lenkens repräsentativ ist bzw. sind, und den Überprüfungskalibrierungsfaktorprozeß zu beginnen.
-
4 zeigt
ein Flußdiagramm
einer verallgemeinerten, sequenzierten Verfahrenskontrolle bzw. -steuerung.
Wie dies in 4 gezeigt
ist, ist die sequenzierte Verfahrenskontrolle als ein "Wizard" bezeichnet,
welcher für
die vorliegenden Zwecke als synonym mit "sequenzierter bzw. Sequenzprozeßsteuerung
bzw. -regelung" betrachtet werden soll. Ein Wizard entspricht einem
einzigen Gegenstand oder einem Scriptfile, enthaltend eine durch
den Betätiger vorprogrammierte
Kraftfahrzeugservicesequenz. Zuerst startet der Be
-
[SEITE FEHLT]
-
ren müssen. Insbesondere macht das
neue System jedes einzelne Stück
von geeignet programmierter PC-Hardware fähig, jede erdenkliche Kraftfahrzeugserviceeinrichtungsfunktion
durchzuführen.
Dies ist insbesondere für
eine kleine Reparaturwerkstatt vorteilhaft, welche nun auf einer
Maschine die Servicefunktionen durchführen kann, die bisher einige
Dutzend von verschiedenen, teuren Maschinen erforderten, durchführen. Wizardprozeduren bzw.
-verfahren können
vorab gewählt
werden, durch Präferenzen
gewählt
werden, durch den Betätiger gewählt werden,
mit einem bestimmten Fahrzeug verknüpft bzw. verbunden werden,
mit dem Betätiger verknüft werden
oder jede Kombination des Vorhergehenden sein. Sobald ein Wizardmodus
gewählt bzw.
aufgerufen ist, werden die Schritte durch den Wizard und die Betätigereingabe
für jeden
Schritt bestimmt.
-
In einer weiteren Ausbildung der
vorliegenden Erfindung umfaßt
die Softwareanwendung 70 Ausrüstungssicherheitsroutinen,
welche die Benutzung des Kraftfahrzeugeinrichtungssystems verfolgen
können.
In einem Aspekt erfordern diese Sicherheitsroutinen von einem Techniker,
sich einzuloggen und ein Paßwort
bzw. Codewort vor der Benutzung der Maschine einzugeben. In einem
weiteren Aspekt verfolgen die Sicherheitsroutinen die Maschinenverwendung,
wenn der Benutzer eingeloggt ist und bis er sich ausgeloggt hat.
Die gewonnene Information umfaßt
die Identität
des Benutzers, die Zeit, die für das
Durchführen
einer Aufgabe benötigt
wurde, die speziellen Aufgaben, die durchgeführt wurden, und andere Produktivitätsstatistiken.
Verschiedene Privilegienniveaus werden auch verwendet, so daß die Einrichtung
nur bis zu diesem Ausmaß freigegeben wird,
zu welchem ein Benutzer Zugang bei dem geeigneten Privilegienniveau
besitzt.
-
Die Installierungs- und Deinstallierungsmerkmale
des vorliegenden Kraftfahrzeugserviceeinrichtungssystems und die
Fileintegritätsüberprüfungsfähigkeit
werden nun erklärt.
-
Eine WINDOWS 32-Bit Anwendungssoftware-Installation
ist manchmal komplex. Unter den Komplexitäten besteht das Erfordernis,
daß Komponenten,
wie DLL und ActiveX Steuerungen bzw. Regelungen in dem Betriebsdirectory
zu registrieren sind. Wenn mehrere Anwendungen Quellen, wie DLLs
teilen, muß das
Register aktualisiert werden, um die mehrfache Benutzung der Quelle
bzw. Ressource zu zeigen, so daß,
wenn eine Anwendung gelöscht
wird, die Ressource nicht entfernt wird. AcktiveX Steuerungen bzw.
Regelungen, die durch die Anwendung verwendet werden, müssen in
dem Register registriert sein. Mittel müssen für den Installierer zur Verfügung gestellt
werden, um durch das ADD/REMOVE-Programm von dem Windows Control
Panel geführt
zu werden. Wenn die Software installiert wird, muß das Benutzerprivilegienniveau
angezeigt werden. Die Installationsprozesse können derart vereinfacht werden,
daß eine
nicht geübte
Person Kraftfahrzeugservicesystemsoftware, wie unten beschrieben,
installieren kann.
-
Das System der vorliegenden Erfindung kann
eine Installationsroutine verwenden, um die Software in die gewünschte Computerumgebung
zu installieren. Der Installierer bzw. die Installationsvorrichtung
ist ein graphisches Aktualisierungsprogramm, welches automatisch
den Benutzer durch das Installationsverfahren führt. Die Installationsvorrichtung
kopiert alle notwendigen Files von den Verteilungsmedien auf die
gewünschte
Computerumgebung. Die Installationseinrichtung macht Konfigurationsveränderungen,
wie Registrierungsveränderungen,
automatisch. Die Installationsvorrich tung installiert und registriert
alle Komponenten, wie DLLs, ActiveX Komponenten usw. Die Installationsvorrichtung stellt
Mittel für
die Software zur Verfügung,
um mit dem ADD/REMOVE-Programm von dem WINDOWS Control Panel installiert
zu werden. Die Installationsvorrichtung benützt das Betriebssystemregister,
um die installierten Komponenten zu registrieren. Der Hauptvorteil
der automatisierten Installationsvorrichtung ist jener, daß sie es
Benutzern ermöglicht,
die Systemsoftware selbst zu installieren, statt daß sie einen
Expertentechniker die Software installieren lassen müssen.
-
Die hier beschriebene Installationseinrichtung
arbeitet in einer 32-Bit Microsoft WINDOWS Umgebung und nutzt die
CD-ROM Autoplay-Merkmale
von WINDOWS 95, WINDOWS 98 und WINDOWS NT. Wenn die Verteilungs-CD
in dem CD-ROM-Treiber angeordnet wird, wird die Installationsroutine
automatisch für
die Ausübung
gestartet bzw. aufgerufen. Dies wird durch ein Anordnen des "AUTORUN.INF"
Files an dem Root Directory der CD durchgeführt, welche Instruktionen auszuführen hat, wenn
die CD eingeführt
wird. Der AUTORUN.INF File enthält
die folgenden Inhalte zum automatischen Starten der Setup- bzw. Aktualisierungsroutine.
-
[autorun]
öffnen = aktualisieren
-
Eine Implementierung der Installationseinrichtung
kann durch ein Programmieren in jeder Sprache durchgeführt werden,
da das Programm das Betriebssystems-Anwendungsprogrammier-Interface
nutzt, um diese Aufgaben auszuführen.
Dies würde
zeitaufwändig
sein und würde
extensive Wartungsarbeit erfordern, wenn jede Version der Software
herausgeben wird.
-
Ein effizienterer Weg zum Erreichen
desselben Effekts ist es, das Produkt INSTALLSHIELD von InstallShield
Corporation zu verwenden, welches visuell einen Benutzer durch das
Aktualisierungsverfahren führt.
Der Benutzer wählt
Files, DLLs, Registereinträge
usw. aus, die in der Computerumgebung zu installieren sind. Der
Werkzeugsatz macht dann ein Bild der Verteilungsmedien, die für eine Installation
erforderlich sind, welche auf die Verteilungsmedien kopiert sind.
-
Die Systeme der vorliegenden Erfindung können eine
vollautomatische Deinstallationsroutine verwenden, die Programmfiles,
Ordner und Registereintragungen von der installierten Umgebung entfernt,
mit der Ausnahme von Datenfiles und Ressourcen, die durch andere
Programme verwendet werden. Die Deinstallationseinrichtung entfernt
sich auch selbst. Die Deinstallationseinrichtung erlaubt es einem
ungeübten
Betätiger,
die Systemsoftware zu entfernen, ohne zufällig unbeabsichtigt bzw. unbewußt die falschen
Files zu entfernen und damit die anderen WINDOWS-Anwendungen zu
beeinflussen.
-
Ein Warten der Integrität eines
installierten Files wird durch ein Installieren eines Fileintetritäts-Überprüfungswerkzeugs
durchgeführt.
Da Software auf einem Festplattentreiber installiert ist, ist einer
Beschädigung
durch Magnetfelder unterworfen. Die Fileintegritäts-Überprüfungssoftware wird eine Aufzeichnung
der installierten Files, umfassend die Filegröße, Filedatum, Fileüberprüfungssumme
(Addition von allen Bytes in dem File), CRC (Cyclic Redundancy Check),
und ähnliche
Mittel einer Aufzeichnung von Filecharakteristika durchführen. Die
Aufzeichnung ist auf einer Zielinstallationsvorrichtung gesichert
und auf einer Vorrichtung eines entfernbaren Mediums rückgesichert.
Die Fileintegritäts-Überprüfungssoftware
wird die aufgezeichnete Information verwenden, um die Integrität bzw. Vollständigkeit von
jedem File zu überprüfen. Sie
kann als ein diagnostisches Werkzeug laufen bzw. verwendet werden kann,
wann immer ein Problem mit der installierten Software auftritt,
jedesmal, wenn das System gestartet wird, oder jedesmal, wenn es
gewünscht
ist.
-
Gegenwärtig erlauben es die Fahrzeugradausrichtungssysteme
einem Betätiger,
die Ausrichtungseinrichtung für
ein Arbeiten zu kalibrieren, um auf einer oder mehreren Ausrichtungsoberflächen (d. h.
Gestell) zu arbeiten. Wenn eine Ausrichtung auf einer neuen Oberfläche ausgeführt wird,
verschiebt der Betätiger
lediglich die Bezeichnung innerhalb der Anwendungssoftware, so daß das System
die geeigneten Kalibrierungsfaktoren verwenden wird. Jedoch sind
gegenwärtig
den Ausrichtungsoberflächen
nicht veränderbaren
Namen zugewiesen. Dies bewirkt eine Konfusion bzw. Verwirrung dahingehend,
welche Ausrichtungsoberfläche
jedem Namen zugewiesen ist.
-
Eine neue Softwareanwendung 70 wird
zur Verfügung
gestellt, welche eine Softwareroutine umfaßt, die es einem Betätiger erlaubt,
einen Namen zu jeder Ausrichtungssoftware zuzuweisen. So können Benutzer
unterschiedliche Ausrichtungsoberflächen mit unterschiedlichen,
einfach in Erinnerung zu rufenden Namen assoziieren. Das Namenssystem
wird zu weniger Konfusion führen,
wenn der Betätiger
es wünscht,
zwischen Ausrichtungsoberflächen
zu schalten. Der Ausrichtungsoberflächenname wird gesichert und
von einem nicht flüchtigen
Speichermedium, wie einem Festplattentreiber zurück bzw. wieder aufgerufen.
-
Die Softwareanwendung 70 kann
eine Softwareroutine umfassen, welche eine angenehme Wiederherstellung
nach einem Leistungsverlust ermöglicht.
Dies wird durch kontinuierliches oder periodisches Sichern von neu
gewonnenen Daten in eine Datenbank durchgeführt. Beispielsweise werden Kundendaten,
ursprüngliche
Ablesungen, Endablesungen und andere Schlüsselinformation unmittelbar auf
einen nicht-flüchtigen
Speicher gespeichert. Wenn die Fahrzeugserviceeinrichtung gestartet
wird, lädt
sie die zuletzt gesicherten Daten von der Datenbank herunter. Eine
neue Aufzeichnung wird in der Datenbank nur dann erzeugt, wenn eine
neue Ausrichtung gewählt
ist.