Les architectures système MAX se distinguent principalement par la manière dont la création et l’affichage des tableaux de bord sont gérés.
Lorsque la création et l’affichage des tableaux de bord sont entièrement gérés localement, on parle d’architecture périphérique.
– L’architecture la plus simple implique un seul dispositif périphérique, qui met en œuvre l’ensemble des services localement, sans connexion dans le cloud ; l’affichage se fait via le panneau de la machine ou le PC local
– Une évolution de l’architecture précédente implique une connexion dans le cloud, permettant l’installation de dockers sur l’appareil périphérique par le biais du service Portainer géré par le MAX Control Center.
– Une généralisation plus poussée de l’architecture périphérique implique l’installation de plusieurs dispositifs périphériques (par exemple, un par machine) ; les fonctions d’authentification, d’historisation, back-end et front-end peuvent être centralisées sur un seul appareil au niveau de l’usine.
Les architectures de périphérie sont particulièrement adaptées aux applications critiques et aux volumes élevés d’échange de données. En revanche, ils nécessitent plus de matériel au niveau local et sont un peu plus complexes à configurer.
On parle d’architecture hybride avec une composante « cloud » lorsque la création et la visualisation des tableaux de bord s’effectuent sur le web. Les données sont collectées auprès d’un ou de plusieurs dispositifs périphériques et transférées dans le cloud.
Il existe toujours deux couches cloud : l’une appartenant au client, où les données sont stockées, et l’autre gérée par 40Factory pour le compte de Gefran, où les modules MAX sont mis en œuvre. De cette manière, les données restent toujours sous le contrôle du client, tandis que la gestion des applications MAX est centralisée, ce qui garantit une disponibilité maximale et une mise à jour continue. Comme les deux couches sont mises en œuvre sur Microsoft Azure, la communication inter-cloud est rapide et facile à configurer.
Le mode d’accès cloud est particulièrement adapté aux parcs de machines géographiquement distribués et permet de réduire l’infrastructure matérielle mise en œuvre dans l’usine.

La plate-forme G-Mation est particulièrement bien adaptée à la mise en œuvre de MAX en mode périphérie complète (full edge) et en mode hybride.
Tout d’abord, l’architecture en docker permet d’implémenter et de mettre à jour facilement les applications dockerisées MAX, même sur des machines déjà en service.
De plus, l’architecture du serveur web de G-Mation, grâce à la technologie NGINX, permet de gérer des backends supplémentaires, en plus de celui intégré à l’automate pour le contrôle et la configuration de la machine.
En particulier, le backend contenu dans les dockers MAX permet d’appeler l’application et ses modules directement sur le panneau de l’opérateur G-Mation, basé sur la technologie Web.
Il suffit d’ouvrir une nouvelle fenêtre dans le navigateur de votre ordinateur personnel.
Un autre des principaux avantages de l’intégration de MAX à G-Mation est l’accès direct aux données de l’automate : un docker « collecteur de données » a été mis en place pour associer directement les variables de l’automate à la base de données interne de MAX, augmentant ainsi la vitesse d’accès aux données et éliminant la nécessité de programmer la communication sur des protocoles externes à l’automate.
En ce qui concerne la mise en œuvre hybride avec accès dans le cloud, la disponibilité d’un VPN dockerisé directement sur l’automate G-Mation vous permet d’accéder à la plateforme cloud MAX en toute sécurité, sans avoir à passer par des passerelles supplémentaires.
Pour une mise en œuvre de type périphérie complète (full edge), les 8 Go de mémoire et l’architecture d’UC multicœur vous permettent de déployer localement de nombreuses fonctions MAX sans ralentir le contrôle des machines de quelque manière que ce soit.

Dans certaines configurations de chaînes de production, il peut être utile de configurer un seul dispositif périphérique pour gérer plusieurs machines.
Ce dispositif périphérique peut être mis en œuvre avec un automate programmable embarqué sur l’une des machines, ou comme un PC industriel indépendant.
Dans cette configuration, des flux de communication doivent être établis entre toutes les machines et l’appareil périphérique.
En particulier, les dispositifs périphériques MAX se connectent aux automates programmables à l’aide d’une série de protocoles d’automatisation standards. Ces protocoles, dont Modbus, OPC Unified Architecture (OPC UA) et EtherNet/IP, sont conçus pour assurer un échange de données transparent entre différentes plates-formes matérielles et logicielles.
La base de la communication entre les périphériques MAX et les automates est essentiellement unidirectionnelle. Cette approche se concentre principalement sur la lecture des données des automates programmables vers les appareils périphériques MAX. L’importance de la communication en lecture seule réside dans sa capacité à minimiser le risque d’interruptions involontaires des opérations de l’automate programmable.
Il existe également des scénarios d’application qui requièrent que les périphériques MAX communiquent de manière bidirectionnelle avec les automates programmables. La gestion des commandes de production est une application essentielle de la communication bidirectionnelle. Ce type de communication bidirectionnelle n’est exécutée que si le module d’exécution des tâches est configuré dans la configuration MAX.