Exigences gnrales pour les instruments de mesure contrls par logiciel

General requirements for software controlled measuring instruments

OIM

L D

31 E

ditio

n 20

08 (F

)

OIML D 31

Edition 2008 (F)

ORGANISATION INTERNATIONALEDE MTROLOGIE LGALE

INTERNATIONAL ORGANIZATIONOF LEGAL METROLOGY

DOCUMENTINTERNATIONAL

OIML D 31:2008 (F)

3

Sommaire Avant -propos ...................................................................................................................................................... 4

1 Introduction ............................................................................................................................................. 5

2 Champ et domaine dapplication ........................................................................................................... 5

3 Terminologie ............................................................................................................................................ 6 3.1 Terminologie gnrale............................................................................................................................... 6 3.2 Abrviations ............................................................................................................................................ 13

4 Instructions pour utiliser ce Document lors de la rdaction de Recommandations OIML............ 13

5 Exigences relatives aux logiciels des instruments de mesure............................................................. 14 5.1 Exigences gnrales................................................................................................................................. 14 5.2 Exigences spcifiques aux configurations ............................................................................................... 18

6 Approbation de type.............................................................................................................................. 31 6.1 Documentation soumettre pour lapprobation de type.......................................................................... 31 6.2 Exigences pour la procdure dapprobation ............................................................................................ 32 6.3 Mthodes de validation (examen du logiciel).......................................................................................... 34 6.4 Procdure de validation ........................................................................................................................... 40 6.5 Equipement soumis lessai (EUT) ........................................................................................................ 42

7 Vrification............................................................................................................................................. 42

8 Evaluation des niveaux de svrit (risque) ........................................................................................ 42

Annexe A Bibliographie.................................................................................................................................... 44

Annexe B Exemple de Rapport dEvaluation Logicielle .................................................................................. 47

Annexe C Index................................................................................................................................................. 53

OIML D 31:2008 (F)

4

Avant-propos

LOrganisation Internationale de Mtrologie Lgale (OIML) est une organisation intergouvernementale mondiale dont lobjectif principal est dharmoniser les rglementations et contrles mtrologiques mis en uvre par les services nationaux de mtrologie, ou organismes apparents, de ses Etats Membres. Les principales catgories de publication de lOIML sont :

Les Recommandations Internationales (OIML R), qui sont des modles de rglementations fixant les caractristiques mtrologiques dinstruments de mesure et les mthodes et moyens de contrle de leur conformit; les tats Membres de lOIML doivent, dans la mesure du possible, mettre en application ces Recommandations;

Les Documents Internationaux (OIML D), qui sont de nature informative et destins amliorer lactivit des services de mtrologie;

Les Guides Internationaux (OIML G), qui sont de nature informative et qui sont destins donner des directives pour la mise en application la mtrologie lgale de certaines exigences; et

Les Publications de Base Internationales (OIML B), qui dfinissent les rgles de fonctionnement des diffrentes structures et systmes OIML.

Les projets de Recommandations, Documents et Guides OIML sont labors par des Comits Techniques ou Sous-Comits Techniques composs de reprsentants dtats Membres. Certaines institutions internationales et rgionales y participent galement titre consultatif. Des accords de coopration ont t conclus entre lOIML et certaines institutions, telles que lISO et la CEI, pour viter des prescriptions contradictoires; en consquence les fabricants et utilisateurs dinstruments de mesure, les laboratoires dessais, etc. peuvent appliquer simultanment les publications OIML et celles dautres institutions. Les Recommandations internationales, Documents et Guides sont publis en franais (F) et en anglais (E) et sont rviss priodiquement. De plus lOIML participe la publication de Vocabulaires (OIML V) et mandate priodiquement des Experts en mtrologie lgale pour rdiger des Rapports dExpert (OIML E). Les Rapports dExpert sont dstins fournir des informations et conseils aux autorits de mtrologie, et refltent uniquement le point de vue de leur auteur, en dehors de toute participation dun Comit Technique ou dun Sous-Comit Technique, ou encore de celle du CIML. Ainsi, ils ne refltent pas ncessairement lopinion de lOIML. Cette publication - rfrence OIML D 31, dition 2008 (F) a t labore par le Sous-Comit Technique OIML TC 5/SC 2 Logiciel. Elle a t approuve par le Comit International de Mtrologie Lgale en 2008 pour publication finale.

Les Publications de lOIML peuvent tre tlcharges depuis le site internet de lOIML sous la forme de fichiers PDF. Des informations complmentaires sur les Publications OIML peuvent tre obtenue au sige de lOrganisation : Bureau International de Mtrologie Lgale 11, rue Turgot - 75009 Paris - France Tlphone : 33 (0)1 48 78 12 82 Fax : 33 (0)1 42 82 17 27 E-mail : biml@oiml.org Internet : http://www.oiml.org

OIML D 31:2008 (F)

5

Exigences gnrales pour les instruments de mesure contrls par logiciel

1 Introduction Lobjectif principal de ce Document International est de fournir aux Comits et Sous-Comits Techniques de lOIML des conseils leur permettant dtablir les exigences portant sur les fonctionnalits logicielles des instruments de mesure couverts par les Recommandations de lOIML.

De plus, ce Document International peut servir daide aux Etats Membres de lOIML lors de la transcription des Recommandations OIML dans leur rglementation nationale.

2 Champ et domaine dapplication 2.1 Ce Document International prcise les exigences gnrales applicables aux fonctionnalits logicielles des instruments de mesure et donne des prcisions sur les moyens de vrifier la conformit ces exigences.

2.2 Ce Document doit tre considr par les Comits et Sous-Comits Techniques de lOIML comme une base pour ltablissement dexigences et de procdures spcifiques aux logiciels dans une Recommandation OIML relative certaines catgories dinstruments de mesure (ci-aprs appele Recommandation OIML approprie).

2.3 Les instructions donnes dans ce Document sappliquent uniquement aux instruments de mesure, ou dispositifs lectroniques, contrls par logiciel.

Notes :

Ce Document ne couvre pas toutes les exigences techniques applicables aux instruments de mesure contrls par logiciel. Ces exigences doivent tre indiques dans la Recommandation OIML approprie, par exemple, celles pour les instruments de pesage, celles pour les compteurs deau, etc.

Ce Document traite certains aspects relatifs la scurit des donnes. En plus de ce dernier, les rglementations nationales dans ce domaine doivent tre prises en compte.

Comme les dispositifs contrls par logiciel sont toujours lectroniques, il est galement ncessaire de tenir compte de lOIML D 11 Exigences gnrales pour les instruments de mesure lectroniques.

OIML D 31:2008 (F)

6

3 Terminologie Certaines dfinitions utilises dans ce Document sont conformes au Vocabulaire International des Termes Fondamentaux et Gnraux de Mtrologie (VIM:1993 [1]), au Vocabulaire International des Termes de Mtrologie Lgale (OIML V 1:2000 [8]), au Document International de lOIML Exigences gnrales pour les instruments de mesure lectroniques (OIML D 11:2004 [3]) et certaines Normes Internationales de lISO/CEI. Dans le cadre de ce Document, les dfinitions et abrviations suivantes sont applicables.

3.1 Terminologie gnrale

3.1.1 Solution acceptable Conception ou principe de module logiciel ou dunit matriel, ou conception ou principe dune caractristique qui est considr comme conforme une exigence donne. Une solution acceptable fournit un exemple illustrant comment une exigence donne peut tre respecte, sans prjudice pour les autres solutions respectant galement lexigence.

3.1.2 Expertise de l'historique Fichier continu de donnes contenant un enregistrement horodat des vnements, par exemple des changements de valeur des paramtres dun dispositif, ou les mises jour dun logiciel, ou toutes autres activits rglementairement pertinentes qui pourraient influencer les caractristiques mtrologiques.

3.1.3 Authentification Vrification de lidentit dclare ou prsume dun utilisateur, processus, ou dispositif (par exemple vrification que le logiciel tlcharg a bien pour origine le dtenteur du certificat dapprobation de type).

3.1.4 Authenticit Rsultat du processus dauthentification (succs ou chec).

3.1.5 Systme de contrle [OIML D 11:2004, 3.18]

Systme intgr un instrument de mesure permettant de dtecter et de mettre en vidence les dfauts significatifs.

Note : Mettre en vidence fait rfrence toute rponse approprie de linstrument de mesure (signal lumineux, signal sonore, protection du processus de mesurage, etc.).

3.1.6 Rseau ferm Rseau compos dun nombre fixe de participants ayant une identit, une fonctionnalit et un emplacement connus (voir galement Rseau ouvert).

3.1.7 Commandes Peuvent tre une squence de signaux lectriques (optiques, lectromagntiques, etc.) sur les interfaces dentre ou des codes dans les protocoles de transmission de donnes. Elles peuvent tre gnres par le logiciel de linstrument de mesure/dispositif lectronique/sous-ensemble lectronique (commandes logicielles) ou bien tre gnres par lutilisateur par le biais de linterface utilisateur de linstrument de mesure (commandes utilisateurs).

OIML D 31:2008 (F)

7

3.1.8 Communication Echange dinformations entre deux ou plusieurs units (par exemple modules logiciels, dispositifs lectroniques, sous-ensembles, etc.) suivant des rgles spcifiques.

3.1.9 Interface de communication Interface lectronique, optique, radio ou autre interface technique permettant le transfert dinformations entre les composants dun instrument de mesure (par exemple les dispositifs lectroniques) ou ses sous-ensembles.

3.1.10 Certificat cryptographique Jeu de donnes contenant la clef publique appartenant un instrument de mesure ou personne complte par un identificateur unique du sujet tel que le numro de srie de linstrument de mesure ou le nom ou Numro dIdentification Personnel (PIN) de la personne. Le jeu de donnes est sign par une institution irrcusable laide dune signature numrique. Laffectation de la clef publique un sujet peut tre vrifie en utilisant la clef publique de linstitution irrcusable et en dcryptant la signature du certificat.

3.1.11 Moyens cryptographiques Cryptage des donnes par lmetteur (le programme de stockage ou de transmission) et dcryptage par le rcepteur (programme de lecture) avec pour objectif la dissimulation des informations aux personnes non autorises.

Signer lectroniquement des donnes dans le but de permettre au rcepteur ou utilisateur des donnes de vrifier lorigine de ces donnes, i.e. de prouver leur authenticit.

Note : Pour signer lectroniquement, un systme de clef publique est en gnral utilis, i.e. lalgorithme ncessite une paire de cls dont une doit tre maintenue secrte, lautre pouvant tre publique.

Lmetteur (le programme de stockage ou de transmission) gnre un code de hachage des donnes (voir 3.1.25) et lencrypte avec sa clef prive. Le rsultat est la signature. Le rcepteur (le programme de rception ou de lecture) dcrypte la signature avec la clef publique de lmetteur et compare le rsultat avec le vritable code de hachage des donnes. En cas dgalit, les donnes sont authentifies.

Le rcepteur peut exiger un certificat cryptographique de lmetteur (voir 3.1.10) afin de sassurer de lauthenticit de la clef publique.

3.1.12 Domaine de donnes Emplacement en mmoire dont chaque programme a besoin pour traiter les donnes. En fonction du type de langage de programmation utilis, cet emplacement est dfini par une adresse matrielle ou par des noms symboliques (noms de variables). La taille du plus petit domaine adressable est typiquement un octet, mais la taille nest pratiquement pas limite : elle peut aller de 1 bit (par exemple un drapeau ou un registre) des structures de donnes arbitraires qui peuvent tre aussi grandes que les besoins du programmeur le sont.

Les domaines de donnes peuvent appartenir un module logiciel unique ou plusieurs. Pour les langages de haut niveaux (tels que le JAVA, le C/C++, etc.) il est simple de sparer le domaine de donnes dun module logiciel, afin dinterdire son accs aux autres modules logiciels, grce au langage de programmation lui-mme.

OIML D 31:2008 (F)

8

3.1.13 Paramtre spcifique au dispositif Paramtre rglementairement pertinent ayant une valeur dpendant de lexemplaire de linstrument. Les paramtres spcifiques aux dispositifs comprennent les paramtres dajustement (par exemple lajustement de la pente ou autres ajustements et corrections) ainsi que les paramtres de configuration (par exemple la valeur maximale, valeur minimale, unit de mesure, etc.).

3.1.14 Durabilit [OIML D 11:2004, 3.17] Aptitude dun instrument de mesure maintenir ses caractristiques de performance durant une priode dutilisation.

3.1.15 Instrument de mesure lectronique [OIML D 11:2004, 3.1] Instrument de mesure dstin mesurer une quantit lectrique ou non-lectrique en utilisant des moyens lectriques et/ou quips de dispositifs lectroniques.

Note : Pour les besoins de ce Document, les quipements complmentaires, dans la mesure o ils sont soumis au contrle de la mtrologie lgale, sont considrs comme faisant partie de linstrument de mesure.

3.1.16 Dispositif lectronique [OIML D 11:2004, 3.2]

Dispositif qui utilise des sous-ensembles lectroniques et qui accomplit une fonction spcifique. Les dispositifs lectroniques sont habituellement fabriqus en tant quunits spares et sont susceptibles dtre tests sparment.

Notes : Un dispositif lectronique peut tre un instrument de mesure complet (par exemple une balance, un compteur lectrique) ou une partie dinstrument de mesure (par exemple une imprimante, un indicateur).

Un dispositif lectronique peut tre un module au sens du terme utilis dans lOIML B 3 Systme de Certificats OIML pour les Instruments de Mesure [2].

3.1.17 Erreur (dindication) [VIM:1993, 5.20; OIML D 11:2004, 3.5] Indication de linstrument de mesure moins la valeur vraie de la grandeur dentre correspondante.

3.1.18 Registre des erreurs Fichier continu de donnes contenant un enregistrement des dfaillances/fautes qui ont une influence sur les caractristiques mtrologiques. Ceci sapplique particulirement aux dfaillances volatiles qui ne peuvent tre identifies ensuite lorsque les valeurs de mesure sont utilises.

3.1.19 Evaluation (de type) [OIML V 1:2000, 2.5] Examen et essai systmatiques des performances dun ou de plusieurs exemplaires dun type (modle) identifi dinstrument de mesure par rapport des exigences documentes et dont le rsultat est contenu dans un rapport dvaluation afin de dterminer si le type peut tre approuv.

3.1.20 Evnement

Action par laquelle une modification dun paramtre, dun facteur dajustement de linstrument de mesure ou la mise jour dun module logiciel est effectue.

OIML D 31:2008 (F)

9

3.1.21 Compteur dvnements Compteur non rinitialisable qui sincrmente chaque fois quun vnement a lieu.

3.1.22 Code excutable Fichier install dans le systme informatique de linstrument de mesure, dispositif lectronique, ou sous-ensemble (EPROM, disque dur, etc.). Ce code est interprt par le microprocesseur et transpos en oprations logiques, arithmtiques, de dcodage ou de transport de donnes.

3.1.23 Faute [adapt de lOIML D 11:2004, 3.9] Dfaut ayant un impact sur les proprits ou fonctions de linstrument de mesure ou causant une erreur dindication suprieure lEMT.

3.1.24 Partie logicielle rsidente rglementairement pertinente Partie du logiciel rglementairement pertinent dans le code excutable qui est et demeure identique celle du type approuv1).

3.1.25 Fonction de hachage [ISO/CEI 9594-8:2001][4] Fonction (mathmatique) qui lie les valeurs dun grand domaine (potentiellement trs grand) une plus petite tendue. Une "bonne" fonction de hachage est telle que les rsultats de lapplication de la fonction une (grande) srie de valeurs dans le domaine seront uniquement distribus (et apparemment alatoirement) sur ltendue.

3.1.26 Intgrit des programmes, donnes et paramtres Assurance que les programmes, donnes, ou paramtres nont pas fait lobjet de changements non autoriss ou non intentionnels en cours dutilisation, de transfert, de stockage, de rparation ou de maintenance.

3.1.27 Interface [ISO 2382-9:1995][5] Limite partage entre deux units fonctionnelles, dfinie par diverses caractristiques se rapportant aux fonctions, aux interconnexions physiques, aux changes de signaux, et autres caractristiques des units, si appropris.

3.1.28 Erreur intrinsque [VIM:1993, 5.24; OIML D 11:2004, 3.7] Erreur dun instrument de mesure, dtermine dans les conditions de rfrence.

3.1.29 Rglementairement pertinent Logiciel/matriel/donne ou partie du logiciel/matriel/donne dun instrument de mesure qui interfre avec les proprits rglementes par la mtrologie lgale, par exemple lexactitude de mesure ou le fonctionnement correct de linstrument de mesure.

1) Cette partie est responsable de la surveillance de la mise jour du logiciel (chargement du logiciel, authentification,

vrification de lintgrit, installation et activation).

OIML D 31:2008 (F)

10

3.1.30 Paramtre rglementairement pertinent Paramtre dun instrument de mesure, dispositif lectronique, ou sous-ensemble sujet au contrle lgal. Les types de paramtre rglementairement pertinent suivants peuvent tre distingus : les paramtres spcifiques au type et les paramtres spcifiques au dispositif.

3.1.31 Partie logicielle rglementairement pertinente Partie de tous les modules logiciels dun instrument de mesure, dispositif lectronique, ou sous-ensemble qui est rglementairement pertinente.

3.1.32 Erreur maximale tolre (dun instrument de mesure) [VIM:1993, 5.21; OIML D 11:2004, 3.6]

Valeur extrme dune erreur tolre par les spcifications, rglements, etc., pour un instrument de mesure donn.

3.1.33 Instrument de mesure [VIM:1993, 4.1] Dispositif destin tre utilis pour faire des mesurages, seul ou associ un ou plusieurs dispositifs annexes.

3.1.34 Mesurage non-interruptible / interruptible Un mesurage non-interruptible est un processus de mesure cumulatif continu sans fin dfinie. Le processus de mesure ne peut tre stopp et poursuivi ultrieurement par lutilisateur ou oprateur sans perturber inacceptablement le mesurage ou lapprovisionnement en bien ou nergie.

Si le mesurage cumulatif de la quantit dune substance peut tre aisment et rapidement arrt en opration normale pas uniquement en cas durgence sans falsifier les rsultats de mesure, alors le mesurage est dnomm interruptible.

3.1.35 Rseau ouvert Rseau participants arbitraires (dispositifs lectroniques ayant des fonctions arbitraires). Le nombre, lidentit et lemplacement dun participant peuvent tre dynamiques et inconnus des autres participants (voir galement rseau ferm).

3.1.36 Performance [OIML D 11:2004, 3.16] Aptitude dun instrument de mesure accomplir les fonctions qui lui sont assignes.

3.1.37 Code programme Code source ou code excutable.

3.1.38 Scellement

Moyen destin protger linstrument de mesure contre toute modification non autorise, rajustement, suppression de partie, logiciel, etc. Il peut tre matriel, logiciel ou une combinaison des deux.

3.1.39 Scuriser Prvenir les accs non autoriss aux parties matrielles et logicielles du dispositif.

OIML D 31:2008 (F)

11

3.1.40 Logiciel Terme gnrique comprenant le code programme, les donnes et les paramtres.

3.1.41 Examen logiciel Opration technique consistant dterminer une ou plusieurs caractristiques du logiciel conformment la procdure spcifique (par exemple lanalyse de la documentation technique ou lexcution du programme dans des conditions contrles).

3.1.42 Identification du logiciel Squence de caractres lisibles (par exemple un numro de version, une somme de contrle) qui est inextricablement lie au logiciel ou au module logiciel ltude. Elle peut tre vrifie sur linstrument en cours dutilisation.

3.1.43 Interface logicielle Code programme et domaine de donnes ddis qui reoivent, filtrent, ou transmettent les donnes entre les modules logiciels (sans quils soient ncessairement rglementairement pertinents).

3.1.44 Module logiciel [similaire CEI 61508-4:1998, 3.3.7][6] Entit logique telle que programme, sous-programme, et objet incluant son domaine de donnes, qui peut tre en relation avec dautres entits. Le logiciel dun instrument de mesure, dispositif lectronique ou sous-ensemble est constitu dun ou plusieurs modules logiciels.

3.1.45 Protection du logiciel Scurisation du logiciel de linstrument de mesure ou du domaine de donnes par la mise en oeuvre de scellement mcanique ou logiciel. Le scellement doit tre retir, endommag, ou bris pour obtenir laccs permettant de changer le logiciel.

3.1.46 Sparation logicielle Le logiciel dun instrument de mesure/dispositif lectronique/sous-ensemble peut tre divis en une partie rglementairement pertinente et une partie non rglementairement pertinente. Ces parties communiquent via une interface logicielle.

3.1.47 Code source Programme informatique crit sous une forme lisible et ditable (langage de programmation). Le code source est compil ou interprt en un code excutable.

3.1.48 Dispositif de stockage Stockage utilis pour conserver les donnes de mesurage disponibles, aprs lachvement du mesurage, des fins ultrieures rglementairement pertinentes (par exemple la conclusion dune transaction commerciale).

OIML D 31:2008 (F)

12

3.1.49 Sous-ensemble [OIML D 11:2004, 3.3] Partie de dispositif lectronique, utilisant des composants lectroniques et ayant par elle-mme une fonction qui lui est reconnue.

Exemples : Amplificateurs, comparateurs, convertisseurs de puissance, etc.

3.1.50 Essai [OIML D 11:2004, 3.20] Srie doprations destine vrifier que lquipement soumis lessai (EUT) est conforme aux exigences spcifies.

3.1.51 Horodatage Valeur de temps unique croissante monotone, par exemple en seconde ou une chane date et heure indiquant la date et/ou lheure laquelle un vnement particulier ou une faute sest produit. Ces donnes sont prsentes dans un format cohrent, facilitant la comparaison de deux enregistrements diffrents et le traage dans le temps.

3.1.52 Transmission des donnes de mesure Transmission des donnes de mesure via des rseaux de communication, ou dautres moyens, un dispositif lectronique distant o elles sont ensuite traites et/ou utilises des fins rglementairement pertinentes.

3.1.53 Paramtre spcifique au type Paramtre rglementairement pertinent ayant une valeur qui dpend uniquement du type de linstrument. Les paramtres spcifiques au type font partie du logiciel rglementairement pertinent.

Exemple : Considrant un ensemble de mesurage de liquides autres que leau, la plage de viscosit cinmatique dune turbine est un paramtre spcifique au type qui est fix par lapprobation de type de la turbine. Toutes les turbines produites de ce mme type, ont la mme plage de viscosit.

3.1.54 Ordinateur universel Ordinateur qui nest pas construit pour une tche spcifique mais qui peut tre adapt aux fonctions mtrologiques laide dun logiciel. En gnral, ce logiciel est bas sur un systme dexploitation qui permet le chargement et lexcution de logiciels, des fins spcifiques.

3.1.55 Interface utilisateur Interface permettant lchange dinformation entre un humain et linstrument de mesure ou ses composants matriels ou logiciels, par exemple, des interrupteurs, un clavier, une souris, un afficheur, un cran, une imprimante, un cran tactile, une fentre logicielle sur un cran incluant le logiciel layant gnre.

3.1.56 Validation [driv de ISO/CEI 14598 et CEI 61508-4:1998][7] Confirmation par lexamen et fourniture de preuves objectives (i.e. informations qui peuvent tre dmontres comme vraies, bases sur des faits obtenus lors dobservations, mesurages, essais, etc.) que les exigences particulires pour lusage spcifique prvu sont respectes. Dans le cas prsent, ces exigences sont celles de ce Document.

OIML D 31:2008 (F)

13

3.1.57 Vrification [V 1: 2000, 2.13] Procdure (autre que lapprobation de type) qui inclut lexamen et le marquage et/ou la dlivrance dun certificat de vrification et qui constate et confirme que linstrument de mesure satisfait aux exigences rglementaires2).

3.2 Abrviations

EUT Equipement soumis lessai CEI Commission Electrotechnique Internationale E/S Entre / Sortie (se rfre aux ports) ISO Organisation Internationale de Normalisation TIC Technologies de lInformation et de la Communication EMT Erreur Maximale Tolre OIML Organisation Internationale de Mtrologie Lgale PCB Carte de Circuit Imprim PIN Numro dIdentification Personnel TC Comit Technique OIML SC Sous-Comit OIML

4 Instructions pour utiliser ce Document lors de la rdaction de Recommandations OIML

4.1 Les dispositions de ce Document sappliquent uniquement aux nouveaux Documents et Recommandations OIML, ainsi quaux Documents et Recommandations en rvision. Les TCs et SCs doivent utiliser ce Document afin dtablir les exigences relatives aux logiciels, en complment des exigences techniques et mtrologiques de la Recommandation OIML approprie.

4.2 Tous les documents normatifs sont soumis rvision. Les utilisateurs de ce Document sont donc encourags envisager la possibilit dappliquer la plus rcente dition de ces documents normatifs.

4.3 Lobjectif de ce Document est de fournir aux TCs ou SCs responsables du dveloppement de Recommandations OIML, des sries dexigences certaines avec diffrents niveaux qui sont appropries pour couvrir les besoins de tout type dinstrument de mesure et cela, dans tous les domaines dapplication. Les TCs et SCs doivent dterminer quel niveau est appropri pour les besoins de protection, de conformit et dintensit de validation, et dterminer comment incorporer les parties pertinentes de ce Document dans les Recommandations en cours de rdaction. Le chapitre 8 fournit quelques aides pour accomplir cette tche.

2) Note : Dfinition diffrente des autres Normes, par exemple ISO/CEI 14598, clause 4.23 or CEI 61508-4, clause 3.8.1.

OIML D 31:2008 (F)

14

5 Exigences relatives aux logiciels des instruments de mesure 5.1 Exigences gnrales

Au moment de publier ce Document, ces exigences gnrales reprsentent ltat de lart des technologies de linformation et de la communication (TIC). Elles sont en principe applicables tous types dinstrument de mesure, dispositifs lectroniques, et sous-ensembles contrls par logiciel et devraient tre considres dans toutes les Recommandations OIML. Contrairement aux exigences gnrales, les exigences spcifiques aux configurations (5.2) traitent des fonctionnalits qui ne sont pas courantes pour certains types dinstrument ou certains domaines dapplication.

Dans les exemples, lorsque applicables, deux niveaux, normal et lev, de svrit sont prsents. Leur notation dans le Document est la suivante :

(I) Solution technique acceptable en cas de niveau normal de svrit,

(II) Solution technique acceptable en cas de niveau lev de svrit (voir 8).

5.1.1 Identification du logiciel Le logiciel rglementairement pertinent dun instrument de mesure/dispositif lectronique/sous-ensemble doit tre clairement identifi avec son numro de version logiciel ou un autre moyen. Lidentification peut tre constitue de plus dune partie mais au moins une delles doit tre ddie lapplication lgale.

Lidentification doit tre inextricablement lie au logiciel lui-mme et doit tre prsente ou imprime la demande ou tre affiche durant le fonctionnement ou au dmarrage des instruments pouvant tre teint et mis en route successivement. Si un sous-ensemble / un dispositif lectronique na ni afficheur ni imprimante, alors lidentification doit tre transmise par le biais dune interface de communication afin dtre affiche/imprime par un autre sous-ensemble/dispositif lectronique.

A titre dexception, la srigraphie de lidentification du logiciel sur linstrument/dispositif lectronique doit tre une solution acceptable si les conditions suivantes sont remplies :

(1) Linterface utilisateur ne doit avoir aucune capacit de contrle pour activer lindication de lidentification du logiciel sur lafficheur, ou lafficheur ne permet pas techniquement la prsentation de lidentification du logiciel (dispositif indicateur analogique ou compteur lectromcanique).

(2) Linstrument/dispositif lectronique ne doit pas avoir dinterface pour communiquer lidentification du logiciel.

(3) Aprs la production de linstrument/dispositif lectronique, un changement du logiciel nest pas possible, ou uniquement possible si le matriel ou un composant matriel est galement chang.

Le fabricant du matriel, ou du composant matriel concern, a la responsabilit de sassurer que lidentification du logiciel est correctement srigraphie sur linstrument/dispositif lectronique concern.

Lidentification du logiciel et les moyens didentification doivent tre dclars dans le certificat dapprobation de type.

Les Recommandations OIML appropries doivent autoriser ou interdire cette exception.

Note : Chaque instrument de mesure en service doit tre conforme au type approuv. Lidentification du logiciel permet aux personnels de surveillance ainsi quaux personnes intresses par le mesurage de dterminer si linstrument considr est conforme.

OIML D 31:2008 (F)

15

Exemple :

(I) Le logiciel contient une chane de texte ou un nombre, identifiant de faon non ambigu la version installe. Cette chane est transfre lafficheur de linstrument quand un bouton est press, quand linstrument est mis en route, ou encore cycliquement contrl par une minuterie.

Un numro de version peut avoir la structure suivante A.Y.Z. Si on considre un dispositif calculateur, la lettre A reprsentera la version du logiciel coeur, qui compte les impulsions. La lettre Y reprsentera la version de la fonction de conversion (aucune, 15 C, 20 C) et la lettre Z reprsentera la langue de linterface utilisateur.

(II) Le logiciel calcule une somme de contrle du code excutable et prsente le rsultat en temps quidentification au lieu de (ou en plus de) la chane en (I). Lalgorithme de la somme de contrle doit tre un algorithme normalis. Par exemple un algorithme de type CRC 16 est une solution acceptable pour ce calcul.

La solution (II) est approprie, si une conformit leve est requise (voir 5.2.5 (d) et 8).

5.1.2 Adquation des algorithmes et fonctions Les algorithmes et fonctions de mesure dun dispositif lectronique doivent tre appropris et fonctionnellement corrects pour le type de dispositif et lapplication considrs (exactitude de lalgorithme, calcul de prix conforme certaines rgles, algorithme darrondi, etc.).

Le rsultat de mesure et les informations laccompagnant, requises par une Recommandation OIML spcifique ou par la rglementation nationale, doivent tre affichs ou imprims correctement.

Il doit tre possible dexaminer les algorithmes et fonctions grce des essais mtrologiques, des essais logiciels ou un examen du logiciel (tel que dcrit en 6.3).

5.1.3 Protection du logiciel 5.1.3.1 Prvention des mauvais usages Un instrument de mesure doit tre construit de telle sorte que les possibilits de mauvais usage non intentionnel, accidentel ou intentionnel soient minimales. Dans le cadre de ce Document OIML, ceci sapplique plus particulirement au logiciel. La prsentation des rsultats de mesure doit tre sans ambigut pour toutes les parties intresses.

Note : Les instruments contrls par logiciel ont souvent des fonctionnalits complexes. Lutilisateur a besoin de bons conseils pour une utilisation correcte et pour obtenir des rsultats de mesure corrects.

Exemple :

Lutilisateur est guid par des menus. Les fonctions rglementairement pertinentes sont combines dans une branche de ce menu. Si des valeurs de mesure peuvent tre perdues lors dune action, lutilisateur doit tre alert et requis deffectuer une autre action avant que la fonction ne soit excute. Voir galement 5.2.2.

OIML D 31:2008 (F)

16

5.1.3.2 Protection contre la fraude 5.1.3.2.a Le logiciel rglementairement pertinent doit tre scuris contre les modifications non autorises, les chargements ou les changements par change de mmoire. En plus des scellements mcaniques, des moyens techniques peuvent tre ncessaires pour scuriser les instruments de mesure ayant un systme dexploitation ou une option de chargement de logiciel.

Note : Lorsque le logiciel est stock sur une mmoire inviolable (sur laquelle les donnes sont inaltrables, par exemple une ROM mmoire en lecture seule scelle), les besoins en moyens techniques sont rduits en consquence.

Exemple :

(I)/(II) Le botier contenant la mmoire est scell ou la mmoire est scelle au PCB.

(II) Si un dispositif rinscriptible est utilis, lentre autorisant lcriture est inhibe par un interrupteur qui peut tre scell. Le circuit est conu de telle sorte que la protection en criture ne peut tre annule par un court-circuit des contacts.

(I) Un instrument de mesure est constitu de deux sous-ensembles dont lun deux contenant les principales fonctions mtrologiques incorpores dans un botier pouvant tre scell. Lautre sous-ensemble est un ordinateur universel avec un systme dexploitation. Certaines fonctions, telle que lindication, sont localises dans le logiciel de cet ordinateur. Une manipulation relativement simple dautant plus si un protocole normalis est utilis pour la communication entre les deux parties du logiciel pourrait tre un change du logiciel de lordinateur universel. Cette manipulation peut tre inhibe par un simple moyen cryptographique, par exemple lencryptage des donnes transfres entre le sous-ensemble et lordinateur universel. La clef de dcryptage est cache dans le programme rglementairement pertinent de lordinateur universel. Ce programme est le seul connatre la clef et est capable de la lire, de dcrypter et dutiliser les valeurs de mesure. Les autres programmes ne peuvent tre utiliss ces fins car ils ne peuvent dcrypter les valeurs de mesure (voir galement lexemple en 5.2.1.2.d).

5.1.3.2.b Seules les fonctions clairement documentes (voir 6.1) sont autorises tre actives par le biais de linterface utilisateur, qui doit tre ralise de telle manire quelle ne facilite pas un usage frauduleux. La prsentation des informations doit tre conforme avec 5.2.2.

Note : Lexaminateur dcide si toutes les commandes documentes sont acceptables.

Exemple :

(I)/(II) Toutes les entres de linterface utilisateur sont rediriges vers un programme qui filtre les commandes entrantes. Il autorise et ne laisse passer que celles qui sont documentes et rejette toutes les autres. Ce programme ou module logiciel fait partie du logiciel rglementairement pertinent.

5.1.3.2.c Les paramtres qui fixent les caractristiques rglementairement pertinentes de linstrument de mesure doivent tre scuriss contre les modifications non autorises. Si ncessaire, et des fins de vrification, le parmtrage courant doit pouvoir tre affich ou imprim.

Note : Les paramtres spcifiques au dispositif peuvent tre ajustables ou slectionnables uniquement dans un mode oprationnel spcifique de linstrument. Ils peuvent tre

OIML D 31:2008 (F)

17

classifis comme ceux devant tre scuriss (inaltrables) ou ceux auxquels une personne autorise peut accder (paramtres rglables), par exemple le dtenteur ou le vendeur de linstrument.

Les paramtres spcifiques au type ont une valeur identique pour tous les exemplaires dun mme type. Ils sont fixs lors de lapprobation de type de linstrument.

Exemple :

(I)/(II) Les paramtres spcifiques au dispositif scuriser sont stocks dans une mmoire non volatile. Lentre autorisant lcriture de la mmoire est inhibe par un interrupteur qui peut tre scell.

Se rfrer aux exemples 5.1.3.2.d (1) (3) de cette section.

5.1.3.2.d La protection du logiciel comprend le scellement par des moyens mcaniques, lectroniques et/ou cryptographiques, rendant toute intervention non autorise impossible ou vidente.

Exemple :

(1) (I) Le scellement lectronique : Les paramtres mtrologiques dun instrument peuvent tre entrs et ajusts grce un lment du menu. Le logiciel reconnat chaque changement et incrmente un compteur dvnements pour chaque vnement de ce type. La valeur du compteur dvnements peut tre indique. La valeur initiale du compteur dvnements doit tre enregistre. Si la valeur indique diffre de la valeur enregistre, linstrument est dans un tat non vrifi (quivalent un scellement bris).

(2) (I)/(II) Le logiciel de linstrument de mesure est construit de telle sorte (voir lexemple 5.1.3.2.a) quil ny a pas de possibilit de modifier les paramtres et la configuration rglementairement pertinente sauf utiliser un menu protg par un interrupteur. Cet interrupteur est scell mcaniquement en position inactive, rendant toute modification des paramtres et de la configuration rglementairement pertinente impossible.

(3) (II) Le logiciel de linstrument de mesure est construit de telle sorte (voir lexemple (a)) quil nest pas possible de modifier les paramtres et la configuration rglementairement pertinente sauf pour les personnes autorises. Si une personne veut entrer dans le menu des paramtres, elle doit insrer sa carte puce contenant un PIN comme partie dun certificat cryptographique. Le logiciel de linstrument est capable de vrifier lauthenticit du PIN avec le certificat et autorise laccs au menu des paramtres. Laccs est enregistr dans une expertise de lhistorique incluant lidentit de la personne (ou au moins la carte puce utilise).

Le niveau (II) des exemples de solution technique acceptable est appropri si un niveau lev de protection contre la fraude est ncessaire (voir 8).

5.1.4 Support des fonctionnalits matrielles 5.1.4.1 Support de la dtection de faute La Recommandation OIML approprie peut exiger des fonctions de dtection de faute pour certaines fautes de linstrument (trait dans lOIML D 11 (5.1.2 (b) et 5.3)). Dans ce cas, il doit tre exig que le fabricant de linstrument conoive les systmes de contrle dans la partie logicielle ou dans la partie

OIML D 31:2008 (F)

18

matrielle ou encore donne les moyens par lesquels la partie matrielle peut tre assiste par la partie logicielle de linstrument.

Si le logiciel est impliqu dans la dtection de faute, une raction approprie est requise. La Recommandation OIML approprie peut prescrire que linstrument/dispositif lectronique soit dsactiv ou quune alarme/un enregistrement dans un registre des erreurs soit gnr dans le cas o une condition de faute est dtecte.

La documentation soumise pour lapprobation de type doit inclure une liste des fautes qui sont dtectes par le logiciel ainsi que la raction attendue et, si ncessaire pour la comprhension, une description de lalgorithme de dtection.

Exemple :

(I)/(II) A chaque dmarrage, le programme rglementairement pertinent calcule la somme de contrle du code programme et des paramtres rglementairement pertinents. La valeur nominale de ces sommes de contrle a t calcule en avance et stocke dans linstrument. Si les valeurs calcules et stockes ne correspondent pas, l'excution du programme est arrte.

Si le mesurage nest pas interruptible, la somme de contrle est calcule cycliquement et contrle par une minuterie logicielle. En cas de dtection de dfaillance, le logiciel affiche un message derreur ou allume un indicateur de dfaillance et enregistre lheure du dfaut dans un registre des erreurs (sil en existe un).

Le CRC 16 est un algorithme de somme de contrle acceptable.

5.1.4.2 Support de la protection de la durabilit Il appartient au fabricant de choisir de raliser les systmes de protection de la durabilit traits dans lOIML D 11:2004 (5.1.3 (b) et 5.4) de manire logicielle ou matrielle, ou de permettre aux systmes matriels dtre assists par logiciel. La Recommandation OIML approprie peut recommander une solution approprie.

Si le logiciel est impliqu dans la protection de la durabilit, une raction approprie est requise. La Recommandation OIML approprie peut prescrire que linstrument/dispositif lectronique soit dsactiv ou quune alarme/enregistrement dans un registre des erreurs, soit gnr dans le cas o la durabilit serait dtecte comme compromise.

Exemple :

(I)/(II) Certaines sortes dinstrument de mesure requirent un ajustement aprs un intervalle de temps prescrit afin de garantir la durabilit des mesures. Le logiciel donne un avertissement lorsque lintervalle de maintenance sest coul et arrte mme de mesurer si celui-ci est dpass de plus dune certaine dure.

5.2 Exigences spcifiques aux configurations

Les exigences donnes dans cette section sont bases sur des solutions techniques typiques pour les TIC. Aussi, elles peuvent ne pas tre communes tous les domaines dapplication lgale. Outre ces exigences, des solutions techniques possibles, prsentant le mme degr de scurit et de conformit au type que les instruments ntant pas contrls par logiciel, sont donnes.

Les exigences spcifiques suivantes sont ncessaires lorsque certaines technologies sont utilises dans les systmes de mesure. Elles doivent tre considres en complment de celles dcrites en 5.1

OIML D 31:2008 (F)

19

Dans les exemples, lorsque applicable, deux niveaux, normal et lev, de svrit sont prsents. Leur notation dans le Document est la suivante :

(I) Solution technique acceptable en cas de niveau normal de svrit,

(II) Solution technique acceptable en cas de niveau lev de svrit (voir 8).

5.2.1 Spcification et sparation des parties pertinentes et spcification des interfaces des parties Les parties mtrologiquement critiques dun systme de mesure quelles soient des parties logicielles ou matrielles ne doivent pas tre inacceptablement influences par les autres parties du systme de mesure.

Cette exigence sapplique si linstrument de mesure (ou le dispositif lectronique, ou le sous-ensemble) a des interfaces pour communiquer avec dautres dispositifs lectroniques, avec lutilisateur, ou avec dautres parties logicielles en dehors des parties mtrologiquement critiques de linstrument de mesure (ou du dispositif lectronique, ou du sous-ensemble).

5.2.1.1 Sparation des dispositifs lectroniques et des sous-ensembles 5.2.1.1.a Les sous-ensembles ou dispositifs lectroniques dun systme de mesure qui ralisent des fonctions rglementairement pertinentes, doivent tre identifis, clairement dfinis et documents. Ils forment la partie rglementairement pertinente du systme de mesure.

Note : Lexaminateur dcide si cette partie est complte et si dautres parties du systme de mesure peuvent tre exclues de toute valuation supplmentaire.

Exemple :

(1) (I)/(II)Un compteur lectrique est quip dune interface optique pour connecter un dispositif lectronique de lecture des valeurs de mesure. Le compteur stocke toutes les quantits pertinentes et conserve les valeurs disponibles la lecture pendant une dure suffisante. Dans ce systme, seul le compteur lectrique est un dispositif rglementairement pertinent. Dautres dispositifs rglementairement non pertinents peuvent exister et peuvent tre connects linterface de linstrument sous rserve que lexigence 5.2.1.1.b est respecte. La scurisation de la transmission des donnes nest pas exige (voir 5.2.3).

(2) (I)/(II) Un instrument de mesure est compos des sous-ensembles suivants: un capteur numrique calculant le poids ou le volume, un ordinateur universel calculant le prix, une imprimante qui imprime les valeurs de mesure et le prix payer.

Tous les sous-ensembles sont connects un rseau local. Dans ce cas, le capteur numrique, lordinateur universel et limprimante sont des sous-ensembles rglementairement pertinents et sont optionnellement connects un systme de vente qui nest pas ncessairement rglementairement pertinent. Les sous-ensembles rglementairement pertinents doivent respecter lexigence 5.2.1.1.b et cause de la transmission par le rseau les exigences de 5.2.3. Il ny a pas dexigence sur le systme de vente.

OIML D 31:2008 (F)

20

5.2.1.1.b Il doit tre dmontr durant les essais dapprobation que les fonctions et donnes pertinentes des sous-ensembles et dispositifs lectroniques ne peuvent pas tre inacceptablement influences par les commandes reues via linterface.

Cela implique quil existe une affectation non ambigu de chaque commande chaque fonction ou changement de donne dans le sous-ensemble ou le dispositif lectronique.

Note : Se rfrer 5.2.3 si les sous-ensembles ou dispositifs rglementairement pertinents interagissent avec dautres sous-ensembles ou dispositifs lectroniques rglementairement pertinents.

Exemple :

(1) (I)/(II) Le logiciel du compteur lectrique (voir exemple (1) de 5.2.1.1.a ci-dessus) est capable de recevoir des commandes pour slectionner les quantits requises. Il combine la valeur de mesure avec des informations additionnelles par exemple lhorodatage, lunit et met ce jeu de donnes vers le dispositif requerrant. Le logiciel accepte uniquement les commandes de slection de quantits valides et autorises et rejette toute autre commande, renvoyant uniquement un message derreur. Le contenu du jeu de donnes peut tre scuris mais ces moyens de scurisation ne sont pas requis puisque le jeu de donnes transmis nest pas soumis au contrle lgal.

(2) (I)/(II) A lintrieur du botier, qui peut tre scell, se trouve un interrupteur qui dfinit le mode opratoire du compteur lectrique : une position de linterrupteur indique le mode vrifi, lautre le mode non-vrifi (des moyens de scurisation autres quun scellement mcanique sont possibles, voir les exemples en 5.1.3.2.a/d). Lors de linterprtation des commandes reues, le logiciel vrifie la position de linterrupteur : dans la position mode non-vrifi, le jeu de commande que le logiciel accepte est tendu par rapport au mode dcrit ci-dessus. Par exemple, il est possible dajuster le facteur dtalonnage par une commande qui est rejete dans le mode vrifi.

5.2.1.2 Sparation des parties logicielles Les TCs et SCs OIML peuvent spcifier dans la Recommandation approprie que le logiciel/le matriel/ les donnes ou quune partie du logiciel/du matriel/des donnes est rglementairement pertinent.

La rglementation nationale peut prescrire quun logiciel/un matriel/des donnes ou quune partie du logiciel/du matriel/des donne spcifique est rglementairement pertinent.

5.2.1.2.a Tous les modules logiciels (programmes, sous-programmes, objets, etc.) qui ralisent des fonctions rglementairement pertinentes ou qui contiennent des domaines de donnes rglementairement pertinents forment la partie logicielle rglementairement pertinente dun instrument de mesure (dispositif lectronique ou sous-ensemble). Lexigence de conformit sapplique cette partie (voir 5.2.5) qui doit tre identifiable suivant les prescriptions de 5.1.1.

Si la sparation du logiciel nest pas possible ou si elle nest pas ncessaire, le logiciel tout entier est considr comme rglementairement pertinent.

Exemple :

(I) un systme de mesure est constitu de plusieurs capteurs numriques connects un ordinateur personnel qui affiche les valeurs de mesure. Le logiciel rglementairement pertinent de lordinateur personnel est spar de la partie rglementairement non pertinente

OIML D 31:2008 (F)

21

en compilant toutes les procdures ralisant des fonctions rglementairement pertinentes dans une bibliothque de liens dynamiques. Une ou plusieurs applications rglementairement non pertinentes peuvent appeler les procdures de cette bibliothque. Ces procdures reoivent les donnes de mesure des capteurs numriques, calculent les rsultats de mesure, et les affichent dans une fentre logicielle. Lorsque les fonctions rglementairement pertinentes sont termines, le contrle est rendu lapplication rglementairement non pertinente.

5.2.1.2.b Si la partie logicielle rglementairement pertinente communique avec dautres parties, une interface logicielle doit tre dfinie. Toute communication doit tre exclusivement ralise via cette interface. La partie logicielle rglementairement pertinente ainsi que linterface doivent tre clairement documentes. Toute fonction et domaine rglementairement pertinent du logiciel doivent tre dcrits pour permettre lautorit dapprobation de type de dcider si la sparation logicielle est correcte ou non.

Linterface est constitue de codes programmes et de domaines de donnes ddis. Les commandes dfinies et codes, ainsi que les donnes, sont changes entre les parties logicielles grce au stockage dans le domaine de donnes ddi par une partie logicielle et la lecture par une autre partie logicielle. Les codes programmes de lecture et dcriture font partie de linterface logicielle. Le domaine de donnes formant linterface logicielle, y compris le code qui exporte depuis la partie rglementairement pertinente vers linterface du domaine de donnes, ainsi que le code qui importe depuis linterface vers la partie rglementairement pertinente, doit tre clairement dfini et document. Linterface logicielle dclare ne doit pas tre contourne.

Le fabricant est responsable du respect de ces contraintes. Il nest pas possible dempcher un programme de contourner linterface ou dempcher la programmation de commandes caches avec des moyens techniques (tel que le scellement). Des instructions concernant ces exigences doivent tre donnes, par le fabricant, au programmeur de la partie logicielle rglementairement pertinente aussi bien quau programmeur de la partie rglementairement non pertinente.

5.2.1.2.c Laffectation de chaque commande doit tre sans ambigut pour toutes fonctions inities ou tous changements de donnes dans la partie rglementairement pertinente du logiciel. Les commandes qui communiquent travers linterface logicielle doivent tre dclares et documentes. Seules les commandes documentes sont autorises tre actives travers linterface logicielle. Le fabricant doit dclarer lexhaustivit de la documentation relative aux commandes.

Exemple :

(I) Dans lexemple dcrit en 5.2.1.2.a, linterface logicielle est ralise par les paramtres et les valeurs retournes par la procdure de la bibliothque. Aucun pointeur du domaine de donnes lintrieur de la bibliothque nest retourn. La dfinition de linterface est fixe dans la bibliothque rglementairement pertinente compile et ne peut tre change par une quelconque application. Il nest pas impossible de contourner directement linterface logicielle ainsi que les adresses des domaines de donnes de la bibliothque, mais ce nest pas une bonne pratique de la programmation. Cest plutt compliqu et peut tre considr comme du piratage.

5.2.1.2.d Lorsque le logiciel rglementairement pertinent est spar du logiciel rglementairement non pertinent, le logiciel rglementairement pertinent doit avoir priorit dans lutilisation des ressources sur le logiciel rglementairement non pertinent. Le travail de mesure (ralis par la partie logicielle rglementairement pertinente) ne doit pas tre retard ou bloqu par une autre tche.

OIML D 31:2008 (F)

22

Le fabricant est responsable du respect de ces contraintes. Des moyens techniques doivent tre prvus afin dempcher la perturbation des fonctions rglementairement pertinentes par un programme rglementairement non pertinent. Des instructions concernant ces exigences devraient tre donnes, par le fabricant, au programmeur de la partie logicielle rglementairement pertinente aussi bien quau programmeur de la partie rglementairement non pertinente.

Exemples :

(1) (I) Dans les exemples 5.2.1.2.a/c lapplication rglementairement non pertinente contrle le dmarrage des procdures rglementairement pertinentes dans la bibliothque. Omettre un appel ces procdures rsulterait videment en une inhibition de la fonction rglementairement pertinente du systme. Aussi les dispositions suivantes ont t prises dans le systme en exemple afin de respecter les exigences de 5.2.1.2.d. Les capteurs numriques mettent les donnes de mesure sous une forme crypte. La clef de dcryptage est cache dans la bibliothque. Seules les procdures de la bibliothque connaissent la clef et sont capables de lire, dcrypter et afficher les valeurs de mesure. Si le programmeur de lapplication veut lire et traiter les valeurs de mesure, il est forc dutiliser les procdures rglementairement pertinentes de la bibliothque qui ralisent toutes les fonctions exiges lgalement comme effet secondaire de leur appel. La bibliothque contient les procdures qui exportent les valeurs de mesure dcryptes permettant au programmeur de lapplication de les utiliser pour ses propres besoins aprs que le traitement rglementairement pertinent ait t termin.

(2) (I)/(II) Le logiciel dun compteur lectrique lectronique lit les valeurs brutes de mesure depuis un convertisseur analogique/numrique (CAN). Pour un calcul correct des valeurs de mesure, le retard entre les vnements "donnes disponibles" du CAN pour finir la mise en mmoire tampon des valeurs de mesure est crucial. Les valeurs brutes sont lues par une routine dinterruption initie par le signal "donnes disponibles". Linstrument est capable de communiquer en parallle, via une interface, avec dautres dispositifs lectroniques servis par une autre routine dinterruption (communication rglementairement non pertinente). Il rsulte de linterprtation des exigences de 5.2.1.2, pour une telle configuration, que la priorit de la routine dinterruption pour le traitement des valeurs de mesure doit tre plus leve que celle de la routine de communication.

Les exemples de 5.2.1.2.a 5.2.1.2.c et 5.2.1.2.d (1) sont des solutions techniques acceptables uniquement pour un niveau de svrit (I). Si un niveau lev de protection contre la fraude ou de conformit est ncessaire (voir 8), la seule sparation logicielle nest pas suffisante. Des moyens additionnels sont ncessaires ou le logiciel tout entier doit tre considr comme tant sous contrle lgal.

5.2.2 Indications partages Un afficheur ou une imprimante peuvent tre utiliss pour prsenter les informations de la partie logicielle rglementairement pertinente et dautres informations. Le contenu et lagencement sont spcifiques la nature de linstrument et au domaine dapplication et doivent tre dfinis dans la Recommandation approprie. Cependant, si lindication est ralise en utilisant une interface utilisateur multi fentre, lexigence suivante sapplique :

Le logiciel qui ralise lindication des valeurs de mesure et dautres informations rglementairement pertinentes appartient la partie rglementairement pertinente. La fentre contenant ces donnes doit avoir la plus haute priorit, i.e. elle ne doit pas pouvoir tre efface par un autre logiciel ou tre chevauche par des fentres gnres par dautres logiciels ou tre rduite ou tre rendue invisible tant

OIML D 31:2008 (F)

23

que la mesure est en cours et que les rsultats prsents sont ncessaires aux besoins rglementairement pertinents.

Exemple :

(I) Dans un systme tel que celui dcrit aux exemples de 5.2.1.2.a 5.2.1.2.d, les valeurs de mesure sont affiches dans une fentre logicielle spare. Les moyens dcrits en 5.2.1.2.d garantissent que seule la partie de programme rglementairement pertinente peut lire les valeurs de mesure. Pour un systme dexploitation avec une interface utilisateur multi fentre, un moyen technique additionnel est utilis pour respecter lexigence 5.2.2 : la fentre affichant les donnes rglementairement pertinentes est gnre et contrle par des procdures de la bibliothque de liens dynamiques rglementairement pertinente (voir 5.2.1.2). Durant les mesures, ces procdures vrifient cycliquement que la fentre approprie est toujours au dessus des autres fentres ouvertes ; si ce nest pas le cas, elle la place au dessus.

Si un niveau lev de protection contre la fraude est ncessaire (II), une simple impression comme indication nest pas approprie. Il doit exister un sous-ensemble ayant des moyens de scurisation levs qui soit capable dafficher les valeurs de mesure.

Lutilisation dun ordinateur universel en temps que partie dun instrument de mesure nest pas approprie si un niveau lev de protection est ncessaire (II). Des prcautions additionnelles pour empcher ou minimiser le risque de fraude, sous forme logicielle ou matrielle, doivent tre envisages lorsquune protection leve est ncessaire, tout comme lors de lutilisation dun ordinateur universel (par exemple PC, PDA, etc.).

5.2.3 Stockage des donnes, transmission par systmes de communication Si les valeurs de mesure sont utilises en un autre lieu que celui du mesurage ou en dautres temps que ceux du mesurage, il se peut quelles aient quitter linstrument (dispositif lectronique, sous-ensemble) et soient stockes ou transmises dans un environnement non sr avant dtre utilises pour des applications lgales. Dans un tel cas, les exigences suivantes sappliquent :

5.2.3.1 Les valeurs de mesure stockes ou transmises doivent tre accompagnes de toutes les informations pertinentes ncessaires lusage rglementairement pertinent futur.

Exemple :

(I)/(II) Un jeu de donnes peut inclure les entres suivantes:

la valeur de mesure incluant son unit, lhorodatage du mesurage (voir 5.2.3.7), le lieu du mesurage ou lidentification de linstrument de mesure utilis pour le

mesurage,

lidentification sans ambigut du mesurage, par exemple une srie de nombres permettant laffectation des valeurs imprimes sur une facture.

5.2.3.2 Les donnes doivent tre protges par des moyens logiciels afin de garantir leur authenticit, leur intgrit et, si ncessaire, lexactitude des informations relatives lheure du mesurage. Le logiciel qui affiche ou qui traite ultrieurement les valeurs de mesure et les donnes les accompagnant doit vrifier lheure du mesurage, lauthenticit et lintgrit des donnes aprs les

OIML D 31:2008 (F)

24

avoir lues depuis un stockage non sr ou aprs les avoir reues par un canal de transmission non sr. Si une irrgularit est dtecte, les donnes doivent tre rejetes ou marques inutilisables.

Les modules logiciels qui prparent les donnes pour lmission ou le stockage, ou qui vrifient les donnes leur lecture ou rception, appartiennent la partie logicielle rglementairement pertinente.

Note : Il est appropri dexiger un niveau plus lev de svrit lorsque lon considre un rseau ouvert.

Exemple :

(I) Le programme du dispositif metteur calcule une somme de contrle du jeu de donnes (un algorithme tel que BCC, CRC 16, CRC 32, etc.) et le joint au jeu de donnes. Il utilise une valeur initiale secrte pour ce calcul au lieu dutiliser la valeur donne dans la norme. Cette valeur initiale est utilise en tant que clef et est stocke comme constante dans le code programme. Le programme de rception, ou de lecture, calcule la somme de contrle et la compare avec celle stocke dans le jeu de donnes. Si les deux valeurs correspondent, le jeu de donnes nest pas falsifi. Sinon, le programme prsume la falsification et rejette le jeu de donnes.

5.2.3.3 Pour un niveau lev de protection, il est ncessaire dutiliser des mthodes cryptographiques. Les cls confidentielles employes pour cela doivent tre gardes secrtes et scurises dans les instruments de mesure, dispositifs lectroniques, ou sous-ensembles impliqus. Des moyens doivent tre fournis de sorte que ces cls ne puissent tre introduites ou lues que si un scellement est bris.

Exemple :

(II) Le programme de stockage ou dmission gnre une "signature numrique" en commenant par le calcul de la valeur de hachage3) puis encrypte celle-ci avec la clef secrte dun systme de clef publique4). Le rsultat est la signature. Elle est jointe au jeu de donnes transmis ou stock. Le rcepteur calcule galement la valeur de hachage du jeu de donnes et dcrypte avec la clef publique la signature jointe au jeu de donnes. La valeur calcule et la valeur dcrypte de la valeur de hachage sont compares. Si elles sont gales, le jeu de donnes nest pas falsifi (lintgrit est prouve). Pour prouver lorigine du jeu de donnes, le rcepteur doit connatre si la clef publique appartient lmetteur, i.e. le dispositif metteur. Aussi, la clef publique est affiche sur lafficheur de linstrument de mesure et peut tre enregistre une fois, par exemple avec le numro de srie du dispositif quand il est lgalement contrl en service. Si le rcepteur est sr quil a utilis la bonne clef publique pour dcrypter la signature, alors lauthenticit du jeu de donnes est galement prouve.

5.2.3.4 Stockage automatique 5.2.3.4.a Lorsque, tant donne lapplication, le stockage des donnes est requis, les donnes de mesure doivent tre stockes automatiquement lorsque le mesurage est conclu, i.e. lorsque la valeur finale utilise pour lapplication lgale a t gnre.

3) Algorithmes acceptables: SHA-1, MD5, RipeMD160, ou quivalent. 4) Algorithmes acceptables: RSA (avec une clef de 1024 bit), Elliptic Curves (avec une clef de 160 bit), ou quivalent.

OIML D 31:2008 (F)

25

Le dispositif de stockage doit avoir une stabilit suffisante pour garantir que les donnes ne sont pas corrompues dans des conditions normales de stockage. La capacit de stockage doit tre suffisante pour toute application particulire.

Lorsque la valeur finale utilise pour lapplication lgale rsulte dun calcul, toutes les donnes ncessaires au calcul doivent tre automatiquement stockes avec la valeur finale.

Note : Les valeurs de mesurages cumulatifs tels que, par exemple, lnergie lectrique ou un volume de gaz, doivent tre actualises constamment. Comme le mme domaine de donnes (variable du programme) est toujours utilis, les exigences concernant la capacit de stockage ne sont pas applicables aux mesurages cumulatifs.

5.2.3.4.b Les donnes stockes peuvent tre effaces si :

la transaction est conclue, ces donnes sont imprimes par une imprimante soumise au contrle lgal.

Note : Dautres rglementations nationales gnrales (par exemple relatives aux taxes) peuvent inclure des limites strictes pour leffacement des donnes de mesure stockes.

5.2.3.4.c Lorsque les exigences de 5.2.3.4.b sont remplies et lorsque le stockage est plein, leffacement de donnes mmorises est autoris lorsque les deux conditions suivantes sont remplies :

les donnes sont effaces dans le mme ordre que lordre denregistrement et les rgles tablies pour lapplication particulire sont respectes,

leffacement est effectu automatiquement ou aprs une opration manuelle particulire.

Note : Lutilisation de droits daccs additionnels devrait tre considr lors de la mise en uvre de "lopration manuelle particulire" prescrite au second alina ci-dessus.

5.2.3.5 Retard de transmission Les mesures ne doivent pas tre influences inacceptablement par un retard de transmission.

5.2.3.6 Interruption de transmission Si le service rseau devient indisponible, aucune donne de mesure ne doit tre perdue. Le processus de mesure doit tre stopp pour viter la perte de ces donnes de mesure.

Note : La distinction entre les mesurages statiques et dynamiques doit tre tudie.

Exemple :

(I)/(II) Le dispositif metteur attend que le rcepteur envoie une confirmation de bonne rception du jeu de donnes. Le dispositif metteur conserve le jeu de donnes dans une mmoire tampon tant que la confirmation na pas t reue. La mmoire tampon peut avoir une capacit suprieure un jeu de donnes, organise comme une pile FIFO 5).

5) FIFO : Premier entr premier sorti

OIML D 31:2008 (F)

26

5.2.3.7 Horodatage Lhorodatage doit tre lu depuis lhorloge du dispositif. Selon la nature de linstrument, ou le domaine dapplication, rgler lhorloge peut tre rglementairement pertinent et ncessiter que des moyens de protection appropris soient pris en accord avec le niveau de svrit devant tre appliqu (voir 5.1.3.2.c).

Lhorloge interne dun instrument autonome tend avoir une grande incertitude car il nexiste pas de possibilit de la synchroniser avec lhorloge mondiale. Cependant, si linformation en rapport avec lheure de mesurage est ncessaire un domaine dapplication spcifique, la fiabilit de lhorloge interne de linstrument doit tre renforce laide de moyens spcifiques.

Exemple :

(II) La fiabilit du dispositif horloge interne de linstrument de mesure, contrle par quartz, est renforce par redondance : une minuterie est incrmente par lhorloge du microcontrleur qui dcoule dun autre cristal de quartz. Lorsque que la valeur de la minuterie atteint une valeur prdfinie, par exemple 1 seconde, un drapeau spcifique du microcontrleur est dress et une routine dinterruption du programme incrmente un second compteur. A la fin de, par exemple, une journe, le logiciel lit le dispositif horloge contrle par quartz et calcule la diffrence avec le second compteur logiciel. Si la diffrence est comprise dans les limites prdfinies, le compteur logiciel est remis zro et la procdure est rpte. Mais si la diffrence excde les limites, le logiciel ragit de faon approprie lerreur.

5.2.4 Compatibilit des systmes dexploitation et du matriel, portabilit 5.2.4.1 Le fabricant doit identifier lenvironnement matriel et logiciel qui est appropri. Les ressources minimales ainsi que la configuration adapte (par exemple le processeur, la mmoire vive, le disque dur, les communications spcifiques, la version du systme dexploitation, etc.) qui sont ncessaires au bon fonctionnement, doivent tre dclares par le fabricant et nonces dans le certificat dapprobation de type.

5.2.4.2 Des moyens techniques doivent tre inclus dans le logiciel rglementairement pertinent afin dempcher toute opration si les exigences de configuration minimale ne sont pas respectes. Le systme doit uniquement oprer dans lenvironnement spcifi par le fabricant pour son bon fonctionnement.

Par exemple, dans le cas o un environnement invariable est spcifi pour un fonctionnement correct du systme, des dispositions doivent tre prises afin de maintenir fixe lenvironnement oprationnel. Ceci sapplique plus particulirement aux ordinateurs universels ralisant des fonctions rglementairement pertinentes.

Figer le matriel, le systme dexploitation, ou la configuration du systme dun ordinateur universel ou mme exclure lutilisation d'ordinateur universel standard, doit tre considr dans les cas suivants :

si une conformit leve est exige (voir 5.2.5.d), si un logiciel fig est exig (par exemple 5.2.6.3.b pour la Mise jour Trace du logiciel), si des algorithmes ou cls cryptographiques sont mis en uvre (voir 5.2.3).

OIML D 31:2008 (F)

27

5.2.5 Conformit du dispositif fabriqu au type approuv Le fabricant doit produire des dispositifs et des logiciels rglementairement pertinents conformes au type approuv et la documentation soumise. Il existe diffrents niveaux de conformit exigibles :

(a) identit des fonctions rglementairement pertinentes de chaque dispositif dcrites dans la documentation (6.1), avec celles du type (le code excutable pouvant tre diffrent),

(b) identit des parties du code source rglementairement pertinent, alors que le reste du logiciel rglementairement pertinent est conforme (a),

(c) identit de tout le code source rglementairement pertinent, et

(d) identit de tout le code excutable.

La Recommandation approprie doit spcifier quel degr de conformit est adapt. Cette Recommandation peut galement dfinir des sous-niveaux de ces degrs de conformit.

A lexception de (d), il peut exister une partie logicielle sans exigence de conformit, si elle est spare de la partie rglementairement pertinente conformment 5.2.1.2.

Les moyens dcrits en 5.1.1 et 5.2.1 doivent tre fournis afin de rendre la conformit vidente.

Note : (a) et (b) doivent tre appliqus pour les niveaux normaux de svrit et (c) et (d) doivent tre appliqus aux niveaux levs de svrit.

5.2.6 Maintenance et re-configuration Mettre jour le logiciel rglementairement pertinent dun instrument de mesure en service doit tre considr comme :

une modification de linstrument de mesure, lors de lchange du logiciel par une autre version approuve,

une rparation de linstrument de mesure, lors de la rinstallation de la mme version.

Un instrument de mesure qui a t modifi ou rpar alors quil est en service, peut ncessiter une vrification primitive ou une vrification ultrieure, selon les rglementations nationales.

Le logiciel qui nest pas ncessaire au bon fonctionnement de linstrument de mesure, ne ncessite pas de vrification aprs avoir t mis jour.

5.2.6.1 Lutilisation des seules versions du logiciel rglementairement pertinent qui sont conformes au type approuv est autorise (voir 5.2.5). Lapplicabilit des exigences suivantes dpend de la nature de linstrument et doit tre dfinie dans la Recommandation OIML approprie. Elle peut diffrer galement selon la nature de linstrument considr. Les options suivantes, 5.2.6.2 et 5.2.6.3, sont des alternatives quivalentes. Cette question concerne le contrle en service. Se rfrer au chapitre 7 pour des contraintes additionnelles.

5.2.6.2 Mise jour Vrifie

Le logiciel mettre jour peut tre charg localement, i.e. directement sur le dispositif mesureur ou distance via un rseau. Le chargement et linstallation peuvent tre deux tapes diffrentes (tel que dcrit en fig. 1) ou combines en une, selon les besoins de la solution technique. Une personne doit tre sur le site dinstallation de linstrument de mesure afin de vrifier lefficacit de la mise jour. Aprs la mise jour du logiciel rglementairement pertinent de linstrument de mesure (change avec

OIML D 31:2008 (F)

28

une autre version approuve ou rinstallation), linstrument nest pas autoris tre employ des fins lgales avant quune vrification de celui-ci, telle que dcrite en chapitre 7, nait t ralise et que les moyens de scurisation aient t renouvels (sil nest pas dclar autrement dans la Recommandation OIML approprie ou dans le certificat dapprobation).

5.2.6.3 Mise jour Trace Le logiciel est implment dans linstrument conformment aux exigences de la Mise jour Trace (5.2.6.3.a 5.2.6.3.g), si cela est conforme la Recommandation OIML approprie. La Mise jour Trace est la procdure de changement de logiciel dun instrument ou dun dispositif vrifi, aprs laquelle une vrification sur site par une personne responsable nest pas ncessaire. Le logiciel mettre jour peut tre charg localement, i.e. directement sur le dispositif mesureur ou distance via un rseau. La mise jour du logiciel est enregistre dans une expertise de lhistorique (voir 3.1.2). La procdure de Mise jour Trace comprend plusieurs tapes : le chargement, la vrification de lintgrit, la vrification de lorigine (authentification), linstallation, lenregistrement et lactivation.

5.2.6.3.a La Mise jour Trace de logiciel doit tre automatique. A lachvement de la procdure de mise jour, lenvironnement de protection logicielle doit tre du mme niveau que celui requis par lapprobation de type.

5.2.6.3.b Linstrument de mesure cible (dispositif lectronique, sous-ensemble) doit avoir un logiciel rglementairement pertinent fig qui ne peut pas tre mis jour et qui contient toutes les fonctions de vrification ncessaires au respect des exigences de la Mise jour Trace.

5.2.6.3.c Des moyens techniques doivent tre utiliss afin de garantir lauthenticit du logiciel charg, i.e. quil provient du dtenteur du certificat dapprobation de type. Si le logiciel charg choue la vrification dauthenticit, linstrument doit le rejeter et utiliser la version prcdente du logiciel ou basculer dans un mode inoprant.

Exemple :

(II) La vrification de lauthenticit est accomplie par des moyens cryptographiques tel quun systme clef publique. Le dtenteur du certificat dapprobation de type (en gnral, le fabricant de linstrument de mesure) gnre une signature lectronique du logiciel de mise jour en utilisant la clef secrte, en usine. La clef publique est stocke dans la partie logicielle fige de linstrument de mesure. La signature est vrifie en utilisant la clef publique lors du chargement du logiciel dans linstrument de mesure. Si la signature du logiciel charg est OK, alors il est install et activ. Si la vrification choue, le logiciel fig rejette alors le logiciel charg et utilise la version prcdente du logiciel ou bascule dans un mode inoprant.

5.2.6.3.d Des moyens techniques doivent tre utiliss afin dassurer lintgrit du logiciel charg, i.e. quil na pas t chang de faon inacceptable avant son chargement. Ceci peut tre accompli en ajoutant une somme de contrle ou un code de hachage au logiciel charg qui seront vrifis lors de la procdure de chargement. Si le logiciel charg choue cet essai, linstrument doit le rejeter et utiliser la version prcdente du logiciel ou basculer dans un mode inoprant. Dans ce mode, les fonctions de mesure sont inhibes. Seule la reprise de la procdure de tlchargement doit tre possible, sans oublier aucune tape du diagramme de Mise jour Trace.

OIML D 31:2008 (F)

29

5.2.6.3.e Des moyens techniques appropris, par exemple une expertise de lhistorique, doivent tre employs afin dassurer que les Mises jour Traces de logiciels rglementairement pertinents sont adquatement traables dans linstrument en vue des vrifications ultrieures, des surveillances ou des inspections.

Lexpertise de lhistorique doit contenir au minimum les informations suivantes : succs/chec de la procdure de mise jour, lidentification de la version du logiciel install, lidentification de la version du logiciel prcdemment install, lhorodatage de lvnement, et lidentification des parties ayant effectu le tlchargement. Une entre est gnre pour chaque tentative de mise jour indpendamment de son succs.

Le dispositif de stockage utilis pour la Mise jour Trace doit avoir une capacit suffisante pour assurer au minimum la traabilit des Mises jour Traces du logiciel rglementairement pertinent entre deux vrifications en service ou inspections successives. Il doit tre garanti par des moyens techniques que tout tlchargement est impossible sans briser de scellement, lorsque la limite de stockage de lexpertise de lhistorique est atteinte.

Note : Cette exigence permet aux autorits dinspection, qui sont responsables de la surveillance mtrologique des instruments lgalement contrls, de retracer les Mises jour Traces du logiciel rglementairement pertinent sur une dure approprie (en fonction de la rglementation nationale).

5.2.6.3.f En fonction des besoins et de la rglementation nationale, il peut tre ncessaire que lutilisateur ou que le dtenteur de linstrument de mesure ait donner son consentement au tlchargement. Linstrument de mesure doit avoir un dispositif/sous-ensemble lectronique permettant lutilisateur ou au dtenteur dexprimer son consentement, par exemple, un bouton poussoir, avant que le tlchargement ne commence. Il doit tre possible dactiver/de dsactiver ce dispositif/sous-ensemble lectronique, par exemple laide dun interrupteur qui peut tre scell, ou laide dun paramtre. Si le dispositif/sous-ensemble lectronique est activ, chaque tlchargement doit tre initi par lutilisateur ou le dtenteur. Si il est dsactiv, aucune action de la part de lutilisateur ou le dtenteur nest ncessaire pour raliser le tlchargement.

5.2.6.3.g Si les exigences de 5.2.6.3.a 5.2.6.3.f ne peuvent tre remplies, il demeure cependant possible de mettre jour la partie logicielle rglementairement non pertinente. Dans ce cas, les exigences suivantes doivent tre respectes : il existe une claire sparation entre le logiciel rglementairement pertinent et le logiciel

rglementairement non pertinent, conformment 5.2.1,

le logiciel rglementairement pertinent tout entier ne peut tre mis jour sans briser de scellement,

il est dclar dans le certificat dapprobation de type que la mise jour du logiciel rglementairement non pertinent est acceptable.

OIML D 31:2008 (F)

30

Figure 1 Procdure de mise jour du logiciel

Non

Non

Non

Oui

Oui

Oui

Installation et activation des fichiers

mis jour (Note 1)

Redmarrage

Mise jour Trace (5.2.6.3)

Demande de mise jour ?

Lintgrit est-elle valide ?

Lauthenticit est-elle valide ?

Mode de fonctionnement

normal

Chargement des fichiers mis jour

(Note 1)

Rejet des fichiers chargs, conservation de lancienne version

active, ou basculement en mode inoprant

Enregistrement des informations de mise jour dans lexpertise

de lhistorique

Non

Oui

Non

Oui

(Note 3)

Mise jour Vrifie (5.2.6.2)

Installation et activation des fichiers

mis jour (Note 2)

Vrification (ultrieure) par une

personne sur site (Voir 5.2.6)

Redmarrage

Demande de mise jour ?

La vrification est-elle

concluante ?

Mode de fonctionnement

normal

Chargement des fichiers mis jour

(Note 2)

Apposition des marques de verification

OIML D 31:2008 (F)

31

Notes : (1)Dans le cas de la Mise jour Trace, la mise jour est divise en deux tapes : le chargement et linstallation/activation. Cela implique que le logiciel est temporairement stock aprs son chargement sans tre activ car il doit tre possible de rejeter le logiciel charg et de revenir la version antrieure, si les vrifications chouent.

(2)Dans le cas dune Mise jour Vrifie, le logiciel peut galement tre charg et temporairement stock avant son installation, mais en fonction de la solution technique, le chargement et linstallation peuvent tre accomplis en une tape.

(3) Ici, les checs de vrification dus la mise jour du logiciel sont les seuls considrs. Les checs dus dautres raisons ne ncessitent pas de re-chargement ni de rinstallation du logiciel, symboliss ici par la branche "Non".

5.2.6.4 La Recommandation OIML approprie peut exiger que le rglage de certains paramtres spcifiques au dispositif soit disponible pour lutilisateur. Dans un tel cas, linstrument de mesure doit tre pourvu dun systme enregistrant automatiquement, et de manire non effaable, tout ajustement de paramtre spcifique au dispositif, par exemple une expertise de lhistorique. Linstrument doit tre capable de prsenter les donnes enregistres.

Note : Un compteur dvnements nest pas une solution acceptable.

5.2.6.5 Les moyens de traabilit et les enregistrements font partie du logiciel rglementairement pertinent et devraient tre protgs en tant que tels. Le logiciel utilis pour afficher lexpertise de lhistorique (5.2.6.2 ; 5.2.6.3) fait partie du logiciel rglementairement pertinent fig.

6 Approbation de type 6.1 Documentation soumettre pour lapprobation de type

Pour lapprobation de type, le fabricant de linstrument de mesure doit dclarer et documenter toutes les fonctions du programme, les structures de donnes pertinentes ainsi que les interfaces logicielles de la partie rglementairement pertinente qui sont mises en uvre dans linstrument. Il ne doit pas exister de fonction cache non documente.

Les commandes et leurs effets doivent tre compltement dcrits dans la documentation du logiciel soumettre lapprobation de type. Le fabricant doit dclarer lexhaustivit de la documentation des commandes. Si les commandes peuvent tre entres via linterface utilisateur, elles doivent tre dcrites compltement dans la documentation du logiciel soumettre lapprobation de type.

De plus, la demande dapprobation de type doit tre accompagne par un document ou tout autre preuve supportant lhypothse que la conception et les caractristiques du logiciel de linstrument de mesure sont conformes avec les exigences de la Recommandation OIML approprie dans laquelle les exigences gnrales de ce document auront t incorpores.

6.1.1 Une documentation typique (pour chaque instrument de mesure, dispositif lectronique, ou sous-ensemble) inclut :

une description du logiciel rglementairement pertinent et de la faon dont les exigences sont respectes :

OIML D 31:2008 (F)

32

- une liste des modules logiciels qui appartiennent la partie rglementairement pertinente (Annexe B), y compris une dclaration que toutes les fonctions rglementairement pertinentes sont incluses dans la description,

- une description des interfaces logicielles de la partie rglementairement pertinente et des commandes et donnes qui transitent par ces interfaces ainsi quune dclaration de leur exhaustivit (Annexe B),

- une description de la gnration de lidentification du logiciel,

- en fonction de la mthode de validation choisie dans la Recommandation OIML approprie (voir 6.3 et 6.4), le code source doit tre rendu disponible lautorit dessai si une conformit leve ou une forte protection est requise par la Recommandation OIML approprie,

- une liste des paramtres devant tre protgs et une description des moyens de protection,

une description de la configuration adquate du systme ainsi que des ressources minimales exiges (voir 5.2.4),

une description des moyens de scurit du systme dexploitation (mot de passe, etc., si applicable),

une description des mthodes de scellement (logiciel), une description du systme matriel, par exemple des diagrammes topologiques, le type

dordinateur(s), le type de rseau, etc. Il doit galement tre identifi lorsque quun composant matriel est estim rglementairement pertinent ou lorsquil ralise des fonctions rglementairement pertinentes,

une description de lexactitude des algorithmes (par exemple le filtrage du rsultat dune conversion A/N, le calcul de prix, les algorithme darrondi, etc.),

une description de linterface utilisateur, des menus et des botes de dialogue, lidentification du logiciel et les instructions pour lobtenir dun instrument en cours

dutilisation,

la liste des commandes de chaque interface matriel de linstrument de mesure, du dispositif lectronique / sous-ensemble, y compris une dclaration de son exhaustivit,

la liste des erreurs de durabilit qui sont dtectes par le logiciel et si ncessaire pour leur comprhension, une description des algorithmes de dtection,

une description des jeux de donns stocks ou transmis, si la dtection de faute est ralise par logiciel, une liste des fautes qui sont dtectes et une

description de lalgorithme de dtection,

le manuel dutilisation.

6.2 Exigences pour la procdure dapprobation

Dans le cadre de lapprobation de type, les procdures dessais, par exemple celles dcrites dans lOIML D 11:2004, sont bases sur des configurations et conditions dessai bien dfinies et reposent sur des mesures comparatives dtermines. "Essayer" et "valider" un logiciel sont deux activits diffrentes. Lexactitude ou la justesse dun logiciel en gnral, ne peut tre mesur au sens mtrologique, bien quil existe des normes prescrivant comment "mesurer" la qualit dun logiciel (par exemple lISO/CEI 14598 [9]). Les procdures dcrites ici prennent en compte les besoins de la mtrologie lgale ainsi que les mthodes bien connues de validation et dessais dingnierie logicielle,

OIML D 31:2008 (F)

33

bien que ces dernires naient pas les mmes buts (par exemple les dveloppeurs de logiciels cherchent les erreurs mais galement optimiser leurs performances). Telle que prsente en 6.4, chaque exigence logicielle a besoin dune adaptation individuelle des procdures de validation appropries. Leffort consacr la procdure devrait reflter limportance de lexigence en terme dexactitude, de fiabilit et de protection contre la corruption.

Lobjectif est de valider le fait quun instrument devant tre approuv est conforme aux exigences de la Recommandation OIML approprie. Pour les instruments contrls par logiciel, la procdure de validation comprend lexamen, lanalyse et les essais. La Recommandation OIML approprie doit inclure une slection approprie des mthodes dcrites ci-aprs.

Les mthodes dcrites ci-aprs se concentrent sur lexamen de type. Les vrifications individuelles dun instrument en service ne sont pas couvertes par ces mthodes de validation. Se rfrer au chapitre 7 Vrification pour plus dinformations.

Les mthodes spcifies pour la validation du logiciel sont dcrites en 6.3. Des combinaisons de ces mthodes, formant une procdure complte de validation adapte toutes les exigences dfinies au chapitre 5, sont spcifies en 6.4.

OIML D 31:2008 (F)

34

6.3 Mthodes de validation (examen du logiciel)

6.3.1 Vue densemble des mthodes et de leur application

La slection et lordre des mthodes suivantes ne sont pas prescrits et peuvent varier au cas par cas dans une procdure de validation.

Abrviation Description Application

Conditions pralables, outils

pour traiter la demande

Comptences spciales pour la

ralisation

AD Analyse de la documentation et validation de la conception (6.3.2.1)

Toujours Documentation -

VFTM Validation par essais fonctionnels des fonctions mtrologiques (6.3.2.2)

Justesse des algorithmes, incertitude, algorithme de compensation et de correction, rgle pour le calcul de prix

Documentation -

VFTSw Validation par essais fonctionnels des fonctions logicielles (6.3.2.3)

Fonctionnement correct des communications, indications, protections contre la fraude, protections contre les erreurs dopration, protections des paramtres, et dtection des fautes

Documentation, outils logiciels courants

-

DFA Analyse du flux de donnes mtrologiques (6.3.2.4)

Sparation logicielle, valuation de limpact des commandes sur les fonctions de linstrument

Code source, outils logiciels courants (procdure simple), outils (procdure sophistique)

Connaissance des langages de programmation, mthode ncessitant des instructions

CIWT Inspection et parcours du code (6.3.2.5)

Tout objet Code source, outils logiciels courants

Connaissance des langages de programmation, protocoles, et autres sujets TIC

SMT Essai de module logiciel (6.3.2.6)

Tout objet lorsque les entres et sorties sont clairement dfinies

Code source, environnement dessai, outils logiciels spcifiques

Connaissance des langages de programmation, protocoles, et autres sujets TIC. Utilisation de loutil ncessitant des instructions

Tableau 1 : Vue densemble