Java & GraalVM Native Image : Amélioration de la connectivité base de données dans les applications manufacturières

Le paysage actuel des applications dans les industries manufacturières est divisé en une hiérarchie rigide. En partant de la gestion utilisant des systèmes ERP, aux systèmes de planification utilisant MES, aux systèmes de supervision utilisant SCADA, jusqu'aux systèmes de contrôle réalisés avec des automates et systèmes de terrain tout en bas.

Alors que la plupart des systèmes pour la gestion, la planification et la supervision sont implémentés dans des langages de programmation orientés objet de haut niveau, les systèmes de contrôle sont implémentés complètement avec des langages de bas niveau, le C étant le langage de programmation dominant.

Ce changement brutal du haut niveau vers un niveau bas de hiérarchie crée plusieurs problèmes. Des outils et écosystèmes complètement différents sont nécessaires. Pour l'implémentation, des développeurs complètement différents avec une façon de penser différente doivent être engagés pour implémenter une tâche. Des interfaces doivent être définies entre les deux mondes ou systèmes. Uniquement parce qu'il n'y a pas de possibilité de continuer avec un langage de programmation de haut niveau connu du niveau de supervision au niveau de contrôle. Cela a maintenant changé. En utilisant la technologie des conteneurs sur le niveau de contrôle dans un automate par exemple, nous sommes capables d'utiliser des langages de programmation comme Java sur ce niveau de hiérarchie et de briser les hiérarchies rigides.

Java est un langage de programmation orienté objet de haut niveau largement utilisé. Il a une communauté dynamique et un écosystème de bibliothèques et frameworks qui fournissent des fonctionnalités supplémentaires, vous permettant de tirer parti d'outils et solutions existants pour construire votre application plus rapidement et efficacement.

Nous allons montrer comment Java est disponible sur un automate Phoenix Contact PLCnext pour simplifier le développement d'une application qui s'exécute sur PLCnext et communique directement avec une base de données pour récupérer et stocker des informations pertinentes pour l'application et les présenter sur une interface web. L'un des frameworks les plus populaires en Java est Hibernate. Il simplifie le processus de mappage d'objets Java vers des tables de base de données relationnelles, réduisant la quantité de code boilerplate nécessaire pour les opérations de base de données. Hibernate fournit un haut niveau d'abstraction, permettant aux développeurs de travailler avec des objets plutôt que des requêtes SQL directement. Cela peut conduire à des cycles de développement plus rapides et à une réduction de l'effort de développement. Hibernate abstrait les différences entre les différents fournisseurs de bases de données, facilitant le passage d'une base de données à une autre sans changements de code significatifs. Cet article décrit l'intégration de Hibernate pour connecter des logiciels s'exécutant sur des automates à des bases de données.

Application Java moderne sur PLCnext

Pour commencer à implémenter une application Java moderne, nous recommandons d'utiliser des frameworks d'application comme Quarkus ou Spring Boot. Ces frameworks simplifient la configuration du projet, la gestion des dépendances.

Pour cet exemple, nous commencerons notre application en utilisant le guide Quarkus « Using Hibernate ORM and Jakarta Persistence ». Un exemple du code source se trouve sur le projet GitHub hibernate-orm-quickstart.

Nous commencerons par modifier le code source de l'application. Nous pouvons changer la classe Java Fruit.java en Event.java et ajouter un nouveau champ date.

Exemple de code Event.java :

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

Nous pouvons configurer l'URL de la base de données et les identifiants en modifiant le fichier application.properties

Exemple de 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 ... 

Lorsque l'application démarre, une table dans la base de données sera créée et initialisée si nécessaire. Après le démarrage, nous pouvons interagir avec la base de données via une interface web s'exécutant sur le port 8080 sur le PLCnext :

Gardez à l'esprit que tout cela se passe au niveau de contrôle de notre hiérarchie sans aucun système supplémentaire entre les deux.

GraalVM Native Image

De nombreux développeurs croient encore que Java nécessite un Java Runtime Environment pour exécuter du bytecode Java et ne fournit pas les performances nécessaires. Ce n'est plus le cas pour les applications embarquées. Dans cet exemple, nous utilisons la technologie GraalVM Native Image pour compiler le code Java en une application native. La compilation d'image native de GraalVM offre une solution convaincante pour relever les défis du temps de démarrage et de la consommation mémoire dans les applications Java, particulièrement dans les environnements à ressources limitées tels que les systèmes embarqués. En compilant les applications Java ahead-of-time (à l'avance) en exécutables natifs, GraalVM réduit significativement le temps de démarrage et la surcharge mémoire par rapport à la compilation Just-In-Time (JIT) traditionnelle.

Le GraalVM de MicroDoc a la capacité unique de générer des binaires pour les dispositifs embarqués. Au moment de la rédaction de ce tutoriel, GraalVM prend en charge les processeurs ARM 32 bits et 64 bits et x86.

Pour compiler notre application Java ahead-of-time ciblant le PLC AXC F 1152, nous pouvons utiliser le GraalVM de MicroDoc et configurer certaines options de compilateur dans le fichier application.properties.

... 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 

Vous trouverez plus d'informations sur le processus de compilation croisée et de débogage dans l'article suivant : Building and debugging Java native images of MicroDoc GraalVM Embedded

Pour construire l'application, vous pouvez simplement utiliser la commande suivante :

$ mvn -Pnative package 

Ensuite, nous démarrons le simulateur PLCnext. Le simulateur est fourni sous forme d'image qemu. Le simulateur nous accueille avec la ligne suivante :

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

Les binaires générés peuvent être copiés sur le PLC avec la commande scp qui ouvre un shell sécurisé vers le PLC et transfère le binaire vers le système cible. Vous pouvez démarrer l'application en utilisant la commande suivante :

$ ./application 

En utilisant le client PLCnext Cockpit, nous pouvons également jeter un œil à l'utilisation actuelle de la mémoire et du stockage :

Cependant, nous sommes également intéressés par le temps de démarrage et la consommation mémoire de notre application unique par rapport à l'exécution de l'application dans un Java Runtime Environment comme OpenJDK. Ainsi, nous avons mesuré les deux valeurs comme indiqué dans le tableau suivant :

Temps de démarrage (moins c'est mieux), Utilisation mémoire (moins c'est mieux)

GraalVM Native Image : 0,413 s, 87 Mo

OpenJDK : 13 s, 128 Mo

GraalVM Native Image offre des performances significativement améliorées en termes de temps de démarrage et d'utilisation mémoire par rapport à OpenJDK, démontrant son efficacité pour optimiser la consommation de ressources pour un déploiement d'application efficace.

Résumé

L'utilisation de Java au niveau de contrôle comme un automate présente de multiples avantages. Tout d'abord, il n'y a pas de rupture technologique entre le niveau de supervision et le niveau de contrôle. La même main-d'œuvre peut implémenter des applications et bénéficier de l'écosystème Java et des outils disponibles. Deuxièmement, GraalVM est capable de compiler du code Java en applications natives sur des dispositifs embarqués comme les processeurs ARM 32 bits et 64 bits et x86. Ainsi, vos développeurs n'ont pas besoin de se soucier de l'architecture sous-jacente et peuvent implémenter votre application dans un langage orienté objet de haut niveau. Troisièmement, grâce au support des conteneurs de Phoenix Contact PLCnext, nous avons accès aux interfaces de l'automate directement dans le même composant matériel et pouvons briser les hiérarchies rigides dans les applications des industries manufacturières actuelles.

Note :

Le blog Makers présente des applications et des histoires d'utilisateurs de membres de la communauté qui ne sont pas testés ou revus par Phoenix Contact. Utilisez-les à vos propres risques.