Java &GraalVM Native Image:Verbesserung der Datenbankkonnektivität in Fertigungs-Apps

Die heutige Anwendungslandschaft in der Fertigungsindustrie ist in eine starre Hierarchie unterteilt. Angefangen vom Management mit ERP-Systemen über Planungssysteme mit MES bis hin zu Überwachungssystemen mit SCADA bis hin zu Steuerungssystemen, die ganz unten mit SPS und Feldsystemen realisiert werden.

Während die meisten Systeme für Management, Planung und Überwachung in objektorientierten Programmiersprachen auf hoher Ebene implementiert sind, werden Steuerungssysteme vollständig in Sprachen auf niedriger Ebene implementiert, wobei C die dominierende Programmiersprache ist.

Dieser abrupte Wechsel von einer hohen zu einer niedrigen Hierarchieebene führt zu mehreren Problemen. Es sind völlig andere Tools und Ökosysteme erforderlich. Für die Umsetzung müssen völlig unterschiedliche Entwickler mit einer anderen Denkweise hinzugezogen werden, um eine Aufgabe umzusetzen. Zwischen den beiden Welten bzw. Systemen müssen Schnittstellen definiert werden. Nur weil es auf der Steuerungsebene keine Möglichkeit gibt, mit einer aus der Aufsichtsebene bekannten Hochprogrammiersprache fortzufahren. Dies hat sich nun geändert. Durch den Einsatz der Container-Technologie auf der Steuerungsebene beispielsweise in einer SPS sind wir in der Lage, Programmiersprachen wie Java auf dieser Hierarchieebene einzusetzen und die starren Hierarchien aufzubrechen.

Java ist eine weit verbreitete, objektorientierte Programmiersprache auf hohem Niveau. Es verfügt über eine lebendige Community und ein Ökosystem aus Bibliotheken und Frameworks, die zusätzliche Funktionen bieten und es Ihnen ermöglichen, vorhandene Tools und Lösungen zu nutzen, um Ihre Anwendung schneller und effizienter zu erstellen.

Wir zeigen, wie Java auf einer PLCnext von Phoenix Contact verfügbar ist, um die Entwicklung einer Anwendung zu vereinfachen, die auf PLCnext ausgeführt wird und direkt mit einer Datenbank kommuniziert, um anwendungsrelevante Informationen abzurufen, zu speichern und auf einer Weboberfläche darzustellen. Eines der beliebtesten Frameworks in Java ist Hibernate. Es vereinfacht den Prozess der Zuordnung von Java-Objekten zu relationalen Datenbanktabellen und reduziert die Menge an Boilerplate-Code, der für Datenbankoperationen erforderlich ist. Hibernate bietet ein hohes Abstraktionsniveau und ermöglicht es Entwicklern, mit Objekten statt direkt mit SQL-Abfragen zu arbeiten. Dies kann zu schnelleren Entwicklungszyklen und einem geringeren Entwicklungsaufwand führen. Hibernate abstrahiert die Unterschiede zwischen verschiedenen Datenbankanbietern und erleichtert so den Wechsel zwischen Datenbanken ohne wesentliche Codeänderungen. Dieser Artikel beschreibt die Integration von Hibernate zur Anbindung von auf SPSen laufender Software an Datenbanken.

Moderne Java-Anwendung auf PLCnext

Um mit der Implementierung einer modernen Java-Anwendung zu beginnen, empfehlen wir die Verwendung von Anwendungsframeworks wie Quarkus oder Spring Boot. Diese Frameworks vereinfachen die Konfiguration des Projekts, das Abhängigkeitsmanagement.

Für dieses Beispiel starten wir unsere Anwendung mit dem Using Hibernate ORM and Jakarta Persistence Guide von Quarkus. Ein Beispiel des Quellcodes finden Sie im Github-Projekt hibernate-orm-quickstart.

Wir beginnen mit der Änderung des Quellcodes der Anwendung. Wir können die Java-Klasse Fruit.java ändern in Event.java und fügen Sie ein neues Feld date hinzu .

Beispiel für Code Event.java :

...
@Entity
@Table(name = "Events")
public class Event {
 @Id
 @GeneratedValue
 private Long id;
 
 private String title;
 
 @Column(name = "eventDate")
 private LocalDateTime date;
 
...

Wir können die Datenbank-URL und die Anmeldeinformationen konfigurieren, indem wir die Datei application.properties ändern

Beispiel für src/main/resources/application.properties

quarkus.datasource.db-kind=postgresql
quarkus.datasource.username=myusername
quarkus.datasource.password=mypassword
quarkus.datasource.jdbc.url=jdbc:postgresql://myremotehost/mydatabase
quarkus.datasource.jdbc.max-size=8
quarkus.datasource.jdbc.min-size=2
quarkus.hibernate-orm.database.generation=create
...

Beim Start der Anwendung wird eine Tabelle in der Datenbank erstellt und bei Bedarf initialisiert. Nach dem Start können wir mit der Datenbank über ein Webinterface interagieren, das auf Port 8080 auf der PLCnext läuft:

Bedenken Sie, dass dies alles auf der Kontrollebene unserer Hierarchie geschieht, ohne dass dazwischen ein zusätzliches System erforderlich ist.

GraalVM Native Image

Viele Entwickler glauben immer noch, dass Java ein sogenanntes Java Runtime Environment zur Ausführung von Java Byte-Code benötigt und nicht die nötige Leistung bietet. Dies ist bei eingebetteten Anwendungen nicht mehr der Fall. In diesem Beispiel verwenden wir die GraalVM Native Image-Technologie, um Java-Code in eine native Anwendung zu kompilieren. Die native Image-Kompilierung von GraalVM bietet eine überzeugende Lösung für die Bewältigung der Herausforderungen der Startzeit und des Speicherverbrauchs in Java-Anwendungen, insbesondere in ressourcenbeschränkten Umgebungen wie eingebetteten Systemen. Durch die vorzeitige Kompilierung von Java-Anwendungen in native ausführbare Dateien reduziert GraalVM die Startzeit und den Speicheraufwand im Vergleich zur herkömmlichen Just-In-Time-Kompilierung (JIT) erheblich.

GraalVM von MicroDoc verfügt über die einzigartige Fähigkeit, Binärdateien für eingebettete Geräte zu generieren. Zum Zeitpunkt des Schreibens dieses Tutorials unterstützt GraalVM 32-Bit- und 64-Bit-ARM- und x86-Prozessoren.

Um unsere Java-Anwendung im Voraus für die SPS zu kompilieren AXC F 1152 , können wir MicroDocs GraalVM verwenden und einige Compiler-Optionen in der Datei application.properties konfigurieren .

...
quarkus.native.additional-build-args=--target=linux-arm,-H:CompilerBackend=llvm,-H:+PreserveFramePointer,-Dllvm.bin.dir=/llvm/bin,--native-compiler-path=/arm-none-linux-gnueabihf-g++,-H:CAPCacheDir=/cap-cache/armv7a-linux-gnueabihf

Weitere Informationen zum Prozess des Cross-Compilierens und Debuggens finden Sie im folgenden Artikel:Erstellen und Debuggen von Java-nativen Images von MicroDoc GraalVM Embedded

Um die Anwendung zu erstellen, können Sie einfach den folgenden Befehl verwenden:

$ mvn -Pnative package

Als nächstes starten wir den PLCnext-Simulator. Der Simulator wird als Qemu-Image bereitgestellt. Der Simulator begrüßt uns mit der folgenden Zeile:

PLCnext Linux 2023.0 sim-axcf1152 ttyAMA0
sim-axcf1152 login:

Die generierten Binärdateien können mit dem Befehl scp in die SPS kopiert werden Dadurch wird eine sichere Shell für die SPS geöffnet und die Binärdatei an das Zielsystem übertragen. Sie können die Anwendung mit dem folgenden Befehl starten:

$ ./application

Mit dem PLCnext-Cockpit-Client können wir auch einen Blick auf die aktuelle Speicher- und Speichernutzung werfen:

Wir interessieren uns jedoch auch für den Start und den Speicherverbrauch unserer einzelnen Anwendung im Vergleich zur Ausführung der Anwendung in einer Java-Laufzeitumgebung wie OpenJDK. Daher haben wir beide Werte gemessen, wie in der folgenden Tabelle dargestellt:

Startzeit (weniger ist besser), Speichernutzung (weniger ist besser)

Natives GraalVM-Image: 0,413 s, 87 MB

OpenJDK: 13 s, 128 MB

GraalVM Native Image bietet im Vergleich zu OpenJDK eine deutlich verbesserte Leistung sowohl hinsichtlich der Startzeit als auch der Speichernutzung und zeigt damit seine Wirksamkeit bei der Optimierung des Ressourcenverbrauchs für eine effiziente Anwendungsbereitstellung.

Zusammenfassung

Der Einsatz von Java auf der Steuerungsebene wie bei einer SPS hat mehrere Vorteile. Erstens gibt es keinen technologischen Schnitt zwischen der Überwachungsebene und der Kontrollebene. Dieselben Mitarbeiter können Anwendungen implementieren und vom Java-Ökosystem und den verfügbaren Tools profitieren. Zweitens ist die GraalVM in der Lage, Java-Code als native Anwendungen auf eingebetteten Geräten wie 32-Bit- und 64-Bit-ARM- und x86-Prozessoren zu kompilieren. Somit müssen sich Ihre Entwickler nicht um die zugrunde liegende Architektur kümmern und können Ihre Anwendung in einer objektorientierten Hochsprache implementieren. Drittens haben wir dank der Container-Unterstützung von PLCnext von Phoenix Contact Zugriff auf die Schnittstellen der SPS direkt in derselben Hardwarekomponente und können die starren Hierarchien in den aktuellen Anwendungen der Fertigungsindustrie durchbrechen.

Hinweis:

Der Makers Blog zeigt Anwendungen und User Stories von Community-Mitgliedern, die nicht von Phoenix Contact getestet oder überprüft wurden. Die Nutzung erfolgt auf eigene Gefahr.