Richtig! Ich texte hier auf jeden Fall nicht von der eigentlichen Hardwareanbindung denn im Falle von XML texte ich ja von der Vernetzung über die Rechnergrenzen hinaus ... und nicht von der Vernetzung mit dem Rechner selbst... denn das will ich mir sparen.

Die Anbindung der unteren Layer über eine einheitliche Schnittstelle (zu diesem Layer).
Also die obere Schicht(en) Abgrenzen von dem was drunter kommen mag.

z.B.
Man packt die Hardwareanbindung in eine Treiber DLL (DynamicLinkLibary WÍN) oder SO(SharedObject LIN) diese dann durch einen/diesen/jenen ApplicationsServer geladen/entladen wird und die Anbindung zwischen zwei Programmteilen herstellt.
Die DLL-Schnittstelle muß fest vorgeschrieben sein um die Funktionszugriffe des ApplicationServers nicht in leere Laufen zu lassen.

Es können beliebige DLLs, ActiveX oder SO oder von diesem Programmteil (ApplicationServer ) geladen und miteinander verbunden werden.

Das Programmteilstück das alle lädt und verbindet hat schon einen festen Namen (sowie die Architektur) nennt sich ApplicationServer in der Softwaretechnik.
Das ist also alles nix neues ... nur bewährtes.
Die DLLs oder SOs vielleicht auch AktiveX

Die einzelnen Module (Treiber, Oberflächen, Auswertungen ...) können je nach Auslegung der Schnittstelle in verschiedenen Sprachen geschrieben sein.

Als Hilfe zur Programmierung gibt es dann Klassen von denen man ableiten kann bzw. muss um alle benötigten Schnittstellenfunktionen bedienen zu können ohne selbst welche bauen zu müssen.
Für C könnte man ähnliche Konstrukte mit Standard Bibliotheken anwenden.
Die Module (interne und externe) können sich untereinander über den ApplicationServers unterhalten.
...über Messagepoolin, Message-Stack, Message-Spooler, Datei, Messageque, SharedMemory-Handling oder Windows Messaging wie auch immer... das ist Bier des Applikationserverbauers
(Ich glaube NumberFive macht so etwas ähnliches in seiner Version).
Ob man dann wirklich XML einsetzt ist auch offen... er sollte jedenfalls eine Netzübergreifende standardisierte Geschichte wählen die auch Lösungen für Binärdaten und Strukturen sowie Objekte (serialize Geschichten) an Board hat.

Praktisches Beispiel WebGUI mit Roboter und CAM.
1.Roboter mit Cam (is klar)
<Kabelsalat>
2.Microprozellor (*XXX)
<RS232>
3.Treiber (Modul des Systems) (*XXX mit fester Schnittstelle)
<ApplikationServer>
4.GUI (Modul des Systems) <-> Messdatenerfassung <-> Steuerung

*XXX = Frei wählbare Auslegung der Programmierung ... in diesem Bereich möchte ich derzeit nicht mitquatschen.

Das ist so im groben die etwas anders beschriebene Fassung.
Das mit den Abgeleiteten Treibern gibt eben die meiste Freiheitsgrade und lenkt das richtige Ergebnis.
Eine Treiberbibliothek könnte vielleicht beim anhacken des Roboters über RS232, Parallel , USB, Infrarot ;BlueT...
helfen... nur sind die Möglichkeiten und Variationen sind mannigfaltig.


Netter Gruß,
Chris

PS: Ich werd mal eine Architektur malen... es ist nun alles a bisl verwirrend wenn man es nicht schon kennt... zudem will/muss ich ernsthaft so was basteln um Bilder und Strukturen übers Netz (WWW) zu bekommen.