Zur Implementation des auf Simulationsebene fertiggestellten Entwurfs auf die Ziel-HW kann der Entwurfsinhalt händisch in eine geeignete Programmiersprache (z.B. C/C++ für Rechner oder VHDL für Gate Arrays) übersetzt werden, seit Längerem stehen als Bestandteil der Entwicklungswerkzeuge dafür aber auch leistungsfähige automatische Codegeneratoren zur Verfügung.

An dieser Stelle sollte bereits geprüft werden, ob der Rechenzeitbedarf des Entwurfs für die geplanten Abtastzeiten nicht zu hoch ist, ein Problem, dass u.U. unerwartet viel Entwicklungszeit in Anspruch nehmen kann.

Mit der Erzeugung des Programmcodes aus dem Entwurf ist die MSR-Lösung allerdings noch nicht fertig:
Zum Einen muss außer dem Lösungsalgorithmus selbst das Abtastsystem realisiert werden, dass die implementierten Routinen zu den gewünschten Zeitpunkten aufruft (Scheduler).
Zum Anderen stellt die entwickelte MSR-Lösung von ihrer spezifischen Funktion abgesehen sowohl ein Interface zur Strecke als auch ein Interface zu externen informationsverarbeitenden Prozessen (Hostprozessen) dar.

Abtastsystem/ Scheduler
Bei Verwendung von Echtzeitbetriebssystemen ist der Scheduler meistens als Bestandteil der Betriebssystemfunktionen schon vorhanden.
Der zyklische bzw. ereignisgesteuerte Aufruf der Anwendungsalgorithmen kann ggf. auch mit Unterstützung der meist leistungsfähigen, hardwareseitig realisierten Interruptsysteme der Mikrokontroller erfolgen.

Interface zur Strecke
Das Interface zur Strecke besteht einerseits in der Messfunktion, also beispielsweise das Lesen von Analog-Signalwerten zum richtigen Zeitpunkt oder der Erfassung von Zeitpunkten (capture) bestimmter streckenrelevanter Ereignisse.
Andererseits sind die Halteglieder zu realisieren, wobei die Stellsignale ggf. in modulierter Form ausgegeben werden müssen (z.B. Pulsweitenmodulation).
Auch hier bieten moderne Mikrokontroller leistungsfähige Hardwareperipherie an, so dass die Infrastruktur-Funktionen die Algorithmen verarbeitende CPU nur minimal belasteten.

Kommunikationsgateway
Für die Kommunikation in Netzwerken bieten die Hardwarehersteller auf Treiber- teilweise auch auf Protokollebene vorgefertigte Lösungen (z.B. CAN/Flexray) bzw. Werkzeuge zur automatischen Generierung entsprechenden Programmcodes an.
Darüber hinaus wird die Protokollebene häufig über Betriebssystemfunktionen bzw. Standardsoftware realisiert.

In den Fällen, bei denen proprietäre Lösungen benötigt werden, die durch entsprechende Hardware-Lösungen, Treiber oder Systemfunktionen nicht vorliegen, sind die Infrastrukturfunktionen wie die Anwendungsfunktionen händisch zu implementieren.

Eine allgemeine Forderung an die Software ist die Flexibilität gegenüber den Anforderungen und den Streckeneigenschaften angesichts wachsender Komplexität der zu implementierenden Anwendungen. Um Minimum an Anpassungsänderungen zu erreichen müssen die Anwendungsimplementation parametrierbar sein und variabel verwendbare Interfaces aufweisen. Gleichzeitig soll die Anwendungssoftware generisch, also unabhängig von konkreten Strecken- und Netzwerkumgebungen entwickelt werden, um in entsprechender Breite einsetzbar zu sein und in der Komplexität entsprechend großen Teams arbeitsteilig entwickelt werden können.

Das hat dazu geführt, dass die Interfacefunktionen zwischen den generischen, parametrierbaren Anwendungsfunktionen und Strecke bzw. Kommunikationsgateway als abstrakte, konfigurierbare Ebenen implementiert werden, sog. Interaction- oder Adaption Layer, in denen die entworfenen Algorithmen bereits 'virtuell' bzw. abstrakt als Platzhalter enthalten sind. Es entsteht ein Framework, das den Anwendungsvarianten entsprechend konfiguriert wird und in das die benötigten generisch entwickelten Entwürfe einfach und fehlerrobust eingehängt werden (z.B. AUTOSAR).

Als Extremfall bzgl. Flexibiltät sollte erwähnt werden, dass ggf. auch, unter Beachtung der entsprechenden Randbedingungen - komplette Anwendungs-Implementierungen während des Betriebs in ein solches Framework eingehängt und so z.B. ausgetauscht werden können. Dazu wird der Anwendungs-Code von einem Framework-Service über das Netzwerk in den flüchtigen Speicher geladen und von dort aus ausgeführt.