erste schrittevolangvolangvmprogrammierunglogik

# Volang und VolangVM: warum ein Smart Home eine eigene Automatisierungssprache braucht

Jedes Smart Home hat zwei Ebenen. Die erste ist die physische Hardware: Verteilungsmodule, Sensoren, Taster, Rollladenantriebe, Wärme- und Kältequellen. Die zweite ist die Logik, also die Regeln, die entscheiden, was geschehen soll, wenn ein Eingang seinen Zustand ändert. Ein Tastendruck soll ein Licht einschalten. Das Überschreiten einer Temperaturschwelle soll die Kühlung starten. Bewegung zu bestimmten Zeiten soll den Flur beleuchten, aber nur, wenn es draußen dunkel ist.

Die meisten Nutzer sehen das Voldeno-System von der ersten Ebene aus: die Module HUB, I/O, RELAY, 1-WIRE und ANALOG INPUT auf einer Hutschiene, alle über den Voldeno Bus verbunden. Die zweite Ebene, die Logik, läuft darunter und ist das, was "ein Satz Module" von "einem System, das genau das tut, was ich will" unterscheidet.

Dieser Artikel erklärt, wie diese zweite Ebene bei Voldeno organisiert ist: was Volang ist, was VolangVM ist, warum wir eine eigene Sprache gebaut haben, statt eine verbreitete wiederzuverwenden, und was das für die Menschen bedeutet, die sie tatsächlich nutzen. Der Text ist für Leserinnen und Leser mit wenig Programmiererfahrung geschrieben, deshalb erklären wir die wichtigsten Konzepte unterwegs.

# Was "Logik" in einem Smart Home tatsächlich bedeutet

Logik sind einfach Regeln. "Wenn A, dann tue B". Mal eine Bedingung, mal sieben, mal etwas mit Zeitbezug (nach zwei Minuten), mit einem Zähler, mit Hysterese oder mit einer Abhängigkeit von der Tageszeit.

Die einfachste Logik sind zwei Sätze in einfacher Sprache: "wenn jemand diese Taste drückt, schalte dieses Licht ein". Diese Regel behalten Sie im Kopf und richten sie in der App mit einem einzigen Zug ein. Komplexere Logik ist eine Kette von Regeln, die sich gegenseitig beeinflussen. Der Sollwert hängt vom Zeitplan ab, der Zeitplan vom Betriebsmodus, der Betriebsmodus von der Anwesenheit, die Anwesenheit von einigen Sensoren und dem letzten Login in der App. Solche Dinge werden sehr schwer zu pflegen, wenn sie nur als lose Liste von "Szenen" und "Automatisierungen" gespeichert sind.

Logik muss außerdem irgendwo laufen. Bei Voldeno ist dieses Irgendwo der Hub, und in ausgewählten Fällen auch die Erweiterungsmodule. Die Frage lautet: In welchem Format soll diese Logik gespeichert sein, damit der Hub genau weiß, was zu tun ist.

# Kann man sich das nicht einfach zusammenklicken?

Kann man. Für die meisten alltäglichen Szenarien wird es genau so gemacht. In Voldeno Studio setzen Sie die gesamte Logik aus fertigen Bausteinen zusammen. Diese Bausteine nennen wir Logikbausteine. Es gibt Schalter, Zeitpläne, einen Klimaregler, Szenen, Zähler, Integrationsbrücken. Sie verbinden sie mit Leitungen: einen Ausgang eines Bausteins mit einem Eingang eines anderen. Ein typisches Hausautomationsprojekt lässt sich so aufbauen, ohne eine einzige Zeile Code zu schreiben.

Dieser Ansatz hat echte Grenzen. Die eingebauten Bausteine sind eine endliche Liste. Sie tun genau das, wofür sie entworfen wurden. Wenn Sie zum Beispiel:

Impulse eines Energiezählers zählen und bei jeder vollen Kilowattstunde ein Ereignis an Ihre Cloud senden wollen,
eine ungewöhnliche Garagentorsequenz umsetzen wollen, die der Hersteller nicht nativ unterstützt,
einen eigenen Regelalgorithmus für eine Wärmepumpe mit Modi und auf eine bestimmte Anlage abgestimmter Hysterese schreiben wollen,
eine Integration über ein Protokoll aufbauen wollen, das noch nicht auf unserer Integrationsliste steht,

dann bringen Sie fertige Bausteine nicht ans Ziel. Sie müssen genau beschreiben, was geschehen soll, und zwar so, dass der Computer es wortwörtlich ausführt. Genau dafür ist eine Programmiersprache da.

# Warum es "Sprachen" für Logik gibt

Eine Programmiersprache ist eine sehr präzise Art, Regeln aufzuschreiben. Ein Mensch schreibt Text, ein Compiler (ein Übersetzungsprogramm) prüft, ob der Text den vereinbarten Regeln folgt, und dann führt das Gerät diese Beschreibung wortwörtlich aus, Schritt für Schritt, millionenfach, ohne Interpretation dazwischen.

Jedes ernsthafte Gebäudeautomationssystem hat seine eigene Art, Logik festzuhalten. KNX hat ETS und die Konfiguration von Gruppenadressen. Industrielle SPS haben die Sprachfamilie IEC 61131-3 (Kontaktplan, Funktionsbausteinsprache, Anweisungsliste, strukturierter Text). Home Assistant nutzt YAML und Python. Je mehr ein System kann, desto präziser muss die "Sprache" darin sein.

Der Grund, warum man einer Form von Sprache nicht entkommt, ist einfach. Auch Logikbausteine in einer grafischen Oberfläche sind eine Sprache. Jeder Baustein ist eine verborgene Funktion. Jede Verbindung ist eine verborgene Codezeile. Der einzige Unterschied ist, wie sichtbar und wie flexibel diese "Sprache" ist. Visuelle Sprachen sind am Anfang leicht und werden mühsam, wenn die Logik wächst. Textbasierte sind am Anfang schwerer und weit haltbarer, sobald das Projekt groß wird.

# Warum wir keine bestehende Sprache wie Python oder JavaScript genommen haben

Das war die erste Frage, die wir uns gestellt haben. Python und JavaScript sind überall. Lua ist in eingebetteten Geräten beliebt. Wir schätzen diese Sprachen und nutzen sie in anderen Teilen unseres Ökosystems (Backend-Werkzeuge, die Desktop-App). Für Logik, die auf einem Hutschienenmodul läuft, haben wir uns dennoch entschieden, etwas Eigenes zu bauen. Hier ist, warum.

Größe. Der Hub hat begrenzten Speicher und eine eingebettete CPU, die Erweiterungsmodule noch weniger. Ein vollständiger Python-Interpreter belegt viele Megabyte RAM und schleppt ein riesiges Abhängigkeitsökosystem mit sich. Für unsere Module ist das unverhältnismäßig teuer. Volang ist so ausgelegt, dass es klein, sparsam und schnell startbereit ist.

Sicherheit. Selbst geschriebene Logik darf niemals den Hub zum Absturz bringen oder andere Projekte auf demselben Gerät beeinträchtigen können. Das erfordert sehr präzise Grenzen dafür, welche Operationen erlaubt sind und wie lange. In einem universellen Python oder JavaScript ist das machbar, aber nur mit großem Aufwand und oft unvollständig. Eine enge, dedizierte Sprache erlaubt uns, diese Grenzen in den Entwurf selbst einzubacken, statt sie nachträglich anzuflanschen.

Vorhersagbare Ausführungszeit. In einem System, das Heizung, Beleuchtung und ein Tor steuert, ist "fast immer schnell" keine ausreichend gute Eigenschaft. Wir wollten eine Sprache, in der derselbe Code immer ungefähr gleich lange läuft und im Hintergrund keine Zauberei betreibt (etwa Speicher zu zufälligen Zeitpunkten freizugeben, wie es die meisten universellen Laufzeitumgebungen tun). Volang hat keinen Garbage Collector, der die Skriptausführung zu einem unerwarteten Moment anhalten könnte.

Für Automatisierung gebaut. In Volang ergibt Code wie output::set("relay_1", true) oder input::value() von der ersten Zeile an Sinn. Konzepte wie "Eingang", "Ausgang", "Kanal", "Baustein" sind Teil der Standardbibliothek. In Python oder JavaScript müssten diese Ebenen obendrauf gebaut und gepflegt werden, und der Nutzer müsste sie trotzdem lernen.

Stabilität über die Zeit. Wie sich Syntax und Standardbibliothek von Volang weiterentwickeln, entscheiden wir, nicht eine externe Community. In Python oder JavaScript verändern neue Sprachversionen regelmäßig bestehende Funktionen oder erklären sie für veraltet, sodass Projekte hin und wieder angepasst werden müssen. Bei Volang wollen wir, dass ein heute geschriebenes Skript in zwei und in zehn Jahren unverändert weiterläuft.

Was ist mit MicroPython? Diese Frage kommt immer wieder, deshalb eine kurze Antwort. MicroPython und CircuitPython sind abgespeckte Python-Versionen für Mikrocontroller und in ihrer Klasse wirklich gut. Für unseren konkreten Einsatzzweck sind die Gründe, sie nicht zu wählen, genau die oben genannten, nur zugespitzt: Sie belegen weiterhin Hunderte KB Speicher, sie haben weiterhin einen Garbage Collector, der das Skript für unvorhersehbare Millisekunden anhält, und um eine sinnvolle Sandbox zu bauen, müssen Sie so viel von Python wegschneiden, dass am Ende ohnehin eine engere, eigene Sprache entsteht. "Fast Python" ist zudem eine Falle, weil Nutzer in Gewohnheiten verfallen, die plötzlich nicht mehr funktionieren.

Das ist keine Haltung nach dem Motto "aus Prinzip alles auf eigene Weise". Wir sind offen dafür, künftig weitere Sprachen einzubinden, wo es sinnvoll ist. Für die Ebene der Bausteinlogik selbst bietet eine enge, eigene Sprache das beste Verhältnis von Aufwand und Nutzen.

# Was VolangVM ist

VM, kurz für virtuelle Maschine, klingt einschüchternd, ist in der Praxis aber einfach ein kleines, spezialisiertes Programm, das "so tut, als wäre es" ein einfacher Computer, und darauf Volang-Anweisungen ausführt.

Wenn Sie ein Skript in Studio schreiben, passiert Folgendes:

Der Volang-Quelltext wird auf Syntax und Typen geprüft. Das ist der Schritt der Kompilierung.
Wenn alles passt, wandelt der Compiler den Text in kompakte, binäre Anweisungen um, den sogenannten Bytecode. Bytecode sieht für einen Menschen wie eine Kette von Zahlen aus, ist für eine Maschine aber schnell zu lesen.
Der Bytecode landet auf dem Hub (und mit der Zeit auf ausgewählten Erweiterungsmodulen) und wird von VolangVM geladen.
VolangVM arbeitet die Anweisungen eine nach der anderen ab. Sie liest Eingänge, wertet Bedingungen aus, setzt Ausgänge und ruft Funktionen der Standardbibliothek auf.

Zum Vergleich: Ohne VM müsste der Hub den Skripttext jedes Mal neu parsen, ihn validieren und in Aktionen übersetzen. Mit einer VM wird diese Arbeit einmal erledigt, und die Ausführung des Skripts auf dem Gerät läuft darauf hinaus, fertige Anweisungen zu lesen.

# Der Compiler lebt nicht nur in Studio

Ein wichtiger und oft übersehener Punkt: Derselbe Volang-Compiler steckt sowohl in Voldeno Studio als auch im Hub selbst.

Im typischen Ablauf öffnet ein Installateur ein Projekt in Studio auf einem Computer, bearbeitet das Skript, kompiliert es lokal, prüft es im Simulator und lädt den bereits kompilierten Bytecode auf den Hub. Das ist der schnellste und bequemste Weg, weil Studio Syntaxfehler und Warnungen sofort anzeigt.

Der Hub verlangt jedoch nicht, dass der Code vorkompiliert ankommt. Er kann auch rohen Volang-Text annehmen und ihn vor der Ausführung selbst kompilieren. Syntaxprüfung, Typprüfung, Integritätsvalidierung, Bytecode-Erzeugung: All das kann der Hub eigenständig erledigen.

Für uns als Systemdesigner ist das ein architektonisches Fundament. Studio und der Hub verwenden denselben Compiler-Code und dieselbe VM. Ein an einem Ort kompiliertes Skript verhält sich identisch, wenn es am anderen ausgeführt wird. Es gibt keinen "Studio-Dialekt" und keinen "Hub-Dialekt". Das öffnet die Tür zu künftigen Szenarien, in denen Logik ohne Studio aktualisiert werden kann (etwa aus der Ferne über Voldeno Cloud oder programmgesteuert aus den Werkzeugen eines Integrators). Vorerst bleibt der primäre Weg das Bearbeiten und Kompilieren in Studio.

// Kurzes Beispiel: prüfen, welcher Eingang sich geändert hat,
// und den Ausgang "relay_1" entsprechend umschalten.
channel = input::channel()
value = input::value()

if (channel == "input" and value) {
    output::toggle("relay_1")
}

Diese wenigen Zeilen Logik kompilieren zu ein paar Dutzend Byte Bytecode und werden von VolangVM jedes Mal ausgeführt, wenn sich der Eingang des Bausteins ändert.

# Was VolangVM Ihnen tatsächlich bringt

Sandbox, also Isolation. Jedes Skript läuft in einer abgeschotteten Umgebung. Ein Laufzeitfehler in einem Baustein (etwa eine Division durch null) stoppt nur dieses eine Skript, nicht den ganzen Hub. Der Rest der Automatisierung arbeitet weiter: Lichter reagieren weiterhin, die Heizung regelt weiter, Zeitpläne feuern weiter.

Leistung auf kleiner Hardware. Bytecode ist klein und schnell auszuführen. Die VM passt an Stellen, an denen ein vollständiger, universeller Interpreter keinen Platz hätte. Das öffnet die Tür, Logik nicht nur zentral auf dem Hub, sondern auch direkt auf Erweiterungsmodulen laufen zu lassen.

Identische Simulation in Voldeno Studio. Das ist eine der wichtigsten Folgen der VM-Architektur. Dieselbe VolangVM, die auf dem Hub läuft, läuft auch in Studio auf dem Computer des Installateurs. Sie können das Skript "trocken" ausführen, es mit Testeingaben füttern und sein Verhalten beobachten, mit der Garantie, dass es sich auf dem echten Gerät identisch verhält. Es gibt kein "läuft auf meinem Computer, aber nicht beim Kunden".

Portabilität. Bytecode hängt nicht von der genauen CPU im jeweiligen Modul ab. Logik kann künftig auf neuer Hardware laufen, ohne Änderungen am Projektcode, solange VolangVM darauf läuft.

Verteilte Ausführung. Ausgewählte Logikteile können nah an der Hardware laufen, auf dem Erweiterungsmodul selbst, statt zentral. Das senkt die Latenz und lässt kritische Reaktionen (etwa "den Kontakt sofort öffnen, wenn der Strom überschritten wird") lokal ablaufen, selbst wenn der Bus gerade ausgelastet ist.

Updates, die sich leicht zurücknehmen lassen. Skripte sind im Projekt versioniert. Das Hochladen einer neuen Version ersetzt keine Modul-Firmware, sondern nur den Inhalt der VM. Ein Notfall-Rollback auf eine frühere Version ist günstig und schnell.

# Die Volang-Standardbibliothek, also was jedes Skript ab Werk bekommt

Die Sprache selbst ist nur die Hälfte des Puzzles. Die andere Hälfte ist die Standardbibliothek, eine Sammlung fertiger Funktionen, die jedes Skript sofort aufrufen kann, ohne Installation, ohne Code von anderswo zu kopieren, ohne Pakete aus dem Internet zu holen.

Jede ernsthafte Programmiersprache hat eine Standardbibliothek. In Python sind das os, math, datetime, json und Hunderte mehr. In JavaScript sind es Math, JSON, Date, fetch. Der Grund ist einfach: Ohne Standardbibliothek müsste jeder Programmierer die Grundlagen von Grund auf schreiben. Das Multiplizieren von Zahlen ist Teil der Sprachsyntax, aber "Quadratwurzel", "aktuelle Uhrzeit", "Text in Zahl umwandeln" oder "aufrunden" sind Funktionen. Die Standardbibliothek beantwortet die Frage "welche grundlegenden Dinge kann die Sprache bereits, sobald sie läuft".

In Volang teilt sich die Standardbibliothek in einige Gruppen. Wir listen sie auf, damit konkret ist, worüber ein Skript verfügt:

Ein- und Ausgänge des Bausteins (input::channel, input::value, input::get, output::set, output::toggle, ...). Das ist die Grundlage, denn der ganze Sinn von Volang ist es, auf ein Ereignis an einem Eingang zu reagieren und einen Ausgang zu setzen. Ohne diese Funktionen hat ein Skript keine Möglichkeit, mit dem Rest der Installation zu sprechen.
Zustand und Konfiguration des Bausteins (state::set, state::get, config::get, ...). Damit merkt sich ein Baustein Dinge zwischen Ereignissen (etwa einen Impulszähler) und liest die in Studio gesetzten Parameter.
Zeit und Terminierung (time::now, Callbacks). Ohne diese lässt sich keine Regel "5 Minuten einschalten, dann aus" schreiben.
Arbeit mit Text, Zahlen, Arrays und Maps (String-Operationen, Mathematik, Array, Map). Alltagswerkzeuge: zählen, sortieren, Text aufteilen, einen Bereich prüfen.
JSON und Base64. Standardformate, die Sie immer dann brauchen, wenn Logik mit der Außenwelt sprechen muss.
HTTP und Netzwerk in ausgewählten, kontrollierten Formen. Das ist der einzige Weg, über den ein Skript über das Gerät hinausreicht. Es gibt kein "importiere irgendetwas aus dem Internet". Es gibt "nutze diese bestimmten Funktionen, die die VM kennt und versteht".
Kryptografie und Hilfsoperationen. Signaturen, Hashes, Kodierungen, gerade genug, um eine sichere Integration zu bauen (zum Beispiel ein JWT für Google Cloud, wie in unserer Demo auf der Google Cloud Next).
Asynchrone Operationen. Damit planen Sie eine Aktion für später, ohne die Ausführung zu blockieren.

In Volang spielt die Standardbibliothek eine weitere Rolle, die "große" Sprachen nicht haben: Sie ist zugleich die Sicherheitsgrenze. Da Sie kein Paket installieren und kein beliebiges Modul importieren können, muss alles, was ein Skript an der Außenwelt tun kann, in der Standardbibliothek liegen. Jede Funktion darin wurde bewusst so entworfen, dass sie aus einer Sandbox heraus aufgerufen werden kann. Nichts sickert durch "Seitentüren", weil es keine Seitentüren gibt.

Das verändert, wie man die Sprache lernt. Bei einer großen Sprache lernt man nach dem Muster "ich finde eine Bibliothek, die das kann". Bei Volang lernt man nach dem Muster "ich prüfe, welche Funktion der Standardbibliothek das tut". Die Liste ist endlich, dafür ist alles darin stabil, schnell und sicher.

Die vollständige Funktionsliste finden Sie in der Volang-Standardbibliothek.

# Die Grenzen von Volang, also was es nicht tut

Volang ist bewusst eng gehalten. Aufzulisten, was es nicht hat, ist hier ehrlicher, als alles aufzuzählen, was es kann.

Kein freier Internetzugang. Netzwerkkommunikation läuft über bestimmte, vorbereitete Funktionen der Standardbibliothek (etwa HTTP-Aufrufe, einen MQTT-Client, das Veröffentlichen in Google Pub/Sub). Es gibt kein import requests in einem Skript.
Keine Installation von Drittanbieter-Bibliotheken. Alles, was Sie aufrufen können, stammt entweder aus der Volang-Standardbibliothek oder aus den von Voldeno ausgelieferten Logikbausteinen.
Kein Dateizugriff. Ein Skript liest oder schreibt keine Dateien auf der Festplatte des Hub. Der Zustand lebt in Bausteinvariablen und in Ein-/Ausgängen.
Keine Systemoperationen. Sie können kein externes Programm aufrufen, keinen Socket "von Hand" öffnen, keinen Container starten. Das ist Absicht, und die Sicherheit des Systems beruht darauf.
Eine enge Syntax. Es gibt nur die while-Schleife, kein for. Globale Variablen sind innerhalb von Funktionen nicht sichtbar, Argumente müssen explizit übergeben werden. Die Liste der Schlüsselwörter ist kurz.

Für einen professionellen Programmierer ist die Liste der Einschränkungen lang. Das ist so gewollt. Volang soll nicht "noch eine universelle Sprache" sein. Es soll der kürzeste Weg von einer Automatisierungsidee zu einem funktionierenden, sicheren und vorhersagbaren Skript im Hub sein.

# Risiken, die man kennen sollte

Eigene Logik zu schreiben ist Macht, und Macht hat Folgen. Ein paar Dinge, die man im Blick behalten sollte.

Schlechte Hardwaresteuerung. Ein Skript, das alle 200 ms die Heizung eines Boilers umschaltet, zerstört das Schütz. Ein Skript, das versucht, Rollläden gleichzeitig zu öffnen und zu schließen, löst den Thermoschutz des Motors aus. VolangVM weiß nicht, was physisch am Kontakt auf der anderen Seite angeschlossen ist. Das liegt in der Verantwortung des Logikdesigners.

Schleifen, die nie enden. Eine while-Schleife mit einer Bedingung, die nie falsch wird, blockiert die Skriptausführung im Baustein. Da das Skript nie normal endet, reagiert es auch nicht auf weitere Eingangsereignisse, und der Baustein stellt seine Arbeit ein. Wenn Sie also ein while schreiben, stützen Sie die Bedingung auf einen Zähler oder einen Eingangswert und bauen Sie stets etwas in die Schleife ein, das ihn verändert. Oder fügen Sie ein break hinzu, das an eine Rückfallbedingung gekoppelt ist. Volang hat bewusst kein for, deshalb liegt die Verantwortung für das Beenden der Schleife beim Skriptautor.

Logik, die "trocken" Sinn ergibt, aber nicht in der physischen Realität. Der Studio-Simulator prüft, ob sich das Skript korrekt verhält, aber nicht, ob sich die Rollläden im Wohnzimmer um 14:00 tatsächlich öffnen können, wenn die Sonne voll steht und das Fenster auf Kippstellung ist und sich am Antrieb verhaken könnte. Einen realen Test an der echten Anlage können Sie nicht überspringen.

Komplexität, die schneller wächst als die Dokumentation. Es ist leicht, eine weitere Bedingung, eine weitere Variable, eine weitere Abhängigkeit hinzuzufügen. Es ist schwerer, in einem Jahr zu dieser Datei zurückzukehren und zu verstehen, warum. Wir empfehlen, Logik in kleine Bausteine aufzuteilen und überall dort Kommentare zu ergänzen, wo der Grund für eine Entscheidung nicht schon aus dem Code selbst hervorgeht.

Updates, die das Verhalten still verändern. Volang als Sprache und die Standardbibliothek sind stabil, aber das Automatisierungsprojekt entwickelt sich weiter. Jede Änderung an einem Skript sollte in Studio mit Simulation laufen, bevor sie auf einen produktiven Hub gelangt.

Diese Risiken sind real, aber auch normal für jedes programmierbare Automatisierungssystem. Deshalb halten wir an drei Grundsätzen fest: Ein Skript läuft in einer Sandbox, dasselbe Skript kann in Studio ausgeführt werden, bevor es auf einen Hub geht, und die vorherige Version lässt sich jederzeit wiederherstellen.

# Logikbausteine, die Ebene über Volang

Ein praktischer Hinweis zum Abschluss. Die meisten Nutzer und Installateure werden nie eine einzige Zeile Volang schreiben. Für sie kommt Logik aus fertigen Logikbausteinen (Schalter, Klimaregler, Zeitpläne, Szenen). Studio verdrahtet sie visuell und der Hub führt sie aus. Jeder dieser Bausteine ist unter der Haube kompiliertes Volang, aus Sicht des Nutzers sieht er aber aus wie ein Baustein mit Eingangs- und Ausgangsanschlüssen.

Volang kommt ins Spiel, wenn:

Sie einen eigenen Baustein hinzufügen wollen, der etwas tut, das die Bibliothek nicht hat,
Sie eine Integration mit einem externen System bauen,
Sie eine ungewöhnliche Automatisierung für einen bestimmten Kunden schreiben,
oder Sie als Installateur/Integrator über viele Anlagen hinweg Ihre eigenen "Hausbausteine" pflegen.

In diesen Fällen ist das Schreiben in Volang schlicht schneller und über die Zeit haltbarer, als viele eingebaute Bausteine nebeneinander zusammenzukleben.

# Wie geht es weiter

Die vollständige Sprachreferenz: Volang.
Funktionen und Module, die in Skripten verfügbar sind: Volang-Standardbibliothek.
Voldeno Studio ist ein kostenloser Download, mit den Werkzeugen zum Bearbeiten von Bausteinen, Kompilieren und Simulieren. Starten Sie auf der Downloadseite.
Möchten Sie eigene Bausteine für Ihre Kunden schreiben oder eine Integration mit einem bestimmten externen System aufbauen? Nehmen Sie Kontakt auf. Für Integratoren und Partner: Für Profis.