Echtzeit-Computing - Real-time computing

Real-Time-Computing ( RTC ) ist der Informatikbegriff für Hard- und Softwaresysteme , die einer „Echtzeitbeschränkung“ unterliegen, beispielsweise vom Ereignis bis zur Systemantwort . Echtzeitprogramme müssen eine Antwort innerhalb festgelegter Zeitbeschränkungen garantieren, die oft als "Fristen" bezeichnet werden.

Echtzeitantworten werden oft in der Größenordnung von Millisekunden und manchmal Mikrosekunden verstanden. Ein System, das nicht als Echtzeitbetrieb spezifiziert ist, kann normalerweise keine Antwort innerhalb eines Zeitrahmens garantieren , obwohl typische oder erwartete Antwortzeiten angegeben werden können. Die Echtzeitverarbeitung schlägt fehl, wenn sie nicht innerhalb einer bestimmten Frist in Bezug auf ein Ereignis abgeschlossen wird; Fristen müssen immer eingehalten werden, unabhängig von der Systemauslastung .

Ein Echtzeitsystem wurde als eines beschrieben, das "eine Umgebung steuert, indem es Daten empfängt, sie verarbeitet und die Ergebnisse ausreichend schnell zurückgibt, um die Umgebung zu diesem Zeitpunkt zu beeinflussen". Der Begriff "Echtzeit" wird in der Simulation auch verwendet , um zu bedeuten, dass die Uhr der Simulation mit der gleichen Geschwindigkeit wie eine echte Uhr läuft, und in Prozesssteuerungs- und Unternehmenssystemen bedeutet "ohne signifikante Verzögerung".

Echtzeit-Software kann eine oder mehrere der folgenden verwenden: synchrone Programmiersprachen , Echtzeit-Betriebssysteme und Echtzeit-Netzwerke, von denen jedes wesentliche Rahmenwerke zum Aufbauen einer Echtzeit-Softwareanwendung bereitstellt.

Systeme, die für viele geschäftskritische Anwendungen verwendet werden, müssen in Echtzeit funktionieren, wie zum Beispiel für die Steuerung von Fly-by-Wire- Flugzeugen oder Antiblockierbremsen , die beide eine sofortige und genaue mechanische Reaktion erfordern .

Geschichte

Der Begriff Echtzeit leitet sich von seiner Verwendung in der frühen Simulation ab , bei der ein realer Prozess mit einer Rate simuliert wird, die der des realen Prozesses entspricht (jetzt Echtzeitsimulation genannt , um Mehrdeutigkeiten zu vermeiden). Analoge Computer waren in den meisten Fällen in der Lage, viel schneller zu simulieren als in Echtzeit, eine Situation, die genauso gefährlich sein könnte wie eine langsame Simulation, wenn sie nicht auch erkannt und berücksichtigt würde.

Minicomputer, insbesondere in den 1970er Jahren, als sie in dedizierte eingebettete Systeme wie DOG - Scanner ( Digital On-Screen Graphics ) eingebaut wurden , erhöhten den Bedarf an prioritätsgesteuerten Reaktionen mit niedriger Latenz auf wichtige Interaktionen mit eingehenden Daten und damit für Betriebssysteme wie Data Allgemein 's RDOS (Real-Time Disk Operating System) und RTOS mit Hintergrund- und Vordergrundplanung sowie Digital Equipment Corporation ' s RT-11 stammt aus dieser Zeit. Hintergrund-Vordergrund-Scheduling ermöglichte Tasks mit niedriger Priorität CPU-Zeit, wenn keine Vordergrund-Task ausgeführt werden musste, und gab Threads/Tasks mit der höchsten Priorität absolute Priorität im Vordergrund. Echtzeitbetriebssysteme würden auch für Timesharing- Mehrbenutzeraufgaben verwendet werden. Zum Beispiel könnte Data General Business Basic im Vorder- oder Hintergrund von RDOS laufen und zusätzliche Elemente in den Planungsalgorithmus einführen, um ihn für Personen, die über dumme Terminals interagieren, besser geeignet zu machen .

Einst, als die MOS-Technologie 6502 (verwendet im Commodore 64 und Apple II ) und später, als das Motorola 68000 (verwendet im Macintosh , Atari ST und Commodore Amiga ) populär war, konnte jeder seinen Heimcomputer als Echtzeit-Computer verwenden System. Die Möglichkeit, andere Interrupts zu deaktivieren, ermöglichte hartcodierte Schleifen mit definiertem Timing, und die geringe Interrupt-Latenz ermöglichte die Implementierung eines Echtzeit-Betriebssystems, das der Benutzeroberfläche und den Plattenlaufwerken eine niedrigere Priorität als dem Echtzeit-Thread einräumte. Im Vergleich zu diesen erzeugt der programmierbare Interrupt-Controller der Intel-CPUs (8086..80586) eine sehr große Latenz und das Windows-Betriebssystem ist weder ein Echtzeit-Betriebssystem noch erlaubt es einem Programm, die CPU vollständig zu übernehmen und deren eigenen Scheduler , ohne native Maschinensprache zu verwenden und damit allen unterbrechenden Windows-Code zu übertreffen. Es existieren jedoch mehrere Codierungsbibliotheken, die Echtzeitfähigkeiten in einer Hochsprache auf einer Vielzahl von Betriebssystemen bieten, beispielsweise Java Real Time . Auch das Motorola 68000 und die nachfolgenden Familienmitglieder (68010, 68020 etc.) wurden bei Herstellern industrieller Steuerungssysteme beliebt. In diesem Anwendungsbereich bietet die Echtzeitsteuerung echte Vorteile in Bezug auf Prozessleistung und Sicherheit.

Kriterien für Echtzeit-Computing

Ein System wird als Echtzeitsystem bezeichnet, wenn die Gesamtkorrektheit einer Operation nicht nur von ihrer logischen Korrektheit abhängt, sondern auch von der Zeit, in der sie ausgeführt wird. Echtzeitsysteme sowie deren Fristen werden nach den Folgen einer Fristversäumung klassifiziert:

  • Schwer  – das Verpassen einer Frist ist ein totaler Systemausfall.
  • Fest  – seltene Terminüberschreitungen sind tolerierbar, können jedoch die Servicequalität des Systems verschlechtern. Die Nützlichkeit eines Ergebnisses ist nach Ablauf der Frist null.
  • Soft  – Die Nützlichkeit eines Ergebnisses lässt nach Ablauf der Frist nach, wodurch die Servicequalität des Systems beeinträchtigt wird.

Somit besteht das Ziel eines harten Echtzeitsystems darin, sicherzustellen, dass alle Fristen eingehalten werden, aber bei weichen Echtzeitsystemen besteht das Ziel darin, eine bestimmte Teilmenge von Fristen einzuhalten, um einige anwendungsspezifische Kriterien zu optimieren. Die speziellen optimierten Kriterien hängen von der Anwendung ab, aber einige typische Beispiele umfassen die Maximierung der Anzahl der eingehaltenen Fristen, die Minimierung der Verspätung von Aufgaben und die Maximierung der Anzahl der Aufgaben mit hoher Priorität, die ihre Fristen einhalten.

Harte Echtzeitsysteme werden eingesetzt, wenn auf ein Ereignis innerhalb einer engen Frist reagiert werden muss. Solche starken Garantien werden von Systemen verlangt, bei denen eine Nichtreaktion in einem bestimmten Zeitraum in irgendeiner Weise große Verluste verursachen würde, insbesondere die Umgebung physisch schädigen oder Menschenleben bedrohen würde (obwohl die strikte Definition einfach ist, dass das Versäumen der Frist einen Ausfall des Systems darstellt.) ). Einige Beispiele für harte Echtzeitsysteme:

  • Ein Auto - Motor - Steuersystem ist ein hartes Echtzeitsystem , weil ein verzögertes Signal Motorschäden oder Schäden verursachen kann.
  • Medizinische Systeme wie Herzschrittmacher . Auch wenn die Aufgabe eines Herzschrittmachers einfach ist, müssen medizinische Systeme aufgrund des potenziellen Risikos für Menschenleben in der Regel gründlich getestet und zertifiziert werden, was wiederum hartes Echtzeit-Computing erfordert, um nachweisbare Garantien für einen Ausfall zu bieten unwahrscheinlich oder unmöglich.
  • Industrielle Prozesssteuerungen, z. B. eine Maschine am Fließband . Wenn sich die Maschine verspätet, könnte der Artikel auf der Montagelinie die Reichweite der Maschine überschreiten (das Produkt bleibt unberührt) oder die Maschine oder das Produkt könnten durch die Aktivierung des Roboters zum falschen Zeitpunkt beschädigt werden. Wird der Fehler erkannt, würden beide Fälle zum Stillstand des Fließbandes führen, was die Produktion verlangsamt. Wird der Fehler nicht erkannt, könnte ein fehlerhaftes Produkt die Produktion durchlaufen oder in späteren Produktionsschritten Schäden verursachen.
  • Harte Echtzeitsysteme interagieren typischerweise auf niedriger Ebene mit physischer Hardware, in eingebetteten Systemen . Frühe Videospielsysteme wie Atari 2600 und Vektorgrafiken von Cinematronics hatten aufgrund der Beschaffenheit der Grafik- und Timing-Hardware harte Echtzeitanforderungen.
  • Softmodems ersetzen ein Hardwaremodem durch Software, die auf der CPU eines Computers ausgeführt wird. Die Software muss alle paar Millisekunden laufen, um die nächsten auszugebenden Audiodaten zu generieren. Wenn diese Daten verspätet sind, verliert das empfangende Modem die Synchronisierung, was zu einer langen Unterbrechung beim Wiederherstellen der Synchronisierung oder zum vollständigen Verlust der Verbindung führt.
  • Viele Arten von Druckern haben harte Echtzeit - Anforderungen, wie beispielsweise Tintenstrahldruckern (die Tinte zu der richtigen Zeit abgeschieden werden muß , wie der Druckkopf die Seite kreuzt), Laserdrucker (der Laser muss über die zum richtigen Zeitpunkt , wenn der Strahl Scans aktiviert werden rotierende Trommel) und Punktmatrix- und verschiedene Arten von Zeilendruckern (der Schlagmechanismus muss zum richtigen Zeitpunkt aktiviert werden, wenn sich der Druckmechanismus auf die gewünschte Ausgabe ausrichtet). Ein Fehler in einem dieser Punkte würde entweder eine fehlende Ausgabe oder eine falsch ausgerichtete Ausgabe verursachen.

Im Kontext von Multitasking- Systemen ist die Scheduling-Policy normalerweise prioritätsgesteuert ( präemptive Scheduler). Diese können in manchen Situationen eine harte Echtzeitleistung garantieren (zB wenn die Aufgabenmenge und deren Prioritäten im Voraus bekannt sind). Es gibt andere harte Echtzeit-Scheduler wie Ratenmonoton, die in Universalsystemen nicht üblich sind, da sie zusätzliche Informationen benötigen, um eine Aufgabe zu planen: nämlich eine gebundene oder Worst-Case-Schätzung, wie lange die Aufgabe ausgeführt werden muss . Es existieren spezifische Algorithmen zum Planen solcher harter Echtzeitaufgaben, wie zum Beispiel früheste Frist zuerst , die, wenn man den Overhead der Kontextumschaltung ignoriert , für Systemlasten von weniger als 100 % ausreicht. Neue Overlay-Scheduling-Systeme, wie beispielsweise ein adaptiver Partitions-Scheduler, unterstützen die Verwaltung großer Systeme mit einer Mischung aus harten Echtzeit- und Nicht-Echtzeit-Anwendungen.

Feste Echtzeitsysteme sind unklarer definiert und einige Klassifikationen enthalten sie nicht, wobei nur harte und weiche Echtzeitsysteme unterschieden werden. Einige Beispiele für feste Echtzeitsysteme:

  • Die zuvor als harte Echtzeit beschriebene Fließbandmaschine könnte stattdessen als feste Echtzeit betrachtet werden. Ein verpasster Termin verursacht immer noch einen Fehler, der behoben werden muss: Möglicherweise gibt es Maschinen, die ein Teil als fehlerhaft markieren oder aus der Montagelinie auswerfen, oder die Montagelinie könnte angehalten werden, damit ein Bediener das Problem beheben kann. Solange diese Fehler jedoch selten sind, können sie toleriert werden.

Weiche Echtzeitsysteme werden normalerweise verwendet, um Probleme des gleichzeitigen Zugriffs und die Notwendigkeit zu lösen, eine Reihe von verbundenen Systemen in wechselnden Situationen auf dem neuesten Stand zu halten. Einige Beispiele für weiche Echtzeitsysteme:

  • Software, und aktualisiert die Flugpläne für kommerzielle hält Flugzeuge . Die Flugpläne müssen einigermaßen aktuell gehalten werden, können aber mit einer Latenz von wenigen Sekunden betrieben werden.
  • Live-Audio-Video-Systeme sind in der Regel auch in Soft-Echtzeit. Ein verspätet abgespielter Audioframe kann einen kurzen Audiofehler verursachen (und dazu führen, dass alle nachfolgenden Audiodaten entsprechend verzögert werden, wodurch der Eindruck entsteht, dass das Audio langsamer als normal abgespielt wird), aber dies kann besser sein als die Alternativen, die Audiowiedergabe fortzusetzen Stille, statisch, einen vorherigen Audio-Frame oder geschätzte Daten wiedergeben. Ein verzögerter Videoframe verursacht in der Regel noch weniger Störungen für die Zuschauer. Das System kann unter Verwendung von Workload-Vorhersage- und Rekonfigurationsmethoden weiterhin betrieben und auch in Zukunft wiederhergestellt werden.
  • Ebenso sind Videospiele oft weiche Echtzeit, insbesondere wenn sie versuchen, eine Zielbildrate zu erreichen . Da das nächste Bild nicht im Voraus berechnet werden kann, da es von Eingaben vom Player abhängt, steht nur eine kurze Zeit zur Verfügung, um die gesamte Berechnung durchzuführen, die zum Erzeugen eines Videorahmens erforderlich ist, bevor dieser Rahmen angezeigt werden muss. Wird die Frist versäumt, kann das Spiel mit einer niedrigeren Bildrate fortgesetzt werden; Je nach Spiel kann dies nur die Grafik beeinträchtigen (während das Gameplay mit normaler Geschwindigkeit fortgesetzt wird) oder das Gameplay selbst kann verlangsamt werden (was bei älteren Konsolen der dritten und vierten Generation üblich war ).

Echtzeit in der digitalen Signalverarbeitung

In einem digitalen Echtzeit- Signalverarbeitungsprozess (DSP) können die analysierten (Eingabe) und generierten (Ausgabe) Abtastwerte kontinuierlich in der Zeit verarbeitet (oder erzeugt) werden, die benötigt wird, um denselben Satz von Abtastwerten unabhängig von der Verarbeitung ein- und auszugeben verzögern. Dies bedeutet, dass die Verarbeitungsverzögerung auch dann begrenzt werden muss, wenn die Verarbeitung auf unbegrenzte Zeit fortgesetzt wird. Das bedeutet, dass die durchschnittliche Verarbeitungszeit pro Abtastung einschließlich des Overheads nicht größer ist als die Abtastperiode, die der Kehrwert der Abtastrate ist . Dies ist das Kriterium, ob die Samples in großen Segmenten zusammengefasst und blockweise verarbeitet werden oder einzeln verarbeitet werden und ob lange, kurze oder nicht vorhandene Ein- und Ausgabepuffer vorhanden sind .

Betrachten Sie ein Audio-DSP- Beispiel; Wenn ein Prozess 2,01 Sekunden benötigt, um 2,00 Sekunden Sound zu analysieren , zu synthetisieren oder zu verarbeiten, handelt es sich nicht um Echtzeit. Wenn es jedoch 1,99 Sekunden dauert, ist es ein Echtzeit-DSP-Prozess oder kann in einen Echtzeit-DSP-Prozess umgewandelt werden.

Eine gängige Lebensanalogie ist, in einem Lebensmittelgeschäft in einer Schlange oder Schlange zu stehen und auf die Kasse zu warten. Wenn die Warteschlange asymptotisch ohne Grenzen immer länger wird, erfolgt der Checkout-Prozess nicht in Echtzeit. Wenn die Länge der Leitung begrenzt ist, werden die Kunden im Durchschnitt so schnell "verarbeitet" und ausgegeben, wie sie eingegeben werden, dann ist dieser Prozess in Echtzeit. Der Lebensmittelhändler könnte sein Geschäft aufgeben oder zumindest sein Geschäft verlieren, wenn er seinen Checkout-Prozess nicht in Echtzeit durchführen kann; Daher ist es von grundlegender Bedeutung, dass dieser Prozess in Echtzeit abläuft.

Ein Signalverarbeitungsalgorithmus, der mit dem Fluss der Eingabedaten nicht Schritt halten kann, wobei die Ausgabe immer weiter hinter die Eingabe zurückfällt, ist nicht in Echtzeit. Wenn jedoch die Verzögerung der Ausgabe (relativ zur Eingabe) in Bezug auf einen Prozess begrenzt ist, der über eine unbegrenzte Zeit abläuft, dann ist dieser Signalverarbeitungsalgorithmus in Echtzeit, selbst wenn die Durchsatzverzögerung sehr lang sein kann.

Live vs. Echtzeit

Echtzeit-Signalverarbeitung ist für die Live-Signalverarbeitung, wie sie beispielsweise bei der Live-Event-Unterstützung erforderlich ist, notwendig, aber nicht ausreichend . Die digitale Live-Audiosignalverarbeitung erfordert sowohl einen Echtzeitbetrieb als auch eine ausreichende Begrenzung der Durchsatzverzögerung, um für Darsteller, die Bühnenmonitore oder In-Ear-Monitore verwenden , tolerierbar zu sein und nicht als Lippensynchronisationsfehler durch das Publikum wahrnehmbar zu sein, das auch die Darsteller direkt beobachtet. Tolerierbare Grenzen der Latenz für Live-Echtzeitverarbeitung sind Gegenstand von Untersuchungen und Diskussionen, werden jedoch auf zwischen 6 und 20 Millisekunden geschätzt.

Bidirektionale Telekommunikationsverzögerungen in Echtzeit von weniger als 300 ms ("Roundtrip" oder das Doppelte der unidirektionalen Verzögerung) werden als "annehmbar" angesehen, um ein unerwünschtes "Übersprechen" im Gespräch zu vermeiden.

Echtzeit und leistungsstark

Echtzeit-Computing wird manchmal als Hochleistungs-Computing missverstanden , aber dies ist keine genaue Klassifizierung. Zum Beispiel kann ein riesiger Supercomputer , der eine wissenschaftliche Simulation ausführt, eine beeindruckende Leistung bieten, führt jedoch keine Echtzeitberechnungen durch. Umgekehrt sind nach der termingerechten Auslegung der Hard- und Software eines Antiblockiersystems keine weiteren Leistungssteigerungen zwingend oder gar sinnvoll. Wenn ein Netzwerkserver außerdem stark mit Netzwerkverkehr ausgelastet ist, kann seine Antwortzeit langsamer sein, ist aber (in den meisten Fällen) immer noch erfolgreich, bevor das Zeitlimit überschritten wird (das Zeitlimit erreicht). Daher würde ein solcher Netzwerkserver nicht als Echtzeitsystem betrachtet: Zeitliche Ausfälle (Verzögerungen, Zeitüberschreitungen usw.) sind typischerweise klein und unterteilt (in der Wirkung begrenzt), aber keine katastrophalen Ausfälle . In einem Echtzeitsystem wie dem FTSE 100 Index würde eine Verlangsamung über die Grenzen hinaus im Anwendungskontext oft als katastrophal angesehen. Die wichtigste Anforderung an ein Echtzeitsystem ist eine konsistente Ausgabe, nicht ein hoher Durchsatz.

Einige Arten von Software, wie viele Schachprogramme , können in beide Kategorien fallen. Zum Beispiel muss ein Schachprogramm, das für ein Turnier mit Uhr entwickelt wurde, vor einer bestimmten Frist einen Zug entscheiden oder das Spiel verlieren, und ist daher eine Echtzeitberechnung, aber ein Schachprogramm, das auf unbestimmte Zeit laufen darf vor dem Umzug ist es nicht. In beiden Fällen ist jedoch eine hohe Leistung erwünscht: Je mehr Arbeit ein Turnierschachprogramm in der vorgegebenen Zeit leisten kann, desto besser werden seine Züge, und je schneller ein uneingeschränktes Schachprogramm abläuft, desto eher kann es Bewegung. Dieses Beispiel veranschaulicht auch den wesentlichen Unterschied zwischen Echtzeitberechnungen und anderen Berechnungen: Wenn das Turnierschachprogramm nicht innerhalb der ihm zugeteilten Zeit eine Entscheidung über seinen nächsten Zug trifft, verliert es die Partie – dh es scheitert als Echtzeitberechnung – während im anderen Szenario davon ausgegangen wird, dass die Frist nicht eingehalten wird. Hohe Leistung gibt an, wie viel Verarbeitung in einer bestimmten Zeit ausgeführt wird, während Echtzeit die Fähigkeit ist, die Verarbeitung zu erledigen, um in der verfügbaren Zeit eine nützliche Ausgabe zu erzielen.

Fast in Echtzeit

Der Begriff "Near Real-Time" oder "Nearly Real-Time" (NRT) bezieht sich in der Telekommunikation und Informatik auf die Zeitverzögerung , die durch automatisierte Datenverarbeitung oder Netzwerkübertragung zwischen dem Eintreten eines Ereignisses und der Nutzung der verarbeitete Daten, etwa für Anzeige- oder Feedback- und Kontrollzwecke. Beispielsweise stellt eine nahezu in Echtzeit angezeigte Anzeige ein Ereignis oder eine Situation so dar, wie sie zum aktuellen Zeitpunkt abzüglich der Verarbeitungszeit existierte, also fast zum Zeitpunkt des Live-Ereignisses.

Die Unterscheidung zwischen den Begriffen "Near Real Time" und "Real Time" ist etwas nebulös und muss für die jeweilige Situation definiert werden. Der Begriff impliziert, dass es keine nennenswerten Verzögerungen gibt. In vielen Fällen würde eine als "Echtzeit" beschriebene Verarbeitung genauer als "nahezu Echtzeit" bezeichnet werden.

Nahezu Echtzeit bezieht sich auch auf die verzögerte Echtzeitübertragung von Sprache und Video. Es ermöglicht die Wiedergabe von Videobildern ungefähr in Echtzeit, ohne auf das Herunterladen einer ganzen großen Videodatei warten zu müssen. Inkompatible Datenbanken können in gemeinsame Flatfiles exportieren/importieren, die die andere Datenbank auf geplanter Basis importieren/exportieren kann, sodass sie gemeinsame Daten "nahezu in Echtzeit" miteinander synchronisieren/freigeben können.

Die Unterscheidung zwischen "Near Real-Time" und "Real-Time" ist unterschiedlich und die Verzögerung hängt von der Art und Geschwindigkeit der Übertragung ab. Die Verzögerung in nahezu Echtzeit liegt typischerweise im Bereich von 1-10 Sekunden.

Designmethoden

Es gibt mehrere Verfahren, um den Entwurf von Echtzeitsystemen zu unterstützen, ein Beispiel dafür ist MASCOT , ein altes, aber sehr erfolgreiches Verfahren, das die gleichzeitige Struktur des Systems darstellt. Andere Beispiele sind HOOD , Real-Time UML, AADL , das Ravenscar-Profil und Real-Time Java .

Siehe auch

Verweise

Weiterlesen

Externe Links