Zur Beschreibung des Systems um den Ball wird ein Netz verwendet. Die Schritte, die notwendig sind, um dieses ausführbar zu machen, auszuführen und zu Laufzeit zu steuern, werden hier beschrieben.
Ein Netz ist die allgemeinste funktionsbeschreibende Einheit des Frameworks. Sie beste-hen aus Komponenten-Netzen, Komponenten-Nodes und Subnetzen. Die Subnetze kön-nen durch die in ihkön-nen enthaltenden Kompokön-nenten-Netzen und Nodes ersetzt werden.
Das Verhalten des Netzes ergibt sich aus der verteilten Ausführung und Kommunikation von Komponenten-Nodes und -Netzen, daher müssen entsprechende lauffähige Artefakte generiert und auf das Zielsystem überspielt werden.
5.3.1 Build
Ein Netz wird auf unterschiedlichen Ebenen durch einen Build Prozess in, falls erforder-lich, mehrere ausführbare Artefakte übersetzt. Die wesentlichen Schritte auf den unter-schiedlichen Ebenen werden hier am Beispielszenario beschrieben.
Netz: Das Beispielszenario als Ganzes wird als Netz abgebildet, der Build Prozess eines Netzes, an dessen Ende ein Archiv von ausführbaren Artefakten steht, unterteilt sich in folgende Teilschritte: Zunächst werden alle Subnetze aufgelöst, um ein Netz ohne Subnetze zu erhalten. Anschließend werden Artefakte für die verbleibenden Instanzen von Komponenten-Netze und Komponenten-Nodes gebaut. Die resultierenden ausführbaren Artefakte enthalten Informationen über ihre Rolle im Netz und verbinden sich, wenn ausgeführt, zu diesem. Um die einem Netz zugehörigen Artefakte zentral zu sammeln und ihre Validität gewährleisten zu können, werden die Artefakte mit Signaturen versehen und in einem Archiv gepackt.
Wie der konkrete Schritt des Aufbaues der Netzverschaltung abläuft, ist abhängig von den verwendeten Runtimes. Im Beispielszenario wird ein Komponenten Node der Runtime
‘esp8266’, einer der Runtime ‘python’ und ein Komponenten-Netz der runtime ‘nodecpp’, in welchem C++ Komponenten für die Audiosynthese verschaltet werden, verwendet.
5 Entwurf eines Frameworks
Komponenten Nodes: Aktuell werde drei Runtimes für Komponenten-Nodes unter-stützt.
Komponenten-Nodes können in Python implementiert werden, Interface-definitionen wer-den als Python Pakete bereitgestellt. Zusätzlich wird ein Paket generiert, welches die konkreten Interfaces des Nodes und Funktionalität zum interfacen mit dem Netz be-reitstellt. Auch C++ kann auf zwei Architekturen (einerseits x86/x86-64 und esp8266) verwendet werden, um Komponenten-Nodes zu erstellen. Interfaceimplementationen sind hierbei C++ Header und Sourcefiles. Für konkrete Interfaces und weitere Netz Funktio-nalität wird entsprechender Quellcode generiert. Im Beispiel Objekt sind die Sensorik und die Wiedergabe als Komponenten-Nodes realisiert, welche in C++, beziehungsweise Python, realisiert sind.
Der Build Prozess eines Komponenten-Node ist abhängig von der verwendeten Run-time und ist nur möglich wenn der Komponenten-Node valide ist. Für einen gültigen Komponenten-Node wird ein Build Ordner erstellt, in welchemcImplementation sowie alle Artefakte der Interfaces, die er verwendet kopiert werden. Abschließend wird ein Runti-me spezifischer Build Prozess angestoßen, welcher die Definition des Nodes und optional seine Verschaltung in einem Netz berücksichtigt, hierbei wird typischerweise Code oder Konfiguration generiert.
Komponenten-Netze: Für Komponenten-Netze steht die ‘nodecpp’ Runtime zur Ver-fügung, welche für die Audiosynthese verwendet wird. Es werden kompilierte Codeteile zu Laufzeit verschaltet, um das gewünscht Verhalten zu erhalten. Die Komponenten wer-den hierzu kompiliert in einer entsprechend strukturierten Shared-Object Datei abgelegt.
Benötigte Komponenten werden beim Starten der Ausführung von der Runtime geladen, und entsprechend einer Initialverschaltung verbunden.
Komponenten: Der Build Prozess einer Komponente hängt stark von der zu verwen-denden Runtime ab, zurzeit wird lediglich eine unterstützt.
Komponenten der Runtime nodecpp werden in C++ code beschrieben, und werden zu einer Shared Object Datei compiliertm welche einen Index der Komponenten und einer Beschreibung dieser enthält.
5 Entwurf eines Frameworks
5.3.2 Deployment und Startup
Das Deployment und anschließend der Startschritt eines Netzes sind abhängig von ver-wendeter Hardware und Verschaltung der Komponenten-Netze/-Nodes. Für die Realisie-rung des Beispielobjektes müssen Artefakte auf einem Microcontroller, einem Raspber-ryPy und einem x64 Linux Rechner ausgeführt werden.
Die Geräte werden manuell mit der Software bespielt. Der Start des Sensor Knotens erfolgt mit Einschalten der Stromversorgung. Mit dem Startup meldet sich der Sensor Knoten in einem WLAN-Netz an und mit seinem Netz und Bezeichner in diesem bei einem Namensserver, daraufhin wartet er auf Anfragen für Sensor Daten.
Ein zentraler Namensserver ist an dieser Stelle optional und kann durch andere Mecha-nismen ersetzt werde. Er wird verwendet, um ein einfaches Finden von Kommunikati-onspartnern zu ermöglichen.
Das zu verwendende WLAN-Netz ist über ein Web Interfaces konfigurierbar, welches über einen Hardware Jumper aktiviert werden kann.
Das Komponenten-Netz der Synthese benötigt eine Runtime für die Ausführung. Zu-nächst werden die Shared-Objects unter entsprechenden Bezeichnern in der Runtime hinterlegt. Anschließend wird die Runtime gestartet, und über eine Netzwerkschnittstel-le eine Instanz des Komponenten-Netzes mittels der binären Beschreibung erstellt. Dieser Prozess wird zurzeit manuell durchgeführt.
Nach Start verbindet sich der Prozess zum Namensserver und wartet auf die Verfügbar-keit des Sensors und der Wiedergabe. Dieses Verhalten ergibt sich aus den Interfaceim-plementationen. Nach dieser Verbindungsphase geht die Komponente in einen regulären Betrieb über, welcher ggf. durch einen Steuerbefehl oder etwa einen Netzwerk-Fehler unterbrochen werden kann.
5.3.3 Steuerung zu Laufzeit
Für die Steuerung von Komponenten-Nodes oder Komponenten-Netzen zur Laufzeit gibt es keine expliziten Mechanismen. Grundsätzlich müssen Komponenten also keine Inter-faces für eine Steuerung bereitstellen.
5 Entwurf eines Frameworks
Zusätzlich bietet die Synthese die Möglichkeit, das Komponenten-Netz zu Laufzeit zu modifizieren und intern anfallende Daten über ein seperates Interface nach Außen be-reitzustellen. Hierdurch ist es möglich, während der Entwicklung interne Signale zu ana-lysieren und das Synthesemodell anzupassen. Auch das Nachladen von Komponenten zur Verwendung im Komponenten-Netz ist möglich.