Guia7 2 ES-v4 Welmec

WELMEC 7.
2 (Edicin 4)
WELMEC
Cooperacin europea en metrologa legal
Gua del software

(Directiva 2004/22/EC relativa a Instrumentos de Medida)
Mayo 2009
Gua Welmec 7.2 Edicin 4 Mayo 2009
WELMEC
Cooperacin europea en metrologa legal
WELMEC es una cooperacin entre las autoridades de metrologa legal de los Estados miembros de la
Unin Europea y la Asociacin Europea de Libre Comercio. Este documento es una de las distintas
guas publicadas por WELMEC para orientar a los fabricantes de instrumentos de medida y a los
organismos notificados responsables de la evaluacin de conformidad de sus productos. Las guas son
puramente orientativas y no imponen ninguna restriccin o requisito tcnico adicional ms all de
aquellas que se incluyen en las Directivas CE pertinentes. Aunque se pueden admitir propuestas
alternativas, la orientacin que se proporciona en este documento representa lo expuesto por
WELMEC como la mejor prctica a seguir.
Nota: todas las referencias a la Directiva 2004/22/EC relativa a los instrumentos de medida contenidas
en este documento se realizarn mediante el acrnimo MID
Publicacin CEM edicin digital 1

Traduccin al espaol de la 4 edicin del original publicado por WELMEC
NIPO: 706-09-004-7
Pgina 2 de 115
ndice
Prefacio .................................................................................................................................................... 5
1. Introduccin ......................................................................................................................................... 6
2. Trminos y definiciones....................................................................................................................... 6
3. Cmo usar esta gua ............................................................................................................................. 9
3.1 Estructura general .......................................................................................................................... 9
3.2 Cmo seleccionar los apartados adecuados ................................................................................. 12
3.3 Cmo trabajar con bloques de requisitos ..................................................................................... 13
3.4 Cmo trabajar con las listas de comprobacin ........................................................................... 13
4 Requisitos bsicos del software integrado en un instrumento de medida desarrollado especficamente
(tipo P) ................................................................................................................................................... 14
4.1 Descripcin tcnica...................................................................................................................... 14
4.2 Requisitos especficos para el tipo P............................................................................................ 14
5 Requisitos bsicos del software de los instrumentos de medida que utilizan un ordenador universal
(tipo U)................................................................................................................................................... 27
5.2 Requisitos especficos del software para el tipo U ...................................................................... 28
6 Extensin L: Almacenamiento a largo plazo de los datos de medida................................................. 48
6.2 Requisitos especficos del software para almacenamiento a largo plazo .................................... 49
7 Extensin T: Transmisin de datos de medida a travs de redes de comunicacin ........................... 61
7.2 Requisitos especficos del software para transmisin de datos ................................................... 62
8 Extensin S: Separacin de software.................................................................................................. 72
8.2 Requisitos especficos para separacin de software .................................................................... 74
9 Extensin D: Descarga de software legalmente relevante.................................................................. 79
9.2 Requisitos especficos del software ............................................................................................. 80
10 Extensin I: Requisitos del software especficos del instrumento.................................................... 85
10.1 Contadores de agua .................................................................................................................... 89
10.2 Contadores de gas y dispositivos de conversin volumtrica.................................................... 94
10.3 Contadores de energa elctrica activa..................................................................................... 101
10.4 Contadores de energa trmica................................................................................................. 106
10.5 Sistemas para la medicin continua y dinmica de cantidades de lquidos distintos del agua.111
10.6 Instrumentos de pesaje............................................................................................................. 112
10.7 Taxmetros ............................................................................................................................... 117
10.8 Medidas materializadas............................................................................................................ 119
10.9 Instrumentos para medidas dimensionales............................................................................... 119
10.10 Analizadores de gases de escape............................................................................................ 120
11 Definicin de las clases de riesgo ................................................................................................... 120
11.1 Principio general ...................................................................................................................... 120
11.2 Descripcin de los niveles de proteccin, examen y conformidad.......................................... 120
11.3 Asignacin de las clases de riesgo ........................................................................................... 121
11.4 Interpretacin de las clases de riesgo....................................................................................... 121
12 Modelo del informe de ensayos (incluidas las listas de comprobacin)......................................... 122
12.1 Modelo de la parte general del informe de ensayos................................................................. 123
12.2 Anexo 1 del informe de ensayos: Listas de comprobacin que facilitan la seleccin del
conjunto de requisitos adecuado ...................................................................................................... 127
Pgina 3 de 115
12.3 Anexo 2 del informe de ensayos: Listas de comprobacin especficas de las respectivas partes
tcnicas............................................................................................................................................. 129
12.4 Informacin que debe incluirse en el certificado de examen de modelo................................. 134
13 Referencias cruzadas entre los requisitos de software de la MID y los artculos y anexos de la MID
.............................................................................................................................................................. 134
13.1 Referencias a la MID para cada requisito de software ............................................................ 134
14 Referencias y Bibliografa .............................................................................................................. 143
15 Histrico de revisiones.................................................................................................................... 143
16 ndice alfabtico.............................................................................................................................. 143
Pgina 4 de 115
Prefacio
Esta gua se basa en la versin 1.00 de la Software Requirements and Validation Guide, 29 de
octubre de 2004, desarrollada y emitida por la Red de Crecimiento Europeo MID software. Desde
enero de 2002 hasta diciembre de 2004 la comisin de la UE respald dicha red mediante el contrato
G7RT-CT-2001-05064.
La gua es puramente orientativa y no impone ninguna restriccin o requisito tcnico adicional ms

all de aquellos que se incluyen en la MID. Se pueden admitir propuestas alternativas, aunque la
orientacin que se proporciona en este documento se presenta lo considerado por WELMEC como la
mejor prctica a seguir.
Aunque la gua est orientada a los instrumentos incluidos en las regulaciones de la MID, los
resultados son de carcter general y pueden aplicarse en otros mbitos.
Esta ltima edicin aprovecha la experiencia adquirida en la aplicacin de esta gua.
Pgina 5 de 115
1. Introduccin
Este documento proporciona una orientacin a todos aquellos relacionados con la aplicacin de la
MID, especialmente para los instrumentos de medida equipados con software.
Va dirigido tanto a los fabricantes de instrumentos de medida como a los organismos notificados
responsables de la evaluacin de la conformidad de los mismos.
Aplicando esta gua puede asumirse la conformidad con los requisitos de la MID relativos al software.
Adems, puede asumirse tambin que todos los organismos notificados aceptan la presente gua como
una interpretacin fiel de la MID respecto al software.
Para demostrar cmo se relacionan los requisitos de la presente gua con los requisitos respectivos en
la MID, se ha incluido una referencia cruzada en la presente gua como anexo (captulo 13).
La gua anterior era la gua 7.1, elaborada por el grupo de trabajo 7 de WELMEC. Ambas guas se
basan en los mismos principios y derivan de los requisitos de la MID. Se ha revisado la gua 7.1 y
sigue existiendo (edicin 2) pero ahora es de carcter meramente informativo, mientras que la gua 7.2
es la nica que recomienda WELMEC para la creacin, examen y validacin del software de los
instrumentos de medida controlados por software sometidos a la MID.
En la pgina Web: http://www.welmecwg7.ptb.de se encuentra disponible informacin actualizada

sobre las guas y la actividad del grupo de trabajo 7 de WELMEC.
2. Trminos y definiciones
Los trminos y definiciones contenidos en este apartado describen el vocabulario tal y como se usa en
esta gua. Cuando una definicin se ha tomado total o parcialmente de una norma u otra fuente se
proporcionan referencias a la misma.
Almacenamiento a largo plazo de los datos de medida: almacenamiento utilizado para conservar los
datos de medida disponibles una vez finalizada la misma para fines posteriores legalmente relevantes
(p. ej., la conclusin de una transaccin comercial).
Almacenamiento integrado: almacenamiento no extrable que forma parte del instrumento de medida
(p. ej., RAM, EEPROM, disco duro).
Autenticacin: verificacin de la identidad declarada o alegada de un usuario, proceso, o dispositivo.
Clases de riesgo: clases que engloban tipos de instrumentos de medida con evaluaciones de riesgo
comparables.
Configuracin bsica: diseo de un instrumento de medida respecto a su arquitectura bsica. Existen

dos configuraciones bsicas diferentes: instrumentos de medida desarrollados especficamente e
instrumentos de medida que usan un ordenador universal. Estos trminos son aplicables del mismo
modo a los subconjuntos.
Configuracin TI (Tecnologas de la Informacin): diseo de un instrumento de medida respecto de

las funciones TI y elementos caractersticos que son de acuerdo a los requisitos independientes de
la funcin de medicin. En esta gua se consideran cuatro configuraciones TI: almacenamiento a largo
plazo de los datos de medida, transmisin de los datos de medida, descarga de software y separacin
de software (consulte tambin configuracin bsica). Estos trminos son aplicables del mismo modo
a los subconjuntos.
Descarga de software: proceso de transferencia automtica del software a un instrumento de medida

o unidad de hardware de destino mediante cualquier medio tcnico, desde una fuente local o remota (p.
Pgina 6 de 115
ej., medios de almacenamiento intercambiables, ordenador porttil, ordenador remoto), a travs de

conexiones arbitrarias (p. ej., enlace directo, redes).
Identificacin del software: secuencia de caracteres legibles ligada indefectiblemente al software (p.
ej., nmero de versin, suma de comprobacin checksum-).
Instrumento de medida: cualquier dispositivo o sistema con funciones de medicin. El calificativo

de medida se omite siempre que de lugar a confusin [Artculo 4, MID].
Instrumento de medida desarrollado especficamente (tipo P): instrumento de medida diseado y

construido especficamente para una tarea concreta. Por consiguiente, toda la aplicacin software se
desarrolla para realizar la medida. Para una definicin ms detallada, vase el apartado 4.1.
Instrumento de medida que utilizan un ordenador universal (tipo U): instrumento de medida que
consta de un ordenador de propsito general, que suele ser un sistema basado en PC, para realizar
funciones legalmente relevantes. Se asume que un sistema de medida es de tipo U si no se cumplen las
condiciones de un instrumento de medida desarrollado especficamente (tipo P).
Integridad de los datos y del software: garanta de que los datos y el software no han sufrido
cambios no autorizados durante su uso, transferencia o almacenamiento.
Interfaz de comunicacin: interfaz electrnica, ptica, de radiofrecuencia o por cualquier otro

sistema que permite que la informacin pase automticamente entre los componentes de los
instrumentos de medida, subconjuntos o dispositivos externos.
Interfaz de usuario: interfaz que constituye la parte del instrumento o sistema de medida que permite
transmitir informacin entre un usuario humano y el instrumento de medida o sus componentes de
hardware o software, como por ejemplo un interruptor, un teclado, un ratn, una pantalla, un monitor,
una impresora o una pantalla tctil.
Parmetro especfico del dispositivo: parmetro legalmente relevante con un valor que depende de
cada instrumento. Los parmetros especficos del dispositivo estn compuestos por los parmetros de
calibracin (p. ej., ajuste del intervalo u otros ajustes o correcciones) y los parmetros de
configuracin (p. ej., valor mximo, valor mnimo, unidades de medida, etc.). Solamente se pueden
ajustar o seleccionar en un modo operativo especial del instrumento. Los parmetros especficos del
dispositivo pueden clasificarse como aquellos que deberan estar protegidos (inalterables) y aquellos a
los que puede acceder una persona autorizada, p. ej., el propietario del instrumento o el proveedor del
producto (parmetros configurables).
Parmetro especfico del modelo: parmetro legalmente relevante cuyo valor depende nicamente
del modelo de instrumento. Los parmetros especficos del modelo forman parte del software
legalmente relevante. Se fijan en el examen de modelo del instrumento.
Parmetro legalmente relevante: parmetro de un instrumento de medida o un subconjunto sometido

a control legal. Se pueden distinguir los siguientes tipos de parmetros legalmente relevantes:
parmetros especficos del modelo y parmetros especficos del dispositivo.
Red abierta: red de participantes arbitrarios (dispositivos con funciones arbitrarias). El nmero, la
identidad y la ubicacin de un participante pueden ser dinmicos y desconocidos para otros
participantes (vase tambin red cerrada).
Red cerrada: red de un nmero fijo de participantes con una identidad, funcionalidad y ubicacin
conocidas (vase tambin red abierta).
Pgina 7 de 115
Registro de actividades: contador software (p. ej., contador de sucesos) y/o un registro de
informacin (p. ej., registro de sucesos) de los cambios realizados en los parmetros o el software
legalmente relevantes.
Separacin del software: separacin inequvoca del software entre el legalmente relevante y el
legalmente no relevante. Si no hay separacin de software, todo el software en conjunto se considera
legalmente relevante.
Software legalmente relevante: programas, datos y parmetros especficos del modelo pertenecientes
a un instrumento de medida o subconjunto, que definen o satisfacen funciones que estn sujetas a
control legal.
Software fijo: parte del software definido como fijo en el examen de modelo, es decir modificable
nicamente con la aprobacin del organismo notificado. Esta parte fija es idntica en cada
instrumento individual.
Solucin aceptable: diseo o base de un mdulo de software o de una unidad de hardware, o de un

elemento que se considera que cumple un requisito determinado. Una solucin aceptable constituye un
ejemplo de cmo se puede cumplir un requisito especfico, sin prejuicio de otras soluciones que
tambin satisfagan ese requisito.
Subconjunto: dispositivo hardware (unidad de hardware) que funciona independientemente y que

junto con otros subconjuntos (o instrumentos de medida), con los cuales es compatible, constituyen un
instrumento de medida [Artculo 4, MID].
TEC: type examination certificate (Certificado de examen de modelo).
Transmisin de datos de medida: transmisin de datos de medida a travs de redes de comunicacin

u otros medios a un dispositivo remoto donde se procesan o utilizan posteriormente con fines
legalmente regulados.
Validacin: confirmacin del cumplimiento de los requisitos particulares para el uso previsto
mediante el examen y la aportacin de evidencias objetivas (p. ej., informacin que puede demostrarse
verdadera basada en datos obtenidos de observaciones, mediciones, ensayos, etc.). En el presente caso
dichos requisitos son los de la MID.
Las siguientes definiciones son bastante especficas. Se usan tan solo en algunos casos y para las
clases de riesgo D o superiores.
Algoritmo hash: algoritmo que comprime el contenido de un bloque de datos en un nmero de

longitud determinada (cdigo hash), de modo que el cambio de cualquier bit del bloque de datos
conlleve, en la prctica, a otro cdigo hash. Los algoritmos hash se seleccionan de tal manera que la
probabilidad terica de que dos bloques de datos diferentes tengan el mismo cdigo hash sea muy
baja.
Algoritmo de firma: algoritmo criptogrfico que cifra (codifica) texto normal en texto cifrado (texto
codificado o secreto) mediante una clave de firma y que permite descodificar el texto cifrado si se
dispone de la correspondiente clave de descifrado.
Autoridad certificadora: asociacin que genera, guarda y emite informacin sobre la autenticidad de
las claves pblicas de personas u otras entidades (p. ej., instrumentos de medida) de manera confiable.
Certificacin de claves: proceso por el que se asocia un valor de clave pblica con un individuo,
organizacin u otra entidad.
Pgina 8 de 115
Clave de firma: cualquier nmero o secuencia de caracteres utilizada para codificar y descodificar
informacin. Hay dos clases diferentes de claves de firma: sistemas de clave simtrica y sistemas de
clave asimtrica. La clave simtrica indica que el emisor y el receptor de la informacin utilizan la
misma clave. El sistema de claves se denomina asimtrico si las claves del emisor y del receptor son
diferentes, pero compatibles. Por lo general, la clave del emisor la conoce el emisor y la clave del
receptor es pblica en un entorno definido.
Infraestructura PKI: organizacin que garantiza la confiabilidad del sistema de claves pblicas.
Incluye la concesin y distribucin de certificados digitales a todos los miembros que forman parte del
intercambio de informacin.
Firma electrnica: cdigo abreviado (firma) que se asigna unvocamente a un texto, bloque de datos
o archivo de software binario para demostrar la integridad y autenticidad de los datos almacenados o
transmitidos. La firma se crea mediante un algoritmo de firma y una clave de firma secreta. Por lo
general, la generacin de una firma electrnica consta de dos pasos: (1) primero, un algoritmo hash
comprime el contenido de la informacin que va a firmarse en un valor abreviado, y (2) a
continuacin, el algoritmo de firma combina este nmero con la clave secreta para generar la firma.
Sistema de clave pblica Public Key Systems (PKS): par de claves de firma diferentes, una
llamada clave secreta y la otra clave pblica. Para verificar la integridad y autenticidad de la
informacin, el valor hash de esta informacin generado por un algoritmo hash se codifica con la
clave secreta del emisor para crear la firma, descifrada ms tarde por el receptor que usa la clave
pblica del emisor.
3. Cmo usar esta gua
Este captulo describe la organizacin de la gua y explica como utilizarla.
3.1 Estructura general
La gua se organiza como una serie estructurada de bloques de requisitos. La estructura general de la
gua sigue la clasificacin de los instrumentos de medida en las configuraciones bsicas y la
clasificacin de las denominadas configuraciones TI. Cada serie de requisitos se complementa con los
requisitos especficos de cada instrumento.
Por lo tanto, existen tres tipos de series de requisitos:
1. requisitos para las dos configuraciones bsicas de los instrumentos de medida (denominadas tipo P y U),
2. requisitos para las cuatro configuraciones TI (denominadas extensiones L, T, S y D)
3. requisitos especficos del instrumento (denominados extensiones I.1, I.2, etc.).
El primer tipo de requisitos es aplicable a todos los instrumentos. El segundo tipo de requisitos atae a
las siguientes funciones TI: almacenamiento a largo plazo de los datos de medida (L), transmisin de
los datos de medida (T), descarga de software (D) y separacin de software (S). Cada serie de estos
requisitos solo se aplica si existe la funcin correspondiente. El ltimo tipo es una coleccin de
requisitos especficos del instrumento. La numeracin se corresponde con la de los anexos especficos
de los instrumentos en la MID. La serie de bloques de requisitos que puede aplicarse a un instrumento
de medida determinado se muestra esquemticamente en la figura 3-1.
Pgina 9 de 115
Requisitos aplicables para

una de las configuraciones Requisitos para las Requisitos aplicables
bsicas de instrumentos de + configuraciones T.I. + especficos del instrumento
medida aplicables
Figura 3-1: Tipo de series de requisitos que deberan aplicarse a un instrumento.
Los esquemas de la figura 3-2 muestran las series de requisitos que existen.
Requisitos del software para las configuraciones bsicas de los instrumentos de medida
Requisitos para los instrumentos de medida Requisitos para los instrumentos de medida que
desarrollados especficamente (tipo P) utilizan un ordenador universal (tipo U)
Bloque de requisitos P1 Bloque de requisitos U1
Bloque de requisitos P2 Bloque de requisitos U2
Requisitos del software para las configuraciones TI

Requisitos para el almacenamiento a largo plazo Requisitos para la separacin
de los datos legalmente relevantes (Extensin L) de software (Extensin S)
Requisitos para la transmisin de los datos Requisitos para la descarga de software

legalmente relevantes (Extensin T) legalmente relevante (Extensin D)
Bloque de Bloque de Bloque de Bloque de

requisitos L1 requisitos T1 requisitos S1 requisitos D1
Bloque de Bloque de Bloque de Bloque de
requisitos L2 requisitos T2 requisitos S2 requisitos D2
Requisitos del software especficos del instrumento

Contadores de Contadores de Contadores de
agua energa elctrica cantidades de lquidos
Contadores de Contadores de Instrumentos

gas energa trmica de pesaje
Bloque de Bloque de Bloque de

requisitos I1-1 requisitos I3-1 requisitos I5-1
Bloque de Bloque de Bloque de
requisitos I2-1 requisitos I4-1 requisitos I6-1
Figura 3-2: Descripcin general de las series de requisitos.
Pgina 10 de 115
Adems de la estructura descrita, los requisitos de esta gua se diferencian segn las clases de riesgo.
Se presentan seis clases de riesgo enumeradas de la A a la F en orden creciente de nivel riesgo. La
clase de menor riesgo (A) y la clase de mayor riesgo (F) no se utilizan en la actualidad. Se reservan
para el caso eventual de que lleguen a ser necesarias en el futuro. Las clases restantes de riesgo que
van de la B a la E abarcan todas las clases de instrumentos regulados por la MID. Proporcionan
adems un rango suficiente para el caso de variar las evaluaciones de riesgo. Las clases se definen en
el captulo 11 de esta gua, el cual es solo de carcter informativo.
Cada instrumento de medida debe asignarse a una clase de riesgo, ya que los requisitos particulares del
software que deben aplicarse quedan determinados por la clase de riesgo a la que pertenece el instrumento.
3.2 Cmo seleccionar los apartados adecuados
Esta gua de software es de aplicacin a una gran variedad de instrumentos. La gua tiene estructura
modular. Las series de requisitos adecuadas pueden seleccionarse fcilmente mediante el siguiente
procedimiento:
Paso 1: Seleccin de la configuracin bsica (P o U)
Solo ser necesario aplicar una de las dos series de requisitos para las configuraciones bsicas. Se
decidir si la configuracin bsica del instrumento se ajusta a: un instrumento desarrollado
especficamente con software integrado (tipo P, vase el apartado 4.1) o un instrumento que utilice un
ordenador universal (tipo U, vase el apartado 5.1). Si no se trata de un instrumento completo, sino de
uno de sus componentes, la decisin se tomar segn dicho componente. Se aplicar la serie completa
de requisitos de la correspondiente configuracin bsica.
Paso 2: Seleccin de las configuraciones TI aplicables (extensiones L, T, S y D)
Las configuraciones TI comprenden: almacenamiento a largo plazo de datos legalmente relevantes (L),
transmisin de datos legalmente relevantes (T), separacin de software (S) y descarga de software
legalmente relevante (D). Las series de requisitos correspondientes, denominadas extensiones
modulares, son independientes entre s. Las extensiones seleccionadas dependen solo de la
configuracin TI. Si se selecciona un conjunto de extensiones, deber aplicarse por completo las series
de requisitos de cada extensin. Se decidir cuales de las extensiones modulares, si la hay, son
aplicables y se aplicarn convenientemente (figura 3-2).
Paso 3: Seleccin de los requisitos especficos del instrumento (extensin I)
Se seleccionarn, segn la extensin especfica del instrumento I.x, los requisitos aplicables
especficos del instrumento, si los hay, y se aplicarn convenientemente (figura 3-2).
Paso 4: Seleccin de la clase de riesgo aplicable (extensin I)
Se seleccionar la clase de riesgo definida en el subapartado I.x.6 correspondiente a la extensin I.x

especfica del instrumento. En este, las clases de riego pueden definirse de manera uniforme para una
clase de instrumentos de medida o de forma diferenciada por categoras, campos de aplicacin, etc.
Una vez que se haya seleccionado la clase de riesgo aplicable, tan solo ser necesario considerar los
requisitos y la gua de validacin respectivos.
3.3 Cmo trabajar con bloques de requisitos
Cada bloque de requisitos contiene un requisito bien definido. Consta de una definicin,
especificaciones aclaratorias, documentacin que debe proporcionarse, gua de validacin y ejemplos
de soluciones aceptables (si estn disponibles). El contenido de un bloque de requisitos puede
Pgina 11 de 115
subdividirse segn las clases de riesgo. En la figura 3-3 se muestra el esquema de un bloque de
requisitos.
Ttulo del requisito

Enunciado del requisito (posible diferenciacin segn las clases de riesgo)
Especificaciones (mbito de aplicacin, explicaciones adicionales, casos excepcionales, etc.)
Documentacin que debe proporcionarse (posible diferenciacin segn las clases de riesgo)
Gua de validacin para una clase de Gua de validacin para otra clase de
riesgo riesgo
Ejemplo de solucin aceptable para Ejemplo de solucin aceptable para
una clase de riesgo otra clase de riesgo
Figura 3-3: Estructura de un bloque de requisitos
El bloque de requisitos representa el contenido tcnico del requisito incluida la gua de validacin. Se
dirige tanto a los fabricantes como a los organismos notificados, en dos sentidos: (1) considerar el
requisito como una condicin mnima y (2) no realizar exigencias adicionales al requisito.
Notas para el fabricante:
- Debe cumplirse el enunciado y las especificaciones adicionales.

- Debe proporcionarse la documentacin tal y como se requiere.
- Las soluciones aceptables son ejemplos que cumplen con el requisito. No existe la obligacin de
seguirlas.
- La gua de validacin tiene carcter informativo.
Notas para los organismos notificados:
- Debe cumplirse el enunciado y las especificaciones adicionales.

- Debe seguirse la gua de validacin.
- Debe confirmarse que la documentacin proporcionada es completa.
3.4 Cmo trabajar con las listas de comprobacin
Las listas de comprobacin son un medio que permite, tanto al fabricante como al examinador,
asegurase de que se han cubierto todos los requisitos de un captulo. Forman parte del modelo del
informe de ensayos. Hay que tener en cuenta que las listas de comprobacin solo son un resumen y no
distinguen entre clases de riesgo. Las listas de comprobacin no sustituyen a las definiciones del
requisito. Debe consultarse los bloques de requisitos para las descripciones completas.
Procedimiento:
- Se recopilarn las listas de comprobacin necesarias segn la seleccin descrita en los pasos 1, 2 y 3
del apartado 3.2.
- Se repasarn las listas de comprobacin verificando que se han cumplido todos los requisitos.
- Se rellenarn adecuadamente las listas de comprobacin.
4 Requisitos bsicos del software integrado en un instrumento de medida desarrollado

especficamente (tipo P)
La serie de requisitos de este captulo es vlida tanto para instrumentos como para componentes de
instrumentos desarrollados especficamente. Tambin es vlida para los subconjuntos aunque no se
mencione de forma explcita en el texto. Si el instrumento de medida utiliza un ordenador universal
(PC de propsito general), deber referirse a la serie de requisitos del siguiente captulo (instrumento
Pgina 12 de 115
tipo U). Tambin se aplicarn los requisitos para instrumentos tipo U si el instrumento no se ajusta con
la siguiente descripcin tcnica.
4.1 Descripcin tcnica
Un instrumento de tipo P es un instrumento de medida con un sistema TI integrado (generalmente es

un sistema basado en un microprocesador o microcontrolador), con las siguientes caractersticas:
Toda la aplicacin software ha sido desarrollada para la medicin. Esta aplicacin incluye tanto las
funciones que estn sometidas a control legal como otras funciones.
La interfaz de usuario es especfica para la medicin (es decir, est normalmente en un modo
operativo sometido a control legal). Es posible cambiar a un modo operativo que no est sometido
a control legal.
Si existe un sistema operativo, este no tiene un intrprete de comandos accesible al usuario (para
cargar o modificar programas, enviar comandos al sistema operativo, cambiar el entorno de la
aplicacin,...).
El instrumento de tipo P puede tener propiedades y caractersticas adicionales que se tratan en las
siguientes extensiones de requisitos:
El software se disea y se trata como un todo, a menos que se haya aplicado una separacin de
software segn la extensin S.
El software es invariable y no hay modo de programar o cambiar el software legalmente relevante.
Solo se permite la descarga de software si se cumple la extensin D.
Se permiten las interfaces de transmisin de los datos de medida a travs de redes de comunicacin
abiertas o cerradas (debe cumplirse la extensin T).
Se permite el almacenamiento de datos de medida, ya sea en un almacenamiento integrado, en uno
remoto o en uno extrable (debe cumplirse la extensin L).
4.2 Requisitos especficos para el tipo P

Clases de riesgo de la B a la E
P1: Documentacin
Adems de la documentacin especfica requerida en cada uno de los siguientes requisitos, la
documentacin incluir bsicamente:
a) Descripcin del software legalmente relevante,
b) Descripcin de la exactitud de los algoritmos de medida (p. ej., algoritmos de redondeo y clculo
de precios),
c) Descripcin de la interfaz de usuario, los mens y los dilogos,
d) Identificacin inequvoca del software,
e) Si no est descrita en el manual de funcionamiento, descripcin general del hardware del sistema
(p. ej., diagrama topolgico de bloques, tipo de ordenador(es), tipo de red, etc.),
f) Manual de funcionamiento.
Pgina 13 de 115
Clase de riesgo B Clase de riesgo C Clase de riesgo D

P2: Identificacin del software:
El software legalmente relevante deber estar claramente identificado. La identificacin del software
estar inequvocamente ligada al mismo. Deber presentarse mediante un comando o durante el
funcionamiento.
Especificaciones: Especificaciones
1. Las modificaciones del 1. Adems de la especificacin 1B: cada modificacin del software
software metrolgicamente legalmente relevante definido como fijo en el examen de modelo
relevante requieren informacin requiere una nueva identificacin del software.
del organismo notificado. El
organismo notificado decide si
es necesaria o no una nueva
identificacin del software. Solo
se requiere una nueva
identificacin del software si las
modificaciones de este
conducen a cambios de las
funciones o caractersticas
aprobadas.
2. La identificacin del software ser fcilmente visualizable para verificacin e inspeccin (fcilmente
significa mediante la interfaz de usuario habitual, sin herramientas adicionales).
3. La identificacin del software tendr una estructura que identifique claramente las versiones que
requieran examen de modelo y las que no.
4. Si los parmetros especficos del modelo pueden modificar las funciones del software , cada funcin o
variante puede identificarse independientemente o bien puede identificarse el paquete entero en su
conjunto.
Documentacin requerida: Documentacin requerida
La documentacin contendr la identificacin del software y (adems de la documentacin
describir cmo se genera dicha identificacin, cmo est requerida para las clases de riesgo
inequvocamente ligada al propio software, cmo puede visualizarse B y C):
y cmo se estructura para diferenciar entre cambios de versin que La documentacin mostrar las
necesiten o no examen de modelo. medidas tomadas para proteger la
identificacin del software frente a
la falsificacin.
Gua de validacin: Gua de validacin (adems de la
Comprobaciones basadas en la documentacin: gua para las clases de riesgo B y
Se examinar la descripcin de la generacin y visualizacin de C):
la identificacin del software. Comprobaciones basadas en la
Se comprobar si todos los programas que realizan funciones documentacin:
legalmente relevantes estn claramente identificados y descritos Se comprobar si son adecuadas
de modo que quede claro tanto para el organismo notificado las medidas de proteccin tomadas
como para el fabricante, qu funciones de software estn frente a la falsificacin.
cubiertas por la identificacin del software y cules no.
Se comprobar si el fabricante proporciona un valor nominal de
la identificacin (nmero de versin o suma de comprobacin
funcional). Este deber indicarse en el certificado de ensayos.
Comprobaciones funcionales:
Se comprobar que la identificacin del software puede
visualizarse tal y como se describe en la documentacin.
Se comprobar que la identificacin presentada es correcta.
Pgina 14 de 115
Ejemplo de solucin aceptable:

La identificacin del software legalmente relevante se compone de dos partes. La parte (A) debe
modificarse si los cambios del software requieren un nuevo examen. La parte (B) tan solo indica
cambios menores del software (p. ej., correcciones de errores) que no requieren un nuevo examen.
La identificacin se genera y visualiza a travs de un comando.
La parte (A) de la La parte (A) de la identificacin consiste en una suma de
identificacin consiste en un comprobacin generada automticamente sobre el software
nmero de versin o el nmero legalmente relevante que se ha declarado fijo en el examen de
del certificado de examen de modelo. Para el otro software legalmente relevante, la parte (A) es
modelo. un nmero de versin o el nmero del certificado de examen de
modelo.
Un ejemplo de solucin aceptable para generar la suma de
comprobacin es el algoritmo CRC-16.
Consideraciones adicionales para la clase de riesgo E

Documentacin requerida (adems de la documentacin requerida para las clases de riesgo B y C):
El cdigo fuente que contiene la generacin de la identificacin.
Gua de validacin (adems de la gua para las clases de riesgo B y C):
Comprobaciones basadas en el cdigo fuente:
Se comprobar si todas las partes relevantes del software estn cubiertas por el algoritmo que genera
la identificacin.
Se comprobar la correcta implementacin del algoritmo.
Pgina 15 de 115

P3: Influencia sobre el software a travs de la interfaz de usuario
Los comandos introducidos a travs de la interfaz de usuario no influirn en el software legalmente
relevante ni en los datos de medida de forma inadmisible.
Especificaciones:
1. Los comandos pueden ser una actuacin o secuencia de actuaciones a travs de teclas o interruptores
llevadas a cabo manualmente.
2. Esto implica que hay una asignacin inequvoca de cada comando a una funcin o cambio de datos.
3. Esto implica que las actuaciones a travs de teclas o interruptores que no estn declaradas ni
documentadas como comandos no tienen ningn efecto en las funciones y datos de medida del
instrumento.

Si el instrumento tiene la capacidad de recibir comandos, la (adems de la documentacin
documentacin incluir: requerida para las clases de riesgo
Una lista completa de todos los comandos (p. ej., elementos de B y C):
men) junto con una declaracin de que no existen otros La documentacin mostrar las
comandos distintos de los relacionados. medidas tomadas para validar que
Una breve descripcin de su significado y su efecto en las la documentacin de los comandos
funciones y datos del instrumento de medida. es completa.
La documentacin contendr un
protocolo que muestre las pruebas
de todos los comandos.
Se evaluar si todos los comandos documentados son admisibles; C):
es decir, si tienen o no un efecto permitido en las funciones de Comprobaciones basadas en la
medida (y datos relevantes). documentacin:
Se comprobar si el fabricante ha suministrado una declaracin Se comprobar si las medidas
explcita de que la documentacin de comandos es completa. tomadas y los protocolos de
Comprobaciones funcionales: prueba son adecuados para el
Se realizarn pruebas (aleatorias) tanto con los comandos nivel de proteccin alto.
documentados como con los no documentados. Se comprobarn todos
los elementos de men, si existen.
Existe un mdulo de software que recibe e interpreta comandos de la interfaz de usuario. Este mdulo
pertenece al software legalmente relevante. Solo transmite comandos permitidos a los otros mdulos de
software legalmente relevantes. Todas las secuencias de actuaciones a travs de teclas o interruptores
desconocidas o no permitidas se rechazan y carecen de efecto alguno en el software o en los datos de
medida legalmente relevantes.

El cdigo fuente del instrumento.
Se comprobar en el diseo del software si el flujo de datos relativo a los comandos del software
legalmente relevante est definido de manera inequvoca y puede verificarse.
Se buscarn flujos de datos inadmisibles desde la interfaz de usuario hasta los dominios que deban
protegerse.
Se comprobar manualmente o mediante herramientas que los comandos se descodifican
correctamente y que no existen comandos no documentados.
Pgina 16 de 115

P4: Influencia sobre el software a travs de interfaces de comunicacin
Los comandos introducidos a travs de interfaces de comunicacin del instrumento no influirn en el
software legalmente relevante ni en los datos de medida de forma inadmisible.
Especificaciones:
1. Esto implica que hay una asignacin inequvoca de cada comando a una funcin o cambio de datos
2. Esto implica que las seales o cdigos que no estn declarados ni documentados como comandos no
tienen ningn efecto en las funciones y datos de medida del instrumento.
3. Los comandos pueden ser una secuencia de seales elctricas (pticas, electromagnticas, etc.) sobre
los canales de entrada o cdigos en los protocolos de transmisin de datos.
4. No son aplicables las restricciones de este requisito cuando se realiza una descarga de software segn
la extensin D.
5. Este requisito se aplica solo a interfaces que no estn selladas.

Si el instrumento dispone de una interfaz, la documentacin (adems de la documentacin
incluir: requerida para las clases de riesgo
Una lista completa de todos los comandos junto con una B y C):
declaracin de que no existen otros comandos distintos de los La documentacin mostrar las
relacionados. medidas tomadas para validar que
Una breve descripcin de su significado y su efecto en las la documentacin de los comandos
funciones y datos del instrumento de medida. es completa.
de todos los comandos o
cualquier otra medida adecuada
para probar que son correctos.
Se evaluar si todos los comandos documentados son admisibles, C):
es decir, si tienen un efecto permitido o ningn tipo de efecto en Comprobaciones basadas en la
las funciones de medida (y datos relevantes). documentacin:
Se comprobar si el fabricante ha suministrado una declaracin Se comprobar que las medidas
explcita de que la documentacin de comandos es completa. tomadas y los protocolos de
Comprobaciones funcionales: prueba son adecuados para el
Se realizarn pruebas (aleatorias) , mediante equipos perifricos, si nivel de proteccin alto.
existen.
Nota: Si no es posible excluir efectos inadmisibles en las funciones de
medicin (o datos relevantes) a travs de la interfaz y si el software no se
puede corregir como correspondera, el certificado de ensayos deber
indicar que la interfaz no es protectora y describir los medios necesarios
de seguridad/sellado. Esto tambin es de aplicacin a las interfaces no
descritas en la documentacin.
Existe un mdulo de software que recibe e interpreta datos de la interfaz. Este mdulo pertenece al
software legalmente relevante. Solo transmite comandos permitidos a los otros mdulos del software
legalmente relevante. Todas las secuencias de seales o cdigo desconocidas o no permitidas se rechazan
y carecen de efecto alguno en el software o en los datos de medida legalmente relevantes.
Pgina 17 de 115

Se comprobar en el diseo del software si el flujo de datos relativo a comandos del software
Se buscarn flujos de datos inadmisibles desde la interfaz usuario hasta los dominios que deban
protegerse.

P5: Proteccin frente a cambios accidentales o no intencionados
El software legalmente relevante y los datos de medida estarn protegidos frente a modificaciones
involuntarias.
Especificaciones:
Las posibles causas de fallos y modificaciones accidentales son: influencias fsicas impredecibles,
efectos causados por las funciones de usuario y defectos residuales del software, incluso aunque se
hayan aplicado las tcnicas de desarrollo actuales. Este requisito incluye:
a) Influencias fsicas: los datos de medida almacenados debern estar protegidos frente a la
corrupcin o borrado cuando ocurre un fallo o, de forma alternativa, se detectar el fallo.
b) Funciones de usuario: Antes de modificar o borrar datos, se solicitar confirmacin.
c) Defectos del software: Debern tomarse las medidas apropiadas para proteger los datos frente a los
modificaciones no intencionados que pudieran producirse por un diseo incorrecto del programa o
errores de programacin (p. ej., comprobaciones de fiabilidad).
Documentacin requerida:
La documentacin deber mostrar las medidas tomadas para proteger el software y los datos frente a
modificaciones involuntarias.
Gua de validacin:
Comprobaciones basadas en la documentacin:
Se comprobar que se genera y verifica de forma automtica una suma de comprobacin del cdigo
del programa y de los parmetros relevantes.
Se comprobar que no pueden sobrescribirse los datos antes de que finalice el periodo de tiempo
previsto y documentado por el fabricante para el almacenamiento de estos.
Se comprobar que aparece un mensaje de advertencia en caso de que el usuario est a punto de
eliminar archivos que contengan datos de medida.
Si existe la posibilidad de eliminar totalmente los datos de medida, se verificar mediante
comprobaciones aleatorias que aparece un mensaje de advertencia antes de realizar esta accin.
La modificacin accidental del software y de los datos de medida puede comprobarse mediante el
clculo de una suma de comprobacin de las partes relevantes, comparndola con el valor nominal
y, en caso de variacin, deteniendo la modificacin.
Los datos de medida no se borran sin una autorizacin previa; p. ej., un cuadro de dilogo o una
ventana que pide confirmacin para su borrado.
Para la deteccin de fallos consltese tambin la extensin I.
Pgina 18 de 115

Gua de validacin (adems de la gua para las clases de riesgo B, C y D):
Se comprobar si las medidas tomadas para la deteccin de modificaciones (fallos) son adecuadas.
Si se aplica una suma de comprobacin, se deber comprobar si esta incluye todas las partes del software
Pgina 19 de 115

P6: Proteccin frente a las modificaciones intencionadas
El software legalmente relevante estar protegido frente a modificaciones, cargas o intercambios
(swapping) inadmisibles de la memoria hardware.
Especificaciones:
1. Instrumento sin interfaces: La manipulacin del cdigo de programa podra ser posible mediante la
manipulacin de la memoria fsica, es decir, la memoria se extrae fsicamente y se reemplaza por
una que contenga software o datos fraudulentos. Para prevenir que esto suceda, la carcasa del
instrumento debera protegerse o la memoria fsica se proteger frente a la extraccin no
autorizada.
2. Instrumento con interfaces: Las interfaces no incluirn ms funciones que las examinadas. Todas
las funciones de las interfaces se sometern a examen (vase P4). Cuando las interfaces se utilicen
para la descarga de software, deber cumplirse la extensin D.
3. Se considerar que los datos estn suficientemente protegidos solo si los procesa el software
legalmente relevante. Si se pretende modificar el software legalmente no relevante despus del
examen de modelo, debern cumplirse los requisitos de la extensin S.
La documentacin garantizar que el software legalmente (adems de la documentacin
relevante no pueda modificarse de forma inadmisible. requerida para las clases de riesgo
B y C):
Se describirn las medidas
tomadas para proteger frente a los
cambios intencionados.
Se examinar si son suficientes los medios documentados de C):
seguridad frente a intercambios no autorizados de la memoria Comprobaciones basadas en la
que contiene el software. documentacin:
Si la memoria puede programarse en circuito (sin desmontarla), Se comprobar si las medidas
se comprobar si el modo de programacin puede tomadas son adecuadas con
deshabilitarse elctricamente y si pueden protegerse/precintarse respecto a la tecnologa actual
los medios para deshabilitarlo. (Para la comprobacin de los para garantizar un nivel de
medios de descarga, vase la extensin D) proteccin alto.
Se comprobar de forma prctica el modo de programacin y se
comprobar si funciona la deshabilitacin.
El instrumento est precintado y las interfaces cumplen los requisitos P3 y P4.

Se comprobar en el cdigo fuente si las medidas tomadas para la deteccin de cambios
intencionados son adecuadas.
Pgina 20 de 115

P7: Proteccin de parmetros
Los parmetros que fijan las caractersticas legalmente relevantes del instrumento de medida estarn
protegidos frente a modificaciones no autorizadas.
Especificaciones:
1. Los parmetros especficos del modelo son idnticos para cada ejemplar del mismo y, generalmente,
forman parte del cdigo del programa. Por lo tanto, se les aplica el requisito P6.
2. Los parmetros especficos del dispositivo considerados protegidos pueden modificarse mediante el
uso de un teclado integrado o interruptores o a travs de interfaces, pero nicamente antes de que se
hayan protegido.
3. Los parmetros especficos del dispositivo considerados configurables pueden modificarse despus
de protegerse.
La documentacin debera describir todos los parmetros (adems de la documentacin
legalmente relevantes, sus rangos y valores nominales, dnde estn requerida para las clases de riesgo
almacenados, cmo pueden visualizarse, cmo y cundo han sido B y C):
protegidos, es decir, antes o despus de la verificacin. Se describirn las medidas
tomadas para la proteccin de los
parmetros.
Se comprobar que es imposible cambiar o ajustar los parmetros C):
especficos del dispositivo protegidos despus de protegerlos. Comprobaciones basadas en la
Se comprobar si todos los parmetros relevantes segn las listas documentacin:
(proporcionadas en la extensin I, si existen) se han clasificado Se comprobar si las medidas
como protegidos. tomadas son adecuadas con
Comprobaciones funcionales: respecto a la tecnologa actual
Se comprobar el modo de ajuste (configuracin) y se para garantizar un nivel de
comprobar si funciona la deshabilitacin tras la proteccin. proteccin alto .
Se examinar la clasificacin y el estado de los parmetros
(protegido/configurable) en la pantalla del instrumento, si existe
una opcin de men para ello.
a) los parmetros se protegen precintando el instrumento o la carcasa de la memoria y deshabilitando la
entrada que habilita/deshabilita la escritura del circuito de memoria mediante un puente de conexin o
interruptor asociados que tambin se han protegido.
Registros de actividades:
b) Un contador de sucesos registra cada modificacin del valor de
los parmetros. Puede mostrarse el recuento actual y compararse
con el valor inicial del contador registrado en la ltima
verificacin oficial y est etiquetado de forma indeleble en el
instrumento.
c) Las modificaciones de los parmetros se registran en un registro
de sucesos. Es un registro de informacin almacenado en una
memoria no voltil. Cada entrada es generada automticamente
por el software legalmente relevante y contiene:

la identificacin del parmetro (p. ej., el nombre)
el valor del parmetro (el actual o el valor anterior)
el registro de fecha y hora del cambio.
El registro de sucesos no puede eliminarse ni modificarse sin
destruir un precinto.
Pgina 21 de 115
Clase de riesgo E
El cdigo fuente que muestra la forma de proteger y visualizar los parmetros legalmente relevantes.
Se comprobar en el cdigo fuente si son adecuadas las medidas tomadas para proteger los
parmetros (p. ej., modo de ajuste deshabilitado despus de la proteccin).
5 Requisitos bsicos del software de los instrumentos de medida que utilizan un ordenador
universal (tipo U)
La serie de requisitos del software de esta seccin se aplica a un instrumento basado en un ordenador
de propsito general. La descripcin tcnica del sistema de medida tipo U se resume a continuacin.
Bsicamente se debe asumir un sistema de tipo U si no se cumplen las condiciones de un instrumento
de tipo P (vase el captulo 4.1).
Configuracin hardware
a) Sistema modular basado en un ordenador de propsito general. El ordenador puede ser autnomo,
formar parte de una red cerrada (p. ej., Ethernet, LAN token ring) o parte de una red abierta (p. ej.,
Internet).
b) Puesto que el sistema es de propsito general, la unidad del sensor (mdulo de medida)
normalmente ser externo al ordenador y estar conectado a l mediante un enlace de
comunicacin cerrado. No obstante, el enlace de comunicacin tambin podra ser abierto (p. ej.,
red), de manera que podran conectarse varios sensores.
c) La interfaz de usuario puede cambiarse de un modo operativo, que no est sometido a control
legal, a uno que s lo est, y viceversa.
d) El almacenamiento puede ser fijo (p. ej., disco duro) o extrable (p. ej., disquetes, CD-RW).
Configuracin software
e) Puede utilizarse cualquier sistema operativo. Adems de la aplicacin del instrumento de medida,
pueden encontrarse a la vez otras aplicaciones de software en el sistema. Parte del software (p. ej.,
la aplicacin del instrumento de medida) est sometido a control legal y no puede modificarse de
forma inadmisible despus de la aprobacin. Las partes que no estn sometidas a control legal
pueden modificarse.
f) El sistema operativo y los drivers de bajo nivel (p. ej., los drivers de vdeo, de la impresora, del
disco, etc.) son legalmente no relevantes a menos que estn programados especialmente para una
tarea de medida especfica
Pgina 22 de 115
5.2 Requisitos especficos del software para el tipo U
U1: Documentacin
Adems de la documentacin especfica requerida en cada uno de los requisitos que figuran a
continuacin, la documentacin incluir bsicamente:
a. Una descripcin de las funciones de software legalmente relevantes, el significado de los datos, etc.
b. Descripcin de la exactitud de los algoritmos de medida (p. ej., algoritmos de redondeo y
clculo de precios)
c. Descripcin de la interfaz de usuario, los mens y los dilogos.
d. Una identificacin del software legal.
e. Descripcin general del hardware del sistema (p. ej., diagrama topolgico de bloques, tipo de
ordenador(es), tipo de red, etc.), si no est descrita en el manual de funcionamiento.
f. Descripcin general de los aspectos de seguridad del sistema operativo (p. ej., proteccin,
cuentas de usuario, privilegios, etc.).
g. Manual de funcionamiento.
Pgina 23 de 115

U2: Identificacin del software:
El software legalmente relevante deber estar claramente identificado. La identificacin del software
estar inequvocamente ligada al mismo. Deber determinarse y presentarse mediante un comando o
durante el funcionamiento.
Especificaciones: Especificaciones:
1. La identificacin excluye al 1. Restriccin de 1B: se identificarn los drivers (de bajo nivel)
sistema operativo y a los drivers definidos como relevantes en el examen de modelo.
de bajo nivel (p. ej., los drivers de 2. Adems de 2B: Cada modificacin del cdigo del programa
vdeo, de la impresora, del disco, legalmente relevante definido como fijo en el examen de
etc.), pero debe incluir los drivers modelo o modificaciones de los parmetros especficos del
programados especialmente para modelo requieren una nueva identificacin del software.
una tarea especfica legalmente
relevante.
2. Las modificaciones del software
metrolgicamente relevante
requieren informacin del
organismo notificado. El
organismo notificado decide si es
necesaria o no una nueva
identificacin del software. Solo
se requiere una nueva
identificacin del software si las
modificaciones de este conducen
a cambios de las funciones o
caractersticas aprobadas.
3. La identificacin del software ser fcilmente visualizable para verificacin e inspeccin (fcilmente
significa mediante la interfaz de usuario habitual, sin herramientas adicionales).
4. La identificacin del software tendr una estructura que identifique claramente las versiones que
requieran examen de modelo y las que no.
5. La identificacin puede aplicarse a diferentes niveles, p. ej., para programas completos, mdulos,
funciones, etc.
6. Si las funciones del software pueden modificarse mediante parmetros, cada funcin o variante puede
identificarse independientemente o bien puede identificarse el paquete entero en su conjunto.

La documentacin contendr la identificacin del software y (adems de la documentacin
describir cmo se genera dicha identificacin, cmo est requerida para las clases de riesgo
inequvocamente ligada al propio software, cmo puede visualizarse B y C):
y cmo se estructura para diferenciar entre cambios de versin que La documentacin mostrar las
necesiten o no examen de modelo. medidas tomadas para proteger la
identificacin del software frente a
la falsificacin.
Pgina 24 de 115

Se examinar la descripcin de la generacin y visualizacin de la C):
identificacin del software. Comprobaciones basadas en la
Se comprobar si todo el software legalmente relevante est documentacin:
claramente identificado y descrito de modo que quede claro tanto Se comprobar si son adecuadas
para el organismo notificado como para el fabricante, qu las medidas de proteccin tomadas
funciones de software estn cubiertas por la identificacin del frente a la falsificacin.
software y cules no.
Se comprobar si el fabricante proporciona un valor nominal de la
identificacin (nmero de versin o suma de comprobacin
funcional). Este deber indicarse en el certificado de ensayos.
Se comprobar que la identificacin del software puede
visualizarse tal y como se describe en la documentacin.
Se comprobar que la identificacin presentada es correcta.

La identificacin del software legalmente relevante se compone de de dos partes. La parte (A) debe
modificarse si los cambios del software requieren un nuevo examen. La parte (B) tan solo indica
cambios menores del software (p. ej., correcciones de errores) que no requieren un nuevo examen.
La parte (B) de la identificacin se genera y visualiza a travs de un comando.
La parte (A) de la identificacin La parte (A) de la identificacin consiste en una suma de
consiste en un nmero de versin comprobacin generada automticamente sobre el software
o el nmero del certificado de legalmente relevante que se ha declarado fijo en el examen de
examen de modelo. Para evitar modelo. Para el otro software legalmente relevante, la parte (A)
que se modifique con es un nmero de versin o el nmero del certificado de examen
herramientas de software de modelo. Para evitar que se modifique con herramientas de
simples, se almacena en el software simples, se almacena en formato binario en el archivo
archivo del programa ejecutable del programa ejecutable.
en formato binario. Una solucin aceptable Los algoritmos aceptables para la
para realizar la suma de suma de comprobacin son
comprobacin es el CRC- CRC-32 o los algoritmos hash
16. (como SHA-1, MD5,
RipeMD160, etc.).

El cdigo fuente que contiene la generacin de la identificacin.
Se comprobar si todas las partes relevantes del software estn cubiertas por el algoritmo que genera
la identificacin.
Se comprobar la correcta implementacin del algoritmo.
Pgina 25 de 115

U3: Influencia sobre el software a travs de la interfaz de usuario
Los comandos introducidos a travs de la interfaz de usuario no influirn en el software legalmente
relevante ni en los datos de medida de forma inadmisible.
Especificaciones:
1. Esto implica que hay una asignacin inequvoca de cada comando a una funcin o cambio de
datos.
2. Esto implica que las actuaciones a travs de teclas o interruptores que no estn declaradas ni
documentadas como comandos no tienen ningn efecto en las funciones y datos de medida del
instrumento.
3. Los comandos pueden ser una sola actuacin o secuencia de actuaciones llevadas a cabo por el
operador. Se proporcionar informacin al usuario sobre qu comandos estn permitidos.
4. El intrprete de comandos del

usuario estar cerrado, es decir,
el usuario no podr cargar ni
escribir programas, ni ejecutar
comandos en el sistema
operativo.
La documentacin incluir: (adems de la documentacin
Una lista completa de todos los comandos junto con una requerida para las clases de riesgo B
declaracin de que no existen otros comandos distintos de los y C):
relacionados. La documentacin mostrar las
Una breve descripcin de su significado y su efecto en las medidas tomadas para validar que la
funciones y datos del instrumento de medida. documentacin de los comandos es
completa.
de todos los comandos.
Se evaluar que todos los comandos documentados son C):
admisibles; es decir, si tienen o no un efecto permitido en las Comprobaciones basadas en la
funciones de medida (y datos relevantes). documentacin:
Se comprobar que el fabricante ha suministrado una Se comprobar si las medidas
declaracin explcita de que la documentacin de comandos tomadas y los protocolos de prueba
es completa. son adecuados para el nivel de
Comprobaciones funcionales: proteccin alto.
Se realizarn pruebas (aleatorias) tanto con los comandos
documentados como con los no documentados. Se comprobarn
todos los elementos de men, si existen.
Un mdulo en el software legalmente relevante filtra comandos inadmisibles. Solo este mdulo
recibe comandos y no hay forma de eludirlo. Se bloquear cualquier entrada falsa. Mediante un
mdulo de software especial, se controla y orienta al usuario en la introduccin de comandos. Este
mdulo de orientacin est ligado inequvocamente al mdulo que bloquea los comandos
inadmisibles.
Se bloquea el acceso al sistema
operativo.
Pgina 26 de 115

El cdigo fuente del software legalmente relevante.
protegerse.

U4: Influencia a travs de la interfaz de comunicacin
Los comandos introducidos a travs de interfaces de comunicacin no protegidas del dispositivo no
influirn de forma inadmisible en el software legalmente relevante ni en los datos de medida.
Especificaciones:
1. Esto implica que hay una asignacin inequvoca de cada comando a una funcin o cambio de datos
2. Esto implica que las seales o cdigos que no estn declarados ni documentados como comandos no
tienen ningn efecto en las funciones y datos del instrumento.
3. Los comandos pueden ser una secuencia de seales elctricas (pticas, electromagnticas, etc.) sobre
los canales de entrada o cdigos en los protocolos de transmisin de datos.
4. No son aplicables las restricciones de este requisito cuando se realiza una descarga de software segn
la extensin D.
5. Aquellas partes del sistema operativo que interpreten 5. Todos los programas y partes del programa
comandos legalmente relevantes se considerarn involucrados en la transmisin y recepcin
software legalmente relevante. de comandos o datos legalmente relevantes
6. Otras partes del software pueden utilizar la interfaz estarn bajo la supervisin del software
siempre que no perturben o falsifiquen la recepcin o legalmente relevante.
transmisin de los comandos o datos legalmente 6. La interfaz que recibe o transmite
relevantes comandos o datos legalmente relevantes
ser especfica para esta funcin y
nicamente podr utilizarla el software
legalmente relevante. Sin embargo, no se
excluye el uso de interfaces estndar, si se
implementan medidas de proteccin de
software de acuerdo con la extensin T.
Documentacin requerida: Documentacin requerida (adems de la
La documentacin incluir: documentacin requerida para las clases de
Una lista completa de todos los comandos junto con riesgo B y C):
una declaracin de que no existen otros comandos La documentacin mostrar las medidas
distintos de los relacionados. tomadas para validar que la documentacin de
Una breve descripcin de su significado y su efecto en los comandos es completa.
las funciones y datos del instrumento de medida. La documentacin contendr un protocolo que
muestre las pruebas de todos los comandos o
cualquier otra medida adecuada para probar
que son correctos.
Pgina 27 de 115
Gua de validacin: Gua de validacin (adems de la gua para

Comprobaciones basadas en la documentacin: las clases de riesgo B y C):
Se evaluar si todos los comandos documentados son Comprobaciones basadas en la
admisibles, es decir, si tienen un efecto permitido o documentacin:
ningn tipo de efecto en el software (y los datos de Se comprobar que las medidas tomadas y los
medida) legalmente relevantes. protocolos de prueba son adecuados para el
Se comprobar si el fabricante ha suministrado una nivel de proteccin alto.
declaracin explcita de que la documentacin de
comandos es completa.
Se realizarn pruebas (aleatorias), mediante equipos
perifricos, si existen.
Existe un mdulo de software que recibe e interpreta comandos de la interfaz. Este mdulo pertenece al
software legalmente relevante. Solo reenva comandos permitidos a los otros mdulos del software
legalmente relevante. Todos los comandos desconocidos o no permitidos se rechazan y carecen de efecto
alguno en el software o en los datos de medida legalmente relevantes.

protegerse.
Pgina 28 de 115

U5: Proteccin frente a cambios accidentales o no intencionados
El software legalmente relevante y los datos de medida estarn protegidos frente a modificaciones no
intencionadas.
Especificaciones:
1. Los cambios no intencionados pueden deberse a:
a. Un diseo de programa incorrecto, p. ej., funcionamiento en bucle incorrecto, modificacin de
variables globales en una funcin, etc.
b. Un uso incorrecto del sistema operativo
c. La sobrescritura o eliminacin accidental de los datos y programas almacenados (vase tambin la
extensin L).
d. Asignacin incorrecta de los datos de una transaccin de una medicin. Las medidas y los datos
pertenecientes a una transaccin de una medicin no deben mezclarse con aquellos de una
transaccin diferente debido a la programacin o almacenamiento incorrectos.
e. Efectos fsicos (perturbacin electromagntica, temperatura, vibracin, etc.).
La documentacin debera mostrar las medidas tomadas para (adems de la documentacin
proteger el software y los datos frente a modificaciones requerida para las clases de riesgo
involuntarias. B y C):
La documentacin mostrar las
medidas tomadas para validar la
efectividad de los medios de
proteccin.
Se comprobar que se genere y se verifique de forma automtica C):
una suma de comprobacin del cdigo del programa y de los Comprobaciones basadas en la
parmetros relevantes. documentacin:
Se comprobar que no pueden sobrescribirse los datos antes de Se comprobar que las medidas
que finalice el periodo de tiempo previsto y documentado por el tomadas son adecuadas para un
fabricante para el almacenamiento de estos. nivel de proteccin alto.
Se comprobar que aparece un mensaje de advertencia en caso de
que el usuario est a punto de eliminar archivos que contengan
datos de medida.
Si existe la posibilidad de eliminar totalmente los datos de medida,
se verificar mediante comprobaciones aleatorias que aparece un
mensaje de advertencia antes de realizar esta accin.
Prevencin del diseo incorrecto del programa esto queda fuera del alcance de estas clases de riesgo.
Uso incorrecto del sistema operativo, sobrescritura o eliminacin de los datos y programas
almacenados - el fabricante debera hacer un uso total de los derechos de proteccin o privacidad
proporcionados por el sistema operativo o por el lenguaje de programacin.
La modificacin accidental de los programas y archivos de datos puede comprobarse mediante el
clculo de una suma de comprobacin del cdigo relevante, comparndolo con el valor nominal y
detenindolo si se ha modificado el cdigo, o reaccionando de manera adecuada si se han visto
afectados parmetros o datos.
Cuando el sistema operativo lo permita, se recomienda que se eliminen todos los derechos de usuario
para la eliminacin, movimiento o modificacin del software legalmente relevante y que el acceso se
controle mediante otros programas de utilidad. Se recomienda el acceso a los programas y datos
mediante contraseas, as como el uso de modos de solo lectura. El supervisor del sistema debera
restaurar los derechos solo cuando sea necesario.
Pgina 29 de 115

Se comprobar si las medidas tomadas para la deteccin de modificaciones (fallos) son adecuadas.
Si se aplica una suma de comprobacin, se deber comprobar si esta incluye todas las partes del software

U6: Proteccin frente a los cambios intencionados
El software y datos de medida legalmente relevantes se protegern frente a modificaciones inadmisibles.
1. Pueden considerarse intentos de modificacin con fines 1. El nivel de proteccin debera
fraudulentos: ser equivalente al del pago
a. Modificacin del cdigo del programa incluidos los datos electrnico.
integrados - si el cdigo del programa est en formato En general, un ordenador
ejecutable (.exe), estar suficientemente protegido para las universal solo es adecuado para
clases de riesgo B y C. esta clase de riesgo si dispone de
b. Modificacin de los datos de medida - vase la extensin L. hardware adicional para la
2. La sustitucin del software aprobado no deber ser posible proteccin.
utilizando simplemente el sistema operativo, p. ej., cargar y
utilizar software no aprobado (vase, p. ej., U3). Para descarga de
software, vase la extensin D.
3. Cuando sea necesario, se tomarn medidas para proteger el software
legalmente relevante frente a la modificacin llevada a cabo
mediante herramientas simples (p. ej., editores de texto).
La documentacin debera garantizar que el software y los datos de (adems de la documentacin
medida almacenados no pueden modificarse de forma inadmisible. requerida para las clases de
riesgo B y C):
Se deben describir las medidas
de proteccin tomadas.
Gua de validacin: Gua de validacin (adems de
Caso 1: Intrprete de comandos cerrado del software sometido a la gua para las clases de riesgo
control legal. B y C):
Comprobaciones basadas en la documentacin: Comprobaciones basadas en la
Los mdulos de software se inician automticamente. documentacin:
El usuario no tiene acceso al sistema operativo del PC. Se comprobar si las medidas
El usuario no tiene acceso a ningn otro software que no sea el tomadas son adecuadas con
aprobado. respecto a la tecnologa actual
Se proporciona una declaracin escrita que indica que no hay para garantizar un nivel de
funciones ocultas para eludir el intrprete de comandos cerrado. proteccin alto.
Caso 2: Sistema operativo y/o software accesible al usuario.
Con el cdigo mquina de los mdulos de software se genera una
suma de comprobacin
El software legalmente relevante no puede iniciarse si el cdigo est
falsificado.
Pgina 30 de 115
Ejemplo de solucin aceptable: Ejemplo de solucin aceptable:

El cdigo del programa y los datos pueden protegerse mediante El cdigo de programa puede
sumas de comprobacin. El programa calcula su propia suma de protegerse almacenando el
comprobacin y la compara con un valor de referencia que est software legalmente relevante en
oculto en el cdigo ejecutable. Si la autocomprobacin falla, el una unidad conectable y
programa se bloquea. especializada que est
Cualquier algoritmo de firma debera tener una longitud de clave precintada. Dicha unidad puede
de al menos 2 bytes; sera suficiente una suma de comprobacin incluir, por ejemplo, una
segn el algoritmo CRC-16 con un vector inicial secreto (oculto en memoria de solo lectura y un
el cdigo ejecutable) (vanse tambin las extensiones L y T). microcontrolador.
La manipulacin no autorizada del software legalmente relevante
puede controlarse mediante el control de acceso o los atributos de
proteccin de privacidad del sistema operativo. El nivel de
administracin de estos sistemas se asegurar mediante el cierre del
software o medios equivalentes.

Se comprobar la comunicacin con el hardware de proteccin adicional.
Se comprobar que las modificaciones de programas o datos se detectan y que en dicho caso la
ejecucin del programa se detiene.

U7: Proteccin de parmetros
Los parmetros legalmente relevantes estarn protegidos frente a modificaciones no autorizadas.
Especificaciones:
1. Los parmetros especficos del modelo son idnticos para cada ejemplar del mismo y generalmente
forman parte del cdigo del programa, es decir, del software legalmente relevante. Por lo tanto, se les
aplica el requisito U6.
2. Parmetros especficos del dispositivo:
Los parmetros considerados protegidos pueden modificarse mediante el uso de un teclado integrado
o interruptores o a travs de interfaces, pero nicamente antes de que hayan protegido. Puesto que en
un ordenador universal los parmetros especficos del dispositivo podran manipularse mediante
herramientas simples, estos no se almacenarn en el almacenamiento estndar de un ordenador
universal. El almacenamiento de estos parmetros solo es aceptable en hardware adicional.
Los parmetros especficos del dispositivo considerados configurables pueden modificarse despus
de protegerse.
La documentacin deber describir todos los parmetros legalmente (adems de la documentacin
relevantes, sus rangos y valores nominales, dnde estn requerida para las clases de riesgo
almacenados, cmo pueden visualizarse, cmo y cundo han sido B y C):
protegidos, es decir, antes o despus de la verificacin. Se describirn las medidas
tomadas para la proteccin de los
parmetros.
Pgina 31 de 115

Se comprobar que es adecuado el mtodo de proteccin de los C):
parmetros especficos del modelo. Comprobaciones basadas en la
Se comprobar que los parmetros especficos del dispositivo no documentacin:
se guardan en almacenamiento estndar del ordenador universal, Se comprobar si las medidas
sino en hardware independiente que pueda precintarse e tomadas son adecuadas con
inhabilitarse para la escritura. respecto a la tecnologa actual
Comprobaciones funcionales: para garantizar un nivel de
Se comprobar el modo de ajuste (configuracin) y se proteccin alto.
comprobar si funciona la deshabilitacin tras la proteccin.
Se examinar la clasificacin y el estado de los parmetros
(protegido/configurable) en la pantalla del instrumento, si existe
una opcin de men para ello.
En el certificado de examen de modelo debera figurar una lista de
aquellos parmetros que son configurables y su ubicacin.
Los parmetros especficos del dispositivo se guardan en un almacenamiento conectable que est
protegido frente a su posible extraccin, o directamente en la unidad del sensor (mdulo de medida).
Se impide la escritura de los parmetros precintando en el estado deshabilitado el interruptor que
permite habilitar y deshabilitar la escritura. Se pueden combinar los registros de actividades con el
hardware de proteccin (vase P7).
Los parmetros configurables se guardan en un almacenamiento estndar del ordenador universal.

Se comprobar si son adecuadas las medidas tomadas para proteger los parmetros.

U8: Autenticidad del software y presentacin de los resultados.
Se utilizarn medios para garantizar la autenticidad del software legalmente relevante. Se garantizar la
autenticidad de los resultados presentados.
1. Se impedir la simulacin fraudulenta (spoof) mediante 1. Restriccin de 1BC, 2BC: Son
herramientas de software simples, del software legalmente necesarios medios, basados en
relevante aprobado. hardware adicional, para la
2. Los resultados presentados pueden considerarse autnticos si la proteccin contra el mal uso
presentacin procede del software legalmente relevante. intencionado, incluyendo la
simulacin.
3. Los valores de medida presentados incluirn toda la informacin necesaria para evitar cualquier
confusin con otra informacin (que no sea legalmente relevante).
4. Se garantizar por medios tcnicos que en el ordenador universal solo pueda ejecutar funciones
legalmente relevantes el software aprobado para tal fin (p. ej., la unidad del sensor o mdulo de medida
trabajar solo con el programa aprobado).
Pgina 32 de 115

La documentacin debera describir cmo se garantiza la (adems de la documentacin
autenticidad del software. requerida para las clases de riesgo
B y C):
Se describirn las medidas de
proteccin tomadas.
Es necesario determinar en el examen que las presentaciones C):
estn generadas por el software legalmente relevante as como la Comprobaciones basadas en la
manera de evitar las tcnicas de suplantacin mediante programas documentacin:
que no sean legalmente relevantes. Se comprobar si las medidas
Se comprobar que las tareas legalmente relevantes solo puedan tomadas son adecuadas con
realizarse mediante el software legalmente relevante aprobado. respecto a la tecnologa actual
Comprobaciones funcionales: para garantizar un nivel de
Se comprobar a travs de controles visuales si la presentacin de proteccin alto.
los resultados se distingue fcilmente de otra informacin que
tambin pueda presentarse.
Se comprobar, de acuerdo con la documentacin, si la
informacin presentada es completa.

Medios formales:
1. La parte (B) de identificacin del software (suma de comprobacin, nmero de versin o nmero del
certificado de examen de modelo, vase U2) indicada por el software se compara con el valor presente
en el certificado de examen de modelo.
Medios tcnicos:
1. El software legalmente relevante genera una ventana para la aplicacin de medida. Las medidas
tcnicas necesarias de la ventana son:
Los programas legalmente no relevantes no tendrn acceso alguno a los valores de medicin hasta
que estos hayan sido mostrados.
La ventana se refrescar peridicamente. El programa asociado comprobar que est siempre
visible.
El procesamiento de los valores de medida se detiene siempre que esta ventana se cierre o no est
completamente visible.
El manual de funcionamiento (y el certificado de examen de modelo) debera contener una copia de la
ventana como referencia.
2a. La unidad del sensor (mdulo de medida) cifra los valores de medicin con una clave conocida para
el software aprobado que funciona en el ordenador universal (p. ej., su nmero de versin). Solo el
software aprobado puede descifrar y utilizar los valores de medida, los programas no aprobados en el
ordenador universal no podrn hacerlo ya que desconocen la clave. Para el tratamiento de claves, vase
la extensin T.
2b. Antes de enviar los valores de medida, la unidad del sensor inicia una secuencia de protocolo
(handshake) con el software legalmente relevante en el ordenador universal basada en claves secretas.
La unidad del sensor enviar sus valores de medida, solo si el programa del ordenador universal se
comunica correctamente. Para el tratamiento de claves, vase la extensin T.
3. La clave utilizada en 2a/2b 3. La clave utilizada en 2a/2b es el cdigo hash del programa del
puede elegirse e introducirse ordenador universal. Cada vez que se modifique el software en el
en la unidad del sensor y en el PC, la nueva clave se introducir en la unidad del sensor y se
software del ordenador precintar.
universal sin destruir ningn
precinto.
Pgina 33 de 115

Se comprobar que el software legalmente relevante genera los resultados de medicin presentados.
Se comprobar si todas las medidas tomadas son adecuadas y correctas para garantizar la
autenticidad del software (p. ej., que las tareas legalmente relevantes solo pueden realizarse
mediante el software legalmente relevante aprobado).
U9: Influencia de otro software
El software legalmente relevante se disear de tal manera que ningn otro software influya en l de
modo inadmisible.
Especificaciones:
Este requisito implica la separacin del software entre el software legalmente relevante y el que no lo
es. Se cumplir la extensin S. Este es el caso estndar para ordenadores universales.
Vase la extensin S.
Gua de validacin:
Vase la extensin S.
Vase la extensin S.
Pgina 34 de 115
6 Extensin L: Almacenamiento a largo plazo de los datos de medida
Es una extensin a los requisitos especficos del software integrado en instrumentos de medida
desarrollados especficamente (requisitos para tipo P) y del software para instrumentos de medida que
utilizan un ordenador universal (requisitos para tipo U). Describe los requisitos para el
almacenamiento de los datos de medida desde el momento en que se haya completado fsicamente una
medicin hasta que han finalizado todos los procesos que deba realizar el software legalmente
relevante. Esto tambin se aplica al almacenamiento posterior de los datos.
La serie de requisitos de esta extensin solo se aplica si incluye almacenamiento a largo plazo de los
datos de medida. Se refiere solo a aquellos datos de medida legalmente relevantes. En la siguiente
tabla se presentan tres configuraciones tcnicas distintas para el almacenamiento a largo plazo. En el
caso de un dispositivo de medida desarrollado especficamente es tpica la opcin de un
almacenamiento integrado: el almacenamiento forma parte del hardware y del software
metrolgicamente necesarios. En el caso de instrumentos que usan un ordenador universal, es tpica
otra opcin: el uso de recursos ya existentes, p. ej., discos duros. La tercera opcin es la del
almacenamiento extrable: el almacenamiento puede extraerse del dispositivo, que puede ser o un
dispositivo desarrollado especficamente o un ordenador universal, y puede llevarse a cualquier parte.
Cuando se recuperan datos de un almacenamiento extrable para fines legales, p. ej., visualizacin,
impresin de recibos, etc., el dispositivo de recuperacin estar sometido a control legal.
Almacenamiento integrado
Instrumento simple, desarrollado especficamente, sin herramientas externas o medios que permitan
editar o cambiar datos, almacenamiento integrado de datos o parmetros de medida, p. ej., memoria
RAM, memoria flash o disco duro.
Almacenamiento para ordenador universal
Ordenador universal, interfaz grfica de usuario, sistema operativo multitarea, las tareas sometidas a
control legal y las que no lo estn coexisten paralelamente, se puede extraer el almacenamiento del
dispositivo o se pueden copiar los contenidos ya sea dentro o fuera del ordenador.
Almacenamiento extrable o remoto (externo)

Instrumento bsico (instrumento desarrollado especficamente o que utiliza un ordenador universal), el
almacenamiento se puede extraer del instrumento. Estos pueden ser, por ejemplo, disquetes, tarjetas flash
o bases de datos remotas conectadas a travs de la red.
Tabla 6-1: Descripcin tcnica de almacenamientos a largo plazo
Pgina 35 de 115
6.2 Requisitos especficos del software para almacenamiento a largo plazo
Los requisitos que se muestran en esta seccin se deben aplicar junto con una serie de requisitos, ya
sea para los instrumentos bsicos desarrollados especficamente o para aquellos que utilizan un
ordenador universal.

L1 Completitud de los datos de medida almacenados
Los datos de medida almacenados deben contener toda la informacin relevante que sea necesaria para
reproducir mediciones anteriores.
Especificaciones:
Los datos de medida almacenados pueden ser necesarios como referencia en una fecha posterior; p. ej.,
para comprobar facturas. Todos los datos necesarios, tanto por razones legales como por razones
metrolgicas, se almacenarn junto con los valores de medida.
Descripcin de todos los campos de los conjuntos de datos.
Gua de validacin:
Se comprobar si se incluye en el conjunto de datos toda la informacin necesaria para fines legal y
metrolgicamente relevantes .
El conjunto de datos legal y metrolgicamente completo consta de los siguientes campos:
valores de medida con la resolucin correcta;
unidades de medida legalmente correctas;
precio unitario o precio que hay que pagar (si es aplicable);
momento y lugar de la medicin (si es aplicable);
identificacin del instrumento (si es aplicable) (almacenamiento externo).
Los datos se almacenan con la misma resolucin, valores, unidades, etc., que indica o imprime el
instrumento.

Documentacin requerida (adems de la documentacin requerida para las clases de riesgo B, C y D):
El cdigo fuente que genera los conjuntos de datos para su almacenamiento.
Se comprobar que los conjuntos de datos se crean correctamente.
Pgina 36 de 115

L2 Proteccin frente a cambios accidentales o no intencionados
Los datos almacenados estarn protegidos frente a cambios accidentales o no intencionados.
Especificaciones:
1. Los cambios de datos accidentales pueden deberse a efectos fsicos.
2. Los cambios no intencionados pueden deberse al usuario del dispositivo. Las tareas de mantenimiento
de los datos pueden requerir que se elimine de cuando en cuando la informacin relativa a facturas
pagadas o vencidas. Deberan utilizarse medios automticos o semiautomticos para garantizar que
solamente se eliminen los datos especificados y se evite la eliminacin accidental de datos "vivos".
Esto es particularmente importante en sistemas conectados en red y en el caso de almacenamiento
remoto o extrable, donde los usuarios podran no darse cuenta de la importancia de los datos.
3. El receptor calcular una suma de comprobacin y la comparar con el valor de referencia asociado. Si
los valores coinciden, el conjunto de datos es vlido y se puede utilizar; si no se deben eliminar o
marcar como invlidos.
Documentacin requerida: Documentacin requerida (adems de
Descripcin de las medidas de proteccin (p. ej., el algoritmo la documentacin requerida para las
de la suma de comprobacin, incluyendo la longitud del clases de riesgo B y C):
polinomio generador). La documentacin describir las
medidas tomadas para validar la
efectividad de los medios de proteccin.
Gua de validacin: Gua de validacin (adems de la gua
Comprobaciones basadas en la documentacin: para las clases de riesgo B, y C):
Se comprobar que se genere una suma de comprobacin Comprobaciones basadas en la
de los datos. documentacin:
Se comprobar que el software legalmente relevante que lee Se comprobar que las medidas tomadas
los datos y calcula la suma de comprobacin, compara sean adecuadas para un nivel de
verdaderamente el valor calculado con el de referencia. proteccin alto.
Se comprobar que los datos no se pueden sobrescribir
antes de que se acabe el periodo de almacenamiento
previsto y documentado por el fabricante.
Se comprobar que aparece un mensaje de advertencia en
caso de que el usuario est a punto de eliminar archivos que
contengan datos de medida.
Si existe la posibilidad de eliminar los datos de medida, se
verificar mediante comprobaciones aleatorias que aparece un
mensaje de advertencia antes de realizar esta accin.
Para detectar cambios en los datos debido a efectos fsicos, se calcula una suma de comprobacin con
el algoritmo CRC-16 de todo el conjunto de datos y se inserta en el mismo conjunto para su
almacenamiento.
Nota: El algoritmo no es secreto y, al contrario que en el requisito L3, tampoco lo son el vector inicial del
registro CRC ni el polinomio generador, es decir, el divisor en el algoritmo. El vector inicial y el polinomio
generador son conocidos tanto por el programa que crea como por el que verifica las sumas de comprobacin.
Los datos de medida y los archivos de facturas pueden protegerse asociando un registro automtico
con la fecha y hora de su creacin o con una bandera o etiqueta que indica si las facturas estn pagadas
o no. Un programa de utilidad podra mover o eliminar los archivos solo si las facturas estn cobradas
o vencidas.
Los datos de medida no se eliminan sin una autorizacin previa; p. ej., un cuadro de dilogo o una
ventana que pide confirmacin para la eliminacin.
Pgina 37 de 115

El cdigo fuente que realiza la proteccin de los datos almacenados.
Se comprobar que las medidas tomadas para proteger los datos almacenados son adecuadas y se han
implementado correctamente.

L3 Integridad de los datos
Los datos de medida almacenados deben estar protegidos frente a cambios intencionados.
1. Este requisito se aplica a todos los tipos de 1. Este requisito se aplica a todos los tipos de
almacenamiento, excepto a los integrados. almacenamiento, excepto a los integrados.
2. La proteccin debe ser efectiva contra cambios 2. La proteccin debe ser efectiva contra cambios
intencionados llevados a cabo mediante intencionados realizados mediante herramientas
herramientas comunes de software. sofisticadas de software.
3. Se entiende por herramientas comunes de 3. Las herramientas sofisticadas de software son,
software, aquellas que estn fcilmente p. ej., depuradores, recompiladores, herramientas
disponibles y su uso es sencillo; p. ej., los de desarrollo de software, etc.
paquetes de ofimtica. 4. El nivel de proteccin deber ser equivalente al
que se requiere para el pago electrnico.
5. La proteccin se aplica mediante una firma
electrnica con un algoritmo que garantiza que
no existen firmas idnticas para conjuntos de
datos diferentes.
Nota: Incluso si el algoritmo y la clave cumplen el nivel
alto de proteccin, una solucin tcnica con un PC
estndar no alcanzara este nivel de proteccin si no hay
medios de proteccin para los programas que firman o
verifican los conjuntos de datos (vase la gua bsica U
para ordenadores universales en el comentario del
requisito U6 - D).
El mtodo para realizar la proteccin deber estar documentacin requerida para las clases de riesgo
documentado. B y C):
Se describirn las medidas de proteccin tomadas.
Pgina 38 de 115
Gua de validacin: Gua de validacin (adems de la gua para las

Comprobaciones basadas en la documentacin: clases de riesgo B y C):
Si se usa una suma de comprobacin o una Comprobaciones basadas en la documentacin:
firma: Se comprobar si las medidas tomadas son
Se comprobar si esta se genera sobre todo adecuadas con respecto a la tecnologa actual para
el conjunto de datos. garantizar un nivel de proteccin alto.
Se comprobar que el software legalmente
relevante, que lee los datos y calcula la
suma de comprobacin o descifra la firma,
verdaderamente compara el valor calculado
con el de referencia.
Se comprobar que los datos secretos (p. ej., el
valor inicial de la clave, si se utiliza) se
mantienen secretos contra el espionaje con
herramientas simples.
Se comprobar que el programa de recuperacin
rechaza un conjunto de datos falsificados.
Justo antes de reutilizar los datos, se recalcula el En lugar de CRC, se calcula una firma. Un
valor de la suma de comprobacin y se compara algoritmo de firma adecuado podra ser uno de los
con el valor de referencia almacenado. Si los algoritmos hash (p. ej., SHA-1 o RipeMD160),
valores coinciden, el conjunto de datos es vlido y combinado con un algoritmo de cifrado como RSA
se puede utilizar; si no, debe eliminarse o marcarse o de curvas elpticas. La longitud mnima de la
como invlido. clave es de 768 bits (RSA) o 128-160 bits (curvas
Una solucin aceptable es el algoritmo CRC-16. elpticas).
Nota: El algoritmo no es secreto pero, al contrario que
en el requisito L2, debe serlo el vector inicial del
registro CRC o el polinomio generador (es decir, el
divisor en el algoritmo). El vector inicial y el polinomio
generador solo los conocen los programas que generan
y verifican las sumas de comprobacin. Deben tratarse
como claves (vase L5).

El cdigo fuente que lleva a cabo la integridad de los datos almacenados.
Se comprobar que las medidas tomadas para garantizar la integridad de los datos almacenados son
adecuadas y estn correctamente implementadas.
Pgina 39 de 115

L4 Autenticidad de los datos de medida almacenados
Deben poder rastrearse fielmente los datos de medida almacenados hasta la medicin que los gener.
Especificaciones:
1. La autenticidad de los datos de medida puede ser necesaria como referencia en una fecha posterior; p.
ej., para comprobar facturas.
2. La autenticidad requiere la correcta asignacin (vinculacin) de los datos de medida a la medicin que
los gener.
3. La autenticidad presupone la identificacin de los conjuntos de datos.
4. Para garantizar la autenticidad, no se requiere necesariamente cifrar los datos.
Documentacin requerida: Documentacin requerida (adems
Descripcin del mtodo utilizado para garantizar la de la documentacin requerida para
autenticidad. las clases de riesgo B y C):
Se describirn las medidas de
proteccin tomadas.
Comprobaciones basadas en la documentacin: gua para las clases de riesgo B y C):
Se comprobar que existe un enlace correcto entre cada valor Comprobaciones basadas en la
de medida y la medicin correspondiente. documentacin:
Si se usa una suma de comprobacin o una firma, se Se comprobar si las medidas tomadas
comprobar si esta se genera sobre el todo el conjunto de son adecuadas con respecto a la
datos. tecnologa actual para garantizar un
Se comprobar que los datos secretos (p. ej., el valor inicial nivel de proteccin alto.
de la clave, si se utiliza) se mantienen secretos contra el
espionaje con herramientas simples.
Se comprobar que tanto los datos almacenados como los datos
que aparecen en el recibo o factura son idnticos.
Un conjunto de datos almacenados contiene los siguientes campos de datos (adems de los campos
definidos en L3):
Un nico nmero de identificacin (actual). El nmero de identificacin tambin se copia en la nota
generada por el instrumento (tique).
La fecha/hora a la que se ha realizado la medida (registro de fecha y hora). El registro de fecha y hora
tambin se copia en el tique.
Una identificacin del instrumento de medida que ha generado el valor.
La firma que se usa para garantizar la integridad de los datos puede utilizarse simultneamente para
garantizar la autenticidad. La firma cubre todos los campos del conjunto de datos. Consltense los
requisitos L2, L3.
En el tique se puede reflejar que los valores de medida pueden compararse con los datos de referencia
que estn almacenados en un medio sometido a control legal. Esta correspondencia se demuestra
comparando el nmero de identificacin o el registro de fecha y hora impreso en el tique con aquella
del conjunto de datos almacenados.
El cdigo fuente que genera los conjuntos de datos para almacenarlos y realiza la autenticacin.
Se comprobar que los conjuntos de datos se crean correctamente y se autentican de manera fidedigna.
Pgina 40 de 115

L5: Confidencialidad de las claves
Las claves y los datos que las acompaan deben tratarse como datos legalmente relevantes y mantenerse
ocultos y protegidos frente a posibles riesgos originados por herramientas software.
1. Este requisito solo se aplica si se utiliza una clave secreta. 1. Este requisito se aplica al
2. Este requisito se aplica al almacenamiento de datos de almacenamiento en ordenadores
medida que se lleva a cabo en un dispositivo externo al universales y en dispositivos externos.
instrumento de medida o mediante ordenadores 2. La proteccin se debe aplicar frente a
universales. cambios intencionados realizados
3. La proteccin se debe aplicar frente a cambios mediante herramientas sofisticadas de
intencionados realizados mediante herramientas comunes software.
de software. 3. Se deben utilizar mtodos adecuados
4. Si el acceso a las claves secretas est restringido, p. ej., equivalentes a los del pago electrnico.
mediante el precintado de la carcasa de un dispositivo El usuario debe ser capaz de verificar la
desarrollado especficamente, no se necesitar ningn autenticidad de la clave pblica.
medio de proteccin software adicional.
Descripcin de la gestin de las claves y de los medios para documentacin requerida para las clases
mantener las claves y la informacin asociada en secreto. de riesgo B y C):
Se describirn las medidas de proteccin
tomadas.
Comprobaciones basadas en la documentacin: para las clases de riesgo B y C):
Se comprobar que la informacin secreta no pueda verse Comprobaciones basadas en la
comprometida. documentacin:
Se comprobar si las medidas tomadas
son adecuadas con respecto a la
tecnologa actual para garantizar un nivel
de proteccin alto.
La clave secreta y los datos que la acompaan estn La clave secreta se almacena en una parte
almacenados en formato binario en el cdigo ejecutable del del hardware que puede precintarse
software legalmente relevante. Por tanto no es obvia la fsicamente. El software no ofrece
direccin en la que se almacenan estos datos. El software ninguna opcin para ver o editar estos
del sistema no ofrece ninguna opcin para editar o ver estos datos.
datos. Si el algoritmo CRC se utiliza como firma, el vector Nota: Una solucin tcnica con un PC
inicial o polinomio generador desempea la funcin de estndar podra no ser suficiente para
clave. garantizar el alto nivel de proteccin si no
existen medios hardware de proteccin
adecuados para la clave y otros datos secretos
(vase la gua bsica para ordenador universal
U6).
1) Infraestructura PKI: la clave pblica del
almacenamiento sometido a control legal
ha sido certificada por una Autoridad
certificadora.
2) Confianza directa: no es necesario implicar
a una Autoridad certificadora si, por un
acuerdo anterior, ambas partes son capaces
de leer la clave pblica del instrumento de
medida directamente en un dispositivo
sometido a control legal que muestra el
conjunto de datos relevantes.
Pgina 41 de 115

El cdigo fuente que realiza la gestin de las claves.
Se comprobar que las medidas tomadas para la gestin de claves son adecuadas.

L6: Recuperacin de los datos almacenados
El software utilizado para verificar los conjuntos de datos de medida almacenados mostrar o imprimir
los mismos, comprobar si han sido modificados y avisar si ha encontrado cambios. Los datos
detectados como corruptos no deben utilizarse.
Especificaciones:
1. Los datos de medida almacenados podran ser necesarios como referencia en una fecha posterior; p.
ej., si se cuestiona alguna transaccin. Si existe alguna duda en la correccin de un tique o recibo,
deber ser posible identificar sin ambigedad los datos de medida almacenados de la medicin puesta
en duda (vase tambin L1, L3, L4 y L5).
2. El nmero de identificacin (vase L1) debe estar impreso en el tique o recibo del cliente, junto con
una explicacin y una referencia al almacenamiento sometido a control legal.
3. La verificacin consiste en comprobar la integridad, autenticidad y correcta asignacin de los datos de
medida almacenados.
4. El software de verificacin utilizado para mostrar o imprimir los datos almacenados estar sometido a
control legal.
5. Para los requisitos especficos de un instrumento, consulte la extensin I.
Descripcin de las funciones del programa de documentacin requerida para las clases
recuperacin. de riesgo B y C):
Descripcin de la deteccin de datos corruptos. Se describirn las medidas de proteccin
Manual de funcionamiento de este programa. tomadas.
Se comprobar que el software de recuperacin Comprobaciones basadas en la
verdaderamente compara el valor calculado con los documentacin:
valores de referencia. Se comprobar si las medidas tomadas
Se comprobar que el software de recuperacin forme son adecuadas con respecto a la
parte del software legalmente relevante. tecnologa actual para garantizar un nivel
Comprobaciones funcionales: de proteccin alto.
Se comprobar si el programa detecta conjuntos de datos
corruptos.
Se realizarn comprobaciones aleatorias para verificar
que la recuperacin proporciona toda la informacin
necesaria.
El programa de verificacin lee el conjunto de datos almacenado, recalcula la firma sobre todos los
campos de datos y la compara con el valor de referencia almacenado. Si ambos valores coinciden, el
conjunto de datos es correcto; de lo contrario, los datos no se utilizan y el programa los elimina o marca
como invlidos.
Pgina 42 de 115

El cdigo fuente del programa de recuperacin.
Se comprobar si las medidas tomadas para recuperacin, verificacin de firmas, etc. son adecuadas y
estn correctamente implementadas.

L7: Almacenamiento automtico.
Los datos de medida debern almacenarse automticamente cuando concluya la medicin.
Especificaciones:
1. Este requisito se aplica a todos los tipos de almacenamiento.
2. Este requisito significa que la funcin de almacenamiento no depender de la decisin del operador.
Sin embargo, algunos tipos de instrumentos, p. ej. instrumentos de pesaje, solicitan al operador la
aceptacin o no del resultado. En otras palabras, podran existir algunas medidas intermedias que no se
almacenen (por ejemplo durante la carga o antes de que la cantidad de productos solicitados se
encuentre en el receptor de carga). No obstante, incluso en este caso, el resultado se almacenar
automticamente cuando el operador lo acepte.
3. En caso de que se realice un almacenamiento completo, vase el requisito L8.
Confirmacin de que el almacenamiento se realiza de forma automtica. Descripcin de la interfaz
grfica de usuario.
Gua de validacin:
Se examinar mediante comprobaciones aleatorias que los valores de medida se almacenan
automticamente despus de terminar o aceptar la medicin. Se comprobar que no existen botones ni
opciones de men que interrumpan o deshabiliten el almacenamiento automtico.
No existen opciones de men ni botones en la interfaz grfica de usuario que permitan iniciar
manualmente el almacenamiento de los resultados de medida. Los valores de medida se combinan en un
conjunto de datos junto con informacin adicional, tal como un registro de fecha y hora o una firma y se
almacenan inmediatamente despus de realizar o aceptar la medicin, respectivamente.
Se comprobar si las medidas tomadas para el almacenamiento automtico son adecuadas y se
implementan correctamente.
Pgina 43 de 115

L8: Capacidad de almacenamiento y continuidad
El almacenamiento a largo plazo debe tener la capacidad suficiente para el uso previsto.
Especificaciones:
1. Cuando un medio de almacenamiento est lleno o se extrae/desconecta del instrumento, el operador
recibir una advertencia. No ser necesaria esta advertencia si se asegura en la construccin que solo
los datos fuera de fecha se pueden sobrescribir. Para otras acciones necesarias, consulte los requisitos
especficos del instrumento de medida (extensin I).
2. La regulacin relativa al perodo mnimo de almacenamiento de los datos de medida est fuera del
alcance de este requisito y es competencia de las regulaciones nacionales. Es responsabilidad del
propietario tener un instrumento con suficiente capacidad de almacenamiento para cumplir los
requisitos aplicables a su actividad. El organismo notificado para el examen CE de modelo solo
comprobar que los datos se almacenan y se recuperan correctamente y si se impiden nuevas
transacciones cuando el almacenamiento est lleno.
3. La exigencia de ciertas inscripciones en el dispositivo, tales como las relativas a la capacidad de
almacenamiento o a otra informacin incluida que permite calcular la capacidad, tambin est fuera del
alcance de este requisito. No obstante, el fabricante facilitar la informacin sobre la capacidad.
Descripcin de la gestin de casos excepcionales cuando se almacenan valores de medida.
Gua de validacin:
Se comprobar que el fabricante proporciona la capacidad de almacenamiento o una frmula para calcularla.
Se comprobar que no puedan sobrescribirse los datos antes de que finalice el periodo de tiempo para
el almacenamiento de estos, previsto y documentado por el fabricante.
Se comprobar que aparece un mensaje de advertencia en caso de que el usuario est a punto de
eliminar archivos que contengan datos de medida (si existe posibilidad de eliminarlos).
Se comprobar que aparece un mensaje de advertencia si el almacenamiento est lleno o se ha extrado.
Para mediciones que se pueden interrumpir, que de manera rpida y sencilla se pueden detener (p. ej.,
pesaje, medicin de combustible, etc.), la medicin se puede completar incluso si el almacenamiento
deja de estar disponible. El instrumento o dispositivo de medida debera tener un buffer (memoria
intermedia) que tenga la capacidad suficiente para almacenar la transaccin en curso. Despus de esto,
no se podr comenzar ninguna otra transaccin y los datos almacenados en el buffer se guardarn para
que puedan transmitirse ms adelante a un almacenamiento nuevo.
Las mediciones que no se pueden interrumpir (p. ej., las mediciones de energa, volumen, etc.) no
necesitarn un buffer especial intermedio porque estas mediciones siempre son acumulativas. El
registro acumulativo podr leerse y transferirse al medio de almacenamiento ms tarde, cuando este
vuelva a estar disponible.
Los datos de medida podrn sobrescribirse automticamente mediante un programa de utilidad que
compruebe si el plazo establecido de dichos datos est vencido (consulte los reglamentos nacionales
relativos a los periodos de tiempo establecido legalmente) o si se ha pagado la factura. El programa de
utilidad mostrar un mensaje de confirmacin al usuario para eliminar los datos que se borrarn en
orden desde el ms antiguo.

El cdigo fuente que realiza el almacenamiento de datos.
Se comprobar si las medidas tomadas para el almacenamiento son adecuadas y se implementan
correctamente.
Pgina 44 de 115
7 Extensin T: Transmisin de datos de medida a travs de redes de comunicacin
Esta es una extensin de los requisitos del software de las guas bsicas P y U. Solo debe utilizarse si
los datos de medida se transmiten a travs de redes de comunicacin a un dispositivo remoto donde se
terminen de procesar y/o se utilicen para fines regulados legalmente. Esta extensin no se aplica a
menos que haya algn procesamiento posterior de datos legalmente relevantes. Si el software se
descarga en un dispositivo sometido a control legal, se aplican los requisitos de la extensin D.
La serie de requisitos de esta extensin se aplica nicamente si el dispositivo en cuestin est

conectado a una red y transmite o recibe datos de medida legalmente relevantes. En la siguiente tabla,
se identifican tres configuraciones de red. La ms simple es un conjunto de dispositivos que estn
todos sometidos a control legal. Los participantes se fijan en la verificacin legal. Una variante de esto
(red cerrada, parcialmente sometida a control legal) es una red con participantes que no estn
sometidos a control legal pero todos son conocidos y no cambian durante la operacin. Una red abierta
no tiene limitaciones en cuanto a la identidad, funcionalidad, presencia y ubicacin de los
participantes.
Descripcin de las configuraciones

Red cerrada, completamente sometida a control legal
Solo hay un nmero fijo de participantes conectados, con una identidad, funcionalidad y ubicacin claras.
Todos los dispositivos estn sometidos a control legal. No existen dispositivos en la red que no estn
sometidos a control legal.
Red cerrada, parcialmente sometida a control legal
Hay un nmero fijo de participantes con una identidad y ubicacin claras conectados a la red. No todos
los dispositivos estn sometidos a control legal y, por tanto, se desconoce su funcionalidad.
Red abierta
A la red se pueden conectar participantes arbitrarios (dispositivos con funciones arbitrarias). La identidad
y funcionalidad de un dispositivo participante y su ubicacin pueden ser desconocidas para otros
participantes.
Cualquier red que contenga dispositivos sometidos a control legal con receptor de infrarrojos o interfaces
de comunicacin entre redes inalmbricas se considerar red abierta.
Tabla 7-1: Descripcin tcnica a travs de redes de comunicacin.
Pgina 45 de 115
7.2 Requisitos especficos del software para transmisin de datos

T1: Completitud de los datos transmitidos
Los datos transmitidos debern contener toda la informacin relevante necesaria para presentar o
procesar posteriormente los resultados de medida en la unidad receptora.
Especificaciones:
La parte metrolgica de un conjunto de datos transmitidos se compone de uno o varios valores de medida
con la resolucin correcta, la unidad de medida correcta legalmente, y segn la aplicacin, el precio
unitario o el precio a pagar y el lugar de la medicin.
Se documentarn todos los campos del conjunto de datos.
Gua de validacin:
Se comprobar si se incluye en el conjunto de datos toda la informacin para el procesamiento posterior
de los valores de medida en la unidad receptora .
El conjunto de datos contiene los siguientes campos:
valores de medida con la resolucin correcta;
unidades de medida legalmente correctas;
precio unitario o precio que hay que pagar (si es aplicable);
hora y fecha de la medicin (si es aplicable);
identificacin del instrumento (si es aplicable) (transmisin de datos);
El lugar de la medicin (si es aplicable).
El cdigo fuente que genera los conjuntos de datos para su transmisin.
Se comprobar que los conjuntos de datos se crean correctamente.

T2: Proteccin frente a los cambios accidentales o no intencionados
Los datos transmitidos estarn protegidos frente a cambios accidentales o no intencionados.
Especificaciones:
1. Los cambios de datos accidentales pueden deberse a efectos fsicos.
2. Los cambios no intencionados pueden deberse al usuario del dispositivo.
3. Se proporcionarn medios para detectar errores de transmisin.
Descripcin del algoritmo de la suma de comprobacin, si documentacin requerida para las clases
se usa, incluida la longitud del polinomio generador. de riesgo B y C):
Descripcin de un mtodo alternativo en caso de que se La documentacin describir las medidas
utilice. tomadas para validar la efectividad de los
medios de proteccin.
Se comprobar que se genere una suma de comprobacin Comprobaciones basadas en la
de los datos. documentacin:
Se comprobar que el software legalmente relevante que recibe Se comprobar que las medidas tomadas
los datos recalcula la suma de comprobacin y la compara con sean adecuadas para un nivel de
el valor de referencia incluido en el conjunto de datos. proteccin alto.
Pgina 46 de 115

1) Para detectar cambios en los datos, se calcula una suma de comprobacin con el algoritmo CRC-16 de
todos los bytes del conjunto de datos y se inserta en dicho conjunto para su transmisin. Justo antes de
reutilizar los datos, el receptor recalcula el valor de la suma de comprobacin y lo compara con el valor
de referencia adjunto. Si los valores coinciden, el conjunto de datos es vlido y se puede utilizar; si no,
habr que eliminarlo o marcarlo como invlido.
Nota: El algoritmo no es secreto y, al contrario que en el requisito T3, tampoco lo son el vector inicial del
registro CRC ni el polinomio generador, es decir, el divisor en el algoritmo. El vector inicial y el polinomio
generador son conocidos tanto por el programa que crea como por el que verifica las sumas de comprobacin.
2) Usar los medios proporcionados por los protocolos de transmisin, p. ej., TCP/IP o IFSF.

El cdigo fuente que realiza la proteccin de los datos transmitidos.
Se comprobar que las medidas tomadas para proteger los datos transmitidos son adecuadas.

T3: Integridad de los datos
Los datos transmitidos legalmente relevantes deben estar protegidos frente a cambios intencionados
realizados con herramientas software.
1. Este requisito solo se aplica a redes abiertas o 1. Este requisito se aplica a redes abiertas y
parcialmente sometidas a control legal, y no a redes a redes cerradas parcialmente sometidas a
cerradas. control legal.
2. La proteccin debe ser efectiva contra cambios 2. La proteccin se aplica mediante una
intencionados llevados a cabo mediante herramientas firma electrnica con un algoritmo que
comunes de software. garantiza que no existen firmas idnticas
3. Se entiende por herramientas comunes de software para conjuntos de datos diferentes
aquellas que estn fcilmente disponibles y su uso es 3. La proteccin debe ser efectiva contra
sencillo; p. ej., los paquetes de ofimtica. cambios intencionados realizados
mediante herramientas sofisticadas de
software.
4. Las herramientas sofisticadas de
software son, p. ej., depuradores,
recompiladores, herramientas de
desarrollo de software, etc.
5. El nivel de proteccin deber ser
equivalente al que se requiere para el
pago electrnico.
Nota: Incluso si el algoritmo y la clave cumplen
el nivel alto de proteccin, una solucin tcnica
con un PC estndar no alcanzara este nivel de
proteccin si no hay medios de proteccin para
los programas que firman o verifican los
conjuntos de datos (vase la gua bsica U para
ordenadores universales en comentario del
requisito U6-D).
Descripcin del mtodo de proteccin documentacin requerida para las clases de
riesgo B y C):
Se describirn las medidas de proteccin
tomadas.
Pgina 47 de 115

Si se usa una suma de comprobacin o una firma: Comprobaciones basadas en la
Se comprobar si esta se genera sobre todo el documentacin:
conjunto de datos. Se comprobar si las medidas tomadas son
Se comprobar que el software legalmente relevante, adecuadas respecto a la tecnologa actual
que recibe los datos y recalcula la suma de para garantizar un nivel de proteccin alto.
comprobacin o descifra la firma, verdaderamente
compara el valor calculado con el de referencia.
Se comprobar que los datos secretos (p. ej., el valor
inicial de la clave, si se utiliza) se mantienen ocultos
ante el espionaje con herramientas simples.
Se genera una suma de comprobacin de los datos a En lugar del CRC, se calcula una firma.
transmitir. Justo antes de reutilizar los datos, se recalcula Un algoritmo de firma adecuado podra
el valor de la suma de comprobacin y se compara con el ser uno de los algoritmos hash (p. ej.,
valor de referencia incluido en el conjunto de datos SHA-1 o RipeMD160), combinado con
recibido. Si los valores coinciden, el conjunto de datos es un algoritmo de cifrado como el RSA o el
vlido y se puede utilizar; si no, debe eliminarse o de curvas elpticas. La longitud mnima
marcarse como invlido. de la clave es de 768 bits (RSA) o 128-
Una solucin aceptable es el algoritmo CRC-16. 160 bits (curvas elpticas).
Nota: El algoritmo no es secreto pero, al contrario que en el Algunos protocolos de transmisin
requisito T2, s debe serlo el vector inicial del registro CRC o el proporcionan proteccin (p. ej., HTTPS).
polinomio generador (es decir, el divisor en el algoritmo). El
vector inicial y el polinomio generador solo los conocen los
programas que generan y verifican las sumas de comprobacin.
Deben tratarse como claves (vase T5).

El cdigo fuente que lleva a cabo la integridad de los datos transmitidos.
Se comprobar que las medidas tomadas para garantizar la integridad de los datos transmitidos son
adecuadas.
Pgina 48 de 115

T4: Autenticidad de los datos transmitidos
El programa que reciba los datos relevantes transmitidos, deber poder verificar la autenticidad y la
asignacin de los valores de medida a una medicin determinada.
Especificaciones:
1a. En una red de participantes desconocidos, es necesario identificar sin ambigedad el origen de los
datos de medida transmitidos. (La autenticidad se basa en el nmero de identificacin del conjunto de
datos y la direccin de la red).
1b. En una red cerrada, todos los participantes son conocidos. No se necesitan medios de TI adicionales,
pero la topologa de la red (el nmero de participantes) estar fijado mediante precintado.
2. Es posible que haya retrasos imprevistos durante la transmisin. Para asignar correctamente un valor
de medida recibido a una medicin determinada, se debe registrar el momento de la medicin.
3. Para garantizar la autenticidad, no se requiere necesariamente el cifrado de los datos de medida.
Documentacin requerida: Documentacin requerida (adems de
Red de participantes desconocidos: Descripcin de los la documentacin requerida para las
medios de TI para asignar correctamente el valor de medida a clases de riesgo B y C):
la medicin. Se describirn las medidas de proteccin
Red cerrada: Descripcin de los medios hardware que tomadas.
preservan el nmero de participantes de la red. Descripcin de
la identificacin inicial de los participantes.
Se comprobar que existe un vnculo correcto entre cada Comprobaciones basadas en la
valor de medida y la medicin correspondiente. documentacin:
Se comprobar que los datos estn firmados digitalmente Se comprobar si las medidas tomadas
para garantizar su correcta identificacin y autenticacin. son adecuadas con respecto a la
tecnologa actual para garantizar un
nivel de proteccin alto.
Cada conjunto de datos tiene un nico nmero de identificacin (actual), que puede contener el
momento en que se ha realizado la medicin (registro de fecha y hora).
Cada conjunto de datos contiene informacin acerca del origen de los datos de medida, es decir, el
nmero de serie o la identidad del instrumento de medida que gener el valor.
En una red de participantes desconocidos, se garantiza la autenticidad si el conjunto de datos contiene
una firma que no sea ambigua. La firma cubre todos estos campos del conjunto de datos.
El receptor del conjunto de datos comprueba la fiabilidad de todos los datos.

El cdigo fuente del dispositivo de envo y recepcin.
Se comprobar que las medidas tomadas para garantizar la autenticidad de los datos transmitidos son
adecuadas.
Pgina 49 de 115

T5: Confidencialidad de las claves
Las claves y los datos que las acompaan deben tratarse como datos legalmente relevantes y mantenerse
ocultos y protegidos frente a posibles riesgos originados por herramientas software.
1. Este requisito solo se aplica si hay una clave secreta 1. Este requisito solo se aplica si hay una clave
en el sistema (normalmente no en redes cerradas). secreta en el sistema (normalmente no en
2. La proteccin se debe aplicar frente a cambios redes cerradas).
intencionados realizados mediante herramientas 2. La proteccin se debe aplicar frente a
comunes de software. cambios intencionados realizados mediante
3. Si el acceso a las claves secretas est restringido, p. herramientas sofisticadas de software.
ej., mediante el precintado de la carcasa de un 3. Los valores de medida recibidos se leen del
dispositivo desarrollado especficamente, no se conjunto de datos y se comprueba su firma
necesitar ningn medio de proteccin software mediante la clave pblica del instrumento de
adicional. medida emisor (o del dispositivo que gener
el conjunto de datos relevante). Con esta
comprobacin el receptor puede probar que
el valor y la firma se corresponden.
4. Se deben utilizar mtodos adecuados
equivalentes a los del pago electrnico..
Descripcin de la gestin de las claves y de los medios documentacin requerida para las clases de
para mantener las claves y la informacin asociada en riesgo B y C):
secreto. Se describirn las medidas de proteccin
tomadas.
Gua de validacin: Gua de validacin (adems de la gua para las
Comprobaciones basadas en la documentacin: clases de riesgo B y C):
Se comprobar que la informacin secreta no pueda Comprobaciones basadas en la documentacin:
verse comprometida. Se comprobar si las medidas tomadas son
adecuadas respecto a la tecnologa actual para
garantizar un nivel de proteccin alto.
La clave secreta y los datos que la acompaan estn La clave secreta se almacena en una parte del
almacenados en formato binario en el cdigo hardware que pueda precintarse fsicamente. El
ejecutable del software legalmente relevante. Por software no ofrece ninguna opcin para ver o
tanto, no es obvia la direccin en la que se almacenan editar estos datos.
estos datos. El software del sistema no ofrece ninguna Nota: Una solucin tcnica con un PC estndar
opcin para editar o ver estos datos. Si el algoritmo podra no ser suficiente para garantizar el alto nivel
CRC se utiliza como firma, el vector inicial o de proteccin si no existen medios hardware de
polinomio generador desempea la funcin de clave. proteccin adecuados para la clave y otros datos
secretos (vase la gua bsica para ordenador
universal U6).
1) Infraestructura PKI: la clave pblica del
almacenamiento sometido a control legal ha
sido certificada por una Autoridad
certificadora.
2) Confianza directa: no es necesario implicar a
una Autoridad certificadora si, por un
acuerdo anterior, ambas partes son capaces
de leer la clave pblica del instrumento de
medida directamente en un dispositivo
sometido a control legal que muestra el
conjunto de datos relevantes.
Pgina 50 de 115

El cdigo fuente que realiza la gestin de las claves.
Se comprobar que las medidas tomadas para la gestin de claves son adecuadas.

T6: Tratamiento de datos corruptos
Si se detectan datos corruptos, estos no deben utilizarse.
Especificaciones:
Aunque los protocolos de comunicacin normalmente repiten una transmisin hasta que es correcta, es
posible que se reciba algn conjunto de datos corrupto.
Descripcin de los mecanismos de deteccin de fallos de documentacin requerida para las clases de
transmisin o de cambios intencionados. riesgo B y C):
Se deben describir las medidas tomadas para
el correcto tratamiento de los datos corruptos.
Comprobaciones basadas en la documentacin y las clases de riesgo B y C):
comprobaciones funcionales: Comprobaciones basadas en la
Se comprobar que los datos corruptos no se utilizan documentacin:
para el fin previsto. Se comprobar si las medidas tomadas son
adecuadas con respecto a la tecnologa actual
para garantizar un nivel de proteccin alto.
Cuando el programa que recibe los conjuntos de datos detecta una discrepancia entre el conjunto de datos
y el valor de referencia de la firma, primero intenta reconstruir el valor original si hay informacin
redundante disponible. Si falla la reconstruccin, genera una advertencia para el usuario, no proporciona
el valor de medicin y:
Activa una bandera en un campo especial del conjunto de datos (campo de estado) con el significado
no vlido, o
Elimina el conjunto de datos corrupto.

El cdigo fuente del dispositivo receptor.
Se comprobar que las medidas tomadas para el tratamiento de los datos corruptos son adecuadas.
Pgina 51 de 115

T7: Retraso en la transmisin
Los retrasos en la transmisin no influirn de modo inadmisible en la medicin.
Especificaciones:
El fabricante investigar la duracin de la transmisin de los datos y garantizar que, en el peor de los
casos, la medicin no se vea influida de modo inadmisible.
Descripcin de cmo se protege la medicin frente a un retraso en la transmisin.
Gua de validacin:
Se comprobar que un retraso en la transmisin no influye en la medicin.
Implementacin de los protocolos de transmisin para los buses de campo.

El cdigo fuente que realiza la transmisin de los datos.
Se comprobar que las medidas tomadas para el tratamiento de las demoras en las transmisiones son
adecuadas.

T8: Disponibilidad de los servicios de transmisin
Si los servicios de red dejan de estar disponibles, no se debe perder ningn dato de medida.
Especificaciones:
1. El usuario del sistema de medida no podr corromper los datos de medida interrumpiendo la
transmisin.
2. Las perturbaciones de la transmisin se producen accidentalmente y no se pueden excluir. El
dispositivo de envo debe ser capaz de manejar esta situacin.
3. Si los servicios de transmisin dejan de estar disponibles, la reaccin del instrumento depender del
principio de medida (vase la extensin I).
Descripcin de las medidas de proteccin frente a la interrupcin de la transmisin u otros fallos.
Gua de validacin:
Se comprobar qu medidas se han implementado para la proteccin frente a las prdidas de datos.
Se comprobar cules son las medidas previstas en caso de fallos de transmisin.
Las comprobaciones aleatorias deben mostrar que no se pierde ningn dato relevante por causa de una
interrupcin de la transmisin.
1) Para mediciones que se pueden interrumpir, que se pueden detener de manera rpida y sencilla (p. ej.,
pesaje, medicin de combustible, etc.), la medicin se puede completar incluso si falla la transmisin.
Sin embargo, el instrumento de medida o dispositivo que est transmitiendo los datos legalmente
relevantes deber contar con un buffer que tenga la capacidad suficiente para almacenar la transaccin
en curso. Despus de esto, no se podr iniciar ninguna otra transaccin y los datos almacenados en el
buffer se guardarn para que puedan transmitirse ms adelante. Para consultar otros ejemplos vase la
extensin I.
2) Las mediciones que no se pueden interrumpir (p. ej., las mediciones de energa, volumen, etc.) no
necesitarn un buffer especial intermedio porque estas mediciones siempre son acumulativas. El
registro acumulativo podr leerse y transmitirse ms tarde, cuando se restablezca la conexin.
Pgina 52 de 115

El cdigo fuente que realiza la transmisin de los datos.
Se comprobar que son adecuadas las medidas tomadas para reactivar un servicio de transmisin
interrumpido.
8 Extensin S: Separacin de software
La separacin de software es una metodologa de diseo opcional que permite al fabricante modificar
fcilmente el software legalmente no relevante. Si se implementa la separacin de software, se
considerar esta extensin adems de los requisitos bsicos de los tipos P y U.
En general, los instrumentos de medida o sistemas controlados por software disponen de una
funcionalidad compleja y contienen mdulos legalmente relevantes y mdulos que no lo son. Es una
ventaja para el fabricante y para el examinador aunque no es obligatorio separar estos mdulos de
software del sistema de medida.
En la siguiente tabla se describen dos variantes de separacin de software (las series de requisitos
contemplan ambas opciones).
Descripcin
La separacin de software se implementa independientemente del sistema operativo dentro de un
dominio de aplicacin; es decir, a nivel de lenguaje de programacin (separacin de software de bajo
nivel).
Nota: Esta caracterstica se aplica tanto a los dispositivos de medida diseados especficamente como a los
ordenadores universales.
Los mdulos de software que se van a separar se implementan como objetos independientes a nivel de
sistema operativo (separacin de software de alto nivel).
Nota: Este tipo de separacin normalmente solo es posible con ordenadores universales. Son ejemplos de solucin
programas ejecutables de forma independiente, bibliotecas dinmicas, etc.
Tabla 8-1: Descripcin tcnica de la separacin de software.
La proteccin frente a cambios inadmisibles de los valores y parmetros de medida se aborda solo de
forma indirecta, ya que el programador de los componentes de software que no estn sometidos a
control legal no debe proporcionar al usuario del sistema de medida la posibilidad de corromperlo. Sin
embargo, el programador debe considerar la proteccin en cualquier caso (con o sin separacin) y los
requisitos adecuados proporcionados en las configuraciones bsicas P y U (captulos 4 y 5) de la gua.
Pgina 53 de 115
8.2 Requisitos especficos para separacin de software

S1: Realizacin de la separacin de software
Habr una parte del software que contenga todo el software y los parmetros legalmente relevantes que
estar claramente separada de las dems partes del software.
Especificaciones:
1. En caso de separacin de bajo nivel, todas las unidades de programa (subrutinas, procedimientos,
funciones, clases, etc.) y, en caso de separacin de alto nivel, pertenecen al software legalmente
relevante1 todos los programas y bibliotecas:
que contribuyan al clculo de los valores de medida o que afecten a este;
que contribuyan a funciones auxiliares, tales como la visualizacin de datos, seguridad de datos,
almacenamiento de datos, identificacin de software, descarga de software, transmisin o
almacenamiento de datos, verificacin de datos recibidos o almacenados, etc.
2. Todas las variables, parmetros y archivos temporales que afecten a los valores de medicin o a las
funciones o datos legalmente relevantes pertenecen al software legalmente relevante.
3. Los componentes de la interfaz de software protectora (vase S3) forman parte del software
4. El software que legalmente no es relevante incluye las unidades de programa, datos o parmetros
restantes que no estn incluidos en los puntos anteriores. Se pueden realizar modificaciones en esta
parte sin necesidad de informar de ello al organismo notificado siempre que se tengan en cuenta los
siguientes requisitos para la separacin de software.
Descripcin de todos los componentes mencionados en documentacin requerida para las clases de
las especificaciones anteriores que pertenezcan al riesgo B y C):
software legalmente relevante. La documentacin describir la correcta
implementacin de la separacin de software.
Se comprobar que todos los componentes legalmente Comprobaciones basadas en la documentacin:
relevantes mencionados en las especificaciones 13 se Se comprobar si la separacin de software se ha
incluyen en el software legalmente relevante. realizado correctamente.
Como se describe en el propio requisito.

Se comprobar el diseo del software para ver si el flujo de datos relativo a la informacin legalmente
relevante est definido inequvocamente en el software legalmente relevante y puede verificarse.
Se comprobar (p. ej., analizando el flujo de datos con herramientas o de forma manual) que todas las
unidades de programa, bibliotecas y programas involucrados en el procesamiento de los valores de
medida estn registrados en el software legalmente relevante.
Se realizarn bsquedas de flujos de datos inadmisibles desde las partes no sujetas a control legal hasta
los dominios que deban protegerse.
1
Nota:
Separacin de bajo nivel : La combinacin de componentes a nivel del lenguaje de programacin o la combinacin de
partes de un programa (es decir, subrutinas, procedimientos, funciones, clases) para formar la parte legalmente relevante
del programa. El resto del programa es la parte legalmente no relevante.
Separacin de alto nivel: Combinacin de todas las partes del software en un objeto que es identificable por el sistema
operativo (un programa, una DLL, etc.). El resto del programa es la parte legalmente no relevante.
Pgina 54 de 115

S2: Indicacin mixta
La informacin adicional generada por el software, que no es legalmente relevante, solo podr
mostrarse en pantalla o impresa, en caso de que no haya posibilidad de confusin con la informacin
originada en la parte legalmente relevante.
Especificaciones:
Ya que es posible que el programador del software legalmente no relevante desconozca si son admisibles
las indicaciones, es responsabilidad del fabricante garantizar que toda la informacin indicada cumpla el
requisito.
Descripcin del software que realiza la indicacin. de la documentacin requerida para
Descripcin de cmo se protege la indicacin de informacin las clases de riesgo B y C):
legalmente relevante contra indicaciones engaosas generadas por La documentacin describir como
el software legalmente no relevante. se realiza la indicacin mixta.
Comprobaciones funcionales: gua para las clases de riesgo B y C):
Se comprobar de forma visual que no haya posibilidad alguna de Comprobaciones basadas en la
que la informacin adicional generada por el software legalmente documentacin:
no relevante y presentada en pantalla o impresa se confunda con Se comprobar si la indicacin
la informacin originada por el software legalmente relevante. mixta se ha implementado
correctamente.

La informacin que va a mostrar el software legalmente no relevante se transfiere a travs de la interfaz
protectora (vase S3) al software legalmente relevante. En la interfaz pasa a travs de un filtro que
detecta la informacin inadmisible. A continuacin, la informacin admisible se inserta en la
indicacin controlada por el software legalmente relevante.
En una pantalla con ventanas (ordenador universal) el software legalmente relevante comprueba a
intervalos breves si la ventana con la informacin legalmente relevante est siempre visible y en la
parte superior del grupo de ventanas. Si est oculta, minimizada o fuera del borde, el software genera
una advertencia o detiene la salida y procesamiento de los valores de medida. Puede cerrarse la ventana
con informacin legalmente relevante cuando termina la medicin.

Se comprobar que el software legalmente relevante genera la indicacin de los valores de medida.
Se comprobar que los programas legalmente no relevantes no pueden cambiar o suprimir esta
indicacin.
Pgina 55 de 115

S3: Interfaz de software protectora
El intercambio de datos entre el software legalmente relevante y el software que no lo sea debe
realizarse mediante una interfaz de software protectora, que incluya las interacciones y el flujo de datos.
Especificaciones:
1. Ninguna interaccin ni flujo de datos debe influir de forma inadmisible en el software legalmente
relevante incluyendo el comportamiento dinmico del proceso de medicin.
2. Existir una asignacin inequvoca de cada comando enviado mediante la interfaz software a una
funcin o modificacin de datos iniciado en el software legalmente relevante.
3. Los cdigos y datos que no estn declarados y documentados como comandos no deben tener efecto
sobre el software legalmente relevante.
4. La interfaz estar completamente documentada y ni el programador del software legalmente relevante
ni los programadores del software que no lo sea implementarn ningn otro flujo de datos o interaccin
que no estn documentados (elusin de la interfaz).
Nota: Los programadores son responsables del cumplimiento de estas restricciones. No es posible aplicar medios
tcnicos que les impidan eludir la interfaz software. Se debera instruir al programador de la interfaz protectora
sobre este requisito.
Descripcin de la interfaz software, especialmente qu dominios de (adems de la documentacin
datos implementa la interfaz. requerida para las clases de
Una lista completa de todos los comandos junto con una declaracin de riesgo B y C):
que no hay comandos adicionales. La documentacin describir
Una breve descripcin de su significado y su efecto sobre las funciones la implementacin de la
y datos del instrumento de medida. interfaz software.
Gua de validacin: Gua de validacin (adems
Comprobaciones basadas en la documentacin: de la gua para las clases de
Se comprobar que se han definido y descrito las funciones del riesgo B y C):
software legalmente relevante que pueden activarse a travs de la Comprobaciones basadas en
interfaz protectora. la documentacin:
Se comprobar que se han definido y descrito los parmetros que Se comprobar si la interfaz
pueden intercambiarse a travs de la interfaz. de software se ha
Se comprobar que la descripcin de las funciones y de los parmetros implementado correctamente.
es concluyente y completa.
Los dominios de datos de la parte de software legalmente relevante se encapsulan declarando
nicamente variables locales en la parte legalmente relevante.
La interfaz se implementa como una subrutina perteneciente al software legalmente relevante que se
llama desde el software legalmente no relevante. Los datos se transfieren al software legalmente
relevante como parmetros de la subrutina.
El software legalmente relevante filtra los comandos inadmisibles de la interfaz.
Pgina 56 de 115

Se comprobar el diseo del software para ver si el flujo de datos est definido de modo inequvoco en
el software legalmente relevante y puede verificarse.
Se comprobar el flujo de datos a travs de la interfaz de software con herramientas o de forma manual.
Se comprobar si se ha documentado todo el flujo de datos entre las partes (no se elude la interfaz de
software declarada).
Se realizarn bsquedas de flujos de datos inadmisibles desde las partes no sujetas a control legal hasta
los dominios que deban protegerse.
Se comprobar que los comandos, si existen, se decodifican correctamente y que no existen comandos
no documentados.
9 Extensin D: Descarga de software legalmente relevante
Esta extensin es de aplicacin a la descarga de software legalmente relevante mientras las

caractersticas metrolgicas permanezcan inalteradas y la declaracin de la conformidad sea vlida; p.
ej., correcciones de fallos. Adems de estos requisitos se considerarn los requisitos bsicos de los
tipos P y U que se describen en los captulos 4 y 5 de la gua.
El software solo puede descargarse a instrumentos de medida con las siguientes propiedades:
Configuracin hardware
El dispositivo de destino est sometido a control legal. Puede ser un instrumento de medida desarrollado
especficamente (tipo P) o uno basado en un ordenador universal (tipo U). Las conexiones de
comunicacin para la descarga pueden ser directas p. ej., RS232, USB, a travs de una red cerrada
parcial o totalmente bajo control legal p. ej., Ethernet, red de rea local tipo token ring o a travs de una
red abierta p. ej., Internet.
Configuracin software
El software del dispositivo de destino puede estar completamente bajo control legal o puede existir
separacin de software. La descarga del software legalmente relevante debe cumplir los requisitos que se
indican a continuacin. Si no hay separacin de software en el instrumento de medida, todos los
requisitos siguientes sern de aplicacin para todas las descargas.
Tabla 9-1: Descripcin tcnica de las configuraciones para la descarga de software.
Pgina 57 de 115
9.2 Requisitos especficos del software

D1: Mecanismo de descarga
La descarga y la instalacin posterior del software ser automtica y garantizar que al finalizar el
proceso el entorno de proteccin del software se encuentre en el nivel aprobado.
Especificaciones:
1. La descarga ser automtica para garantizar que el nivel de proteccin existente no se ve comprometido.
2. El dispositivo de destino tiene un software legalmente relevante fijo que contiene todas las funciones
de comprobacin necesarias para cumplir los requisitos D2D4.
3. El instrumento debera ser capaz de detectar si la descarga o la instalacin fallan. Se mostrar una
advertencia. Si la descarga o instalacin falla o se interrumpe, el estado original del instrumento de
medida no se ver afectado. De modo alternativo, el instrumento mostrar un mensaje de error
permanente y su funcionamiento metrolgico se inhibir hasta que se corrija la causa del error.
4. Tras finalizar la instalacin correctamente, se deberan restaurar todos los medios de proteccin a su
estado original a menos que el software descargado tenga autorizacin del organismo notificado en el
certificado de examen de modelo para corregirlos.
5. Durante la descarga y la instalacin posterior del software descargado, se inhibir la funcin de
medicin del instrumento o se garantizar la medicin correcta.
6. Si se producen fallos durante la descarga deben implementarse los requisitos de control de fallos
descritos en la extensin I. El nmero de intentos de reinstalacin ser limitado.
7. Si no pueden cumplirse los requisitos D2D4, an podr descargarse la parte del software que no sea
legalmente relevante. En este caso, debern cumplirse los requisitos siguientes:
- Existe una separacin clara entre el software legalmente relevante y el software que no lo es,
segn la extensin S.
- Toda la parte del software legalmente relevante es fija, es decir, no puede descargarse ni
modificarse sin romper ninguna proteccin.
- En el certificado de examen de modelo, se establece que se acepta la descarga de la parte
legalmente no relevante.
La documentacin debera describir brevemente la naturaleza de la documentacin requerida para
automtica de la descarga, la comprobacin y la instalacin, las clases de riesgo B y C):
cmo se garantiza el nivel de proteccin al finalizar el proceso y La documentacin describir la
qu sucede si se produce un fallo. implementacin del mecanismo de
descarga.
Se comprobar la documentacin para ver cmo se gestiona el Comprobaciones basadas en la
procedimiento de descarga. documentacin:
Se comprobar que la descarga e instalacin se controlan Se comprobar si la
automticamente, que el instrumento de medida est bloqueado implementacin del mecanismo de
(si procede) y que la proteccin del software no se ve descarga es correcta.
comprometida tras una descarga.
Se comprobar que existe un software legalmente relevante fijo
que no se puede descargar para comprobaciones de autenticidad
e integridad.
Se comprobar que durante la descarga de software no es
posible realizar ninguna medicin se garantiza que las que se
realicen sean correctas.
Se realizar, al menos, una descarga de software para comprobar
que esta funcin se realiza correctamente.
Pgina 58 de 115

Un programa de utilidad residente en la parte fija del software que:
a. Negocia con el remitente (handshake) y comprueba la existencia de permisos.
b. Inhibe automticamente la medicin a menos que se pueda garantizar una medicin correcta.
c. Descarga automticamente el software legalmente relevante a un rea de almacenamiento segura.
d. Realiza automticamente las comprobaciones requeridas en D2D4.
e. Instala automticamente el software en la ubicacin correcta.
f. Se ocupa de la gestin interna; p. ej., eliminacin de archivos redundantes, etc.
g. Garantiza que cualquier proteccin eliminada para facilitar la descarga e instalacin se repone
automticamente al nivel aprobado al finalizar el proceso.
h. Inicia los procedimientos adecuados de control de fallos si se produce uno.

El cdigo fuente de la parte de software fija responsable de la gestin del proceso de descarga.

Se comprobar si las medidas tomadas para gestionar el proceso de descarga son adecuadas.
Pgina 59 de 115

D2: Autenticacin del software descargado
Se emplearn medios para garantizar que el software descargado es autntico, y para indicar que ha
sido aprobado por un organismo notificado.
Especificaciones:
1. Antes de que el software descargado se utilice por primera vez, el instrumento de medida comprobar
automticamente que:
a. El software es autntico (no una simulacin fraudulenta);
b. El software est aprobado para ese modelo de instrumento de medida.
2. Los medios por los que el software identifica su condicin de aprobado por el organismo notificado
sern seguros para evitar la falsificacin.
3. Si el software descargado no cumple alguna de las comprobaciones anteriores, vase D1.
4. Si el fabricante tiene intencin de cambiar o actualizar el software legalmente relevante deber
comunicar los cambios al organismo notificado responsable. El organismo notificado decide si es o no
necesario una adicional al certificado de examen de modelo. Para la descarga del software es
indispensable que exista una identificacin del software asignada de forma inequvoca a la versin
aprobada del software.
La documentacin debera describir: documentacin requerida para las clases de
Cmo se garantiza la autenticidad de la riesgo B y C):
identificacin del software. La documentacin describir la
Cmo se garantiza la autenticidad de la aprobacin implementacin de la autenticacin.
del organismo notificado.
Cmo se garantiza que el software descargado est
aprobado para el modelo de instrumento de medida
para el que ha sido descargado.
Comprobaciones basadas en la documentacin y las clases de riesgo B y C):
comprobaciones funcionales: Comprobaciones basadas en la
Se comprobar en la documentacin cmo se evitan documentacin:
las descargas de software fraudulento. Se comprobar si las medidas tomadas son
Se comprobar, a travs de comprobaciones adecuadas con respecto a la tecnologa actual
funcionales, que se evitan las descargas de software para garantizar un nivel de proteccin alto.
fraudulento.
Se asegurar la comprobacin de autenticidad del
software segn la documentacin y a travs de
comprobaciones funcionales.
1. Autenticidad: por razones de integridad (vase D3), se genera una firma electrnica sobre la parte del
software que se va a descargar. La autenticidad se garantiza si una clave almacenada en la parte fija del
software del instrumento confirma que la firma procede del fabricante. La correspondencia de las
claves se realizar automticamente.
2. Organismo notificado: la clave se almacena en la parte fija del software antes de la verificacin
inicial.
3. Modelo correcto del instrumento de medida: la comprobacin del modelo de instrumento requiere
la correspondencia automtica de una identificacin del modelo de instrumento que se almacena en la
parte fija del software del mismo con una lista de compatibilidad asociada al software.
Pgina 60 de 115
4. Aprobacin por el organismo notificado 4. Aprobacin por el organismo notificado

Si se garantiza la autenticidad mediante el uso de la Para comprobar que ese software ha sido
clave del fabricante, puede asumirse la aprobacin por aprobado realmente, una posibilidad es que
el organismo notificado. todo el software aprobado que se haya
descargado contenga la firma de la autoridad
responsable. La clave pblica de la autoridad
responsable se almacena en el instrumento de
medida y se utiliza para comprobar
automticamente la firma asociada al
software. Esta se puede visualizar en el
instrumento para compararla con la clave
publicada por la autoridad responsable.

El cdigo fuente de la parte de software fija responsable de la comprobacin de la autenticidad del
software descargado.
Se comprobar si las medidas tomadas para la comprobacin de la autenticidad son adecuadas.

D3: Integridad del software descargado
Se emplearn medios para garantizar que durante la descarga el software descargado no haya sido
modificado de forma inadmisible.
Especificaciones:
1. Antes de utilizar por primera vez el software descargado, el instrumento de medida comprobar
automticamente que dicho software no se haya modificado de forma inadmisible.
2. Si el software descargado no supera esta comprobacin, vase D1.
La documentacin describir cmo se garantiza la documentacin requerida para las clases de
integridad del software. riesgo B y C):
La documentacin describir las medidas
que garantizan la integridad.
Se garantizar la comprobacin de la integridad del las clases de riesgo B y C):
software despus de la descarga segn la documentacin Comprobaciones basadas en la
y a travs de comprobaciones funcionales. documentacin:
Se comprobar si las medidas tomadas son
adecuadas con respecto a la tecnologa
actual para garantizar un nivel de proteccin
alto.
La integridad puede demostrarse realizando una suma de Generar un valor hash del software a
comprobacin del software legalmente relevante y descargar (p. ej.: algoritmos SHA-1, Ripe
comparndola con la suma de comprobacin asociada al MD 160) y cifrarlo (RSA, curvas elpticas)
software (vase tambin U2 para un ejemplo de solucin con una longitud de clave adecuada.
aceptable). La clave para descifrar se almacena en la
Algoritmo aceptable: CRC, vector inicial secreto, 32 bits parte de software fija.
de longitud. El vector inicial se almacena en la parte de
software fija.
Pgina 61 de 115

El cdigo fuente de la parte de software fija responsable de la comprobacin de la integridad del
software descargado.
Se comprobar si son adecuadas las medidas tomadas para la comprobacin de la integridad.

D4: Trazabilidad de la descarga del software legalmente relevante
Se garantizar mediante los medios tcnicos adecuados que las descargas del software legalmente
relevante puedan rastrearse dentro del instrumento para realizar controles posteriores.
Especificaciones:
1. Este requisito permite que las autoridades de inspeccin, responsables de la supervisin metrolgica
de los instrumentos sometidos a control metrolgico, rastreen las descargas del software legalmente
relevante durante un perodo de tiempo adecuado (que depender de la legislacin nacional).
2. Los medios y registros de trazabilidad forman parte del software legalmente relevante y deberan
protegerse como tales.
La documentacin deber: de la documentacin requerida para
Describir brevemente cmo se implementan y protegen los las clases de riesgo B y C):
medios para la trazabilidad. La documentacin describir las
Establecer cmo puede rastrearse el software descargado. medidas que garantizan la
trazabilidad.
Se comprobar que se implementan y protegen los medios para la Comprobaciones basadas en la
trazabilidad. documentacin:
Comprobaciones funcionales: Se comprobar si las medidas
Se comprobar la funcionalidad de los medios a travs de tomadas son adecuadas con respecto
comprobaciones aleatorias. a la tecnologa actual para garantizar
un nivel de proteccin alto.
Registro de actividades. El instrumento de medida puede estar equipado con un registro de sucesos
que registra automticamente al menos la fecha y la hora de la descarga, la identificacin del
software legalmente relevante que se ha descargado, la identificacin de la parte descargada, y una
anotacin del xito de la operacin. Se genera una entrada por cada intento de descarga,
independientemente de si ha tenido xito.
Despus de haber alcanzado el lmite del registro de sucesos, se garantizar por medios tcnicos que
no es posible realizar ms descargas. Los registros de sucesos solo se podrn borrar rompiendo un
precinto fsico o electrnico y solo podrn volver a precintarlos las autoridades de inspeccin.

El cdigo fuente de la parte fija del software responsable de rastrear los procesos de descarga y de
gestionar el registro de sucesos.

Se comprobar si las medidas tomadas para rastrear los procesos de descarga son adecuadas.
Se comprobar si las medidas tomadas para proteger el registro de sucesos son adecuadas.
Pgina 62 de 115
Consentimiento para la descarga
Se asume que el fabricante del instrumento de medida mantiene a su cliente bien informado sobre las
actualizaciones del software, en especial sobre la parte legalmente relevante, y que el cliente no se
negar a su actualizacin. Adems se asume que el fabricante y el cliente, usuario o propietario del
instrumento acordarn un procedimiento adecuado para la realizacin de la descarga en funcin del
uso y ubicacin del instrumento.
10 Extensin I: Requisitos del software especficos del instrumento.
Esta extensin complementa los requisitos generales del software de los captulos anteriores y no
puede considerarse de forma independiente de las partes P o U ni de otras extensiones (vase el
captulo 3). Refleja la existencia de anexos de la MID especficos para cada instrumento (MI-x) y
contiene aspectos y requisitos especficos de los instrumentos o sistemas de medida (o subconjuntos).
Sin embargo, estos requisitos no van ms all de los requisitos de la MID. Slo se hace referencia a las
recomendaciones de la OIML o a las normas ISO/IEC, cuando estas pueden considerarse documentos
normativos en el sentido de la MID, y si respaldan una interpretacin armonizada de los requisitos de
esta Directiva.
Adems de los aspectos y requisitos del software especficos del instrumento, la extensin I contiene la
asignacin especfica de clases de riesgos para el instrumento (o categora) que garantiza un nivel
armonizado de examen, proteccin y conformidad del software.
Por ahora, la extensin I est pensada como un borrador inicial a completar por el respectivo grupo de
trabajo de WELMEC con los conocimientos especficos correspondientes. Por lo tanto, la extensin I
tiene una "estructura abierta", es decir, que proporciona un esqueleto que adems de la asignacin
inicial de las clases de riesgo est cumplimentado solo parcialmente (p. ej., para los contadores de
servicio pblico e instrumentos de pesaje de funcionamiento automtico). Tambin puede utilizarse
para otros instrumentos (incluidos o no en la MID), segn las experiencias adquiridas y las decisiones
tomadas por los grupos de trabajo WELMEC responsables. La numeracin x de los subapartados 10.x
se corresponde con la numeracin de los anexos especficos de la MID. Los instrumentos no incluidos
en la MID podran aadirse comenzando en el 10.11.
Para un determinado tipo x de instrumento de medida, pueden existir diferentes aspectos del software
especficos a tener en cuenta. Estos aspectos deberan tratarse de un modo sistemtico como se indica
a continuacin: cada subapartado 10.x debera dividirse en secciones 10.x.y, donde y trata los
siguientes aspectos:
10.x.1 Reglamentos especficos, normas y otros documentos normativos
Aqu deben mencionarse los reglamentos especficos de instrumentos (o categoras), las normas y
dems documentos normativos (p. ej., las recomendaciones de la OIML) o las guas WELMEC que
pueden ayudar a desarrollar los requisitos del software especficos del instrumento (o categora) como
una interpretacin de los requisitos del anexo I y de los anexos especficos MI-x de la MID.
Normalmente, los requisitos del software especficos del instrumento se aplican junto con los
requisitos generales de los captulos anteriores. De otro modo, se debera exponer claramente si un
requisito del software especfico sustituye a uno (o a varios) de los requisitos generales del software o
si uno (o varios) de los requisitos generales del software no es (son) aplicable(s) y el motivo.
Pgina 63 de 115
10.x.2 Descripcin tcnica
Aqu pueden proporcionarse:
- ejemplos de las configuraciones tcnicas especficas ms comunes,

- la aplicacin de las partes P, U y extensiones para estos ejemplos y
- listas de comprobacin (especficas de los instrumentos) tiles para el fabricante y el
examinador.
La descripcin debera incluir:
- el principio de medida (medicin acumulativa o independiente, medicin repetible o no

repetible y medicin esttica o dinmica) y
- deteccin de fallos y la reaccin ante ellos. Existen dos casos posibles:
a) que la presencia de un error sea obvia o que pueda comprobarse de forma sencilla o
existan medios hardware para detectar el fallo,
b) que no resulte obvia la presencia de un error y no pueda comprobarse fcilmente y no
haya medios hardware para la detectar el fallo.
En el ltimo caso (b), la deteccin de fallos y la reaccin ante estos requiere medios de
software adecuados y, por tanto, requisitos de software adecuados
- la configuracin hardware; al menos, deberan incluirse los siguientes aspectos:
a) Se trata de un sistema modular basado en un ordenador de propsito general o se trata

de un instrumento dedicado con un sistema integrado sometido a control legal?
b) El sistema informtico es autnomo o forma parte de una red cerrada (p. ej., Ethernet,
LAN token ring), o forma parte de una red abierta (p. ej., Internet)?
c) La unidad del sensor (mdulo de medida) est separado (ubicacin y suministro de
energa separados) del sistema de tipo U o est integrado en l completa o
parcialmente?
d) La interfaz de usuario se encuentra siempre sometida a control legal (tanto para los
instrumentos de tipo P y U) o puede cambiarse a un modo operativo que no est
sometido a control legal?
e) Se prev el almacenamiento de datos a largo plazo? Si es as, entonces el
almacenamiento es local (p. ej., disco duro) o remoto (p. ej., servidor de ficheros)?
f) El medio de almacenamiento es fijo (p. ej., ROM interna) o extrable (p. ej., disquete,
CD-RW, tarjeta inteligente o memory stick)?
- la configuracin software y el entorno; al menos, deberan incluirse los siguientes aspectos:
a) Qu sistema operativo se utiliza o puede utilizarse?

b) Hay otras aplicaciones de software en el sistema adems del software legalmente
relevante?
c) Existe software que no est sometido a control legal pensado para poder modificarse
libremente tras la aprobacin?
10.x.3 Requisitos del software especficos
Aqu deberan relacionarse y describirse, de un modo parecido al de los captulos anteriores, los
requisitos del software especficos.
Pgina 64 de 115
10.x.4 Ejemplos de funciones y datos legalmente relevantes
Aqu pueden proporcionarse ejemplos de:
- parmetros especficos del dispositivo (p. ej., parmetros individuales de configuracin y

calibracin de un instrumento de medida especfico),
- parmetros especficos del modelo (p. ej., los parmetros especficos que se fijan en el
examen de modelo) o
- funciones especficas legalmente relevantes.
10.x.5 Otros aspectos
Aqu pueden mencionarse otros aspectos como por ejemplo la documentacin especfica necesaria
para el examen (software) del modelo, descripciones especficas e instrucciones que deben
proporcionarse en los certificados de examen de modelo. Tambin pueden mencionarse otros aspectos
(p. ej., los requisitos relativos a la realizacin de ensayos).
10.x.6 Asignacin de la clase de riesgo
Aqu debera definirse la clase de riesgo adecuada para los instrumentos de tipo x. Esto puede hacerse:
- de forma general (para todas las categoras del tipo respectivo) o

- segn el campo de aplicacin o categora u otros aspectos, si existen.
10.1 Contadores de agua
10.1.1 Reglamentos especficos, normas y otros documentos normativos

Los Estados miembros pueden segn el artculo 2 de la MID prescribir el uso de contadores de
agua sometidos a la regulacin de la MID en el uso residencial, comercial y de industria ligera.
Los requisitos especficos de este captulo se basan exclusivamente en el anexo MI-001.
No se han tenido en cuenta las recomendaciones y normas de la OIML.
10.1.2 Descripcin tcnica
10.1.2.1 Configuracin hardware
Los contadores de agua suelen construirse como dispositivos desarrollados especficamente (tipo P en
esta gua).
10.1.2.2 Configuracin software
Es especfica de cada fabricante, pero normalmente debera esperarse que siguiera las
recomendaciones proporcionadas en el cuerpo principal de esta gua.
10.1.2.3 Principio de medida
Los contadores de agua acumulan de forma continua el volumen consumido. El volumen acumulado
se visualiza en el instrumento. Se emplean varios principios.
La medicin de volumen es no repetible.
Pgina 65 de 115
10.1.2.4 Deteccin de fallos y reaccin ante ellos
El requisito MI-001, 7.1.2 trata las perturbaciones electromagnticas. Es necesario interpretar este
requisito para los instrumentos controlados por software porque solo se puede detectar una
perturbacin y recuperarse de la misma mediante accin combinada de determinadas partes del
hardware y del software especfico. Desde el punto de vista del software no importa cul sea el motivo
de una perturbacin (electromagntico, elctrico, mecnico, etc.): los procedimientos de recuperacin
son los mismos.
10.1.3 Requisitos de software especficos (contadores de agua)

I1-1: Recuperacin ante fallos
El software se recuperar de una perturbacin y pasar al funcionamiento normal.
Especificaciones:
Debern activarse indicadores con la fecha para facilitar el registro de periodos de mal funcionamiento.
Una breve descripcin del mecanismo de recuperacin ante fallos y cundo se activa.
Gua de validacin:
Se comprobar si la implementacin de la recuperacin ante fallos es adecuada.
Ninguna, aparte de las realizadas durante el examen de modelo para confirmar el correcto
funcionamiento en presencia de determinadas magnitudes de influencia.
Una subrutina microprocesada reinicia peridicamente un temporizador de control hardware (hardware
watchdog) evitando su disparo. Si alguna funcin no se ha procesado o en el peor de los casos el
microprocesador se cuelga en un bucle infinito, este reinicio no tiene lugar y el temporizador de control
se dispara al cabo del tiempo establecido.
I1-2: Funcionalidades para la generacin de copias de seguridad
Existir una funcionalidad que, en caso de que se produzca alguna perturbacin, proporcione copias de
seguridad peridicas de los datos legalmente relevantes como los valores de medicin y el estado actual
del proceso. Estos datos se guardarn en un almacenamiento no voltil.
Especificaciones:
Los intervalos de almacenamiento deben ser suficientemente breves como para que la discrepancia entre
los valores actuales y los acumulativos sea pequea.
Una breve descripcin de sobre qu datos se ha realizado copia de seguridad y de cundo se realiz dicha
copia. Un clculo del error mximo que puede producirse para los valores acumulativos.
Gua de validacin:
Se comprobar que todos los datos legalmente relevantes se guardan en un almacenamiento no voltil y
que se pueden recuperar.
Se realizan copias de seguridad de los datos legalmente relevantes segn se requiera (p. ej., cada 60
minutos).
Pgina 66 de 115

I1-3: Anexo I, 8.5 de la MID (Evitar la puesta a cero de los valores de medida acumulativos)
En el caso de los instrumentos de medida de empresas de servicio pblico el indicador de la cantidad
total suministrada o los indicadores de los que puede extraerse la cantidad total suministrada, que
sirvan de referencia total o parcial para el pago, no podrn ponerse a cero durante su utilizacin.
Especificaciones:
Los registros acumulativos de un instrumento de medida pueden ponerse a cero antes de su puesta en
servicio.
Documentacin de los medios de proteccin frente a la puesta a cero de los registros de volumen.
Gua de validacin:
Se comprobar que los valores de medida legalmente relevantes y acumulativos no puedan ponerse a
cero sin dejar rastro.
Los registros de volumen estn protegidos frente a los cambios y la puesta a cero del mismo modo que
los parmetros (vase P7).
I1-4: Comportamiento dinmico
El software legalmente no relevante no deber influir de forma negativa en el comportamiento dinmico
de un proceso de medida.
Especificaciones:
Este requisito se aplica junto con S-1, S-2 y S-3 si se ha realizado separacin de software conforme a
la extensin S.
Este requisito adicional garantiza que, para aplicaciones en tiempo real de los contadores, el
comportamiento dinmico del software legalmente relevante no se ve influenciado de forma
inadmisible por el software legalmente no relevante, es decir, que los recursos del software
legalmente relevante no se vean reducidos por la parte no legal de forma inadmisible.
Descripcin de la jerarqua de interrupcin.
Diagrama de tiempos de las tareas de software. Lmites del ejecutable proporcionado para tareas
legalmente no relevantes.
Gua de validacin:
La documentacin de los lmites del ejecutable proporcionado para tareas legalmente no relevantes estar
disponible para el programador de la parte del software legalmente no relevante.
La jerarqua de interrupcin est diseada de manera que impida influencias adversas.
Pgina 67 de 115

I1-5: Identificacin impresa del software
La identificacin del software suele presentarse en un dispositivo indicador. Como excepcin para los
contadores de agua, ser una solucin aceptable una impresin que identifique el software en la placa
de caractersticas del instrumento siempre que se cumplan las siguientes condiciones:
A. La interfaz de usuario no tiene capacidad de control para activar la indicacin de la identificacin
del software en el dispositivo indicador o este tcnicamente no permite mostrar la identificacin del
software (contador mecnico).
B. El instrumento no tiene ninguna interfaz para comunicar la identificacin del software.
C. No es posible cambiar el software del contador despus de su fabricacin o solo es posible si se
cambia tambin el hardware o un componente hardware.
Especificaciones:
El fabricante del hardware o del componente hardware pertinente es responsable de que la
identificacin del software est correctamente marcado en dicho hardware.
Se aplican todas las dems especificaciones de P2/U2.
La misma que en P2/U2.
Gua de validacin:
Una marca impresa en la placa de caractersticas del instrumento que identifique el software
10.1.4 Ejemplos de parmetros legalmente relevantes
Los contadores de agua tienen parmetros, como constantes de clculo, de configuracin, etc., pero
tambin tienen parmetros para el ajuste de la funcionalidad del dispositivo. Con respecto a la
identificacin y proteccin de los parmetros y el conjunto de parmetros, vanse los requisitos P2 y
P7 de la gua P.
A continuacin, se proporcionan algunos parmetros tpicos de los contadores de agua . Esta tabla se
actualizar cuando el grupo de trabajo 11 de WELMEC haya decido su contenido final.
Parmetro Protegido Configurable Comentario

Factor de calibracin x
Factor de linealidad x
10.1.5 Otros aspectos
En el caso de aplicaciones domsticas, se supone que la descarga de software (extensin D, captulo 9)

no ser muy importante.
El registro de energa o volumen acumulados de instrumentos domsticos no es un almacenamiento a
largo plazo en el sentido de la extensin L (captulo 6). En el caso de instrumentos que solo midan
energa/volumen acumulados, no es necesario aplicar la extensin L.
Pgina 68 de 115
10.1.6 Asignacin de la clase de riesgo
Hasta ahora, segn las decisiones del grupo de trabajo responsable de WELMEC n 11 (segunda
reunin, 3-4 de marzo de 2005), se consideran adecuadas las siguientes clases de riesgo y deberan
aplicarse si se llevan a cabo exmenes de software basados en la presente gua para los contadores de
agua (controlados mediante software).
- Clase de riesgo C para instrumentos de tipo P
Sin embargo, no se ha tomado todava ninguna decisin definitiva y el grupo de trabajo n 11

reconsiderar este tema en relacin con el debate sobre las clases de riesgo adecuadas para los
instrumentos de tipo U.
Pgina 69 de 115
10.2 Contadores de gas y dispositivos de conversin volumtrica
Los Estados miembros pueden segn el artculo 2 de la MID prescribir el uso de los contadores
de gas y dispositivos de conversin volumtrica sometidos a la regulacin de la MID en el uso
residencial, comercial y de industria ligera.
Los contadores de gas y dispositivos de conversin volumtrica suelen construirse como dispositivos
desarrollados especficamente (tipo P en esta gua). Pueden tener una o varias entradas para unidades
de sensores externas y los contadores y dispositivos de conversin pueden ser unidades de hardware
separadas.
10.2.2.2 Configuracin de software
Los contadores de gas acumulan continuamente el volumen consumido. El volumen acumulado se

muestra en el instrumento. Se emplean varios principios. Se utiliza un dispositivo de conversin
volumtrica para calcular el volumen en condiciones de base. El convertidor puede ser una parte
integral del contador.
La medicin de volumen no puede repetirse.
son los mismos.
Pgina 70 de 115
10.2.3 Requisitos de software especficos (contadores de gas y dispositivos de conversin

volumtrica)

Especificaciones:
Gua de validacin:

Especificaciones:
Gua de validacin:
Se realizan copias de seguridad de los datos legalmente relevantes segn se requiera (p. ej., cada 60 minutos).
Pgina 71 de 115

I2-3: MI-002, 5.2 (idoneidad de la indicacin)
El dispositivo indicador del volumen total sin corregir tendr un nmero de dgitos suficiente para
asegurar que, cuando el contador funcione durante 8 000 horas con Qmx, la indicacin no vuelva a su
valor inicial.
Especificaciones:
Documentacin de la representacin interna del registro de volumen.
Gua de validacin:
Se comprobar si la capacidad de almacenamiento es suficiente.
Los valores tpicos del contador de gas domstico son: Qmx = 6 m3/h. El rango necesario es de 48 000 m3
(en la actualidad los contadores de gas electrnicos muestran hasta 99 999 m3).

Especificaciones:
Los registros acumulativos de un instrumento de medida pueden ponerse a cero antes de su puesta en servicio.
Gua de validacin:
Los registros de volumen estn protegidos frente a los cambios y la puesta a cero, del mismo modo que
Pgina 72 de 115

I2-5: MI-002, 5.2 (Vida til de la fuente de alimentacin)
Una fuente de alimentacin dedicada deber tener una vida til de al menos cinco aos. Deber
aparecer una adecuada advertencia una vez transcurrido el 90 % de su vida til.
Especificaciones:
Vida til se utiliza aqu en el sentido de capacidad de energa disponible.
Si la fuente de energa puede sustituirse in situ, ni los parmetros ni los datos legalmente relevantes
resultarn daados durante el cambio.
Documentacin sobre la capacidad de la fuente de alimentacin, vida til (independiente del consumo de
energa), medidas para determinar la energa consumida o disponible y descripcin de los medios de
advertencia de nivel bajo de energa disponible .
Gua de validacin:
Se comprobar si las medidas que se han tomado son adecuadas para vigilar la energa disponible.
Se cuentan las horas operativas o los sucesos de reactivacin del dispositivo, se almacenan en una
memoria no voltil y se comparan con el valor nominal de vida til de la batera. Si ha transcurrido el
90% de la vida til, se mostrar la adecuada advertencia. El software detecta el intercambio de la fuente
de alimentacin y reinicia el contador.
Otra solucin sera monitorizar continuamente el nivel del suministro de energa.

I2-6: MI-002, 9.1 (Dispositivo de conversin electrnico)
Un dispositivo de conversin electrnico deber poder detectar cundo funciona fuera del rango de
funcionamiento declarado por el fabricante para los parmetros que son relevantes en la exactitud de la
medida. Si eso sucediera, el dispositivo de conversin deber interrumpir la integracin de la cantidad
convertida y poder totalizar por separado la cantidad convertida durante el tiempo que se encuentre
fuera del rango de funcionamiento.
Especificaciones:
Deber existir una indicacin visual del estado de error.
Documentacin de los diferentes registros para la cantidad convertida y la cantidad durante el fallo.
Gua de validacin:
Se comprobar si las medidas tomadas son adecuadas para la gestin de condiciones operativas inusuales.
El software controla los valores de entrada relevantes y los compara con los lmites predefinidos. Si
todos los valores estn dentro de los lmites, la cantidad convertida se integrar en el registro normal (una
variable dedicada). En caso contrario, totaliza la cantidad en otra variable.
Otra solucin sera disponer de un solo registro de acumulacin, pero grabar la fecha y la hora de inicio y
de fin, as como los valores de registro del periodo que est fuera del intervalo en un log de sucesos
(vase P7).
Se pueden indicar ambas cantidades. El usuario puede identificar y distinguir claramente la indicacin
regular y la indicacin durante el fallo, mediante una indicacin del estado.
Pgina 73 de 115

I2-7: MI-002, 5.5 (elemento de ensayo)
El contador de gas dispondr de un elemento de ensayo que permitir realizar pruebas en un plazo de
tiempo razonable.
Especificaciones:
El elemento de ensayo para acelerar los procedimientos de ensayo que consumen mucho tiempo se utiliza
normalmente para realizar la comprobacin antes de la instalacin y el funcionamiento normal.
Durante el modo de ensayo debern utilizarse los mismos registros y partes del software que en el modo
operativo estndar.
Documentacin del elemento de ensayo e instrucciones para activar el modo de ensayo.
Gua de validacin:
Se comprobar si todos los procedimientos de ensayo del contador de gas que consumen mucho tiempo
pueden realizarse mediante el elemento de ensayo.
La base de tiempo del reloj interno puede acelerarse. Los procesos que duran, por ejemplo, una semana,
un mes o incluso un ao y desbordan los registros pueden comprobarse en el modo de prueba en minutos
u horas.

de un proceso de medida.
Especificaciones:
la extensin S.
Gua de validacin:
La jerarqua de interrupcin est diseada de manera que impide influencias adversas.
Pgina 74 de 115

contadores de gas y dispositivos de conversin volumtrica, ser una solucin aceptable una impresin
que identifique el software en la placa de caractersticas del instrumento siempre que se cumplan las
siguientes condiciones:
Especificaciones:
Gua de validacin:
Una marca impresa en la placa de caractersticas del instrumento que identifique el software.
Los contadores de gas y los dispositivos de conversin volumtrica suelen tener muchos parmetros.
Se utilizan como constantes de clculo, de configuracin, etc., pero tambin para el ajuste de la
funcionalidad del dispositivo. Con respecto a la identificacin y proteccin de los parmetros y el
conjunto de parmetros, vanse los requisitos P2 y P7 de la gua P.
A continuacin se proporcionan algunos parmetros tpicos de los contadores de gas y dispositivos de

conversin volumtrica. Esta tabla se actualizar cuando el grupo de trabajo 11 de WELMEC haya
decido su contenido final.



Pgina 75 de 115
gas y dispositivos de conversin volumtrica (controlados mediante software):

El grupo de trabajo n 11 considera que la funcionalidad de prepago y de medicin en intervalos son

adicionales a aquellas funciones de medicin esenciales especificadas en el anexo MI-002 de la MID.
Por lo tanto, a estas variantes no se les asigna una categora de riesgos mayor que la asignada a los
contadores de tipo bsico contemplados en esta gua. Sin embargo, debera evaluarse la funcin de
medicin bsica, como ocurre con todos los dems instrumentos de tipo P junto con cualquier otra
evaluacin que se considere necesaria para demostrar que el software asociado que proporciona estas
funciones no tiene una influencia inadmisible sobre la medicin bsica.
10.3 Contadores de energa elctrica activa
de energa elctrica activa sometidos a la regulacin de la MID en el uso residencial, comercial y de
industria ligera.
No se han tenido en cuenta las recomendaciones y normas de la OIML ni las normas IEC.
Los contadores de energa elctrica activa toman como entrada las medidas de tensin e intensidad de
corriente, obtienen a partir el ellas la potencia elctrica activa y la integran con respecto al tiempo para
aportar la energa elctrica activa.
Los contadores de energa elctrica activa suelen construirse como dispositivos desarrollados
especficamente (tipo P en esta gua). Pueden tener una o varias entradas y pueden combinarse con
transformadores externos.
Pgina 76 de 115
Los contadores de energa elctrica activa acumulan continuamente la energa consumida en un

circuito. El valor de energa acumulativo se muestra en el instrumento. Se emplean transductores y
multiplicadores basados en varios principios.
La medicin de energa no puede repetirse.
son los mismos.
10.3.3 Requisitos de software especficos (contadores de energa elctrica activa)

Especificaciones:
Una breve descripcin del mecanismo de recuperacin ante fallos y cundo se activa. Breve descripcin
de las comprobaciones relacionadas realizadas por el fabricante.
Gua de validacin:
Pgina 77 de 115

Especificaciones:
Si se utiliza la funcionalidad de copia de seguridad para la recuperacin de fallos, deber calcularse el
intervalo mnimo para garantizar que no se exceda el valor crtico de cambio.
Una breve descripcin de sobre qu datos se ha realizado copia de seguridad y de cundo se realiz dicha copia.
Gua de validacin:
Se realizan copias de seguridad de los datos legalmente relevantes segn se requiera.

I3-3: MI-003, 5.2 (aptitud de la indicacin)
El dispositivo indicador de la energa total tendr un nmero de dgitos suficiente para asegurar que,
cuando el contador funcione durante 4 000 horas a carga completa (I = Imx, U = Un y FP = 1), la
indicacin no vuelva a su valor inicial.
Especificaciones:
Documentacin de la representacin interna del registro de energa elctrica y magnitudes auxiliares
(tipos de variables).
Gua de validacin:
Se comprobar si la capacidad de almacenamiento es suficiente.
Los valores tpicos para los contadores de electricidad trifsicos son:
Pmx (4 000 h) = 3 * 60 A * 230 V * 4 000 h = 165 600 kWh. Esto requiere una representacin interna de 4 bytes.
Pgina 78 de 115

Especificaciones:
Documentacin de los medios de proteccin frente a la puesta a cero de los registros de energa.
Gua de validacin:
cero sin evidencia de la intervencin.
funcionamiento. Vase P3 y P4.
Los registros de energa estn protegidos frente a los cambios y la puesta a cero del mismo modo que los
parmetros (vase P7).

de un proceso de medicin.
Especificaciones:
la extensin S.
legalmente relevante no se vean reducidos de forma inadmisible por la parte no legal.
Gua de validacin:
Pgina 79 de 115

contadores de energa elctrica activa, ser una solucin aceptable una impresin que identifique el
software en la placa de caractersticas del instrumento siempre que se cumplan las siguientes
condiciones:
Especificaciones:
Gua de validacin:
Los contadores electrnicos de suministros de servicios pblicos suelen tener muchos parmetros. Se
utilizan como constantes de clculo, de configuracin, etc., pero tambin para el ajuste de la
funcionalidad del dispositivo. Con respecto a la identificacin y proteccin de los parmetros y el
conjunto de parmetros, vanse los requisitos P2 y P7 de la gua P.
A continuacin se proporcionan algunos parmetros tpicos de los contadores de energa elctrica

activa. Esta tabla se actualizar cuando el grupo de trabajo 11 de WELMEC haya decido su contenido
final.



Pgina 80 de 115
energa elctrica activa (controlados mediante software):

El grupo de trabajo n 11 considera que la funcionalidad de prepago y de medicin en intervalos son

adicionales a aquellas funciones de medicin esenciales especificadas en el anexo MI-003 de la MID.
Por lo tanto, a estas variantes no se les asigna una categora de riesgos mayor que la asignada a los
contadores de tipo bsico contemplados en esta gua. Sin embargo, debera evaluarse la funcin de
medicin bsica, como ocurre con todos los dems instrumentos de tipo P junto con cualquier otra
evaluacin que se considere necesaria para demostrar que el software asociado que proporciona estas
funciones no tiene una influencia inadmisible sobre la medicin bsica.
10.4 Contadores de energa trmica

de energa trmica sometidos a la regulacin de la MID en el uso residencial, comercial y de industria
ligera.
Los contadores de energa trmica suelen construirse como dispositivos desarrollados especficamente
(tipo P en esta gua). Un contador de energa trmica puede ser un instrumento completo o un
instrumento combinado que consta de los subconjuntos: sensor de flujo, par sensor de temperatura, y
calculador, segn se define en el artculo 4 b), o una combinacin de estos.
Los contadores de energa trmica acumulan continuamente la energa consumida en un circuito de

calefaccin. La energa trmica acumulada se muestra en el instrumento. Se emplean varios principios.
La medicin de energa no puede repetirse.
Pgina 81 de 115
Los requisitos MI-004, 4.1 y 4.2 tratan las perturbaciones electromagnticas. Es necesario interpretar
este requisito para los instrumentos controlados por software porque solo se puede detectar una
son los mismos.
10.4.3 Requisitos especficos de software (contadores de energa trmica)

Especificaciones:
Gua de validacin:

seguridad peridicas de los datos legalmente relevantes, como los valores de medicin y el estado actual
Especificaciones:
Gua de validacin:
Se realizan copias de seguridad de los datos legalmente relevantes segn se requiera (p. ej., cada 60 minutos).
Pgina 82 de 115

Especificaciones:
Gua de validacin:
Los registros de volumen estn protegidos frente a los cambios y la puesta a cero del mismo modo que
de un proceso de medicin.
Especificaciones:
la extensin S.
Gua de validacin:
Pgina 83 de 115

contadores de energa trmica, ser una solucin aceptable una impresin que identifique el software en
la placa de caractersticas del instrumento siempre que se cumplan las siguientes condiciones:
Especificaciones:
Gua de validacin:
Los contadores de energa trmica tienen parmetros, como constantes de clculo, de configuracin,
etc., pero tambin parmetros para el ajuste de la funcionalidad del dispositivo. Con respecto a la
identificacin y proteccin de los parmetros y el conjunto de parmetros, vanse los requisitos P2 y
P7 de la gua P.
A continuacin, se proporcionan algunos parmetros tpicos de los contadores de energa trmica. Esta
tabla se actualizar cuando el grupo de trabajo 11 de WELMEC haya decido su contenido final.


Pgina 84 de 115
energa trmica (controlados mediante software):

10.5 Sistemas para la medicin continua y dinmica de cantidades de lquidos distintos del agua.
Los sistemas para la medicin continua y dinmica de cantidades de lquidos distintos del agua estn
sometidos a la regulacin de la MID. Los requisitos especficos se encuentran en el anexo MI-005.
An no se han tenido en cuenta ni estos requisitos especficos ni los documentos normativos.
Los apartados 10.5.1 y 10.5.2 se rellenarn en el futuro si se considera necesario.
10.5.3 Requisitos de software especficos (Sistemas para la medicin de lquidos distintos del
agua)

componentes de un sistema de medicin de lquidos distintos del agua, ser una solucin aceptable una
impresin que identifique el software en la placa de caractersticas del instrumento siempre que se
cumplan las siguientes condiciones:
C. No es posible cambiar el software del componente despus de su fabricacin o solo es posible si se
Especificaciones:
La etiqueta con la identificacin del software debe ser indeleble y no transferible
Gua de validacin:
Los apartados 10.5.4 y 10.5.5 se rellenarn en el futuro si se considera necesario.
Por ahora, y segn el resultado del cuestionario de 2004 del grupo de trabajo 7 de WELMEC y sujeto a
futuras decisiones del grupo de trabajo responsable de WELMEC, deberan aplicarse si se llevan a
Pgina 85 de 115
cabo exmenes de software basados en la presente gua para los sistemas de medida para medir de
forma continua y dinmica magnitudes de lquidos distintos del agua (controlados mediante software):
- Clase de riesgo C
10.6 Instrumentos de pesaje
Los instrumentos de pesaje se dividen en dos categoras principales:
1. Instrumentos de pesaje de funcionamiento no automtico (IPFNA) e

2. Instrumentos de pesaje de funcionamiento automtico (IPFA).
La mayora de los IPFA estn sometidos a la MID; sin embargo, los IPFNA estn sometidos todava a
la Directiva europea 90/384/CEE. Por lo tanto, la gua de software WELMEC 2.3 se aplica a los
IPFNA, mientras que la presente gua de software se aplica a los IPFA.
Los requisitos especficos de este captulo se basan en el anexo MI-006 y en los documentos
normativos mencionados en el apartado 10.6.1, que facilitan la interpretacin de los requisitos de la
MID.
Hay cinco categoras de instrumentos de pesaje de funcionamiento automtico sometidas al anexo MI-
006 de la MID:
- Seleccionadoras ponderales automticas (R 51)

- Instrumentos gravimtricos de llenado de funcionamiento automtico (R 61)
- Totalizador discontinuo (R 107)
- Totalizador continuo (cinta de pesaje) (R 50)
- Bscula puente de ferrocarril (R 106).
Los nmeros entre parntesis hacen referencia a las respectivas recomendaciones de la OIML que son
documentos normativos en el sentido de la MID. Adems, WELMEC ha publicado la gua WELMEC
2.6 que facilita los ensayos de las seleccionadoras ponderales automticas.
Hay una categora de IPFA que no est sometida a la MID.
- Instrumentos de pesaje automticos para vehculos en movimiento (R 134).
Los IPFA de todas las categoras pueden disearse como tipo P o tipo U y todas las extensiones
podran ser relevantes para cada categora.
Sin embargo, de estas seis categoras, solo los totalizadores discontinuos y los totalizadores
continuos (cintas de pesaje) se han identificado como susceptibles de necesitar requisitos de software
especficos de los instrumentos (vase 10.6.3). Esto se debe a que la medicin es acumulativa durante
un periodo de tiempo relativamente largo y no se puede repetir si aparece un fallo significativo.

Un totalizador discontinuo es una pesadora-totalizadora de tolva que determina la masa de un producto

a granel (p. ej. el grano) dividindolo en cargas discretas. El sistema normalmente consta de una o
varias tolvas apoyadas en clulas de carga, fuente de alimentacin, controles electrnicos y dispositivo
indicador.
Pgina 86 de 115
Un totalizador continuo es una cinta de pesaje que mide la masa de un producto mientras la cinta
transportadora pasa sobre una clula de carga. El sistema normalmente consta de una cinta
transportadora, rodillos, receptor de carga apoyado en clulas de carga, fuente de alimentacin,
controles electrnicos y dispositivo indicador. Habr un modo de ajustar la tensin de la cinta.
En el caso de un totalizador discontinuo el producto a granel se introduce en una tolva y se pesa. La

masa de cada carga discreta se determina secuencialmente y se suma. A continuacin, cada carga
discreta se devuelve a granel.
En el caso de un totalizador continuo, la masa se mide continuamente mientras pasa el producto por el
receptor de carga. Las mediciones se realizan en unidades discretas de tiempo que dependen de la
velocidad de la cinta y de la fuerza sobre el receptor de carga. No se produce ninguna subdivisin
deliberada del producto, ni ninguna interrupcin de la cinta transportadora como sucede con el
totalizador discontinuo. La masa total es una integracin de las muestras discretas. Hay que destacar
que el receptor de carga podra utilizar clulas de carga con galgas extensomtricas u otras tecnologas
como hilo vibrante.
10.6.2.4 Defectos
Las juntas en la cinta podran causar impacto que pueden dar lugar a errores en la puesta a cero. En el
caso de los totalizadores discontinuos, podran perderse uno o todos los resultados de pesaje de cargas
discretas antes de ser sumados.
10.6.3 Requisitos especficos de software (totalizadores continuos y discontinuos)
El anexo MI-006 de la MID, captulo IV apartado 8 y captulo V apartado 6, trata las perturbaciones
electromagnticas. Es necesario interpretar estos requisitos para los instrumentos controlados por
software porque solo se puede detectar una perturbacin (fallo) y recuperarse de la misma mediante la
accin combinada de determinadas partes del hardware y del software especfico. Desde el punto de
vista del software no importa cul sea el motivo de una perturbacin (electromagntico, elctrico,
mecnico, etc.): los procedimientos de recuperacin son los mismos.
Pgina 87 de 115

I6-1: Deteccin de fallos
El software detectar que el procesamiento normal se ha visto perturbado.
Especificaciones:
Al detectar un fallo:
a. Las mediciones acumulativas y otros datos legalmente relevantes se guardarn automticamente en
un almacenamiento no voltil (vase el requisito I6-2) y
b. la pesadora de tolva o cinta transportadora se detendr de forma automtica o se activar una alarma
visible o audible (vase la documentacin requerida).
Una breve descripcin de lo que se comprueba, qu se requiere para activar el proceso de deteccin de
fallos y cmo actuar si se detecta un fallo.
Si al detectar un fallo no es posible detener el sistema de transporte de manera automtica y sin retraso
(p. ej., debido a razones de seguridad), la documentacin incluir una descripcin de cmo tratar el
material que no se haya medido o de cmo tenerlo en cuenta debidamente.
Gua de validacin:
Se comprobar si la implementacin de la deteccin de fallos es adecuada.
Si es posible: simule determinados fallos de hardware y compruebe si el software los detecta y reacciona
ante ellos como se describe en la documentacin.
watchdog) evitando su disparo. Antes de reiniciar, la subrutina comprueba el estado del sistema, por
ejemplo, si durante el ltimo intervalo se han procesado todas las subrutinas metrolgicamente
relevantes. Si alguna funcin no se ha procesado o en el peor de los casos el microprocesador se
cuelga en un bucle infinito, este reinicio no tiene lugar y el temporizador de control se dispara al cabo del
tiempo establecido.
Pgina 88 de 115

seguridad de los datos legalmente relevantes como los valores de medicin y el estado actual del
proceso.
Especificaciones:
a. Las caractersticas de estado y los datos importantes se guardarn en un almacenamiento no voltil.
b. Este requisito normalmente implica un sistema de almacenamiento controlado que efecte copias de
seguridad automticas en caso de perturbacin. Las copias de seguridad peridicas solo se aceptarn
si no se dispone de un sistema de almacenamiento controlado debido a restricciones funcionales o de
hardware. En ese caso excepcional los intervalos de almacenamiento han de ser lo suficientemente
pequeos, es decir, la discrepancia mxima posible entre los valores actuales y los guardados ha de
estar dentro de una fraccin definida del error mximo permitido (vase la documentacin requerida).
c. Las funcionalidades de copia de seguridad deberan incluir normalmente funciones de reactivacin
adecuadas para que el sistema de pesaje, incluido su software, no entre en un estado indefinido
causado por alguna perturbacin.
Una breve descripcin del mecanismo de copias de seguridad y los datos que se copian y cundo se
realiza la copia.
Especificacin o clculo del error mximo que puede producirse para los valores acumulativos si se ha
implementado una copia de seguridad cclica (peridica).
Gua de validacin:
Se comprobar si en caso de perturbacin se guardan todos los datos legalmente relevantes .
Se comprobar, simulando una perturbacin, si el mecanismo de copias de seguridad funciona tal y como
se describe en la documentacin.
Se dispara un temporizador de control hardware (hardware watchdog) cuando no se haya reiniciado
cclicamente. Esto activa una interrupcin en el microprocesador. La rutina asignada a la interrupcin
recoge simultneamente los valores de medicin, los valores de estado y otros datos relevantes, y los
guarda en un almacenamiento no voltil como, por ejemplo, una EEPROM u otro almacenamiento
adecuado.
Nota: Se supone que la interrupcin generada por el temporizador de control tiene la prioridad de interrupcin ms
alta y domina sobre cualquier proceso normal o cualquier bucle arbitrario infinito, es decir, el control del programa
siempre salta hasta la rutina de interrupcin si se dispara el temporizador de control.
10.6.4 Ejemplos de funciones y datos legalmente relevantes
Tabla 10-1: Ejemplos de funciones legalmente relevantes especficas del dispositivo (FD), datos
legalmente relevantes especficos del dispositivo (DD) y funciones legalmente relevantes especficas
del tipo (FT), datos legalmente relevantes especficos del tipo (DT) para los IPFA en comparacin con
aquellos para los IPFNA (R 76). VV indica valores variables.
Pgina 89 de 115
Funciones/datos Tipo OIML n

50 51 51 61 76 106 107
(X) (Y)
Clculo del peso FT, DT X X X X X X X
Anlisis de estabilidad FT, DT X X X X X X
Clculo del precio FT, DT X X
Algoritmo de redondeo del precio FT, DT X X
Intervalo (sensibilidad) DD X X X X X X X
Correcciones debidas a la falta de DD (DT) X X X X X X X
linealidad
Mx., mn., e, d DD (DT) X X X X X X X
Unidades de medida (p. ej. g, kg) DD (DT) X X X X X X X
Valor del peso como se indica VV X X X X X
(redondeado a mltiplos de e o d)
Tara, tara predeterminada VV X X X X X
Precio unitario, precio a pagar VV X X X
Valor del peso en resolucin interna VV X X X X X X X
Seales de estado (p. ej. indicacin de FT X X X X X X X
cero, estabilidad del equilibrio)
Comparacin entre el peso real y el FT X X
valor preestablecido
Impresin automtica (p. ej. En la FT X X
interrupcin del funcionamiento
automtico)
Tiempo de calentamiento FT (DT) X X X X X X X
Interbloqueo entre funciones FT X X
p. ej. puesta cero/tara X X X X
operacin automtica/no automtica X
puesta a cero/totalizacin X X
Registro del acceso al ajuste dinmico FT (VV) X X
Valor mximo de DD (DT) X X X X X X
funcionamiento/intervalo de velocidad
de funcionamiento (pesaje dinmico)
Parmetros (del producto) para el VV X X X
clculo dinmico del peso
Amplitud del intervalo de ajuste DD (DT) X X
Criterio para la puesta a cero DD (DT) X X X X X
automtica (p. ej. intervalo de tiempo,
fin del ciclo de pesaje)
Descarga mnima, valor mnimo de DD X X
carga
Valor lmite de fallo significativo (si es DD (DT) X X
distinto de 1 e 1 d)
Valor lmite de la tensin de la batera DD (DT) X X X X X X
Tabla 10-1: Ejemplos de funciones y datos legalmente relevantes especficos del dispositivo y del
modelo.
Pgina 90 de 115
Es probable que las funciones y los parmetros marcados en la tabla anterior estn presentes en los
distintos tipos de instrumentos de pesaje. Si alguno de ellos est presente, deber tratarse como
legalmente relevante. Sin embargo, la tabla no es una lista obligatoria que indique que cada funcin
o parmetro de los mencionados deba estar presente en cada instrumento.
Ninguno
Hasta ahora, segn las decisiones del grupo de trabajo responsable de WELMEC (24 reunin del
grupo de trabajo n 2, 22-23 de enero de 2004), se aplicar en general la clase de riego B a todas las
categoras de IPFA independientemente del tipo (P o U).
Sin embargo, como consecuencia del cuestionario del grupo de trabajo n 7 (2004), se considera
adecuada la siguiente diferenciacin con respecto a los instrumentos de tipo P y U y a los instrumentos
totalizadores continuos y discontinuos y dicha diferenciacin se discutir de nuevo en el grupo de
trabajo n 2 de WELMEC (decisin de la 25 reunin del grupo de trabajo n 2, 14-15 de octubre de
2004):
- Clase de riesgo B para instrumentos de tipo P (excepto los totalizadores)

- Clase de riesgo C para instrumentos de tipo U y totalizadores de tipo P y tipo U
10.7 Taxmetros
Los taxmetros estn sometidos a la regulacin de la MID. Los requisitos especficos se encuentran en
el anexo MI-007. An no se han tenido en cuenta ni estos requisitos especficos ni los documentos
normativos.
10.7.1 Reglamentos especficos, normas y documentos normativos
An no se ha considerado la norma europea EN50148 que podra convertirse en un documento

normativo en el sentido de la MID. Existe una publicacin de un documento orientativo sobre
taxmetros como consecuencia del proyecto sobre procedimientos de la MID. En el futuro, este
documento constituir la base de una gua WELMEC. Existe tambin un primer borrador de
recomendacin de la OIML sobre taxmetros. Sin embargo, el documento de la OIML no se encuentra
en una fase en la que pueda utilizar como documento normativo (situacin de octubre de 2004).
Un taxmetro, segn se define en la MID, mide el tiempo, la distancia (usando la salida de un

generador de seales de distancia que no est cubierto por la MID) y calcula el importe de un viaje
segn las tarifas aplicables.
Los taxmetros actuales utilizan una arquitectura integrada, lo que significa que los taxmetros son
instrumentos desarrollados especficamente (tipo P) en segn esta gua. En el futuro, se espera que los
taxmetros tambin se fabriquen utilizando ordenadores universales (tipo U).
10.7.3 Requisitos especficos de software
Anexo MI-007, 9 de la MID:
Pgina 91 de 115
En caso de disminucin del suministro de tensin hasta un valor inferior al lmite mnimo de
funcionamiento especificado por el fabricante, el taxmetro deber:
- seguir funcionando correctamente o reanudar su funcionamiento correcto sin prdida de los

datos de que se dispona antes de la bajada de corriente si la interrupcin de corriente es
temporal, por ejemplo debido a que se ha vuelto a poner en marcha el motor;
- interrumpir la medicin existente y volver a la posicin "Libre" si la interrupcin de
corriente es durante un perodo ms largo.
Los taxmetros tambin necesitan disponer de un almacenamiento a largo plazo; los datos han de estar
disponibles en el taxmetro durante al menos un ao (vase MI-007, 15.2).

Existir una funcionalidad que realizar copias de seguridad de los datos esenciales de forma
automtica como, por ejemplo, los valores de medida y el estado actual del proceso si la tensin
disminuye durante un perodo de tiempo mayor.
Especificaciones:
1) Normalmente, estos datos deberan guardarse en un almacenamiento no voltil.
2) Se considera necesario un detector del nivel de tensin para detectar cundo almacenar valores de
medicin.
3) Las funcionalidades de copia de seguridad incluirn funcionalidades de reactivacin adecuadas para
que el taxmetro, incluido su software, no entre en un estado indefinido.
copia.
Gua de validacin:

El detector del nivel de tensin dispara una interrupcin cuando el nivel de tensin desciende durante
15 s. La rutina de interrupcin asignada recopila los valores de medicin, los valores de estado y otros
datos relevantes, y los guarda en un almacenamiento no voltil como, por ejemplo, una EEPROM.
Cuando el nivel de tensin aumenta de nuevo, los datos se restauran y el funcionamiento contina o se
detiene (vase MI-007, 9).
Nota: Se supone que la interrupcin generada por el nivel de tensin tiene una prioridad de interrupcin alta y
domina sobre cualquier proceso normal o cualquier bucle arbitrario infinito, es decir, el control del programa
siempre salta hasta la rutina de interrupcin si cae la tensin.
10.7.4 Ejemplos de funciones y datos legalmente relevantes
A continuacin, se proporcionan algunos parmetros tpicos de los taxmetros.

Factor k X Impulsos por km
Tarifas X X Unidad monetaria/km, unidad monetaria/h.
Parmetros de la interfaz X Velocidad de transmisin en baudios, etc.

Pgina 92 de 115
Se recomienda la revisin de la Directiva relativa a la homologacin de vehculos o que se lleve a cabo

cualquier otra regulacin que especifique los requisitos de los generadores de seales de distancia de
los vehculos utilizados como taxis. Una propuesta preliminar establece:
Para los vehculos que se van a utilizar como taxis, se aplicarn los siguientes requisitos:
1. El generador de seales de distancia proporcionar una seal con una resolucin de al menos
2 m.
2. El generador de seales de distancia proporcionar una seal estable a cualquier velocidad del
vehculo.
3. El generador de seales de distancia tendr caractersticas definidas en lo que se refiere al nivel
de tensin, la amplitud de pulsos y la relacin entre velocidad y frecuencia.
4. Facilidad de ensayo
Hasta ahora, y segn los resultados del cuestionario de 2004 del grupo de trabajo 7 de WELMEC y
sujeto a futuras decisiones del grupo de trabajo de WELMEC responsable, deberan aplicarse las
siguientes clases de riesgo si se llevan a cabo exmenes de software basados en la presente gua para
los taxmetros (controlados por software):

- Clase de riesgo D para instrumentos de tipo U
10.8 Medidas materializadas
Las medidas materializadas estn sometidas a las regulaciones de la MID. Los requisitos especficos se
encuentran en el anexo MI-008.
Sujeto a futuros desarrollos y decisiones, las medidas materializadas en el sentido del anexo MI-008 de
la MID no se consideran instrumentos de medida controlados por software.
Por lo tanto, por ahora, la presente gua de software no se aplica a medidas materializadas.
10.9 Instrumentos para medidas dimensionales
Los instrumentos para medidas dimensionales estn sometidos a las regulaciones de la MID. Los
requisitos especficos se encuentran en el anexo MI-009. An no se han tenido en cuenta ni estos
requisitos especficos ni los documentos normativos.
Los apartados 10.9.110.9.5 se completarn en el futuro si se considera necesario.
instrumentos para medidas dimensionales (controlados por software):
- Clase de riesgo B para instrumentos de tipo P

- Clase de riesgo C para instrumentos de tipo U
Pgina 93 de 115
10.10 Analizadores de gases de escape
Los analizadores de gases de escape estn sometidos a las regulaciones de la MID. Los requisitos
especficos se encuentran en el anexo MI-010. An no se han tenido en cuenta ni estos requisitos
especficos ni los documentos normativos.
Los apartados 10.10.110.10.5 se completarn en el futuro si se considera necesario.
analizadores de gases de escape (controlados por software):
- Clase de riesgo B para instrumentos de tipo P

- Clase de riesgo C para instrumentos de tipo U
11 Definicin de las clases de riesgo

11.1 Principio general
Los requisitos de esta gua se distinguen segn las clases de riesgo (software). Los riesgos se refieren
exclusivamente al software del instrumento de medida y a ningn otro riesgo. Por comodidad, se
utiliza el trmino abreviado clase de riesgo. A cada instrumento de medida se le debe asignar una
clase de riesgo porque los requisitos del software que hay que aplicar estn determinados por la clase
de riesgo a la que pertenece el instrumento. Una clase de riesgo se define como la combinacin de los
niveles adecuados requeridos de proteccin, examen y conformidad del software. Se presentan tres
niveles para cada una de estas categoras: bajo, medio y alto.
11.2 Descripcin de los niveles de proteccin, examen y conformidad
Las siguientes definiciones se utilizan para los niveles correspondientes.
Niveles de proteccin del software
Bajo: No se requieren medidas de proteccin concretas frente a los cambios intencionados.

Medio: El software est protegido frente a los cambios intencionados realizados utilizando
herramientas software simples, comunes y fcilmente disponibles (por ej.: editores de texto).
Alto: El software est protegido frente a cambios intencionados realizados utilizando herramientas
software sofisticadas (por ej.: depuradores y editores de disco duro, herramientas de
desarrollo de software, etc.).
Niveles de examen del software
Bajo: Se realizan las comprobaciones funcionales estndar de examen de modelo del instrumento.
No es necesario realizar pruebas de software adicionales.
Medio: Adems de las comprobaciones correspondientes al nivel bajo, el software se examina segn
su documentacin. La documentacin incluye la descripcin de las funciones implementadas
por software, la descripcin de los parmetros, etc. Para verificar la fiabilidad de la
documentacin y la eficacia de las medidas de proteccin, pueden realizarse comprobaciones
prcticas aleatorias de las funciones compatibles con el software.
Pgina 94 de 115
Alto: Adems de las comprobaciones correspondientes al nivel medio, se lleva a cabo una
comprobacin del software en profundidad, que suele basarse en el cdigo fuente.
Niveles de conformidad del software
Bajo: La funcionalidad del software implementado en cada uno de los instrumentos individuales es
conforme con la documentacin aprobada.
Medio: Adems de la conformidad del nivel bajo, en funcin de las caractersticas tcnicas, partes
del software se definirn como fijas en el examen de modelo, es decir, modificables
solamente con la aprobacin previa del organismo notificado. La parte fija ser idntica en
cada uno de los instrumentos individuales.
Alto: El software implementado en cada uno de los instrumentos individuales es completamente
idntico al aprobado.
11.3 Asignacin de las clases de riesgo
De las 27 permutaciones de nivel tericamente posibles, solo cuatro o, a lo sumo cinco, tienen inters
prctico (clases de riesgo B, C, D y E, eventualmente F). Abarcan todas las clases de instrumentos que
estn incluidas en la regulacin de la MID. Adems, proporcionan suficiente rango en caso de que se
modifiquen las evaluaciones de riesgo. En la tabla siguiente se definen las clases de riesgo.
Grado de
Clase de Proteccin del Examen del
conformidad
riesgo software software
del software
A bajo bajo bajo
B medio medio bajo
C medio medio medio
D alto medio medio
E alto alto medio
F alto alto alto
Tabla 11-1: Definicin de las clases de riesgo
11.4 Interpretacin de las clases de riesgo
Clase de riesgo A: Es la clase de riesgo ms baja de todas. No se requieren medidas de proteccin

concretas frente a los cambios intencionados del software. El examen de software
forma parte de la comprobacin funcional del dispositivo. Se requiere conformidad a
nivel documental. No es de esperar que ningn instrumento se clasifique con una clase
de riesgo A. Sin embargo, al introducir esta clase, se mantiene abierta esta posibilidad.
Clase de riesgo B: En comparacin con la clase de riesgo A, se requiere una proteccin de software
de nivel medio. En consecuencia, el nivel de examen aumenta al nivel medio. La
conformidad es la misma que la de la clase de riesgo A.
Clase de riesgo C: En comparacin con la clase de riesgo B, la conformidad aumenta hasta el nivel
medio. Esto significa que partes del software pueden declararse como fijas en el
examen de modelo. El resto del software requiere conformidad en el nivel funcional.
Los niveles de proteccin y examen son los mismos que en la clase de riesgo B.
Clase de riesgo D: Si se compara con la clase de riesgo C, la proteccin aumenta hasta el nivel alto.
Puesto que el examen se mantiene invariable en el nivel medio, debe proporcionarse
documentacin suficientemente informativa para demostrar que las medidas de
Pgina 95 de 115
proteccin tomadas son adecuadas. El nivel de conformidad es el mismo que en la clase

de riesgo C.
Clase de riesgo E: En comparacin con la clase de riesgo D, el examen aumenta hasta el nivel alto.
Los niveles de proteccin y conformidad no cambian.
Clase de riesgo F: Todos los aspectos (proteccin, examen y conformidad) se establecen en el nivel
alto. Al igual que en la clase de riesgo A, no es de esperar que ningn instrumento se
clasifique en esta clase. Sin embargo se mantiene abierta esta posibilidad.
12 Modelo del informe de ensayos (incluidas las listas de comprobacin)
Este es un modelo de un informe de ensayo, que consta de una parte principal y dos anexos. La parte
principal contiene informacin general del objeto a ensayar. En la prctica debe adaptarse segn
corresponda. El anexo 1 consta de dos listas de comprobacin que facilitan la seleccin de las partes
de la gua que deben aplicarse. El anexo 2 consta de listas de comprobacin especficas de las
respectivas partes tcnicas de la gua. Estos anexos son recomendables para ayudar a que el fabricante
y examinador comprueben que han tenido en cuenta todos los requisitos aplicables.
Adems del modelo de informe de ensayo y de las listas de comprobacin, se incluye la informacin
necesaria para el certificado de examen de modelo en el ltimo subapartado de este captulo.
Pgina 96 de 115
12.1 Modelo de la parte general del informe de ensayos
Informe de ensayo n. XYZ122344
Modelo de caudalmetro Dynaflow DF101
Validacin del software
(n anexos)
Comisin
La MID proporciona los requisitos esenciales para determinados instrumentos de medida que
utilizados en la Unin Europea. El software del instrumento de medida se ha validado para demostrar
su conformidad con los requisitos esenciales de la MID.
La validacin se ha basado en el informe de WELMEC sobre los requisitos de software de la MID

(gua WELMEC 7.2), donde se interpretan y explican los requisitos esenciales de software. Este
informe describe el examen de software necesario para establecer la conformidad con la MID.
Cliente
Dynaflow
P.O. Box 1120333
100 Reykiavik
Islandia
Referencia: Sr. Bjarnur Sigfridson
Objeto del ensayo
El caudalmetro Dynaflow DF100 es un instrumento de medida para medir caudal de lquidos.
El rango de medida oscila entre 1 l/s y 2.000 l/s. Las funciones bsicas del instrumento son:
- medida del caudal de lquidos,

- indicacin del volumen medido,
- interfaz del transductor.
Segn la gua WELMEC 7.2, el caudalmetro se describe del siguiente modo:
- instrumento de medida desarrollado especficamente (sistema embebido),

- almacenamiento a largo plazo de datos legalmente relevantes.
El caudalmetro DF100 es un instrumento independiente con un transductor conectado. El transductor

est fijado al instrumento y no puede desconectarse. El volumen medido se indica en una pantalla. No
es posible establecer comunicacin con otros dispositivos.
El software integrado en el instrumento de medida ha sido desarrollado por:
Dynaflow, P.O. Box 1120333, 100 Reykiavik, Islandia
Pgina 97 de 115
La versin del software validado es V1.2.c. El cdigo fuente consta de los siguientes archivos:
main.c 12.301 bytes 23 nov 2007

int.c 6.509 bytes 23 nov 2003
filter.c 10.897 bytes 20 oct 2003
input.c 2.004 bytes 20 oct 2003
display.c 32.000 bytes 23 nov 2003
Ethernet.c 23.455 bytes 15 jun 2002
driver.c 11.670 bytes 15 jun 2002
calculate.c 6.788 bytes 23 nov 2003
La validacin se ha basado en los siguientes documentos del fabricante:
- Manual de usuario del DF100,

- Manual de mantenimiento del DF100,
- Descripcin del software del DF100 (documento de diseo interno, con fecha de 22 de noviembre
de 2003).
- Diagrama del circuito electrnico del DF100 (dibujo n 222-31, con fecha de 5 de octubre de
2003)
La versin definitiva del objeto de ensayo se entreg al Laboratorio National Testing &
Measurement el 25 de noviembre de 2003.
Procedimiento de examen
La validacin se ha realizado segn la gua de software WELMEC 7.2, edicin 1 (que se puede
descargar de www.welmec.org).
La validacin se realiz ente el 1 de noviembre y el 23 de diciembre de 2003. El 3 de diciembre, el Dr.

K. Fehler realiz, en la sede central de Dynaflow en Reykiavik, una revisin del diseo. El Dr. K.
Fehler y M. S. Problme llevaron a cabo otros trabajos de validacin en el laboratorio National Testing
& Measurement .
Se han validado los siguientes requisitos:
- requisitos especficos del instrumento de medida desarrollado especficamente (tipo P);

- extensin L: - almacenamiento a largo plazo de datos legalmente relevantes.
La lista de comprobacin para la seleccin de configuracin se encuentra en el anexo 1 de este

informe.
A este instrumento se le ha aplicado la clase de riesgo C.
Los mtodos de validacin aplicados son los siguientes:
- identificacin del software,

- completitud de toda la documentacin,
- examen del manual de funcionamiento,
- comprobacin funcional,
- revisin del diseo del software,
- revisin de la documentacin del software,
- anlisis del flujo de datos,
- simulacin de las seales de entrada.
Pgina 98 de 115
Resultado
Se han validado sin encontrar fallos los siguientes requisitos de la gua de software WELMEC 7.2:
- P1, P2, P3, P5, P6, P7 (El requisito P4 no se considera aplicable.)

- L1, L2, L3, L4, L5, L6, L7
La lista de comprobacin de los requisitos P figura en el anexo 2.1 de este informe.
La lista de comprobacin de los requisitos L figura en el anexo 2.2 de este informe.
Se encontraron dos comandos que no se haban descrito inicialmente en el manual del operador.
Ambos comandos se han incluido en el manual del operador actualizado al 10 de diciembre de 2003.
Se encontr un fallo de software que limitaba el mes de febrero a 28 das tambin en los aos bisiestos
en el paquete de software V1.2b. Este fallo se ha corregido en el paquete V1.2c.
El software de Dynaflow DF100 V1.2c cumple los requisitos esenciales de la MID.
El resultado solo se aplica al objeto ensayado.
National Testing & Measurement Lab

Departamento de Software
Dr. K.E.I.N. Fehler

Director tcnico
M. S. A. N. S. Problme
Tcnico
Fecha: 23 de diciembre de 2003
Pgina 99 de 115
12.2 Anexo 1 del informe de ensayos: Listas de comprobacin que facilitan la seleccin del
conjunto de requisitos adecuado
La primera lista de comprobacin ayuda al usuario a decidir qu configuracin bsica P o U se aplica
al instrumento que se est comprobando.
Decisin sobre el tipo de instrumento
(P) Comentarios
Toda la aplicacin software se ha desarrollado con el (S)

1
propsito especfico de la medicin?
En caso de que haya software de propsito general, es
2
accesible o visible para el usuario? (N)
Se impide al usuario acceder al sistema operativo en caso (S)
3 de que sea posible cambiar a un modo operativo que no
est sometido a control legal?
Son invariables los programas implementados y el
4
entorno de software (aparte de las actualizaciones)? (S)
Hay alguna manera de programarlo? (N)
5
Marque la casilla que corresponda
Si y solo si todas las respuestas a las cinco preguntas anteriores estn en la columna P, se aplicarn los
requisitos del apartado P (captulo 4). En los dems casos, se aplicarn los requisitos del apartado U
(captulo 5).
La segunda lista de comprobacin ayuda a decidir qu configuracin TI se aplica al instrumento bajo
ensayo.
Decisin sobre las extensiones requeridas
Comentarios
No aplicable
Extensin
requerida
NO
S
Tiene el dispositivo la posibilidad de almacenar los datos

L de medicin en un almacenamiento integrado o en un
almacenamiento remoto o extrable?
Posee el dispositivo interfaces para la transmisin de
T datos a dispositivos sometidos a control legal o recibe
datos de otro dispositivo sometido a control legal?
Hay partes del software con funciones que no estn
S sometidas a control legal y se desea cambiarlas tras el
examen de modelo?
D Es posible o deseable cargar software?
Considere la extensin requerida para cada una de las respuestas afirmativa.
Pgina 100 de 115

12.3 Anexo 2 del informe de ensayos: Listas de comprobacin especficas de las respectivas
partes tcnicas
1) Lista de comprobacin de los requisitos bsicos para instrumentos tipo P
Lista de comprobacin de los requisitos de tipo P
Procedimientos
No aplicable
Rechazado
de ensayo
Requisito
Aceptado
Comentarios*
La documentacin requerida del fabricante cumple el

P1
requisito P1 (a-f)?
La identificacin del software se ha implementado segn
P2
se requiere en P2?
Se impide que los comandos introducidos a travs de la
P3 interfaz de usuario influyan de manera inadmisible en el
software legalmente relevante y en los datos de medida?
Se impide que los comandos introducidos a travs de
interfaces de comunicacin no protegidas del instrumento
P4
influyan de manera inadmisible en el software legalmente
relevante y en los datos de medida?
El software legalmente relevante y los datos de medida
P5 estn protegidos frente a cambios accidentales o no
intencionados?
El software legalmente relevante est protegido frente a
P6 modificaciones, cargas o intercambios (swapping)
inadmisibles de la memoria hardware?
Los parmetros que fijan las caractersticas legalmente
P7 relevantes de los instrumentos de medida estn protegidos
frente a modificaciones no autorizadas?
* Debern aadirse aclaraciones si hay desviaciones a los requisitos de software.
Pgina 101 de 115

2) Lista de comprobacin de los requisitos bsicos para instrumentos tipo U

Lista de comprobacin de los requisitos de tipo U
Procedimientos
Rechazado
de ensayo
Requisito
Aceptado
No aplicable
Comentarios*
La documentacin requerida del fabricante cumple el requisito

U1
U1 (a-g)?
La identificacin del software se ha implementado segn se
U2
requiere en U2?
Se impide que los comandos introducidos a travs de la
U3 interfaz de usuario influyan de forma inadmisible en el software
legalmente relevante y en los datos de medida?
Se impide que los comandos introducidos a travs de
interfaces de comunicacin no protegidas del instrumento
U4
influyan de forma inadmisible en el software legalmente
relevante y en los datos de medida?
El software legalmente relevante y los datos de medida estn
U5
protegidos frente a cambios accidentales o no intencionados?
El software legalmente relevante est protegido frente a
U6
modificaciones inadmisibles?
Los parmetros legalmente relevantes estn protegidos frente a
U7
modificaciones no autorizadas?
Se han utilizado medios para garantizar la autenticidad del
U8 software legalmente relevante y se garantiza la autenticidad de
los resultados que se presentan?
El software legalmente relevante est diseado de tal manera
U9
que otro software no influya en l de modo inadmisible?
* Debern aadirse aclaraciones si hay desviaciones a los requisitos de software.
Pgina 102 de 115

3) Lista de comprobacin de los requisitos especficos de la extensin L

Lista de comprobacin de los requisitos de la extensin L
Procedimientos
No aplicable
Rechazado
de ensayo
Requisito
Aceptado
Comentarios*
Los datos de medida almacenados contienen toda la

L1 informacin relevante necesaria para reconstruir una
medicin anterior?
Los datos almacenados estn protegidos frente a cambios
L2
accidentales o no intencionados?
Los datos de medida almacenados estn protegidos frente a
cambios intencionados llevados acabo con herramientas de
L3 software comunes y simples (para las clases de riesgo B y
C) o herramientas de software sofisticadas especiales (para
las clases de riesgo D y E)?
Es posible rastrear fielmente los datos de medida
L4
almacenados hasta la medicin que los gener?
(B y C) Se tratan las claves como datos legalmente
relevantes y se mantienen en secreto y protegidas frente a
los posibles riesgos originados por herramientas de
software simples?
L5 (D y E) Se tratan las claves y los datos que estas incluyen
como datos legalmente relevantes y se mantienen en secreto
y protegidos frente a posibles riesgos originados por
herramientas de software sofisticadas? Se usan mtodos
apropiados equivalentes a los usados en el pago
electrnico? Puede el usuario verificar la autenticidad de la
clave pblica?
El software utilizado para verificar los datos de medida
almacenados visualiza o imprime informacin, comprueba
L6 los datos en busca de cambios y avisa de las modificaciones
realizadas? Existen medios para evitar que se utilicen los
datos corruptos detectados?
Los datos de medida se almacenan automticamente
L7
cuando finaliza la medicin?
El almacenamiento a largo plazo tiene capacidad suficiente
L8
para el propsito deseado?
* Debern aadirse aclaraciones si hay desviaciones de los requisitos de software.
Pgina 103 de 115

4) Lista de comprobacin de los requisitos especficos de la extensin T

Lista de comprobacin de los requisitos de la extensin T
Procedimientos
No aplicable
Rechazado
de ensayo
Requisito
Aceptado
Comentarios*
Los datos transmitidos contienen toda la informacin

relevante necesaria para presentar o procesar
T1
posteriormente el resultado de medida en el mdulo
receptor?
Los datos transmitidos estn protegidos frente a
T2
cambios accidentales o no intencionados?
Los datos legalmente relevantes que se transmiten
estn protegidos frente a cambios intencionados
llevados a cabo mediante herramientas de software
T3
comunes y simples (para las clases de riesgo B y C) o
mediante herramientas de software sofisticadas
especiales (para las clases de riesgo D y E)?
Puede el programa que recibe los datos relevantes
T4 transmitidos verificar su autenticidad y asignar los
valores de medida a una medicin determinada?
B y C) Se tratan las claves como datos legalmente
relevantes y se mantienen en secreto y protegidas
frente a los posibles riesgos originados por
herramientas de software simples?
T5 D y E) Se tratan las claves y los datos que estas
incluyen como datos legalmente relevantes y se
mantienen en secreto y protegidos frente a posibles
riesgos originados por herramientas de software
sofisticadas? Se usan mtodos apropiados
equivalentes a los usados en el pago electrnico?
Puede el usuario verificar la autenticidad de la clave
pblica?
Se impide el uso de los datos que han sido detectados
T6
como corruptos?
Se garantiza que la medida no est influida de modo
T7
inadmisible por una demora en la transmisin?
Se garantiza que no se perdern los datos de medicin
T8
si los servicios de red dejan de estar disponibles?
Pgina 104 de 115

5) Lista de comprobacin de los requisitos especficos de la extensin S
Lista de comprobacin de los requisitos de la extensin S

Procedimientos
No aplicable
Rechazado
de ensayo
Requisito
Aceptado
Comentarios*
El software sometido a control legal contiene todo el

S1
software y los parmetros legalmente relevantes?
Se garantiza que la informacin adicional generada
por la parte de software legalmente no relevante que
S2 aparezca en pantalla o impresa no se confunde con la
informacin que se origina en la parte legalmente
relevante?
El intercambio de datos entre el software legalmente
relevante y el software legalmente no relevante se
S3 realiza mediante una interfaz de software protectora,
que incluye el control de las interacciones y el flujo
de datos?
6) Lista de comprobacin de los requisitos especficos de la extensin D
Lista de comprobacin de los requisitos de la extensin D

Procedimientos
Rechazado
de ensayo
Requisito
Aceptado
No aplicable
Comentarios*
La descarga y posterior instalacin del software

son automticas? Se garantiza que el entorno de
D1
proteccin del software se encuentre en el nivel
aprobado al terminar la descarga e instalacin?
Se han utilizado medios para garantizar que la
descarga de software es autntica y para indicar que
D2
el software descargado lo ha aprobado un organismo
notificado?
Se han utilizado medios para garantizar que el
D3 software descargado no ha sido modificado de
forma inadmisible durante dicho proceso?
Se garantiza mediante los medios tcnicos
adecuados que las descargas de software legalmente
D4
relevante puedan rastrearse adecuadamente dentro
del instrumento para realizar controles posteriores?
Pgina 105 de 115

12.4 Informacin que debe incluirse en el certificado de examen de modelo
Aunque el informe de ensayos completo es una documentacin del equipo sometido a ensayo, de la
validacin realizada y de los resultados, solo se requiere una seleccin determinada de la informacin
incluida en el informe de ensayos para el certificado de examen de modelo. La siguiente informacin
deber incluirse adecuadamente en el certificado de examen de modelo:
Referencia a la documentacin presentada para el examen de modelo

Identificacin y descripcin de los componentes (subconjuntos, mdulos) electrnicos (hardware)
que son importantes para el software/funciones TI de los instrumentos de medida
Descripcin general del entorno software necesario para utilizar el software bajo examen
Descripcin general de los mdulos de software bajo control legal (incluida la separacin de
software, si se ha implementado)
Descripcin general e identificacin de las interfaces de hardware y software (si es relevante) que
son importantes para el software/funciones TI del instrumento de medida (incluidos infrarrojos,
Bluetooth, LAN inalmbrica...)
Identificacin y descripcin de las ubicaciones de los componentes software en el instrumento de
medida (es decir, EPROM, procesador, disco duro) que deben precintarse o protegerse
Instrucciones de cmo comprobar la identificacin del software (para la supervisin metrolgica)
En caso de precinto electrnico: instrucciones para la inspeccin de los registros de actividades.
13 Referencias cruzadas entre los requisitos de software de la MID y los artculos y anexos de la
MID
(Versin de la MID utilizada: Directiva 2004/22/EC del 31 de marzo de 2004)
13.1 Referencias a la MID para cada requisito de software
Requisito MID
N. Descripcin N. de artculo/anexo Descripcin
(AI = Anexo I)
Gua bsica P
AI-9.3 Informacin que deber figurar en el
instrumento y acompaarlo
P1 Documentacin del fabricante
AI-12 Evaluacin de la conformidad
Artculo 10 Documentacin tcnica
AI-7.6 Aptitud
P2 Identificacin del software
AI-8.3 Proteccin frente a la corrupcin
Influencia a travs de la interfaz
P3 AI-7.1 Aptitud
de usuario
Influencia a travs de la interfaz AI-7.1 Aptitud
P4
de comunicacin AI-8.1 Proteccin frente a la corrupcin
Proteccin frente a los cambios AI-7.1, AI-7.2 Aptitud
P5
accidentales o no intencionados AI-8.4 Proteccin frente a la corrupcin
Aptitud
Nota: En lo que se refiere al contenido, el
apartado 7.1 de la Directiva relativa a los
Proteccin frente a los cambios AI-7.1
P6 instrumentos de medida Anexo I no es un
intencionados AI-8.2, AI-8.3, AI-8.4 problema de aptitud si no de proteccin
frente a la corrupcin (prrafo 8)
Proteccin frente a la corrupcin
P7 Proteccin de parmetros AI-7.1 Aptitud
Pgina 106 de 115

Requisito MID
N. Descripcin N. de artculo/anexo Descripcin
(AI = Anexo I)
AI-8.2, AI-8.3, AI-8.4 Proteccin frente a la corrupcin
Gua bsica U
AI-9.3 Informacin que deber figurar en el
instrumento y acompaarlo
U1 Documentacin del fabricante
Artculo 10 Documentacin tcnica
AI-7.6 Aptitud
U2 Identificacin del software
Influencia a travs de las
U3 AI-7.1 Aptitud
interfaces de usuario
Influencia a travs de la interfaz
AI-7.1 Aptitud
U4
de comunicacin AI-8.1 Proteccin frente a la corrupcin
Proteccin frente a los cambiosAI-7.1, AI-7.2 Aptitud
U5
accidentales o no intencionadosAI-8.4 Proteccin frente a la corrupcin
Proteccin frente a los cambiosAI-7.1 Aptitud
U6
intencionados AI-8.2, AI-8.3, AI-8.4 Proteccin frente a la corrupcin
AI-7.1 Aptitud
U7 Proteccin de parmetros
AI-8.2, AI-8.3, AI-8.4 Proteccin frente a la corrupcin
AI-7.1, AI-7.2, AI-7.6 Aptitud
Autenticidad del software y
U8 AI-8.3 Proteccin frente a la corrupcin
presentacin de los resultados
AI-10.2, AI-10.3, AI-10.4 Indicacin del resultado
U9 Influencia de otro software AI-7.6 Aptitud
Extensin L
AI-7.1 Aptitud
Completitud de los datos
L1 AI-8.4 Proteccin frente a la corrupcin
almacenados
AI-10.2 Indicacin del resultado
L2
accidentales o no intencionados AI-8.4 Proteccin frente a la corrupcin
AI-7.1 Aptitud
L3 Integridad de los datos
AI-7.1 Aptitud
Autenticidad de los datos
L4 AI-8.4 Proteccin frente a la corrupcin
almacenados
AI-7.1 Aptitud
L5 Confidencialidad de las claves
Recuperacin de los datos AI-7.2 Aptitud
L6
almacenados AI-10.2, AI-10.3, AI-10.4 Indicacin del resultado
AI-7.1 Aptitud
L7 Almacenamiento automtico
Capacidad y continuidad de
L8 AI-7.1 Aptitud
almacenamiento
Otros procesamientos de datos para
Lx Todas las extensiones L AI-11.1
concluir la transaccin comercial
Pgina 107 de 115

Extensin T
Completitud de los datos AI-7.1 Aptitud
T1
transmitidos AI-8.4 Proteccin frente a la corrupcin
T2
accidentales AI-8.4 Proteccin frente a la corrupcin
AI-7.1 Aptitud
T3 Integridad de los datos
Autenticidad de los datos AI-7.1 Aptitud
T4
transmitidos AI-8.4 Proteccin frente a la corrupcin
AI-7.1 Aptitud
T5 Confidencialidad de las claves
AI-7.1 Aptitud
T6 Gestin de los datos corruptos
AI-7.1 Aptitud
T7 Demora en la transmisin
Disponibilidad de los servicios AI-7.1 Aptitud
T8
de transmisin AI-8.4 Proteccin frente a la corrupcin
Extensin S
Realizacin de la separacin de AI-7.6 Aptitud
S1
software AI-10.1 Indicacin del resultado
AI-7.1, AI-7.2, AI-7.6 Aptitud
S2 Indicacin mixta
Interfaz protectora del software
S3 AI-7.6 Aptitud
Extensin D
D1 Mecanismo de descarga AI-8.2, AI-8.4 Proteccin frente a la corrupcin
AI-7.6 Aptitud
Autenticacin del software
D2 AI-8.3, AI-8.4 Proteccin frente a la corrupcin
descargado
Integridad del software AI-7.1 Aptitud
D3
descargado AI-8.4 Proteccin frente a la corrupcin
AI-7.1, AI-7.6 Aptitud
Trazabilidad de la descarga del
D4 AI-8.2, AI-8.3 Proteccin frente a la corrupcin
software legalmente relevante
Pgina 108 de 115

Extensin I
(requisitos de software
especficos del instrumento)
I1-1,
AI-6 Fiabilidad
I2-1,
Deteccin de fallos MI-001-7.1, MI-002-3.1, Requisitos especficos para
I3-1,
MI-003-4.3.1, MI-004-4 medidores de suministros pblicos
I4-1
I1-2,
Funcionalidades para la AI-6 Fiabilidad
I2-2,
generacin de copias de MI-001-7.1, MI-002-3.1, Requisitos especficos para
I3-2,
seguridad MI-003-4.3.1, MI-004-4 medidores de suministros pblicos
I4-2
I1-3,
Funcionalidades de restauracin AI-6 Fiabilidad
I2-3,
y reactivacin MI-001-7.1, MI-002-3.1, Requisitos especficos para
I3-3,
MI-003-4.3.1, MI-004-4 medidores de suministros pblicos
I4-3
I1-4,
I2-4, Requisitos especficos para
Resolucin interna MI-002-5.3, MI-003-5.2
I3-4, medidores de suministros pblicos
I4-4
I1-5,
I2-5, Evitar la puesta a cero de los
I3-5, valores de medida acumulativos
I4-5
I1-6,
I2-6, AI-7.2 Aptitud
Indicacin para el cliente
I3-6, AI-10.5 Indicacin del resultado
I4-6
Solucin aceptable para
Requisitos especficos de los
I2-7 controlar el periodo de vida de MI-002-5.2
contadores de gas
una batera
Solucin aceptable para
I2-8 controlar los convertidores del MI-002-9.1
contadores de gas
volumen de un gas
I2-9 Elemento de ensayo. MI-002-5.5
contadores de gas
Totalizadores continuos y
I6-1 Deteccin de fallos MI-006-IV, MI-006-V
discontinuos
Funcionalidades para la
Totalizadores continuos y
I6-2 generacin de copias de MI-006-IV, MI-006-V
discontinuos
seguridad
Pgina 109 de 115

13.2 Interpretacin de los artculos y anexos de la MID segn los requisitos del software
MID Gua de software

N. de
artculo/anexo Descripcin Comentario N. de requisito
(AI = Anexo I)
Parte del artculo
1, 2, 3 Irrelevante para el software
Transmisin de informacin legalmente T
Definiciones, disposicin de
4(b) relevante
los subconjuntos
Guas bsicas aplicables a los subconjuntos P, U
Del 5 al 9 Irrelevante para el software
Documentacin sobre el diseo, la
fabricacin y el funcionamiento. Que
permita la evaluacin de la conformidad.
Descripcin general del instrumento.
Descripcin de los dispositivos
Documentacin tcnica
10 electrnicos con planos, diagramas de flujo P1, U1
de la lgica, informacin general del
software.
Ubicacin de precintos y marcas.
Condiciones de compatibilidad con
interfaces y subconjuntos.
Del 11 al 27 Irrelevante para el software
Anexo I
Del AI-1 al AI-5 Irrelevante para el software
Del I1-1 al I1-3,
Del I2-1 al I2-3,
Deteccin de fallos, copia de seguridad,
AI-6 Fiabilidad Del I3-1 al I3-3,
restauracin, reinicio
Del I4-1 al I4-3,
Del I6-1 al I6-2
P3P7,
No hay caractersticas que faciliten el uso
U3U8,
fraudulento; posibilidades mnimas de un
AI-7 Aptitud L1L5, L7, L8,
uso incorrecto no intencionado.
T1T8,
S2, D3, D4
Proteccin frente a la
AI-8
corrupcin
La conexin de otros dispositivos no
AI-8.1 P4, U4
influye.
Proteccin; prueba evidente de P6, P7, U6, U7,
AI-8.2
intervencin D1, D4
P2, P6, P7,
Identificacin del software; prueba
AI-8.3 U2, U6, U7, U8,
evidente de intervencin
D2, D4
P5P7,
U5U7,
Proteccin de los datos almacenados o
AI-8.4 L1L5,
transmitidos
T1T8
D1D3
No permitir la puesta a cero los registros I1-5, I2-5, I3-5,
AI-8.5
acumulativos I4-5
Pgina 110 de 115
MID Gua de software

N. de
(AI = Anexo I)
Informacin que deber
AI-9 figurar en el instrumento y
acompaarlo
Alcance mximo
AI-9.1 (el resto de los elementos son irrelevantes L8
para el software)
AI-9.2 Irrelevante para el software
Instrucciones de instalacin,, condiciones
AI-9.3 de compatibilidad con la interfaz, P1, U1
subconjuntos o instrumentos de medida.
Del AI-9.4 al
Irrelevante para el software
AI-9.8
AI-10 Indicacin del resultado
Indicacin mediante una presentacin
AI-10.1 U8, L6, S2
visual o documento impreso.
Importancia del resultado, no confusin U8, L1, L4, L6,
AI-10.2
con indicaciones adicionales. S2
Impresin o grabacin fcilmente legibles
AI-10.3 U8, L6, S2
e indelebles.
Para ventas directas: presentacin del
AI-10.4 U8, S2
resultado a ambas partes.
Para medidores de suministros pblicos: I1-6, I2-6, I3-6,
AI-10.5
indicador visual para el cliente I4-6
Otros procesamientos de
AI-11 datos para concluir la
transaccin comercial
Grabacin de los resultados de la medicin
AI-11.1 L1 - L8
en un soporte duradero.
Prueba duradera del resultado de la
AI-11.2 medicin e informacin necesaria para L1, L6
identificar la transaccin.
Evaluacin de conformidad fcil con los P1, P2, U1, U2,
AI-12 Evaluacin de conformidad
requisitos de la Directiva. D2, D4
Anexos del A1 al H1
Ningn requisito de las caractersticas de
Del A1 al H1
los instrumentos
Anexo MI-001
Del MI-001-1
al MI-001-6
Deteccin de fallos
Funcionalidades para la generacin de
MI-001-7.1.1,
Inmunidad electromagntica copias de seguridad Del I1-1 al I1-3
MI-001-7.1.2
Funcionalidades de restauracin y
reactivacin
Pgina 111 de 115

MID Gua de software

N. de
(AI = Anexo I)
Del MI-001-7.1.3
al MI-001-9
Anexo MI-002
Del MI-002-1
al MI-002-2
Deteccin de fallos
MI-002-3.1 Inmunidad electromagntica copias de seguridad Del I2-1 al I2-3
reactivacin
Del MI-002-3.1.3
al MI-002-5.1
Solucin aceptable para controlar el
MI-002-5.2 Aptitud I2-7
periodo de vida de una batera
MI-002-5.3 Aptitud Resolucin interna I2-4
Del MI-002-5.4
al MI-002-8
MI-002-5.5 Aptitud Elemento de ensayo. I2-9
Del MI-002-5.6
al MI-002-8
Dispositivos de conversin
Solucin aceptable para controlar el
MI-002-9.1 volumtrica I2-8
convertidor del volumen de un gas
Aptitud
Del MI-002-9.2
al MI-002-10
Anexo MI-003
Del MI-003-1
al MI-003-4.2 Irrelevante para el software
Deteccin de fallos
Efecto permisible de los
fenmenos
MI-003-4.3 copias de seguridad Del I3-1 al I3-3
electromagnticos
transitorios
reactivacin
MI-003-5.1 Irrelevante para el software
MI-003-5.2 Aptitud Resolucin interna I3-4
Del MI-003-5.3
al MI-003-7
Anexo MI-004
Del MI-004-1
al MI-004-4.1
Pgina 112 de 115
MID Gua de software

N. de
(AI = Anexo I)
Deteccin de fallos
Influencias permitidas de Funcionalidades para la generacin de
MI-004-4.2 las perturbaciones copias de seguridad Del I4-1 al I4-3
electromagnticas Funcionalidades de restauracin y
reactivacin
Del MI-004-4.3
al MI-004-7
Anexo MI-005
Anexo MI-006
Deteccin de fallos
MI-006-IV, Totalizadores continuos y
Funcionalidades para la generacin de Del I6-1 al I6-2
MI-006-V discontinuos
copias de seguridad
Anexo MI-007
Anexo MI-008
Anexo MI-009
Anexo MI-010
Pgina 113 de 115

14 Referencias y Bibliografa
[1] Directiva 2004/22/CE del Parlamento Europeo y del Consejo de 31 de marzo de 2004 relativa a los
instrumentos de medida Diario oficial de la Unin Europea L 135/1, 30/4/2004.
[2] Software Requirements and Validation Guide, versin 1.00, 29 de octubre de 2004, Red de
Crecimiento Europeo sobre el software de la MID, nmero de contrato G7RT-CT-2001-05064, 2004.
[3] Requisitos de software segn la MID, WEMEC 7.1, nmero 2, 2005.
15 Histrico de revisiones
Versin Fecha Cambios significativos
1 Mayo 2005 Primera versin de la gua
2 Abril 2007 Adicin y mejora de trminos en la seccin 2
Cambios de redaccin en secciones 4.1 y 5.1
Modificacin de una aclaracin para la identificacin del
software de en la seccin 4.2, requisito P2 y seccin 5.2,
requisito U2
Enmienda en requisito L8, especificacin de la nota 1
Aadir una explicacin al requisito S1, especificacin 1
Sustitucin del requisito D5 por un recordatorio
Cambio de la clase de riesgo para sistemas de medicin de
lquidos distintos del agua
Cambio de las clases de riesgo para instrumentos de pesaje
Inclusin de varios cambios menores de redaccin en el
documento
Inclusin de esta tabla de revisiones
3 Marzo 2008 Inclusin de excepciones para la indicacin de la identificacin del
software: nuevos requisitos I1-5, I2-9, I3-6, I4-5 e I5-1
4 Mayo 2009 Eliminacin de los ltimos prrafos de la gua de validacin de
clases B y C de los requisitos P2 y U2
Inclusin de aclaracin para la aplicacin de la descarga de
software legalmente relevante, captulo 9 Extensin D
Inclusin del punto 4 en especificaciones del requisito D2
Tabla 15.1 Histrico de revisiones
16 ndice alfabtico
algoritmo de firma, 9, 31, 39, 48 clases de riesgo, 8, 11, 12, 14, 15, 16, 17, 18,
algoritmo hash, 9 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30,
almacenamiento a largo plazo, 6, 9, 11, 35, 31, 32, 33, 34, 36, 37, 38, 39, 40, 41, 42,
36, 44, 68, 75, 80, 84, 92, 97, 98, 103 43, 44, 46, 47, 48, 49, 50, 51, 52, 53, 54,
almacenamiento integrado, 13, 35, 100 55, 56, 57, 58, 59, 60, 61, 62, 63, 69, 76,
analizadores de gases de escape, 94 81, 84, 85, 93, 94, 95, 103, 104, 114
autenticacin, 40, 49, 60 clave de firma, 8, 9
autenticidad, 8, 9, 32, 33, 34, 40, 41, 42, 49, comando, 14, 15, 16, 17, 24, 25, 26, 27, 56
58, 60, 61, 102, 103, 104 configuracin bsica, 6, 11, 100
Autoridad certificadora, 8, 41, 50 configuracin TI, 11, 100
certificado de examen de modelo, 15, 25, 32, contador de energa trmica, 81
33, 96, 106 contador de gas, 72, 74
circuito, 20, 21, 77, 81, 98 control legal, 7, 8, 13, 22, 30, 35, 40, 41, 42,
45, 47, 50, 53, 54, 57, 64, 100, 105, 106
Pgina 114 de 115
desarrollado especficamente, 7, 11, 12, 35, memoria, 20, 21, 31, 35, 73, 101
41, 50, 57, 97, 98 , 1, 5, 6, 7, 8, 9, 11, 63, 65, 67, 70, 72, 76, 79,
descarga de software, 17, 20, 27, 30, 54, 57, 81, 83, 85, 86, 87, 91, 93, 94, 95, 97, 99,
58, 68, 75, 80, 84, 105 106, 110, 114
deteccin de fallos, 18, 51, 64, 88 parmetro, 7, 21, 91
documentacin, 11, 12, 13, 14, 15, 16, 17, 18, red, 7, 13, 22, 23, 35, 37, 45, 49, 52, 57, 64,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 104
30, 31, 32, 33, 34, 36, 37, 38, 39, 40, 41, red abierta, 7, 22, 45, 57, 64
42, 43, 44, 46, 47, 48, 49, 50, 51, 52, 53, red cerrada, 7, 22, 45, 49, 57, 64
54, 55, 56, 57, 58, 59, 60, 61, 62, 65, 66, referencia cruzada, 6
67, 68, 71, 72, 73, 74, 75, 77, 78, 79, 80, registro de sucesos, 8, 21, 62
82, 83, 84, 85, 88, 89, 92, 94, 95, 98, 101, requisitos especficos, 9, 11, 35, 42, 44, 63,
102, 106 65, 70, 76, 81, 85, 86, 91, 93, 94, 98, 103,
firma electrnica, 9, 38, 47, 60 104, 105
flujo de datos, 16, 18, 27, 28, 54, 56, 57, 98, secuencia de actuaciones, 16
105 separacin de software, 8, 53, 54, 57, 67, 74,
herramientas sofisticadas, 38, 41, 47 79, 83, 106, 108
identificacin, 14, 15, 21, 23, 24, 25, 33, 36, sistema operativo, 13, 22, 23, 24, 26, 27, 29,
40, 42, 46, 49, 54, 60, 62, 68, 75, 80, 84, 30, 31, 35, 53, 54, 64, 100
85, 98, 101, 102, 106, 114 spoof, 32
indicacin, 55, 68, 72, 73, 75, 78, 80, 84, 85, subconjunto, 7, 8
90, 97, 114 subrutina, 56, 66, 71, 77, 82, 88
informe de ensayos, 100, 101, 106 suma de comprobacin, 7, 14, 15, 18, 19, 25,
instrumentos para medidas dimensionales, 93 29, 30, 31, 33, 37, 39, 40, 46, 47, 48, 61
integrado, 6, 11, 12, 21, 31, 35, 64, 97 taxmetro, 91, 92
integridad, 9, 39, 40, 42, 48, 58, 60, 61, 62 tipo P, 7, 9, 11, 12, 13, 22, 35, 57, 64, 65, 69,
interfaz de comunicacin, 27, 106, 107 70, 76, 81, 85, 86, 91, 93, 94, 98, 101
interfaz de usuario, 13, 14, 16, 18, 22, 23, 24, tipo U, 7, 11, 13, 22, 23, 35, 57, 64, 69, 76,
26, 27, 28, 64, 68, 75, 80, 84, 85, 101, 102, 81, 85, 86, 91, 93, 94, 102
106 transmisin, 6, 8, 9, 11, 13, 17, 27, 46, 47, 48,
legalmente relevante, 6, 7, 8, 11, 13, 14, 15, 49, 51, 52, 53, 54, 92, 100, 104, 108
16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, trazabilidad, 62
27, 28, 29, 30, 31, 32, 33, 34, 35, 37, 39, validacin, 6, 11, 12, 14, 15, 16, 17, 18, 19,
41, 42, 45, 46, 47, 48, 50, 52, 53, 54, 55, 20, 21, 22, 25, 26, 27, 28, 29, 30, 31, 32,
56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 33, 34, 36, 37, 38, 39, 40, 41, 42, 43, 44,
67, 68, 71, 72, 73, 74, 75, 78, 79, 80, 82, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56,
83, 84, 88, 89, 90, 91, 92, 97, 98, 101, 102, 57, 58, 59, 60, 61, 62, 66, 67, 68, 71, 72,
103, 104, 105, 108, 110 73, 74, 75, 77, 78, 79, 80, 82, 83, 84, 85,
lista de comprobacin, 98, 99, 100 88, 89, 92, 97, 98, 106
Pgina 115 de 115

Guia7 2 ES-v4 Welmec

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guia7 2 ES-v4 Welmec

Transféré par

Droits d'auteur :

Formats disponibles

WELMEC 7.

Gua del software

Publicacin CEM edicin digital 1

La gua es puramente orientativa y no impone ninguna restriccin o requisito tcnico adicional ms

Esta ltima edicin aprovecha la experiencia adquirida en la aplicacin de esta gua.

En la pgina Web: http://www.welmecwg7.ptb.de se encuentra disponible informacin actualizada

Autenticacin: verificacin de la identidad declarada o alegada de un usuario, proceso, o dispositivo.

Configuracin bsica: diseo de un instrumento de medida respecto a su arquitectura bsica. Existen

Configuracin TI (Tecnologas de la Informacin): diseo de un instrumento de medida respecto de

Descarga de software: proceso de transferencia automtica del software a un instrumento de medida

ej., medios de almacenamiento intercambiables, ordenador porttil, ordenador remoto), a travs de

Instrumento de medida: cualquier dispositivo o sistema con funciones de medicin. El calificativo

Instrumento de medida desarrollado especficamente (tipo P): instrumento de medida diseado y

Interfaz de comunicacin: interfaz electrnica, ptica, de radiofrecuencia o por cualquier otro

Parmetro legalmente relevante: parmetro de un instrumento de medida o un subconjunto sometido

Solucin aceptable: diseo o base de un mdulo de software o de una unidad de hardware, o de un

Subconjunto: dispositivo hardware (unidad de hardware) que funciona independientemente y que

TEC: type examination certificate (Certificado de examen de modelo).

Transmisin de datos de medida: transmisin de datos de medida a travs de redes de comunicacin

Algoritmo hash: algoritmo que comprime el contenido de un bloque de datos en un nmero de

3. Cmo usar esta gua

Este captulo describe la organizacin de la gua y explica como utilizarla.

3.1 Estructura general

Por lo tanto, existen tres tipos de series de requisitos:

2. requisitos para las cuatro configuraciones TI (denominadas extensiones L, T, S y D)

3. requisitos especficos del instrumento (denominados extensiones I.1, I.2, etc.).

Requisitos aplicables para

Figura 3-1: Tipo de series de requisitos que deberan aplicarse a un instrumento.

Bloque de requisitos P2 Bloque de requisitos U2

Requisitos del software para las configuraciones TI

Requisitos para la transmisin de los datos Requisitos para la descarga de software

Bloque de Bloque de Bloque de Bloque de

Requisitos del software especficos del instrumento

Contadores de Contadores de Instrumentos

Bloque de Bloque de Bloque de

Figura 3-2: Descripcin general de las series de requisitos.

3.2 Cmo seleccionar los apartados adecuados

Paso 1: Seleccin de la configuracin bsica (P o U)

Paso 2: Seleccin de las configuraciones TI aplicables (extensiones L, T, S y D)

Paso 3: Seleccin de los requisitos especficos del instrumento (extensin I)

Paso 4: Seleccin de la clase de riesgo aplicable (extensin I)

Se seleccionar la clase de riesgo definida en el subapartado I.x.6 correspondiente a la extensin I.x

3.3 Cmo trabajar con bloques de requisitos

Ttulo del requisito

Notas para el fabricante:

- Debe cumplirse el enunciado y las especificaciones adicionales.

Notas para los organismos notificados:

- Debe cumplirse el enunciado y las especificaciones adicionales.

3.4 Cmo trabajar con las listas de comprobacin

4 Requisitos bsicos del software integrado en un instrumento de medida desarrollado

4.1 Descripcin tcnica

Un instrumento de tipo P es un instrumento de medida con un sistema TI integrado (generalmente es

4.2 Requisitos especficos para el tipo P

Clase de riesgo B Clase de riesgo C Clase de riesgo D

Ejemplo de solucin aceptable:

Consideraciones adicionales para la clase de riesgo E

Clase de riesgo B Clase de riesgo C Clase de riesgo D

Documentacin requerida: Documentacin requerida

Consideraciones adicionales para la clase de riesgo E

Clase de riesgo B Clase de riesgo C Clase de riesgo D

Documentacin requerida: Documentacin requerida

Consideraciones adicionales para la clase de riesgo E

Clase de riesgo B Clase de riesgo C Clase de riesgo D