-
Erfindungsgebiet
-
Die
vorliegende Erfindung betrifft allgemein die elektronische Datenverarbeitung
und betrifft insbesondere Verfahren, Computerprogrammprodukte und
Systeme für
die Materialbedarfsplanung (MRP – material requirements planning).
-
Allgemeiner
Stand der Technik
-
Einige
Computersysteme wie etwa beispielsweise Enterprise-Resource-Planning-(ERP)-Systeme
oder Supply-Chain-Management-(SCM)-Systeme
unterstützen
Funktionen zum Planen des Materialbedarfs für die Produktion. Komplexe
Produkte, die viele Komponenten enthalten, weisen in der Regel große Auftragsstücklisten
(BOM – bills
of materials) auf. Eine Auftragsstückliste enthält alle
Komponenten eines Produkts in einer hierarchischen Struktur. Die
Hierarchie zeigt für
jede Komponente an, für
welche Hauptkomponente sie benötigt
wird. Eine Hauptkomponente kann mehrere Unterkomponenten aufweisen.
Wenn die Materialbedarfsplanung für mehrere Produkte ausgeführt wird,
werden mehrere BOMs gleichzeitig verarbeitet, weil einige der Produkte möglicherweise
die gleichen Komponenten verwenden. Zur Planung dieser Komponenten,
die von mehreren Produkten verwendet werden, müssen deshalb die Anforderungen
durch jedes der Produkte berücksichtigt
werden.
-
Einige
Systeme setzen Parallelisierung ein, um bei gleichzeitiger Planung
mehrerer Produkte eine riesige Datenmenge zu bewältigen. Um sicherzustellen,
daß alle
Anforderungen für
eine spezifische Komponente berücksichtigt
worden sind, erstellen einige Systeme eine Datenstruktur, die die
BOMs aller Produkte enthält,
die der Materialbedarfsplanung unterworfen werden, und führt in dieser
Datenstruktur Planungsebenen ein. Innerhalb einer Planungsebene
werden alle Komponenten geplant, bevor sich das System zur nächsten Planungsebene weiterbewegt.
Dies garantiert, daß alle
Anforderungen der vorausgegangenen Planungsebene berücksichtigt
werden. Ein derartiges System wird in der internationalen Patentanmeldung
WO 94/01826 beschrieben.
-
Bei
Einsatz von Parallelisierung kann es jedoch dazu kommen, daß mit Ausnahme
einer Komponente einer Planarisierungsebene alle bereits geplant
sind und das System wegen der einen noch ungeplanten Komponente
nicht zur nächsten
Planungsebene weitergehen kann. Infolgedessen ist nun nur ein Prozeß aktiv,
während
die letzte Komponente einer Planungsebene geplant wird, wohingegen
andere parallele Prozesse untätig
sind.
-
Die
untätigen
Prozesse müssen
warten, bis der letzte Prozeß abschließt, bevor
die parallele Verarbeitung auf der nächsten Planungsebene weitergehen
kann. Die Warteperiode kann lang sein. Im Fall von konfigurierbaren
Produkten existieren individuelle Kundenanforderungen auf mehr als
nur der letzten Produktebene, was Wartezeiten bei mehreren Planungsebenen
verursachen kann. Wenn beispielsweise das Endprodukt eine Küche ist,
kann ein Einlegeboden enthalten sein, der als Komponente auch in fast
jeder anderen Küche
des Küchenherstellers
enthalten ist. Wenn Aufträge
für verschiedene
Küchen vorliegen,
die in dem MRP Anforderungen für
den gleichen Boden erzeugen, kann dieser Boden somit in der MRP
zu einem Langläufer
werden, der stundenlang einen Prozeß belegt und die anderen Prozesse
warten läßt, bevor
es zu der nächsten
Planungsebene weitergeht.
-
Solche
Langläufer
finden sich üblicherweise auf
verschiedenen Planungsebenen, sie können mehrere Barrieren für die parallele
Planung bilden.
-
Aus
der Patentanmeldung
EP 0992868 ist ein
MRP-System bekannt, das mehrere parallel angeordnete Material-/Mengenbedarfsplanungs-(MRP)-Arithmetikvorrichtungen
enthält.
Eine MRP-Arithmetikvorrichtung bestimmt arithmetisch eine erforderliche
Nettomenge eines gegebenen Artikels zur Lieferung der erforderlichen
Nettomenge nach Bestimmung durch die anderen MRP-Arithmetikvorrichtungen.
Die MRP-Arithmetikvorrichtungen führen eine
teilebasierte Expansionsarithmetik jeweils parallel für zugeordnete
einzelne von mehreren Unterartikeln durch, die den Artikel auf der
Basis der erforderlichen Nettomenge des Artikels darstellen. In einer
für Arithmetik
zugänglichen
Artikelmanagementeinheit ist ein Bestandszähler vorgesehen, der den verarbeiteten
niedrigen Bestand anzeigt.
-
Das
US-Patent 6,122,560 schlägt
vor, die Verarbeitungszeit für
eine Materialanforderungsberechnung zu reduzieren durch Ausführen eines
parallelen Prozesses ohne Verwendung herkömmlicher Niedrigbestandscodes.
Teileberechnungsmittel sind jeweils Artikeln zugeordnet. Wenn das
Unterteileberechnungsmittel das Rechenergebnis des Oberteileberechnungsmittels
erhält,
führt es
den Berechnungsprozeß unabhängig aus,
wenn das Rechenergebnis für
die Teileberechnung ausreicht.
-
Die
letzteren Lösungen
basieren auf einer komplexen Softwarearchitektur, wo Berechnungsmittel
jedem Artikel zugeordnet sind, wodurch viel Speicher verbraucht
wird. Angesichts der Tatsache, daß Auftragsstücklisten
Tausende von Komponenten enthalten können, kann Speicher ein kritischer
Faktor werden.
-
Kurze Darstellung der
Erfindung
-
Ein
allgemeiner Aspekt der Erfindung besteht in der Bereitstellung eines
Verfahrens, eines Computersystems und eines Computerprogrammprodukts
zum Reduzieren von MRP-Laufzeiten auf der Basis einer weniger komplexen
Softwarearchitektur. Erzielt wird dies durch Ausführungsformen
der Erfindung gemäß den unabhängigen Ansprüchen 1, 9
und 10.
-
Erzielt
wird dies durch folgendes: Laden mehrerer Auftragsstücklisten
in eine Datenstruktur;
Analysieren von Haupt/Unterkomponenten-Beziehungen
zwischen Komponenten der mehreren Auftragsstücklisten in der Datenstruktur,
wobei die Haupt-/Unterkomponenten-Beziehungen in der Datenstruktur
Planungsebenen für
die Komponenten definieren;
wobei eine Materialbedarfsplanungs-Engine
für jede Komponente
in der Datenstruktur einen Zählerwert setzt,
der die Anzahl der Hauptkomponenten für jede Komponente angibt;
wobei
die Materialbedarfsplanungs-Engine den Zählerwert einer spezifischen
Unterkomponente dekrementiert, wenn das Planen einer Hauptkomponente der
spezifischen Unterkomponente abgeschlossen ist; und
wobei die
Materialbedarfsplanungs-Engine die Planung der spezifischen Unterkomponente
fortsetzt, wenn der assoziierte Zählerwert angibt, daß das Planen
aller Hauptkomponenten der spezifischen Unterkomponente abgeschlossen
ist, wobei die Hauptkomponenten Planungsebenen aufweisen, die der Planungsebene
der spezifischen Unterkomponente übergeordnet sind, und paralleles
Fortsetzen der Planung weiterer Komponenten auf der Planungsebene der
Unterkomponente übergeordneten
Planungsebenen.
-
Durch
Einführen
von mit Komponenten assoziierten Zählern kann das Computersystem über die Fortsetzung
der Planung von Komponenten auf einer Basis Komponente für Komponente
entscheiden während
es weiterhin auf einer weniger komplexen Softwarearchitektur basiert.
Die Notwendigkeit für Planungsebenen
zur Sicherstellung der Vollständigkeit
der Planung von übergeordneten
Komponenten entfällt.
Die Parallelisierung von MRP-Läufen kann effizienter
eingesetzt werden, weil Wartezeiten von untätigen Prozessen vermieden werden
können.
-
Die
Aspekte der Erfindung werden mit Hilfe der Elemente und Kombinationen
realisiert und erreicht, auf die in den beigefügten Ansprüchen besonders hingewiesen
wird. Es versteht sich, daß sowohl die
vorausgegangene allgemeine Beschreibung als auch die folgende ausführliche
Beschreibung lediglich beispielhaft und erläuternd sind und keine Einschränkung für die Erfindung
wie beansprucht darstellen.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein vereinfachtes Blockschaltbild eines Computersystems für die Materialbedarfsplanung;
-
2 bis 4 zeigen
einen Abschnitt einer Datenstruktur, der mit einer Ausführungsform
der Erfindung zu verschiedenen Zeitpunkten verwendet werden kann;
und
-
5 ist
ein Implementierungsbeispiel der Datenstruktur als eine nichtrelationale
Tabelle.
-
Ausführliche
Beschreibung der Erfindung
-
1 ist
ein vereinfachtes Blockschaltbild eines Computersystems 900 für die Materialbedarfsplanung.
-
Das
Computersystem 900 enthält
eine erste Speicherungskomponente 200, die mehrere Auftragsstücklisten
speichert, wobei jede Auftragsstückliste
mit einem Produkt assoziiert wird, das einer Materialbedarfsplanung
(MRP) unterzogen werden kann. Die erste Speicherungskomponente wird
auch als mehrere (200) BOMs bezeichnet.
-
Weiterhin
enthält
das Computersystem 900 eine zweite Speicherungskomponente 300,
die dazu verwendet wird, eine Datenstruktur zu speichern, wobei
die Auftragsstücklisten,
die mit Produkten assoziiert sind, die einer MRP unterzogen werden,
durch eine Schnittstelle 503 geladen werden können. Die zweite
Speicherungskomponente wird ebenfalls als die Datenstruktur 300 bezeichnet.
In der Datenstruktur 300 kann eine Unterkomponente mehrere
Hauptkomponenten ausweisen, die zu mehreren BOMs gehören. Mit
anderen Worten wird die Datenstruktur 300 dazu verwendet,
Haupt-/Unterkomponenten-Beziehungen zwischen Hauptkomponenten verschiedener
BOMs und einer Unterkomponente, die von diesen Hauptkomponenten
verwendet wird, herzustellen. Infolgedessen lernt die Unterkomponente über Anforderungen
von mehreren Hauptkomponenten, die von mehreren Produkten herrühren. Zudem
wird die Unterkomponente einmal in der Datenstruktur 300 gespeichert,
anstelle der redundanten Speicherung in mehreren 200 der
BOMs, wo die Unterkomponente in der BOM eines jeden Produkts enthalten ist,
die die Unterkomponente verwendet. Beispielsweise können die
mehreren 200 BOMs als ein Speicherabschnitt implementiert
werden, der Tabellen mit spezifischen Spalten zum Speichern von
Haupt- und Unterattributen für
jede Komponente einer BOM enthält.
Der Speicherabschnitt kann Teil einer Datenbank oder kann Teil des
Hauptspeichers des Computersystems 900 sein.
-
Die
Datenstruktur 300 kann auch als ein Speicherabschnitt implementiert
sein. Bevorzugt wird die Datenstruktur 300 in dem Hauptspeicher
gespeichert, weil der Zugriff auf die Datenstruktur 300 während des
MRP-Laufs schneller ist als ein Datenbankzugriff es sein würde.
-
Der
MRP-Lauf wird einer MRP-Engine 100 gesteuert, die eine
Schnittstelle 502 zu den mehreren 200 BOMs und eine weitere
Schnittstelle 501 zur Datenstruktur 300 aufweist.
-
Beispielsweise
steuert die MRP-Engine, welche BOMs von den mehreren 200 BOMs
in die Datenstruktur 300 geladen werden. Die MRP-Engine kann
die Haupt-/Unterkomponenten-Beziehungen zwischen Komponenten der
mehreren 200 von BOMs in der Datenstruktur 300 analysieren,
um die oben erläuterten
Haupt-/Unterkomponenten-Beziehungen zwischen Hauptkomponenten der
verschiedenen BOMs und einer Unterkomponente, die von diesen Hauptkomponenten
verwendet wird, herzustellen.
-
Die
MRP-Engine kann als ein Computerprogramm implementiert werden, das
in den Speicher des Computersystems geladen und von mindestens einem
Prozessor des Systems 900 ausgeführt wird. Weitere Funktionen
der MRP-Engine werden zusammen mit den folgenden Figuren erläutert.
-
2 ist
ein Abschnitt der Datenstruktur 300 zu einem ersten Zeitpunkt,
nachdem die Datenstruktur von der MRP-Engine 100 darauf
vorbereitet worden ist, in einem MRP-Lauf gemäß der vorliegenden Erfindung
verwendet zu werden.
-
Nachdem
die MRP-Engine 100 die Haupt-/Unterkomponenten-Beziehungen zwischen den
Komponenten der mehreren 200 BOMs analysiert hat, werden
die Haupt-/Unterkomponenten-Beziehungen 310 in der Datenstruktur 300 hergestellt. Die
Haupt-/Unterkomponenten-Beziehungen 310 in der Datenstruktur 300 gestatten,
daß eine
Unterkomponente A2 mehrere Hauptkomponenten F1, F2 aufweist. Beispielsweise
können
die Komponenten F1, F2 Endprodukten entsprechen.
-
F1
enthält
die Unterkomponenten A1, A2, die Teilbaugruppen entsprechen können. A2
enthält
weiterhin die Unterkomponenten R1, R2, die Rohmaterialien entsprechen
können.
Weiterhin sind zur einfachen Darstellung weitere Teilbaugruppen
oder Rohmaterialien, die zu F1 gehören, nicht gezeigt.
-
F2
enthält
außerdem
die Unterkomponente A2. Deshalb weist A2 zwei Hauptkomponenten auf.
-
Nachdem
die Haupt-/Unterkomponenten-Beziehungen 310 in der Datenstruktur 300 hergestellt
worden sind, tastet die MRP-Engine 100 die Datenstruktur 300 ab
und setzt einen Zählerwert
CV für
jede Komponente in der Datenstruktur 300. Jeder Zähler gibt
die Anzahl der Hauptkomponenten für die entsprechende Komponente
an. Die Endprodukte F1, F2 weisen keine Hauptkomponenten auf. Deshalb
werden die entsprechenden Zählerwerte
auf CV = 0 gesetzt. Die Teilbaugruppe A1 weist die Hauptkomponente
F1 auf. Deshalb wird ihr Zählerwert
auf CV = 1 gesetzt. Die Teilbaugruppe A2 weist die Hauptkomponenten
F1 und F2 auf. Deshalb wird ihr Zählerwert auf CV = 2 gesetzt.
Die Rohmaterialien R1 und R2 weisen die Hauptkomponente A2 auf. Deshalb
werden die entsprechenden Zählerwerte
auf CV = 1 gesetzt.
-
Zu
diesem Zeitpunkt wurde an keiner der Komponenten eine Planung durchgeführt, was
durch leere Kreise dargestellt ist.
-
3 zeigt
den Abschnitt der Datenstruktur 300 zu einem zweiten Zeitpunkt,
nachdem der MRP-Lauf begonnen hat. Zum zweiten Zeitpunkt ist die
Komponente F2 erfolgreich geplant worden. Dies ist durch ein schraffiertes
Muster veranschaulicht.
-
Die
MRP-Engine 100 dekrementiert die Zählerwerte der Unterkomponenten
von F2 nach dem Abschluß der
Planung von F2. Bei dem Beispiel wird der Zählerwert der spezifischen Unterkomponente A2
von CV = 2 auf CV = 1 dekrementiert.
-
4 zeigt
den Abschnitt der Datenstruktur 300 zu einem dritten Zeitpunkt
während
des MRP-Laufs. Zum dritten Zeitpunkt war das Planen der Komponente
F1 abgeschlossen (durch das schraffierte Muster dargestellt).
-
Folglich
dekrementiert die MRP-Engine 100 die Zählerwerte der Unterkomponenten
von F1. Bei diesem Beispiel werden die Zählerwerte der spezifischen
Unterkomponenten A2 und A1 auf CV = 0 dekrementiert. Der mit der
spezifischen Unterkomponente A2 assoziierte Zählerwert CV = 0 gibt der MRP-Engine
an, daß für die spezifische
Unterkomponente A2 von keiner ihrer Hauptkomponenten F1, F2 irgendwelche
weiteren Planungsanforderungen zu erwarten sind, weil die Planung
der Hauptkomponenten F1, F2 abgeschlossen ist. Deshalb kann die MRP-Engine
mit der Planung der spezifischen Unterkomponente A2 fortfahren.
-
5 ist
ein Beispiel für
eine Ausführungsform
der Datenstruktur 300. Bei diesem Beispiel wird die Datenstruktur 300 als
eine nichtrelationale Tabelle unter Verwendung von Zeigern implementiert,
um die Haupt-/Unterkomponenten-Beziehungen 310 zwischen Komponenten
widerzuspiegeln.
-
Jede
Zeile der Tabelle 300 bezieht sich auf eine Komponente in der Datenstruktur.
Die Beziehungszeiger 310 weisen von einer Hauptkomponente
auf ihre Unterkomponenten. Gleichermaßen können die Zeiger so implementiert
werden, daß sie
von Unterkomponenten auf ihre Hauptkomponenten weisen.
-
Beispielsweise
kann die Tabelle 300 auf einer Materialhaupttabelle eines Anwendungssystems basieren.
Eine Materialhaupttabelle enthält
in der Regel Hauptdaten für
jede Komponente (z.B. Maßeinheit,
Chargengröße, usw.),
die von dem Anwendungssystem gehandhabt wird.
-
Durch
Hinzufügen
der Beziehungszeiger 310 zu der Materialhaupttabelle stehen
die BOM-Informationen und die Materialhauptdateninformationen in einer
einzelnen Datenstruktur zur Verfügung.
Während
des MRP-Laufs braucht deshalb von der MRP-Engine nur auf die Datenstruktur
(Tabelle 300) zurückgegriffen
zu werden. Dies reduziert die Gesamtdatenzugriffszeit.
-
Bei
dem Beispiel weist die Tabelle 300 eine Komponentenspalte
zum Speichern einer Komponenten ID (z.B. F1, F2, A1 usw.), eine
Planungsebenenspalte, eine Zählerwertspalte
und eine Planungsflagspalte auf.
-
Die
Zählerwertspalte
speichert für
jede Komponente den assoziierten Zählerwert CV, der wie in 2 bis 4 beschrieben
berechnet wird. 5 veranschaulicht den Zustand
der Datenstruktur zum ersten Zeitpunkt (siehe 2).
-
Die
Planungsflagspalte gibt für
jede Komponente an, ob die Komponente MRP unterliegt oder nicht.
Beispielsweise setzen einige ERP-Systeme ein Planungsflag für eine spezifische
Komponente nur dann, wenn sich bezüglich der Anforderungen für diese
Komponente irgend etwas geändert
hat. Dies kann eintreten, wenn die Auftragsgröße für ein spezifisches Produkt,
das die spezifische Komponente verwendet, geändert wird oder wenn weitere
Aufträge
für Produkte,
bei denen die spezifische Komponente verwendet wird, in das System
eingegeben oder aus dem System gelöscht werden. Jeder dieser Fälle hat
eine Auswirkung auf die Anforderungen für die spezifische Komponente
und führt
deshalb zum Setzen eines entsprechenden Planungsflags in der Tabelle 300.
Bei Ausführung
des MRP-Laufs wie in 2 bis 4 beschrieben,
kann die MRP-Engine die Zählerwerte
nur für
jene Komponenten mit einem Planungsflag setzen. Weiterhin kann bei
dieser Implementierung die MRP-Engine
nur dann mit der Planung einer Unterkomponente fortfahren, wenn
die Unterkomponente ein Planungsflag aufweist. Der Vorteil bei der
Verwendung des Planungsflags besteht darin, daß die MRP-Engine im Voraus
jede Komponente in der Tabelle 300 kennt, die von dem MRP-Lauf
nicht beeinflußt
wird. Deshalb kann die MRP-Engine jede Komponente ohne ein Planungsflag
ignorieren.
-
Die
Werte der Planungsebenenspalte dieser Implementierung können erhalten
werden, indem die Haupt-/Unterkomponenten-Beziehungen in der Datenstruktur
zum Definieren einer Planungsebene für jede Komponente verwendet
werden. Wie Planungsebenen definiert werden, ist in der Technik
bekannt und beispielsweise in dem SAP-Trainingskurs „LO050:
PP-Planning" oder
dem SAP-Workshop „EWC10:
Technical optimisation of the Availability Check" dokumentiert.
-
Bei
einer Ausführungsform
der Erfindung kann die MRP-Engine
mit der Planung der spezifischen Unterkomponente A2 fortfahren,
die zu einer Planungsebene 1 gehört,
die der Planungsebene 0 mindestens einer der entsprechenden Hauptkomponenten
F1, F2 untergeordnet ist, selbst wenn die Planung weiterer Komponenten
auf der Planungsebene 0 der mindestens einen entsprechenden Hauptkomponente
unvollständig
ist. Dadurch kann die MRP-Engine von einer Parallelisierung profitieren, weil
die Planung der Unterkomponente auf der untergeordneten Planungsebene
durch einen ersten Prozeß ausgeführt werden
kann, während
die Planung weiterer Komponenten auf übergeordneten Planungsebenen
durch mindestens einen zweiten Prozeß parallel ausgeführt werden
kann. Ohne das Konzept des Dekrementierens assoziierter Zähler von Unterkomponenten
(siehe 2 bis 4) würde der erste Prozeß zu warten
haben, bis die weiteren Prozesse auf den übergeordneten Planungsebenen abgeschlossen
sind.
-
Außerdem kann
jede Komponente ein weiteres Attribut zum Speichern einer Zeitstatistik
aufweisen, wo die Planungsdauer des vorausgegangenen MRP-Laufs für die Komponente
aufgezeichnet wird. In der Tabelle 300 entspricht das weitere
Attribut einer weiteren Spalte. In diesem Fall können Feststellungen über die
wahrscheinliche Planungsdauer für jede
Komponente von der MRP-Engine aus einer Vorhersage auf der Basis
des vorausgegangenen MRP-Laufs hergeleitet werden, da MRP-Läufe in einer Firma üblicherweise
im allgemeinen ähnlich
sind.
-
Komponenten
können
zur optimierten parallelen Verarbeitung zu Paketen gebündelt werden. Beispielsweise
können
Komponenten gebündelt
werden, so daß Langläufer mit
Kurzläufern
gruppiert werden. Die ungefähren
MRP-Laufzeiten für die Pakete können im
Voraus berechnet werden, um ihre Gruppierung zu verbessern und eine
gleichzeitige Beendigung aller Prozesse zu approximieren. Die MRP-Laufzeit
ist proportional zur Anzahl der Planungselemente, wie etwa beispielsweise
geplante Aufträge,
Bestellanforderungen, Lieferplanlinien usw., die während des
Planungslaufs erstellt werden sollen. Die Anzahl der Planungselemente
pro Produkt hängt
von verschiedenen Planungsmechanismen ab, wie etwa der Chargenbemessungsprozedur und/oder
der Anzahl der Anforderungen (z.B. Verkaufsaufträge, Vorhersagenanforderungen)
und ändert
sich im Laufe der Zeit nicht viel. Die Anzahl der Planungselemente
pro Produkt kann zur späteren Verwendung
in einer Planungsdatei gespeichert werden. Die Pakete können dann
so gebaute Pakete sein, daß eine
vordefinierte Anzahl von Planungselementen in jedem Paket erstellt
wird. Beispielsweise können
in einer SAP APO-PP/DS-Anwendung
gute Leistungsergebnisse erzielt werden, wenn jedes Paket etwa 100
Planungselemente erstellt. Komplexe Planungselemente erfordern möglicherweise
kleinere Pakete.
-
Ausführungsformen
der Erfindung können
in digitalen Elektronikschaltungen oder in Computerhardware, Firmware,
Software oder in Kombination aus diesen implementiert werden. Die
Erfindung kann als ein archivierendes Computerprogrammprodukt implementiert
werden, das heißt
ein Computerprogramm, das greifbar in einem Informationsträger verkörpert ist,
z.B. in einer maschinenlesbaren Speicherungseinrichtung oder in
einem ausgebreiteten Signal, zur Ausführung durch eine Datenverarbeitungsvorrichtung
oder zum Steuern ihrer Operation (als Beispiel), einem programmierbaren
Prozessor, einem Computer oder mehreren Computern. Ein archivierendes
Computerprogramm kann in jeder Form von Programmierungssprache geschrieben
werden, einschließlich
kompilierender oder interpretierender Sprachen, und es kann in jeder
Form eingesetzt werden, einschließlich als ein selbständiges Programm oder
als ein Modul, eine Komponente, eine Subroutine oder andere Einheit,
die sich zur Verwendung in einer Rechnerumgebung eignet. Ein Computerprogramm
kann dafür
eingesetzt werden, auf einem Computer oder auf mehreren Computern
an einem Ort oder über
mehrere Orte verteilt und durch ein Kommunikationsnetz verbunden
ausgeführt
zu werden.
-
Verfahrensschritte
der Erfindung können durch
einen oder mehrere programmierbare Prozessoren ausgeführt werden,
die ein Computerprogramm durchführen,
um Funktionen der Erfindung auszuführen, indem eingegebene Daten
bearbeitet und eine Ausgabe erzeugt wird. Verfahrensschritte können außerdem durchgeführt, und
Vorrichtungen der Erfindung können
implementiert werden, als Speziallogikschaltungen (als Beispiel),
ein FPGA (frei programmierbares Gatearray) oder eine ASCI (anwendungsspezifische
integrierte Schaltung).
-
Für die Durchführung eines
Computerprogramms geeignete Prozessoren enthalten beispielhaft sowohl
Allzweck- als auch Spezialmikroprozessoren und einen oder mehrere
beliebige Prozessoren einer beliebigen Art von Digitalcomputer.
Allgemein empfängt
ein Prozessor Anweisungen und Daten von einem Festwertspeicher oder einem
Direktzugriffsspeicher oder beiden. Die wesentlichen Elemente eines
Computers sind mindestens ein Prozessor zum Ausführen von Anweisungen und eine
oder mehreren Speichereinrichtungen zum Speichern von Anweisungen
und Daten. Ein Computer wird im allgemeinen auch eine oder mehrere
Massenspeicherungseinrichtungen zum Speichern von Daten enthalten,
z.B. magnetische, magnetooptische Platten oder optische Platten,
oder operativ gekoppelt sein, um Daten von diesen zu empfangen oder
Daten zu diesen zu übertragen
oder beides. Für
das Ausführen von
Computerprogrammanweisungen und Daten geeignete Informationsträger enthalten
alle Formen von nichtflüchtigem
Speicher, einschließlich
beispielsweise Halbleiterspeichereinrichtungen, z.B. EPROM, EEPROM
und Flashspeichereinrichtungen; Magnetplatten, z.B. interne Festplatten
oder entfernbare Platten; magnetooptische Platten und CD-ROM- und DVD-ROM-Platten.
Der Prozessor und der Speicher können
durch Speziallogikschaltungen ergänzt oder in diese integriert
sein.
-
Um
für eine
Interaktion mit einem Benutzer zu sorgen, kann die Erfindung auf
einem Computer mit einer Displayeinrichtung, z.B. einem Kathodenstrahlröhren-(CRT) oder Flüssigkristalldisplay-(LCD)-Monitor
zum Anzeigen von Informationen für
den Benutzer und einer Tastatur und einer Zeigeeinrichtung, z.B.
einer Maus oder einem Trackball, über die der Benutzer Eingaben
zu dem Computer liefern kann, implementiert werden. Es können auch andere
Arten von Einrichtungen verwendet werden, um für eine Interaktion mit einem
Benutzer zu sorgen; beispielsweise kann eine dem Benutzer gelieferte Rückkopplung
beliebiger Form von sensorischer Rückkopplung vorliegen, z.B.
visuelle Rückkopplung, auditorische
Rückkopplung
oder taktile Rückkopplung;
und Eingabe von dem Benutzer kann in beliebiger Form empfangen werden,
einschließlicher
akustischer, Sprach- oder taktiler Eingabe.
-
Die
Erfindung kann in einem Rechnersystem implementiert werden, das
eine Back-end-Komponente enthält,
z.B. als ein Datenserver, oder das eine Middleware-Komponente enthält, z.B.
einen Applikationsserver, oder das eine Front-End-Komponente enthält, z.B.
einen Client-Computer
mit einer graphischen Benutzerschnittstelle oder einen Web-Browser, über den
ein Benutzer mit einer Implementierung der Erfindung interagieren
kann, oder eine beliebige Kombination aus solchen Back-end, Middleware- oder
Front-end-Komponenten. Die Komponenten des Systems können durch
eine beliebige Form oder ein beliebiges Medium digitaler Datenkommunikation miteinander
verbunden sein, z.B. ein Kommunikationsnetz. Zu Beispielen für Kommunikationsnetze zählen ein
lokales Netz (LAN) und ein Fernnetz (WAN) z.B. das Internet.
-
Das
Rechnersystem kann Clients und Server enthalten. Ein Client und
Server sind im allgemeinen voneinander abgesetzt und interagieren
in der Regel durch ein Kommunikationsnetz. Die Beziehung von Client
und Server ergibt sich aufgrund von Computerprogrammen, die auf
den jeweiligen Computern laufen und eine Client-Server-Beziehung zueinander aufweisen.