-
PRIORITÄT
-
Diese Offenbarung beansprucht die Priorität aus der vorläufigen
US-Anmeldung Nr. 62/642,011 mit dem Titel „INTEGRATED DEVELOPMENT EN-VIRONMENT FOR PROTOCOL DESIGN, EVALUATION, AND DEBUGGING“, die am 13. März 2018 eingereicht wurde und die durch Verweis in ihrer Gesamtheit hier aufgenommen ist.
-
GEBIET DER ERFINDUNG
-
Diese Offenbarung bezieht sich auf Systeme und Verfahren im Zusammenhang mit Test- und Messsystemen und insbesondere auf das Verfassen, das Debugging und die Bereitstellung von Protokolldefinitionen für ein Test- und Messinstrument.
-
HINTERGRUND
-
In elektronischen Kommunikationssystemen werden Informationen typischerweise nach bestimmten Protokollen in Form von Paketen übertragen. Protokollstapel setzen sich aus verschiedenen Protokollen in einer geschichteten Konfiguration zusammen. Die erste Schicht kann zum Beispiel eine physikalische Schicht sein, die die Übertragung unstrukturierter Bitströme - also der Wellenform - umfasst. Bei der zweiten Schicht kann es sich um eine Datenverbindungsschicht handeln, die eine fehlerfreie Übertragung gewährleistet. Die dritte Schicht kann eine Netzwerkschicht zur Adressierung und Steuerung sein. Die vierte Schicht kann eine Transportschicht für den Transport der Daten sein. Die fünfte Schicht kann eine Sitzungsschicht für den Aufbau, die Verwaltung und den Abschluss von Verbindungen sein. Und schließlich kann die sechste Schicht eine Präsentationsschicht für den sinnvollen Austausch von Daten sein - einschließlich Verschlüsselung, Komprimierung und Neuformatierung von Daten. Informationen werden als analoges Signal übertragen, das auf der physikalischen Schicht Folgen von Einsen und Nullen darstellt. Die analogen Daten können dann in ein digitales Äquivalent umgewandelt und gemäß einem definierten Protokoll dekodiert werden.
-
Gegenwärtig bietet der konventionelle Protokoll-Designer nur Optionen für das Verfassen und/oder Erstellen von Protokolldefinitionsdateien und die Überprüfung der sprachlichen Korrektheit des Protokolls mit Hilfe eines Compilers. Der konventionelle Protokoll-Designer für Test- und Messinstrumente bietet jedoch keine Unterstützung beim Debuggen von Dekodierungsergebnissen und auch keine Informationen über eine Interpretation einer analogen seriellen Busquelle auf der physikalischen Ebene.
-
Ausführungsformen der Offenbarung behandeln diese und andere Mängel des Standes der Technik.
-
Figurenliste
-
Aspekte, Merkmale und Vorteile von Ausführungsformen der vorliegenden Offenbarung werden aus der folgenden Beschreibung von Ausführungsformen unter Bezugnahme auf die beigefügten Zeichnungen ersichtlich:
- 1 ist ein Blockdiagramm eines beispielhaften Protokoll-Designers nach Ausführungsformen der Offenbarung.
- 2 ist ein Beispiel für eine grafische Benutzeroberfläche (GUI) des Protokoll-Designers von 1.
- 3 zeigt ein Beispiel für einen Teil der GUI aus 2 zum Debuggen von Protokolldefinitionen mit Hilfe eines Compilers.
- 4 zeigt ein Beispiel für einen Teil der GUI aus 2 zum Debuggen von Protokolldefinitionen mit Hilfe einer Dekodierausgabe.
- 5 zeigt ein Beispiel für einen Teil der GUI aus 2 zum Debuggen von Protokolldefinitionen mit Hilfe einer Bitstrom-Ausgabe.
- 6 veranschaulicht eine visuelle Ausrichtung übereinstimmender Ereignisse und der Quelldaten.
- Die 7-9 veranschaulichen das visuelle Durchlaufen übereinstimmender Ereignisse in den Quelldaten.
- 10 ist ein Beispiel für die gleichzeitige Anzeige der Eingabedaten und der Dekodierungsergebnisse.
- 11 ist ein Blockdiagramm, das den Deployer des Protokoll-Designers zeigt, der Informationen an ein Test- und Messinstrument überträgt.
-
BESCHREIBUNG
-
Wie oben erörtert, bieten aktuelle Tools zum Verfassen von Protokolldefinitionen nur Optionen zur Erstellung von Protokolldefinitionen und zur Überprüfung der sprachlichen Korrektheit der Protokolldefinitionen. Die aktuellen Tools erlauben jedoch kein weiteres textuelles und/oder visuelles Debugging an den erstellten Protokolldefinitionen, wie z.B. die Bestätigung, dass die Protokolldefinitionen Pakete und Daten innerhalb eines Signals korrekt erfassen. Das heißt, die vorhandenen Protokolldefinitionstools helfen weder beim Debuggen von Dekodierungsergebnissen noch liefern sie Informationen über die Interpretation einer analogen seriellen Busquelle auf der physikalischen Ebene.
-
Ausführungsformen der Offenbarung bieten dagegen zusätzliche Informationen, sowohl grafisch als auch textuell, um einem Benutzer zu helfen, mögliche Probleme mit einer Protokolldefinition zu identifizieren. Beispielsweise können Ausführungsformen der Offenbarung eine Bitstrom-Ausgabe auf physikalischer Ebene, eine Decoder-Debug-Ausgabe, Timing-Informationen und eine visuelle Darstellung von zeitkorrelierten Eingabequellen- und Dekodierungsergebnissen umfassen, um es dem Benutzer zu ermöglichen, seine Protokolldefinitionen interaktiv zu debuggen. Darüber hinaus bieten Ausführungsformen der Offenbarung, wie weiter unten näher erläutert, eine vollständige Entwicklungsumgebung vom Verfassen über das Debugging bis hin zur Bereitstellung.
-
1 ist ein Blockdiagramm eines beispielhaften Protokoll-Designers 100 zur Implementierung von Ausführungsformen der hier preisgegebenen Offenbarung. Der Protokoll-Designer 100 kann z.B. eine integrierte Designumgebung sein. Der Protokoll-Designer 100 enthält einen oder mehrere Ports 102. Die Ports 102 können jede Vorrichtung zum Empfang von Daten enthalten, entweder drahtgebunden oder drahtlos. Die Ports 102 sind mit einem Prozessor 104 verbunden, der verschiedene Komponenten zur Implementierung von Ausführungsformen der Offenbarung enthält, wie weiter unten ausführlicher besprochen. Obwohl in 1 der Einfachheit halber nur ein Prozessor 104 dargestellt ist, können, wie ein Fachmann verstehen wird, statt eines einzelnen Prozessors 104 auch mehrere Prozessoren 104 unterschiedlichen Typs in Kombination verwendet werden.
-
Die Ports 102 können auch mit einem Speicher 106 verbunden sein, um über die Ports 102 empfangene Daten zu speichern. Der Speicher 106 kann auch Anweisungen zur Ausführung durch einen oder die mehreren Prozessoren 104 speichern, z.B. zur Durchführung von Verfahren, Operationen und/oder zugehörigen Schritten, die durch solche Anweisungen angezeigt werden. Zum Beispiel kann der Speicher 106 Anweisungen zum Verfassen von Protokollen und zum Debugging von Protokollen enthalten, einschließlich der visuellen Anzeige von Ergebnissen der Protokolldefinitionen anhand eines bekannten analogen Signals. Wie dem Durchschnittsfachmann klar sein wird, kann der Speicher 106 einen oder mehrere Speicher enthalten, wie z. B. ein Prozessor-Cache, ein RAM (Random Access Memory), ROM (Read Only Memory), einen Festkörperspeicher, ein oder mehrere Festplattenlaufwerke oder jeden anderen Speichertyp, ohne darauf beschränkt zu sein.
-
Die Benutzereingaben 108 sind mit dem einen oder den mehreren Prozessoren 104 gekoppelt. Die Benutzereingaben 108 können eine Tastatur, eine Maus, einen Trackball, einen Touchscreen und/oder beliebige andere Bedienelemente umfassen, die von einem Benutzer zur Interaktion mit einer grafischen Benutzeroberfläche (GUI) auf einer Anzeige 110 eingesetzt werden können. Die Anzeige 110 kann ein digitaler Bildschirm, eine Anzeige auf der Basis einer Kathodenstrahlröhre oder ein beliebiger anderer Monitor zur Anzeige von Wellenformen, Messungen und anderen Daten für einen Benutzer sein. Während die Komponenten des Protokoll-Designers 100 so dargestellt sind, dass sie in den Protokoll-Designer 100 integriert sind, wird dem Durchschnittsfachmann klar sein, dass jede dieser Komponenten außerhalb des Protokoll-Designers 100 liegen kann und mit dem Protokoll-Designer 100 auf jede herkömmliche Art und Weise (z.B. drahtgebundene und/oder drahtlose Kommunikationsmedien und/oder -mechanismen) gekoppelt werden kann. Beispielsweise kann in einigen Ausführungsformen die Anzeige 110 vom Protokoll-Designer 100 entfernt sein.
-
Mit erneutem Bezug zum Prozessor 104, kann der Prozessor 104 einen Autor 112 enthalten. Der Autor 112 kann so konfiguriert sein, dass ein Benutzer Protokolldefinitionsdateien erstellen und/oder bearbeiten kann, z.B. wie in der US-Patentveröffentlichung Nr.
2007/0030812 A1 gelehrt, die hier durch Verweis in ihrer Gesamtheit enthalten ist. Der Prozessor 104 kann auch einen Debugger 114 enthalten. Der Debugger 114 bietet, wie weiter unten ausführlicher besprochen wird, Optionen zum Debuggen der Protokolldefinitionen und zur Verfeinerung der Dekodierungsergebnisse durch mehrere Text- und Visualisierungsschemata. Der Prozessor 104 kann auch einen Deployer 116 enthalten, um die Protokolldefinitionsdateien an ein Test- und Messinstrument, wie z.B. ein Oszilloskop, einen Logikanalysator usw., zu verteilen oder auszugeben und darauf zu übertragen. Der Prozessor 104 enthält auch eine Laufzeit-Engine. In einigen Ausführungsformen ist die Laufzeit-Engine als Teil des Debuggers 114 bereitgestellt. Die Laufzeit-Engine, die auch als DDL-Laufzeit-Engine (Declarative Decode Language) bezeichnet werden kann, erzeugt die Dekodierungsergebnisse auf der Grundlage der Protokolldefinitionen und eines empfangenen Signals von den Ports 102 und/oder eines im Speicher 106 gespeicherten Signals.
-
2 zeigt ein Beispiel für die Ausgabe einer grafischen Benutzeroberfläche auf der Anzeige 112 für einen Protokoll-Designer 100. Die grafische Benutzeroberfläche 200 kann verschiedene Fenster 202 enthalten, um verschiedene Informationen anzuzeigen, z. B. eine empfangene Wellenform oder einen Protokoll-Editor. Die grafische Benutzeroberfläche 200 kann verschiedene Menüs enthalten, mit denen ein Benutzer einen Instrumententyp für die Bereitstellung, Viewer, gespeicherte Protokolle usw. auswählen kann. Diese grafische Benutzeroberfläche 200 kann, wie oben erwähnt, zum Verfassen, Debuggen und Bereitstellen von Protokolldefinitionsdateien durch den Autor 112, den Debugger 114 und den Deployer 116 verwendet werden.
-
Die grafische Benutzeroberfläche 200 enthält ein Fenster 204 zur Anzeige verschiedener Dekodierausgaben des Debuggers 114. Die graphische Benutzeroberfläche 200 enthält ferner verschiedene Menüs 206 und 208 zur Anzeige dessen, was sich im aktuellen System befindet, und welche Instrumente, Viewer und Protokolle dem System hinzugefügt werden können.
-
3 zeigt ein Beispiel für eine der Funktionen des Debuggers 114. 3 zeigt einen Teil der grafischen Benutzeroberfläche 200. Nachdem eine Protokolldefinition mit dem Autor 112 in einer domänenspezifischen Sprache geschrieben wurde, führt der Debugger 114 die Protokolldefinitionen durch einen Compiler aus. Die Compilerausgabe kann in einem Fenster 204 für einen Benutzer zur Analyse angezeigt werden. Der Compiler identifiziert Syntaxfehler in der Protokolldefinition, z.B. nicht deklarierte Bezeichner, zusammen mit ihren Positionen in der Protokolldefinitionsdatei, z.B. durch Angabe der Zeilen- und Spaltennummer des Fehlers im Quellcode der Protokolldefinition.
-
Um die schnelle Identifizierung von Quellcode-Fehlern zu erleichtern, kann der Debugger 114 den vom Compiler erzeugten Fehler im Fenster 204 markieren oder anderweitig identifizieren. Wenn der vom Compiler erzeugte Fehler von einem Benutzer ausgewählt wird, kann der Debugger 114 die entsprechende Quelldatei im Fenster 202 anzeigen, wobei der beanstandete Fehler hervorgehoben 302 wird. Zum Beispiel, wie in 3 zu sehen ist, wird ein Syntaxfehler im Fenster 204 identifiziert 300 und der Fehler in der Protokolldefinition hervorgehoben 302, so dass ein Benutzer schnell feststellen kann, wo der Fehler vorliegt, und den Fehler korrigieren kann.
-
4 veranschaulicht eine weitere Funktion des Debuggers 114. Eine Laufzeit-Engine des Debuggers 114, die von einem oder mehreren der Prozessoren 104 betrieben werden kann, kann Debug-Ausgabedaten erzeugen, die Ereignis- und Feldübereinstimmungen der Protokolldefinitionen zusammen mit Timing-Informationen der Übereinstimmungen anzeigen. Wie oben erwähnt, können bekannte Daten über den einen oder mehrere Ports 102 an den Speicher 106 geliefert werden.
-
Wie in 4 zu sehen ist, kann das Dekodierausgabefenster 204 Daten enthalten, die die Ereignis- und Feldübereinstimmungen des bekannten Signals mit der Timing-Information anzeigen. Ein Benutzer kann diese Daten dann mit den bekannten Eingabedaten vergleichen, um festzustellen, ob die Protokolldefinitionen ordnungsgemäß oder erwartungsgemäß funktionieren. Das heißt, dass die Protokolldefinitionen die Feld- und Ereignispunkte in den bekannten Eingabedaten korrekt identifizieren. Ein Benutzer kann diese Debug-Ausgaben durch Einfügen von optionalen OUTPUT-Befehlen innerhalb der Protokolldefinitionen noch erweitern.
-
Der Debugger 114 kann auch die Ausgabe sowohl einer Dekodieroperation als auch der darunter liegenden Bitstrom-Konvertierung der physikalischen Schicht ermöglichen. Die Bitstrom-Information ist die Umwandlung von rohen analogen Eingangssignalen in eine serielle Folge von digitalen Bits mittels getakteter Signale, Taktrückgewinnung und anderer Kodierungsmechanismen. 5 veranschaulicht die Bitstrom-Ausgabe im Fenster 204, die die serielle Sequenz digitaler Bits zusammen mit Timing-Informationen ausgibt, die der Benutzer mit dem bekannten Eingangssignal vergleichen kann. Auf diese Weise kann der Benutzer sicherstellen, dass die Bitstrom-Umwandlung unter Verwendung einer vom Autor erstellten Protokolldefinition die erwartete Bitfolge liefert. Ungültige Bitsequenzen können auf Timing-Fehler in den Eingangssignalen hindeuten oder auf Algorithmusfehler in den Bitstrom-Umwandlungsdefinitionen in den Protokolldefinitionen hinweisen.
-
Im Fenster 204 von 5 zeigt die Ausgabe des Bitstrom-Debuggers 114 das Timing der Quellenkonvertierung in Bits an. In einigen Ausführungsformen kann der Protokoll-Designer 100 standardmäßig eine Bibliothek von Protokolldefinitionen enthalten, um eine Vielzahl häufig verwendeter Kodierungsschemata der physikalischen Schicht zu unterstützen. Die Bibliothek mit Bestandsprotokolldefinitionen kann zum Beispiel im Speicher 106 gespeichert werden. Die Protokolldefinitionsbibliothek kann Kodierungsschemata der physikalischen Schicht unterstützen, wie z. B., aber nicht beschränkt auf, Non-Return to Zero (NRZ), Manchester, Multi-Level-Transmit 3 (mlt3) sowie benutzereigene Definitionen. Dies kann besonders nützlich für Benutzer sein, die ihre eigene Definition der physikalischen Schicht mit einer domänenspezifischen Sprache erstellt haben, anstatt eine der Bestandsdefinitionen der physischen Schicht wiederzuverwenden.
-
Protokoll-Ereignisdefinitionen können das primäre Mittel sein, um den Anfang und das Ende von Paketen zu identifizieren. Folglich sind Tools zur Identifizierung der korrekten Ereignisdefinition und Timing-Charakteristika wichtig für die Protokolldefinitionen. Daher kann der Debugger 114 eine Funktion zur Verfügung stellen, bei der die Laufzeitdekodierungsverarbeitung anhält, wenn ein Ereignis von Interesse erfasst wird, und das Ereignis und die Zeit, zu der es aufgetreten ist, kann an den Benutzer ausgegeben werden. Zum Beispiel kann ein Benutzer einen Haltepunkt auf ein Ereignis S setzen wollen, um zu sehen, wo dieses Ereignis in den Eingabedaten zuerst erfasst wird. In einigen Ausführungsformen kann der Debugger 114 nach allen Ereignissen in den Eingabedaten suchen. Anstatt zur Laufzeit anzuhalten, kann der Debugger 114 eine statische Auswertung darüber liefern, wie die Laufzeit-Engine Ereignisse im gesamten Datensatz interpretiert, indem er jedes von einem Benutzer angegebene Ereignis findet.
-
In einigen Ausführungsformen, wie in 6 dargestellt, kann der Debugger 114 das Fenster 202 verwenden, um die Eingabedaten mit übereinstimmenden Ereignissen zu annotieren. Beispielsweise wird das Ereignis-S-Paket 600 mit den Eingabedaten 602 abgeglichen und identifiziert. In dem in 6 gezeigten Beispiel können die mit „Ch. 1“ und „Ch. 2“ gekennzeichneten Wellenformen das Taktsignal bzw. das Datensignal eines seriellen Kommunikationsbusses sein. Auf diese Weise kann einem Benutzer die Möglichkeit gegeben werden, die Laufzeitauswertung von Ereignissen visuell an den bekannten Eingangsdaten auszurichten, um zu bestätigen, dass die Protokolldefinitionen wie erwartet funktionieren und kein Fehler in den Protokolldefinitionen vorliegt.
-
Der Debugger 114 kann dem Benutzer auch erlauben, schrittweise durch die Paketerfassung zu gehen und die Ergebnisse zu dekodieren, wie in 7-9 gezeigt. Der Debugger 114 kann es einem Benutzer ermöglichen, eine Eingangswellenform zu durchlaufen und festzustellen, wie die Laufzeit-Engine jede Paketsequenz interpretiert. Wie in 7 zu sehen ist, wird ein erstes Paket 700 in Fenster 202 angezeigt, das für die Eingangswellenform 702 relevant ist. Ein Cursor wird angezeigt, um die Eingangswellenform und den Anfang des dekodierten Pakets 700 auszurichten, wodurch eine zeitkorrelierte Ansicht zwischen einem dekodierten Paket und einer Eingangswellenform angezeigt wird. In 8 wurde der Cursor entlang der Eingangswellenform 702 von einem Benutzer bewegt, und das neue Paket 800 an diesem Punkt in der Eingangswellenform wird angezeigt. Ein Benutzer kann weiter durch die Eingangswellenform scrollen, und das nächste Paket 900 wird, wie in 9 gezeigt, angezeigt, wenn es in die Wellenform eingeht.
-
In einigen Ausführungsformen kann ein Benutzer eine Schaltfläche auswählen, um durch jede Paketerfassung zu gehen. Wenn die Taste zum ersten Mal gedrückt wird, werden ein Paket 700 und ein Cursor auf der Eingangswellenform beim ersten Paket 700 angezeigt. Wenn die Taste erneut gedrückt wird, wird das nächste Paket 800 angezeigt, und der Cursor bewegt sich auf der Eingangswellenform bis zur Position des nächsten Pakets 800. Dies setzt sich bis zum Ende der Eingangswellenform fort.
-
In einigen Ausführungsformen kann der Benutzer außerdem eine „Dekodieren von“-Option im Debugger 114 wählen, um einen beliebigen Zeitpunkt innerhalb der Wellenformansicht auszuwählen, und der Laufzeitdecoder oder die Laufzeit-Engine beginnt ab diesem Zeitpunkt mit der Dekodierauswertung. Dies kann zu einer schnelleren Analyse und kürzeren Debug-Zeit führen, wenn es sich um Protokollspezifikationen handelt, die mehrere Paketanfangsereignisse kodieren.
-
Der Debugger 114 kann auch eine Überlagerungsoption enthalten. Wenn diese Option von einem Benutzer ausgewählt wird, bietet der Debugger 114 die Möglichkeit, die Eingabedaten 1000 und die Dekodierungsergebnisse 1002 als überlagerte Ansichten anzuzeigen, wie in 10 dargestellt. Die überlagerten Ansichten können direkt übereinander gelegt oder so eingestellt werden, dass jede der Quellen in vertikaler Richtung leicht versetzt ist. Das heißt, die überlagerten Ansichten der Eingabedaten 1000 und der Dekodierungsergebnisse 1002 müssen nicht vollständig überlagert werden, sondern können gegeneinander versetzt sein. Wie in 10 zu sehen ist, kann dies die Fähigkeit des Benutzers verbessern, anhand der Protokolldefinitionen zu erkennen, wie Eingangssignale und ihr Timing von der Laufzeit-Engine interpretiert werden. Ein Benutzer kann diese Informationen nutzen, um dann bei Bedarf seine Protokolldefinitionen zu ändern, um ein gewünschtes Ergebnis zu erzielen.
-
Der Debugger 114 kann auch zusätzliche Funktionen enthalten, die bei der Definition und Auswertung von Dekodierungsergebnissen helfen, wie z.B. Cursors und Markierungen zum Auffinden von Stellen, die von Interesse sind, Tools zum Messen von Zeitunterschieden zwischen den Cursors, Such-/Filteroptionen zum schnellen Auffinden dekodierter Ergebnisse sowie verschiedene Anzeige-Radix-Optionen.
-
Wie oben erörtert, kann der Protokoll-Designer 100 auch einen Deployer 116 enthalten. Sobald ein Benutzer die vollständige Protokolldefinition mit dem Autor 112 und/oder dem Debugger 114 erzeugt hat, kann der Deployer 116 die Protokolldefinitionen an ein Test- und Messinstrument 1100 übertragen, wie in 11 dargestellt. Das heißt, der Protokoll-Designer 100 ermöglicht es einem Benutzer, eine vollständige Protokolllösung zu erstellen und vollständig zu debuggen, die dann innerhalb eines Test- und Messinstruments 1100 ohne Änderungen an der Kern-Firmware des Test- und Messinstruments 1100 ausgeführt werden kann. Das Test- und Messinstrument 1100 kann die gleiche Laufzeit-Engine enthalten, die auch im Protokoll-Designer 100 enthalten ist. Mit anderen Worten, Ausführungsformen der offenbarten Technologie ermöglichen es dem Test- und Messinstrument 1100, eine Dekodier- und/oder Ereignissuch-Unterstützung für ein völlig neues oder proprietäres Protokoll bereitzustellen, ohne die Kern-Codebasis des Test- und Messinstruments 1100 zu verändern. Da die Codebasis des Test- und Messinstruments 1100 in der Regel recht komplex ist, ist die Modifikation und das erforderliche Testen der Codebasis im Allgemeinen zeitaufwendig, teuer und fehleranfällig. Daher verbessern Ausführungsformen der offenbarten Technologie die Zeit bis zur Markteinführung und die Kosten für die Unterstützung neuer und/oder kundenspezifischer Protokolle erheblich.
-
Ein Test- und Messinstrument 1100 kann die gleiche Beschreibungsdefinitionssprachen-(DDL)-Laufzeit-Engine 1102 enthalten wie der Protokoll-Designer 100. Das Test- und Messinstrument 1100 kann auch eine Analysekomponente 1104 zum Analysieren aller in das Test- und Messinstrument 1100 eingehenden Signale sowie ein deklaratives Benutzeroberflächenlayout 1106 enthalten.
-
Der Deployer 116 des Protokoll-Designers 100 kann eine deklarative Benutzerschnittstellendatei 1108 erzeugen und übertragen, die ein Konfigurations- und/oder Einstellungsmenü für die Dekodieroptionen des Protokolls enthält. In einigen Ausführungsformen kann die deklarative Benutzerschnittstellendatei 1108 die Qt Modeling Language (QML) verwenden. Der Deployer 116 kann auch eine deklarative Definitionsdatei 1110 erzeugen und übertragen, die die Abfragesprache, Protokollanzeigeeigenschaften und Suchdefinitionen definiert. In einigen Ausführungsformen kann die deklarative Definitionsdatei 1110 die eXtensible Markup Language (XML) verwenden. Der Deployer 116 kann die kompilierte Protokolldefinitionsdatei 1112 oder die DDL-Definitionsdatei auch ausgeben, die von der DDL-Laufzeit-Engine 1102 ausgeführt werden soll.
-
Wie oben erwähnt, sind Ausführungsformen der Offenbarung vorteilhaft, indem sie es einem Protokoll-Designer ermöglichen, nicht nur Protokolldefinitionen zu verfassen, sondern die Protokolldefinitionen auch zu debuggen und einem Test- und Messinstrument bereitzustellen. Auf diese Weise kann ein Benutzer sicherstellen, dass sich die von ihm erstellten Protokolldefinitionen wie erwartet verhalten, um später Daten auf einem Test- und Messinstrument zu analysieren und sicherzustellen, dass die getesteten Vorrichtungen die erwartete Leistung erbringen. Bisherige Protokoll-Designer und integrierte Design-Umgebungen für Protokolldefinitionen haben es einem Benutzer lediglich erlaubt, die Protokolldefinitionen zu erzeugen, nicht aber das umfangreiche Debugging der Protokolldefinitionen durchzuführen, wie es mit Ausführungsformen der Offenbarung möglich ist.
-
Aspekte der Offenbarung können auf speziell geschaffener Hardware, Firmware, digitalen Signalprozessoren oder auf einem speziell programmierten Computer einschließlich eines nach programmierten Anweisungen arbeitenden Prozessors arbeiten. Die hier verwendeten Begriffe Controller oder Prozessor sollen Mikroprozessoren, Mikrocomputer, anwendungsspezifische integrierte Schaltungen (ASICs) und dedizierte Hardware-Controller einschließen. Ein oder mehrere Aspekte der Offenbarung können in computerverwendbaren Daten und computerausführbaren Anweisungen verkörpert sein, z.B. in einem oder mehreren Programmmodulen, die von einem oder mehreren Computern (einschließlich Überwachungsmodulen) oder anderen Geräten ausgeführt werden. Im Allgemeinen umfassen Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren, wenn sie von einem Prozessor in einem Computer oder einem anderen Gerät ausgeführt werden. Die computerausführbaren Anweisungen können auf einem computerlesbaren Speichermedium gespeichert werden, z.B. auf einer Festplatte, einer optischen Platte, einem Wechseldatenträger, einem Festkörperspeicher, einem Direktzugriffspeicher (RAM), etc. Wie einem Fachmann klar sein wird, kann die Funktionalität der Programmmodule nach Belieben unter verschiedenen Gesichtspunkten kombiniert oder verteilt werden. Darüber hinaus kann die Funktionalität ganz oder teilweise in Firmware oder Hardware-Äquivalenten wie integrierten Schaltungen, FPGA und dergleichen verkörpert sein. Bestimmte Datenstrukturen können verwendet werden, um einen oder mehrere Aspekte der Offenbarung effektiver zu implementieren, und solche Datenstrukturen werden im Rahmen der hier beschriebenen computerausführbaren Anweisungen und computerverwendbaren Daten in Betracht gezogen.
-
Die offenbarten Aspekte können in einigen Fällen in Hardware, Firmware, Software oder einer Kombination davon implementiert sein. Die offenbarten Aspekte können auch in Form von Anweisungen umgesetzt werden, die von einem oder mehreren oder computerlesbaren Speichermedien befördert werden oder darauf gespeichert sind, die von einem oder mehreren Prozessoren gelesen und ausgeführt werden können. Solche Anweisungen können als ein Computerprogrammprodukt bezeichnet werden. Computerlesbare Medien, wie sie hier besprochen werden, sind alle Medien, auf die von einem Computergerät zugegriffen werden kann. Computerlesbare Medien können zum Beispiel, aber nicht ausschließlich, Computerspeichermedien und Kommunikationsmedien umfassen.
-
Computerspeichermedien sind alle Medien, die zur Speicherung computerlesbarer Informationen verwendet werden können. Als Beispiel, und nicht als Einschränkung, können Computerspeichermedien RAM, ROM, elektrisch löschbare programmierbare Festwertspeicher (EEPROM), Flash-Speicher oder andere Speichertechnologien, Compact Disc Festwertspeicher (CD-ROM), Digital Video Disc (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetband, Magnetplattenspeicher oder andere magnetische Speichergeräte und alle anderen flüchtigen oder nicht flüchtigen, entfernbaren oder nicht entfernbaren Medien, die in irgendeiner Technologie implementiert sind, umfassen. Computerspeichermedien schließen Signale an sich und vorübergehende Formen der Signalübertragung aus.
-
Als Kommunikationsmedien werden alle Medien bezeichnet, die für die Übermittlung computerlesbarer Informationen verwendet werden können. Zu den Kommunikationsmedien können beispielsweise Koaxialkabel, Glasfaserkabel, Luft oder andere Medien gehören, die für die Übertragung von elektrischen, optischen, Hochfrequenz-(HF), Infrarot-, akustischen oder anderen Arten von Signalen geeignet sind, ohne darauf beschränkt zu sein.
-
BEISPIELE
-
Nachfolgend finden sich veranschaulichende Beispiele für die hier offenbarten Technologien. Ein Ausführungsform der Technologien kann eine oder mehrere und jede Kombination der unten beschriebenen Beispiele umfassen.
-
Beispiel 1 ist ein Protokoll-Designer für ein Test- und Messinstrument, umfassend: einen Eingang zum Empfang eines Signals; einen Speicher, der zur Speicherung des Signals konfiguriert ist; einen Autor, der so konfiguriert ist, dass er Protokolldefinitionen auf der Grundlage einer Benutzereingabe erzeugt; einen Debugger, der so konfiguriert ist, dass er textuelle und visuelle Dekodierungsergebnisse auf der Grundlage der Protokolldefinitionen und des Signals ausgibt; und einen Deployer, der so konfiguriert ist, dass er eine kompilierte Protokolldefinitionsdatei an das Test- und Messinstrument ausgibt.
-
Beispiel 2 ist der Protokoll-Designer von Beispiel 1, bei dem der Debugger weiterhin so konfiguriert ist, dass er Ereignis- und Feldübereinstimmungen mit Timing-Informationen im Signal auf der Grundlage der Protokolldefinitionen erzeugt.
-
Beispiel 3 ist der Protokoll-Designer eines der Beispiele 1 oder 2, bei dem das Signal ein analoges Signal ist und der Debugger weiterhin so konfiguriert ist, dass er einen Bitstrom erzeugt, der auf dem analogen Signal und einer oder mehreren der Protokolldefinitionen basiert.
-
Beispiel 4 ist der Protokoll-Designer eines der Beispiele 1-3, bei dem der Debugger weiterhin so konfiguriert ist, dass er die Dekodierung des Signals anhält, wenn ein Ereignis erfasst wird.
-
Beispiel 5 ist der Protokoll-Designer eines der Beispiele 1-4, bei dem der Debugger weiter konfiguriert ist, um das Eingangssignal auf der Grundlage der Protokolldefinitionen zu dekodieren und nach einem bestimmten Ereignis innerhalb des dekodierten Eingangssignals zu suchen.
-
Beispiel 6 ist der Protokoll-Designer eines der Beispiele 1-6, bei dem der Debugger Ereignispakete auf der Grundlage der Protokolldefinitionen ausgibt, und der Protokoll-Designer ferner eine Anzeige umfasst, die so konfiguriert ist, dass sie zumindest einen Teil der Ereignispakete und das Eingangssignal gleichzeitig anzeigt.
-
Beispiel 7 ist der Protokoll-Designer von Beispiel 6, bei dem die Anzeige weiter so konfiguriert ist, dass zumindest der eine Teil der Ereignispakete angezeigt wird, die dem Eingangssignal überlagert sind.
-
Beispiel 8 ist der Protokoll-Designer eines der Beispiele 1-7, bei dem der Debugger weiter konfiguriert ist, um Syntaxfehler innerhalb der Protokolldefinitionen zu identifizieren und hervorzuheben.
-
Beispiel 9 stellt ein oder mehrere computerlesbare Speichermedien mit Anweisungen dar, die, wenn sie von einem oder mehreren Prozessoren eines Protokoll-Designers ausgeführt werden, den Protokoll-Designer dazu veranlassen: ein Signal zu empfangen; das Signal zu speichern; Protokolldefinitionen auf der Grundlage einer Benutzereingabe zu erzeugen; textuelle und visuelle Dekodierungsergebnisse auf der Grundlage der Protokolldefinitionen und des Signals auszugeben; eine kompilierte Protokolldefinitionsdatei auf der Grundlage der Benutzereingabe zu erzeugen; und die kompilierte Protokolldefinitionsdatei an ein Test- und Messinstrument auszugeben.
-
Beispiel 10 stellt das eine oder die mehreren computerlesbaren Speichermedien von Beispiel 9 dar, wobei die Anweisungen den Protokoll-Designer ferner dazu veranlassen, Ereignis- und Feldübereinstimmungen mit Timing-Informationen im Signal auf der Grundlage der Protokolldefinitionen zu erzeugen.
-
Beispiel 11 stellt das eine oder die mehreren computerlesbaren Speichermedien eines der Beispiele 9 und 10 dar, bei dem/denen das Signal ein analoges Signal ist, und wobei die Anweisungen den Protokoll-Designer ferner dazu veranlassen, einen Bitstrom auf der Grundlage des analogen Signals und einer oder mehrerer der Protokolldefinitionen zu erzeugen.
-
Beispiel 12 stellt das eine oder die mehreren computerlesbaren Speichermedien eines der Beispiele 9-11 dar, wobei die Anweisungen den Protokoll-Designer ferner dazu veranlassen, die Dekodierung des Signals anzuhalten, wenn ein Ereignis erfasst wird.
-
Beispiel 13 stellt das eine oder die mehreren computerlesbaren Speichermedien eines der Beispiele 9-12 dar, wobei die Anweisungen den Protokoll-Designer ferner dazu veranlassen, das Eingangssignal auf der Grundlage der Protokolldefinitionen zu dekodieren und nach einem bestimmten Ereignis innerhalb des dekodierten Eingangssignals zu suchen.
-
Beispiel 14 stellt das eine oder die mehreren computerlesbaren Speichermedien eines der Beispiele 9-13 dar, wobei die Anweisungen den Protokoll-Designer ferner dazu veranlassen, mindestens einen Teil der Ereignispakete und das Eingangssignal gleichzeitig anzuzeigen.
-
Beispiel 15 stellt das eine oder die mehreren computerlesbaren Speichermedien von Beispiel 14 dar, wobei die Anweisungen den Protokoll-Designer ferner dazu veranlassen, den zumindest einen Teil der Ereignispakete anzuzeigen, die dem Eingangssignal überlagert sind.
-
Beispiel 16 stellt das eine oder die mehreren computerlesbaren Speichermedien eines der Beispiele 9-15 dar, wobei die Anweisungen den Protokoll-Designer ferner dazu veranlassen, Syntaxfehler innerhalb der Protokolldefinitionen zu identifizieren und hervorzuheben.
-
Beispiel 17 ist ein Verfahren zum Erzeugen, Debuggen und Bereitstellen von Protokolldefinitionen für ein Test- und Messinstrument, umfassend: Empfang eines analogen Signals; Speicherung des analogen Signals; Erzeugen von Protokolldefinitionen auf der Grundlage einer Benutzereingabe; Ausgeben von textuellen und visuellen Dekodierungsergebnissen auf der Grundlage der Protokolldefinitionen und des analogen Signals; Erzeugen einer kompilierten Protokolldefinitionsdatei auf der Grundlage der Benutzereingabe; und Bereitstellen der kompilierten Protokolldefinitionsdatei für ein Test- und Messinstrument.
-
Beispiel 18 ist das Verfahren von Beispiel 17, wobei die Ausgabe von textuellen und visuellen Dekodierungsergebnissen ferner die Erzeugung von Ereignis- und Feldübereinstimmungen mit Timing-Informationen im Signal auf der Grundlage der Protokolldefinitionen umfasst.
-
Beispiel 19 ist das Verfahren eines der Beispiele 17 oder 18, wobei die Ausgabe von textuellen und visuellen Dekodierungsergebnissen ferner die Erzeugung eines Bitstroms auf der Grundlage des analogen Signals und einer oder mehreren der Protokolldefinitionen umfasst.
-
Beispiel 20 ist das Verfahren eines der Beispiele 17-19, weiterhin umfassend das gleichzeitige Anzeigen zumindest eines Teils der Ereignispakete und des Eingangssignals.
-
Die zuvor beschriebenen Versionen des offenbarten Gegenstandes haben viele Vorteile, die entweder beschrieben wurden oder für einen Durchschnittsfachmann offensichtlich wären. Dennoch sind diese Vorteile oder Merkmale nicht in allen Versionen der offenbarten Vorrichtungen, Systeme oder Verfahren erforderlich.
-
Zusätzlich wird in dieser schriftlichen Beschreibung auf besondere Merkmale hingewiesen. Es versteht sich, dass die Offenbarung in dieser Spezifikation alle möglichen Kombinationen dieser besonderen Merkmale umfasst. Wenn ein besonderes Merkmal im Zusammenhang mit einem bestimmten Aspekt oder Beispiel offenbart ist, kann dieses Merkmal, soweit möglich, auch im Zusammenhang mit anderen Aspekten und Beispielen verwendet werden.
-
Auch wenn in dieser Anmeldung auf ein Verfahren mit zwei oder mehr definierten Schritten oder Operationen Bezug genommen wird, können die definierten Schritte oder Operationen in beliebiger Reihenfolge oder gleichzeitig ausgeführt werden, es sei denn, der Kontext schließt diese Möglichkeiten aus.
-
Obwohl zur Veranschaulichung spezifische Beispiele der Erfindung illustriert und beschrieben wurden, sollte klar sein, dass verschiedene Änderungen vorgenommen werden können, ohne vom Sinngehalt und Umfang der Erfindung abzuweichen. Dementsprechend sollte die Erfindung nicht eingeschränkt sein, außer durch die beigefügten Ansprüche.
