La version 2.5 de la Flashbox est déployée sur de nombreux sites. C’est une version très stable et dont les performances n’ont jamais été mises en défaut. En conséquence, la question se pose de la migration vers la Flybox. Nous allons nous efforcer de donner des éléments de réponses.
Pourquoi avoir changé de nom ?
La Flybox est le fruit de l’expérience Flashbox, dont elle est en fait la version 3. Cette version 3 est plus qu’une évolution ou amélioration. L’ensemble du code a été réécrit, et l’organisation générale a été refondue pour notamment obtenir une ouverture sans limite grâce aux modules et faciliter la mise en place en supprimant la dépendance de Sql Server. A ce titre, la version 3 est une plateforme neuve qui outre les caractéristiques de la version 2.5 propose une nouvelle révolution dans l’approche de la supervision industrielle et tertiaire. Il était nécessaire et somme toute logique de faire évoluer le nom de la plateforme afin de bien marquer cette révolution.
La migration d’applications Flashbox en Flybox est-elle possible ?
Oui, un soin particulier a été apporté pour permettre une migration sans risque d’applications Flashbox 2.5. Pour cela, il faut distinguer la partie serveur de la partie cliente des applications.
Pour la partie serveur, la première étape consiste à adapter la liste des variables de communication temps réel. Ces variables sont associées à des équipements Modbus, OPC, ou Twincat. Avec la Flashbox 2.5, c’est l’outil Flashbox Studio qui permettait la saisie de ces équipements et ces variables. Mais le format d’enregistrement utilisé était le format CSV, fort pratique pour ce type de déclarations notamment pour les imports/exports. Dans les nouveaux modules de communication Flybox, aussi bien en Modbus qu’en OPC, ce principe a été conservé, c’est-à-dire que ce sont toujours des fichiers CSV qui définissent les variables. Le format des colonnes a certes évolué mais la transition est naturelle. De même pour la gestion des alarmes et évènements, le principe des niveaux et modèles d’état est toujours en place dans les contrôleurs Flybox ce qui facilite en compatibilité vers le haut des applications.
Pour la partie cliente, il ne s’agit pas de refaire ou adapter les vues d’exploitation mais de changer la librairie de communication temps réelle entre l’application web et le contrôleur Flybox. Ce changement de librairie est mineur et n’impacte que fort peu le cœur de l’application. Pour les interfaces développées pour Flash Player avec Flash Builder, la déclaration initiale des variables dans le code source n’est plus obligatoire (elle était automatiquement générée par Flashbox Studio).
Si des développements externes mais liés au Data Service de la Flashbox 2.5 ont été mis en place dans une application, il convient d’intégrer le code source de ces développements dans des modules Flybox.
Dans quel cas faut-il envisager la migration ?
Pour toute application de supervision susceptible d’évoluer dans le temps avec de nouveaux besoins, il est fortement préconisé de profiter d’une de ces évolutions pour migrer en Flybox. Le coût de migration sera faible car il sera fait en parallèle de l’évolution et les tests de bon fonctionnement seront communs.
Comment s’y prendre pour préparer et réaliser la migration en Flybox ?
Bien entendu, le mieux est de se rapprocher du service commercial de LInaware qui guidera les choix et la méthode. Pour l’envisager en toute sécurité, Linaware peut proposer la prise en charge de la migration en dehors de toute évolution fonctionnelle. Cela apporte une garantie de réussite sur laquelle Linaware s’engage. Il est entendu que les développeurs en charge de l’application doivent être formés au développement d’application Flybox pour prendre en compte la migration.
Quels sont les risques de la migration ?
Les risques sont mineurs mais cependant il serait présomptueux de les négliger. Chaque application a ses singularités qu’il faut prendre en compte et les tests de bon fonctionnement après migration doivent être exhaustifs faute de quoi c’est en exploitation que des disfonctionnements issus d’erreurs dans la migration peuvent surgir. Le banc de test que Linaware utilise dans le cadre de son organisation d’assurance qualité apporte une réponse à ces risques.
Comment basculer en exploitation l’application Flashbox 2.5 en Flybox ?
Ici les avantages considérables apportés par l’organisation matérielle sont conservés. Une carte Compact Flash est préparée en amont avec l’application Flybox fruit de la migration et lors de basculement, il suffit de la mettre en place en lieu et place de la précédente dans la box industrielle. En cas de problème quelconque, il est ainsi très simple et très rapide de relancer à l’application Flashbox en replaçant la carte Compact Flash précédente. Le temps de basculement est donc tout au plus de quelques minutes. Cela est à comparer avec les solutions conventionnelles qui utilisent les PC comme organes essentiels et dont les migrations sont toujours un cauchemar qui finit mal en général.