Equipos de referencia para la evaluación de software de medición por coordenadas con respecto a su implementación en conceptos GPS

Este trabajo se presentó en el Congreso de Metrología de 2017

En esta presentación se describe el concepto y se dan ejemplos de cotas particularmente importantes y críticas, que en muchos casos no se calculan correctamente de acuerdo a ISO GPS. Se presentan ejemplos de análisis de software en concreto. Para cada cota en los equipos existen soluciones de referencia para comparar y así concluir los algoritmos usados en el software bajo test. Sabiendo como calcula el software, se puede —si hace falta— aplicar correcciones a los resultados (‘work arounds’) para que se ajusten mejor a lo que pide la norma. Importante es saber cómo funciona el software y saber si se aplica correctamente tal software.

La idea fundamental de la serie de normas ‘ISO GPS’ es que se definan y se verifiquen especificaciones geométricas de productos de manera que se interpreten igual en todo el mundo. Así se puede asumir que no haya discrepancias en resultados de verificación; salvo las debidas a la incertidumbre de medición que deberían ser despreciables o contempladas de la misma manera que están descritas en la norma ISO 14253-1 sobre el tratamiento de incertidumbre de verificación en la aceptación de productos.

En la práctica hay obstáculos: por una parte, los paquetes de software no tienen siempre los conceptos teóricos de la GPS perfectamente implementados. Por otra parte, los usuarios no saben cómo están implementados estos conceptos y confían en los cálculos sin cuestionarlos. La situación está caracterizada por la falta de validación de software y la falta de transparencia por parte de los proveedores de software que tendrán que formar a los usuarios sobre ‘dónde hay deficiencias y cómo hacer el ‘work around’ para compensar estas deficiencias’, pero pocos lo hacen.

Podemos asumir que una vez que existan validaciones públicas, pronto habrá también una mejora de las deficiencias – justo como era el caso cuando el PTB, el INRIM, el NIST, y el NPL introdujeron la validación de Algoritmos de Mejor Ajuste Gauss a finales de los años 1980. También existe la necesidad de aclarar al usuario si su evaluación con un determinado paquete de software es correcto según reglas GPS, incluyendo no solo el software sino también su uso correcto.

2.1 Posibles conceptos para la validaciones de software GD&T/GPS

Hoy en día existen validaciones por lado de los Laboratorios Nacionales como el PTB Alemania para el cálculo de elementos Gauss y Elementos Tangenciales y de Mínima Zona. La empresa www.eumetron.de vende un equipo que se llama ‘Multi Feature Check’, que incorpora una multitud de cotas calibradas; pero ellos no pretenden evaluar la validez de cálculos si no la incertidumbre con la cual se mide estas cotas; los desvíos del nominal son pequeños, así no se nota problemas de algoritmos. No existe todavía una validación ‘completa’ de conformidad con ISO GPS. Por eso se estuvimos buscando un concepto de prueba a bajo coste, además de un concepto donde los costes de I&D de cada fase estuvieran recuperados en poco tiempo. En esta búsqueda nos encontramos confrontados entre otros con los siguientes aspectos:

• ¿Cómo garantizar que las pruebas que hace el laboratorio de testeo a distancia con data sets a evaluar por el software bajo prueba, eran realmente evaluados por este software? (en el concepto de evaluación de software que se practica hoy en día desde hace 20 años, eso no está garantizado)
• ¿Cómo permitir la prueba de los numerosos releases de paquetes de software?
• ¿Cómo incluir en la prueba la influencia del operador, que quizá no entiende cómo usar el software por falta de formación o por razón de complejidad del mismo software?
• ¿Cómo hacer el feed back al usuario de problemas o de que está evaluando bien?
• ¿Es posible validar por el operador mismo?
• ¿Cómo solo validar los aspectos que importan al operador en un cierto momento?
• ¿Cómo garantizar que las soluciones de referencia son correctas?
• ¿Cómo diseminar el servicio?
• ¿Cómo acreditar para el servicio? ¿Hay que acreditar, y para qué hay que acreditar?

Repasando estos aspectos se concluyó que es mandatorio que el usuario debe ser capaz de hacer las evaluaciones en cada momento, siempre que lo necesite y con poco esfuerzo. Existen dos posibles soluciones:

1. Facilitar datos de prueba, modelos CAD e instrucciones de medición; el problema es asegurar que los softwares permitan leer estos datos. Muchos no lo pueden. Una solución puede ser una medidora virtual/emulada con protocolo I++ que facilita los datos como que si fuese una medidora real. Protocolo I++ tienen prácticamente todos softwares.
2. Equipos de prueba en los cuales se incorporen cotas con desvíos tan grandes y conocidos que la incertidumbre de medición (real) sea despreciable en la validación.

Podemos excluir solución N° 1 porque requiere una instalación de software adicional en cada computadora de evaluación, lo que no es practicable (esfuerzo, seguridad, fallos). Quedan los equipos de prueba como en solución 1 practicable.

2.2 Cotas y pruebas realizados por los primeros equipos de referencia

Las pruebas más importantes para empezar son sin duda las referencias (‘datums’). por comentarios de usuarios sabemos que existen diferencias no despreciables entre los distintos paquetes de software. Fig. 1 aclara el caso de una referencia secundaria y terciaria. De la Norma ISO 1101 y la ISO 5459 sabemos que el plano secundario debe ser ‘tangencial exterior’. Eso significa evaluación con algoritmo ‘Mínima Zona’ y de ahí el plano exterior. Tradicionalmente algunos softwares evalúan simplemente con Gauss, otros con Gauss pero desplazan el plano Gauss hacia ‘fuera’ por la mitad del error de forma. Eso aproxima normalmente bien el plano tangencial… pero hay diferencias como vemos en la figura 1. Si los desvíos en la pieza de referencia están bien elegidos, sería posible averiguar del resultado según que algoritmo un software trabaja, y si es necesario, hacer un ‘work around’ (como por ejemplo desplazar el plano Gauss por 50% del error de forma). Hay softwares que no automáticamente evalúan elementos según Norma, pero el operario debe elegir el algoritmo adecuado al principio en la medición ‘manualmente’.

La figura 2 demuestra otro caso de una referencia. Aquí es el plano medio. Importante es que este plano medio no es el plano promedio de ambos lados calculados independientemente, sino simultáneamente. No son 2 planos Gauss, tampoco 2 planos tangenciales: son 2 planos tangenciales y paralelos entre sí con máxima distancia entre sí. Sabemos que es una tarea matemáticamente difícil y que pocos softwares lo hacen de manera correcta.

La figura 3 muestra un caso de una referencia combinada de dos cilindros con diámetros distintos. Importante es que este eje de referencia no es el eje promedio de ambos lados calculados independientemente, sino simultáneamente. No son 2 o 4 o más puntos en los ejes de los cuales se calcula un nuevo eje conjunto: son 2 cilindros inscritos, coaxiales, con diámetro máximo. Sabemos que es una tarea matemáticamente muy difícil y que pocos softwares lo hacen de manera correcta.

Se puede entender fácilmente qué consecuencias tendrán referencias erróneas en cotas como posición, simetría, perpendicularidad, paralelismo… Nos limitamos aquí a las referencias, aunque las piezas descritas en el siguiente apartado permiten analizar los cálculos de muchas más cosas.

Como resultado del análisis descrito en el apartado anterior, se puede construir mapas de desvíos en objetos prismáticos y cilíndricos que ‘fuerzan los resultados de diferentes cálculos en diferentes direcciones’ y así permitan concluir el tipo de algoritmo en cada caso. La figura 4 muestra el conjunto de desvíos superpuestos a los elementos nominales. Además de lo dicho antes, estos desvíos permiten evaluar cálculos de posición sin y con Condición de Máximo Material, en elementos tolerados y elementos de referencia, planicidad, cilindricidad, simetría, y más.

Si se define ‘cualquier’ desvío, va a ser difícil a juzgar si el software trabaja correcto sin tener un software de referencia ya comprobado. Por eso se ha definido los desvíos de una manera que permita relativamente fácilmente calcular a mano la mayoría de los resultados; en eso nos ayuda el principio tangencial: ‘solo importan puntos extremos’. Eso nos permite evaluar un software como software de referencia con datos sintéticos, no influenciados por errores aleatorios de una medición real. Obviamente este software de referencia debe permitir introducir valores de un fichero texto o Excel. Se está usado el software ‘Smart profile’ de la empresa Kotem como software de referencia.

Una vez comprobados los algoritmos del software de referencia, hemos sido capaces de evaluar con puntos reales (palpados), como por ejemplo con una MMC, y comparar los resultados, que en este caso se desvían algo de los calculados con desvíos programados en la máquina-herramienta que ha mecanizado la pieza de referencia.

El proceso de evaluar un software por cotas en concreto es el siguiente:

• Se importa el modelo CAD (IGES) de la pieza de referencia en el software a verificar,
• Se programa la medición de los puntos especificados en los elementos especificados,
• Se mide la pieza con la MMC
• Se importa al software de referencia los mismos puntos reales palpados y el modelo CAD (sin errores) de la pieza de referencia
• Se evalúan las mismas cotas con ambos softwares
• Se comparan resultados

Miramos a algunos resultados en concreto con dos paquetes de software. Como se ha dicho:

Un primer paso en este proyecto ha sido evaluar el software de referencia con puntos calculados; a partir de eso este software sirve como software de referencia. En la tabla 1, parte izquierda, se muestran los resultados para diversas cotas en la pieza para la verificación del software de referencia. Son los puntos con desvíos programados según figura 4, una vez evaluadas ‘manualmente’, una vez evaluadas con el software de referencia. En la tabla 1 parte derecha se muestra lo mismo, pero ahora con puntos reales palpados: una vez evaluando con el software de referencia y una vez con el software a validar. Vemos que no es exactamente lo mismo que resulta del software de referencia. Tenemos que confiar ahora en este software de referencia. Hemos visto que tenemos todavía que aumentar/exagerar los errores superpuestos a la geometría nominal en las piezas de prueba para ser capaces de despreciar efectos de la mecanización y de la medición que realmente no queremos estudiar, como efectos aleatorios.

¿Cómo interpretar la tabla 1? Todas las cotas salen como se esperaba con el software de referencia. Con el software a verificar vemos desvíos sustanciales, particularmente podemos concluir, que la simetría como referencia no se calcula de la misma manera que está definida en la norma ISO, el software de referencia lo hace bien como se comprobó con datos sintéticos.

Como segunda pieza se ha creado una pieza de referencia cilíndrica. Aquí nos limitamos para esta presentación a una cota importante: la referencia combinada de dos cilindros de diámetro diferente. La figura 4 muestra dos conjuntos de desvíos los cuales se ha implementado en diferentes piezas de prueba. A la izquierda son desvíos al interior de la pieza; obviamente no deberían tener efecto en el resultado, porque no influyen elementos tangenciales. En este caso fallaron todos los softwares, también el ‘software de referencia’. Ambos calculan cilindros medios en lugar de circunscritos (ver figura 3 para la explicación del problema). En un segundo experimento se evaluaron los puntos palpados en una medición en MMC de una pieza de referencia con los desvíos como se ve en figura 4 a la derecha, que representan un caso menos extremo. Los resultados del software que usamos de referencia eran ‘27 μm desvío de la coaxialidad’, que corresponden (con diferencia < 1 μm) a lo que se calcula a mano usando mejor ajuste Gauss. El segundo software bajo test daba ‘116 μm de desvío de la coaxialidad’, que era lejos de lo correcto, para sea el que sea el algoritmo usado, incluso Gauss. Podemos ver que el software de referencia usa en este caso (excepcionalmente) el ajuste Gauss para la referencia, siendo ésta una tarea para la cual es posible que ningún software lo haga mejor, es decir, siguiendo exactamente las reglas del sistema GPS (elementos tangenciales mínimos con respeto al material de la pieza con restricciones de parallelidad etc.).

Figura 5. Dos juegos de desvíos superpuestos a las geometrías nominales. (Pieza cilíndrica), a la izquierda los desvíos van ‘material adentro’, a la derecha ‘afuera’.

En las figuras 6 y 7 vemos las piezas realizadas durante su medición en MMC. Se pueden ver en el cilindro las huellas de los diferentes desvíos radiales. Con desvíos en forma de escaleras/pasos discretos, eso ayuda al programador que hace su programa por teach-in, a colocar los puntos de palpado. Es recomendable usar para la programación el modelo CAD, disponible para cada pieza.

Con las piezas de referencia presentadas es posible establecer confianza en los cálculos que hace el software de evaluación. Si resulta que no calcula un software según la norma, entonces el operario sabe que tiene que buscar ‘work arounds’ para efectuar mediciones comparables según norma ISO GPS. Las piezas de referencia son una herramienta de (auto-) aprendizaje para el uso correcto de software de medición. Estas piezas ayudan a que se verifiquen piezas de manera comparable en todo el mundo.

Referencias

[1] ISO 1101:2017, Geometrical product specifications (GPS) — Geometrical tolerancing — Tolerances of form, orientation, location and run-out

[2] ISO 5459:2011, Geometrical product specifications (GPS) — Geometrical tolerancing — Datums and datum systems

[3] 2015_04_21_PTB Pruefbericht Auswertesoftware nach Tschebyscheff für Koordinatenmessgeräte (PDF disponible en internet en pagina de Volumegraphics (ejemplo, existen otros))