La evaluación del software de los instrumentos de medida

S. Ruiz
M.P. Caeque
T. de San Teodoro
Centro Español de Metrología

1. Generalidades

La legislación metrológica tiene dentro de sus objetivos, tal como establece el documento OIML D1 “Consideraciones para una ley de Metrología” de la Organización Internacional de Metrología legal, proteger los intereses de individuos y empresas; proteger los intereses nacionales; proteger la salud pública y la seguridad, incluso en relación con el medio ambiente y los servicios médicos y garantizar el comercio justo y la igualdad de condiciones para promover el comercio. En ese sentido, la Ley 3/1985, de 18 de marzo, de metrología [1], derogada por la Ley 32/2014 [7], de 22 de diciembre de metrología, estableció en defensa de la seguridad, de la protección de la salud y de los intereses económicos de los consumidores y usuarios, los instrumentos, aparatos, medios y sistemas de medida que sirvieran para pesar, medir o contar, no podrían ser fabricados, importados, comercializados o empleados, mientras no hubieran superado el control metrológico establecido en dicha Ley y en las disposiciones que se dictaran para su aplicación.

En base a la Ley 3/1985 [1] y al Real Decreto 1296/1986 [2], que modifico la referida ley para adaptarla a las necesidades de la incorporación de España, a la entonces, Comunidad Económica Europea, se desarrolló el control metrológico del Estado en el Real Decreto 1616/1985 [3] y el control metrológico CEE en el Real Decreto 597/1988 [4] y en una serie de reglamentaciones específicas, generalmente en formato orden ministerial, que regulaban, directa o mediante transposición de directivas comunitarias, los diferentes tipos de instrumentos de medida que previsiblemente iban a ser utilizados dentro de lo establecido en la Ley 3/1985 de metrología [1].

Sin embargo, hasta la aparición de la Directiva 2004/22/CE [6] de instrumentos de medida conocida como la MID (Measuring Instruments Directive), no se establecen los requisitos específicos sobre el software de los instrumentos de medida. La Directiva 2004/22/CE [6]:

• estableció entre la documentación que tiene que aportar un fabricante para la realización de un examen de modelo, una descripción de los dispositivos electrónicos con planos, diagramas, diagramas de flujo de la lógica e información del software general, que expliquen sus características y funcionamiento;

• e incluyó dentro de los requisitos esenciales un apartado sobre “protección contra la corrupción” en el que establecían requisitos sobre el software de los instrumentos de medida para, entre otros:
  • protegerlo respecto a intervenciones intencionadas o accidentales;
  • protegerlo respecto a otros dispositivos conectados;
  • proteger los datos, parámetros y comandos.

La Directiva 2004/22/CE [6] se incorporó a la legislación española mediante el Real Decreto 889/2006 [5], que incluía, además de la transposición de la Directiva, modificaciones sustanciales de la ejecución del control metrológico basadas en la filosofía del nuevo enfoque y enfoque global y la utilización de organismos de evaluación de la conformidad para su ejecución, pero eso no es objeto directo de este artículo. A partir de la promulgación del Real Decreto 889/2006 [5], es cuando se incluye en los requisitos esenciales de instrumentos de medida la los referidos al software complementando a los habituales relativos a los entornos climáticos, mecánicos y electromagnéticos.

Para una correcta evaluación de los requisitos de software, la Comisión Europea apoyó entre 2002 y 2004 el desarrollo de “La guía de requisitos y validación de software”, desarrollada por la Red Europea de Crecimiento “MID-Software”. Posteriormente en la XX Reunión del Comité WELMEC, en mayo de 2004, se presentó la Declaración de la Comisión, en la que con el propósito de facilitar la aplicación coherente y fluida de la Directiva, la Comisión contaría con WELMEC para, entre otros, la elaboración de guías que impulsaran una evaluación igualitaria de los requisitos de las Directivas, entre ellos los requisitos de software.

A partir de ese momento y del documento desarrollado por la Red Europea de Crecimiento “MID-Software”, el grupo 7 de WELMEC empieza a desarrollar una serie de Guías 7.x relativas al software.

Posteriormente la Ley 32/2014 [7] de metrología, amplió lo establecido en la anterior Ley 3/1985 [1], considerando sometidos a control metrológico del Estado, no solo los instrumentos, aparatos, medios y sistemas de medida que sirvieran para pesar, medir o contar, sino también los programas informáticos.

El desarrollo de la Ley 32/2014 [7] de metrología se llevó a cabo por el Real Decreto 244/2016 [10], de 3 de junio, que además transpuso la nueva directiva de instrumentos de medida Directiva 2014/32/UE [8] y la directiva de instrumentos de pesaje de funcionamiento no automático Directiva 2014/31/UE [9].

El Real Decreto 244/2016 [10] además de trasponer los requisitos de la Directiva 2014/32/UE [8] en su anexo II relativo a requisitos esenciales comunes, incluyendo los del software, de los instrumentos de medida sometidos a control metrológico del Estado, incluye el anexo IV específico de software “Software legalmente relevante vinculado a la medición en los instrumentos de medida sometidos a control metrológico del Estado”. El anexo IV traslada al Real Decreto 244/2016 [10] los aspectos contenidos en las guías WELMEC 7.x.

2. Las guías WELMEC 7.x

Las guías WELMEC 7.x, en adelante WELMEC 7.x,  pueden ser de aplicación durante el proceso de evaluación de conformidad, tal y como lo permite el anexo IV del Real Decreto 244/2016 [10]. Existen cuatro guías, véase tabla 1.

7.1	Software Requirements on the Basis of the Measuring Instruments Directive (MID) [11]
7.2	Software Guide (Measuring Instruments Directive 2014/32/EU) [12]
7.3	Reference Architectures – Based on WELMEC Guide 7.2 [13]
7.4	Exemplary Applications of WELMEC Guide 7.2 [14]

La evaluación de la conformidad con los requisitos establecidos en la Directiva MID o en las regulaciones nacionales de los instrumentos de medida sometidos al control metrológico del Estado que dispongan de software, obliga a un análisis de las características de este software y de los equipos sobre los que trabaja. En base al punto 5 del artículo 3: Generalidades, del anexo IV del Real Decreto 244/2016 [10], el procedimiento técnico de ensayos para la comprobación de los requisitos de software, así como los medios técnicos que se empleen, dependerán de la solución aportada por el fabricante, pudiendo ser de aplicación lo establecido en normas armonizadas o en recomendaciones internacionales de la Organización Internacional de Metrología Legal (OIML) y tomando en consideración los requisitos esenciales publicados por la Comisión Europea u otros documentos aprobados por organismos nacionales e internacionales (UNE-EN/ISO, OIML, WELMEC, etc.). Por lo que, aunque en teoría, la evaluación depende de la solución aportada por el fabricante, la realidad es que hasta la fecha todos los fabricantes han optado por la utilización de las guías WELMEC 7.x para demostrar conformidad con los requisitos de software, y más concretamente la Guía 7.2 [12], al ser la que recomienda WELMEC para la creación, examen y validación del software de los instrumentos de medida controlados por software sometidos a la MID, por ser la que establece los requisitos y la forma de evaluarlos, constituyendo las otras guías documentos aclaratorios de apoyo.

Las guías están dirigidas tanto a los fabricantes de instrumentos de medida como a los organismos responsables de la evaluación de la conformidad de los mismos. Además son puramente orientativas y no impone ninguna restricción o requisito técnico adicional más allá de aquellos que se incluyen en la MID. La orientación proporcionada es lo considerado por WELMEC como la mejor práctica a seguir.

Por otro lado aunque las guías están orientadas a los instrumentos equipados con software, incluidos en las regulaciones de la MID y extensibles a regulaciones nacionales, son de carácter general y pueden aplicarse en otros ámbitos, como se expone más adelante.

Inicialmente fueron elaboradas las Guías 7.1 [11] y 7.2 [12]. Ambas guías se basan en los mismos principios y derivan de los requisitos de la MID. Después de la revisión de WELMEC 7.1 [1] en 2005 pasó a ser un documento de requisitos de carácter meramente informativo.

WELMEC 7.2 [12] proporciona una interpretación técnica de los requisitos esenciales establecidos en el anexo I de MID (2014/32/UE [8]) y el módulo de evaluación de la conformidad B. Su estructura establece un concepto modular genérico que permite describir una gran variedad de arquitecturas tecnológicas de TI (véase Figura 1). Este enfoque modular garantiza una adaptación sencilla a las nuevas tecnologías presentes y futuras y, por lo tanto, admite innovaciones.

La elaboración de WELMEC 7.3 [13] nace de las necesidades actuales del mercado,  cada vez más globalizado que busca impulsar la eficiencia y atender las demandas de los consumidores en constante desarrollo.

WELMEC 7.3 [13] surge de la convicción del Grupo 7 de WELMEC, de que ofrecer a los fabricantes una plantilla generalizada (basada en el concepto modular de la Guía 7.2 [12] de WELMEC) para el diseño de sus instrumentos supone un gran beneficio para garantizar que el producto innovador previsto esté en línea con los requisitos reglamentarios de la Directiva MID. Proporciona modelos de arquitecturas de referencia específicas y un esquema para facilitar el proceso de evaluación de la conformidad de los diseños innovadores de los instrumentos de medida.

Finalmente WELMEC 7.4 [14] proporciona orientación técnica para la aplicación de la MID a instrumentos equipados con software, está diseñada para usarse junto con WELMEC 7.2 [12] , proporcionando ejemplos de soluciones aceptables para diversas arquitecturas específicas de instrumentos e indica cómo estas soluciones aceptables cumplen los requisitos establecidos en WELMEC 7.2 [12]. Mientras que WELMEC 7.3 [13] proporcionaba soluciones aceptables a nivel arquitectónico, WELMEC 7.4 [14] aborda soluciones aceptables a nivel técnico.

Las versiones más recientes de las guías WELMEC 7.x contemplan la experiencia completa obtenida a raíz de la aplicación de la Guía y, por lo tanto, es la versión oficial confirmada por el Comité WELMEC. Las versiones anteriores están disponibles solo con fines de referencia.

WELMEC 7.2 en su enfoque modular, véase Figura 1, establece los siguientes aspectos clasificatorios en los que profundizaremos a continuación:

• Clases de riesgo.
• Tipos de instrumento.
• Configuraciones de tecnología de la información (TI).
• Requisitos del software específicos de instrumentos MID.

2.1 Clases de riesgo

WELMEC 7.2 [12] recoge como definición “clase de tipos de instrumentos de medida con evaluaciones de riesgo comparables”, por comodidad se utiliza el término abreviado “clase de riesgo”. A cada tipo de instrumento de medida se le debe asignar una clase de riesgo (del software) ya que los requisitos específicos del software que hay que aplicar están subordinados a la clase de riesgo a la que pertenece el instrumento.

Los riesgos del software en los instrumentos de medida tienen su origen principalmente en tres factores de riesgo: protección inadecuada del software, examen inadecuado del software y no conformidad con el tipo. Una clase de riesgo es una combinación de los niveles de estos tres factores de riesgo donde la definición de los niveles de los factores de riesgo se realiza indirectamente por definición de los niveles para las correspondientes contrapartidas necesarias (protección del software, examen del software y grado de conformidad del software). Introduce tres niveles para cada uno de los factores de riesgo: bajo, medio y alto. Cuanto mayor sea el riesgo asumido, mayor será el nivel requerido de contrapartida. De las 27 combinaciones de niveles teóricamente posibles, solo 6, y principalmente 3, son de interés práctico (clases de riesgo B, C, D y eventualmente A, E y F). Abarcan todas las clases de instrumentos que están incluidas en la regulación de la MID. Además, proporcionan suficiente rango en caso de que se modifiquen las evaluaciones de riesgo. En la tabla 2 se definen las clases de riesgo.

Clase de riesgo	Protección del software	Examen del software	Grado de conformidad 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

Cabe mencionar que las clases de riesgo del software de un instrumento de medida se definen en la extensión I que veremos más adelante para los instrumentos incluidos en la MID, pero no están definidas para los instrumentos sometidos a regulación nacional exclusiva. Las clases de riesgo A y F no se utilizan en WELMEC 7.2 [12].

2.2 Tipos de instrumentos

Tanto el Real Decreto 244/2016 [10] como WELMEC 7.2 [12] definen 2 tipos de instrumentos, atendiendo a su configuración básica: instrumentos de medida desarrollados específicamente e instrumentos de medida que usan un ordenador universal, conocidos como tipo P y tipo U, respectivamente.

Un instrumento tipo P está diseñado y construido específicamente para una tarea concreta. Por consiguiente, todo el software se desarrolla para realizar la medida. Con un sistema informático integrado (generalmente es un sistema basado en un microprocesador o microcontrolador). El sistema informático integrado presenta las siguientes características:

• El software está construido exclusivamente para el propósito de medición. Las funciones adicionales para la protección del software y de los datos, para la transmisión de los datos y para la actualización del software se consideran construidas para el propósito de medición.
• El software se diseña y se trata como un todo, a menos que se haya aplicado una separación de software según la extensión S, que veremos más adelante.
• La interfaz de usuario dedicada al propósito de la medición es legalmente relevante, aunque pudiera ser posible otros modos de funcionamiento no sometidos a control metrológico del Estado, como por ejemplo para la realización de actividades de reparación.
• Puede incluir un sistema operativo (SO) o subsistemas siempre que toda comunicación está bajo control de software legalmente relevante y no permita cargar, cambiar o ejecutar programas, parámetros, datos o el entorno de la aplicación legalmente relevante, etc.
• El entorno del software es invariable y no hay medios internos o externos para programar o cambiar el software en su estado incorporado.

Un instrumento tipo U consta de un ordenador de propósito general, que suele ser un sistema basado en ordenador personal, 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 específicamente (tipo P).

Se debe asumir un sistema de tipo U si no se cumplen las condiciones de un instrumento de tipo P. La descripción técnica del sistema de medida tipo U se resume a continuación.

• Configuración hardware
  1. Sistema modular basado en un ordenador de propósito general. El ordenador puede ser autónomo, formar parte de una red cerrada (p. ej., Ethernet, LAN token ring) o parte de una red abierta (p. ej., Internet).
  2. Puesto que el sistema es de propósito general, la unidad del sensor (módulo de medida) normalmente será externo al ordenador y estará conectado a él mediante un enlace de comunicación cerrado o abierto.
  3. La interfaz de usuario ofrece funciones adicionales, que no están bajo control metrológico del Estado, además del modo operativo para la tarea de la medición.
  4. El almacenamiento puede ser fijo (p. ej., disco duro), extraíble (p. ej., USB) o remoto.

• Configuración software
  1. Puede utilizarse cualquier sistema operativo
  2. Además de la aplicación del instrumento de medida, pueden encontrarse a la vez otras aplicaciones de software en el sistema, sometidas o no a control metrológico del Estado.

En general el sistema operativo y los drivers de bajo nivel (p. ej., los controladores o drivers de vídeo, de la impresora, del disco, etc.) son legalmente no relevantes a menos que estén programados especialmente para una tarea de medida específica

2.3 Configuraciones de tecnología de la información (TI)

Son elementos característicos independientes de la función de medición. Se consideran configuraciones TI: el almacenamiento a largo plazo de los datos de medida, la transmisión de los datos de medida, la actualización del software y la separación de software, conocidas como extensiones L, T, D y S respectivamente.

• El almacenamiento a largo plazo consiste en el registro de los datos resultantes de las mediciones que sean legalmente relevantes. Cuando la reglamentación especifica de un instrumento lo establezca como requisito se incorpora en el propio instrumento o sistema con independencia de su clasificación de tipo (P o U).
• La transmisión de los datos de medida a través de redes de comunicación u otros medios a un dispositivo remoto donde se procesan o utilizan posteriormente con fines legalmente regulados.
• La actualización del software es el proceso mediante el que el software se transfiere de forma automática a un instrumento de medida o subconjunto del mismo, por cualquier medio técnico, desde una fuente local o remota (p. ej., medios de almacenamiento intercambiables, ordenador portátil, ordenador remoto), a través de conexiones establecidas discrecionalmente por el fabricante (p. ej., enlace directo, redes). En este caso el instrumento tienen que disponer de un registro de sucesos no volátil donde se almacenarán las características de los eventos de la actualización del software. La capacidad de dicho registro debe ser apropiada para cada tipo de instrumento y permitirá conocer su historial de actualizaciones. En caso de llenado del registro, el instrumento deberá quedar inhabilitado para la realización de funciones metrológicas legalmente relevantes. La actualización de software debe entenderse sobre la posibilidad de actuar sobre el software de instrumentos que ya están en servicio. Las actuaciones sobre nuevos instrumentos no constituyen una actualización de software, sino una modificación del mismo. En ambos casos el software debería ser previamente sometido a evaluación.

WELMEC 7.2 [12] utiliza para esta extensión el término “Download” que podría interpretarse como descarga, pero se refiere a “Actualización”.

• La separación del software se da cuando conviven varios software en un instrumento, unos metrológicamente relevantes y otros no. Está situación puede darse en instrumentos tipo P y siempre se da en instrumentos tipo U. Se debe garantizar que si hay posibilidad de intercambio de datos entre ambos tipos de software se realiza mediante  una interfaz protegida. Dicha interfaz forma parte del software legalmente relevante. Cuando no hay separación de software, todo el software en conjunto se considera legalmente relevante.

2.4 Requisitos del software específicos de instrumentos MID

WELMEC 7.2 [12] contempla una extensión I de requisitos específicos que complementan los requisitos generales del software de los apartados anteriores (tipo de instrumento y configuración TI) para los diferentes instrumentos incluidos en la MID. La extensión I contiene la asignación específica de clases de riesgos para cada instrumento incluido en la MID (o categoría) que garantiza un nivel armonizado de examen, protección y conformidad del software. Tiene una estructura abierta, ya que está pensada como un borrador inicial a completar por el respectivo grupo de trabajo de WELMEC con los conocimientos específicos correspondientes. Por lo tanto, la extensión I tiene una “estructura abierta”.

2.5 Arquitecturas aceptables

El principal desafío de WELMEC 7.3 [13] es definir arquitecturas de referencia generales para instrumentos de medida innovadores que abarquen el cumplimiento de los requisitos esenciales (anexo I de la Directiva 2014/32/UE [8]), facilitar las actividades de verificación e inspección de los instrumentos de medida en el mercado y la exploración de riesgos y amenazas a través de un análisis de riesgos adecuado. WELMEC 7.3 [13] incluye modelos de esquemas de arquitecturas de referencia generales de los diseños de instrumentos de medida innovadores basados en nuevos desarrollos tecnológicos. Para que estas arquitecturas de referencia general sean aplicables a una clase específica de instrumentos, debe cumplir requisitos adicionales específicos del instrumento de acuerdo con la clase de riesgo del instrumento.

Las arquitecturas de referencia propuestas se muestran en las figuras 2 a 6.

Como regla general cualquier cambio o intervención en los módulos legalmente relevantes separados de la unidad madre debe dejar evidencia.

Finalmente en WELMEC 7.4 [14] se contemplan ejemplos de algunas de las configuraciones mencionadas anteriormente, pero no todas. Los lectores han de elegir detalles de implementación específicos entre los diferentes ejemplos presentados para satisfacer sus necesidades. Está diseñada para usarse junto con la guía WELMEC 7.2 [12] y proporcionar orientación técnica para la aplicación de la Directiva de instrumentos de medida (MID) equipados con software y el cumplimiento de los requisitos que en ella se establecen, es decir, aborda soluciones aceptables a nivel técnico.

3. Proceso de evaluación del software

Una vez introducido el marco legal y las guías WELMEC, vamos a abordar el proceso de evaluación de software necesario para poder comercializar y poner en servicio los instrumentos de medida sometidos a control metrológico.

Generalmente el proceso de evaluación del software se lleva de forma conjunta con el resto del instrumento, al igual que los entornos mecánico, climático y electromagnético, aunque el fabricante tiene la opción de presentar un nuevo software a evaluación, por ejemplo cuando hay un cambio total en el software y el resto de las características del equipo se mantienen.

Como ya hemos mencionado una de las posibilidades para asegurar el cumplimiento de los requisitos establecidos en el Real Decreto 244/2016 [10], y por ende en la Directiva 2014/32/UE [8], es a través de la evaluación del software siguiendo las recomendaciones que proporciona la guía WELMEC, sin embargo, no es una obligatoriedad el seguimiento de esta guía pudiendo elegir fórmulas alternativas. En este artículo nos centraremos en la evaluación según WELMEC 7.2 [12].

La figura 7 muestra el proceso de evaluación.En este artículo nos centraremos en la parte técnica, no entrando en el proceso administrativo de la evaluación.

Inicialmente el fabricante presenta la documentación técnica del instrumento definida en el artículo 13 y en el anexo IV del Real Decreto 244/2016 [10], junto con unas muestras del instrumento.

Toda la información del software debe estar contemplada en la memoria técnica, incluyendo descripción de los algoritmos de medición, descripción de interfaz de usuario, identificadores del software, entre otros.

Adicionalmente, el fabricante incluye junto con la documentación una declaración de veracidad y cumplimiento de requisitos firmada. No hay que olvidar que el responsable final del instrumento y del software es el propio fabricante. La declaración también incluye su compromiso de no cometer acciones que vulneren el software y no facilitar información de acceso al software a terceros.

La documentación debe ser completa y clara, en caso contrario el evaluador debe indicar al fabricante las deficiencias encontradas. Así mismo aunque la responsabilidad de clasificar el instrumento según tipo de instrumento, clase de riesgo y extensiones aplicables, es del fabricante, en caso de que el evaluador no esté de acuerdo se lo debe comunicar. En función de la clasificación, P o U, clase de riesgo y extensiones, se van a definir los tipos de pruebas que será necesario realizar para verificar que cumple con los requisitos particulares del software. Por ejemplo, en el caso de que el nivel de riesgo sea B o C, las pruebas a realizar serán muy similares; sin embargo, si habrá diferencia significativas en el caso de que el nivel de riesgo sea D o E.

Solventadas las deficiencias iniciales, si existiesen, el evaluador procede con la evaluación documental de aquellos aspectos incluidos en cada uno de los requisitos de Guía WELMEC 7,2. A modo de ejemplo para un instrumento tipo P se evaluará:

• P1: Documentación.  
• P2: Identificación del software.
• P3: Influencia a través de las interfaces de usuario.
• P4:Influencia a través de interfaces de comunicación.
• P5: Protección  frente  a  cambios  accidentales  o  no intencionados.
• P6: Protección frente a modificaciones inadmisibles intencionadas.
• P7: Protección de parámetros.
• P8: Autenticidad de los resultados de medida que se presentan.

O para la extensión D de actualización de software:

• D1: Mecanismo de actualización.  
• D2: Autenticación del software actualizado.
• D3: Integridad del software actualizado.
• D4: Trazabilidad de la actualización del software legalmente relevante.

Una vez evaluada la documentación se comunican al fabricante las deficiencias encontradas, si existiesen, para que las solvente. Una vez que no existen deficiencias o son de poca importancia, se procede a la evaluación mediante ensayo de los requisitos aplicables.

Para la realización de las comprobaciones funcionales será necesaria la actuación de personal con cocimiento funcional y técnico que permita realizar modificaciones en el software.

Algunas de las pruebas comunes que se realizan durante la evaluación del software para los instrumentos tipo P son las siguientes:

• Identificación del software legalmente relevante. Se comprueba que la suma de comprobación del software es la declarada en la documentación, así como que es un valor calculado. Para ello una de las pruebas que se realizan es la modificación a nivel de líneas de código y la compilación del mismo para verificar que la suma de verificación mostrada es diferente al inicial y que el instrumento lo detecta e impide su funcionamiento.

• Influencia a través de interfaces de usuario. Se verifica que los comandos ingresados a través de las interfaces de usuario no influyan inadmisiblemente en el software y los datos de medición legalmente relevantes. Una de las posibles verificaciones puede realizarse haciendo una captura de los comandos incluidos en el código del software, comparándolos con los declarados por el fabricante en la documentación y comprobando que cualquier comando es filtrado por esa parte del código, no permitiendo la ejecución de comandos no incluidos en esa parte del software.

• Influencia a través de interfaces de comunicación. Se verifica que los comandos ingresados a través de las interfaces de comunicación del instrumento no influyen de manera inadmisible en el software legalmente relevante, los parámetros específicos del dispositivo y los datos de medición, una solución aceptable puede ser la misma que en el punto anterior.

• Protección contra cambios accidentales o involuntarios. Se comprueba que el software legalmente relevante y los datos de medición están protegidos contra cambios accidentales o involuntarios.

• Protección contra cambios intencionales inadmisibles. Se verifica que el software legalmente relevante está protegido contra la modificación, carga o intercambio inadmisible e intencional de la memoria de hardware

• Protección de parámetros. Se comprueba que los parámetros legalmente relevantes están asegurados contra modificaciones inadmisibles. Se probará, por ejemplo, que no están habilitadas opciones de escritura para los parámetros legalmente relevantes.

• Autenticidad de datos de medición mostrados. Se verifica que está garantizada la autenticidad de los datos de medición que se presentan

Los instrumentos tipo U tienen que cumplir las mismas premisas que para el caso de instrumentos tipo P, incluyendo adicionalmente:

• Influencia de otro software. Se comprueba que el software legalmente relevante está diseñado de tal manera que otro software no influya inadmisiblemente en él.

Adicionalmente se realizarán las pruebas necesarias para cada una de las extensiones L, T, D o S, según proceda.

Como resultado de la evaluación funcional se comunican al fabricante las deficiencias, si existiesen, para que las dé solución. Para su comprobación puede ser necesario en función de la gravedad de las deficiencias, nuevas comprobaciones funcionales o simplemente una comprobación documental.

Una vez que el software es satisfactorio, el evaluador debe descargar el software del instrumento y mantenerlos en custodia por si en el futuro surgiera la necesidad de comprobar el software del instrumento. Previsiblemente en el fututo sea suficiente con los ficheros de carga.

Una vez el software analizado cumple con los requisitos, se podrá dar por finalizado el análisis del software mediante la inclusión en el examen de evaluación de la siguiente información a la que hace referencia el artículo 6 del anexo IV del Real Decreto 244/2016 [10]:

1. Identificación y descripción de los componentes electrónicos que son importantes para el software.
2. Descripción general del entorno informático necesario para utilizar el software sometido a control metrológico.
3. Descripción general del software sometido a control metrológico (incluida la separación de software, si esta ha sido implementada).
4. Descripción general e identificación de las interfaces.
5. Identificación y descripción de las ubicaciones de los componentes en el instrumento de medida (EPROM, procesador, disco duro y accesorios similares) que deben precintarse o protegerse.
6. Instrucciones para la comprobación de la identificación del software.
7. En caso de precinto lógico, instrucciones para la inspección de los registros de sucesos.
8. Instrucciones para realizar la descarga externa del software validado.

4. Aplicación en otros entornos

Como ya hemos mencionado anteriormente aunque las guías están orientadas a los instrumentos equipados con software incluidos en las regulaciones de la MID, los resultados son de carácter general y pueden aplicarse en otros ámbitos. En ese sentido el CEM ha aplicado la guía WELMEC 7.2 [12] junto con la norma UNE 199141-1-2013 [15] y UNE 199141-2-2013 [16] para evaluar un sistema de control y sanción de vehículos que circulan por zonas de acceso restringido, por ejemplo por temas medioambientales, en adelante lo denominaremos SCSV

Un SCSV aunque no es un sistema de medida como tal, se podría considerar como un sistema de lógica booleana en que las medidas se corresponden con circulación de vehículo autorizado y circulación de vehículo no autorizado y por lo tanto sancionable.

Consta principalmente de un ordenador en centro de control con el que se comunica una red de ordenadores localizados en diferentes puntos de la zona restringida. A cada ordenador local se pueden conectar varios sistemas de captura de imágenes, compuestos normalmente por dos cámaras y un lector OCR. Véase figura 8.

El funcionamiento es el siguiente, cada vez que un sistema de captura detecta un vehículo e identifica la matricula, envía la información al ordenador local al que está conectado. En el ordenador local hay un listado de matrículas clasificadas por tipo de vehículo desde un punto de vista medioambiental. En caso de que la matricula recibida pueda dar origen a una potencial sanción, el ordenador local solicita al sistema de captura las imágenes que evidencian la sanción. Periódicamente los ordenadores locales envían al ordenador central la información de las potenciales sanciones. El ordenador central comprueba en una lista de exclusiones cuales de las potenciales sanciones son sanciones reales. Dicha lista del ordenador central incluye los vehículos con autorización para la entrada por diferentes motivos.

Por supuesto toda la transmisión de información entre sistemas de captura, ordenadores locales y ordenador central se realiza mediante comunicaciones seguras y ficheros firmados con claves de acceso.

El sistema normalmente es tipo U y se evalúan las extensiones:

• L: Almacenamiento de datos a largo plazo
• T: Transmisión de datos vía redes
• S: Separación de Software

5. Conclusiones

Desde la entrada en vigor del Real Decreto 889/2006 [5] el 30 de octubre de 2006, la certificación del software forma parte de la evaluación de los instrumentos de medida al igual que ya se evaluaban los entorno climáticos, mecánicos o electromagnéticos. El software cada vez toma más importancia en la evaluación de los instrumentos de medida debido a los avances tecnológicos y se prevé que su importancia en el futuro ira en aumento.

No solo se han evaluado instrumentos incluidos en la MID como contadores eléctricos, contadores de agua, instrumentos de pesaje, etc., sino otros instrumentos con legislación nacional exclusiva como cinemómetros, etilómetros, sonómetros. Etc.

Las guías WELMEC constituyen una buena herramienta de apoyo para la evaluación permitiendo a todos los actores conocer los requisitos, ejemplos de cumplimiento y la forma de evaluarlos.

En definitiva la implantación de la evaluación del software de instrumentos de medida llegó para quedarse y es una realidad desde hace mucho más de una década.