Do you API?

Gerade schreibe ich an unserem Beitrag für die nächste BKAWE (Berliner Konferenz Abfallwirtschaft und Energie, am 29./30. Januar 2024) zum Thema Digitale Zwillinge. Dort steht dann sinngemäss, dass man Digitale Zwillinge Top-down oder Bottom-up entwickeln kann: Top-down = das Produkt Digitaler Zwilling existiert schon und wird für eine Anlage angepasst, Bottom-up = in der Regel eine umfangreichere Massen- und Energiebilanzierung, vielleicht auf Grundlage eines Auslegungstools. Oder ­als dritte Variante – wie wir das machen würden – mit einem hybriden Ansatz.

Egal wie, so richtig Power bekommt der Digitale Zwilling erst mit API-Schnittstellen ("application programming interface"). APIs dienen dazu, Informationen zwischen verschiedenen Anwendungen auszutauschen. Auf OpenPi können wir so Prozesswerte "anders als über den Browser" abrufen und für den Digitalen Zwilling dann in einer eigenen, separaten Modellumgebung verwenden. Das hat den Vorteil, dass Modell, Datenspeicher und Visualisierung getrennt bleiben, mit vielen Vorteilen für Flexibilität, Geschwindigkeit und Kosten.

Aus Entwicklersicht interessant: APIs sind nicht unbedingt REST APIs und verbinden auch nicht in jedem Fall ein Frontend mit einem Backend (es geht ja oft auch ohne diese Trennung). Neben ressourcen-orientierten REST APIs arbeiten wir viel mit RPC bzw. remote procedure call APIs, die z.B. Aktionen auf Datensätze durchführen (Prozesswerte anzeigen, Statistiken updaten, nach Anomalien suchen etc.). Eine schöne Übersicht, wie man die verschiedenen API Layer organisieren kann, findet sich hier: Organize APIs around business domains and capabilities, not tools