Jede Messung beginnt mit einem Trigger

Eine wichtige Anforderung an Messgeräte wie Oszilloskope ist die Fähigkeit, ein relevantes Ereignis innerhalb einer kontinuierlichen Reihe von unauffälligen Signalen schnell und zuverlässig erkennen und daraufhin einen Trigger auslösen zu können. Je schneller ein bestimmtes Ereignis erkannt werden kann, desto schneller lässt sich ein Problem in einem Elektronikdesign lösen, was Entwicklungs- und Fertigungstestzeiten reduziert.

Auch Anbieter von Oszilloskopen haben die Bedeutung erkannt. Viele Lieferanten bieten mehr als 100 vordefinierte Trigger, damit Anwender umgehend sehr geläufige und weniger geläufige Signalbedingungen isolieren können. Das erlaubt mehr Flexibilität. Die Wahl des richtigen Triggers kann sogar schwieriger sein, als die Signalerfassung. Denn Trigger werden in vielen Variationen hinsichtlich Typ, Geschwindigkeit, Bandbreite, Hold off, Software usw. angeboten. Bei jedem ist jedoch zwischen Flexibilität und Totzeit abzuwägen. Wer die verschiedenen Trigger und ihre jeweiligen Vor- und Nachteile kennt, kann besser den idealen Ansatz ermitteln und so die Chancen für ein erfolgreich getriggertes Ereignis steigern.

Zwei Aspekte bestimmen die Trigger-Leistung eines Oszilloskops:

1. Die Trigger-Flexibilität beschreibt, wie einfach oder schwer es ist, einen Schwellenwert oder eine Bedingung eines Triggers zu definieren, um durch Anpassung die getesteten Signalbedingungen optimal zu erfüllen. Die meisten Oszilloskope stellen eine Vielzahl von durch den Anbieter definierten Trigger-Funktionen bereit, die minimale Einstellungen erlauben, z. B. Pegel oder Breite. Sie bieten allerdings keine Möglichkeit zur individuellen Anpassung.
   
2. Die Trigger-Totzeit gibt an, wie lange das Oszilloskop zwischen einzelnen Messdatenerfassungen keine Trigger erkennen kann. Dadurch werden Trigger-Bedingungen versäumt, falls ein relevantes Ereignis in diese Totzeit fällt. Die Trigger-Totzeit ist eine Qualität, die allen Trigger-Architekturen innewohnt. Jedoch gibt es Methoden und Techniken, mit denen sie verringert werden kann. Viele Anbieter von Oszilloskopen bieten softwarebasierte Trigger an, um die Flexibilität auszuweiten. Das erfordert aber eine erhebliche Spanne an Totzeit, da eine nachträgliche Verarbeitung notwendig wird. Zudem eignen sie sich nicht unbedingt für sehr seltene und unregelmäßige Ereignisse.

Die Flankentriggerung (die Erfassung wird bei einem steigenden oder fallenden Signalübergang begonnen) ist einer der gängigsten Trigger-Modi bei Oszilloskopen. Einen Großteil der einfachen Fehlersuch- und Testfunktionen übernimmt ein Flanken-Trigger. Oft wird allerdings ein komplexeres Trigger-Szenario benötigt, um eine bestimmte Signalform oder mehrere Formen in Folge zu isolieren. Erweiterte Trigger-Optionen sind ebenfalls üblich und bieten zusätzliche Flexibilität für das Erfassen serieller Protokolle wie I²C oder SPI sowie erweiterte Ereignisse und Signaleigenschaften wie beispielsweise Glitches, Runt, Breite, Anstiegsgeschwindigkeit und Timeout.

Abb. 1: Dieses Blockdiagramm eines Oszilloskops beruht auf digitaler Signalverarbeitung. Die Erfassungsspeicher- und Signalverarbeitungseinheiten bestimmen die Aktualisierungsrate der Erfassung und die Totzeit des Oszilloskops.

Viele Trigger-Bedingungen sind in der Hardware implementiert. Anspruchsvollere Trigger-Optionen und Signalqualifizierungen werden oft in Software ausgeführt (siehe Abb. 1). Software-Trigger bieten die größte Flexibilität, steigern allerdings die erforderliche Datenübertragungs- und -verarbeitungszeit, während der die Oszilloskope keine neuen Trigger erkennen können (siehe Abb. 2). Dieser Zeitraum, in dem ein Trigger-System blind ist, wird Totzeit genannt. Er kann ohne Weiteres eine Größenordnung länger sein als die eigentliche Datenaufzeichnung. Trigger-Systeme eines Oszilloskops können also über 95 Prozent der Zeit blind sein. Dadurch wird das Erkennen seltener oder unregelmäßiger Ereignisse schwieriger, was zu längeren Testzeiten führt. Noch schwerwiegender ist, dass Anwender zu der falschen Annahme gelangen könnten, dass gar keins der erwarteten Ereignisse vorliegt, weil sie so selten sind, dass sie während der Messung nicht erkannt wurden.

Abb. 2: Hier wird das Erfassen und Analysieren von Signalverläufen mit klassischen Oszilloskopen mit Totzeiten zwischen den Momentaufnahmen (oben) und der kontinuierlichen Verarbeitung (unten) gezeigt.

Falls die verfügbare Trigger- oder Signalanalysefunktion eines Oszilloskops für eine Aufgabe nicht ausreicht, bleibt Anwendern nur noch, lange Segmente des Signalverlaufs zu erfassen und diese erfassten Rohdaten zur Nachverarbeitung auf einen PC herunterzuladen, um ein bestimmtes Ereignis zu finden. Dadurch wird das Gesamtsystemdesign allerdings komplexer und auch die Testzeiten verlängern sich aufgrund der Datenübertragungslatenz und der erforderlichen Verarbeitungszeit.

Zwar können softwarebasierte Trigger oder Smart-Trigger den Großteil der Anforderungen beim Entwurf und Test von elektrischen Schaltungen erfüllen. Oft gibt es jedoch seltene Ereignisse, die die Produktentwicklung erheblich verlangsamen können, werden sie nicht schnell isoliert und behoben. Aufgrund der Begrenzung der meisten Trigger-Funktionen von Oszilloskopen kann der Anwender nur auf das zugreifen, was seitens des Anbieters zur Verfügung gestellt wird.

Besteht die Möglichkeit, eigene Algorithmen in einem Oszilloskop zu implementieren, können Anwender das Messgerät an spezifische Aufgaben anpassen und sind nicht auf die vom Geräteanbieter definierte Funktionalität beschränkt. So können sie beispielsweise ihre eigenen anwendungsspezifischen Trigger-Bedingungen festlegen, um speziell eine Signalbedingung zu erfassen. Dadurch kann die Testzeit deutlich reduziert werden, da die Notwendigkeit einer Nachverarbeitung der Daten am PC entfällt (siehe Abb. 3).

Die wichtigste technologische Entwicklung, die sowohl Inline-Datenverarbeitung in Oszilloskopen wie auch die Flexibilität zur erneuten Programmierung der Algorithmen bereitstellt, sind FPGAs. Dabei handelt es sich im Wesentlichen um programmierbare Chips, die benutzerdefinierte Signalverarbeitung und Steueralgorithmen bei hohen Durchsatzraten mit echter Parallelität ausführen können. Die Flexibilität der FPGAs erlaubt das Modifizieren oder Hinzufügen anwenderspezifischer Trigger-Algorithmen. Durch die Verarbeitung mit hohem Durchsatz ist das Analysieren von Datensätzen in Echtzeit während der Erfassung möglich, statt während der Nachverarbeitung. Damit wird Totzeit ausgeschlossen, versäumten Triggern wird vorgebeugt und seltenere Ereignisse werden deutlich schneller erkannt.

Ein Beispiel für einen benutzerdefinierten Trigger wäre ein Trigger, der Signalformen oder -übergänge erkennt, die nicht den Standarddefinitionen von Triggern entsprechen (etwa das Signal in Abb. 3). Das digitale Signal weist eine nicht monotone Flanke auf, die etwa durch Signalreflexionen oder eine fehlerhafte Stromversorgung der getesteten Schaltung verursacht worden sein kann. Ein gewöhnlicher Flanken- oder ein Impulsbreiten-Trigger würden dieses unerwünschte Signal nicht erkennen und eine Erkennung auf den üblichen Wegen ist nahezu unmöglich. Damit dieses Ereignis genau und konsistent erfasst werden kann, muss ein neuer Trigger erstellt werden. Dazu kann ein Software-Trigger entwickelt werden; aufgrund der hohen Totzeit bei dieser Methode wird ein seltenes Ereignis jedoch nicht schnell erkannt. Eine Alternative ist der Einsatz eines anwenderprogrammierbaren FPGAs, der eine Reihe von Fenster-Triggern bereitstellt, die erfasste Messpunkte mit einer Maske abgleichen. Immer dann, wenn alle Fenster-Trigger gleichzeitig eine gültige Trigger-Bedingung erkennen, wird ein kombinierter Trigger ausgelöst und der Signalverlauf wird erfasst.

Da der FPGA das Signal kontinuierlich und in Echtzeit evaluiert, kann das Oszilloskop Einzelereignisse sowie aufeinanderfolgende Ereignisse ohne Totzeit zwischen einzelnen Erfassungen festhalten.

Abb. 3: Ein bestimmter Signalübergang wird mit einem benutzerdefinierten Trigger erfasst. Die Funktion ist im FPGA eines rekonfigurierbaren Oszilloskops implementiert.

Seit Jahren nutzen Testingenieure Softwarewerkzeuge wie LabVIEW anstelle von vordefinierter Software in herkömmlichen Stand-alone-Messgeräten, um ihre Testsysteme zu automatisieren, Messungen zu analysieren und zu präsentieren sowie Kosten zu senken. Dieser Ansatz sorgt für Flexibilität und nutzt die neuesten PC- und CPU-Technologien. Sehr häufig wünschen Anwender jedoch mehr und möchten auch die Art und Weise ändern können, in der die Messgeräte Messungen vornehmen, um den Anforderungen einer Anwendung besser zu entsprechen.

Traditionelle Messgeräte sind in der Regel herstellerdefiniert und umfassen nur definierte Funktionalität. NI hingegen bietet offenere und flexiblere Messgeräte basierend auf der FPGA-Technologie. Das Resultat ist sofort einsatzbereite Hardware, die das Beste beider Welten vereint: definierte, hochwertige Messtechnologie, neueste digitale Busintegration und anwenderseitig definierbare Logik mit ausgeprägter Parallelität, die niedrige Latenz bietet und direkt an I/O für die Inline-Verarbeitung angebunden ist.

Abbildung 4. Hier ist das Blockdiagramm des rekonfigurierbaren Oszilloskops NI PXIe-5171R zu sehen.

In der Vergangenheit stand die FPGA-Technologie nur Ingenieuren mit tiefem Verständnis des Entwurfs digitaler Hardware mithilfe von Tools wie Verilog oder VHDL zur Verfügung. Der verstärkte Einsatz anspruchsvoller Systemdesignwerkzeuge wie LabVIEW vereinfacht auch die FPGA-Programmierung, da neue Technologien grafische Blockdiagramme und sogar C-Programmcode in digitale Hardwareschaltungen konvertieren können. Alle FPGA-Hardwareprodukte von NI (einschließlich des NI PXIe-5171R) basieren auf der LabVIEW-RIO-Architektur (rekonfigurierbare I/O), die leistungsstarke Fließkommaprozessoren, rekonfigurierbare FPGAs und modulare I/O bietet. Die LabVIEW-RIO-Architektur vereinfacht die Entwicklung und verkürzt die Markteinführungszeit beim Entwickeln anspruchsvoller Steuer-, Überwachungs- und Testanwendungen. Mit LabVIEW können Benutzer die Leistungsfähigkeit des Geräts erweitern, z. B. durch benutzerdefinierte Trigger oder zusätzliche Timing- oder Steuersignale. Anwender können auch eigene Algorithmen in den FPGA softwaredesignter Messgeräte implementieren, um die Hardware für eine ganz andere Aufgabe auszurüsten. Ein Oszilloskop beispielsweise kann zu einem Echtzeit-Spektrumanalysator, einem Transientenrekorder, einem Protokollanalysator, einem RF-Empfänger und vielem mehr werden.

Dadurch lassen sich Gerätekosten reduzieren, denn es müssen weniger Messgeräte gekauft und gewartet werden. Bei Testsystemen ist dies ein wesentlicher Kostenfaktor. Dies kann sich als besonders hilfreich erweisen, wenn Test- und Geräteumfang über eine sehr lange Zeit (10 Jahren aufwärts) bereitgestellt werden müssen, wie etwa bei Testsystemen im Bereich der Luft- und Raumfahrt. Für solche Anwendungen muss oft das Verhalten alter Messgeräte nachgebildet werden, die nicht mehr verfügbar sind (das Ende der Produktlebensdauer erreicht haben).

Rekonfigurierbare Messgeräte sind für eine solche Anwendung von Nutzen, da sie umprogrammiert werden können, um das Verhalten eines alten Messgeräts nachzubilden. So werden Kosten gespart, denn für die Software des Testsystems ist ein viel geringerer Nachbesserungs- und Rezertifierungsaufwand erforderlich, damit ein Arbeiten mit diesem neuen Messgerät möglich ist.

Ein Beispiel für ein solches Messgerät ist das rekonfigurierbare Oszilloskop NI PXIe-5171R, das einen Kintex-7-FPGA von Xilinx für die Verarbeitung der erfassten Samples von acht Eingängen in Echtzeit verwendet. Abbildung 4 zeigt, wie der anwenderprogrammierbare FPGA in den Datenpfad integriert wird und wie er Zugriff auf die Steuerung und das Timing von Signalen des Messgeräts ermöglicht.

Mit konventionellen Trigger-Methoden von Oszilloskopen ist es herausfordernd, sehr seltene oder komplexe Ereignisse zu erfassen, da Flexibilität und Echtzeitanalyse fehlen. Neue Ansätze können FPGA-Technologie nutzen, um benutzerdefinierte Trigger-Funktionen zu definieren, damit auch komplexeste Trigger-Bedingungen erfüllt werden und das Signal in Echtzeit verarbeitet und analysiert wird.

In der Demo wird gezeigt, wie sich Totzeit durch Anpassung der Trigger vermeiden lässt.