-
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 Unwuchtkompensatiorsverfahren, 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 2 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. Ein Umluftkorrekturverfahren
wird 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 zweite
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, 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 nutzer den Wizard-Modus, welcher eine Gruppe
von kleinen Programmbausteinen innerhalb der Softwareanwendung 70 ist.
Als nächstes wählt der
Betätiger
einen speziellen Wizard, der für die
Ausübung
gewünscht
ist. Eine Scriptbibliothek wird dem Betätiger auf einer Anzeige präsentiert
und der Betätiger
wählt einen
von der Biblikothek. Dann beginnt die Softwareanwendung 70 die
Wizardmaschinen-Gruppenverarbeitung, welche ein Steuer- bzw. Regelprogramm
ist, welches sicherstellt, daß die
geeignete Sequenz gemäß dem gewählten Script durchgeführt wird.
Standardmäßige Windows-Steuerungen
bzw. -Regelungen werden verwendet, um den Wizard zu navigieren,
umfassend Next, Back, Skip und Quit-Buttons. Sobald alle Schritte
in einer Sequenz vervollständigt
sind, zeichnet die Softwareanwendung 70 die Ergebnisse
auf und speichert sie vorzugsweise in einer Kundendatenbank, welche mehrere
Gegenstände
umfassen kann, von welchen jeder für einen speziellen Kunden repräsentativ
ist. Sobald diese Aufgabe beendet ist, ist die Hauptroutine der
Softwareanwendung 70 zu Ende.
-
Diese
sequenzielle Editierfähigkeit
kombiniert die vorteilhaften Merkmale der Fahrzeugserviceeinrichtungssysteme
gemäß dem Stand
der Technik, während
die Nachteile eliminiert werden. Ebenso wie mit dem sequenziellen
Modus gemäß dem Stand der
Technik kann ein Betätiger
eine Kraftfahrzeugservicesequenz in der geeigneten Reihenfolge ausüben, ohne
das Erfordernis für
spezielle Entscheidungen oder ein Expertentraining. Und wie bei
den menügesteuerten
Zufallsmodus-Systemen kann der Betätiger, falls notwendig, die
Reihenfolge, in welcher die Sequenz auftritt, auswählen. Dieses
neue System erlaubt auch einem Servicemanager, die Verfahren und die
Sequenzen zu erzeugen, die ihrer oder seine Autoservicetechniker
mit einem speziellen Ausrüstungsstück ausfüh 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.