Unter einem Realzeitbetriebssystem versteht man ein Betriebsystem mit deterministischem Zeitverhalten. Typischerweise werden von außen (Sensoren, Benutzereingaben, etc.) ein oder mehrere Tasks an einem Realzeitsystem erzeugt, auf welche dieses innerhalb einer festen Zeit reagiert haben muss.
Neben die zeitkritische Komponente tritt noch eine sicherheitskritische Komponente: bei Nichteinhaltung der Frist eines so genannten essentiell kritischen Tasks kann das Überleben des Gesamtsystems nicht garantiert werden, d.h. das System kann zerstört oder schwer beschädigt werden. Man spricht von funktionskritischen Systemen (mission critical systems). Außer der Bedingung an die überlebensfähigkeit (survivability) sind Zuverlässigkeit und Fehlertoleranz weitere Anforderungen, die erfüllt werden müssen. Da funktionskritische Systeme außerdem meistens in unvorhersehbaren Umgebungen operieren, sind die Designanforderungen an ein derartiges Betriebsystem sehr komplex. Kontrollsysteme für Kernkraftwerke, Industrieroboter oder Flugzeuge sind Beispiele für derartige Systeme.
MELODY ist ein verteiltes Realzeitbetriebssystem für zeitkritische Anwendungen, in dem lokal verteilte Tasks mit unterschiedlichen Prioritäten und Fristen (deadlines) um verteilte Dateien (files) konkurrieren. Die Tasks sind jeweils an einen Knoten gebunden, d.h. es findet keine Prozessmigration statt. Dateien hingegen können von einem Knoten auf einen anderen kopiert oder verlagert werden, um ihre Verfügbarkeit (accessability) zu erhöhen. Man spricht dabei von Replikation bzw. Relokation.
Für jedes File gibt es über die Systemknoten verteilte Filekopien verschiedener "Qualität", deren Anzahl und Verteilung dynamisch von File-Assignern an jedem Knoten verwaltet werden:
In Abhängigkeit davon, wie oft hintereinander Deadlines eines Tasks nicht eingehalten worden sind, werden diese immer kritischer (degree of criticality). Wird ein Task wesentlich kritisch, d.h. die Deadline wird hart, so werden rechtzeitig vorher (mindestens private) Kopien der benötigten Files lokal zugänglich gemacht.
Um überlebensfähigkeit (survivability) sinnvoll zu ermöglichen, wird die traditionelle Service-Reihenfolge (Ressourcenscheduling vor Task-Scheduling) in MELODY umgekehrt. Dabei wird zwar die Garantie rechtzeitiger Ausführung von Tasks durch den Task-Scheduler unmöglich (in verteilten Systemen auf jeden Fall fragwürdig), jedoch wird die unnötige Blockierung von Ressourcen (zu Lasten von Tasks an anderen Knoten) minimiert. Dies erfordert eine neue Systemfunktion pro Knoten, den Run-Time Monitor (RTM).
Die besondere Betonung von schicht-durchgreifender und funktionaler Integration in MELODY ist richtungweisend für Vorstellungen in vielen laufenden und geplanten Betriebssystem-Projekten, besonders in komplexen Anwendungen wie verteilter Informationsgewinnung und -auswertung in Hypermedia-Systemen.