Device et Module
En standard Sisal interagit avec le monde extérieure à l'aide des équipements standards (field bus) et des modules standards (base produits, horloge, ...). Les équipements sont définis dans la rubrique [equipment] et les modules dans la rubrique [Module] du fichier de configuration.
Afin de pouvoir s'adapter à toute sorte d'environnement, Sisal permet de définir des classes et des objets s ’interfaçant au monde extérieur, ce sont les devices et les modules.
La déclaration de ces classes est faite dans la nouvelle rubrique [Include] du fichier de configuration, en déclarant un nouveau fichier d'inclusion ; ces fichiers définissent une ou plusieurs classes héritées des classes Device (mot réservé) et Module (mot réservé).
[Include] inc1 = Poste_robotise.sch inc2 = Compteur_electrique.sch
Les fichiers d ’inclusion pourraient définir :
Poste_robotise class device lib "robot_412" begin create( gamme, adresse string) integer alias "prob_create"; update( tick date) Dword alias "prob_update"; end;
compteur_electrique class device lib "compteur_s10c4" begin create( adresse string) integer alias "extdvc_create"; get() alias « extdvc_get » ; remise_a_zero() ; consommation _totale float sys 2; end;
Un module est un objet d'une classe qui dérive de la classe Module et donc dispose de la méthode Unlock(), cette méthode permet à Sisal de libérer la ressource à la fin de l'exécution d'une clause ; elle est définie par défaut dans la classe module.
Un device est un objet d'une classe qui dérive de la classe Device et donc dispose des méthodes Update( datation) et Unlock() ; la méthode Update permet à Sisal de réactiver périodiquement un device et de savoir si ce dernier a levé un ou plusieurs événements.
Un device ou un module peuvent être déclarés dans la rubrique [Module] du fichier de configuration, les paramètres de la déclaration seront les paramètres d'appel de la méthode Create.
Un device ou un module peuvent être déclarés dans la rubrique [Equipment] du fichier de configuration ; ils sont alors considérés comme des équipements de production et sont associés à une gamme de production (cf.Rubrique Equipment). La gamme de production est toujours le premier paramètre de l'objet et donc le premier paramètre d'appel du Create.
Par exemple
[Equipment] PR_chargement = Poste_robotise; fChargement , fRessort; « 192.168.0.1 » ; PR_dechargement = Poste_robotise; fCollage | fDechargement; « 192.168.0.2 » ;
[Module]
Dans cet exemple on voit que le device Compteur_electrique est complètement géré par une bibliothèque externe à Sisal (compteur_sc104.dll sous windows et libsisal_compteur_sc104.so sous linux) ; on dit qu'il s'agit d'un équipement « extérieur » car toutes ces valeurs et ses traitements sont gérés à l'extérieur de sisal [1] , sisal ne connaît que l'interface.
Inversement dans le fichier d'inclusion on peut définir un équipement ou un module complètement défini en langage de script sisal ; dans ce cas là on dit qu'il s'agit d'un équipement ou d'un module « interne ».
Cette librairie extérieure n'est pas fournie par Sisal mais par le fabricant du compteur électrique ou un fournisseur tiers ; cette librairie est définie par une interface standardisée (cf.annexe) et en particulier les données échangées sont typées ( entier, flottant, chaîne ce caractère et date).
Données échangées
La librairie extérieure définit des données identifiées dans l'interface par l'attribut Sys (par exemple consommation_totale est le premier attribut « sys 0 » défini dans l'interface). Toutes ces variables pourront être échangées avec les méthodes get (mot réservé) et put (mot réservé) que doit définir la librairie.
La librairie extérieure peut définir des événements et des itérateurs [2] ., ce typage est fait au vol par Sisal mais doit donc être précisé dans l'interface (par exemple la valeur consommation_totale est de type flottant).
Méthodes
La librairie extérieure définit des méthodes pouvant être appelées par Sisal, une librairie pouvant gérer plusieurs classes, le lien entre une méthode d'une classe et sa fonction est faite par l'attribut alias qui définit le nom de la fonction dans la librairie, en l'absence de l'attribut alias sisal recherche la fonction de nom le nom de la méthode.
Une librairie extérieure peut définir plusieurs classes, lorsque sisal veut créer un équipement ou un module à la librairie, il appelle la méthode create définie dans sa classe. Cette méthode rend un identifiant d'objet maintenu par la librairie extérieure. Chaque fois que sisal a besoin de référencer cet objet il transmettra cet identifiant, en particulier pour demander sa destruction avec la méthode delete (mot réservé).
La méthode update (mot réservé) est appelée régulièrement par sisal pour chaque objet, cette méthode effectue le travail qu'elle a à faire et rend un compte-rendu indiquant à sisal si des événements ont été levés depuis le dernier appel à Update.
Ce compte-rendu est pour les équipements et modules externes [3] , un champ de bits (d'au moins 32bits), chaque bit correspond à un événement interne associé à une attribut ou événement identifié par son « sys » . Dans notre exemple, si au cours d'un update on constate que la consommation totale a changée, la méthode update retournera 0x04, c'est à dire 2 à la puissance 2 (sysid de consommation_totale).
La méthode unlock est très importante car elle permet de faire fonctionner le mécanisme implicite de protection des données. Cette méthode est définie dans les classes racines (device et module) ;Si vous êtes amenés à la redéfinir, il faut impérativement qu'elle intègre alors un appel à la méthode de la classe racine [4] .
mon_module class module begin unlock() ; // Redéfinition et donc masquage de module.unlock() end ;
monmodule.unlock() begin module.unlock() ; // Appel du deverrouillage systeme end
La méthode print (mot réservé) est utile (mais pas nécessaire) car elle est utilisée par le débogueur pour afficher les données caractéristiques d'un équipement ou d'un module.
Les méthodes save et restore sont appelées respectivement à l'arrêt de sisal pour que l'objet puisse sauvegarder ses données propres dans un contexte commun et au démarrage de sisal pour que chaque objet déclaré dans le fichier de configuration puisse retrouver ses données propres lors de la dernière sauvegarde du contexte.
Visibilité des devices et modules
La configuration générale d'une application sisal est définie dans le fichier de configuration général Sisal.ini.
Dans ce fichier on peut avoir plusieurs déclarations dans la rubrique [MonApplication/Line], chaque ligne est ce que l'on appelle un topic. Par exemple un serveur qui gère la domotique de plusieurs bâtiments aura autant de topics que de bâtiments gérés. Les équipements et modules déclarés dans ce module ont une visibilité générale préfixé par le nom du topic ( topic1.monmodule.monattribut), l'ensemble de tous les équipements et modules des topics définissent l'environnement.
Dans ce même fichier de configuration, on peut déclarer un ou plusieurs serveurs dans la rubrique [MonApplication/Server], généralement on en a un seul mais pour des raisons de simplifications on peut décider d'en avoir plusieurs. A chacun de ces serveurs est associés un environnement d ’exécution que l'on appelle une librairie. Par définition, cette librairie ne peut pas publier le contenu de ses données (variables globales), si elle doit communiquer avec une autre librairie elle doit utiliser des éléments définis dans l'environnement.
L'introduction des devices et modules a nécessité d'associer un environnement d'exécution sisal à chaque topic, cette environnement d'exécution a une fonction principale exécutée périodiquement la méthode update sur chacun des devices et modules, et des fonctions accessoires de sauvegarde save et de restauration restore .
Donc maintenant sur un environnement simple de sisal on a généralement deux environnements d'exécution un sur le topic et un sur le server [5] .
Publication des données de device et module interne
Les équipements et modules internes peuvent utiliser des données propres que l'on ne souhaite pas diffuser à l'extérieur, elles sont alors déclarées normalement ; par contre les données que l'on veut rendre visible à l'extérieur de la libraire doivent être suffixées par le mot-réservé « public ».
[1] Généralement les librairies extérieures sont écrites en langage C, et donc l'interface est celle du langage C ; si vous êtes amenés à développer une librairie dans un autre langage, intégrez une interface de conversion du C vers votre langage.
[2] Seuls les itérateurs des équipements et modules externes peuvent être définis aujourd'hui (version 4.7), les équipements et modules internes peuvent faire l ’équivalent d'un itérateur avec une variable sisal.
[3] Les équipements et modules internes n'ont pas besoin de ce mécanismes car pendant l ’exécution d'update ils peuvent directement modifier un attribut ou lever un événement tout chose qui sera prise en compte par Sisal.
[4] Sinon sisal peut se bloquer ... et vous n'y comprendrez rien.
[5] Il est donc conseillé d'avoir le nom de topic et le nom de serveur différents afin que les fichiers de traces et de dump de ces deux environnements d'exécutions soient différents.