DE60207429T2

DE60207429T2 - Vorrichtung und verfahren zur bidirektionalen kommunikation und ausführung dynamischer befehlsätze

Info

Publication number: DE60207429T2
Application number: DE60207429T
Authority: DE
Inventors: Gowri Rajaram
Original assignee: Kyocera Wireless Corp
Current assignee: Kyocera Corp
Priority date: 2001-07-26
Filing date: 2002-07-25
Publication date: 2006-07-27
Anticipated expiration: 2022-07-26
Also published as: AU2002319572A1; EP1425894B1; CN1275149C; DE60219536D1; EP1410190B1; EP1610222A3; WO2003010932A2; ES2253553T3; WO2003010668A3; WO2003010942A3; ES2249602T3; JP4104546B2; WO2003010658A2; KR100940178B1; ES2248568T3; KR100911604B1; JP4278513B2; WO2003010664A3; EP1610222A2; ES2263799T3

Description

Hintergrund
1. Gebiet der Erfindung
Die Erfindung betrifft allgemein das Gebiet drahtloser Kommunikation und betrifft insbesondere Zwei-Wege-Kommunikation von dynamischen Befehlssätzen zwischen einem Mobilteil und einem drahtlosen Kommunikationsnetzwerk.
2. Stand der Technik
Herkömmliche drahtlose Kommunikationsvorrichtungen werden typischerweise zu isolierten Computerplattformen, wenn sie einmal ausgegeben sind, d.h. an einen Verbraucher verkauft sind. Diese herkömmlichen drahtlosen Kommunikationsvorrichtungen weisen extrem beschränkte oder keine Fähigkeiten zum Kommunizieren von Daten, wie zum Beispiel Betriebs- oder Instandhaltungsdaten mit einem Stammnetzwerk auf. Dieser Mangel an Datenkommunikationsfähigkeit stellt an den Provider der drahtlosen Kommunikationsvorrichtung beträchtliche Herausforderungen bezüglich eines Aktualisierens der Software, die auf der Vorrichtung ausgeführt wird, und eines Erhaltens von Betriebs- oder Instandhaltungsdaten der Vorrichtung. Zum Upgraden des Betriebssystems eines Mobiltelefons muss der Verbraucher beispielsweise das Telefon physisch in eine Kundendienststelle bringen, wo ein Techniker das Telefon in einen Computer einstecken muss, um das Telefon upzugraden. Das gleiche gilt für das Durchführen umfassender oder tiefgreifender Untersuchungen auf einem Mobiltelefon.
Die herkömmlichen Lösungen zum Aktualisieren einer drahtlosen Kommunikationsvorrichtung oder zum Erhalten von Informationen von solch einer Vorrichtung erfordern im Allgemeinen, dass die Vorrichtung in eine Kundendienststelle gebracht wird, wo ein Techniker die Vorrichtung zum Aktualisieren seiner Softwareprogramme oder zum Erhalten von Daten der Vorrichtung bedienen kann. Das ist für sowohl den Verbraucher als auch den Provider der Vorrichtung extrem kostenaufwändig.
Zusätzlich erfordern herkömmliche Verfahren zum Aktualisieren einer drahtlosen Kommunikationsvorrichtung oder zum Erhalten von Informationen von solch einer Vorrichtung im Allgemeinen eine festverdrahtete Verbindung mit der Vorrichtung. Das verkompliziert die Aktualisierungs- und Instandhaltungsnotwendigkeiten für die drahtlose Kommunikationsvorrichtung weiter, da es spezielle Kabel erfordert und sogar erfordert, das die Vorrichtung selbst eine festverdrahtete Schnittstelle aufweist. Diese Zwänge treiben sowohl die Herstellungs- als auch die Instandhaltungskosten einer drahtlosen Kommunikationsvorrichtung nach oben, während ebenfalls die Lebensdauer der Vorrichtung verkürzt wird.
Schließlich sind herkömmliche Verfahren zur Datenkommunikation mit einer drahtlosen Kommunikationsvorrichtung unidirektional. Herkömmliche Netzwerke weisen die Fähigkeit zum Bereitstellen von Anwendungssoftware und Daten auf der drahtlosen Kommunikationsvorrichtung auf. Zusätzlich können herkömmliche drahtlose Kommunikationsvorrichtungen die Fähigkeit aufweisen, auf solch eine Kommunikation mit begrenzten Einrichtungsdaten und Statusinformationen zu antworten. Diese begrenzte Master-Slave-Kommunikationsfähigkeit, die in herkömmlichen Systemen vorgefunden wird, leidet jedoch an der Unfähigkeit der drahtlosen Kommunikationsvorrichtung zum Einleiten einer Kommunikation mit dem Netzwerk.
Eine bestimmte Anzahl von Stand-der-Technik-Dokumenten offenbart solche Verfahren zur unidirektionalen Datenkommunikation mit einer drahtlosen Kommunikationsvorrichtung.
Das veröffentlichte US-Patent US-B-6 247 065 offenbart eine Nachrichtenplattform, die eingerichtet ist, Informationspakete, die eine oder eine Mehrzahl von Ausführungs-Befehlssätzen (EISs, Execution Instruction Sets) aufweisen, zu empfangen und danach zu handeln, wobei die EIS wie angegeben ausgeführt werden.
Die veröffentlichte europäische Patentanmeldung EP-A 0 459 344 offenbart eine Vorrichtung zum Herunterladen eines Software-Programms für ein Mobiltelefon, um häufige Änderungen des Betriebsprogramms des Telefons zu erlauben.
Das veröffentlichte US-Patent US-A-5 699 275 offenbart ein System zum entfernten Korrigieren oder Aktualisieren des Betriebskodes in einer Mobileinheit. Ein Verwaltungs-Hostrechner leitet die Übertragung durch ein Kommunikationsnetzwerk von einer oder einer Mehrzahl von Patch-Nachrichten ein. Die Mobileinheit empfängt diese Patch-Nachrichten und erzeugt einen Patch-Betriebskode. Die Mobileinheit kann auch Download-Nachrichten empfangen, die einen neuen Betriebskode zum Ersetzen des aktuellen definieren.
Das veröffentlichte US-Patent US-A-6 023 620 offenbart ein Verfahren und eine Vorrichtung zum Herunterladen von Software in ein entfernt angeordnetes Mobiltelefon mittels drahtloser Kommunikation.
Alle Systeme, die in diesen Stand-der-Technik-Dokumenten offenbart sind, leiden an der oben genannten Unfähigkeit.
Folglich ist, was gebraucht wird, ein System und ein Verfahren, die diese beträchtlichen Probleme überwinden, die in den herkömmlichen Systemen, wie oben beschrieben, gefunden werden.
Zusammenfassung
Einmal verteilt, werden herkömmliche drahtlose Kommunikationsvorrichtungen zu isolierten Rechnerplattformen mit extrem beschränkten oder ohne Fähigkeiten zum Instandhalten einer Datenkommunikation mit einem Stammnetzwerk. Dieser Mangel an Datenkommunikationsfähigkeit stellt beträchtliche Herausforderungen bezüglich des Aktualisierens der Software, die auf der drahtlosen Kommunikationsvorrichtung ausgeführt wird, und dem Ableiten von Betriebsdaten der Vorrichtung. Zusätzlich mangelt es herkömmlichen drahtlosen Kommunikationsvorrichtungen an der Fähigkeit zum Einleiten von Anfragen nach Informationen oder Software-Aktualisierungen, die ihre Fähigkeit zum Interagieren mit ihrer Umgebung verbessern können.
Es ist ein Ziel der Erfindung, Systeme und Verfahren für bidirektionale Kommunikation dynamischer Befehlssätze zwischen einem Handgerät und einem drahtlosen Kommunikationsnetzwerk bereitzustellen. Ein dynamischer Befehlssatz, z.B. ein oder eine Mehrzahl von Patchmanager-Laufzeitbefehlen (PMRTI, patch manager run time instructions), stellt eine eigenständige Funktion oder eine eigenständige Aktion dar, der von der Empfangsvorrichtung auszuführen ist. Das drahtlose Kommunikationsnetzwerk kann einen dynamischen Befehlssatz an ein Handgerät senden, um das Handgerät anzuweisen, bestimmte Vorgänge, wie zum Beispiel Zurückberichten des Status an das Netzwerk, durchzuführen. In ähnlicher Weise stellt die Erfindung für das Handgerät ein Kompilieren eines dynamischen Befehlssatzes, z.B. eines oder einer Mehrzahl umgekehrter Patchmanager-Laufzeitbefehle (RPMRTI, reverse patch manager run time instructions), und ein Senden des Befehlssatzes zur Ausführung an das Netzwerk bereit. Diese Fähigkeit erlaubt es dem Handgerät, Informationen, Software oder andere Daten bereitzustellen oder anzufordern, die dem Handgerät das Ausführen wünschenswerter Funktionen erlauben.
Das Ziel der Erfindung wird durch die Vorrichtungen und das Verfahren, die in den unabhängigen Ansprüchen beschrieben sind, erreicht. Andere Ausführungsbeispiele dieser Vorrichtungen und Verfahren sind in den abhängigen Ansprüchen beschrieben.
Kurzbeschreibung der Zeichnungen
Die Details der Erfindung, sowohl ihrer Struktur als auch ihres Betriebs, können durch Studieren der begleitenden Zeichnungen nachgelesen werden, in denen ähnliche Bezugszeichen gleiche Teile bezeichnen, und in denen:
1 ein schematisches Blockdiagramm des gesamten drahtlosen Vorrichtungssoftware-Instandhaltungssystems ist;
2 ein schematisches Blockdiagramm des Software-Instandhaltungssystems ist, das die Installation von Befehlssätzen über die Luftschnittstellen-Kommunikationsverbindung betont;
3 ein schematisches Blockdiagramm ist, das das Erfindungssystem zum Ausführen dynamischer Befehlssätze in einer drahtlosen Kommunikationsvorrichtung darstellt;
4 ein schematisches Blockdiagramm der Speichervorrichtung der drahtlosen Vorrichtung ist;
5 eine Tabelle ist, die die Kodeabschnitt-Adresstabelle aus 3 darstellt;
6 eine detaillierte Abbildung von Symbolbibliothek Eins aus 3 mit Symbolen ist;
7 eine Tabelle ist, die die Symboloffset-Adresstabelle aus 3 darstellt;
8 eine Abbildung des Betriebskodes ("opcodes") ist, auf den von der Laufzeit-Engine zugegriffen wird;
9 eine detailliertere Abbildung des ersten Betriebskodes aus 8 ist;
10 ein Flussdiagramm ist, das das erfindungsgemäße Verfahren zum Ausführen dynamischer Befehlssätze auf einer drahtlosen Kommunikationsvorrichtung darstellt;
11 ein Flussdiagramm ist, das eine beispielhafte Ausführung eines dynamischen Befehlssatzes darstellt;
12 ein Flussdiagramm ist, das eine andere beispielhafte Ausführung eines dynamischen Befehlssatzes darstellt;
13 ein Flussdiagramm ist, das eine dritte beispielhafte Ausführung eines dynamischen Befehlssatzes darstellt;
14 ein Flussdiagramm ist, das eine vierte beispielhafte Ausführung eines dynamischen Befehlssatzes darstellt;
15 ein Flussdiagramm ist, das eine fünfte beispielhafte Ausführung eines dynamischen Befehlssatzes darstellt;
16 ein High-Level-Netzwerkdiagramm ist, das ein beispielhaftes drahtloses Kommunikationsnetzwerk darstellt;
17A ein Blockdiagramm ist, das eine beispielhafte drahtlose Kommunikationsvorrichtung darstellt;
17B ein Blockdiagramm ist, das einen beispielhaften entfernten Laufzeit-Anweisungs-Befehlsabschnitt darstellt;
18A ein Blockdiagramm ist, das einen beispielhaften PMRTI-Server darstellt;
18B ein Blockdiagramm ist, das einen beispielhaften Serverrechner-Laufzeitanweisungs-Befehlsabschnitt darstellt;
19 ein Flussdiagramm ist, das einen beispielhaften Prozess zum Ausführen dynamischer Befehlssätze auf einer drahtlosen Kommunikationsvorrichtung darstellt;
20 ein Flussdiagramm ist, das einen beispielhaften Prozess zum Kompilieren dynamischer Befehlssätze auf einer drahtlosen Kommunikationsvorrichtung darstellt;
21 ein Flussdiagramm ist, das einen beispielhaften Prozess zum Ausführen dynamischer Befehlssätze auf einem PMRTI-Serverrechner darstellt;
22 ein Flussdiagramm ist, das einen beispielhaften Prozess zum Synchronisieren von Betriebskode-Bibliotheken darstellt; und
23 ein Blockdiagramm ist, das ein beispielhaftes Computersystem darstellt, das in Verbindung mit verschiedenen hierin beschriebenen Ausführungsbeispielen verwendet werden kann.
Detaillierte Beschreibung
Systeme und Verfahren zur bidirektionalen Kommunikation dynamischer Befehlssätze zwischen einer drahtlosen Kommunikationsvorrichtung und einem drahtlosen Kommunikationsnetzwerk sind offenbart. Ein hierin offenbartes Verfahren erlaubt es zum Beispiel einer drahtlosen Kommunikationsvorrichtung, einen Befehlssatz dynamisch zu konstruieren und diesen Befehlssatz zum Ausführen und Verarbeiten an das Netzwerk zu senden.
Nach dem Lesen dieser Beschreibung wird es für Fachleute offensichtlich, wie die Erfindung in verschiedenen alternativen Ausführungsbeispielen und alternativen Anwendungen implementiert werden kann. Obwohl jedoch verschiedene Ausführungsbeispiele der Erfindung hierin beschreiben sind, ist verständlich, dass diese Ausführungsbeispiele nur mittels Beispiel und nicht mittels Beschränkung präsentiert sind. Folglich soll diese detaillierte Beschreibung verschiedener alternativer Ausführungsbeispiele nicht so ausgelegt werden, den Umfang oder die Breite der Erfindung, wie in den angefügten Ansprüchen erklärt, zu begrenzen.
Einige Abschnitte der detaillierten Beschreibungen, die folgen, sind in Begriffen von Prozeduren, Schritten, Logik-Blöcken, Kodes, Verarbeitung und anderen symbolischen Darstellungen von Vorgängen auf Datenbits innerhalb eines drahtlosen Vorrichtungs-Mikroprozessors oder -Speichers dargestellt. Diese Beschreibungen und Darstellungen sind die Mittel, die von Datenverarbeitungsfachleuten verwendet werden, die am effektivsten den Kern ihrer Arbeit anderen Fachleuten vermitteln. Eine Prozedur, ein Mikroprozessorausgeführter Schritt, eine Anwendung, ein Logikblock, ein Prozess usw. ist hier und allgemein als eine selbstkonsistente Abfolge von Schritten oder Befehlen vorgestellt, die zu einem gewünschten Ergebnis führen. Die Schritte sind jene, die physikalische Manipulationen physikalischer Größen erfordern. Üblicherweise, aber nicht notwendigerweise, nehmen diese Größen die Form von elektrischen oder magnetischen Signalen an, die fähig sind, gespeichert, übertragen, kombiniert, verglichen und anders in einer Mikroprozessor-basierten drahtlosen Vorrichtung manipuliert zu werden. Es wurde beizeiten bequem gefunden, hauptsächlich aus Gründen des allgemeinen Gebrauchs, diese Signale als Bits, Werte, Elemente, Symbole, Buchstaben, Ausdrücke, Zahlen oder ähnliches zu bezeichnen. Wo physikalische Vorrichtungen, wie z.B. eine Speichervorrichtung erwähnt sind, sind sie mit anderen physikalischen Vorrichtungen mittels eines Busses oder anderer elektrische Verbindungen gekoppelt. Es kann angenommen werden, dass diese physikalischen Vorrichtungen mit logischen Prozessen oder Anwendungen interagieren und folglich mit logischen Vorgängen "gekoppelt" sind. Zum Beispiel kann eine Speichervorrichtung Kode speichern oder darauf zugreifen, um einen logischen Vorgang zu fördern, oder eine Anwendung kann einen Kodeabschnitt aus der Speichervorrichtung zur Ausführung aufrufen.
Es sollte jedoch nicht vergessen werden, dass alle diese und ähnliche Begriffe geeigneten physikalischen Größen zugeordnet sind und nur bequeme Begriffe sind, die auf diese Größen angewendet werden. Solange nicht spezifisch anders ausgedrückt, als aus der folgenden Diskussionen offensichtlich ist, wird verstanden, das in der gesamten Erfindung Diskussionen, die Begriffe, wie zum Beispiel "Verarbeiten" oder "Koppeln" oder "Übersetzen" oder "Anzeigen" oder "Beantworten" oder "Bestimmen" oder "Anzeigen" oder "Erkennen" oder ähnliche verwenden, die Aktion und Prozesse in einem Mikroprozessorsystem einer drahtlosen Vorrichtung bezeichnen, die Daten, die als physikalische (elektronische) Größen innerhalb der Register und Speichervorrichtungen des Computersystems dargestellt sind, manipulieren und in andere Daten umwandeln, die in ähnlicher Weise als physikalische Größen innerhalb der Speichervorrichtungen oder Register der drahtlosen Vorrichtung oder anderer solcher Informationsspeicher-, Übertragungs- oder Anzeigevorrichtungen dargestellt sind.
1 ist ein schematisches Blockdiagramm des gesamten drahtlosen Vorrichtungssoftware-Instandhaltungssystems 100. Die Systemsoftwareorganisation der Erfindung ist im Detail unten dargestellt, einer allgemeinen Übersicht des Software-Instandhaltungssystems 100 folgend. Das allgemeine System 100 beschreibt einen Prozess zum Liefern von Systemsoftware-Aktualisierungen und -Befehlssätzen (Programmen) und Installieren der gelieferten Software in einer drahtlosen Vorrichtung. Systemsoftware-Aktualisierungen und Patchmanager-Laufzeitbefehle (PMRTI, patch manager run time instructions), die allgemeiner als Befehlssätze oder dynamische Befehlssätze bekannt sind, sind von dem Hersteller der Handgeräte erzeugt. Die Systemsoftware ist in Symbolbibliotheken organisiert. Die Symbolbibliotheken sind in Kodeabschnitten angeordnet. Wenn Symbolbibliotheken upgedated werden, wird die Softwareaktualisierung 102 als ein Kodeabschnitt oder eine Mehrzahl von Kodeabschnitten transportiert. Die Softwareaktualisierung wird an drahtlose Vorrichtungen im Gebiet gesendet, von denen eine drahtlose Kommunikationsvorrichtung 104 repräsentativ ist, oder in getrennter Übertragung von einer Basisstation 106 unter Verwendung bekannter herkömmlicher Funk-, Daten- oder Nachrichten-Transportprotokolle übermittelt. Die Erfindung ist nicht auf ein bestimmtes Transportformat beschränkt, da die drahtlose Kommunikationsvorrichtung einfach modifiziert werden kann, um jedes verfügbare Funk-Transportprotokoll zum Zwecke des Empfangs von Systemsoftware und von PMRTI-Aktualisierungen zu verarbeiten.
Die Systemsoftware kann als eine Sammlung verschiedener Subsysteme angesehen werden. Kodeobjekte können eng in eines dieser abstrakten Subsysteme gekoppelt sein und die resultierende Sammlung kann als eine Symbolbibliothek bezeichnet werden. Das schafft eine logische Aufschlüsselung der Kodebasis, und Softwarekorrekturen (patch) und -Fixes können einer dieser Symbolbibliotheken zugeordnet werden. In den meisten Fällen ist eine einzelne Aktualisierung einer, oder höchstens zwei, Symbolbibliotheken zugeordnet. Der Rest der Kodebasis, die anderen Symbolbibliotheken, bleiben unverändert.
Die Vorstellung von Symbolbibliotheken schafft einen Mechanismus zum Umgehen mit Kode und Kostanten. Andererseits passen die Lese-Schreib (RW, read-write)-Daten in eine einzigartige individuelle RW-Bibliothek, die RAM-basierte Daten für alle Bibliotheken aufweist.
Einmal von der drahtlosen Vorrichtung 104 empfangen, muss der transportierte Kodeabschnitt verarbeitet werden. Diese drahtlose Vorrichtung überschreibt einen spezifischen Kodeabschnitt des nichtflüchtigen Speichers 108. Der nichtflüchtige Speicher 108 weist einen Dateisystemabschnitt (FSS, file system section) 110 und einen Kodespeicherabschnitt 112 auf. Der Kodeabschnitt ist typischerweise vor dem Transport komprimiert zum Minimieren des Belegung in dem FSS 110. Oft wird der upgedatete Kodeabschnitt von seinen RW-Daten begleitet sein, die ein anderer Typ von Symbolbibliothek ist, die alle RW-Daten für jede Symbolbibliothek aufweist. Obwohl in die flüchtige Lese-Schreib-Speichervorrichtung 114 mit wahlfreiem Zugriff geladen, wenn die Systemsoftware ausgeführt wird, müssen die RW-Daten immer in der nichtflüchtigen Speichervorrichtung 108 gespeichert werden, damit sie jedes Mal, wenn die drahtlose Vorrichtung resettet wird, in die flüchtige Lese-Schreib-Speichervorrichtung 114 mit wahlfreiem Zugriff geladen werden können. Das schließt ein, dass die ersten RW-Daten in die flüchtigen Lese-Schreib-Speichervorrichtung mit wahlfreiem Zugriff geladen werden. Wie unten detaillierter erklärt ist, sind die RW-Daten typischerweise mit einem Patchmanager-Kodeabschnitt angeordnet.
Das System 100 weist das Konzept virtueller Tabellen auf. Unter Verwendung solcher Tabellen können Symbolbibliotheken in einem Kodeabschnitt korrigiert (ersetzt) werden, ohne andere Teile der System Software (oder Kodeabschnitte) aufzubrechen (ersetzen). Virtuelle Tabellen werden aus Effizienzgründen aus der flüchtigen Lese-Schreib-Speichervorrichtung 114 für wahlfreien Zugriff ausgeführt. Eine Kodeabschnitt-Adresstabelle und eine Symboloffset-Adresstabelle sind virtuelle Tabellen.
Die upgedateten Kodeabschnitte werden von der drahtlosen Vorrichtung 104 empfangen und in dem FSS 110 gespeichert. Eine drahtlose Vorrichtungs-Benutzerschnittstelle (UI, user interface) wird typischerweise den Benutzer benachrichtigen, dass neue Software verfügbar ist. In Antwort auf UI-Bereitschaftsmeldungen bestätigt der Benutzer die Meldung und signalisiert den Patch- oder Aktualisierungs-Vorgang. Alternativ wird der Aktualisierungs-Vorgang automatisch durchgeführt. Die drahtlose Vorrichtung kann zum Durchführen von Standard-Kommunikationsaufgaben unfähig sein, wenn der Aktualisierungsprozess durchgeführt wird. Der Patchmanager-Kodeabschnitt weist eine nichtflüchtige Lese-Schreib-Treiber-Symbolbibliothek auf, die auch in die flüchtige Lese-Schreib-Speichervorrichtung 114 mit wahlfreiem Zugriff geladen wird. Die nichtflüchtige Lese-Schreib-Treiber-Symbolbibliothek bewirkt, das Kodeabschnitte mit upgedateten Kodeabschnitten überschrieben werden. Der Patchmanager-Kodeabschnitt weist die Lese-Schreib-Daten, die Kodeabschnitt-Adresstabelle und die Symboloffset-Adresstabelle, genauso wie einen Symbolzugriffskode und die Symbolzugriffskodeadresse (unten diskutiert) auf. Abschnitte dieser Daten sind ungültig, wenn upgedatete Kodeabschnitte eingeführt werden und Kodeabschnitte eines upgedateten Patchmanagers Lese-Schreib-Daten, eine Kodeabschnitt-Adresstabelle und eine Symboloffset-Adresstabelle aufweisen, die für die upgedateten Kodeabschnitte gültig sind. Wenn die upgedateten Kodeabschnitte in den Kodespeicherabschnitt 112 geladen sind, ist die drahtlose Vorrichtung zurückgesetzt. Der Resetoperation folgend, kann die drahtlose Vorrichtung die upgedatete Systemsoftware ausführen. Es sollte auch verstanden werden, dass der Patchmanager-Kodeabschnitt andere Symbolbibliotheken aufweisen kann, die oben nicht diskutiert wurden. Diese anderen Symbolbibliotheken brauchen nicht in die flüchtige Lese-Schreib-Speichervorrichtung 114 geladen sein.
2 ist ein schematisches Blockdiagramm des Software-Instandhaltungssystems 100, das die Installation von Befehlssätzen über die Luftschnittstellen-Kommunikationsverbindung hervorhebt. Zusätzlich zum Aktualisieren von Systemsoftware-Kodeabschnitten kann das Instandhaltungssystem 100 dynamische Befehlssätze, Programme oder Patchmanager-Befehlssätze (PMIS, patch manager instruction sets), die hierin als Patchmanager-Laufzeitbefehle (PMRTI, patch manager run time instructions) bezeichnet werden, herunterladen und installieren. Der PMRTI-Kodeabschnitt 200 wird auf die gleiche Weise zu der drahtlosen Vorrichtung 104 transportiert wie die oben beschriebenen Systemsoftware-Kodeabschnitte. PMRTI- Kodeabschnitte sind anfänglich in dem FSS 110 gespeichert. Ein PMRTI-Kodeabschnitt ist typischerweise eine Binärdatei, die als kompilierte Befehle für das Handgerät vorgestellt werden kann. Ein PMRTI-Kodeabschnitt ist umfassend genug zum Bereitstellen für die Leistung von grundlegenden mathematischen Operationen und die Leistung von bedingt ausgeführten Operationen. Zum Beispiel kann ein RF-Kalibrierungs-PMRTI die folgenden Operationen durchführen:
IF RF CAL ITEM IS LESS THAN X
EXECUTE INSTRUCTION
ELSE
EXECUTE INSTRUCTION
Ein PMRTI kann grundlegende mathematische Operationen unterstützen, wie zum Beispiel: Addition, Subtraktion, Multiplikation und Division. Wie bei den Systemsoftware-Kodeabschnitten kann der PMRTI-Kodeabschnitt in Antwort auf UI-Bereitschaftsmeldungen geladen werden und die drahtlose Vorrichtung muss resettet werden, nachdem die PMRTI in den Kodespeicherabschnitt 112 geladen ist. Dann kann der PMRTI-Abschnitt ausgeführt werden. Falls der PMRTI-Kodeabschnitt virtuellen Tabellen oder Lese-Schreib-Daten zugeordnet ist, wird ein upgedateter Patchmanager-Kodeabschnitt mit dem PMRTI transportiert zur Installation in dem Kodespeicherabschnitt 112. Alternativ kann der PMRTI gehalten und aus dem FSS 1120 verarbeitet werden. Nachdem das Handgerät 104 alle Befehle im PMRTI-Abschnitt ausgeführt hat, kann der PMRTI-Abschnitt aus dem FSS 110 gelöscht werden. Alternativ wird der PMRTI für zukünftige Vorgänge aufrechterhalten. Zum Beispiel kann der PMRTI jedes Mal aufgeführt werden, wenn die drahtlose Vorrichtung mit Energie versorgt wird.
Der PMRTI ist eine sehr leistungsstarke Laufzeitbefehls-Engine. Das Handgerät kann jeden Befehl ausführen, der an sie durch die PMRTI-Umgebung geliefert wird. Dieser Mechanismus kann zum Unterstützen von RF-Kalibrierungen verwendet werden. Allgemeiner kann der PMRTI zum entfernten Debuggen einer drahtlosen Vorrichtungssoftware verwendet werden, wenn Softwareprobleme von dem Hersteller oder Dienstanbieter erkannt werden, typischerweise als das Ergebnis von Benutzerbeschwerden. Der PMRTI kann auch Daten aufzeichnen, die für Diagnose-Softwareprobleme benötigt werden. Der PMRTI kann neu heruntergeladene Systemanwendungen für Datenanalyse, Debuggen und Fixes starten. Der PMRTI kann RW-Daten-basierte Aktualisierungen für Analysen bereitstellen und möglicherweise kurzfristige Fixes auf ein Problem anstelle eines upgedateten Systemsoftware-Kodeabschnitts. Der PMRTI kann Speicherkomprimierungsalgorithmen zum Gebrauch durch die drahtlose Vorrichtung bereitstellen.
In einigen Aspekten der Erfindung kann die Organisation der Systemsoftware in Systembibliotheken auf die Größe der flüchtigen Speichervorrichtung 114 und der nichtflüchtigen Speichervorrichtung 108, die zur Ausführung benötigt sind, Einfluss haben. Das ist aufgrund der Tatsache, dass die Kodeabschnitte typischerweise größer sind als die Symbolbibliotheken, die in den Kodeabschnitten angeordnet sind. Diese größeren Kodeabschnitte existieren zum Aufnehmen upgedateter Kodeabschnitte. Das Organisieren der Systemsoftware als Sammlung von Bibliotheken hat Auswirkungen auf die Größenerfordernisse der nichtflüchtigen Speichervorrichtung. Für die gleiche Kodegröße, wird die verwendete Menge von nichtflüchtigen Speicher größer sein aufgrund der Tatsache, dass Kodeabschnitte eine Größe haben können, die größer ist als die Symbolbibliotheken, die darin angeordnet sind.
Wenn Softwareaktualisierungen an die drahtlose Vorrichtung geliefert wurden, unterstützt das Software-Instandhaltungssystem 100 eine Speicherkomprimierung. Speicherkomprimierung ist den Disk-Defragmentierungs-Anwendungen in Desktop-Computern ähnlich. Der Komprimierungsmechanismus stellt sicher, dass Speicher optimal genutzt wird und für zukünftige Kodeabschnittaktualisierungen gut ausgeglichen ist, wo die Größe der upgedateten Kodeabschnitte unvorhersehbar ist. Das System 100 analysiert den Kodespeicherabschnitt, wenn er korrigiert (upgedatet) wird. Das System 100 versucht, upgedatete Kodeabschnitte an den Speicherplatz anzupassen, der von dem Kodeabschnitt besetzt ist, der ersetzt wird. Falls der upgedatete Kodeabschnitt größer ist als der Kodeabschnitt, der ersetzt wird, komprimiert das System 100 die Kodeabschnitte im Speicher 112. Alternativ kann die Komprimierung von dem Hersteller oder Dienstanbieter berechnet werden und Komprimieranweisungen können zu der drahtlosen Vorrichtung 104 transportiert werden.
Komprimierung kann aufgrund der Komplexität des Algorithmus und auch der enormen Menge an Datenbewegung ein zeitaufwändiger Prozess sein. Der Komprimieralgorithmus sagt die Durchführbarkeit vorher, bevor er irgendeine Verarbeitung beginnt. UI-Bereitschaftsmeldungen können zum Ersuchen nach der Erlaubnis des Benutzers verwendet werden, bevor die Komprimierung versucht wird.
In einigen Aspekten der Erfindung können alle Systemsoftware-Kodeabschnitte gleichzeitig upgedatet werden. Ein vollständiges Systemsoftwareupgrade jedoch würde ein größeres FSS 110 benötigen.
3 ist ein schematisches Blockdiagramm, das die dynamische Befehlssatzausführung der Erfindung in einer drahtlosen Kommunikationsvorrichtung darstellt. Das System 300 weist einen Kodespeicherabschnitt 112 im Speicher 108 auf, der ausführbare drahtlose Vorrichtungs-Systemsoftware aufweist, die in eine Mehrzahl von aktuellen Kodeabschnitten differenziert ist. Kodeabschnitt Eins (302), Kodeabschnitt Zwei (304), Kodeabschnitt n (306) und ein Patchmanager-Kodeabschnitt 308 sind gezeigt. Jedoch ist die Erfindung nicht auf eine bestimmte Anzahl von Kodeabschnitten beschränkt. Ferner weist das System 300 weiter eine erste Mehrzahl von Symbolbibliotheken auf, die in die zweite Mehrzahl von Kodeabschnitten angeordnet sind. Gezeigt sind eine Symbolbibliothek Eins (310), die im Kodeabschnitt Eins (302) angeordnet ist, Symbolbibliotheken Zwei (312) und Drei (314), die in dem Kodeabschnitt Zwei (304) angeordnet sind, und Symbolbibliothek m (316), die in dem Kodeabschnitt n (306) angeordnet ist. Jede Bibliothek weist Symbole auf mit in Zusammenhang stehender Funktionalität. Zum Beispiel kann die Symbolbibliothek Eins (310) in dem Betrieb der Flüssigkristallanzeige (LCD) der drahtlosen Vorrichtung involviert sein. Dann wären die Symbole mit Anzeigefunktionen zugeordnet. Wie im Detail unten erklärt ist, sind zusätzliche Symbolbibliotheken in dem Patchmanager-Kodeabschnitt 308 angeordnet.
4 ist ein schematische Blockdiagramm des Speichers der drahtlosen Vorrichtung. Wie gezeigt, ist der Speicher der Kodespeicherabschnitt 112 aus 1. Die Speichervorrichtung ist ein beschreibbarer, nichtflüchtiger Speicher, wie zum Beispiel eine Flash-Speichervorrichtung. Es sollte verstanden werden, dass die Kodeabschnitte nicht notwendigerweise in der gleichen Speichervorrichtung gespeichert zu werden brauchen wie die FSS 110. Es sollte auch verstanden werden, dass die Systemsoftwarestruktur der Erfindung mit Kodeabschnitten ermöglicht sein könnte, die in einer Mehrzahl von kooperierenden Speichervorrichtungen gespeichert sind. Der Kodespeicherabschnitt 112 weist eine zweite Mehrzahl von fortlaufend adressierten Speicherblöcken auf, wo jeder Speicherblock einen entsprechenden Kodeabschnitt von der der zweiten Mehrzahl von Kodeabschnitten speichert. Folglich ist der Kodeabschnitt Eins (302) in einem ersten Speicherblock 400 gespeichert, Kodeabschnitt Zwei (304) in dem zweiten Speicherblock 402, Kodeabschnitt n (306) in dem n-ten Speicherblock 404 und der Patchmanager-Kodeabschnitt (308) in dem p-ten Speicherblock 406.
In 3 und 4 ist der Start jedes Kodeabschnitts an entsprechenden Startadressen in der Speichervorrichtung gespeichert und Symbolbibliotheken sind zum Starten am Start der Kodeabschnitte angeordnet. Das heißt, jede Symbolbibliothek beginnt mit einer ersten Adresse und läuft aufeinander folgend von der ersten Adresse durch einen Bereich von Adressen. Zum Beispiel startet der Kodeabschnitt Eins (302) an der ersten Startadresse 408 (markiert mit "S") in der Kodespeicherabschnitt-Speichervorrichtung 112. In 3 startet die Symbolbibliothek Eins (310) am Start 318 des ersten Kodeabschnitts. In ähnlicher Weise startet der Kodeabschnitt Zwei (304) an einer zweiten Startadresse 410 (4) und die Symbolbibliothek Zwei startet am Start 320 des Kodeabschnitts Zwei (3). Der Kodeabschnitt n (306) startet an einer dritten Startadresse 412 in der Kodespeicherabschnitt-Speichervorrichtung 112 (4) und Symbolbibliothek m (316) startet am Start des Kodeabschnitts n 322 (3). Der Patchmanager-Kodeabschnitt startet an der p-ten Startadresse 414 in der Kodespeicherabschnitt-Speichervorrichtung 112 und die erste Symbolbibliothek im Patchmanager-Kodeabschnitt 308 startet am Start 324 des Patchmanager-Kodeabschnitts. Folglich ist die Symbolbibliothek Eins (310) schließlich in dem ersten Speicherblock 400 gespeichert. Falls ein Kodeabschnitt eine Mehrzahl von Symbolbibliotheken aufweist, wie zum Beispiel Kodeabschnitt Zwei (304), sind die Mehrzahl von Symbolbibliotheken in dem entsprechenden Speicherblock gespeichert, in diesem Fall im zweiten Speicherblock 402.
In 3 weist das System 300 ferner eine Kodeabschnitt-Adresstabelle 326 als ein Symboltyp auf, der in einer Symbolbibliothek enthalten ist, die in dem Patchmanager-Kodeabschnitt 308 angeordnet ist. Die Kodeabschnitt-Adresstabelle macht Querverweise von Kodeabschnitt-Identifizierer mit entsprechenden Kodeabschnitt-Startadressen im Speicher.
5 ist eine Tabelle, die die Kodeabschnitt-Adresstabelle 326 aus 3 darstellt. Die Kodeabschnitt-Adresstabelle 326 wird konsultiert zum Finden der Kodeabschnitt-Startadresse für eine Symbolbibliothek. Zum Beispiel sucht das System 300 Kodeabschnitt Eins, wenn ein Symbol in Symbolbibliothek Eins zur Ausführung benötigt wird. Zum Finden der Startadresse des Kodeabschnitts Eins, und daher Lokalisieren des Symbols in der Symbolbibliothek Eins, wird die Kodeabschnitt-Adresstabelle 326 konsultiert. Die Anordnung von Symbolbibliotheken in Kodeabschnitten und die Verfolgung von Kodeabschnitten mit einer Tabelle erlaubt, das die Kodeabschnitte bewegt oder expandiert werden. Die Expansions- oder Bewegungsvorgänge können zum Installieren upgegradeter Kodeabschnitte (mit upgegradeten Symbolbibliotheken) benötigt werden.
Zurückkehrend zu 3 sollte bemerkt werden, das nicht jede Symbolbibliothek notwendigerweise am Start eines Kodeabschnitts startet. Wie gezeigt, ist die Symbolbibliothek Drei (314) im Kodeabschnitt Zwei (304) angeordnet, aber sie startet nicht von der Kodeabschnitt-Startadresse 320. Folglich, falls ein Symbol in der Symbolbibliothek Drei (314) zur Ausführung benötigt wird, konsultiert das System 300 die Kodeabschnitt-Adresstabelle 326 für die Startadresse des Kodeabschnitts Zwei (304). Wie unten erklärt, erlaubt eine Symboloffset-Adresstabelle, dass die Symbole in der Symbolbibliothek Drei (314) lokalisiert werden. Es macht nichts, das die Symbole über eine Mehrzahl von Bibliotheken verteilt sind, solange wie sie in dem gleichen Kodeabschnitt behalten sind.
Wie oben angemerkt, weist jede Symbolbibliothek funktionell verwandte Symbole auf. Ein Symbol ist ein Programmierer-definierter Name zum Lokalisieren und Verwenden eines Routine-Körpers, einer Variable oder einer Datenstruktur. Folglich kann ein Symbol eine Adresse oder ein Wert sein. Symbole können intern oder extern sein. Interne Symbole sind nicht über den Bereich des aktuellen Kodeabschnitts hinaus sichtbar. Insbesondere werden sie nicht von anderen Symbolbibliotheken in anderen Kodeabschnitten gesucht. Externe Symbole werden über Kodeabschnitte hinweg verwendet und aufgerufen und werden von Bibliotheken in unterschiedlichen Kodeabschnitten gesucht. Die Symboloffset-Adresstabelle weist typischerweise eine Liste aller externen Symbole auf.
Zum Beispiel kann die Symbolbibliothek Eins (310) Zeichen auf einer Anzeige einer drahtlosen Vorrichtung erzeugen. Symbole in dieser Bibliothek würden, im Gegenzug, Telefonnummern, Namen, die Zeit, oder andere Anzeigemerkmale erzeugen. Jedes Merkmal wird mit Routinen erzeugt, die hierin als ein Symbol bezeichnet werden. Zum Beispiel erzeugt ein Symbol in der Symbolbibliothek Eins (310) Telefonnummern auf der Anzeige. Dieses Symbol ist durch ein "X" dargestellt und ist extern. Wenn die drahtlose Vorrichtung einen Telefonanruf empfängt und der Anrufer-ID-Dienst aktiviert ist, muss das System zum Erzeugen der Nummer auf der Anzeige das "X"-Symbol ausführen. Folglich muss das System das "X"-Symbol lokalisieren.
6 ist eine detaillierte Abbildung der Symbolbibliothek Eins (310) aus 3 mit Symbolen. Symbole sind angeordnet, um einen Offset von jeweiligen Kodeabschnitt-Startadressen aufzuweisen. Unter vielen Umständen ist der Start der Symbolbibliothek der Start eines Kodeabschnitts, aber das gilt nicht, falls ein Kodeabschnitt mehr als eine Symbolbibliothek aufweist. Die Symbolbibliothek Eins (310) startet am Start des Kodeabschnitts Eins (siehe 3). Wie in 6 gezeigt, ist das "X"-Symbol mit einem Offset von (03) von dem Start der Symbolbibliothek lokalisiert und das "Y"-Symbol ist mit einem Offset von (15) lokalisiert. Sie Symboloffsetadressen sind in einer Symboloffset-Adresstabelle 328 in dem Patchmanager-Kodeabschnitt gespeichert (siehe 3).
7 ist eine Tabelle, die die Symboloffset-Adresstabelle 328 aus 3 darstellt. Die Symboloffset-Adresstabelle 328 macht Querverweise von Symbolidentifizierern zu entsprechenden Offsetadressen und zu entsprechenden Kodeabschnitt-Identifizierern im Speicher. Folglich wird die Symboloffset-Adresstabelle 328 konsultiert zum Lokalisieren der exakten Adresse des Symbols bezüglich des Kodeabschnitts in dem es angeordnet ist, wenn das System versucht, das "X"-Symbol in der Symbolbibliothek Eins auszuführen.
Zurückkehrend zu 3 weisen die erste Mehrzahl von Symbolbibliotheken typischerweise alle Lese-Schreib-Daten auf, die konsultiert oder in der Ausführung dieser Symbolbibliotheken gesetzt werden müssen. Zum Beispiel kann eine Symbolbibliothek einen Vorgang aufweisen, der von einem Bedingungsausdruck abhängig ist. Der Lese-Schreib-Datenabschnitt wird konsultiert zum Bestimmen des Status, der zum Vervollständigen der Bedingungsausdrucks nötig ist. Die Erfindung gruppiert die Lese-Schreib-Daten aller Symbolbibliotheken in einen miteinander geteilten Lese-Schreib-Abschnitt. In einigen Aspekten der Erfindung sind die Lese-Schreib-Daten 330 in dem Patchmanager-Kodeabschnitt 308 angeordnet. Alternativ (nicht gezeigt) können die Lese-Schreib-Daten in einem anderen Kodeabschnitt, zum Beispiel Kodeabschnitt n (306), angeordnet sein.
Die erste Mehrzahl von Symbolbibliotheken weist auch Symbolzugriffskode auf, der in einem Kodeabschnitt angeordnet ist, zum Berechnen der Adresse eines gesuchten Symbols. Der Symbolzugriffskode kann an einer Adresse in einem getrennten Kodeabschnitt, zum Beispiel Kodeabschnitt Zwei (304), angeordnet und gespeichert sein. Jedoch, wie gezeigt, ist der Symbolzugriffskode 332 an einer Adresse in dem Patchmanager-Kodeabschnitt 308 angeordnet und gespeichert. Das System 300 weist ferner eine erste Position zum Speichern der Symbolzugriffskodeadresse auf. Die erste Position kann ein Kodeabschnitt in dem Kodespeicherabschnitt 112 sein, oder in einem getrennten Speicherabschnitt der drahtlosen Vorrichtung (nicht gezeigt). Die erste Position kann auch in dem gleichen Kodeabschnitt wie die Lese-Schreib-Daten angeordnet sein. Wie gezeigt, ist die erste Position 334 in dem Patchmanager-Kodeabschnitt 308 mit den Lese-Schreib-Daten 330, der Symboloffset-Adresstabelle 328, der Kodeabschnitt- Adresstabelle 326 und dem Symbolzugriffskode 332 und der Patchbibliothek (Patch-Symbolbibliothek) 336 gespeichert.
Der Symbolzugriffskode greift auf die Kodeabschnitt-Adresstabelle und die Symboloffset-Adresstabelle zu, um die Adresse eines gesuchten Symbols in der Speichervorrichtung zu berechnen oder finden. Das heißt, der Symbolzugriffskode berechnet die Adresse des gesuchten Symbols unter Verwendung eines entsprechenden Symbolidentifizierers und eines entsprechenden Kodeabschnitt-Identifizierers. Falls zum Beispiel das "X"-Symbol in der Symbolbibliothek Eins gesucht wird, wird zum Suchen des Symbolidentifizierers (Symbol-ID) "X_1", der dem "X"-Symbol entspricht (siehe 7), der Symbolzugreifer angerufen. Der Symbolzugriffskode konsultiert die Symboloffset-Adresstabelle zum Bestimmen, dass der "X_1"-Symbolidentifizierer einen Offset von (03) von dem Start des Kodeabschnitts Eins aufweist (siehe 6). Der Symbolzugriffskode wird angerufen zum Suchen des Kodeabschnitt-Identifizierer "CS_1", der dem Kodeabschnitt Eins entspricht. Der Symbolzugriffskode konsultiert die Kodeabschnitt-Adresstabelle zum Bestimmen der Startadresse, die dem Kodeabschnitt-Identifizierer (Kodeabschnitt ID) "CS_1" zugeordnet ist. Auf diese Weise bestimmt der Symbolzugriffskode, dass der Symbolidentifizierer "X_1" von der Adresse von (00100) einen Offset (03) aufweist, oder an der Adresse (00103) lokalisiert ist.
Das Symbol "X" ist ein reservierter Name, da es ein Teil des aktuellen Kodes ist. In anderen Worten, es weist einen absoluten Datenwert auf, der damit assoziiert ist. Der Datenwert kann eine Adresse oder ein Wert sein. Der Symbolidentifizierer ist ein Alias, der zum Verfolgen des Symbols erzeugt ist. Die Symboloffset-Adresstabelle und die Kodeabschnitt-Adresstabelle arbeiten beide mit Identifizierern zum Vermeiden von Konfusion mit reservierten Symbol- und Kodeabschnittnamen. Es ist auch möglich, dass der gleiche Symbolname über viele Symbolbibliotheken hinweg verwendet wird. Der Gebrauch von Identifizierern verhindert eine Konfusion zwischen diesen Symbolen.
Zurück zu 1 weist das System 300 ferner eine flüchtige Lese-Schreib-Speichervorrichtung 114, typischerweise eine Speichervorrichtung mit wahlfreien Zugriff (RAM, random access memory) auf. Die Lese-Schreib-Daten 330, die Kodeabschnitt-Adresstabelle 326, die Symboloffset-Adresstabelle 328, der Symbolzugriffskode 332 und die Symbolzugriffskodeadresse 334 sind von dem Patchmangager-Kodeabschnitt in die flüchtige Lese-Schreib-Speichervorrichtung 114 geladen, zum Zugreifen während der Ausführung der Systemsoftware. Es ist allgemein bekannt, dass die Zugriffszeiten für Kode, der im RAM gespeichert ist, wesentlich kürzer ist als der Zugriff auf eine nichtflüchtige Speichervorrichtung, wie zum Beispiel Flash.
Zurück zu 3 kann bemerkt werden, dass die Symbolbibliotheken nicht notwendigerweise die Kodeabschnitte in denen sie angeordnet sind, auffüllen, obwohl die Speicherblöcke eine Größe aufweisen, um die entsprechenden Kodeabschnitte, die darin gespeichert sind, exakt aufzunehmen. Alternativ ausgedrückt, jede der zweiten Mehrzahl von Kodeabschnitten weist eine Größe in Byte auf, die die angeordneten Symbolbibliotheken aufnehmen, und jede der aufeinander folgend adressierten Speicherblöcke weist eine Größe in Byte auf, die entsprechende Kodeabschnitte aufnimmt. Zum Beispiel kann der Kodeabschnitt Eins (302) ein 100-Byte-Abschnitt zum Aufnehmen einer Symbolbibliothek mit einer Länge von 100 Bytes sein. Der erste Speicherblock wäre 100 Bytes zum Übereinstimmen mit der Bytegröße des Kodeabschnitts Eins. Jedoch kann die in den Kodeabschnitt 1 geladene Symbolbibliothek kleiner als 100 Bytes sein. Wie in 3 gezeigt, weist der Kodeabschnitt Eins (302) einen unverwendeten Abschnitt 340 auf, da die Symbolbibliothek Eins (310) kleiner als 100 Bytes ist. Folglich kann jede der zweiten Mehrzahl von Kodeabschnitten ein Größe aufweisen, die größer ist als die Größe, die zum Aufnehmen der angeordneten Symbolbibliotheken nötig ist. Durch "Über-Vergrößern" der Kodeabschnitte können größere upgedatete Symbolbibliotheken aufgenommen werden.
Aufeinander folgend adressierte Speicherblöcke beziehen sich auf das Aufteilen des physikalischen Speicherplatzes in logische Blöcke mit variabler Größe. Kodeabschnitte und Speicherblöcke sind Ausdrücke, die im Wesentlichen austauschbar sind, wenn der Kodeabschnitt in der Speichervorrichtung gespeichert ist. Das Konzept eines Kodeabschnitts wird zum Identifizieren eines Abschnitts von Kode verwendet, der vielleicht größer ist als die Symbolbibliothek, oder der Sammlung von Symbolbibliotheken in dem Kodeabschnitt, wenn er bewegt und manipuliert wird.
Wie in 3 gesehen, weist das System 300 eine Patchsymbolbibliothek auf, die hierin als Patchbibliothek 336 gezeichnet wird, zum Anordnen neuer Kodeabschnitte in dem Kodespeicherabschnitt mit den aktuellen Kodeabschnitten. Die Anordnung von neuen Kodeabschnitten mit aktuellen Kodeabschnitten in dem Kodespeicherabschnitt bildet upgedatete ausführbare Systemsoftware. Der Patchmanager 336 ordnet nicht nur neue Kodeabschnitte mit den aktuellen Kodeabschnitten an, er ersetzt auch Kodeabschnitte mit upgedateten Kodeabschnitten.
Zurück zu 4 empfängt der Dateisystemabschnitt 110 der Speichervorrichtung 108 neue Kodeabschnitte, wie zum Beispiel den neuen Kodeabschnitt 450 und den upgedateten Patchmanager-Kodeabschnitt 452. Der Dateisystemabschnitt empfängt auch einen ersten Patchmanager-Laufzeitbefehl (PMRTI, patch manager run time instruction) 454, der Befehle zum Anordnen der neuen Kodeabschnitte mit den aktuellen Kodeabschnitten aufweist. Wie in 1 zu sehen, empfängt eine Luftschnittstellen (Airlink)-Kommunikationsverbindung 150 neue oder upgedatete Kodeabschnitte, genauso wie den ersten PMRTI. Obwohl die Luftschnittstellen-Kommunikationsverbindung 150 durch eine Antenne dargestellt ist, sollte es verständlich sein, dass die Luftschnittstellen-Kommunikationsverbindung auch ein RF-Transceiver, Basisband-Schaltkreise und Demodulations-Schaltkreise (nicht gezeigt) aufweist. Der Dateisystemabschnitt 110 speichert die neuen Kodeabschnitte, die über die Luftschnittstellen-Kommunikationsverbindung 150 empfangen werden. Die Patchbibliothek 336, die in der Lese-Schreib-Speichervorrichtung 114 ausgeführt wird, ersetzt einen ersten Kodeabschnitt in dem Kodespeicherabschnitt, zum Beispiel Kodeabschnitt n (306), mit den neuen, oder upgedateten Kodeabschnitt 450 in Antwort auf die erste PMRTI 454. Typischerweise wird der Patchmanager-Kodeabschnitt 308 mit dem upgedateten Patchmanager-Kodeabschnitt 452 ersetzt. Wenn Kodeabschnitte ersetzt werden, überschreibt die Patchbibliothek 336 den ersten Kodeabschnitt, zum Beispiel Kodeabschnitt n (306), im Kodespeicherabschnitt 112 mit den upgedateten Kodeabschnitten, zum Beispiel Kodeabschnitt 450, im Dateisystemabschnitt 110. Im Extremfall werden alle Kodeabschnitte im Kodespeicherabschnitt 112 mit upgedateten Kodeabschnitten ersetzt. Das heißt, der FSS 110 empfängt eine zweite Mehrzahl von upgedateten Kodeabschnitten (nicht gezeigt) und die Patchbibliothek 336 ersetzt die zweite Mehrzahl von Kodeabschnitten im Kodespeicherabschnitt 112 mit der zweiten Mehrzahl von upgedateten Kodeabschnitten. Natürlich muss der FSS 110 groß genug sein zum Aufnehmen der zweiten Mehrzahl von upgedateten Kodeabschnitten, die über die Luftschnittstellen-Kommunikationsverbindung empfangen werden.
Wie oben bemerkt, können die empfangenen upgedateten Kodeabschnitte Lese-Schreib-Daten-Kodeabschnitte, Kodeabschnitt-Adresstabellen-Kodeabschnitte, Symbolbibliotheken, Symboloffset-Adresstabellen-Kodeabschnitte, Symbolzugriffsmethoden-Kodeabschnitte oder einen Kodeabschnitt mit einer neuen Patchbibliothek aufweisen. Alle diese Kodeabschnitte mit ihren zugeordneten Symbolbibliotheken und Symbolen, können als verschiedene unabhängige Kodeabschnitte gespeichert sein. Dann würde jeder dieser Kodeabschnitte mit einem einzigartigen upgedateten Kodeabschnitt ersetzt. Das heißt, ein upgedateter Lese-Schreib-Kodeabschnitt würde empfangen werden und würde den Lese-Schreib-Kodeabschnitt in dem Kodespeicherabschnitt ersetzten. Ein upgedateter Kodeabschnitt-Adresstabellen-Kodeabschnitt würde empfangen werden und würde den Kodeabschnitt-Adresstabellen-Kodeabschnitt in dem Kodespeicherabschnitt ersetzen. Ein upgedateter Symboloffset-Adresstabellen-Kodeabschnitt würde empfangen werden und würde den Symboloffset-Adresstabellen-Kodeabschnitt in dem Kodespeicherabschnitt ersetzen. Ein upgedateter Symbolzugriffskodeabschnitt würde empfangen werden und würde den Symbolzugriffskodeabschnitt in dem Kodespeicherabschnitt ersetzen. In ähnlicher Weise würde ein upgedateter Patchmanager-Kodeabschnitt (mit einer Patchbibliothek) empfangen werden und würde den Patchmanager-Kodeabschnitt in dem Kodespeicherabschnitt ersetzen.
Jedoch sind die oben genannten Kodeabschnitte typischerweise miteinander in dem Patchmanager-Kodeabschnitt gebündelt. Folglich wird der Lese-Schreib-Kodeabschnitt in dem Kodespeicherabschnitt mit dem upgedateten Lese-Schreib-Kodeabschnitt von dem Dateisystemabschnitt 110 ersetzt, wenn der Patchmanager-Kodeabschnitt 308 mit dem upgedateten Patchmanager-Kodeabschnitt 450 ersetzt wir. In ähnlicher Weise werden die Kodeabschnitt-Adresstabelle, die Symboloffset-Adresstabelle, die Symbolzugriffskodeabschnitte genauso wie die Patchbibliothek ersetzt, wenn der upgedatete Patchmanager-Kodeabschnitt 450 installiert ist. Die Anordnung der neuen Lese-Schreib-Daten, der neuen Kodeabschnitt-Adresstabelle, der neuen Symboloffset-Adresstabelle, des neuen Symbolzugriffskode und der neuen Patchbibliothek als den upgedateten Patchmanager-Kodeabschnitt 450, zusammen mit den aktuellen Kodeabschnitten in dem Kodespeicherabschnitt bilden upgedatete ausführbare Systemsoftware.
Wenn der Dateisystemabschnitt 110 eine upgedatete Symbolzugriffskodeadresse empfängt, ersetzt der Patchmanager die Symbolzugriffskodeadresse in der ersten Position im Speicher mit upgedateten Symbolzugriffskodeadresse. Wie oben angemerkt, ist die erste Position im Speicher 334 typischerweise im Patchmanager-Kodeabschnitt (siehe 3).
Wie in 3 gesehen, weist die Patchbibliothek 308 auch einen Komprimierer oder eine Komprimierer-Symbolbibliothek 342 auf. Der Komprimierer 342 kann auch als ein getrennter und unabhängiger Kodeabschnitt eingerichtet sein, jedoch ist es, wie oben angemerkt, nützlich und effizient, die Funktionen, die Systemsoftwareupgrades zugeordnet sind, in einen einzelnen Patchmanager-Kodeabschnitt zu bündeln. Im Allgemeinen kann von dem Komprimierer 342 gesagt werden, dass er Kodeabschnitten eine neue Größe zuordnet, so dass neue Abschnitte mit aktuellen Kodeabschnitten in dem Kodespeicherabschnitt 112 angeordnet werden können.
Mit den Organisations-, Herunterlade- und Komprimieraspekten der Erfindung, die jetzt etabliert sind, wird die folgende Diskussion sich auf das dynamische Befehlssatz-Ausführungssystem 300 der drahtlosen Kommunikationsvorrichtung zentrieren. Das System 300 weist ausführbare Systemsoftware und Systemdaten auf, die in Kodeabschnitte differenziert sind, wie oben detailreich diskutiert ist. Ferner weist das System 300 dynamische Befehlssätze zum Operieren auf den Systemdaten und der Systemsoftware und Steuern der Ausführung der Systemsoftware auf. Wie in 4 gesehen, ist ein dynamischer Befehlssatz 470 in den ersten PMRTI 454 organisiert. Wie in 3 gesehen, weist das System auch eine Laufzeit-Engine zum Verarbeiten der dynamischen Befehlssätze auf, die als Laufzeitbibliothek 370 eingerichtet sind. Wie bei der oben genannten Komprimiererbibliothek 342 und der Patchbibliothek 336, ist die Laufzeitbibliothek 370 typischerweise in dem Patchmanager-Kodeabschnitt 308 angeordnet. Jedoch könnte die Laufzeitbibliothek 370 alternativ in einem anderen Kodeabschnitt angeordnet sein, zum Beispiel dem ersten Kodeabschnitt 304.
Die dynamischen Befehlssätze sind ein einzelner oder eine Mehrzahl von Befehlssätzen, die Bedingungs-Betriebskodes aufweisen und im Allgemeinen Datengegenstände aufweisen. Die Laufzeit-Engine liest den Betriebskode und bestimmt, welche Vorgänge ausgeführt werden müssen. Betriebskode kann bedingt, mathematisch, prozedural oder logisch sein. Die Laufzeit-Engine oder Laufzeitbibliothek 370 verarbeitet die dynamischen Befehlssätze zum Durchführen von Operationen, wie zum Beispiel mathematischen oder logischen Operationen. Das heißt, die Laufzeit-Engine liest den dynamischen Befehlssatz 470 und führt eine Folge von Operationen in Antwort auf den Betriebskode durch. Obwohl die dynamischen Befehlssätze nicht auf irgendeine bestimmt Sprache beschränkt sind, ist der Betriebskode typischerweise eine Form von Maschinenkode, da der Speicher der drahtlosen Vorrichtung begrenzt ist und die Ausführungsgeschwindigkeit wichtig ist. Der Betriebskode wird als bedingt angesehen, indem er einen Datengegenstand analysiert und eine Entscheidung als ein Ergebnis der Analyse trifft. Die Laufzeit-Engine kann auch bestimmen, dass eine Operation auf Daten ausgeführt wird, bevor sie analysiert sind.
Zum Beispiel kann der Betriebskode spezifizieren, dass ein Datenwert einer Speichervorrichtung einer drahtlosen Vorrichtung mit einem vorgegebenen Wert verglichen wird. Falls der Datenwert kleiner ist als der vorgegebene Wert, wird der Datenwert zurückgelassen und falls der Datenwert größer ist als der vorgegebene Wert wird er durch den vorgegebenen Wert ersetzt. Alternativ kann der Betriebskode einen zweiten vorgegebenen Wert zu einem Datenwert der Speichervorrichtung der drahtlosen Vorrichtung addieren, bevor die oben genannte Vergleichsoperation durchgeführt wird.
Wie oben erwähnt, empfängt die nichtflüchtige Speichervorrichtung 110 des Dateisystemabschnitts die dynamischen Befehlssätze durch eine Schnittstelle wie zum Beispiel die Luftschnittstelle (Airlink) 150. Wie in 1 gezeigt, kann die Schnittstelle auch eine Hochfrequenz (RF, radio frequency)-Leitung 160 sein. Dann kann der PMRTI von dem FSS 110 empfangen werden, ohne dass die Systemsoftware betriebsbereit ist, wie zum Beispiel in einer Fabrik- Kalibrierumgebung. Der PMRTI kann auch über eine Logik-Port-Schnittstelle 162 oder ein installierbares Speichermodul 164 empfangen werden. Das Speichermodul 164 kann in der drahtlosen Vorrichtung 104 mit Anfangskalibrierung installiert sein, im Feld installiert sein, oder während der Fabrik-Rekalibrierung installiert sein. Obwohl nicht speziell gezeigt, kann der PMRTI über eine Infrarot- oder Bluetooth-Schnittstellen empfangen werden.
8 ist eine Abbildung von Befehlen, auf die von der Laufzeit-Engine 370 zugegriffen wird. Gezeigt ist ein erster Befehl 800, ein zweiter Befehl 802 und ein j-ter Befehl 804, jedoch ist der dynamischen Befehlssatz nicht auf eine bestimmte Anzahl von Befehlen begrenzt. Die Länge des Betriebskodes in jedem Befehl ist fest. Die Laufzeit-Engine 370 erfasst die Länge des Befehls als ein Maß von Bytes oder Bits, und bestimmt, ob der Befehl Datengegenstände aufweist. Die verbleibende Länge des Befehls, nachdem der Betriebskode abgezogen ist, weist die Datengegenstände auf. Die Laufzeit-Engine extrahiert die Datengegenstände aus dem Befehl. Wie gezeigt, wird die Länge 806 des ersten Befehls 800 gemessen und Datengegenstände 808 werden extrahiert. Es ist zu bemerken, dass nicht alle Befehle notwendigerweise zu extrahierende Datengegenstände aufweisen. Die Laufzeit-Engine 370 verwendet die extrahierten Daten 808 beim Durchführen der Sequenz von Operationen, die auf den Betriebskode 801 in dem Befehl 800 antworten.
9 ist eine detailliertere Abbildung des ersten Befehls 800 aus 8. Unter Verwendung des ersten Befehls 800 als ein Beispiel weist der Befehl den Betriebskode 810 und die Daten 808 auf. Der Befehl und insbesondere der Datengegenstandabschnitt 808 weist Symbolidentifizierer auf, die als eine Verbindung zu Symbolen in den Kodeabschnitten der drahtlosen Vorrichtung wirken. Wie im Detail oben erklärt ist, werden die Symbolidentifizierer mit der Kodeabschnitt-Adresstabelle 326 (siehe 5) und der Symboloffset-Adresstabelle 328 (siehe 7) verwendet zum Positionieren des Symbols, das dem Symbolidentifizierer entspricht. Wie gezeigt, ist ein Symbolidentifizierer "X_1" in dem ersten Befehl 800 gezeigt. Die Symboloffset-Adresstabelle 328 positioniert das entsprechende Symbol in einem Kodeabschnitt mit dem "CS_1"-Identifizierer und einem Offset von "3". Die Kodeabschnitt-Adresstabelle 326 ergibt die Startadresse des Kodeabschnitts Eins (302). Auf diese Weise wird das Symbol "X" gefunden (siehe 6).
Nachdem die Laufzeit-Engine Symbole, die den empfangenen Symbolidentifizierern entsprechen, unter Verwendung der Kodeabschnitt-Adresstabelle und der Symboloffset-Adresstabelle lokalisiert, extrahiert sie Daten, wenn die lokalisierten Symbole Datengegenstände sind. Zum Beispiel falls das Symbol "X" ein Datengegenstand in der Symbolbibliothek Eins (310 ist, extrahiert die Laufzeit-Engine sie. Alternativ kann das "X"-Symbol Betriebskode sein, und die Laufzeit-Engine führt das Symbol "X" aus, wenn es lokalisiert ist.
Der PMRTI kann zum Aktualisieren von Systemdaten oder Systemdatengegenständen verwendet werden. In einigen Aspekten der Erfindung sind Systemdaten in einem Kodeabschnitt in dem Dateisystemabschnitt 110, zum Beispiel Kodeabschnitt 472, gespeichert, siehe 4. Die Laufzeit-Engine greift auf Systemdaten vom Kodeabschnitt 472 zu und analysiert die Systemdaten. Die Laufzeit-Engine verarbeitet den Betriebskode der dynamischen Befehlssätze zum Durchführen mathematischer oder logischer Operation auf Datengegenständen, wie oben beschrieben. Nach der Operation verarbeitet die Laufzeit- Engine die Befehle zum Erzeugen upgedateter Systemdaten. Es ist anzumerken, dass die upgedateten Systemdaten unveränderte Datengegenstände unter einigen Umständen aufweisen können. Die Systemdaten in dem zweiten Kodeabschnitt 472 werden mit den upgedateten Systemdaten in Antwort auf den Betriebskode ersetzt. Folglich, durch Verarbeiten der Befehle durch die Laufzeit-Engine, wird die Systemsoftware zum Ausführen unter Verwendung der upgedateten Systemdaten im Kodeabschnitt 472 gesteuert. Auf diese Weise können spezifisch abgezielte Symbole in der Systemsoftware upgedatet werden, ohne gesamte Kodeabschnitte zu ersetzen. Durch den gleichen Prozess können die Systemdaten in einem Kodeabschnitt in dem Kodespeicherabschnitt 112 ersetzt werden. Zum Beispiel können die Systemdaten in dem dritten Kodeabschnitt 344 gespeichert werden, und die Laufzeit-Engine kann die Systemdaten in dem dritten Kodeabschnitt in Antwort auf den Betriebskode mit upgedateten Systemdaten ersetzen.
Der PMRTI kann auch zum Aktualisieren von Datengegenständen in der flüchtigen Speichervorrichtung 114 verwendet werden. Als ein Beispiel nimmt die flüchtige Speichervorrichtung 114 Lese-Schreib-Daten 330 an, siehe 1. Die Lese-Schreib-Daten können von einer, oder von einer Mehrzahl von Kodeabschnitten in dem Kodespeicherabschnitt 112 und/oder dem FSS 100 sein. Die Laufzeit-Engine greift auf die Lese-Schreib-Daten zu, analysiert die Lese-Schreib-Daten 330, erzeugt upgedatete Lese-Schreib-Daten und ersetzt die Lese-Schreib-Daten 330 in der flüchtigen Speichervorrichtung 114 mit den upgedateten Lese-Schreib-Daten in Antwort auf den Betriebskode. Dann wird die Systemsoftware gesteuert zum Ausführen unter Verwendung der upgedateten Lese-Schreib-Daten in der flüchtigen Speichervorrichtung 114.
In einigen Aspekten der Erfindung überwacht die Laufzeit-Engine die Ausführung der Systemsoftware. Leistungsüberwachung ist breit definiert zum Aufweisen einer großen Anzahl von Aktivitäten der drahtlosen Vorrichtung. Zum Beispiel können Daten wie zum Beispiel Kanalparameter, Kanalkenngrößen, Systemstack, Fehlerzustände oder eine Sammlung von Datengegenständen im RAM mittels einer Sequenz von Operationen, die zu einem spezifischen Fehlerzustand oder einem reduzierten Leistungszustand führen, gesammelt werden. Es ist auch möglich, dynamische Befehlssätze zum Analysieren gesammelter Leitungsdaten, Bereitstellen upgedateter Datenvarianten und Wiedernahmedaten zum Studieren möglicher Lösungen des Problems zu verwenden. Zeitweilige Fixes können auch unter Verwendung von PMRTI-Prozessen bereitgestellt werden.
Insbesondere sammelt die Laufzeit-Engine Leistungsdaten und speichert die Leistungsdaten in dem Dateisystemabschnitt in Antwort auf den Betriebskode. Dann wird die Systemsoftware gesteuert zum Ausführen durch Sammeln der Leistungsdaten zur Auswertung der Systemsoftware. Auswertung kann als eine Form von Analysis auftreten, die von dynamischem Befehlssatz-Betriebskode durchgeführt wird, oder sie kann außerhalb der drahtlosen Vorrichtung durchgeführt werden. In einigen Aspekten der Erfindung greift die Laufzeit-Engine auf die Leitungsdaten zu, die von dem Dateisystemabschnitt gesammelt wurden, und überträgt die Leistungsdaten über eine Luftschnittstellen-Kommunikationsverbindung in Antwort auf den Betriebskode. Das Sammeln von Leitungsdaten von drahtlosen Vorrichtung im Feld erlaubt einem Hersteller, Probleme, entweder lokal oder globale, tiefgreifend zu analysieren, ohne die Vorrichtungen zurückzurufen.
In einigen Aspekten der Erfindung empfängt der Dateisystemabschnitt 110 einen Patchmanager-Laufzeitbefehl, der einen neuen Kodeabschnitt aufweist. Zum Beispiel ist ein neuer Kodeabschnitt 474 in 4 gezeigt. Alternativ kann der neue Kodeabschnitt von der PMRTI unabhängig sein, wie zum Beispiel der neue Kodeabschnitt n (450). Zum Beispiel kann der neue Kodeabschnitt n (450) in früheren Luftschnittstellen-Kommunikationsverbindung empfangen worden sein, oder während einer Fabrik-Kalibrierung installiert worden sein. Die Laufzeit-Engine fügt den neuen Kodeabschnitt 474 (450) in Antwort auf den Betriebskode zu dem Kodespeicherabschnitt hinzu. In einigen Aspekten der Erfindung wird der neue Kodeabschnitt zu einem unverwendeten Block in dem Kodespeicherabschnitt 112 hinzugefügt. Alternativ wird eine Komprimieroperation benötigt. Dann wird die Systemsoftware gesteuert zum Ausführen unter Verwendung des neuen Kodeabschnitts 474 (450). In anderen Aspekten der Erfindung, weist der PMRTI 454 einen upgedateten Kodeabschnitt 474 auf. Alternativ ist der neue Kodeabschnitt 450 ein upgedateter Kodeabschnitt, der von der PMRTI unabhängig ist. Die Laufzeit-Engine ersetzt einen Kodeabschnitt in dem Kodespeicherabschnitt, zum Beispiel Kodeabschnitt Zwei (304), mit dem upgedateten Kodeabschnitt 474 (450) in Antwort auf den Betriebskode. Die Systemsoftware wird gesteuert zum Ausführen unter Verwendung des upgedateten Kodeabschnitts 474 (450). In einigen Aspekten der Erfindung wird eine Komprimieroperation benötigt zum Aufnehmen des upgedateten Kodeabschnitts. Alternativ wird der upgedatete Kodeabschnitt zu einem unverwendeten oder freien Abschnitt des Kodespeicherabschnitts hinzugefügt.
Wie oben erklärt, benötigt das Hinzufügen eines neuen Kodeabschnitts oder das Aktualisieren eines Kodeabschnitts typischerweise die Erzeugung einer neuen Kodeabschnitt- Adresstabelle, das diese Operation entweder neue und/oder geänderte Kodeabschnitt-Startadressen involviert. Ferner benötigt auch eine Komprimieroperation eine neue Kodeabschnitt-Adresstabelle. Die Komprimieroperationen können ein Ergebnis der Operation des Komprimierer 342, wie oben erklärt, oder das Ergebnis der PMRTI-Befehle sein, die Details bereitstellen, wie die Komprimierung aufzutauchen hat. Wenn der PMRTI Herunterlade- und Komprimierbefehle aufweist, weist der PMRTI typischerweise auch eine neue Kodeabschnitt-Adresstabelle auf, die gültig wird, nachdem die Herunterlade- und Komprimieroperationen abgeschlossen wurden.
Die 10A und 10B sind Flussdiagramme, die die Verfahren zum Ausführen dynamischer Befehlssätze in einer drahtlosen Kommunikationsvorrichtung gemäß der Erfindung darstellen. Obwohl als eine Sequenz von nummerierten Schritten zu Klarheit dargestellt, sollte keine Reihenfolge aus der Nummerierung (und der Nummerierung in den unten dargestellten Verfahren) geschlossen werden, solange nicht explizit angegeben. Das Verfahren startet mit Schritt 1000. Schritt 1001a bildet die Systemsoftware in Symbolbibliotheken ab, wobei jede Symbolbibliothek Symbole mit verwandter Funktionalität aufweist. Schritt 1001b ordnet die Symbolbibliotheken in Kodeabschnitten an. Schritt 1002 führt Systemsoftware aus. Schritt 1003 empfängt die dynamischen Befehlssätze. Das Empfangen der dynamischen Befehlssätze in Schritt 1003 weist den Empfang der dynamischen Befehlssätze durch eine Schnittstelle auf, die aus der Gruppe ausgewählt ist, die Luftschnittstellen-, Hochfrequenz (RF)-Leitungs-, installierbare Speichermodul-, Infrarot- und Logikanschluss-Schnittstellen aufweist. In einigen Aspekten der Erfindung weist der Empfang des dynamischen Befehlssatzes in Schritt 1003 ein Empfangen eines Patchmanager-Laufzeitbefehls (PMRTI, patch manager run time instruction) in einem nichtflüchtigen Dateisystemabschnittspeicher auf.
Schritt 1004 startet eine Laufzeit-Engine. Typischerweise weist das Starten einer Laufzeit-Engine das Aufrufen einer Laufzeitbibliothek von einem ersten Kodeabschnitt auf. Die Laufzeit-Engine kann von entweder einer flüchtigen oder einer nichtflüchtigen Speichervorrichtung gestartet werden. Schritt 1006 führt dynamische Befehlssätze durch. Durchführen dynamischer Befehlssätze weist ein Durchführen von Befehlen in Antwort auf mathematische und logische Operationen auf. In einigen Aspekten der Erfindung löscht Schritt 1007 (nicht gezeigt), der dem Durchführen der dynamischen Befehlssätze folgt, dynamische Befehlssätze. Schritt 1008 wirkt auf Systemdaten und Systemsoftware. Schritt 1010 steuert die Ausführung der Systemsoftware in Antwort auf die Operation auf den Systemdaten und der Systemsoftware.
Typischerweise weist ein Empfangen der Patchmanager-Laufzeitbefehle in Schritt 1003 ein Empfangen von bedingen Betriebskodes und von Datengegenständen auf. Dann weist das Verarbeiten dynamischer Befehlssätze in Schritt 1006 Unterschritte auf. Schritt 1006a1 verwendet die Laufzeit-Engine zum Lesen des Patchmanager-Laufzeitbefehl-Betriebskodes. Schritt 1006b führt eine Sequenz von Operationen in Antwort auf den Betriebskode durch.
In einigen Aspekten weist das Anordnen der Symbolbibliothek in Kodeabschnitte in Schritt 1001b das Starten von Symbolbibliotheken am Start von Kodeabschnitten und Anordnen von Symbolen um von ihren jeweiligen Kodeabschnitt-Startadressen einen Offset aufzuweisen, auf. Dann weist das Verfahren weitere Schritte auf. Schritt 1001c speichert den Satz von Kodeabschnitten an entsprechenden Startadressen. Schritt 1001d hält eine Kodeabschnitt-Adresstabelle (CSAT, code section address table), die Kodeabschnitt-Identifizierer mit entsprechenden Startadressen querverweist, aufrecht. Schritt 1001e hält eine Symboloffset-Adresstabelle (SOAT, symbol offset address table), die Symbolidentifizierer mit entsprechenden Offsetadressen und entsprechenden Kodeabschnitt-Identifizierer querverweist, aufrecht.
In einigen Aspekten der Erfindung weist das Empfangen des Patchmanager-Laufzeitbefehls in Schritt 1003 das Empfangen von Symbolidentifizierern auf. Dann weist das Verfahren einen weiteren Schritt auf. Schritt 1006a2 lokalisiert Symbole, die den empfangenen Symbolidentifizierern entsprechen, unter Verwendung der Kodeabschnitt-Adresstabelle und der Symboloffset-Adresstabelle. Ein Durchführen einer Sequenz von Operationen in Antwort auf den Betriebskode in Schritt 1006b weist Unterschritte auf. Schritt 1006b1 extrahiert die Daten, wenn die lokalisierten Symbole Datengegenstände sind. Schritt 1006b2 führt die Symbole aus, wenn die lokalisierten Symbole Befehle sind.
In einigen Aspekten der Erfindung weist das Durchführen dynamischer Befehlssätze in Schritt 1006b1 zusätzliche Unterschritte auf. Schritt 1006b1a verwendet die Laufzeit-Engine zum Erfassen der Länge des Patchmanager-Laufzeitbefehls. Schritt 1006b1b extrahiert die Datengegenstände von dem Patchmanager-Laufzeitbefehl in Antwort auf den Betriebskode. Schritt 1006b1c verwendet die extrahierten Daten beim Durchführen der Sequenz von Operationen, die auf den Betriebskode antworten.
11 ist ein Flussdiagramm, das eine beispielhafte dynamische Befehlssatzoperation darstellt. Einige der Schritte in 11 sind die gleichen wie in 10 und sind im Interesse der Kürze hier nicht wiederholt. Durchführen dynamischer Befehlssätze in Schritt 1106 weist Unterschritte auf. Schritt 1106a greift auf Systemdaten zu, die in einem zweiten Kodeabschnitt in dem Dateisystemabschnitt gespeichert sind. Schritt 1106b analysiert die Systemdaten. Schritt 1106c erzeugt upgedatete Systemdaten. Dann weist ein Operieren auf Systemdaten und Systemsoftware in Schritt 1180 ein Ersetzen der Systemdaten in dem zweiten Abschnitt mit den upgedateten Systemdaten und ein Steuern der Ausführung der Systemsoftware in Schritt 1010 weist ein Verwenden der upgedateten Systemdaten in der Ausführung der Systemsoftware auf.
12 ist ein Flussdiagramm, das eine andere beispielhafte dynamische Befehlssatzoperation darstellt. Einige der Schritte in 12 sind die gleichen wie in 10 und sind hier im Interesse der Kürze nicht wiederholt. Schritt 1201c speichert eine Mehrzahl von Kodeabschnitten in einer nichtflüchtigen Kodespeicherabschnitt-Speichervorrichtung. Ein Durchführen dynamischer Befehlssätze in Schritt 1206 weist Unterschritte auf. Schritt 1206a greift auf Systemdaten zu, die in einem dritten Kodeabschnitt in dem Kodespeicherabschnitt (CSS, code storage section) gespeichert sind. Schritt 1206b analysiert die Systemdaten. Schritt 1206c erzeugt upgedatete Systemdaten. Eine Operation auf den Systemdaten und der Systemsoftware in Schritt 1208 weist ein Ersetzen der Systemdaten in dem dritten Kodeabschnitt mit den upgedateten Systemdaten auf. Ein Steuern der Ausführung der Systemsoftware in Schritt 1210 weist ein Verwenden der upgedateten Systemdaten bei der Ausführung der Systemsoftware auf.
13 ist ein Flussdiagramm, das eine dritte beispielhafte dynamische Befehlssatzoperation darstellt. Einige der Schritte in 13 sind die gleichen wie in 10 und sind hier im Interesse der Kürze nicht wiederholt. Schritt 1301c speichert eine Mehrzahl von Kodeabschnitten in einer nichtflüchtigen Kodespeicherabschnitt-Speichervorrichtung. Schritt 1301d lädt Lese-Schreib-Daten in der flüchtigen Speichervorrichtung. Ein Durchführen dynamischer Befehlssätze in Schritt 1306 weist Unterschritte auf. Schritt 1306a greift auf die Lese-Schreib-Daten in der flüchtigen Speichervorrichtung zu. Schritt 1306b analysiert die Lese-Schreib-Daten. Schritt 1306c erzeugt upgedatete Lese-Schreib-Daten. Eine Operation auf den Systemdaten und der Systemsoftware in Schritt 1308 weist ein Ersetzen der Lese-Schreib-Daten im der flüchtigen Speichervorrichtung mit den upgedateten Lese-Schreib-Daten auf. Ein Steuern der Ausführung der Systemsoftware weist ein Verwenden der upgedateten Lese-Schreib-Daten bei der Ausführung der Systemsoftware auf.
14 ist ein Flussdiagramm, das eine vierte beispielhafte dynamische Befehlssatzoperation darstellt. Einige der Schritte in 14 sind die gleichen wie in 10 und sind hier im Interesse der Kürze nicht wiederholt. Ein Durchführen dynamischer Befehlssätze weist Unterschritte auf. Schritt 1406a überwacht die Ausführung der Systemsoftware in Antwort auf den Betriebskode. Schritt 1406b sammelt Leistungsdaten. Schritt 1406c speichert die Leistungsdaten. Schritt 1406d überträgt die gespeicherten Daten über eine Luftschnittstellen-Kommunikationsverbindung. Eine Operation auf den Systemdaten und der Systemsoftware in Schritt 1408 weist ein Verwenden der Leistungsdaten in der Auswertung der Systemsoftware auf.
15 ist ein Flussdiagramm, das eine fünfte beispielhafte dynamische Befehlssatzoperation darstellt. Einige der Schritte in 15 sind die gleichen wie in 10 und sind hier im Interesse der Kürze nicht wiederholt. Schritt 1501c speichert eine Mehrzahl von Kodeabschnitten in einer nichtflüchtigen Kodespeicherabschnitt-Speichervorrichtung. Ein Empfangen von Patchmanager-Laufzeitbefehlen in Schritt 1503 weist ein Empfangen eines neuen Kodeabschnitts auf. Eine Operation auf den Systemdaten und der Systemsoftware in Schritt 1508 weist ein Hinzufügen des neuen Kodeabschnitts zu den Kodespeicherabschnitt und das Steuern der Ausführung der Systemsoftware in Schritt 1510 weist ein Verwenden des neuen Kodeabschnitts in der Ausführung der Systemsoftware auf.
Alternativ weist das Empfangen eines neuen Kodeabschnitts in Schritt 1503 ein Empfangen eines upgedateten Kodeabschnitts auf. Dann weist eine Operation auf den Systemdaten und der Systemsoftware in Schritt 1508 ein Ersetzen eines vierten Kodeabschnitts in dem Kodespeicherabschnitt mit dem upgedateten Kodeabschnitt auf.
Ein System und Verfahren wurden zum Ausführen dynamischer Befehlssätze in einer drahtlosen Kommunikationsvorrichtung vorgesehen, um in dem Prozess des Aktualisierens der Software und Überwachen der Leistung der Software zu helfen. Das System ist aufgrund der Anordnung von Symbolbibliotheken in Kodeabschnitten mit Tabellen zum Zugreifen auf die Startadressen der Kodeabschnitt im Speicher und die Offsetadressen von Symbolen in den Symbolbibliotheken einfach aktualisierbar. Die Verwendung auf dynamische Befehlssätze erlaubt, das maßgeschneiderte Modifikationen für jede drahtlose Vorrichtung durchgeführt werden, basierend auf spezifischen Kenngrößen dieser Vorrichtung. Ein paar wenige allgemeine Beispiel wurden angegeben, die mögliche Verwendungen für die dynamischen Befehlssätze darstellen. Jedoch ist die Erfindung nicht auf gerade diese Beispiele beschränkt. Andere Variationen und Ausführungsbeispiele der Erfindung werden für Fachleute auftauchen.
16 ist ein High-Level-Netzwerkdiagramm, das eine beispielhaftes drahtloses Kommunikationsnetzwerk darstellt. Das dargestellte drahtlose Kommunikationsnetzwerk weist eine Mehrzahl von drahtlosen Kommunikationsvorrichtungen 10, 12 und 14; eine Mehrzahl von Basisstationen 20 und 22; und einen PMRTI-Serverrechner 30 auf, der mit den drahtlosen Kommunikationsvorrichtungen 10, 12 und 14 über ein Netzwerk 40 gekoppelt ist.
Die drahtlose Kommunikationsvorrichtung 10 kann jede Sorte von Vorrichtung mit der Fähigkeit zum Kommunizieren innerhalb des drahtlosen Kommunikationsnetzwerks 100 sein. Zum Beispiel kann die drahtlose Kommunikationsvorrichtung 10 ein Mobiltelefon, ein persönlicher digitaler Assistent ("PDA", personal digital assistant), ein Laptop-Computer, eine Armbanduhr oder jede andere Vorrichtung, die für drahtlose Kommunikation eingerichtet ist, sein. Drahtlose Kommunikationsvorrichtung können hierin auch als "Handgeräte" oder "Mobiltelefone" oder "Mobilvorrichtungen" bezeichnet werden.
Die Basisstation 20 ist vorzugsweise zum Kommunizieren mit einer Mehrzahl drahtloser Kommunikationsvorrichtung über Funk eingerichtet, und weist einen Transceiver (nicht gezeigt) auf, der die Funkkommunikation in drahtgebundene Kommunikation umwandelt, die über das Netzwerk 40 läuft. Vorzugsweise ist das Netzwerk 40 ein privates Netzwerk, das von dem Drahtlos-Betreiber betrieben wird. Das Netzwerk 40 stellt vorzugsweise die Infrastruktur für Übergabeanrufe zwischen Basisstationen, wie zum Beispiel Basisstation 20 und 22 bereit. Zusätzlich stellt das Netzwerk 40 vorzugsweise die Kommunikationsverbindung zwischen verschiedenen Anwendungen, Diensten und anderen Computer-basierten Serverrechnern, wie zum Beispiel dem PMRTI-Serverrechner 30, bereit.
Das Netzwerk 40 kann auch als Leitung für Verbindungen zu anderen Netzwerken (nicht abgebildet), wie zum Beispiel einem digitalen Netzwerk mit integrierten Diensten (ISDN, integrated services digital network), einem öffentlichen geschalteten Telefonnetzwerk ("PSTN", public switched telephone network), einem öffentlichen Land-basierten Mobilnetzwerk ("PLMN", public land mobile network), einem öffentlichen Paket-geschalteten Datennetzwerk ("PSPDN", packet switched public data network) und dem Internet, um nur wenige zu nennen, dienen. Der PMRTI-Server 30 kann als ein einzelner Computer oder als eine Mehrzahl von Serverrechnern, die logisch angeordnet sind, zum Bereitstellen dynamischer Befehlssätze an Mobilvorrichtung und zum Ausführen dynamischer Befehlssätze, die von Mobilvorrichtungen empfangen werden, eingerichtet sein.
17A ist ein Blockdiagramm, das eine beispielhafte drahtlose Kommunikationsvorrichtung 10 darstellt. Die allgemeinen Merkmale der drahtlosen Kommunikationsvorrichtung 10, die ihm erlauben, als solches zu funktionieren, sind in der Technik gut bekannt, und sind daher hierin nicht dargestellt oder beschrieben.
Die drahtlose Kommunikationsvorrichtung 10 weist eine Laufzeit-Engine 50, eine Entfernt-Betriebskode ("Opcode")-Bibliothek 60, eine Serverrechner-Opcodebibliothek 70 und entfernte Laufzeitbefehls-Kodeabschnitt 80 auf. Die Laufzeit-Engine 50 ist vorzugsweise zum Durchführen dynamischer Befehlssätze eingerichtet. Ein Beispiel eines dynamischen Befehlssatzes ist ein PMRTI-Befehlssatz. Ein anderes Beispiel eines dynamischen Befehlssatzes ist ein RPMRTI-Befehlssatz. Der Unterschied zwischen diesen beiden Befehlssätzen ist, dass der PMRTI-Satz jene Funktionen aufweist, die von der drahtlosen Vorrichtung ausgeführt werden können, während der RPMRTI-Befehlssatz jene Funktionen aufweist, die von dem PMRTI-Serverrechner 30 ausgeführt werden können, der auf dem Netzwerk 40 liegt. Die Durchführung von dynamischen Befehlssätzen weist die Ausführung von PMRTI-Sätzen auf, die von dem PMRTI-Serverrechner 30 empfangen werden, und die Kompilierung von RPMRTI-Sätzen und entsprechender Daten zur Lieferung an den PMRTI-Serverrechner 30. Vorzugsweise kann die Laufzeit-Engine 50 von der drahtlosen Kommunikationsvorrichtung 10 gestartet werden, wenn sie gebraucht wird, so dass sie nur wenn nötig läuft und eine minimale Menge von Systemressourcen (z.B. Speicher, CPU-Zyklen, usw.) auf der Vorrichtung 10 konsumiert.
Die Entfernt-Opcodebibliothek 60 weist vorzugsweise die Gesamtheit der Betriebskodes auf, die jede PMRTI-Funktion oder jedes ausführbare Kodesegment darstellen. Vorteilhafterweise weist die Entfernt-Opcodebibliothek 60 die Betriebskodes auf, die als Platzhalter für die aktuellen ausführbaren Maschinenkodefunktionen oder -Kodesegmente dienen. Als solche weist die Entfernt-Opcodebibliothek 60 eine Liste aller verfügbarer Betriebskodes auf, die allen und jeder PMRTI-Funktion entsprechen, die von der drahtlosen Kommunikationsvorrichtung 10 ausgeführt werden können.
In ähnlicher Weise weist die Serverrechner-Opcodebibliothek 70 vorzugsweise die Gesamtheit von Betriebskodes auf, die jede RPMRTI-Funktion oder ausführbares Kodesegment darstellen. Vorteilhafterweise weist die Serverrechner-Opcodebibliothek 70 nur die Betriebskodes für die aktuelle ausführbaren Maschinenkodefunktionen oder Kodesegmenten auf, die nicht auf der drahtlosen Kommunikationsvorrichtung 10 liegen. Als solche weist die Serverrechner-Opcodebibliothek 70 eine Liste aller Betriebskodes für jede verfügbare RPMRTI-Funktion auf, die von dem PMRTI-Serverrechner 30 für die drahtlose Kommunikationsvorrichtung 10 ausgeführt werden kann.
In dem bevorzugten Ausführungsbeispiel kann die Anzahl verfügbarer RPMRTI-Funktionen die Anzahl verfügbarer PMRTI-Funktionen weit übersteigen, da der PMRTI-Serverrechner 30 nicht an den minimalen Ressourcen leidet, die typischerweise auf Mobilvorrichtungen, wie zum Beispiel Mobiltelefonen und PDAs, gefunden werden.
Ferner weist die drahtlose Kommunikationsvorrichtung 10 entfernte Laufzeitbefehls-Kodeabschnitt 80 auf. Der Kodeabschnitt 80 ist, wo der aktuelle Maschinenkode oder ausführbare Befehlet in persistentem Speicher auf der Vorrichtung 10 liegen. Diese ausführbaren Befehle oder Kodesegmente entsprechen vorzugsweise in einer Eins-zu-Eins-Beziehung den Opcodes, die in der Entfernt-Opcodebibliothek 60 enthalten sind. 17b ist ein Blockdiagramm, das einen beispielhaften Kodeabschnitt 80 aufweist, von Befehl 01 bis Befehl n. Optimalerweise sind eine große Anzahl von Funktionen im Kodeabschnitt 80 verfügbar, wobei sie sehr wenig Ressourcen (z.B. persistenten Speicher) der Vorrichtung 10 konsumieren.
Vorteilhafterweise können die Serverrechner-Opcodebibliothek 70, die Entfernt-Opcodebibliothek 60 und die entsprechende Kodeabschnitt 80 im persistenten Speicher auf der drahtlosen Kommunikationsvorrichtung während des Herstellens der Vorrichtung 10 und vor seinem Verbreiten im Feld (d.h. bevor es an Verbraucher verkauft wird) installiert werden. Zukünftige Aktualisierungen für den Opcodesatz, der in jeder Bibliothek enthalten ist, oder für den Satz von ausführbaren Befehlen in dem Kodeabschnitt 80, können von dem PMRTI-Serverrechner 30 vorgesehen sein, der den Prozess implementiert, der später mit Bezugnahme zu 22 beschrieben ist.
Schließlich weist in dem dargestellten Ausführungsbeispiel die drahtlose Kommunikationsvorrichtung eine Funk-Kommunikationsverbindung 90 auf. Die Implementierung der Kommunikationsverbindung 90 ist in der Technik allgemein bekannt und schafft eine drahtlose Kommunikationsvorrichtung 10 mit der Fähigkeit zum Kommunizieren innerhalb des drahtlosen Kommunikationsnetzwerks 100 über eine Radio- oder eine andere Funk-Verbindung. Vorteilhafterweise kann die Funk-Kommunikationsverbindung 90 die Mittel für den PMRTI-Serverrechner 30 zum Aktualisieren der Entfernt-Opcodebibliothek 60, der Serverrechner-Opcodebibliothek 70 und des entfernten Laufzeitbefehls-Kodeabschnitts 80 bereitstellen.
18A ist ein Blockdiagramm, das einen beispielhaften PMRTI-Serverrechner 30 darstellt. Die Merkmale eines Universalcomputers, der den PMRTI-Serverrechner implementiert sind später mit Bezugnahme zu 23 beschreiben.
In dem dargestellten Ausführungsbeispiel weist der PMRTI-Serverrechner 30 ein Steuermodul 95, eine Entfernt- Opcodebibliothek 60, eine Serverrechner-Opcodebibliothek 70 und einen Serverrechner-Laufzeitbefehls-Kodeabschnitt 82 auf. Die Entfernt-Opcodebibliothek 60 und die Serverrechner-Opcodebibliothek 70 weisen vorzugsweise die gleiche Liste von Opcodes auf wie die Bibliotheken die in der drahtlosen Kommunikationsvorrichtung 10 gegenwärtig sind. Das Steuermodul 95 ist vorzugsweise zum Durchführen dynamischer Befehlssätze und Verwalten eines Netzwerks von PMRTI-Kommunikationen zwischen dem PMRTI-Serverrechner 30 und einer Mehrzahl von drahtlosen Kommunikationsvorrichtung, die über das drahtlose Kommunikationsnetzwerk verfügbar sind, eingerichtet.
Zum Beispiel kann das Steuermodul 95 verschiedene dynamische PMRTI-Sätze kompilieren und diese Befehlssätze an eine Mehrzahl getrennter drahtloser Kommunikationsvorrichtungen senden. In ähnlicher Weise kann das Steuermodul auch eine Mehrzahl dynamischer RPMRTI-Sätzen empfangen und diese Befehlssätze für die sendende drahtlose Kommunikationsvorrichtung ausführen.
Die Entfernt-Opcodebibliothek 60 weist vorzugsweise die Gesamtheit von Betriebskodes auf, die jeder verfügbaren PMRTI-Funktion oder jedem ausführbaren Kodesegment entsprechen. Vorteilhafterweise weist die Entfernt-Opcodebibliothek 60 eine List der Betriebskodes auf, die als Platzhalter für die aktuellen ausführbaren Maschinenkodefunktionen oder -Kodesegmente in dem entfernen Laufzeitbefehls-Kodeabschnitt 80 (auf der drahtlosen Kommunikationsvorrichtung) dienen. Als solches weist die Entfernt-Opcodebibliothek 60 eine Liste aller verfügbaren Opcodes für alle verfügbaren PMRTI-Funktionen auf, die von einer drahtlosen Kommunikationsvorrichtung ausgeführt werden können.
In ähnlicher Weise weist die Serverrechner-Opcodebibliothek 70 die Gesamtheit von Betriebskodes auf, die jeder RPMRTI-Funkiton oder ausführbarem Kodesegment entsprechen. Vorteilhafterweise weist die Serverrechner-Opcodebibliothek 70 nur die Betriebskodes für die aktuellen ausführbaren Maschinenkodefunktionen oder -Kodesegmente auf, die von dem PMRTI-Serverrechner 30 ausgeführt werden können. Vorzugsweise übersteigt die Anzahl von verfügbaren RPMRTI-Funktionen die Anzahl von verfügbaren PMRTI-Funktionen weit, da der PMRTI-Serverrechner 30 nicht an den minimalen Ressourcen leidet, die typischerweise auf Mobilvorrichtung, wie zum Beispiel Mobiltelefonen und PDAs, vorgefunden werden.
Zusätzlich weist der PMRTI-Serverrechner 30 den Serverrechner-Laufzeitbefehls-Kodeabschnitt 82 auf. Der Kodeabschnitt 82 ist, wo der aktuelle Maschinenkode oder ausführbare Befehle in der persistenten Speichervorrichtung auf dem Serverrechner 30 liegen. Diese ausführbaren Befehle oder Kodesegmente entsprechen vorzugsweise in einer Eins-zu-Eins-Beziehung den Betriebskodes, die in der Serverrechner-Opcodebibliothek 70 enthalten sind, die sowohl auf dem Serverrechner 30 als auch auf der drahtlosen Kommunikationsvorrichtung 10 liegen. 18B ist ein Blockdiagramm, das einen beispielhaften Serverrechner-Laufzeitbefehls-Kodeabschnitt darstellt.
19 ist ein Flussdiagramm, das einen beispielhaften Prozess zum Ausführen dynamischer Befehlssätze auf einer drahtlosen Kommunikationsvorrichtung darstellt. Ursprünglich, in Schritt 500, empfängt die drahtlose Vorrichtung einen Satz von Entfernt-Opcodes. Der Satz von Entfernt-Opcodes kann über ein Funk-Kommunikationsverbindung, zum Beispiel eine Verbindung mit einem drahtlosen Kommunikationsnetzwerk, empfangen werden. Vorzugsweise sind die Opcodes zum Minimieren der Menge an gefunkten Daten optimiert. Zusätzlich können Nutzdaten in dem Satz von Opcodes, der über die drahtlose Vorrichtung empfangen wird, enthalten sein.
In Schritt 502 startet die drahtlose Vorrichtung seine Laufzeit-Engine zum Verarbeiten des Entfernt-Opcodesatzes. Wie in Schritt 504 dargestellt, analysiert die Laufzeit-Engine den Entfernt-Opcodesatz und extrahiert dann die Nutzdaten in Schritt 506. Falls keine Nutzdaten existieren, kann dieser Schritt übersprungen werden. Falls Nutzdaten existieren, können die resultierenden Daten in einem verfügbaren Abschnitt eines flüchtigen Speichers zur späteren Verwendung gespeichert werden. Als Nächstes erhält die Laufzeit-Engine die ausführbaren Befehle, die den Opcodes in dem Entfernt-Opcodesatz entsprechen, wie in Schritt 508 gezeigt ist. Diese Befehle können aus dem entfernten Laufzeitbefehls-Kodeabschnitt der drahtlosen Vorrichtung erhalten werden.
Wenn die ausführbaren Befehle, die den Opcodes in dem Entfernt-Opcodesatz entsprechen, erhalten wurden, führt die Laufzeit-Engine die Befehle aus, wie in Schritt 510 dargestellt ist. Wenn die Befehle ausgeführt werden, können alle notwendigen Daten auf denen operiert wird, aus dem flüchtigen Speicher erhalten werden, wo die Nutzdaten gespeichert sind. Alternativ oder zusätzlich können alle notwendigen Daten auf denen operiert wird, als das Ergebnis eines ausgeführten Befehls erhalten werden.
Zum Beispiel können die Nutzdaten ein upgedatetes Softwaremodul für die drahtlose Vorrichtung aufweisen. Zusätzliche kann einer der Opcodes in dem Entfernt-Opcodesatz einem ausführbaren Befehl zum Ersetzen eines Abschnitts eines persistenten Speichers mit einem Abschnitt der Nutzdaten entsprechen. In diesem Beispiel ist der Abschnitt des ersetzten persistenten Speichers das veraltete Softwaremodul und als eine Ergebnis wird das upgedatete Softwaremodul von dem Befehl in den persistenten Speicher geladen. Folglich operieren der Entfernt-Opcodesatz und die Nutzdaten auf der drahtlosen Vorrichtung zum Aktualisieren eines Softwaremoduls.
Wenn der Befehlssatz in seiner Gesamtheit von der Laufzeit-Engine ausgeführt wurde, kann die Laufzeit-Engine beendet werden, wie in Schritt 512 gezeigt ist. Vorteilhafterweise kann die Laufzeit-Engine gestartet und beendet werden, so dass sie nur wenn nötig läuft. Das spart Systemressourcen auf der drahtlosen Vorrichtung, zum Beispiel kann es flüchtige Speicherplätze und CPU-Zyklen einsparen.
20 ist ein Flussdiagramm, das einen beispielhaften Prozess zum Kompilieren dynamischer Befehlssätze auf einer drahtlosen Kommunikationsvorrichtung darstellt. Zu Anfang ist die Laufzeit-Engine gestartet, wie in Schritt 520 dargestellt ist. Wenn die Laufzeit-Engine läuft, kann die Engine einen Satz von Serverrechner-Opcodes kompilieren, wie in Schritt 522 gezeigt ist. Der Satz von Serverrechner-Opcodes kann von einem Hintergrundprozess erhalten werden, der auf der drahtlosen Vorrichtung läuft. Alternativ kann der Serverrechner-Opcodesatz von einem Prozess erhalten werden, der auf der drahtlosen Vorrichtung unter der Anweisung eines Benutzers läuft.
Zum Beispiel kann die drahtlose Vorrichtung einen Satz von Routinen aufweisen, die periodisch und automatisch von dem Betriebssystem laufen gelassen werden, um eine Systeminstandhaltung oder andere wünschenswerte Funktionen durchzuführen. Diese Prozeduren können, als ein Ergebnis ihrer Ausführung, bewirken, dass ein Serverrechner-Opcodesatz von der Laufzeit-Engine erzeugt wird. Alternativ kann ein Benutzer einen bestimmten Satz von Routinen anstoßen, die nur ausgeführt werden, wenn es von einem Benutzer angefragt wird. Dieser Satz von Routinen kann auch bewirken, dass ein Serverrechner-Opcodesatz von der Laufzeit-Engine erzeugt wird. In beiden Fällen ist das Ergebnis ein Serverrechner-Opcodesatz, der von der Laufzeit-Engine erzeugt ist, wie in Schritt 522 gezeigt.
Wenn der Serverrechner-Opcodesatz erzeugt wurde, bestimmt die Laufzeit-Engine in Schritt 524, ob Nutzdaten den Serverrechner-Opcodesatz begleiten sollen. Falls es Daten gibt, die zusammen mit dem Serverrechner-Opcodesatz gehen sollen, holt die Laufzeit-Engine die Daten aus dem persistenten oder flüchtigen Speicher, oder führt einen Befehl aus, der die benötigten Daten zurückbringt. Wenn die Daten erhalten sind, fügt die Laufzeit-Engine als Nächstes die Daten in den Serverrechner-Opcodesatz ein, wie in Schritt 528 dargestellt. Ein einfacher Weg, um das zu erreichen, ist das Anfügen der Nutzdaten an den Serverrechner-Opcodesatz in einem einzelnen Datenpaket.
Wenn die Nutzdaten mit dem Serverrechner-Opcodesatz kombiniert sind, oder falls keine Nutzdaten benötigt sind, dann sendet die Laufzeit-Engine den Serverrechner-Opcodesatz (mit oder ohne einer Nutzlast) an den Serverrechner, wie in Schritt 530 gezeigt ist. Nachdem der Serverrechner-Opcodesatz gesendet ist, kann die Laufzeit-Engine beendet werden, um Ressourcen auf der drahtlosen Vorrichtung freizumachen, wie in Schritt 532 dargestellt ist.
21 ist ein Flussdiagramm, das einen beispielhaften Prozess zum Ausführen dynamischer Befehlssätze auf einem PMRTI-Serverrechner darstellt. Anfänglich empfängt der Serverrechner in Schritt 540 den Serverrechner-Opcodesatz. Der Opcodesatz ist vorzugsweise eine Liste von Namen, die eine Reihe von ausführbaren Befehlen repräsentieren, wobei jeder Opcode einen eigenständigen ausführbaren Befehl oder einen eigenständigen Satz von ausführbaren Befehlen repräsentiert. Wenn der Satz von Serverrechner-Opcodes empfangen wurde, analysiert der Serverrechner dann den Serverrechner-Opcodesatz in Schritt 542 und extrahiert alle Nutzdaten, die in dem Serverrechner-Opcodesatz enthalten sind, wie in Schritt 544 dargestellt ist. Wenn die Nutzdaten extrahiert sind, können sie zeitweise im flüchtigen Speicher auf dem Serverrechner zum späteren Gebrauch gespeichert werden.
Als Nächstes erhält der Serverrechner den entsprechenden Befehlssatz, wie in Schritt 546 gezeigt ist. Vorzugsweise ist der entsprechende Befehlssatz in einem Serverrechner-Laufzeitbefehls-Kodeabschnitt gespeichert, der im persistenten Speicher auf der PMRTI-Serverrechnermaschine liegt. Wenn einmal der Befehlssatz erhalten wurde, führt der Serverrechner dann den Befehlssatz aus, wie in Schritt 548 gesehen werden kann. Wenn der Befehlssatz ausgeführt wird, können die Ausführungsroutinen die Nutzdaten verwenden, die mit dem Serverrechner-Opcodesatz gekommen sind. Vorzugsweise werden die Nutzdaten im Speicher auf dem Serverrechner zu diesem Zweck gespeichert. Alternativ kann die Ausführungsroutinen Befehle aufweisen, die die Daten erzeugen, die für den Befehlssatz zum Ausführen seiner Funktion notwendig sind.
22 ist ein Flussdiagramm, das einen beispielhaften Prozess zum Synchronisieren von Opcodebibliotheken darstellt. Zu Anfang erhält in Schritt 580 die drahtlose Vorrichtung eine Liste von Serverrechner-Opcodes. Das kann am einfachsten gemacht werden, indem die Serverrechner-Opcodebibliothek konsultiert wird. Alternativ kann eine Routine aufgerufen werden oder ein Programm laufen gelassen werden, wovon das Ergebnis die erwünscht Liste von Serverrechner-Opcodes ist. In einem allgemeinen Sinn kann der Prozess zum Synchronisieren von Opcodebibliotheken periodisch und automatisch von der drahtlosen Vorrichtung gestartet werden oder er kann durch eine Eingabe eines Benutzers gestartet werden.
Wenn eine Liste von Serverrechner-Opcodes erhalten wurde, ist die Liste als Nutzdaten in einen Serverrechner-Opcodesatz eingeschlossen und an den Serverrechner zur Durchführung gesendet, wie in Schritt 582 gezeigt ist. Der Serverrechner führt die Befehle durch, die dem Opcode entsprechen und verarbeitet dadurch die Nutzdaten, die die Liste aller verfügbarer Serverrechner-Opcodes gemäß der drahtlosen Vorrichtung ist. Als Antwort empfängt die drahtlose Vorrichtung einen Entfernt-Opcodesatz und Nutzdaten, wie in Schritt 584 dargestellt ist. Die von dem Serverrechner empfangenen Nutzdaten weisen vorteilhafterweise alle upgedateten oder modifizierten Opcodes und den entsprechenden ausführbaren Befehl auf. Zusätzlich weisen die Nutzdaten auch alle neuen Opcodes und den entsprechenden ausführbaren Befehl auf.
Die drahtlose Vorrichtung extrahiert als Nächstes diese Nutzdaten in Schritt 586 und speichert die Nutzdaten vorzugsweise in einem verfügbaren Speicher der drahtlosen Vorrichtung, zum Beispiel einem freien Segment des flüchtigen Speichers. Wenn die Nutzdaten extrahiert wurden, erhält die drahtlose Vorrichtung die ausführbaren Befehle, die dem Entfernt-Opcodesatz entsprechen, wie in Schritt 588 dargestellt ist. Wenn der Satz ausführbarer Befehle, der dem Entfernt-Opcodesatz entspricht, erhalten wurde, führt die drahtlose Vorrichtung dann diese Befehle aus, wie in Schritt 590 gezeigt ist. Wenn die Befehle ausgeführt sind, können die Daten der Nutzdaten von der zeitweisen Speicherposition innerhalb der drahtlosen Vorrichtung zugegriffen werden. Zum Beispiel kann ein erster ausführbarer Befehle bewirken, dass die drahtlose Vorrichtung einen ersten Abschnitt des persistenten Speichers mit einem ersten Abschnitt der Nutzdaten ersetzt. Nachdem das gemacht ist, ist das Ergebnis vorzugsweise ein upgedateter Serverrechner-Opcode in der Serverrechner-Opcodebibliothek. Entsprechend kann ein zweiter ausführbarer Befehle bewirken, dass die drahtlose Vorrichtung einen zweiten Abschnitt des persistenten Speichers mit einem zweiten Abschnitt der Nutzdaten ersetzt. Nachdem das gemacht ist, ist das Ergebnis vorzugsweise ein upgedateter ausführbarer Befehl in dem Serverrechner-Laufzeitbefehls-Kodeabschnitt. Das erlaubt es der drahtlosen Vorrichtung vorteilhafterweise periodisch den PMRTI-Serverrechner nach Aktualisierungen für seine Funktionalitätseinrichtung anzufragen.
Zusätzliche Anwendungen der Fähigkeit eines Handgeräts zum Konstruieren eines Serverrechner-Opcodesatzes und entsprechender Nutzdaten und Senden derselben an den PMRTI-Serverrechner 30 zum Durchführen, weisen Bereitstellen von Positionsaktualisierungen (z.B. GPS-Informationen), Speichern einer Sprachnachricht auf dem Netzwerk, Senden von Dateien an das Netzwerk und andere Benutzer auf. Im Allgemeinen umfasst das Senden von Dateien an das Netzwerk oder an andere Benutzer einen extrem breiten Bereich wünschenswerter Anwendungen, wie zum Beispiel Senden benutzerdefinierter Klingeltöne an einen Freund oder ein Familienmitglied, Senden von Fotos oder Digitalbilder, die von der drahtlosen Vorrichtung aufgenommen sind, Senden von E-Mails, Dokumenten oder allen anderen wünschenswerten Daten, die auf dem Netzwerk zu speichern sind oder an andere Benutzer zu senden sind.
23 ist ein Blockdiagramm, das ein beispielhaftes Computersystem 550 aufweist, das in Verbindung mit den verschiedenen hierin beschriebenen Beispielen verwendet werden kann. Zum Beispiel kann das Computersystem 550 als der PMRTI-Serverrechner angewendet werden, der innerhalb des drahtlosen Kommunikationsnetzwerks liegt. Das Computersystem 550 kann auch als irgendeines der verschiedenen anderen allgemeinen oder Spezialzweck-Computersysteme angewendet werden, die das drahtlose Kommunikationsnetzwerk und seine Bestandteil-Komponenten aufweisen. Jedoch können andere Computersysteme und Computerarchitekturen verwendet werden, wie für Fachleute klar sein wird.
Das Computersystem 550 weist vorzugsweise einen oder eine Mehrzahl von Prozessoren, wie zum Beispiel Prozessor 552 auf. Zusätzliche Prozessoren können vorgesehen sein, wie zum Beispiel ein Hilfsprozessor zum Verwalten von Eingabe und Ausgabe, ein Hilfsprozessor zum Durchführen von mathematischen Fließpunkt-Operationen, ein Spezialzweck-Mikroprozessor mit einer Architektur, die zur schnellen Ausführung von Signalverarbeitungsalgorithmen geeignet ist (z.B. ein digitaler Signalprozessor), ein Slave-Prozessor, der dem Haupt-Prozessorsystem untergeordnet ist (z.B. Back-End-Prozessor), ein zusätzlicher Mikroprozessor oder Controller für duale oder Mehrfach-Prozessorsysteme oder ein Koprozessor. Solche Hilfsprozessoren können eigenständige Prozessoren sein oder können in dem Prozessor 552 integriert sein.
Der Prozessor 552 ist vorzugsweise mit einem Kommunikationsbus 554 gekoppelt. Der Kommunikationsbus 554 kann einen Datenkanal zum Erleichtern eines Informationstransfers zwischen Speicher- und anderen Peripheriekomponenten des Computersystems 550 aufweisen. Der Kommunikationsbus 554 kann ferner einen Signalsatz bereitstellen, der zur Kommunikation mit dem Prozessor 552 verwendet wird, einschließlich eines Datenbusses, eines Adressbusses und eines Steuerbusses (nicht gezeigt). Der Kommunikationsbus 554 kann jede Standard- oder Nicht-Standard-Busarchitektur aufweisen, wie zum Beispiel Busarchitekturen, die sich nach der Industriestandardarchitektur ("ISA", industry standard architecture), der Erweiterten Industriestandardarchitektur ("EISA", extended industry standard architecture), der Mikrokanalarchitektur ("MCA", micro channel architecture), dem lokalen Peripheriekomponenten-Verbindungs-Bus ("PCT", peripheral component interconnect) richten oder Standards, die von dem Institute of Electrical and Electronics Engineers ("IEEE") verkündet werden, einschließlich IEEE 488-Allzweckschnittstellenbus ("GPIB", general-purpose interface bus), IEEE 696/5-100 und ähnlichen.
Das Computersystem 500 weist vorzugsweise einen Hauptspeicher 556 auf und kann auch einen zweiten Speicher 558 aufweisen. Der Hauptspeicher 556 stellt Speicher für Befehle und Daten für Programme bereit, die auf dem Prozessor 552 ausgeführt werden. Der Hauptspeicher 556 ist typischerweise ein Halbleiter-basierter Speicher, wie zum Beispiel ein dynamischer Speicher mit wahlfreiem Zugriff ("DRAM", dynamic random access memory) und/oder ein statischer Speicher mit wahlfreiem Zugriff ("SRAM", static random access memory). Andere Halbleiter-basierte Speichertypen weisen zum Beispiel einen synchronen dynamischen Speicher mit wahlfreiem Zugriff ("SDRAM", snchronous dynamic random access memory), einen dynamischen Rambus-Speicher mit wahlfreiem Zugriff ("RDRAM", Rambus dynamic random access memory), einen ferroelektrischen Speicher mit wahlfreiem Zugriff ("FRAM", ferroelectric random access memory) und ähnliche auf, einschließlich einem Nur-Lese-Speicher ("ROM", read only memory).
Der Sekundärspeicher 558 kann optional ein Festplattenlaufwerk 560 und/oder ein entfernbares Speicherlaufwerk 562, zum Beispiel ein Floppy-Disk-Laufwerk, ein Magnetband-Laufwerk, ein Compact-Disc-Laufwerk ("CD"), ein DVD (digital versatile disc)-Laufwerk usw. aufweisen. Das entfernbare Speicherlaufwerk 562 liest und/oder beschreibt ein entfernbares Speichermedium 564 in einer allgemein bekannten Weise. Das entfernbare Speichermedium 564 kann zum Beispiel eine Floppy-Diskette, ein Magnetband, eine CD, eine DVD usw. sein.
Das entfernbare Speichermedium 564 ist vorzugsweise ein Computerlesbares Medium mit darauf gespeichertem Computerausführbaren Kode (d.h. Software) und/oder Daten. Die Computersoftware oder Daten, die auf dem entfernbaren Speichermedium 564 gespeichert sind, werden in das Computersystem 550 als elektrische Kommunikationssignale 578 gelesen.
In alternativen Ausführungsbeispielen kann der Sekundärspeicher 558 andere ähnliche Mittel aufweist, um es zu erlauben, dass Computerprogramme oder andere Daten oder Befehle in das Computersystem 550 geladen werden. Solche Mittel können, zum Beispiel, ein externes Speichermedium 572 und eine Schnittstelle 570 aufweisen. Beispiel eines externen Speichermediums 572 können eine externe Festplattenlaufwerk oder ein externes optisches Laufwerk oder ein externes magnetooptisches Laufwerk aufweisen.
Andere Beispiele des Sekundärspeichers 558 können Halbleiter-basierte Speicher, wie zum Beispiel programmierbare Nur-Lese-Speicher ("PROM", programmable read-only memory), löschbare programmierbare Nur-Lese-Speicher ("EPROM", erasable programmable read-only memory), elektrisch löschbare Nur-Lese-Speicher ("EEPROM", electrically erasable read-only memory), oder Flash-Speicher (Blockorientierte Speicher ähnlich EEPROM) aufweisen. Ebenfalls enthalten sind alle anderen entfernbaren Speichereinheiten 572 und Schnittstellen 570, die es erlauben, Software und Daten von der entfernbaren Speichereinheit 572 auf das Computersystem 550 zu übertragen.
Das Computersystem 550 kann auch eine Kommunikationsschnittstelle 574 aufweisen. Die Kommunikationsschnittstelle 574 erlaubt es, das Software und Daten zwischen dem Computersystem 550 und externen Vorrichtungen (z.B. Druckern), Netzwerken oder Informationsquellen übertragen werden. Zum Beispiel kann Computersoftware oder ausführbarer Kode von einem Netzwerk-Serverrechner über die Kommunikationsschnittstelle 574 auf das Computersystem 550 übertragen werden. Beispiel einer Kommunikationsschnittstelle 574 weisen ein Modem, eine Netzwerk-Schnittstellenkarte ("NIC", network interface card), einen Kommunikationsanschluss, einen PCMCIA-Slot und -Karte, eine Infrarotschnittstelle und eine IEEE-1394-Firewire auf, um nur wenige zu nennen.
Die Kommunikationsschnittstelle 574 implementiert vorzugsweise in der Industrie verbreitete Protokollstandards, wie zum Beispiel Ethernet-IEEE-802-Standards, Glasfaserkanal, digitale Fernsprechkunden-Leitung ("DSL", digital subscriber line), asynchrone digitale Fernsprechkunden-Leitung ("ADSL", asynchronous digital subscriber line), Frame Relay, asynchroner Übertragungsmodus ("ATM", asynchronous transfer mode), Netzwerk mit integrierten digitalen Diensten ("ISDN", integrated digital services network), persönliche Kommunikationsdienste ("PCS", personal communications devices), Übertragungs-Steuerungsprotokoll/Internet-Protokoll ("TCP/IP", transmission control protocol/Internet protocol), Internetprotokoll für serielle Leitung/Punkt-zu-Punkt-Protokoll ("SLIP/PPP", serial line Internet protocol/point to point protocol) und so weiter, aber kann genauso auch benutzerdefinierte oder Nicht-Standard-Schnittstellenprotokolle implementieren.
Software und Daten, die über die Kommunikationsschnittstelle 574 übertragen werden, sind allgemein in der Form von elektrischen Kommunikationssignalen 578. Diese Signale 578 sind vorzugsweise an die Kommunikationsschnittstelle 574 über einen Kommunikationskanal 576 angelegt. Der Kommunikationskanal 576 trägt die Signale 578 und kann unter Verwendung einer Vielzahl von Kommunikationsmittel einschließlich Draht oder Kabel, Glasfaserkabel, herkömmlicher Telefonleitung, Mobiltelefonverbindung, Hochfrequenz (RF, radio frequency)-Verbindung oder Infrarotverbindung, um nur wenige zu nennen, implementiert sein.
Computer-ausführbarer Kode (d.h. Computerprogramme oder Software) ist in dem Hauptspeicher 556 und/oder dem Sekundärspeicher 558 gespeichert. Computerprogramme können auch über die Kommunikationsschnittstelle 574 empfangen werden und in dem Hauptspeicher 556 und/oder dem Sekundärspeicher 558 gespeichert werden. Solche Computerprogramme ermöglichen dem Computersystem 550, wenn sie aufgeführt werden, die verschiedenen Funktionen der Erfindung wie oben beschrieben, durchzuführen.
In dieser Beschreibung wird der Begriff "Computerlesbares Medium" zum Bezeichnen aller Medien verwendet, die zum Bereitstellen Computer-ausführbaren Kodes (z.B. Software und Computerprogramme) auf dem Computersystem 500 verwendet werden. Beispiel dieser Medien weisen den Hauptspeicher 556, den Sekundärspeicher 558 (einschließlich des Festplattenlaufwerks 50, des entfernbaren Speichermediums 564 und des externen Speichermediums 572) und jede Peripheriekomponente, die kommunikativ mit der Kommunikationsschnittstelle 574 (einschließlich einem Netzwerk-Informationsserverrechner oder einer anderen Netzwerkvorrichtung) gekoppelt ist, auf. Diese computerlesbaren Medien sind Mittel zum Bereitstellen ausführbaren Kodes, Programmierbefehle und Software auf dem Computersystem 500.
In einem Ausführungsbeispiel, die unter Verwendung von Software implementiert ist, kann die Software auf einem Computerlesbaren Medium gespeichert sein und in das Computersystem 550 mittels eines entfernbaren Speicherlaufwerks 562, einer Schnittstelle 570 oder einer Kommunikationsschnittstelle 574 geladen werden. In solch einem Ausführungsbeispiel wird die Software in das Computersystem 550 in der Form von elektrischen Kommunikationssignalen 578 geladen. Die Software bewirkt vorzugsweise, wenn sie von dem Prozessor 552 ausgeführt wird, dass der Prozessor 552 die erfinderischen Merkmale und Funktionen ausführt, die oben beschrieben sind.
Verschiedene Ausführungsbeispiele können auch hauptsächlich durch Hardware-Verwendung, zum Beispiel Komponenten wie zum Beispiel Anwendungsspezifische integrierte Schaltkreise ("ASICS", application specific integrated circuits) oder Feldprogrammierbare Gatearrays ("FPGAs", fiel programmable gate arrays) implementiert sein. Implementierungen einer Hardware-Zustand-Maschine, die fähig ist, die hierin beschriebenen Funktionen durchzuführen, wird auch für Fachleute offensichtlich sein. Verschiedene Ausführungsbeispiel können auch unter Verwendung einer Kombination von sowohl Hardware als auch Software implementiert sein.
Während die bestimmten System und Verfahren, die hierin gezeigt und im Detail beschrieben sind, vollständig fähig sind, die oben beschriebenen Ziele der Erfindung zu erreichen, ist es zu verstehen, dass die Beschreibung und die hierin beschriebenen Zeichnungen ein gegenwärtig bevorzugtes Ausführungsbeispiel der Erfindung darstellen und folglich für den Gegenstand repräsentativ sind, der durch die Erfindung in breitem Umfang in Betracht gezogen ist. Es ist weiter zu verstehen, dass der Umfang der Erfindung vollständig andere Ausführungsbeispiele, die für Fachleute offensichtlich sind, umfasst, und dass der Umfang der Erfindung entsprechend durch nichts anderes als die angefügten Patentansprüche beschränkt ist.

Claims

Drahtlose Kommunikationseinrichtung (10), die aufweist: eine Bibliothek von Server-Betriebskodes (70); eine Bibliothek von Entfernt-Betriebskodes (60); einen ersten Satz von ausführbaren Befehlen (80), wobei jeder ausführbare Befehl einem Betriebskode in der Bibliothek von Entfernt-Betriebskodes (60) entspricht; eine Laufzeit-Engine (50), die zum Kompilieren eines Satzes von Server-Betriebskodes aus der Bibliothek von Server-Betriebskodes (70) und zum Senden des Satzes von kompilierten Server-Betriebskodes an einen Server-Rechner (30), der mit der drahtlosen Kommunikationseinrichtung (10) über ein drahtloses Kommunikationsnetzwerk (40) kommunikativ gekoppelt ist, eingerichtet ist, wobei die Laufzeit-Engine (50) ferner zum Empfangen eines Satzes von Entfernt-Betriebskodes und zum Ausführen eines zweiten Satzes von ausführbaren Befehlen aus dem ersten Satz von ausführbaren Befehlen (80) eingerichtet ist, wobei jeder ausführbare Befehl des zweiten Satzes einem Betriebskode in dem empfangenen Satz von Entfernt-Betriebskodes entspricht.
Drahtlose Kommunikationseinrichtung gemäß Anspruch 1, wobei der kompilierte Satz von Server-Betriebskodes ferner Nutzdaten aufweisen.
Drahtlose Kommunikationseinrichtung gemäß Anspruch 1, wobei die Laufzeit-Engine zum automatischen Kompilieren des Satzes von Server-Betriebskodes und zum Senden des kompilierten Satzes von Server-Betriebskodes zu einer vorgegebenen Zeit eingerichtet ist.
Drahtlose Kommunikationseinrichtung gemäß Anspruch 1, wobei die Laufzeit-Engine zum Kompilieren des Satzes von Server-Betriebskodes und zum Senden des kompilierten Satzes von Server-Betriebskodes in Antwort auf eine Eingabe eines Benutzers der drahtlosen Kommunikationseinrichtung eingerichtet ist.
Bidirektionales System zum Senden und Empfangen von Betriebskodes zwischen einer drahtlosen Kommunikationseinrichtung (10) und einem Server-Rechner (30), wobei die drahtlose Kommunikationseinrichtung und der Server-Rechner über ein drahtloses Kommunikationsnetzwerk (40) kommunikativ gekoppelt sind, wobei das System aufweist: eine drahtlose Kommunikationseinrichtung (10) mit einer Laufzeit-Engine (50), einer Bibliothek von Server-Betriebskodes (70), einer Bibliothek von Entfernt-Betriebskodes (60), und einem ersten Satz von ausführbaren Befehlen (80), wobei jeder ausführbare Befehl in dem ersten Satz einem Betriebskode in der Bibliothek von Entfernt-Betriebskodes (60) der drahtlosen Kommunikationseinrichtung entspricht; und einen Server-Rechner (30) mit einem Steuerungsmodul (95), einer Bibliothek von Server-Betriebskodes (70), einer Bibliothek von Entfernt-Betriebskodes (60), und einem zweiten Satz von ausführbaren Befehlen (82), wobei jeder ausführbare Befehl in dem zweiten Satz einem Betriebskode in der Bibliothek von Server-Betriebskodes (70) des Server-Rechners entspricht; wobei die Laufzeit-Engine (50) zum Kompilieren eines Satzes von Server-Betriebskodes aus der Bibliothek von Server-Betriebskodes (70) und zum Senden des kompilierten Satzes von Server-Betriebskodes an den Server-Rechner (30) eingerichtet ist, wobei der Server-Rechner (30) zum Empfangen des kompilierten Satzes von Server-Betriebskodes von der drahtlosen Kommunikationseinrichtung und zum Ausführen eines dritten Satzes von ausführbaren Befehlen aus dem zweiten Satz von ausführbaren Befehlen eingerichtet ist, wobei jeder ausführbare Befehl des dritten Satzes einem Betriebskode in dem empfangenen Satz von Server-Betriebskodes entspricht, wobei der Server-Rechner ferner zum Kompilieren eines Satzes von Entfernt-Betriebskodes aus der Bibliothek von Entfernt-Betriebskodes (60) und zum Senden des kompilierten Satzes von Entfernt-Betriebskodes an die drahtlose Kommunikationseinrichtung (10) eingerichtet ist, und wobei die Laufzeit-Engine (50) ferner zum Empfangen des kompilierten Satzes von Entfernt-Betriebskodes und zum Ausführen eines vierten Satzes von ausführbaren Befehlen aus dem ersten Satz von ausführbaren Befehlen (80) eingerichtet ist, wobei jeder ausführbare Befehl des vierten Satzes einem Betriebskode in dem empfangenen Satz von Entfernt-Betriebskodes entspricht.
System gemäß Anspruch 5, wobei der kompilierte Satz von Server-Betriebskodes ferner Nutzdaten aufweist.
System gemäß Anspruch 5, wobei die Laufzeit-Engine zum automatischen Kompilieren des Satzes von Server-Betriebskodes und zum Senden des kompilierten Satzes von Server-Betriebskodes zu einer vorgegebenen Zeit eingerichtet ist.
System gemäß Anspruch 5, wobei die Laufzeit-Engine zum Kompilieren des Satzes von Betriebskodes und zum Senden des kompilierten Satzes von Server-Betriebskodes in Antwort auf eine Eingabe eines Benutzers der drahtlosen Kommunikationseinrichtung eingerichtet ist.
Verfahren zum Senden und Empfangen von Betriebskodes zwischen einer drahtlosen Kommunikationseinrichtung (10) und einen Server-Rechner (30), wobei die drahtlose Kommunikationseinrichtung (10) und der Server-Rechner (30) über ein drahtloses Kommunikationsnetzwerk (40) kommunikativ gekoppelt sind, wobei das Verfahren auf der Ebene der drahtlosen Kommunikationseinrichtung (10) die Schritte aufweist: Kompilieren (522) eines Satzes von Server-Betriebskodes aus einer Bibliothek von Server-Betriebskodes (70); Hinzufügen (528) von Nutzdaten an den kompilierten Satz von Server-Betriebskodes, wobei die Nutzdaten dem kompilierten Satz von Server-Betriebskodes entsprechen; Senden (530) des kompilierten Satzes von Server-Betriebskodes und der Nutzdaten an den Server-Rechner zum Ausführen der entsprechenden Befehle darauf; Empfangen (500) eines Satzes von Entfernt-Betriebskodes von dem Server-Rechner; und Ausführen (510) eines Satzes von ausführbaren Befehlen, wobei jeder ausführbare Befehl aus diesem Satz einem Betriebskode in dem entfernten Satz von Entfernt-Betriebskodes entspricht.
Verfahren gemäß Anspruch 9, wobei der Anbring-Schritt (528) ferner die Schritte aufweist: Bestimmen, ob ein entsprechender Datenwert für jeden Betriebskode benötigt wird, der in dem kompilierten Satz von Betriebskodes enthalten ist; Abrufen (526) des benötigten entsprechenden Datenwerts für jeden Betriebskode; und Kompilieren des für jeden Betriebskode abgerufenen entsprechenden Datenwerts in Nutzdaten.
Verfahren gemäß Anspruch 9, wobei der Kompilierungsschritt ferner die Schritt aufweist: Abrufen eines Betriebskodes von der Bibliothek von Server-Betriebskodes; und Speichern des Betriebskodes in einem temporären Speicherort, der den Satz von Server-Betriebskodes aufnimmt.
Verfahren gemäß Anspruch 9, wobei die Nutzdaten Diagnose-Informationen aufweisen.
Computerlesbares Medium, das darauf gespeichert eine oder eine Mehrzahl von Befehlssequenzen aufweist, um zu Bewirken, dass einer oder eine Mehrzahl von Mikroprozessoren die Schritte zum Senden von Betriebskodes an einen Server-Rechner (30) ausführt, der kommunikativ mit einer drahtlosen Kommunikationseinrichtung (10) über ein drahtloses Kommunikationsnetzwerk (40) gekoppelt ist, wobei die Schritte aufweisen: Kompilieren (522) eines Satzes von Server-Betriebskodes aus einer Bibliothek von Server-Betriebskodes (70); Hinzufügen (528) von Nutzdaten an den kompilierten Satz von Server-Betriebskodes, wobei die Nutzdaten dem kompilierten Satz von Server-Betriebskodes entsprechen; und Senden (530) des kompilierten Satzes von Server-Betriebskodes und der Nutzdaten an einen Server-Rechner zum Ausführen der jeweiligen Befehle darauf, und wobei das computerlesbare Medium ferner darauf gespeichert eine oder eine Mehrzahl von Befehlssequenzen aufweist, um zu Bewirken, dass einer oder eine Mehrzahl von Mikroprozessoren die Schritte ausführt: Empfangen (500) eines Satzes von Entfernt-Betriebskodes von dem Server-Rechner (30); Erreichen (508) eines Satzes von ausführbaren Befehlen, wobei jeder ausführbare Befehl dieses Satzes einem Betriebskode des empfangenen Satzes von Entfernt-Betriebskodes entspricht; Ausführen (510) des Satzes von ausführbaren Befehlen.
Computerlesbares Medium gemäß Anspruch 13, ferner aufweisend eine oder eine Mehrzahl von Befehlssequenzen zum Durchführen der Schritte: Bestimmen (524), ob ein entsprechender Datenwert für jeden Betriebskode, der in dem kompilierten Satz von Betriebskodes enthalten ist, benötigt wird; Abrufen (526) des benötigten entsprechenden Datenwerts für jeden Betriebskode; und Kompilieren des entsprechenden Datenwerts, der für jeden Betriebskode abgerufen wird, in Nutzdaten.
Computerlesbares Medium gemäß Anspruch 13, ferner aufweisend eine oder eine Mehrzahl von Befehlssequenzen zum Durchführen der Schritte: Abrufen eines Betriebskodes von der Bibliothek von Server-Betriebskodes; und Speichern des Betriebskodes in einem temporären Speicherort, der den Satz von Server-Betriebskodes aufnimmt.
Computerlesbares Medium gemäß Anspruch 13, wobei die Nutzdaten Diagnose-Informationen aufweisen.