MODULE No 15

Nom : Nombres et normes pour l’interopérabilité

But : Montrer comment le modèle de qualité de ISO 9126 est plus facile à comprendre quand on introduit des mesures et des normes.

Antécédents : Module 04 bis.

Corps : Interopérabilité

Considérons l’interopérabilité et allons voir ce que la norme ISO 9126-2 (celle concernant les mesures externes) propose :

Facilité d’échange des données fondé sur le format des données. X = A/B où A est le nombre de formats de données qui ont été échangés avec succès et B le nombre total d’échanges.

Facilité d’échange des données fondé sur les tentatives des utilisateurs.

X = A/B où A nombre de fois dans lesquelles l’utilisateur n’a pas réussi à échanger des données et B le nombre de tentatives.

Y = A/T où A est le même de la formule précédente et T est la période de temps.

Voyons maintenant l’interopérabilité en tant qu’attribut de la qualité interne (ISO 9126-3)

Facilité d’échange des données fondé sur le format des données. X = A/B où A est le nombre d’interfaces qui ont été correctement mises en œuvre selon les spécifications et B le nombre total de format de données qui doivent être échangés selon les spécifications.

Cohérence de l’interface. X = A/B où A est le nombre des protocoles d’interfaces qui mettent en œuvre des formats cohérents avec les spécifications. (cohérence vérifiée lors d’une revue) et B le nombre des protocoles d’interfaces qui doivent être mis en œuvre selon les spécifications.

En considérant les quatre attributs mesurables cette de l’interopérabilité, on peut voir les impacts de la qualité interne sur la qualité externe : si lors des revues on détecte des incohérences, il y aura moins d’erreurs lors des tests — ce qui n’est pas difficile à accepter.

Mais… Mais… qu’est-ce que l’interopérabilité au-delà de ces mesures ? Comment peut-on connaître le format et les protocoles corrects ? Via des documents et probablement des normes si on veut dépasser l’étendue d’une entreprise et des normes internationales si on veut une interopérabilité étendue à toute la terre.

Il est clair que si l’on veut une interopérabilité à niveau des applications (ce qui est important pour les clients et les utilisateurs) il ne suffit pas que les protocoles des sept couches du modèle OSI soient interopérables. Il faut que la sémantique des données « portées sur le dos de la couche application » soit partagée. Il faut aussi (surtout ?) que l’on restreint le domaine d’application. Note : il ne suffit pas de dire que les applications échangent des données en XML selon un certain schéma ! Fin de la note.

Pour éclaircir les problèmes liés à l’interopérabilité, on considérera les postes de production et de transport d’électricité dont l’interopérabilité a été normalisée avec la série de normes IEC 61850.

Exemple avec IEC 61850

Il s’agit d’une série de 10 normes pour un total de plusieurs centaines de pages qui s’appliquent à des systèmes pour commander à distance et protéger des postes de répartition et de transport de l’énergie électrique.

Les systèmes sont des systèmes distribués sur un réseau local de type IEEE-802.3 doté de la pile de protocoles suivante :

Pile pour les services client-serveur (IEC 61850 pour HQ)

Couche OSI

Spécification du protocole (PDU)

Application

ISO 9506-2:2003  et ISO/CEI 8560 1996

Présentation

ISO/CEI 8823-1 1994 et ISO/CEI 8825

Session

ISO/CEI 8327-1 1997.

Transport

RFC 1006, RFC 792 et RFC 793

Réseau

RFC 791 et RFC 894

Liaison de données

RFC 894

ISO 8802.3 : 2001

Cette pile permet d’échanger des données entre les ordinateurs (Intelligent Electronic Device, dans le jargon de la norme) branchés sur le réseau local et reliés à l’équipement du poste. Même la couche application ne permet pas d’interpréter les données de l’application (le protocole d’application est trop général et, en un certain sens, générique). Il faut donc une « entente » à niveau des processus d’application : ceux qui emploient les services de la couche application.

Voici un extrait d’un fichier pour paramétrer une application dans le cadre d’un système qui suit les normes IEC 61850.

<?xml version="1.0" encoding="UTF-8"?> <SCL  xmlns="http://www.iec.ch/61850/2003/SCL"

http://www.iec.ch/61850/2003/SCL  SCL.xsd

">

(…)

<Substation desc="Baden" name="S12">

<PowerTransformer name="T1" type="PTR" virtual="false">

(…)

<Address>

<P type="MAC-Address">01-0C-CD-01-00-01</P>

<P type="APPID">3000</P>

<P type="VLAN-PRIORITY">4</P>

</Address>

Substation, PowerTransformer, PTR… qui sont des concepts du domaine électrique et MAC-Adress qui est un concept du domaine des protocoles, par exemple, doivent être interprétés de la même façon par les applications de tous les ordinateurs.

Mais que veut dire : « interpréter de la même façon PTR ? »

Que toutes les fonctions et les données de PTR (une classe) soient connues par toutes les applications. De plus, les classes qui collaborent avec PTR pour exécuter les fonctions doivent être connues.

Pour atteindre cet objectif la norme définit une hiérarchie de classes dont les feuilles sont des types de base (certains types sont une simple redéfinition de types primitifs comme INTEGER, LONG, etc.)

La norme définit aussi, pour chaque donnée, un attribut de qualité (Encore !) qui dit si la donnée est valide et qui donne la cause de la non validité, quand la donnée est invalide : dépassement des limites, donnée trop vieille, problèmes de matériel…

Note : cette qualité est une mise en œuvre à niveau de la norme d’une exigence de qualité plus générale : fiabilité des données. On voit ici à l’œuvre un principe important dans le développement des logiciels et dans toute approche technique à des problèmes moindrement complexes : une exigences (quoi) peut se préciser dans une manière de mettre en œuvre (comment) qui devient une exigence (quoi) pour un pas ultérieur dans la mise en œuvre (comment) qui à son tour peut devenir une exigences (quoi) qui… Fin de la note

Conséquents : Connaissance des mesures d’interopérabilité et une meilleure maîtrise du modèle ISO 9126

Notes 01 :