Image native Java et GraalVM :renforcer la connectivité des bases de données dans les applications de fabrication

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

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

Ce passage brutal d’un niveau hiérarchique élevé à un niveau hiérarchique inférieur crée plusieurs problèmes. Des outils et des écosystèmes complètement différents sont nécessaires. Pour la mise en œuvre, il faut faire appel à des développeurs complètement différents avec une façon de penser différente pour mettre en œuvre une tâche. Des interfaces doivent être définies entre les deux mondes ou systèmes. Uniquement parce qu'il n'y a aucune possibilité de continuer avec un langage de programmation de haut niveau connu du niveau supervision au niveau contrôle. Cela a maintenant changé. En utilisant la technologie des conteneurs au niveau du contrôle dans un automate par exemple, nous sommes capables d'utiliser des langages de programmation comme Java à ce niveau hiérarchique et de briser les hiérarchies rigides.

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

Nous montrerons comment Java est disponible sur un PLCnext de Phoenix Contact 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 les informations pertinentes sur 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 des objets Java aux tables de base de données relationnelles, réduisant ainsi la quantité de code passe-partout nécessaire aux opérations de base de données. Hibernate fournit un haut niveau d'abstraction, permettant aux développeurs de travailler directement avec des objets plutôt qu'avec des requêtes SQL. Cela peut conduire à des cycles de développement plus rapides et à une réduction des efforts de développement. Hibernate élimine les différences entre les différents fournisseurs de bases de données, ce qui facilite le basculement entre les bases de données sans modifications significatives du code. Cet article décrit l'intégration d'Hibernate pour connecter les logiciels exécutés sur les automates aux bases de données.

Application Java moderne sur PLCnext

Afin de commencer à implémenter une application Java moderne, nous vous 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 allons démarrer notre application en utilisant le guide d'utilisation de Quarkus Hibernate ORM et Jakarta Persistence. Un exemple du code source peut être trouvé sur le projet github hibernate-orm-quickstart.

Nous allons commencer à modifier le code source de l'application. Nous pouvons changer la classe Java Fruit.java dans Event.java et ajoutez 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 informations d'identification 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
...

Au démarrage de l'application, 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 avec une interface web fonctionnant sur le port 8080 du 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.

Image native GraalVM

De nombreux développeurs pensent encore que Java nécessite un environnement d'exécution Java pour exécuter le Byte-Code 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 du code Java dans une application native. La compilation d'images natives de GraalVM offre une solution intéressante pour relever les défis du temps de démarrage et de la consommation de mémoire dans les applications Java, en particulier dans les environnements aux ressources limitées tels que les systèmes embarqués. En compilant les applications Java à l'avance en exécutables natifs, GraalVM réduit considérablement le temps de démarrage et la surcharge de mémoire par rapport à la compilation Just-In-Time (JIT) traditionnelle.

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

Afin de compiler en amont notre application Java ciblant l'automate AXC F 1152 , nous pouvons utiliser GraalVM de MicroDoc et configurer certaines options du 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 :Création et débogage d'images natives Java de MicroDoc GraalVM Embedded

Afin de créer 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 accueillera avec la ligne suivante :

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

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

$ ./application

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

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

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

Image native GraalVM : 0,413 s, 87 Mo

OpenJDK : 13 s, 128 Mo

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

Résumé

L'utilisation de Java au niveau du contrôle comme un automate présente de nombreux avantages. Tout d’abord, il n’y a pas de coupure technologique entre le niveau de supervision et le niveau de contrôle. La même main-d'œuvre peut mettre en œuvre 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 tant qu'applications natives sur des appareils embarqués tels que les processeurs ARM et x86 32 bits et 64 bits. Ainsi, vos développeurs n'ont pas besoin de s'occuper de l'architecture sous-jacente et peuvent implémenter votre application dans un langage orienté objet de haut niveau. Troisièmement, grâce à la prise en charge des conteneurs PLCnext de Phoenix Contact, nous avons accès aux interfaces de l'API directement dans le même composant matériel et pouvons briser les hiérarchies rigides dans les applications actuelles des industries manufacturières.

Remarque :

Le Makers Blog présente des applications et des témoignages d'utilisateurs de membres de la communauté qui ne sont ni testés ni examinés par Phoenix Contact. Utilisez-les à vos propres risques.