O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
TESTING DE SOFTWARE EN INSTRUMENTOS DE PESAR DE
FUNCIONAMIENTO NO AUTOMATICO
Disertante:
Téc. Angel Vicente Nuñez
Física y...
CONSIDERACIONES INICIALES
Protección contra
la adulteración del
software
Vs Protección contra
el uso fraudulento
Son conce...
CONSIDERACIONES INICIALES
Protección contra el uso fraudulento.
Es la capacidad que tiene un instrumento de evitar que se ...
CONSIDERACIONES INICIALES
Cual es el objetivo de una aprobación de modelo?
Verificar que una muestra cumpla con los requis...
CONSIDERACIONES INICIALES
Que debemos verificar en una rutina de aprobación de modelo?
1. Verificar que la muestra se corr...
CONSIDERACIONES INICIALES
En los instrumentos electrónicos actuales, el funcionamiento depende, en
un gran porcentaje, del...
PROCEDIMIENTO
Que hacemos en INTI para verificar que la muestra se corresponda con
la documentación descriptiva entregada?...
Pero si el fabricante describe que el parámetro F sirve para modificar el nivel de
filtrado, que 0 sirve para ambientes en...
PROCEDIMIENTO
3. El funcionamiento cumpla con todos los requisitos del reglamento.
4. Que la actualización del software no...
PROCEDIMIENTO
Como se puede evaluar el software?
Existen dos métodos fundamentales de evaluación:
Como caja negra.
Solo se...
Como caja blanca.
Consiste en analizar el código fuente.
Es un método muy laborioso, pero permite detectar funciones que n...
Que buscamos cuando verificamos que el funcionamiento cumpla con todos los
requisitos del reglamento?
Se busca, analizando...
PROCEDIMIENTO
Características que no pueden ser alteradas mediante las maniobras antes
mencionadas:
•Valor indicado ya sea...
PROCEDIMIENTO
o Alteren la posición de las indicaciones (por ejemplo en una pantalla LCD).
o Alteren el estado de ajuste d...
METODOLOGIA
Métodos de verificación (ref. OIML D031 6.3)
1.Análisis de la documentación y la especificación, y validación ...
1.Análisis de la documentación y la especificación, y validación del diseño
METODOLOGIA
Aplicación:
Se trata del procedimi...
c. En lo relativo a las interfaces, la documentación incluirá una lista completa
de comandos o señales que el software pue...
METODOLOGIA
Descripción:
El examinador evalúa las funciones y las características del instrumento,
utilizando la descripci...
METODOLOGIA
2. Validación mediante ensayo funcional de las funciones metrológicas (VFTM)
Aplicación:
Adecuación de algorit...
METODOLOGIA
Descripción:
La mayoría de los métodos de aprobación de modelo y de ensayo se basan en
medidas de referencia e...
METODOLOGIA
3. Validación mediante el ensayo funcional de las funciones del software
(VFTSw)
Aplicación:
Validación, por e...
METODOLOGIA
Descripción:
En la práctica se comprueban las características requeridas descritas en el
manual de funcionamie...
METODOLOGIA
• la efectividad de la protección de los datos almacenados puede comprobarse
modificando algunos datos del arc...
Terminou este documento.
Transfira e leia offline.
Próximos SlideShares
Seguridad de sistemas embebidos para el ámbito regulado - Alejandro Bertello Gustavo Escudero
Avançar
Próximos SlideShares
Seguridad de sistemas embebidos para el ámbito regulado - Alejandro Bertello Gustavo Escudero
Avançar
Transfira para ler offline e ver em ecrã inteiro.

Compartilhar

Testing de software en instrumentos de pesar de funcionamiento no automatico - Angel Vicente Nuñez

Baixar para ler offline

Palestra proferida por Angel Vicente Nuñez no I Workshop Interamericano de Segurança de Software e Hardware em Metrologia Legal

  • Seja a primeira pessoa a gostar disto

Testing de software en instrumentos de pesar de funcionamiento no automatico - Angel Vicente Nuñez

  1. 1. TESTING DE SOFTWARE EN INSTRUMENTOS DE PESAR DE FUNCIONAMIENTO NO AUTOMATICO Disertante: Téc. Angel Vicente Nuñez Física y Metrología – Masa - Aprobación de modelos de balanzas
  2. 2. CONSIDERACIONES INICIALES Protección contra la adulteración del software Vs Protección contra el uso fraudulento Son conceptos distintos a pesar de que la protección contra el uso fraudulento este vinculada con el software en un alto porcentaje. Protección contra la adulteración del software Es la capacidad que tiene un instrumento de evitar que su software sea adulterado. Depende del grado de protección contra su adulteración que tenga la memoria donde se encuentra almacenado y de los mecanismos implementados para actualizarlo o reinstalarlo.
  3. 3. CONSIDERACIONES INICIALES Protección contra el uso fraudulento. Es la capacidad que tiene un instrumento de evitar que se pueda hacer uso fraudulento. La parte vinculada al software, tiene que ver con los mecanismos de seguridad implementados en el mismo para evitar que las características legalmente relevantes sean adulteradas sin dejar evidencia.
  4. 4. CONSIDERACIONES INICIALES Cual es el objetivo de una aprobación de modelo? Verificar que una muestra cumpla con los requisitos del reglamento aplicable. Que evidencias se conservan para determinar si un modelo fue aprobado o no? Una documentación que describe sus partes constitutivas y su funcionamiento, mas un protocolo de ensayos donde se evidencia el cumplimiento con los requisitos aplicables, mas una disposición emitida por la autoridad de aplicación que otorga la aprobación del modelo.
  5. 5. CONSIDERACIONES INICIALES Que debemos verificar en una rutina de aprobación de modelo? 1. Verificar que la muestra se corresponda con la documentación descriptiva entregada. 1.1. Partes constitutivas. 1.2. Funcionamiento (modo de uso y prestaciones). 2. Verificar que se cumpla con todos lo requisitos de reglamento aplicable.
  6. 6. CONSIDERACIONES INICIALES En los instrumentos electrónicos actuales, el funcionamiento depende, en un gran porcentaje, del software que tiene incorporado (firmware). Por otro lado los errores metrológicos, si bien dependen en gran porcentaje de la calidad del sensor que se utilice y la electrónica asociada, también pueden disminuirse utilizando algoritmos de corrección que se implementan en el firmware
  7. 7. PROCEDIMIENTO Que hacemos en INTI para verificar que la muestra se corresponda con la documentación descriptiva entregada? (en lo relacionado con el firmware). 1. Todas las funciones (tanto accesibles al usuario como al técnico) estén claramente descriptas. Verificamos que: 2. Todos los parámetros ajustables estén claramente descriptos (tanto el “para qué sirve” como el “cómo se configura”). Por ejemplo, supongamos que existe un parámetro configurable que se llama F y se puede configurar con valores entre 0 y 10. Si el fabricante no describe el “para que sirve”, deberá definir un valor, se ensaya el prototipo para aprobación de modelo configurándolo con ese valor y todas las unidades fabricadas también deberán estar configuradas con el mismo valor. De todos modos debe describir “como se configura”.
  8. 8. Pero si el fabricante describe que el parámetro F sirve para modificar el nivel de filtrado, que 0 sirve para ambientes en que no hay vibraciones ni ruidos electromagnéticos y a medida que configuramos valores más altos, se pueden filtrar mejor los ruidos, entonces ya sabemos que es un parámetro importante y que puede afectar el comportamiento metrológico del instrumento, pero también sabemos que no puede tener un valor único para todas las unidades que se fabriquen. PROCEDIMIENTO Si además, se describe que (por ejemplo) para modificar el parámetro F se debe romper un precinto, retirar la tapa del gabinete, accionar un interruptor, presionar una tecla determinada la cual mostrará un menú en el cual (dentro de una lista) está el parámetro F, que con otra tecla determinada podemos selecciónalo, luego escribimos un valor entre 0 y 10 y con otra tecla guardamos el nuevo valor, entonces ya sabemos el “cómo se configura”.
  9. 9. PROCEDIMIENTO 3. El funcionamiento cumpla con todos los requisitos del reglamento. 4. Que la actualización del software no pueda realizarse sin dejar evidencia. En este aspecto hay que tener en cuenta que: a) cuando el software se sustituye por otra versión (aunque sea aprobada) estamos ante una modificación del instrumento. b) cuando se vuelve a instalar la misma versión estamos ante una reparación del instrumento de medida. de estas situaciones puede darse sin que el organismo de aplicación del reglamento esté notificado. Ninguna de estas situaciones puede darse sin que el organismo de aplicación del reglamento esté notificado.
  10. 10. PROCEDIMIENTO Como se puede evaluar el software? Existen dos métodos fundamentales de evaluación: Como caja negra. Solo se analiza el funcionamiento. Si, de acuerdo a lo documentado y las pruebas practicas realizadas, todos los requisitos del reglamento aplicable se cumplen, entonces el software es aceptado (concuerda con OIML D031 5.2.5 nivel a). Si las sucesivas unidades fabricadas funcionan de acuerdo a lo documentado, en consecuencia, conforme al prototipo ensayado en aprobación de modelo, se acepta. Con este método de evaluación, no se pueden detectar funciones ocultas. Solo se puede analizar lo que el fabricante documenta.
  11. 11. Como caja blanca. Consiste en analizar el código fuente. Es un método muy laborioso, pero permite detectar funciones que no están documentadas. En argentina se usa el método de caja negra. PROCEDIMIENTO
  12. 12. Que buscamos cuando verificamos que el funcionamiento cumpla con todos los requisitos del reglamento? Se busca, analizando la documentación y haciendo pruebas de funcionamiento, que no exista alguna maniobra que pueda realizarse, sin dejar evidencia, que permita alterar una configuración o acceder a una función mediante la cual se pueda lograr que el instrumento deje de cumplir con algún requisito establecido en el reglamento. Las maniobras que se analizan son aquellas que se pueden realizar mediante un teclado, perillas, botones, enviando comandos a través de una interfaz óptica (por ej. Lectores de código de barras), eléctrica (por ej. Puertos serie, paralelos, IEEE488, Ethernet, etc.). PROCEDIMIENTO
  13. 13. PROCEDIMIENTO Características que no pueden ser alteradas mediante las maniobras antes mencionadas: •Valor indicado ya sea peso bruto o peso neto durante cualquier intervalo de tiempo dentro del que transcurre una pesada. •Condición de apagado o encendido de la visualización del valor de tara. •Parámetros que: o Determinen el nivel de filtrado de oscilaciones de una indicación de peso. o Activen o desactiven los indicadores de tara activa, centro de cero o capacidad máxima alcanzada. o Activen o desactiven el dispositivo de puesta en cero automático o sus valores característicos. o Modifiquen la función de las señales indicadoras.
  14. 14. PROCEDIMIENTO o Alteren la posición de las indicaciones (por ejemplo en una pantalla LCD). o Alteren el estado de ajuste del instrumento. o Alteren el rango de funcionamiento del comando de puesta a cero. o Alteren la función de los comandos de puesta a cero o tara.
  15. 15. METODOLOGIA Métodos de verificación (ref. OIML D031 6.3) 1.Análisis de la documentación y la especificación, y validación del diseño 2. Validación mediante ensayo funcional de las funciones metrológicas (VFTM) 3. Validación mediante el ensayo funcional de las funciones del software (VFTSw)
  16. 16. 1.Análisis de la documentación y la especificación, y validación del diseño METODOLOGIA Aplicación: Se trata del procedimiento básico aplicable en cualquier situación. Condiciones previas: El procedimiento se basa en la documentación del fabricante del instrumento. En función de los requisitos, esta documentación debe contener: a. especificación de las funciones del instrumento accesibles externamente de forma general. Todas las características son verificables mediante ensayos funcionales. b. Especificación de las funciones del software. La descripción mostrará y explicará toda función del software que pueda repercutir en las características metrológicas (por ej. algoritmos de filtrado).
  17. 17. c. En lo relativo a las interfaces, la documentación incluirá una lista completa de comandos o señales que el software puede interpretar. El efecto de cada comando se debe documentar detalladamente. Se describirá la reacción del instrumento ante comandos no documentados (puede responder no haciendo nada, con un código que indica comando no reconocido, etc.). d. Si resulta necesario para comprender y evaluar las funciones del software, se aportará documentación adicional del mismo para comprender y evaluar algoritmos de medida complejos, funciones criptográficas o restricciones de tiempo determinantes, etc. e. Cuando el modo de validación de la función de un programa de software no sea evidente, el fabricante tiene la responsabilidad de desarrollar un método de ensayo. Además, los servicios del programador deberían estar a disposición del evaluador con la finalidad de dar respuesta a las preguntas. Una condición previa general para llevar a cabo el examen es una declaración de completitud de la documentación. METODOLOGIA
  18. 18. METODOLOGIA Descripción: El examinador evalúa las funciones y las características del instrumento, utilizando la descripción escrita y las representaciones gráficas, y decide si éstas cumplen con los requisitos del reglamento. Los requisitos metrológicos, así como los requisitos funcionales del software (p. ej. protección contra el fraude, protección de los parámetros de ajuste, funciones anuladas, comunicación con otros dispositivos, actualización del software, detección de fallos, etc.) se deben considerar y evaluar.
  19. 19. METODOLOGIA 2. Validación mediante ensayo funcional de las funciones metrológicas (VFTM) Aplicación: Adecuación de algoritmos para el cálculo del valor de medida de datos sin procesar, para la linealización de una característica, compensación de influencias medioambientales, redondeo en el cálculo del precio, etc. Condiciones previas: Manual de funcionamiento, referencias metrológicas y equipamiento de ensayo.
  20. 20. METODOLOGIA Descripción: La mayoría de los métodos de aprobación de modelo y de ensayo se basan en medidas de referencia en diversas condiciones. Aunque en principio no esté destinada a validar el software, el resultado del ensayo se puede interpretar como una validación de algunas partes del mismo, suele ser incluso la más importante desde el punto de vista metrológico. Si los ensayos descritos en el reglamento abarcan todas las características metrológicas, las partes del software correspondientes pueden considerarse validadas. Por lo general, no se debe aplicar ningún análisis o ensayo de software adicional para validar las características metrológicas de los instrumentos.
  21. 21. METODOLOGIA 3. Validación mediante el ensayo funcional de las funciones del software (VFTSw) Aplicación: Validación, por ejemplo, de la protección de parámetros, la indicación de una identificación del software, la detección de fallos mediante software, funcionamiento de instrumento acorde a lo documentado. Condiciones previas: Manual de funcionamiento, documentación del software, patrón de funcionamiento, equipo de ensayo.
  22. 22. METODOLOGIA Descripción: En la práctica se comprueban las características requeridas descritas en el manual de funcionamiento, en la documentación del instrumento o en la documentación del software. Si están controladas por software, deben considerarse como validadas si su funcionamiento es correcto sin análisis de software posteriores. Las características a las que se hace referencia son, por ejemplo: • el funcionamiento normal del instrumento. Se deberían utilizar todos los interruptores o las teclas, así como las combinaciones descritas, y evaluar la reacción del instrumento. En las interfaces gráficas del usuario, se deberían activar y comprobar todos los menús y otros elementos gráficos; • la efectividad de la protección de parámetros puede comprobarse activando los medios de protección e intentando modificar un parámetro;
  23. 23. METODOLOGIA • la efectividad de la protección de los datos almacenados puede comprobarse modificando algunos datos del archivo y, posteriormente, comprobando si el programa lo detecta; • si la detección de fallos se realiza mediante software, las partes relevantes del software se pueden validar provocando, implementando o simulando un fallo y comprobando si la reacción del instrumento es correcta;

Palestra proferida por Angel Vicente Nuñez no I Workshop Interamericano de Segurança de Software e Hardware em Metrologia Legal

Vistos

Vistos totais

699

No Slideshare

0

De incorporações

0

Número de incorporações

7

Ações

Baixados

5

Compartilhados

0

Comentários

0

Curtir

0

×