Plattform-Architekturen für Dinge entwickeln sich immer schneller zu einem System, das eine Virtualisierung am oberen und unteren Ende dieses Aufbaus bietet (Bild 2). Am oberen Ende sorgt das Internet dafür, dass viele ortsfeste Systeme durch Remote-Anwendungen ersetzt werden, die mit RPCs (Remote Procedure Calls) anstelle von IPCs aufgerufen werden. Dafür kommen APIs (z.B. RESTful Web Services) anstatt Betriebssystem-APIs zum Einsatz. Am unteren Ende wird die Hardware virtualisiert, damit sich Betriebssysteme einfacher austauschen lassen oder mehrere Betriebssysteme in einem System gemischt zum Einsatz kommen können – je nachdem, welches Produkt sich am besten für die Anforderungen eines jeden Subsystems eignet.
Diese Transformation der Plattform-Architektur ist unausweichlich und wird durch einen vorhergehenden digitalen Megatrend verursacht: das Cloud Computing. Ab dem Jahr 2000 fanden sich immer mehr Cloud Hypervisors (Cloudvisor) wie VMware ESX Server, Hyper-V und Xen auf dem Markt, und Intel stellte seine VT-Technologie vor, damit diese effizienter arbeiten können. Innerhalb von zehn Jahren war dann jedes große Datencenter virtualisiert. Dieser unglaublich schnelle architektonische Wandel wurde durch die massive Ressourceneffizienz getrieben. Die Virtualisierung der Rechnersysteme ermöglichte somit eine höhere Fehlertoleranz und Flexibilität. In der Welt der Dinge haben sich „Thingvisors“ wie Green Hills‘ Integrity Multivisor ebenfalls weiterentwickelt, indem ähnliche Hardware-Virtualisierungsfunktionen zur ARM-Architektur hinzugefügt wurden, wie sie heute in vielen tragbaren Geräten zu finden sind. Dazu zählt auch die neue Echtzeit-Prozessorfamilie ARMv8-R.
Dinge haben ganz andere Anforderungen als Cloud Server. Während Cloudvisors die CPU-, Speicher- und Netzwerk-Ressourcen virtualisieren, muss ein Thingvisor diese plus eine Vielzahl weiterer Hardware virtualisieren, die Funkschnittstellen, Sensoren, Multimedia-Beschleuniger etc. enthalten kann. Thingvisors müssen oft auch Anwendungen mit gemischter Kritikalität handhaben, z.B. im Automotive-Bereich. Ein einzelnes System betreibt dann ein High-Level-Betriebssystem wie Android (z.B. für Infotainment) zusammen mit einer sicherheitskritischen Echtzeit-Anwendung (z.B. für Rückfahrkamera oder Fahrzeug-Cockpit).
Mit einem Thingvisor können einfache Anwendungen direkt auf ihm selbst ausgeführt werden (Bild 3). Dies vermeidet den Overhead, durch zwei Ebenen mit Interrupt-Handling, Scheduling und Kommunikation gehen zu müssen, die sonst beim Hosting von Anwendungen auf einem Gast-Betriebssystem erforderlich wären. Im Automotive-Bereich kann eine einfache Thingvisor-Anwendung die Fast-Boot- und Echtzeit-Anforderungen der Netzwerkkommunikation (z.B. CAN-Bus) sowie sicherheitskritische Anwendungen (z.B. Rückfahrkamera, Cluster, ADAS) handhaben, während High-End-Anwendungen für den Verbraucher von einem Gast-Betriebssystem wie Android gehostet werden.
Der Thingvisor kann auch als Software Root of Trust betrachtet werden, auf dem sich ein robustes und sicheres System aufbauen lässt. Sicherheitskritische Komponenten wie eine Trusted Execution Environment (TEE), Verschlüsselungsfunktionen und Digital Rights Management (DRM) können in isolierten Prozessen oberhalb des Thingvisor gehostet werden. Sie sind dann von den universellen Systemanwendungen isoliert.