Mes premiers pas

Introduction

Vous venez d’acquérir le produit logiciel DevI/O et vous souhaitez maintenant l’installer et le mettre en œuvre dans votre contexte de communication industrielle. Ce manuel, découpé en quatre grands chapitres, est fait pour vous y aider. A noter que ce document, qui doit être le point de départ de votre lecture et de votre apprentissage, référence d’autres documents « produit », que nous vous conseillons de consulter par la suite, pour accéder à des compléments d’informations techniques et approfondir certaines thématiques.

Le premier chapitre de ce manuel débute par une présentation des contextes dans lesquels le produit DevI/O peut être mis en œuvre, ce qui permet d’introduire dans la continuité, l’architecture fonctionnelle du produit avec ses différentes couches logicielles. Les concepts généraux seront ensuite distillés, à mesure de l’avancée dans la présentation des différents composants mis à disposition au sein du produit : le serveur DevI/O, DevI/O Studio et le module DevI/O configuration XML. La notion de continuité de service, vitale à tout projet, sera également traitée dans ce chapitre.

Le deuxième chapitre est consacré à l’installation du produit DevI/O. Nous listons les quelques prérequis avant de dérouler la procédure d’installation. Une partie relative à l’activation de la licence logicielle du produit est également abordée.

Après l’installation, le troisième chapitre explique comment mettre en œuvre et exploiter le produit DevI/O. Dans ce chapitre, vous verrez comment créer et activer votre premier projet, à travers la mise en œuvre du composant DevI/O Studio, comment démarrer le serveur DevI/O avec ce premier projet et enfin, comment ajouter de nouveaux équipements et de nouvelles données dans ce projet courant, à l’aide du module DevI/O configuration XML.

Le quatrième chapitre aborde les parties liées à l’administration système et à l’administration applicative. Dans ce chapitre, vous apprendrez à sauvegarder et restaurer un projet courant et à mettre en place des traces afin d’analyser les divers flux de communication mis en œuvre.

Présentation du produit DevI/O

Le produit DevI/O est un frontal de communication multi-canal, multiprotocole et multi-application (Cf. figure 1).

Il est mis en œuvre dans des projets d’acquisition de données, d’interconnexion d'équipements et d’applications, de concentration de données, de traitement et de stockage de l'information, de sécurisation des échanges et de management des parcs d’équipements.

Il adresse des applications de supervision, d’Hypervision, de contrôle-commande, de télécollecte de données, de télégestion d'équipements, de télédiagnostic ou de télémaintenance, dans lesquelles la nature des équipements et des applications connectés est totalement hétérogène en termes de moyens de communication et d'échange.

Figure 1 : DevI/O - frontal de communication ou « middleware »

En synthèse, le produit DevI/O :

• unifie l’interfaçage avec les couches « hautes » (superviseur, MES, reporting, entrepôt de données, services de Cloud computing) en s’appuyant sur des protocoles ouverts, sécurisés et standardisés. Le produit DevI/O peut être serveur OPC DA/UA et/ou client MQTT producteur ou encore s’interfacer à des bases de données (système de gestion de bases de données relationnelles classique ou Big Data Hadoop),
• fédère les différents canaux de communication et protocoles propriétaires des constructeurs. Le frontal d’acquisition facilite la gestion quotidienne d’un parc d’équipements. Il assure l’interface avec plus de 300 protocoles : des automates aux IoT (Internet of Things ou Objets connectés) ; il gère les données historiques en temps réel.

Architecture fonctionnelle DU Produit

Pour répondre aux différents contextes « Métier » évoqués sur la figure 1, qui nécessitent tous d’interconnecter diverses applications à divers équipements, le produit DevI/O s’appuie sur différentes couches de communication : les interfaces de type canal, les interfaces d’échanges et les interfaces applicatives, dont le fonctionnement est dicté et régi par le moteur du produit : le serveur DevI/O (Cf. figure 2). A noter que cette architecture fonctionnelle permet de rendre indépendantes les évolutions des couches matérielles et des couches logicielles.

Figure 2 : Architecture fonctionnelle du produit DevI/O

En fonction du contexte, il sera possible de sélectionner les interfaces les mieux adaptées à la situation (Cf. figure 3). Par exemple, pour communiquer avec un même équipement, plusieurs interfaces de type canal (série et TCPIP, par exemple) pourront être configurées et seront sollicitées en fonction du besoin. Autre exemple, pour accéder aux équipements, le produit DevI/O propose un large choix d’interfaces d’échanges ou protocoles (comme Modbus et BACnet, par exemple), dans lesquels vous pourrez puiser. Enfin, vous pourrez également diriger les flux d’informations vers différentes applications (client OPC UA et broker MQTT, par exemple).

Figure 3 : Mise en œuvre des interfaces

UN projet et DES composants logiciels

A la lecture des précédentes parties, vous comprenez maintenant qu’une des premières tâches à réaliser sera de configurer les différentes interfaces dont vous aurez besoin au sein de votre application globale. Et cette première étape va s’effectuer au sein d’un élément central : le projet DevI/O. Dans cette partie nous évoquerons ce projet, en présentant trois composants du produit, qui vont participer à tour de rôle, à la construction, l’exploitation et l’enrichissement du projet.

serveur DevI/O

Le serveur DevI/O est le cœur du produit. Il démarre et supervise toutes les interfaces ou processus DevI/O et assure les échanges entre applications et équipements. Avant d’être démarré, le serveur DevI/O a besoin qu’un projet ait été défini et sélectionné.

Le serveur DevI/O est normalement démarré en mode service quand une licence logicielle a été activée (Cf. le chapitre 2, relatif à l’installation du produit). Dans ce cas, tous les processus sont automatiquement démarrés quand l’ordinateur démarre. Il peut également être démarré en mode console (sur le bureau), par exemple durant une session de formation pour laquelle nous utilisons une licence de démonstration. Cette licence de démonstration autorise une utilisation du serveur DevI/O pendant une durée d’une heure, à l’issue de laquelle, il faut manuellement relancer le serveur pour pouvoir l’utiliser à nouveau.

Le serveur DevI/O est un serveur d’acquisition et de traitement des informations qui sont issues des objets/équipements distribués sur le terrain. D’une façon générale, il permet de mettre les informations acquises ou élaborées à la disposition des applications, permettant ainsi la réalisation d’architectures distribuées mettant en œuvre des interfaces équipements et des protocoles divers.

Historiquement un serveur OPC ...

Le serveur DevI/O propose une interface OPC (DA et UA) qui assure une parfaite compatibilité avec l’ensemble des superviseurs actuels du marché. Les fonctions d’OPC permettent la remontée des données horodatées en les « rejouant » au travers de tags OPC dédiés. Il fédère, pour les applications, des informations de tous types (E/S analogiques entières ou réelles, Tout Ou Rien, compteurs, messages, tableaux d’informations, fichiers, historiques), en provenance de tous les objets (automate, sondes, GTB/C, IoT) accédés au moyen de tous les canaux de communication (RS232, RS485, RS422, Ethernet TCP/IP, RTC, RNIS, GSM, GPRS, SMS ou réseaux large bande comme Sigfox ou LoRa). Les médias de communication et le serveur peuvent être redondés. Les entrées / sorties échangées peuvent être utilisées pour l’élaboration de variables calculées par le serveur (résultats de mises à l’échelle, de dépassement de seuil, de comptage, de chronométrage, de combinatoires, …).

Le serveur DevI/O peut fonctionner en complète autonomie tel un automate qui se connecte et échange des données en continu. Il peut également être télécommandé par l’application. Des points OPC sont automatiquement créés, lors de la configuration, pour permettre un contrôle total de l'état des connexions, des échanges avec les retours nécessaires des différents statuts. Il est possible de déclencher des appels, de déclencher des relevés d'historiques, d'être averti d'un appel entrant ou du changement d'état d'un modem.

... mais bien plus aujourd’hui

Le serveur DevI/O gère des données structurées et propose différentes manières de les rendre disponibles aux applications tout en les homogénéisant. Certaines typologies de données ne se prêtent pas facilement à la présentation et aux accès des données fournis par OPC ; il s’agit des flux et des listes :

• les historiques, liste de valeurs horodatées à la source, remontés par paquet. Ces données peuvent être présentées, séquentiellement, au travers de l’interface OPC en respectant l’horodate associé à chaque échantillon. Une option permet de rejouer les données dans le point OPC standard ou de dupliquer le point OPC en point temps réel et point historique. Ces données ne reflétant en rien le temps réel, le seul intérêt est d’historiser ces données au niveau applicatif. C’est pourquoi, le produit DevI/O propose des méthodes directes pour remonter ces flux, en générant des fichiers ou en déposant les informations directement en base de données (via le langage SQL).

• les programmes horaires, listes de « plannings » récurrents et exceptionnels, connus de l’équipement, gérés en lecture/écriture. Il ne s’agit pas d’informations temps réel et DevI/O propose une description XML unifiée qui peut être transmise aux applications par des fichiers ou par une arborescence dédiée en OPC UA.

  Les applications se connectent au travers des interfaces applicatives, comme OPC DA ou OPC UA, mais DevI/O met à disposition d’autres moyens d’échanger des informations avec les applications :

• interface sockets TCP/IP,

• interface avec des bases de données issues de systèmes de gestion de bases de données relationnelles « classiques », suivant un schéma spécifique à DevI/O ou adapté à l’application avec un module personnalisé de conversion,
• interface avec les entrepôts de données Big Data via Kafka ou WebHDFS (Apache Hadoop),
• ou encore, interface MQTT producteur.

Des fonctions de base ...

Les services rendus par le serveur DevI/O sont banalisés et communs à l’ensemble des équipements :

• connexion et déconnexion des équipements distants et / ou des applications distantes par l'intermédiaire des interfaces d'échanges,
• gestion de la liste des ressources disponibles, gestion des pools, connexion entre les protocoles et les moyens de connexion, gestion des voies de repli, gestion des stratégies de ré-essais,
• lecture / écriture des informations équipements : entrées / sorties, historiques, programmes horaires, fichiers, horloges de datation en modes synchrone, asynchrone, cyclique ou non sollicité en lecture,
• élaboration de variables de types physique (mises à l'échelle des entrées / sorties), logique, compteur, chronomètre, calculées à partir d'expressions mettant en œuvre des entrées / sorties ou d'autres variables,
• agrégateur de données de provenances diverses,
• mise en cache des données temps réel, stockage des historiques, archivage de l’ensemble des données,
• détection des changements des entités gérées dans le projet (entrées / sorties, variables, historiques, fichiers, horloges, statuts de communication), génération d’alarmes,
• importation de données historiques d’équipements non connectés au système (équipements virtuels), par traitement de fichier de données au format XML,
• traitement d’évènements permettant de déclencher des actions en fonction des changements d'états d'entités du projet,
• routage d'informations, dans le cas où l'application est une passerelle d’échange entre des équipements homogènes ou hétérogènes,
• inhibition hiérarchisée des traitements sur certaines entités du projet (exemple : inhibition des alarmes pendant une intervention de maintenance),
• archivage des évolutions de certaines entités du projet, les fichiers d'archives tracent les changements de valeurs, d'états, de statuts des entités concernées et sont directement exploitables par des tableurs,
• gestion de la configuration à chaud,
• fonction d’autodécouverte des équipements pour les protocoles supportant cette fonctionnalité,
• gestion de la continuité de service, « chiens de garde » applicatifs et systèmes, redondance à froid, redondance à chaud.

... au device management

Enfin, suivant les capacités des objets connectés, le produit DevI/O propose des fonctions de gestion des équipements ou objets : mise à l’heure, niveau de batterie, qualité du signal, gestion des versions, localisation.

Capacités évolutives

Un serveur DevI/O peut gérer jusqu’à 100 000 entités. Une entité est tout objet déclaré dans le projet comme, par exemple, un équipement, une E/S, une variable, une voie de communication, un protocole. Il faut prévoir un surnombre des entités par rapport aux variables supervisées : par exemple, certaines variables nécessitent la définition d’un minimum et d’un maximum, d’autres la définition de seuil. Ce rapport est à évaluer en fonction des équipements et des variables supervisés. Enfin, pour les configurations nécessitant des architectures distribuées, il est possible de mettre plusieurs serveurs DevI/O en parallèle.

DevI/O studio

C’est l’outil dédié à la configuration manuelle et hors-ligne du projet. La configuration est l’étape de déclaration et de description de l’ensemble des entités mises en œuvre dans le projet. A chaque modification apportée au sein du projet, DevI/O Studio effectue automatiquement un enregistrement de la configuration sur le disque, sous forme de fichiers binaires. Il est possible de créer, sous des répertoires différents, plusieurs projets sur une même machine, en revanche, à un instant donné, seul un de ces projets pourra être défini en tant que projet courant et utilisé par le serveur DevI/O. Pour des raisons de performance, le serveur DevI/O utilise une copie mémoire du projet appelée base binaire.

Un projet DevI/O est composé de différentes entités parmi lesquelles : les canaux de communication, les protocoles et les équipements, entités que nous avons déjà évoquées précédemment et que nous nous proposons maintenant de décrire succinctement.

Equipement

L’équipement est identifié par un nom, une adresse et des moyens, physique et logique, de connexion. L’équipement est caractérisé par son statut de communication qui reflète les échanges en cours : connecté / déconnecté au sens du canal de communication ou connecté / déconnecté au sens du protocole, par exemple. Des stratégies, qui s’appuient sur ce statut, permettent de passer d’un moyen de connexion à un autre : différentes « routes » peuvent ainsi être définies.

Un équipement peut contenir :

• des entrées / sorties échangées (tous types de format, avec possibilité de tableaux), ces dernières pouvant être regroupées au sein de blocs adaptés au protocole et au type d’accès ; une formule de mise à l’échelle peut être associées aux E/S,
• des historiques,
• des fichiers (programmes, fichiers de paramétrage, plannings…),
• des statuts,

• une horloge interne.

  Un équipement est associé à un protocole qui doit être défini au préalable.

Protocole

Un protocole propose les services suivants :

• connexion / déconnexion logique avec les équipements (identification, contrôle d’accès, …),
• lecture et écriture des E/S et des fichiers,
• lecture des historiques,
• gestion des échanges en modes normal et dégradé,
• gestion de la mise à l’heure des équipements,

• enregistrement des échanges au sein de fichiers.

  Il est en mesure de traiter les connexions déclenchées à l’initiative du serveur et/ou des applications (appels sortants) mais aussi les connexions déclenchées à l’initiative des équipements (appels entrants). Les données sont échangées sur demande du serveur ou de manière non sollicitée, lorsqu’elles sont spontanément transmises par l’équipement. Toutes les données sont « horodatées à la source ». Chaque information est caractérisée par sa valeur, son statut, son horodatage.

Canaux de communication

Les interfaces de gestion des canaux sont indépendantes des protocoles installés. Elles sont partagées entre ces derniers dynamiquement, en fonction des sessions de connexion à établir. Ces interfaces assurent les services suivants :

• connexion et déconnexion « physique » (typiquement une phase de numérotation en RTC), avec reconfiguration dynamique des matériels le cas échéant,
• émission / réception de flux d’octets,
• gestion des synchronisations liées aux matériels considérés (signaux de jonction),
• enregistrement des échanges au sein de fichiers traces,
• surveillance d’activité, c’est-à-dire suivi des échanges durant la connexion,

• surveillance de temps de session maximal ou « timeout » de session.

  Les moyens de communication de type modems (ISDN, RTC, GSM, SMS, GPRS, …) sont organisés en pools ou grappes afin de paralléliser la capacité de sortie.

  Tous les canaux (IP ou modem) sont sortants et entrants (phase d’établissement du canal).

  Les canaux sont caractérisés par leur statut de communication, ce dernier reflétant les échanges en cours (connecté / déconnecté, échanges corrects / incorrects).

  En synthèse : DevI/O Studio est utilisé pour créer, en particulier, le projet DevI/O initial avec ses diverses interfaces (canal, protocole et application). Il permet de sélectionner (si plusieurs projets sont disponibles) le projet DevI/O courant, qui sera activé au moment du lancement du serveur DevI/O. Le projet DevI/O initial est préparé hors-ligne et est ensuite chargé en mémoire au démarrage du serveur DevI/O.

  Note : Les projets sont mémorisés sous la forme de fichiers et sauvegardés sur le disque. L’utilisateur veillera donc à la disponibilité d’un espace de stockage suffisant sur le disque. L’espace utile à la création d’un projet dépend essentiellement du nombre d’entités mises en jeu pour les acquisitions (nombre de variables, d’équipements, …).

DevI/O configuration xml

C’est l’outil dédié à la configuration en ligne des équipements. Ce module est l’un des moyens simples, mis à votre disposition, d’ajouter de nouveaux équipements « à chaud », pendant que le serveur DevI/O est démarré.

Le module de configuration XML de DevI/O est une application optionnelle tierce venant se greffer au serveur DevI/O, afin de configurer de nouveaux équipements sur un projet DevI/O.

A travers son interface graphique, il permet notamment de :

• créer et paramétrer un équipement et réaliser une autodécouverte, c'est-à-dire obtenir le paramétrage de l’équipement en communiquant directement avec lui,
• créer et paramétrer un équipement et réaliser un import, c'est-à-dire obtenir le paramétrage de l’équipement indirectement en s’appuyant sur un fichier (qui peut être issu d’outils de configuration du constructeur),
• réaliser le paramétrage complet de l’équipement dans le serveur DevI/O par autoconfiguration, en utilisant les résultats des étapes d’autodécouverte ou d’import,
• supprimer un équipement,

• réaliser des opérations de lecture / écriture des programmes horaires d’un équipement.

  Il permet en outre de réaliser les opérations suivantes :

• gérer un historique des configurations d’équipements auto-découverts ou importés,

• convertir un paramétrage d’équipement dans un format XML pouvant être intégré directement dans un superviseur.

en synthese

Pour fonctionner, le produit DevI/O a besoin qu’un premier projet soit créé et sélectionné. Cette première étape est réalisée à l’aide du produit DevI/O Studio ; elle permet essentiellement de définir les différentes interfaces de communication que vous souhaitez mettre en œuvre dans le cadre de votre projet. Une fois sélectionné et activé, ce projet sera ensuite utilisé par le serveur DevI/O, véritable chef d’orchestre du produit, qui démarre et gère les différentes interfaces de communication préalablement définies. Enfin, afin d’enrichir ce premier projet et d’ajouter de nouveaux équipements (avec leurs variables) en ligne, c’est-à-dire pendant l’exécution du serveur DevI/O, le module DevI/O configuration XML pourra être mis à contribution.

	Un quatrième outil nommé DevI/O Tray ou icône de notification DevI/O, accessible via la barre des tâches, est également disponible : il permet d’accéder à un menu de démarrage du serveur DevI/O (en mode service ou bureau) et de démarrage de DevI/O Studio.

A propos de la continuite de service

Les aspects de monitoring et de continuité de service sont intégrés au produit DevI/O. DevI/O propose plusieurs niveaux de sécurisation : cette partie permet d’en présenter les concepts.

autosurveillance

Une solution DevI/O est constituée de différents modules fonctionnels qui sont organisés par le moteur fonctionnel central : le serveur DevI/O. Ce dernier surveille l'état de ces différents modules : il est capable de détecter d’éventuelles défaillances et de prendre les actions correctives qui s’imposent comme la réinitialisation d’une connexion ou la relance d’un processus.

Cette surveillance est disponible pour les applications clientes de la solution DevI/O, sous la forme d’un « chien de garde » OPC. DevI/O fournit une information OPC qui change régulièrement. Le client OPC, constatant que cette information ne bouge plus, peut déclencher une alerte et relancer le serveur OPC DevI/O, aussi bien sur la machine initiale que sur une autre machine.

monitoring du client

Le serveur DevI/O a la capacité de surveiller un « chien de garde » client. Ainsi, il peut surveiller l’activité d’un ou de plusieurs clients OPC et, en fonction des options positionnées, libérer des connexions ou s’arrêter suite à la disparition du client concerné.

utilisation de machines virtuelles

Les solutions DevI/O sont entièrement compatibles d’un fonctionnement en machine virtuelle. En plus des avantages apportés en termes de gestion, de déploiement ou de coût, cette technologie peut aussi être utilisée pour servir de secours en cas de perte d’un serveur complet.

Pour que cette solution fonctionne, il faut sauvegarder régulièrement la configuration de la machine virtuelle, en particulier la configuration DevI/O. En redémarrant le serveur DevI/O avec la sauvegarde du projet, il pourra reprendre son travail d'acquisition. Cependant, il est important de noter que les données en temps réel ou les variables courantes seront réinitialisées, et les index de lecture des historiques seront perdus. Ainsi, DevI/O devra remonter l'intégralité des historiques disponibles lors de la prochaine demande de relève.

redondance à froid

Les « chiens de garde » applicatifs permettent aux clients OPC de valider périodiquement que le ou les serveurs DevI/O sont fonctionnels. Le serveur DevI/O fournit une information OPC qui change régulièrement. Si le client OPC (i.e., l’application) constate que cette information n’évolue plus, il peut déclencher une alerte et/ou relancer le serveur OPC DevI/O par les mécanismes intégrés à la partie DCOM d’OPC DA, aussi bien sur la machine initiale que sur une autre machine.

Dans ce mode de fonctionnement, la configuration statique de DevI/O est conservée, si la relance s’effectue sur la même machine ou si le répertoire de travail de DevI/O est partagé dans le cas d’une relance sur une autre machine. Les données temps réel et les index de lecture des historiques ne sont pas conservés et les variables OPC repartent à zéro.

redondance à chaud

La redondance à chaud fonctionne sur le mode actif / passif. L'instance DevI/O active communique ses informations et ses messages de vie à un module de redondance hébergé sur le serveur de secours (le passif). Ce module entretient une copie du projet courant de l'instance active. Lorsque le message de vie ne parvient plus au module de redondance, celui-ci démarre l'instance DevI/O de secours avec la copie du projet du serveur principal qu’il a maintenu à jour. Lorsque l'instance principale réapparaît, une copie du projet du serveur de secours est renvoyée et une bascule inverse est déclenchée.

Dans ce mode de fonctionnement, il y a continuité des variables et des index de lecture des historiques et les variables OPC conservent leurs dernières valeurs lues.

Un module de redondance est capable de surveiller jusqu’à cinq instances principales ; il maintient une copie à jour de chaque projet principal. Cependant, il ne peut secourir qu'une seule instance à la fois.

Les ressources externes, comme les modems ou les ports de communication, doivent être mutualisées sur le réseau IP et donc partagées entre les instances principales et le secours.

Installation du produit DevI/O

Ce chapitre est consacré à l’installation du produit DevI/O et présente toutes les étapes nécessaires à l’accomplissement de cette tâche.

Le produit DevI/O doit être installé dans des environnements intégrant le système d’exploitation Microsoft Windows, tels que : Windows 7, Windows 10, Windows Server 2008 et 2008 R2, Windows Server 2012 et 2012 R2 et Windows Server 2016 et 2019.

Pré-requis

L’installation du composant DevI/O configuration XML peut nécessiter l’installation des composants Microsoft suivants : .Net Framework 4 et ses mises à jour.

L’installation doit se faire à partir d’un compte appartenant au groupe des « administrateurs ».

Produit DevI/O

Pour installer le produit DevI/O, des interfaces applicatives aux interfaces d’échanges, en passant par les composants DevI/O Studio et DevI/O configuration XML, exécuter le programme d'installation « setup_all.exe » (situé dans le dossier d’installation qui vous a été fourni) et suivre les instructions présentées à l’écran.

Après le lancement de l'exécutable « setup_all.exe », le message, présenté sur la figure 4, apparaît.

Figure 4 : Démarrage de la procédure d’installation

Figure 5 : Choix de la langue

Sélectionner la langue d'installation (English ou Français) et valider en cliquant sur le bouton OK (Cf. figure 5). Le français est la langue d’installation par défaut.

L'écran présenté en figure 6 ci-dessous apparaît :

Figure 6 : Installation du produit DevI/O et de ses interfaces

Figure 7 : Choix du répertoire d’installation du produit DevI/O

Cliquer sur le bouton Installer >, pour installer DevI/O et ses interfaces.

Dans la fenêtre qui apparaît (Cf. figure 7), sélectionner le répertoire d’installation. Vous pouvez modifier ce répertoire d’installation - par défaut, c:\Program Files (x86)\DevIO - en cliquant sur le bouton Parcourir.

Cliquer sur le bouton Suivant > pour poursuivre l’installation.

À ce stade, trois modes sont proposés (Cf. figures 8 et 9) :

• Installation complète (sélection par défaut), mode dans lequel toutes les options sont déjà cochées,
• Installation compacte, mode dans lequel toutes les options sont décochées,
• Installation personnalisée, mode dans lequel un choix est possible (Cf. copie d’écran ci-dessus).

Figure 8 : Choix des composants

Figure 9 : Choix des composants suite

L’option Agent SNMP offre la possibilité à un manager SNMP de lire et/ou d’écrire dans les entités DevI/O.

L’option Archivage offre la possibilité de stocker des entités DevI/O dans une base de données sous différents formats (ODBC et ADO).

L’option Installation du service permet de sélectionner le mode de lancement du service DevI/O : le mode Installer le serveur DevI/O natif est à privilégier mais l’ancien mode de lancement Installer le service APIRIC de lancement d’application est toujours disponible, pour rester compatible avec les anciennes versions, ce qui n’est plus indispensable.

L'option Suppression automatique des logs permet de mettre en place deux scripts de suppression des logs :

• un pour le serveur DevI/O

• un pour les protocoles.

  Si vous activez les trois cases correspondantes, les scripts PowerShell (remielogs.ps1 et remsrvlogs.ps1) seront automatiquement copiés dans C:\Program Files (x86)\DevIO\Data et configurés en tant que tâches dans le planificateur de tâches Windows.

  Par défaut, ces scripts supprimeront les fichiers logs âgés de plus de 7 jours, mais ce délai peut être ajusté. Assurez-vous que ces tâches fonctionnent correctement après l'installation, en tenant compte des politiques de sécurité de votre entreprise.

  Si la suppression des logs ne fonctionnent pas, vous pouvez exécuter ce script PowerShell suivant dans une console PowerShell exécuter au préalable avec un compte administrateur du poste :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Choisir a minima Installation personnalisée et Installer le service DevI/O natif voire Suppression automatique des logs (Cf. figure 9).

Une fois ce choix effectué, cliquer sur le bouton Suivant > pour accéder à la fenêtre présentée en figure 10.

Figure 10 : Choix du nom du dossier dans le menu Démarrer Windows pour le produit DevI/O

Par défaut, le nom du dossier (dans lequel seront placés les raccourcis du programme DevI/O ) dans le menu Démarrer Windows est "DevIO" ; vous avez la possibilité de modifier ce nom en cliquant sur le bouton Parcourir.

Cliquer ensuite sur Suivant >.

Figure 11 : Sélection des tâches supplémentaires pour le produit DevI/O

	Pour effectuer l’activation de la licence ultérieurement, vous pouvez décocher, dans cet écran (Cf. figure 11), la case Activer la licence.

Cliquer sur le bouton Suivant > : un récapitulatif des différents choix effectués est alors présenté (Cf. figure 12) avant le démarrage de l’installation. Cliquer sur le bouton Installer pour effectuer l’installation de DevI/O.

Figure 12 : Récapitulatif des options sélectionnées pour le produit DevI/O

A l’issue de cette installation et si vous avez coché la case Activer la licence, l’écran présenté sur la figure 13 apparaît.

Figure 13 : Installation de la clé logicielle

Se reporter au chapitre 2.3 Installation de la clé d'activation, pour obtenir les informations nécessaires à l’activation de la licence ou cliquer sur le bouton Quitter/Close pour poursuivre l’installation.

L’installation des interfaces d’échanges associées à DevI/O commence alors. A ce stade, le déroulé de l’installation peut être sensiblement différent d’une installation à une autre : il dépend du package initial fourni, qui contient les interfaces d’échanges ou protocoles que vous avez acquis. Les exemples, illustrés par les copies d’écrans qui vont suivre, contiennent toutes les indications nécessaires pour vous permettre de finaliser votre installation. Dans tous les cas, vous aurez à installer les deux composants DevI/O Studio et DevI/O configuration XML et, suivant les cas, une ou plusieurs interfaces d’échanges et applicatives. Se reporter au manuel associé à chaque interface, pour obtenir un complément d’information.

Au moment de l’installation de DevI/O Studio, la fenêtre présentée en figure 14 apparaît.

Figure 14 : Choix du répertoire d’installation de DevI/O Studio

Vous pouvez modifier le répertoire d’installation du composant DevI/O Studio - par défaut, c:\Program Files (x86)\DevIO - en cliquant sur le bouton Parcourir (Cf. figure 14)

Cliquer sur le bouton Suivant > pour poursuivre l’installation.

Figure 15 : Choix du nom du dossier dans le menu Démarrer Windows pour DevI/O Studio

Par défaut, le nom du dossier (dans lequel seront placés les raccourcis du programme DevI/O Studio) dans le menu Démarrer Windows est DevI/O ; vous avez la possibilité de modifier ce nom en cliquant sur le bouton Parcourir (Cf. figure 15). Cliquer ensuite sur Suivant >.

Figure 16 : Sélection des tâches supplémentaires pour DevI/O Studio

Cliquer à nouveau sur Suivant (Cf. figure 16) pour poursuivre.

Figure 17 : Récapitulatif des options sélectionnées pour DevI/O Studio

Cliquer ensuite sur Installer (Cf. figure 17).

Figure 18 : Fin de l’installation de DevI/O Studio

Et enfin, cliquer sur Terminer (Cf. figure 18).

Au moment de l’installation du module DevI/O configuration XML (Cf. copie d’écran présentée en figure 19), cliquer simplement sur Installer.

Figure 19 : Installation de DevI/O configuration XML

Enfin, à titre d’exemple, pour installer l’interface d’échanges Modbus (Cf. copie d’écran présentée en figure 20), cliquer simplement sur Installer.

Figure 20 : Installation de l’interface d’échanges Modbus

A la fin de la séquence d’installation de tous les protocoles inclus dans le setup, la fenêtre suivante apparaît :

Figure 22 : Fin de l’installation du produit DevI/O

Cliquez alors sur le bouton Terminer pour redémarrer votre ordinateur.

Installation du produit et de la clé d’activation

Pour activer la licence DevI/O, lancer le programme situé dans le menu Démarrer / Tous les programmes / DevIO / Activer la licence.

Dans la fenêtre qui apparaît (Cf. figure 23), sélectionner le produit DevI/O dans le menu déroulant et communiquer à Technilog (support@technilog.com) le numéro de la Licence installée (dans notre exemple ci-dessous : 5F7378D6-25DC768).

Figure 23 : Obtention du numéro de licence

Figure 24 : Saisie et validation de la clé logicielle

Saisir ensuite la valeur de la clé logicielle obtenue auprès de Technilog puis cliquer sur le bouton Valider/Apply (Cf. figure 24). Si la clé d’activation est correcte, l’Etat / Status passe à OK.

Cliquer enfin sur le bouton Quitter/Close pour fermer l’écran d’installation (Cf. figure 24).

Par défaut, le champ associé à Clef installée est fixé à DEMO (Cf. figure 23). Dans ce cas et pour rappel, cette licence de démonstration n’autorisera une utilisation du serveur DevI/O que pendant une heure, à l’issue de laquelle, il faudra manuellement relancer le serveur pour pouvoir l’utiliser à nouveau. Au démarrage du serveur en mode console, un message d'avertissement sera alors affiché au lancement (Cf. figure 25).

Figure 25 : Avertissement au démarrage du serveur DevI/O avec une licence de démonstration

DEsinstallation du produit et de la clé d’activation

Pour désinstaller le produit DevI/O, lancer le programme situé dans le menu Démarrer / Tous les programmes / DevIO / Désinstaller DevIO (Cf. figure 26).

Figure 26 : Option Désinstaller DevIO dans le dossier DevIO (menu Démarrer Windows)

Après confirmation en cliquant sur le bouton Oui (Cf. figure 27), la désinstallation de DevI/O et de tous ses composants s'exécute.

Figure 27 : Désinstallation de DevIO

Cette désinstallation du produit DevI/O peut s’accompagner d’une désinstallation définitive de la licence DevI/O, si vous cliquez sur le bouton Désinstallation définitive / Permanent uninstall (Cf. figure 28). Pour conserver la licence, cliquer sur le bouton Quitter.

Figure 28 : Désinstallation de la licence logicielle DevIO

Si vous cliquez sur le bouton Désinstallation définitive / Permanent uninstall (Cf. figure 28) et si vous confirmez en cliquant sur le bouton Oui (Cf. figure 29), noter la clé de désinstallation et conserver la précieusement ; dans notre exemple ci-dessous, la clé de désinstallation vaut 53535-65148 (Cf. figure 30). Elle vous sera demandée par Technilog, si une nouvelle installation de DevI/O est nécessaire.

Figure 29 : Confirmation de la désinstallation de la licence logicielle DevIO

Figure 30 : Génération d’une clé de désinstallation à conserver

Cliquez alors sur le bouton OK.

Figure 31 : Fin de la désinstallation de la clé logicielle

Cliquez enfin sur le bouton Quitter (Cf. figure 31) pour terminer la désinstallation de DevI/O et de ses composants.

Figure 32 : Fin de la désinstallation de DevI/O

Appuyer sur le bouton OK pour mettre fin au programme (Cf. figure 32).

	La désinstallation du produit DevI/O peut également s’effectuer en passant par le panneau de configuration Windows (Cf. Panneau de configuration\Tous les Panneaux de configuration\Programmes et fonctionnalités). Dans ce cas, vous pourrez désinstaller DevI/O et également le composant DevI/O Studio.

Exploitation du produit DevI/O

Après deux chapitres consacrés à une présentation générale puis à l’installation, le moment est maintenant venu de mettre en situation et en pratique le produit DevI/O.

les principales etapes

Pour bien démarrer cette partie et avoir une vision globale dès le début, commençons par définir les principales étapes de la mise en œuvre du produit (Cf. figure 33). Nous pourrons ensuite détailler certaines de ces étapes pour apprendre à les maîtriser.

Figure 33 : Les principales étapes de la mise en œuvre du produit DevI/O

• Etape 1

  Le serveur DevI/O fonctionne en arrière-plan. Il est lancé par l’intermédiaire d’un service installé et configuré durant la procédure d’installation. Ce service apparait sous le libellé « Service DevI/O » (pour une installation en français) ou « DevI/O Service » (pour une installation en anglais). Le projet ou base de configuration, utilisé par le serveur DevI/O et préalablement préparé avec DevI/O Studio, est lu dans la base de registre et est chargé au démarrage du serveur. Selon la configuration, les interfaces implémentant les protocoles utilisés sont lancées. Chaque interface est chargée d’effectuer toutes les opérations nécessaires à l’initialisation des couches de communications utilisées.

• Etape 2

  DevI/O Studio permet de préparer la configuration initiale du projet. Ce dernier contient les interfaces ainsi que les modèles d’équipements qui seront utilisés pour ajouter les équipements de production. Ce projet est préparé hors-ligne et est chargé lorsque le serveur DevI/O est lancé.

• Etape 3

  Le projet ou base de configuration est chargé par le serveur DevI/O au démarrage, puis enrichi à chaque fois qu’un nouvel équipement est ajouté via le module DevI/O configuration XML.

• Etape 4

  La configuration XML permet d’ajouter en ligne ou « à chaud » de nouveaux équipements sans arrêter l’acquisition des équipements existants. Des fichiers XML contenant les informations permettant la définition du nouvel équipement sont déposés dans un répertoire partagé avec le serveur DevI/O. Le compte rendu de l’opération est également placé par le serveur DevI/O dans un fichier XML et le succès ou l’échec de l’opération est reporté à l’utilisateur.

• Etape 5

  La présence d’un fichier XML dans le répertoire partagé est détectée par le serveur DevI/O qui ajoute le nouvel équipement dans la base de configuration (voir étape et flux 3).

• Etape 6

  Le serveur DevI/O transmet des requêtes génériques aux interfaces d’échanges qui les traduisent en requêtes spécifiques. Les données sont encodées et décodées par l’interface. Les données sont remontées au serveur DevI/O pour que ce dernier exécute les traitements génériques.

• Etape 7

  Les protocoles de communication sont utilisés pour acquérir (appel sortant), à la demande ou sur planning, les données des divers équipements ou pour recevoir (appel entrant), les données transmises à l’initiative de l’équipement (envoi d’alarmes, par exemple). Il est également possible d’écrire pour modifier par exemple une consigne.

• Etapes 8 et 9

  Le serveur DevI/O transmet les données aux diverses interfaces applicatives qui alimentent ensuite les applications « métiers ».

les modes de configuration

Le besoin de configuration est présent à différents stades de la vie de votre projet DevI/O : cela commence dès la création de votre premier projet puis se poursuit lors de chaque intégration de nouveaux équipements voire de nouveaux protocoles. Différents modes de configuration sont proposés : nous les décrivons dans cette partie.

Par saisie manuelle hors ligne en utilisant DevI/O Studio

DevI/O Studio est une application de saisie de la configuration des paramètres fonctionnels par un opérateur. Les résultats de la configuration sont archivés dans une base « projet » et permettent de générer l'image de la base « mémoire » du système d'acquisition et de traitement. Pour limiter les saisies, DevI/O Studio propose une fonction de gestion de modèles permettant de prédéfinir, pour un type d'équipement, les différentes entités de configuration associées.

La configuration réalisée avec cet outil est obligatoirement réalisée hors ligne (i.e., le serveur DevI/O arrêté).

Même si cet outil est systématiquement utilisé pour la revue de la configuration, pour la saisie, il est souvent remplacé par des procédures automatiques.

Par import de fichiers en utilisant DevI/O configuration XML

Il est possible d'importer des fichiers de configuration. Les formats inclus dans DevI/O, sont ceux produits par les outils fournis par le constructeur pour configurer les équipements.

La configuration réalisée avec cette interface peut être effectuée en cours de fonctionnement : il s’agit donc de configuration « à chaud ». Le serveur DevI/O principal met à jour en temps réel sa configuration et synchronise le tout avec le serveur de secours éventuel.

Il est possible de réaliser l’import à partir de fichiers multi-équipements, c’est le domaine de la personnalisation.

Par autoconfiguration en utilisant DevI/O configuration XML

La méthode la plus efficace consiste à utiliser, quand les protocoles le permettent, les capacités d’autodécouverte des équipements.

Le serveur DevI/O doit connaître les paramètres de connexion aux équipements. Il peut alors interroger les équipements et rapatrier l’ensemble des paramètres nécessaires à sa propre configuration.

Cette définition de toutes les variables accessibles des équipements peut être amendée (choix des variables utiles, par exemple) par l’application avant de servir de base à une autoconfiguration du projet DevI/O. Ce processus est réalisé équipement par équipement.

C’est la méthode de configuration « à chaud » par excellence.

CREER VOTRE PREMIER PROJET avec DevI/O Studio

Le composant DevI/O Studio fait l’objet d’une documentation à part entière, qui permet de décrire toutes les fonctionnalités qu’un utilisateur pourrait être amené à mettre en œuvre. L’objectif de cette partie n’est donc pas de faire une présentation exhaustive des fonctions de DevI/O Studio mais plutôt de cibler les éléments utiles à une première implémentation.

Dans le dossier d’installation, nous fournissons généralement un premier projet que nous avons prédéfini pour répondre à votre contexte d’utilisation. Ce projet contient la définition des interfaces que vous nous avez demandées. Dans ce cas, la procédure d’installation intègre la mise en place de ce projet, de façon que vous puissiez immédiatement passer aux deux étapes suivantes : le démarrage du serveur DevI/O et l’ajout d’équipements en ligne. Bien entendu, vous pourrez avoir besoin de créer ou ajouter vous-même, une nouvelle interface, par exemple : dans ce cas, référez-vous à la documentation de cette interface, qui contient toutes les informations nécessaires en termes d’installation et de configuration.

ouvrir le projet predefini et fourni

Les copies d’écrans, présentées dans cette partie, indiquent la procédure à suivre pour démarrer, dans un premier temps, DevI/O Studio puis pour ouvrir, dans un deuxième temps, le projet prédéfini.

Si vous avez sélectionné la case à cocher Créer une icône sur le Bureau (option par défaut) au moment de l’installation de DevI/O Studio, vous pouvez double-cliquer sur l’icône DevI/O Studio sur le bureau, pour démarrer le composant. Sinon, pour ce faire, vous pouvez également double-cliquer sur le fichier DevIO.Studio.exe qui est situé, par défaut, dans C:\Program Files (x86)\DevIO\Studio.

Dans les deux cas, l’écran présenté en figure 34 apparaît et permet de créer un Nouveau projet ou d’ouvrir un projet existant (Ouvrir projet).

Figure 34 : Interface graphique DevI/O Studio

Pour ouvrir le projet prédéfini, cliquer sur Ouvrir projet pour accéder au fichier VotreProjet.pro, localisé par défaut dans C:\Program Files (x86)\DevIO\Data\Base\\<VotreProjet>. Dans le cas de notre exemple (Cf. figure 35), le projet prédéfini se nomme DEMO.

Figure 35 : Ouverture du projet DEMO dans DevI/O Studio

Dans ce projet prédéfini, les interfaces - qui vous seront nécessaires - ont déjà été configurées ; c’est également le cas des modèles d’équipements.

le sélectionner comme projet courant

Vérifions maintenant ensemble que ce projet prédéfini est bien le projet courant. Pour cela, faire un clic-droit sur Serveur (Cf. figure 35), racine de l’arborescence associé à l’Explorateur du projet, et cliquer sur Propriétés...

Dans la fenêtre qui apparaît (Cf. figure 36), cliquer sur le bouton Remplacer, si aucune base actuelle (ou projet courant) n’est sélectionnée ou si vous souhaitez modifier la base actuelle par celle que vous venez d’ouvrir.

Figure 36 : Sélection du projet courant dans DevI/O Studio

Cette action a pour conséquence de modifier le projet courant (Cf. copie d’écran en figure 37) et modifie également la clé de registre PATH_BASE (Cf. copie d’écran en figure 38 : Ordinateur\HKEY_LOCAL_MACHINE\SOFTWARE\ WOW6432Node\TECHNILOG\DevIOParameters\DEVIOSRV). Cliquer sur le bouton Appliquer (Cf. figure 36 ou figure 37) pour finaliser l’opération.

Figure 37 : Validation et visualisation du projet courant dans DevI/O Studio

Figure 38 : Visualisation du projet courant dans la base de registre Windows

demarrER VOTRE PROJET AVEC LE serveur DEVI/O

Votre projet courant est maintenant prêt à être utilisé et, pour ce faire, le serveur DevI/O doit être démarré. Dans cette partie, nous présentons les deux modes de démarrage du serveur DevI/O.

lancement en service (mode automatique)

A l’issue de l’installation du produit DevI/O, un nouveau service a été créé : « Service DevI/O », pour une installation en français ou « DevI/O Service », pour une installation en anglais ; dans les deux cas, ce service est configuré de façon à être automatiquement démarré (Cf. Type de démarrage sur la copie d’écran présentée en figure 39), au redémarrage de votre ordinateur ou serveur.

Figure 39 : Propriétés du service DevI/O

	Si vous n’avez pas installé de licence - vous fonctionnez donc avec une licence de démonstration d’une durée d’une heure - le service ne pourra pas être démarré en mode service. Dans ce cas, la seule possibilité est de démarrer le serveur DevI/O en mode console ou sur le bureau.

lancement en mode console ou sur le bureau (mode manuel)

Il est possible de démarrer manuellement le serveur DevI/O en mode console ou sur le bureau, à partir de l’icône de notification DevI/O ou DevI/O Tray, qui est disponible à l’issue de l’installation du produit DevI/O.

Cet icône de notification DevI/O est accessible, quand il a été lancé, via la barre des tâches de Windows. Dans le cas où cet icône n’est pas présent dans la barre des tâches, vous pouvez le faire apparaître en double-cliquant sur le fichier DevIOTray.exe situé, pour une installation par défaut, dans le répertoire C:\Program Files (x86)\DevIO\Tray.

En cliquant ensuite sur cet icône avec le bouton droit de votre souris (Cf. figure 40), vous pouvez accéder à un menu de démarrage du serveur DevI/O (en mode service ou sur le bureau) et également de démarrage de DevI/O Studio.

Il est alors possible de Lancer DevI/O sur le bureau dans un Mode d’affichage qui peut contenir plus ou moins d’informations.

Figure 40 : Démarrage du serveur DevI/O sur le bureau

	Le serveur DevI/O peut également être démarré par l’intermédiaire d’un client OPC DA, en fonction du paramétrage mis en œuvre au niveau du composant Windows DCOM. Dans ce cas, le client OPC DA démarre le serveur DevI/O dans le même mode (service ou sur le bureau) que celui du dernier lancement opéré.

ENRICHIR VOTRE PROJET AVEC DEVI/O Configuration XML

Le module DevI/O configuration XML est une application optionnelle tierce venant se greffer au serveur DevI/O, afin de configurer de nouveaux équipements en ligne ou « à chaud », dans un projet courant. C’est donc un module essentiel dans un chapitre dédié à l’exploitation du produit DevI/O. C’est pour cette raison que nous vous proposons maintenant de l’aborder de façon très détaillée, en commençant par décrire le principe de son fonctionnement.

principe de fonctionnement

Le module de configuration XML est autonome mais les opérations demandées ne sont effectives que lorsque le serveur DevI/O est en fonctionnement.

Le principe retenu au niveau du serveur DevI/O est la scrutation du contenu de répertoires. La détection de la présence de fichiers XML permet, après analyse, d’initier les opérations suivantes sur les équipements :

• autodécouverte,
• import,
• autoconfiguration,
• suppression,

• lecture/écriture des programmes horaires.

  Le module intervient alors dans les opérations suivantes :

• génération du contenu des fichiers requêtes XML,

• gestion de la dépose de ces fichiers XML à travers les différents répertoires,
• gestion de l’attente de fin d’opération du serveur DevI/O,

• indication du résultat de l’opération effectuée.

  Les opérations demandées sont traitées par le serveur DevI/O, via des DLL fournies optionnellement et chargées dynamiquement.

Une interface graphique

L’interface graphique (Cf. figure 41) permet à l’utilisateur de fournir les renseignements nécessaires pour l’opération à effectuer.

Figure 41 : Interface graphique du module DevI/O configuration XML

Pour que la demande formulée soit traitée, il est impératif que le serveur DevI/O pour le projet concerné soit en fonctionnement. Si tel n’est pas le cas, la demande reste en attente de traitement et le module reste en attente du résultat du traitement : dans ce cas, plusieurs demandes ne peuvent donc pas être mises en file d’attente de traitement. L’opérateur peut néanmoins quitter le module ; le fichier de la requête de demande est alors positionné comme annulé. Si la demande était en cours de traitement par le serveur DevI/O, l’opération ira jusqu’à son terme.

Lorsqu’une opération est demandée pendant le fonctionnement du serveur DevI/O, le module attend et fournit le résultat de traitement à l’utilisateur. Les résultats positifs, des demandes d’autodécouverte et d’import, peuvent directement être suivis par une demande d’autoconfiguration. Une opération d’autoconfiguration peut néanmoins être réalisée seule par sélection d’un résultat d’autodécouverte ou d’import.

Les opérations ainsi effectuées n’affectent que la base binaire ; le projet visible dans DevI/O Studio n’est pas modifié. Il est possible de synchroniser la base binaire utilisée par le serveur DevI/O avec le projet visible dans DevI/O Studio, en utilisant la fonction « Import complet (recommandé) » dans DevI/O Studio (Cf. figure 35). Le paramétrage effectué au travers du module de configuration XML sera alors disponible dans DevI/O Studio à des fins de contrôle ou modification.

	Attention, la compilation, partielle ou complète (Cf. figure 35), d’un projet dans DevI/O Studio, effectué sans avoir réalisé une importation au préalable, entrainera la perte de toutes les modifications effectuées via le module depuis la dernière compilation.

Equipements supportés

L’autoconfiguration et la suppression sont des opérations dites génériques :

• l’autoconfiguration est le paramétrage dans le projet DevI/O d’un équipement, en utilisant un fichier XML contenant ce paramétrage, formaté à cet effet,

• la suppression consiste simplement à effacer le paramétrage d’un équipement dans le projet DevI/O.

  L’autodécouverte et l’import sont des opérations spécifiques à certains protocoles de DevI/O, consistant à formater le paramétrage dans un fichier XML en vue de réaliser une autoconfiguration.

  Le tableau suivant présente la couverture des opérations d’autodécouverte en fonction des protocoles par type d’équipement :

Protocole DevI/O	Constructeur	Type
Napbus	Napac	TBC, XFLOW
WitNet	Wit	FORCE, CLIP, EASY
TRSII	ACS	Domino
BACnet	Générique	BACNET
Lacbus (Sofbus)	Sofrel	S50 (Sofbus), S500 (Lacbus)
TrendIQxxx	Trend	IQ2, IQ3

Le tableau suivant présente la couverture des opérations d’import en fonction des protocoles par type d’équipement :

Protocole DevI/O	Constructeur	Outil import	Modèle
Lacbus	Sofrel	SOFTOOLS	Lacbus : chaîne contenant LACBUS Sofbus : chaine contenant S10, S15, S50, S500, CELLBOX ou TELBOX
SMS	Sofrel	SMS_SOFREL	Chaîne contenant : CELLBOX ou LS
PcText	Générique	PCTEXT	STCTELYO
Perax	Perax	PERAX	Libre
Virtual Transmitter	Générique	VT	VT
	Les noms des modèles d’équipement pour réaliser un import sont imposés.

installation et lancement du module

Installation

Le module de configuration XML étant optionnel, un setup d’installation à part entière est fourni et permet d’installer l’ensemble des fonctionnalités nécessaires : interface graphique et DLL complémentaires du serveur DevI/O (voir chapitre 3 Installation).

Ce setup peut être automatiquement exécuté lors de l’installation de DevI/O (à l’identique des interfaces d’échanges).

L’installation de ce module sur un poste ne nécessite pas forcément que DevI/O soit préalablement installé : cela peut-être le cas dans le cadre d’une utilisation pour des serveurs DevI/O distants. Cependant, pour une facilité de gestion de la base des équipements modèles localement, il est souhaitable que le composant DevI/O Studio soit installé voire le produit DevI/O au complet.

Paramétrage

Bien qu’autonome, le module de configuration XML repose sur le paramétrage du serveur DevI/O. Les arguments du serveur DevI/O peuvent être précisés à deux niveaux :

• dans la base de registres Windows (cf. Figure 38)

  chaine ARGUMENTS

  clé \HKLM\SOFTWARE\WOW6432Node\TECHNILOG\DevIOParameters\DEVIOSRV

• dans le projet DevI/O (cf. Figure 37)

  champ Arguments additionnels

  Note : Dans le projet DevI/O, les arguments ont priorité sur ceux de la base de registres lorsqu'ils sont spécifiés aux deux endroits.

  La base de données DevI/O est récupérée dans le niveau suivant :

  chaine PATH_BASE (cf. Figure 38)

  clé \HKLM\SOFTWARE\WOW6432Node\TECHNILOG\DevIOParameters\DEVIOSRV

  Les paramétrages relatifs à la localisation de la base modèle et du répertoire d’échanges des fichiers XML sont formatés ainsi :

• \<-PATH_MODELS>\<sp>‘’\<chemin de la base binaire des modèles d’équipements>’’

• \<-PATH_XML>\<sp>‘’\<chemin racine des répertoires d’échanges XML>’’

  Lorsque ces arguments ne sont pas précisés, les paramètres par défaut sont utilisés :

• Base modèle

  correspond au projet DevI/O, ce qui signifie que les équipements modèles doivent être paramétrés dans le projet DevI/O.

• Répertoire racine des fichiers XML

  \<chemin du projet DevI/O >_XML » (exemple : DEMO_DB_BIN_XML).

  Les sous répertoires sont automatiquement créés par le serveur DevI/O dès son lancement dans le répertoire racine d’échanges des fichiers XML: ils sont décrit dans le tableau suivant.

« Racine XML\ »	Description
Discovery\Request	Demande d’autodécouverte
Discovery\Response	Réponse des autodécouvertes
Discovery\TimeZone	Réponse d’une lecture de programmes horaires suite à une autoconfiguration
Import\Request	Demande d’import
Import\Response	Réponse des imports
Update\Request	Demande d’autoconfiguration
Update\Response	Réponse des autoconfigurations
Delete\Request	Demande de suppression
Delete\Response	Réponse des suppressions
TimeZone\Request	Demande de lecture/écriture des programmes horaires
TimeZone\Response	Réponses des lectures/écritures des programmes horaires

Lorsque le traitement d’un fichier XML d’un répertoire « Request » est terminé, le fichier est renommé avec l’extension « .ended » ; un fichier avec cette extension a une structure XML et peut donc être ouvert avec un éditeur supportant ce format. Dès lors que les fichiers ont un nom unique, ces fichiers sont conservés à des fins de suivi.

Les noms des fichiers suivent les règles indiquées ci-dessous :

• les noms de fichiers sont identiques entre un répertoire « Request » et son répertoire « Response » associé,
• les noms de fichiers sont identiques entre le répertoire « Request » d’autoconfiguration et le répertoire « Response » d’autodécouverte ou d’import.

Lancement du module

Un raccourci nommé « DevIO - Configuration XML » est créé dans le menu programmes de Windows lors de l’installation. Celui-ci ne comporte aucun argument de lancement et peut être utilisé directement pour le serveur DevI/O installé localement si tel est le cas.

Lorsqu’aucun argument n’est passé au module, les répertoires utilisés (base binaire, base modèle et échanges XML) sont identiques à ceux utilisés par le serveur DevI/O local. Le module analyse alors les arguments de ce serveur DevI/O et se conformera au paramétrage du serveur en ce qui concerne les répertoires.

Le module peut également être lancé en lui passant un ou plusieurs arguments :

• \<-PATH_BASE >\<sp>’’\<chemin de la base binaire du serveur DevI/O >’’
• \<-PATH_MODELS>\<sp>‘’\<chemin de la base binaire des modèles d’équipements>’’

• \<-PATH_XML>\<sp>‘’\<chemin racine des répertoires d’échanges XML>’’

  Si aucun paramétrage n’a été effectué pour le module de configuration XML (pas d’arguments ou pas de clé dans la base de registres), ce dernier ne sera pas exploitable.

  A partir du moment où un projet DevI/O a été sélectionné en tant que projet courant, même si les autres arguments (-PATH_BASE et -PATH_MODELS) n’ont pas été définis, le module les construira à partir du projet mentionné.

  Le module de configuration XML étant dissocié du serveur DevI/O, il convient donc d’avoir une certaine cohérence entre les arguments passés au module et ceux passés au serveur DevI/O.

	Lorsque la base binaire est un emplacement réseau (partage) pour un poste distant, le module de configuration XML n’analyse pas la base de registre de ce poste distant. Si toutefois les arguments sont passés par la base de registres, ils doivent être identiques à ceux passés au niveau du module.

Il est possible par les arguments passés au module de lancer plusieurs modules sur des projets DevI/O différents.

Arrêt du module

Pour quitter le module, il suffit de cliquer sur le bouton Quitter de l’interface (Cf. figure 41). Le bouton Fermer (= clic sur la croix) de l’interface a été désactivée pour ne pas stopper une opération demandée par le module en attente de traitement par le serveur DevI/O. Lorsque le module passe en attente de traitement, seul le bouton Quitter reste accessible. L’utilisateur peut stopper cette attente en cliquant sur le bouton Quitter et en confirmant cet arrêt. Dans ce cas, le fichier de demande est renommé avec l’extension « cancel ». Cependant, la demande pouvant être en cours de traitement par le serveur DevI/O, le résultat ne sera alors pas remonté par le module. L’utilisateur peut donc ensuite quitter le module.

présentation de l’interface graphique

L’interface graphique, présentée sur figure 41, est découpée en différentes zones : Répertoires, Historique, Autodécouverte / Import, Communication, Autoconfiguration et Equipement, que nous nous proposons de décrire maintenant.

Répertoires

L’interface utilisateur rappelle les différents répertoires paramétrés pour le module :

• « Base DevI/O »

  emplacement des fichiers binaires du projet utilisé par le serveur DevI/O,

• « Base modèles »

  emplacement des fichiers binaires du projet DevI/O contenant les modèles d’équipements.

• « Echanges XML »

  emplacement du répertoire racine des sous répertoires d’échanges de fichiers XML du serveur DevI/O.

  Lorsque les arguments « -PATH_MODELS » et « -PATH_XML » sont ceux par défaut, c’est à dire non mentionnés pour le serveur DevI/O ni passés en arguments du module, le module permet par sélection de répertoire de les modifiés en cliquant sur un bouton « … » respectif.

Historique

L’interface utilisateur présente sous forme de tableau un historique comportant les caractéristiques de toutes les opérations d’autodécouverte ou d’import réalisées avec le module. Cette mémorisation est effectuée dans une base de données locale au module.

L’unicité dans l’historique se fait par le couple mnémonique de l’équipement / projet DevI/O. Ces opérations sont donc mémorisées pour tous les projets DevI/O gérés par le module.

Les éléments présentés dans ce tableau sont les suivants :

• Mnémonique

  mnémonique de l’équipement dans le projet DevI/O,

• Identification (*)

  identification de l’équipement, il s’agit en réalité de l’adresse de l’équipement pour le serveur DevI/O,

• Login (*)

  login autorisé à se connecter à l’équipement,

• Mot de passe (*)

  mot de passe pour accéder à l’équipement,

• Modèle

  mnémonique de l’équipement modèle de la base des modèles,

• Tr

  indique si le résultat d’une des opérations est transformé avant de réaliser une autoconfiguration,

• Outil

  outil utilisé pour réaliser l’opération (soit découverte, soit un des outil d’import),

• Fichier importé

  chemin complet du fichier contenant le paramétrage de l’équipement pour réaliser l’import,

• Conversion

  indique le nom de l’interface de sortie du résultat d’autoconfiguration si celui-ci est converti pour être importé dans un superviseur,

• Téléphone

  numéro de téléphone de l’équipement,

• IP

  adresse IP de l’équipement,

• Port

  port TCP de l’équipement,

• Canal NULL

  adresse de communication complémentaire de l’équipement lors de l’utilisation de l’interface canal DevI/O NULL pour le modèle d’équipement,

• Base DevI/O

  chemin complet du projet utilisé par le serveur DevI/O pour lequel une de ces opérations est réalisé pour l’équipement,

  (*) Ces trois champs sont génériques dans l’historique et sont ou non utiles, ou bien sont nommés différemment en fonction du protocole DevI/O associé au modèle d’équipement choisi.

  Les modèles d’équipements servent à associer la configuration des canaux de communication de l’équipement avec celui du modèle sélectionné (canaux et paramètres canaux). Les équipements modèles se distinguent des autres équipements dans la base modèle par leur adresse équipement au sens DevI/O, qui débute par un « ?? ». Dans le cas où la base binaire DevI/O est dissocié de la base modèle, il est nécessaire que la définition des canaux et des paramètres canaux soit identique dans les deux bases.

Autodécouverte / Import

Ce cadre rassemble l’ensemble du paramétrage nécessaire à la réalisation d’une autodécouverte ou d’un import d’un équipement.

Les différents paramètres sont :

• Outil

  liste de choix de l’outil pour réaliser l’opération, « Découverte » ou tous les outils d’import de configuration,

• Modèle

  choix du modèle d’équipement à utiliser parmi la liste de tous les modèles d’équipements présents dans la base des modèles. Cette liste est remplie dynamiquement en fonction du répertoire de la base des modèles d’équipement,

• Transformation du résultat

  case à cocher indiquant ou non si le résultat de l’opération sera transformé avant autoconfiguration,

• Fichier à importer

  chemin complet du fichier contenant le paramétrage de l’équipement accessible uniquement pour les opérations d’import (outil autre que « Découverte » sélectionné),

• Identification, Login et Mot de passe

  ces trois champs sont génériques et représentent l’identification (obligatoire), le login et le mot de passe si nécessaires de l’équipement. Ces trois champs évoluent en fonction du protocole DevI/O associé au modèle d’équipement choisi.

La liste des outils est la suivante :

• Découverte

  outil par défaut, il s’agit de l’outil à sélectionner pour toutes les opérations d’autodécouverte d’un équipement s’il supporte cette opération,

• SIGFOX

  supporté par les équipements du backend Sigfox,

• SOFTOOLS

  supporté par les équipements Sofrel utilisant le protocole Sofbus ou Lacbus,

• PCTEXT

  supporté par les équipements utilisant le protocole générique PcText,

• PERAX

  supporté par les équipements Perax,

• VT

  supporté par les équipements utilisant le protocole générique des transmetteurs virtuels,

• SMS_SOFREL

  supporté par les équipements Sofrel utilisant le protocole générique SMS,

• IJINUS

  supporté par les équipements Ijinus,

• TBOX

  supporté par les équipements Tbox,

• SCVARSET

  supporté par les commandes numériques Siemens (840D par exemple),

• LERNE

  supporté par les équipement du superviseur Lerne,

• CSVImport

  supporté par les équipements de type import CSV générique,

• S7

  supporté par les automates Siemens S7,

• KEP_S7

  supporté par les automates Siemens S7 définis dans le produit Kepware,

• KEP_FOCAS

  supporté par les commandes numériques Fanuc définies dans le produit Kepware,

• ORANGE

  supporté par les équipements du backend Orange,

• OPCUA

  supporté par les équipements intégrant un serveur OPC UA.

  La transformation du résultat consiste en l’application d’un fichier XSLT sur le fichier XML de réponse de l’opération (dont le résultat est correct), pour obtenir un nouveau fichier XML. Ce nouveau fichier XML se substitue à la réponse XML faite par DevI/O (l’ancien fichier est néanmoins conservé).

Communication

Ce cadre rassemble l’ensemble des canaux de communication pour se connecter à l’équipement. Les canaux de communication, de 1 à n (8 maximum) accessibles dépendent de ceux définis dans le modèle d’équipement sélectionné. De plus, les différents champs de communication sont adaptés en fonction des canaux paramétrés dont les équipements modèles :

• Téléphone

  le numéro de téléphone est accessible si l’interface canal TAPI ou canal Modem est utilisée pour le canal i du modèle d’équipement,

• IP, Port

  l’adresse IP et le port TCP sont accessibles si l’interface canal DevI/O Ethernet est utilisée pour le canal j du modèle d’équipement

  Lorsque ces champs de communication sont accessibles, ils sont obligatoires. Néanmoins, lorsqu’un équipement possède plusieurs canaux de type téléphone et/ou plusieurs paramètres TCPIP, et que ceux-ci sont identiques pour chaque canal du même type, seul le premier champ téléphone et/ou la première adresse IP avec son port TCP est/sont à renseigner. Les autres champs, puisqu’ils sont identiques, seront recopiés automatiquement.

Autoconfiguration

Ce cadre rassemble les informations de l’autoconfiguration d’un équipement, ainsi que des boutons de commandes d’opérations unitaires relatifs à l’autoconfiguration.

La case à cocher « Lecture automatique des programmes horaires » n’est jamais accessible, mais indique seulement si les programmes horaires seront lus durant l’opération d’autoconfiguration, en fonction du paramétrage du serveur DevI/O. Par défaut, lors de l’opération d’autoconfiguration, les programmes horaires de l’équipement, s’ils sont supportés, sont automatiquement lus. Cependant, l’argument « -NO_TZ » précisé pour le serveur DevI/O, permet de ne pas effectuer cette opération.

La liste de choix « Conversion dans un format » permet de sélectionner un format de sortie du résultat d’autoconfiguration en vue de son importation dans un superviseur. Par défaut « Aucune » conversion est sélectionnée.

La conversion dans un format consiste en l’application d’un fichier XSLT sur le fichier XML de réponse de l’autoconfiguration (dont le résultat est correct), pour obtenir un nouveau fichier XML compréhensible par l’interface du format sélectionné.

Equipement

Ce cadre permet le renseignement d’un mnémonique équipement et regroupe l’ensemble des boutons de commandes relatifs aux opérations effectuées sur un équipement. Pour ces opérations, le mnémonique est obligatoire.

Les noms des fichiers XML d’échanges sont définis à partir du mnémonique donné à l’équipement. La case à cocher « Noms fichiers uniques », non cochée par défaut, permet d’indiquer si les fichiers XML d’échanges auront un nom unique, obtenu dans ce cas, par concaténation du mnémonique de l’équipement avec l’horodatage de l’opération sous la forme AAAAMMJJHHMMSSmil.

utilisation du module

Historique

Tout le paramétrage d’une opération d’autodécouverte ou d’import réalisé dans le module est mémorisé sous forme d’historique, par mnémonique d’équipement sur une base binaire DevI/O.

Par double clic sur un enregistrement de l’historique, les rubriques suivantes seront automatiquement renseignées :

• autodécouverte / import,
• communication,
• autoconfiguration,

• équipement.

  Attention, cette opération effacera alors tout paramétrage en cours lié à ces rubriques.

  Cette fonctionnalité permet de réaliser de nouveau des opérations d’autodécouverte / import et d’autoconfiguration d’équipements qui auraient été mis à jour, ou bien de modifier un paramètre.

  Si toutefois un des paramètres mémorisés dans l’enregistrement n’existe pas ou a été modifié, ce paramètre ne sera pas positionné (exemple : modèle d’équipement, accessibilité des paramètres de communications, …).

  L’historique peut comporter un grand nombre d’enregistrements. Une fonctionnalité permet de restreindre la liste, par une méthode de tri et de filtrage indissociables :

• Tri

  liste de choix de la colonne sur laquelle l’affichage par ordre alphanumérique est réalisé. Par défaut le tri s’effectue sur la colonne « Mnémonique ».

• Filtrage

  texte permettant de filtrer la liste sur la colonne de tri sélectionné, contenant les caractères saisis,

• Toutes les bases DevI/O

  case à cocher qui permet de réaliser la sélection sur la base binaire DevI/O du module ou sur tous les projets DevI/O définis. Par défaut, seuls les enregistrements pour la base binaire DevI/O du module sont affichés. Cette option peut être utile pour déplacer un équipement d’une base binaire DevI/O à une autre.

• Recharger

  lorsque les caractéristiques de tri / filtrage sont modifiées, l’appui sur ce bouton de commande permet de recharger la liste.

  Le bouton « Effacer » permet d’effacer de l’historique, après confirmation, l’enregistrement sélectionné.

Autodécouverte / import d’un équipement

Pour réaliser une opération d’autodécouverte ou d’import, l’utilisateur doit renseigner les paramètres suivants :

• Outil, « Découverte » ou un des outils d’import,
• Modèle d’équipement,
• Fichier à importer dès lors que le champ est accessible,
• Identification (*),
• Téléphone dès lors que le champ est accessible,
• Adresse IP et Port TCP, dès lors que ces champs sont accessibles,

• Mnémonique de l’équipement, qui doit respecter les règles de nommage de DevI/O (40 caractères alphanumériques et « _ » maximum).

  L’utilisateur peut également positionner les éléments suivants :

• Transformation du résultat, si l’utilisateur souhaite transformer le résultat de l’opération en un nouveau fichier pour l’autoconfiguration,

• Login (*), si l’équipement nécessite un login de connexion,
• Mot de passe (*), si l’équipement nécessite un mot de passe d’accès,

• Conversion dans un format, si l’utilisateur souhaite créer un fichier de sortie XML pour une interface externe (superviseur).

  Si toutefois un paramètre est manquant ou incorrect, l’utilisateur en est informé lors de la demande de l’opération par appui sur le bouton de commande situé dans la rubrique équipement. Ce bouton de commande change de nom en fonction de l’opération, c’est-à-dire en fonction de l’outil sélectionné : Découvrir ou Importer.

  Un enregistrement est automatiquement généré dans l’historique en fonction du mnémonique saisi et de la base binaire DevI/O :

• si ce couple n’existe pas dans l’historique, l’enregistrement des paramètres est ajouté,

• si ce couple existe dans l’historique, les paramètres sont mis à jour.

  Le module passe ensuite en attente du traitement de la demande par le serveur DevI/O ; il surveille le passage du fichier de demande XML traité par DevI/O (renommage avec l’extension « ended »). Puis il indique le résultat par analyse du fichier de réponse.

Les tableaux suivants présentent les codes d’erreurs qui peuvent survenir lors d’une autodécouverte et lors d’un import de fichier.

Codes d’erreurs possibles lors d’une autodécouverte

Code	Description
0	Résultat correct
14	Connexion physique impossible
16	Communication interrompue (non-réponse répétitives)
30	Accès refusé
41	Echec connexion (niveau protocole)
61441	Modèle non trouvé dans la base modèle
61442	Fichier XML incomplet

Codes d’erreurs possibles lors d’un import de fichier

Code	Description
0	Résultat correct
8	Nom d’une entité dans le fichier de paramétrage trop long
11	Ligne d’entête du fichier de paramétrage erronée
13	Type de donnée incorrect
28	Erreur ouverture du fichier de paramétrage (absence, …)
61441	Modèle non trouvé dans la base modèle
61442	Fichier XML incomplet

Lorsque le résultat de l’opération est correct, l’utilisateur a la possibilité de poursuivre par l’autoconfiguration de l’équipement.

Si l’option transformation du résultat a été demandée, c’est le résultat de cette transformation qui sera « passé » à l’autoconfiguration. La transformation du résultat n’est possible que si dans le sous-répertoire « Transforms » du répertoire d’échanges XML, il existe un fichier XSLT dont le nom correspond au nom du modèle d’équipement sélectionné.

Autoconfiguration d’un équipement

Après une autodécouverte ou un import réussi d'un équipement, l'utilisateur peut choisir de poursuivre ou non avec une autoconfiguration. Il peut également demander une autoconfiguration en utilisant un fichier de réponse en cliquant sur le bouton « auto-conf ». Dans les deux cas, l'utilisateur sélectionne un fichier XML et est informé si le fichier n'est pas correct. Le module attend ensuite que le serveur DevI/O traite la demande, surveillant le fichier de demande XML renommé avec l'extension "ended", puis affiche le résultat. Le temps d'autoconfiguration peut varier en fonction du rapatriement des programmes horaires. Les programmes horaires sont ensuite gérés via le paramétrage d'une entité de type fichier dans l'équipement, toujours en utilisant un formatage XML. Un tableau des codes d'erreur possibles est présenté pour référence lors de l'autoconfiguration.

Codes d’erreurs possibles lors de l’autoconfiguration

Code	Description
0	Pas d’erreur
42	Equipement connecté

Si une conversion dans un format a été demandée, celle-ci est réalisée lorsque le résultat d’autoconfiguration est correct. Cette conversion est réalisée dans le sous répertoire « Interface_\<nom de l’interface sélectionnée> » du répertoire d’échanges XML

Une conversion directe peut être demandée après sélection d’un format en cliquant sur le bouton Conversion de la rubrique Autoconfiguration. L’utilisateur est invité à sélectionner un fichier XML du répertoire de réponse d’autoconfiguration. Le résultat de ce fichier doit être correct et l’utilisateur en est informé, si ce n’est pas le cas.

Suppression d’un équipement

La demande de suppression d’un équipement de la base binaire utilisée par le serveur DevI/O est réalisée par saisie du mnémonique dans la rubrique Equipement puis en cliquent sur le bouton Supprimer.

L’utilisateur est également invité à indiquer s’il souhaite que l’enregistrement soit supprimé ou conservé dans l’historique.

Le module passe ensuite en attente du traitement de la demande par le serveur DevI/O ; il surveille le passage du fichier de demande XML traité par DevI/O (fichier renommé avec l’extension « ended »). Puis il indique le résultat par analyse du fichier de réponse.

Le tableau suivant présente les codes d’erreurs qui peuvent survenir lors d’une suppression de fichier.

Codes d’erreurs possibles lors de la suppression

Code	Description
0	Pas d’erreur
10	Equipement non trouvé
42	Equipement connecté

Lecture des programmes horaires

La demande de lecture des programmes horaires d’un équipement de la base binaire utilisée par le serveur DevI/O est réalisée par saisie du mnémonique dans la rubrique Equipement puis en cliquent sur le bouton Lecture PH.

Le module passe ensuite en attente du traitement de la demande par le serveur DevI/O ; il surveille le passage du fichier de demande XML traité par DevI/O (fichier renommé avec l’extension « ended »). Puis il indique le résultat par analyse du fichier de réponse. Le tableau suivant présente les codes d’erreurs qui peuvent survenir lors d’une suppression de fichier.

Codes d’erreurs possibles lors de la lecture des programmes horaires

Code	Description
0	Pas d’erreur
7	Opération non autorisée (IOControl="3" pour une lecture)
10	Equipement non trouvé

Ecriture des programmes horaires

La demande d’écriture des programmes horaires d’un équipement de la base binaire utilisée par le serveur DevI/O est réalisée par saisie du mnémonique dans la rubrique Equipement puis en cliquent sur le bouton Ecriture PH.

L’écriture des programmes horaires se réalise par sélection d’un fichier XML contenant le descriptif des programmes horaires. L’utilisateur est alors invité à sélectionner le fichier XML décrivant les programmes horaires à écrire dans l’équipement.

Le fichier XML doit posséder les attributs suivants pour qu’il soit pris en compte :

• « Name="Planning" » correspondant au mnémonique de l’entité fichier de DevI/O,
• « Equipment="\<mnémonique équipement saisi>" »
• « IOControl="2" » code correspondant au code de demande d’écriture de fichier dans le serveur DevI/O. Si les programmes horaires avaient préalablement été lus (3), il suffit de modifier ce code,

• « Status="0" » code correspondant au code de statut correct si les programmes horaires avaient préalablement été lus.

  Le tableau suivant présente les codes d’erreurs qui peuvent survenir lors d’une suppression de fichier.

Codes d’erreurs possibles lors de l’écriture des programmes horaires

Code	Description
0	Pas d’erreur
7	Opération non autorisée (IOControl="2" pour une écriture)
10	Equipement non trouvé

exemple de fichiers

Demande d’autodécouverte

Le format du fichier XML d’une demande d’autodécouverte est le suivant :

\<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

\<DiscoveryRequest>

\<Device Name="{mnémonique équipement}"

Pin="-p1 {login}-p2 {mot de passe}"

Model="{nom modèle}">

\<DeviceParameters Address="adresse équipement"

Parameters="{paramètres équipements}">

\</DeviceParameters>

\<DeviceCall>

\<Call Address="{adresse d'appel}"

Kind="{type}" Parameters="">

\</Call>

\</DeviceCall>

\<Import Tool="" PathFile="">

\</Import>

\</Device>

\</DiscoveryRequest>

Demande d’import

Le format du fichier XML d’une demande d’import est le suivant :

\<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

\<ImportRequest>

\<Device Name="{mnémonique équipement}"

Pin="-p1 {login}-p2 {mot de passe}"

Model="{nom modèle}">

\<DeviceParameters Address="{adresse équipement}" />

\<DeviceCall>

\<Call Address="{adresse d'appel}"

Kind="{type}" />

\</DeviceCall>

\<Import Tool="{Format}"

PathFile="{chemin complet du fichier contenant le paramétrage}" />

\</Device>

\</ImportRequest>

Réponse d’autodécouverte, d’import ou d’autoconfiguration

Les fichiers XML de réponse d’autodécouverte, d’import ou d’autoconfiguration sont similaires.

L’entête du fichier XML d’une réponse à ces demandes est le suivant :

\<?xml version="1.0" encoding="UTF-8"?>

\<DevIODbUpdate DevIO="{version DevIO}" DLL="0.0"

Interface="DEVIOSRV{mnémonique IE}"

ResultatDecouverte="{résultat découverte}"

DateTime="{date heure}">

\<Device Mnemonic="{mnémonique équipement}"

Modele="{nom modèle}"

NumeroTelephone="{adresse d'appel}"

ResultatDecouverte="{résultat découverte}">

\<Parameters>

\<Others>

\<NoBlocks/>

\<AllBlocks/>

\<AllHistoricals/>

\<AllFiles/>

\</Device>

\</DevIODbUpdate>

Ce format de fichier est décrit dans le document « 16 - Importation XML.pdf »

Demande de suppression

Le format du fichier XML d’une demande de suppression d’équipement est le suivant :

\<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

\<DeleteRequest>

\<Device Name="{mnémonique équipement}">

\</Device>

\</DeleteRequest>

Réponse de suppression

Le format du fichier XML d’une réponse à une demande de suppression est le suivant :

\<?xml version="1.0" encoding="UTF-8"?>

\<DeleteRequest ResultatDecouverte="{résultat découverte}">

\<Device Name="{mnémonique équipement}">

\</Device>

\</DeleteRequest>

Demande de lecture des programmes horaires

Le format du fichier XML d’une demande de lecture des programmes horaires est le suivant :

\<?xml version="1.0"?>

\<DevIOFileOrder>

\<File Name="Planning" Equipment="{mnémonique équipement}" IOControl="3" Status="0"/>

\</DevIOFileOrder>

Réponse de lecture des programmes horaires

Le format du fichier XML d’une réponse à une demande de lecture des programmes horaires est le suivant :

\<?xml version="1.0"?>

\<DevIOFileOrder>

\<File Name="Planning" Equipment="{mnémonique équipement}" IOControl="3" Status="0"/>

\<Plannings>

Description des programmes horaires

\</Plannings>

\</DevIOFileOrder>

Demande d’écriture des programmes horaires

Le format du fichier XML d’une demande d’écriture des programmes horaires est le suivant :

\<?xml version="1.0"?>

\<DevIOFileOrder>

\<File Name="Planning" Equipment="{mnémonique équipement}" IOControl="2" Status="0"/>

\<Plannings>

Description des programmes horaires

\</Plannings>

\</DevIOFileOrder>

Remarque : une demande d’écriture de programmes horaires est quasiment identique à une réponse de lecture de programmes horaires ; seul le champ « IOControl= » diffère.

Réponse d’écriture des programmes horaires.

Le format du fichier XML d’une réponse à une demande d’écriture des programmes horaires est identique à la demande d’écriture de ces programmes horaires ; le statut (« status= ») de la réponse reflétant alors le statut réel de la demande.

ENRICHIR VOTRE PROJET A travers un client OPC UA

Le serveur OPC UA de DevI/O peut agir en tant qu’intermédiaire entre une application cliente et les répertoires de dépose des fichiers. Pour cela, les points suivants sont disponibles dans le serveur OPC UA :

• Server._CONFIG_REQUEST

  ce point de type ‘chaine de caractères’ accepte le contenu XML qui aurait été placé dans un fichier déposé dans le répertoire « Request »

  Les formats XML acceptés dans ce point sont ceux de l’autodécouverte, de l’import et de l’autoconfiguration. Pour l’import, afin de contourner la difficulté de transférer le fichier à importer sur le serveur DevI/O avant de faire la demande, la syntaxe du fichier requête a été modifiée pour accepter la balise « ImportData » à la place de la balise « Import », comme dans l’exemple suivant :

  \<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

  \<ImportRequest>

  \<Device Name="{mnémonique équipement}"

  Pin="-p1 {login}-p2 {mot de passe}"

  Model="{nom modèle}">

  \<DeviceParameters Address="{adresse équipement}" />

  \<DeviceCall>

  \<Call Address="{adresse d'appel}" Kind="{type}" />

  \</DeviceCall>

  \<ImportData Tool="{Format}" >

  \<!-- Données à importer, éventuellement dans une balise CDATA -->

  \</importdata>

  \</device>

  \</importrequest>

• Server._CONFIG_RESPONSE

  ce point de type ‘chaine de caractères’ est mis à jour par le serveur DevI/O lorsque la demande de configuration a été traitée. C’est le contenu XML du fichier généré dans le répertoire « Response » qui est affecté à ce point,

• Server._CONFIG_STATUS

  ce point de type ‘entier non signé’ est mis à jour par le serveur DevI/O lorsque la demande de configuration a été traitée. C’est le contenu de l’attribut « ResultatDecouverte » de l’élément XML racine placé dans le point « _CONFIG_RESPONSE »,

• Server._DELETE_REQUEST

  ce point de type ‘chaine de caractères’ accepte le mnémonique de l’équipement à supprimer,

• Server._DELETE_STATUS

  ce point de type ‘entier non signé’ est mis à jour par le serveur DevI/O lorsque la demande de suppression a été traitée.

AdministRation du produit DevI/O

Ce dernier chapitre est consacré à l’administration système et à l’administration applicative du produit DevI/O.

administration systeme

Dans cette partie, nous abordons les sujets relatifs à la configuration du service associé au serveur DevI/O, à la procédure à suivre en cas de mise à jour du produit DevI/O, à la gestion et surveillance des processus, de la mémoire et de l’espace disque.

configuration du service DevI/O en cas de defaillance

A l’issue de la procédure d’installation du produit DevI/O, un nouveau service a été créé (Cf. figure 42 ci-dessous) : Service DevI/O (ou DevI/O service, pour une installation en anglais). Par défaut, le compte de démarrage du Service DevI/O est Système local. Par défaut également, aucun paramétrage spécifique n’a été appliqué, à ce stade, pour traiter les cas de défaillance de ce service.

Figure 42 : Configuration du Service DevIO

Nous recommandons à l’administrateur système, une fois le produit DevI/O installé, de modifier ce paramétrage pour, a minima, tenir compte des cas de défaillance du service. Pour cela, configurer le Service DevI/O comme indiqué sur la figure 43.

Figure 43 : Configuration du Service DevI/O en cas de défaillance

mise a jour du produit

Nous avons détaillé, au chapitre 3, la procédure d’installation du produit DevI/O. Lors d’une mise à jour du produit, c’est cette même procédure qui est applicable.

Avant toute mise à jour ou réinstallation du produit, il convient d’arrêter le serveur DevI/O mais également de fermer les interfaces graphiques, associées aux composants DevI/O Studio, DevI/O configuration XML et DevI/O Tray icon, qui seraient ouvertes.

A l’issue de la mise à jour ou réinstallation, il faudra remettre à disposition le projet DevI/O courant ainsi que les différents fichiers de configuration (Cf. partie relative à l’administration applicative), notamment ceux utilisés pour la communication avec les applications, à repositionner dans le répertoire C:\Program Files (x86)\DevIO\Bin, par défaut.

surveillance des processus, memoire et espace disque

En dehors du processus DevioSvc lui-même, le démarrage du serveur DevI/O entraine le démarrage de tous les processus, qui ont été définis dans le projet DevI/O courant, à savoir : les processus associés aux interfaces applicatives et ceux associés aux interfaces d’échanges et interfaces de type canal.

Le serveur DevI/O peut être configuré pour surveiller ses différents processus et nous verrons comment mettre en place ce paramétrage dans la partie qui suit (Cf. partie relative à l’administration applicative). En dehors de cette surveillance applicative, l’administrateur système peut en complément installer des outils de monitoring additionnels, pour informer et prévenir l’équipe d’astreinte, en cas de disparition d’un processus ou d’une augmentation de la taille mémoire d’un processus.

Une augmentation importante de l’utilisation de l’espace disque, causée par le produit DevI/O, peut également se produire dans les deux cas suivants :

• lors de l’ajout d’équipements dans le projet DevI/O. Dès la mise en œuvre du projet DevI/O, il convient donc d’anticiper ce point en positionnant le projet sur un espace disque dédié et surveillé (qui peut-être un espace disque distant et partagé),
• ou lors de la mise en place des logs. Lors de l’installation, l’option Suppression automatique des logs est proposée et permet, pour rappel, de mettre en place deux scripts de suppression des logs générés, par le serveur DevI/O et les interfaces applicatives, d’une part, et par les protocoles et les canaux de communication, d’autre part. Par défaut, ces scripts sont configurés pour supprimer les fichiers logs qui ont plus de 7 jours, mais ce paramètre (nombre de jours de conservation des fichiers logs, fixé à 7, par défaut) peut être modifié. Il est important de vérifier, après l’installation, que ces deux tâches s’effectuent correctement : en effet, l’exécution de scripts PowerShell sur votre ordinateur ou serveur, dépend de la politique de votre entreprise en matière de sécurité.

administration applicative

Dans cette partie, nous abordons les sujets relatifs au maintien en condition opérationnelle du produit DevI/O qui passe par une surveillance « applicative » du produit, un diagnostic des incidents nécessitant la mise en place des logs et enfin, une sauvegarde régulière du projet et des fichiers de configuration des interfaces applicatives mises en œuvre.

auto-surveillance des processus et appel cyclique applicatif

Le produit DevI/O intègre un mécanisme d’autosurveillance de l’ensemble de ces processus, que sont les interfaces applicatives, les protocoles et les canaux de communication. Le serveur DevI/O, moteur central du produit, est capable de surveiller l'état de ses différents processus (qu’il a lui-même démarré), de détecter d’éventuelles défaillances et de prendre les actions correctives qui s’imposent comme la réinitialisation d’une connexion ou la relance d’un processus. Ce mécanisme peut être mis en place, dans la partie dédiée à la configuration du Serveur du projet DevI/O courant (Cf. figure 44), à travers le positionnement de deux paramètres situés dans le volet Surveillance :

• Interfaces délai

  qui permet de définir la durée minimale de bon fonctionnement des interfaces pour autoriser une relance,

• Interfaces relances

  qui permet de définir le nombre maximum de relances des interfaces (0 pour infini).

  Pour expliciter le paramétrage en prenant un exemple, dans le cas d’une configuration identique à celle présentée sur la figure 44 (configuration que nous conseillons), chaque interface sera systématiquement relancée excepté dans le cas où cette interface dysfonctionne deux fois consécutivement sur une période de temps de 10 secondes.

Figure 44 : Configuration du mécanisme d’auto-surveillance des processus

Dans votre application globale, le produit DevI/O est certes un élément important de la chaîne, qui relie vos applications à vos équipements et réciproquement, mais ce n’est qu’un élément de cette chaîne. Nous recommandons donc, en dehors du mécanisme d’autosurveillance intégré au produit DevI/O, qu’un mécanisme « d’appels cycliques » (avec acquittement, idéalement), étendu à l’ensemble de l’application soit mis en place. L’objectif est de tester régulièrement un flux descendant, de l’application vers l’équipement, et un flux montant, de l’équipement vers l’application. Cela permettra de suivre régulièrement deux indicateurs :

• la disponibilité de l’application, indicateur obtenu après avoir vérifié que les messages échangés sont bien arrivés à destination voire sont bien revenus à la source (en cas d’acquittement) et ont donc bien traversé toutes les couches logicielles et matérielles intermédiaires,
• le temps de réponse de l’application, indicateur obtenu après avoir analysé les horodatages associés aux différents messages.

diagnostic des incidents

Pour faciliter l’analyse d’un incident a posteriori, le produit DevI/O autorise la mise en œuvre de différents niveaux de logs. Vous trouverez, à travers les copies d’écrans présentées ci-dessous, des informations concernant le paramétrage à suivre, dans le projet DevI/O courant, pour générer les différents fichiers logs : au niveau du serveur DevI/O (Cf. figure 45), des interfaces d’échanges (Cf. figure 47) et des canaux de communication (Cf. figure 46).

Figure 45 : Mise en place des logs au niveau du serveur

Figure 46 : Mise en place des logs au niveau du canal Figure 47 : Mise en place des logs au niveau du protocole

L’interruption anormale d’un processus DevI/O peut entraîner la création automatique d’un fichier de vidage ou mini-dump. Ce fichier contient une image de la mémoire au moment où le processus a disparu et permet de faciliter notre diagnostic, quand il nous a été transmis. En fonction du mode de lancement du serveur DevI/O, les fichiers dump générés peuvent être localisés dans différents répertoires : C:\Users\\<UserName>\AppData\Local\ Temp\technilog\ ou C:\Windows\Temp.

Enfin, dans le cas d’un blocage d’un des processus DevI/O et avant un redémarrage de ce processus, il est important de générer manuellement un fichier de vidage. Pour cela, ouvrir le Gestionnaire des tâches, se positionner dans l’onglet Détails, sélectionner le processus, faire un clic-droit sur ce processus et choisir Créer un fichier de vidage (cf. figure 48). Vous pourrez ensuite nous adresser ce fichier, une fois généré.

Figure 48 : Création d’un fichier de vidage

Pour nous aider à mieux vous répondre, pensez à préparer - voire à nous fournir lors de vos demandes - un ensemble de « pièces » dont nous pourrions avoir besoin : votre projet DevI/O, les fichiers « logs » associés et les éventuels fichiers « dumps » qui auraient pu être générés.

sauvegarde du projet et des fichiers de configuration

De façon à avoir la capacité de restaurer rapidement un projet DevI/O et en dehors de la mise en place des mécanismes de redondance qui assurent ce travail, il est important de sauvegarder régulièrement votre projet DevI/O. En effet, le projet est la partie « vivante » ou dynamique du produit, qui s’enrichit au fil des configurations de vos équipements et des acquisitions des valeurs courantes et des historiques de mesures et d’alarmes. Cette sauvegarde nécessitera de stopper le serveur DevI/O puis de sauvegarder le répertoire racine de votre projet (situé par défaut dans C:\Program Files (x86)\DevIO\Data\Bases).

De la même façon, il est conseillé de sauvegarder les fichiers de configuration associés aux interfaces applicatives que vous mettez en œuvre (OPC UA, MQTT, Archivage, ...), à chaque modification d’un de ces fichiers.

conclusion

Que de chemin parcouru depuis les premières pages de ce document dont la lecture touche à sa fin.

Après une présentation générale du produit DevI/O, de ses concepts et des différents composants mis à votre disposition, vous avez voyagé au sein des différents chapitres, pour apprendre à installer le produit, le configurer, l’exploiter et enfin, l’administrer.

Le moment est maintenant venu pour vous de mettre en pratique et d’expérimenter vos nombreux acquis.

Bien entendu, notre équipe Support sera à vos côtés dans cette aventure et se tient à votre disposition pour vous assister dans les différentes tâches que vous aurez à effectuer ... et continuer à vous former.

A très bientôt.