guía documental para la verificación de inocuidad en base a la … · 2020-01-16 · 1 de 16 km...
TRANSCRIPT
1 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
El Marqués, Qro., a 15 de enero de 2020
Guía Documental para la verificación de Inocuidad
en base a la Norma Oficial Mexicana NOM-185-SCFI-2017
Este documento es una guía para la Empresa (fabricante o distribuidor) encargada de la elaboración
de la documentación que deberán presentar para la verificación de la Inocuidad a los Sistemas de
Control a Distancia (SCD) y las Interfaces de comunicación (IC), vinculados a Sistemas para
Medición y Despacho de gasolina y otros combustibles líquidos (SMD).
I. Se debe integrar la información solicitada en los siguientes tres documentos:
a. El manual Documento General para la verificación de Inocuidad en base a la NOM-185-SCFI-
2017. Es este manual se le proporciona al Cenam la información que solicitan los incisos de la
NOM-185-SCFI-2017 aplicables. Ver página 4 de este documento.
b. El Manual de Usuario y Configuración. Es el manual que se le proporciona a los clientes de la
Empresa para la correcta utilización y configuración del SCD y la IC.
c. El Procedimiento para la Verificación en Campo. Es el manual que se le proporciona a la
autoridad de vigilancia (PROFECO) para la correcta verificación de los siguientes datos: Número
de versión de software (identificación) y el procedimiento de autenticación del mismo mediante la
suma de comprobación binaria con el algoritmo MD5 de todos los módulos de software
legalmente relevantes. Para tener mayores detalles de este procedimiento se debe consultar la
explicación del inciso 5.3.3.
II. El formato de los documentos, debe contener (al menos) los elementos que se incluyen en el
ejemplo de formato de la figura 1 de este documento. En ningún caso debe utilizarse el logotipo
del CENAM en el membrete. Ver página 2.
III. En la integración de la información, se debe seguir el orden de los incisos. Es importante considerar
que, de acuerdo con la NOM-185-SCFI-2017, el Software Legalmente Relevante lo componen:
Todos los módulos de software responsables de la comunicación directa (armado y recepción
de comandos) con:
o Los SMD.
o Las IC que se encuentran intermedias al SMD y los SCD, donde las IC pueden ser de
fabricación propia o fabricadas por terceros.
El módulo de software responsable de la seguridad, es decir, la validación (verificación)
dinámica de la autenticidad (integridad) de todos los demás módulos de software legalmente
relevantes.
En caso de emplear IC fabricadas por terceros, estas deben verificarse previamente a los SCD.
2 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Figura 1 Ejemplo de formato (Hoja tamaño carta)
Logotipo de la Empresa Título del Documento
Ejemplo: "Documento General para la Verificación de la Inocuidad"
Logotipo del SCD o IC
Nombre de la Empresa Número para llevar el control de las revisiones de
la documentación Nombre del SCD o IC
Información
Domicilio de la Empresa Paginación
(# de página de # total de páginas)
Datos de contacto de la Empresa
(teléfono, correo electrónico, página de
internet, etc.)
3 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Otro aspecto importante a considerar, son las tres capas o estructuras principales que establece la
NOM-185-SCFI-2017: la Interfaz de Usuario, la Interfaz de Comunicación y la Interfaz de Software,
para las cuales se debe entender lo siguiente:
Interfaz de Comunicación. Se refiere a todo el código fuente responsable de gestionar el
protocolo de comunicación (incluyendo y dando énfasis al armado y la recepción de comandos)
de entrada y salida, con los SMD, IC y SCD:
Interfaz de Usuario. Se refiere a todo el código fuente responsable de generar formas gráficas
por medio de las cuales el usuario puede interactuar con la IC y/o SCD.
Interfaz de Software. Se refiere a todo el código fuente responsable de transmitir información
relacionada con los SMD entre la Interfaz de Usuario y la Interfaz de Comunicación.
4 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Incisos requeridos en la integración del manual “Documento General para la verificación de Inocuidad
en base a la NOM-185-SCFI-2017” para los Sistemas de Control a Distancia (SCD) y las Interfaces
de comunicación (IC), vinculados a Sistemas para Medición y Despacho de gasolina y otros
combustibles líquidos (SMD)..
Para la referencia del contexto global de cada inciso, refiérase a la norma oficial mexicana NOM-SCFI-
185-2017.
----------------------------------------------------------------------------------------------------------------------------------------
5. Requisitos y especificaciones generales para la evaluación del software de los instrumentos
o sistemas de medición.
5.1. Documentación.
5.1.1. Formato de la documentación.
5.1.1.1. En idioma español, salvo el código fuente referido en los incisos 5.3.8.5, 5.5.7.3,
5.6.6.2, 5.7.5.4 y 5.8.8.4 de esta Norma Oficial Mexicana, el cual puede mostrarse en idioma
inglés, en las instalaciones que indique el fabricante.
Toda información presentada para la verificación debe de estar en idioma español.
Es posible utilizar términos en otros idiomas, siempre y cuando resulte en un mayor beneficio para la
verificación, en estos casos se debe incluir el significado de dicho término (mediante una nota al pie de
página).
5.1.1.2. En formato electrónico, legible mediante un procesador de texto o similar. En caso de
que los archivos que contienen la documentación tengan un formato electrónico que sea
propietario, el fabricante debe proveer los medios y licencia para su lectura.
La información debe estar en un formato electrónico libre. Se recomienda entregar su información en
formato .pdf, ya que es un formato electrónico, no propietario (ISO/IEC 32000-1:2008) y no editable.
Los documentos en formatos de Microsoft Office, son propietarios y serán utilizados para su verificación
solamente si se proporciona la licencia para su lectura.
5.1.2.1. La descripción del software legalmente relevante y de cada una de sus funciones.
Se deben de describir, de una forma general, todas las funcionalidades que tiene el SCD sobre los
SMD.
5.1.2.4. Mostrar el código fuente requerido en los incisos 5.3.8.5, 5.5.7.3, 5.6.6.2, 5.7.5.4 y
5.8.8.4 de esta Norma Oficial Mexicana.
La inspección y revisión de código se llevará a cabo durante la verificación en sitio.
Las revisiones de los códigos fuentes referidos en este inciso se vuelven a pedir posteriormente para
su revisión en sus respectivos incisos de la norma.
5 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
5.1.2.5. Estructuras de los datos relevantes y no relevantes y el significado de ambos. Nota:
La estructura de datos se refiere a los tipos de datos, los vínculos o relaciones y las
restricciones que deben cumplir esos datos.
Se deben declarar los intervalos de valores válidos, es decir, los límites máximos y mínimos que el SCD
tiene para:
Los cambios de precios de los productos por unidad de volumen:
o Inmediato.
o Programado.
Los prefijados:
o Por monto de dinero.
o Por volumen.
Los totalizadores:
o De dinero.
o De volumen.
Todos los demás valores que se comuniquen con:
o Los SMD.
o Las cajas de interfaz de comunicación intermediarias:
De fabricación propia.
Fabricadas por terceros.
La validación de estos límites se debe encontrar implementada en el software legalmente relevante, no
está permitido que la única validación se encuentre en el software legalmente no relevante (interfaces
que quedan no aseguradas).
Para facilitar la verificación se deben identificar claramente estas variables en el código fuente, para
ello se debe especificar:
El módulo donde es definida.
El tipo de variable.
El nombre de la variable en el código fuente.
El valor nominal.
La base de datos y el campo donde es almacenada (para el caso del cambio de precio
programado).
Si los límites no son iguales para todas las configuraciones que el SCD maneje con las diferentes cajas
de interfaz y con los SMD, se deberán de declarar por separado (por configuración).
5.1.2.7. Las listas de los comandos requeridas en los incisos 5.7.5.1 y 5.8.8.1 de esta Norma
Oficial Mexicana.
Se debe incluir sencillamente una referencia a los incisos correspondientes donde se encuentre
descrita la información solicitada.
6 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
5.1.2.9. Descripción física y funcional de la interfaz de usuario; de la interfaz del software; y de
la interfaz de comunicación.
Se debe describir, de una forma general: la Interfaz de Usuario, la Interfaz de Software y la Interfaz de
Comunicación. Se recomienda incluir un diagrama a bloques en donde se describa la interacción de
todos los módulos de software teniendo en cuenta estas tres interfaces y distinguiendo los legalmente
relevantes de los legalmente no relevantes.
5.1.2.10. Las descripciones de los comandos y sus efectos requeridas en los incisos 5.7.5.2 y
5.8.8.2 en esta Norma Oficial Mexicana.
Se debe incluir sencillamente una referencia a los incisos correspondientes donde se encuentre
descrita la información solicitada.
5.1.2.12. Las sumas de comprobación binaria correspondientes a las versiones del software
legalmente relevante. El método criptográfico utilizado para el cálculo de la suma de
comprobación binaria debe ser el MD5.
Se deben declarar todos los módulos de software legalmente relevantes, se recomienda elaborar una
tabla que contenga:
El nombre del módulo.
El número de versión que lo identifica.
La suma de comprobación binaria por el método de reducción criptográfica MD5 a 128 bits.
5.1.2.13. La descripción del hardware del instrumento o sistema de medición, la cual debe
incluir:
5.1.2.13.1. Plataforma de desarrollo electrónico para el procesamiento de información, esto
es, si la arquitectura de hardware está basada en un microprocesador, un
microcontrolador, o algún otro dispositivo lógico programable, y
Se deben describir, de una forma general, todos los componentes de la arquitectura de hardware del
SCD, incluyendo:
Computadoras de propósito general (y sus componentes).
Hardware de propósito específico (y sus componentes).
Se recomienda incluir un diagrama que muestre la relación entre los componentes. Las descripciones
de los componentes electrónicos deben ser más detalladas cuando se trate de:
Componentes de comunicación (tarjetas de comunicación, convertidores de protocolos).
Componentes de interfaz de usuario (pantallas, terminales, dispositivos móviles).
Componentes de identificación vehicular.
Componentes de almacenamiento (memorias, HDD).
Componentes de procesamiento (CPU, microcontroladores).
7 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
5.1.2.13.2. Los puertos y protocolos de comunicación.
Se deben describir, de una forma general, todas las interfaces de comunicación de la solución final.
Se recomienda incluir un diagrama que muestre la comunicación entre los componentes externos, si
existen múltiples, se debe elaborar uno o varios diagramas que muestres todas las configuraciones.
Las descripciones de las interfaces de comunicación deben incluir:
Los parámetros de configuración de la comunicación.
El número máximo de dispositivos (cajas de interfaz y SMD) que se pueden conectar.
5.1.2.14. Manuales de usuario y de configuración.
Se debe proporcionar, en un documento aparte y en formato electrónico, los Manuales de Usuario y
Configuración; los manuales que son proporcionados a los clientes de la Empresa en verificación para
la correcta utilización y configuración del SCD.
Además de proporcionar los manuales, se debe de incluir en el documento general, en el inciso
5.1.2.14., las referencias precisas de estos manuales incluyendo por cada manual:
El nombre de archivo.
La suma de reducción criptográfica MD5.
5.1.2.17. La documentación particular señalada en los incisos 5.3.8, 5.5.7, 5.6.6.2, 5.7.5, 5.8.8,
5.14.6 y 5.22.2 de esta Norma Oficial Mexicana.
Se deben incluir sencillamente las referencias a los incisos correspondientes donde se encuentre
descrita la información solicitada.
5.2. Configuración para un instrumento o sistema de medición tipo U.
5.2.1. Configuración del hardware.
5.2.1.1. El fabricante debe describir la configuración del hardware de la computadora de
propósito general necesaria para el correcto funcionamiento del instrumento o sistema de
medición.
Se debe describir todo el hardware necesario para que el SCD opere idealmente.
La descripción debe incluir marca, familia y modelo de todos los componentes de hardware:
Computadoras de propósito general (y sus componentes).
Hardware de propósito específico (y sus componentes).
Las descripciones de los componentes electrónicos deben ser más detalladas cuando se trate de:
Componentes de comunicación (cajas de interfaz, convertidores de protocolos, tarjetas de
comunicación, etc.).
Componentes de interfaz de usuario (dispositivos móviles, pantallas, quioscos, terminales,
TPVs, etc.)
8 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Componentes de identificación vehicular (anillos, antenas, aros, códigos de barras, hologramas,
escáneres, estampas, etiquetas, RFID-tags, lectores, etc.)
Componentes de almacenamiento (discos duros, memorias, etc.)
Componentes de procesamiento (CPUs, microprocesadores, microcontroladores, etc.)
Componentes varios (equipo de tele-medición de tanques, impresoras, etc.)
5.2.2. Configuración del software.
5.2.2.1. Se debe describir la configuración del sistema operativo y los módulos de software.
Dicha descripción debe incluir marca y número de versión.
Se debe describir todo el software necesario para que el SCD opere idealmente.
La descripción debe incluir marca, familia y modelo de todos los componentes de:
Softwares.
Firmwares.
Sistemas operativos.
Aplicaciones, utilerías, dependencias, paquetes informáticos, archivos de sistema.
Módulos opcionales y cualquier programa adicional.
Que son necesarios para el correcto funcionamiento del SCD.
5.3. Identificación del software legalmente relevante de los instrumentos o sistemas de medición
Tipo P y Tipo U.
5.3.1. El software debe estar identificado con el número de versión.
Todos los módulos de software legalmente relevantes deben contar con versión que los identifique, se
deben declarar los números de versión que los identifican.
5.3.2. El fabricante debe describir los medios de protección implementados para impedir la
falsificación de la identificación.
Se deben describir todas las medidas de seguridad implementadas para impedir la modificación de la
identificación de cualquiera de los módulos de software legalmente relevantes.
La descripción debe incluir qué medidas de protección se tienen implementadas para evitar tener dos
instancias de softwares legalmente relevantes con el mismo MD5 pero diferente versión, y viceversa;
misma versión pero diferentes MD5.
5.3.3. El número de versión de software se debe presentar mediante un comando durante su
funcionamiento, o en la puesta en operación de un instrumento o sistema de medición que
pueda encenderse y apagarse de nuevo.
Se debe proporcionar, en un documento aparte y en formato electrónico, un procedimiento detallado
para la verificación en campo por parte de la entidad verificadora de:
9 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
La suma de comprobación binaria MD5.
El número de versión.
Dependiendo de la programación, se pueden tener dos opciones generales para los SCD:
Existe un módulo (vigilante) de software responsable de validar la autenticidad de todos los
demás módulos de software legalmente relevantes.
o Puede darse el caso, en el que, dependiendo de situaciones muy particulares, no se
pueda crear un módulo vigilante, en tal caso, la entidad encargada verificará la
autenticidad de cada uno de los módulos de software legalmente relevantes en las
estaciones de servicio.
Todo el SCD se encuentra compilado en un único módulo de software ejecutable.
La verificación de la autenticidad debe de hacerse desde el sistema operativo o desde una interfaz de
software legalmente relevante, mas no únicamente desde una interfaz de usuario legalmente no
relevante.
Este procedimiento debe ir guiando paso a paso al verificador partiendo desde la pantalla principal del
SCD (que sería lo primero que el verificador vería) a poder observar la versión y hasta obtener los
archivos legalmente relevantes para la verificación de su autenticidad.
El documento debe contener también el procedimiento para verificar que los archivos obtenidos
corresponden al software que se encuentra corriendo en la estación de servicio.
Es importante unificar la presentación de estos parámetros, para tener una mayor referencia de esta
unificación consultar el apartado ‘iii.’ de los lineamientos finales.
5.3.7. El algoritmo que genera la identificación debe cubrir todo el software.
Este inciso no es evaluado por el método de análisis documental, es verificado por medio del método
de inspección y revisión de código.
5.3.8. La documentación específica para la identificación del software debe incluir:
5.3.8.1. La identificación del software y la descripción de cómo se genera dicha identificación.
Se deben declarar los números de versión que identifican a todos los módulos de software legalmente
relevantes.
Se deben incluir las descripciones de cómo son generados los números de versión de todos los
módulos de software legalmente relevantes.
5.3.8.2. La descripción de cómo está unívocamente ligada al propio software.
Se debe describir cómo es que los números de versión que identifican a todos y cada uno de todos los
módulos de software legalmente relevantes se encuentran unívocamente ligados a los propios módulos
de software legalmente relevantes.
La descripción debe aclarar si la más mínima alteración de cualquiera de los módulos de software
legalmente relevantes resulta una alteración en la suma de comprobación binaria MD5 y en el número
de versión.
10 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
5.3.8.3. La descripción de cómo se visualiza y cómo se estructura para diferenciar entre
cambios de versión que necesiten o no certificación.
Se deben describir los pasos a seguir para visualizar el número de versión que identifica a cada uno
los módulos de software legalmente relevante.
Si existen diversas maneras de ver la versión de los módulos, se deben describir todas. Es
recomendable incluir impresiones de pantalla.
Se debe describir cómo está estructurada la versión, es decir, se debe explicar qué significan los
caracteres de la versión.
Se deben dar ejemplos por cada uno de los módulos de software legalmente relevantes, de manera
que se muestre la variación de los números con respecto a la versión anterior y a la versión posterior
del software.
Los ejemplos deben ser representativos de las versiones de los módulos a verificar.
5.3.8.4. Las medidas implementadas para proteger la identificación del software frente a la
falsificación y la descripción de dichas medidas.
Se deben describir todas las medidas de seguridad implementadas para impedir la modificación de la
identificación de todos los módulos de software legalmente relevantes.
La descripción debe aclarar si la más mínima alteración de cualquiera de los módulos de software
legalmente relevantes resulta una alteración en la suma de comprobación binaria MD5 y en el número
de versión.
5.3.8.5. Mostrar la parte del código fuente correspondiente a la generación de la identificación.
Este requisito es aplicable únicamente para el proceso de evaluación de software.
La inspección y revisión de código se llevará a cabo durante la verificación en sitio.
5.5. Protección del software legalmente relevante ante cambios no intencionados.
5.5.2. El software legalmente relevante, debe incluir un sellado a través de medios mecánicos,
electrónicos o criptográficos, que imposibilite cualquier intervención ilícita.
Se deben describir todas las medidas de seguridad implementadas para impedir la alteración de
cualquiera de los módulos de software legalmente relevantes.
5.5.4. El software debe solicitar una confirmación antes de modificar o borrar datos.
Este inciso no es evaluado por el método de análisis documental, es verificado por medio del método
de prueba de ensayo de software.
5.5.5. Los datos deben estar protegidos ante las modificaciones no intencionadas, mediante un
mensaje o señal de advertencia antes de la modificación.
11 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Se deben describir las confirmaciones que debe haber antes de la modificación o borrado de datos en
los SMD, como cambio de precio, totalizadores, factores, fecha, hora, usuarios, contraseñas, etc.
Es recomendable incluir impresiones de pantalla con los mensajes de las advertencias.
5.5.7. La documentación requerida para verificar la protección del software legalmente relevante
debe incluir:
5.5.7.1. La descripción de las medidas implementadas para proteger el software y los datos
frente a modificaciones no intencionadas.
Se deben describir todas las medidas de seguridad implementadas para impedir la alteración de
cualquiera de los módulos de software legalmente relevantes.
5.5.7.2. La suma de comprobación binaria del código del programa, así como de los
parámetros legalmente relevantes.
Se deben declarar todos los módulos de software legalmente relevantes, se recomienda elaborar una
tabla que contenga:
El nombre del módulo.
El número de versión que los identifica.
La suma de comprobación binaria por el método de reducción criptográfica MD5 a 128 bits.
5.5.7.3. Mostrar la parte del código fuente correspondiente a la protección de datos ante las
modificaciones no intencionadas. Este requisito es aplicable únicamente para la evaluación
del software.
La inspección y revisión de código se llevará a cabo durante la verificación en sitio.
5.5.7.4. La descripción de las medidas implementadas para comprobar la efectividad de la
protección.
Se deben describir las medidas de seguridad implementadas para impedir la alteración de cualquiera
de los módulos de software legalmente relevantes.
En el caso de la mínima alteración de cualquier módulo, el SCD debe, al menos, detener toda la
comunicación con las cajas de interfaz y con los SMD.
Es recomendable incluir impresiones de pantalla que muestren el comportamiento del SCD frente a las
modificaciones.
5.6. Protección contra actos ilícitos.
5.6.5. En los instrumentos o sistemas de medición tipo U en los que se cuente con un sistema
operativo y/o software accesible al usuario:
12 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
5.6.5.1. Se debe generar una suma de comprobación del código del programa de los módulos
de software.
Este inciso no es evaluado por el método de análisis documental, es verificado por medio del método
de inspección y revisión de código.
5.6.5.2. Con la suma de comprobación referida en el inciso 5.6.5.1, se debe comprobar la
autenticidad del software legalmente relevante y sólo permitir su ejecución en caso de que
dicha autenticidad sea válida.
Este inciso no es evaluado por el método de análisis documental, es verificado por medio del método
de inspección y revisión de código.
5.6.6. La documentación requerida para verificar la protección frente a las modificaciones ilícitas
debe incluir:
5.6.6.2. Mostrar la parte del código fuente correspondiente a la protección del software
legalmente relevante ante los cambios ilícitos. Este requisito es aplicable únicamente para
la evaluación del software.
La inspección y revisión de código se llevará a cabo durante la verificación en sitio.
5.7. Influencia sobre el software a través de la interfaz de usuario.
5.7.2. Los comandos introducidos a través de la interfaz de usuario no deben influir ilícitamente
en el software legalmente relevante ni en los datos de la medición.
Se deben describir las medidas de seguridad implementadas para evitar que los comandos introducidos
por la interfaz de usuario influyan de manera ilícita en el SCD y/o en los datos enviados al SMD.
5.7.5. La documentación requerida para la verificación de la influencia sobre el software a través
de la interfaz de usuario debe incluir:
5.7.5.1. La lista de todos los comandos.
Se debe incluir una la lista de todos los comandos que desde cualquier interfaz de usuario resultan en
una interacción con los SMD.
5.7.5.2. La descripción del significado de los comandos y su efecto en las funciones y datos
del instrumento o sistema de medición.
Se deben describir todos y cada uno de los comandos (incluyendo todas las formas gráficas y botones
físicos) que desde cualquier interfaz de usuario resultan en una interacción con los SMD.
13 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
5.7.5.4. Mostrar la parte del código fuente correspondiente a la interfaz de usuario. Este
requisito sólo es aplicable para la evaluación del software.
La inspección y revisión de código se llevará a cabo durante la verificación en sitio.
5.8. Influencia sobre el software a través de la interfaz de comunicación
5.8.1. Los comandos introducidos a través de las interfaces de comunicación del instrumento o
sistema de medición no deben influir ilícitamente en el software legalmente relevante ni en los
datos de la medición.
Este inciso no es evaluado por el método de análisis documental, es verificado por medio de los
métodos de análisis del flujo de datos metrológicos y la inspección y revisión de código.
5.8.2. Los comandos deben asignarse unívocamente a cada función.
Cada comando de la interfaz de comunicación debe resultar en una única acción concreta en los SMD,
se debe describir cómo se garantiza esta asignación.
Se debe declarar si existen comandos distintos que realicen aparentemente la misma función en el
SMD.
5.8.3. Los comandos deben actuar sólo sobre las interfaces de comunicación y sobre los códigos
en los protocolos de transmisión de datos documentados por el fabricante.
Este inciso no es evaluado por el método de análisis documental, es verificado por medio del método
de inspección y revisión de código.
5.8.6. La interfaz de comunicación que recibe o transmite comandos o datos legalmente
relevantes debe ser específica para esta función y únicamente puede ser utilizada por el
software legalmente relevante.
El SCD se comunica con los SMD a través de una interfaz de comunicación, esta interfaz debe ser
exclusiva y no deberá de estar compartida con otras interfaces. Se debe describir cómo está
implementada dicha exclusividad.
5.8.8. La documentación requerida para la verificación de la Influencia sobre el software a través
de interfaces de comunicación de los instrumentos o sistemas de medición debe incluir:
5.8.8.1. Una lista completa de todos los comandos.
Se debe incluir una la lista de todos los comandos de la interfaz de comunicación.
5.8.8.2. Una descripción del significado de cada comando y su efecto en las funciones y datos
del instrumento de medición.
14 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Se deben describir todos los comandos de la interfaz de comunicación.
5.8.8.3. El procedimiento que describe las pruebas de todos los comandos.
Se deben describir las condiciones que se necesitan reunir para que se envíe cada uno de los
comandos de la interfaz de comunicación.
Se recomienda elaborar una tabla o matriz para describir dichas condiciones por cada comando.
5.8.8.4. Mostrar la parte del código fuente correspondiente a la interfaz de comunicación. Este
requisito sólo es aplicable para la evaluación del software.
La inspección y revisión de código se llevará a cabo durante la verificación en sitio.
5.14. Autenticidad del software y presentación de los resultados.
5.14.2. La suma de comprobación binaria del software legalmente relevante debe coincidir con la
declarada por el fabricante.
Este inciso no es evaluado por el método de análisis documental, es verificado por medio de los
métodos de ensayo de software y la lectura del código del programa.
5.14.6. La documentación requerida para la verificación de la autenticidad del software y
presentación de los resultados debe incluir:
5.14.6.1. La descripción de las medidas implementadas para garantizar la autenticidad del
software.
Se deben describir las medidas de seguridad implementadas que garanticen que el SCD verificado es
el que está ejecutándose.
Se recomienda incluir impresiones de pantalla que muestren el comportamiento del SCD cuando falla
la validación de la autenticidad.
5.14.6.2. El resultado de la suma de comprobación binaria del software legalmente relevante.
Se deben declarar todos los módulos de software legalmente relevantes, se recomienda elaborar una
tabla que contenga:
El nombre del módulo.
El número de versión que los identifica.
La suma de comprobación binaria por el método de reducción criptográfica MD5 a 128 bits.
5.18. Compatibilidad de los sistemas operativos y hardware
5.18.1. El fabricante debe describir los medios implementados para evitar la operación del
instrumento o sistema de medición, si no son cumplidos los requisitos de configuración
señalados en los incisos 5.2.1.1 y 5.2.2.1.
15 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Basado en lo declarado en los incisos:
5.2.1.1. Los requisitos mínimos de hardware.
5.2.2.1. Los requisitos mínimos de software.
Requeridos para el correcto funcionamiento del SCD.
Se debe describir, por cada uno de estos requisitos, la reacción o el comportamiento del SCD en el
caso de que estos requerimientos:
No sean cumplidos o alcanzados.
En ausencia del requisito.
Es recomendable elaborar una tabla en donde se pueda observar más claramente, todos y cada uno
de los requerimientos de hardware y software, y el comportamiento del SCD ante a los requerimientos
por debajo del mínimo y frente a la ausencia del éstos.
Es recomendable, en los casos que aplique, incluir impresiones de pantalla de las reacciones del SCD
en dichos casos.
5.22. Integridad del software cargado en el instrumento o sistema de medición.
5.22.1. Antes de utilizar por primera vez el software cargado, el instrumento o sistema de medición
debe comprobar automáticamente que dicho software no se haya modificado. El fabricante
debe describir las medidas implementadas para cumplir con este requisito. Si el software
cargado no supera esta comprobación, se debe cumplir con los requisitos dispuestos en el
inciso 5.21.3.
Referencia: 5.21.3. Si la carga del software falla o se interrumpe, el estado original del instrumento o
sistema de medición no debe ser afectado. El instrumento o sistema de medición debe mostrar un
mensaje de error permanente e inhibir su funcionamiento metrológico hasta que se corrija la causa del
error.
Se deben describir las medidas de seguridad implementadas para impedir la alteración de cualquiera
de los módulos de software legalmente relevantes.
En el caso de la mínima alteración de cualquier módulo, el SCD debe, al menos, detener toda la
comunicación con los SMD.
Se recomienda incluir impresiones de pantalla que muestren el comportamiento del SCD cuando falla
la validación de la autenticidad.
5.22.2. La documentación requerida para la verificación de la integridad del software cargado
debe incluir:
5.22.2.1. La descripción de las medidas implementadas que garantizan la integridad del
software.
Se deben describir las medidas de seguridad implementadas que garanticen que el SCD verificado es
el que está ejecutándose.
16 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Se recomienda incluir impresiones de pantalla que muestren el comportamiento del SCD cuando falla
la validación de la autenticidad.
17 de 16 km 4.5 Carretera a los Cués, C.P. 76246, El Marqués, Querétaro t: (442) 2110500 al 04
Lineamientos finales para la elaboración de la documentación
I. Evitar referencias múltiples y redundantes.
II. Evitar la duplicidad de la información, en su lugar se pueden utilizar referencias a información
contenida en el mismo documento.
III. Verificar que todas las referencias sean exactas (incluyendo mayúsculas, minúsculas, acentos,
etc.) para:
Los nombres de archivos.
Los números de versión.
Las sumas de comprobación MD5.
Rutas de carpetas.
Incisos en el mismo documento.
Todos los demás archivos a los que se haga referencia.
Y estén unificadas (exactamente los mismos caracteres siempre) para su presentación en:
Todas las maneras de obtener la suma de comprobación MD5.
Todas las formas de observar el número de versión.
Todos los archivos físicos (incluyendo las rutas):
o Proporcionados para la verificación.
o Instalados en las estaciones de servicio.
Toda la documentación presentada para la verificación (las impresiones de pantalla
deben de estar actualizadas y unificadas), lo que constituye:
o El documento general.
o Los manuales.
o El procedimiento para la verificación en campo.
o Cualquier otro documento presentado en la verificación.
IV. Evitar incluir código fuente en el Documento General, el código fuente se revisará en la
verificación en sitio.
V. El documento puede contener imágenes y diagramas que ayuden a la descripción de los incisos, pero éstas deben estar optimizadas para evitar aumentar considerablemente el tamaño del documento.
VI. Es recomendable solicitar al CENAM, con al menos cinco días hábiles antes de la verificación
en sitio, aclaraciones a cuestiones pendientes, dudas y cualquier incertidumbre sobre los
requerimientos y disposiciones normativas sobre el servicio.
Estas aclaraciones pueden atenderse a través de alguna sesión virtual (video-conferencia) vía internet por Skype, con previa autorización del responsable de las verificaciones en el CENAM, quien le proporcionará los nombres de usuarios para que la Empresa pueda entrar en contacto de los verificadores asignados.