Hablo de un equipo industrial que está generando gas. Está bajo prueba de certificación ( marcado CE ) IEC 61010 en un laboratorio de terceros.
En el dispositivo hay un mecanismo de detección de sobretemperatura, que tiene como objetivo detener el dispositivo. Así es como funciona:
El laboratorio que hace las pruebas de certificación nos dice que como la detección de sobre temperatura se hace por medio de un software, no es confiable. Y debido a que no es confiable, no cumple con la marca CE.
También agregan que "los laboratorios de pruebas consideran que un software es todo menos un componente confiable. Lista no exhaustiva: bucles infinitos, corrupción de datos, perturbación de EMC ..."
Suena completamente extrapolado para mí.
¿Es correcto el laboratorio de pruebas? ¿Se considera que el software/firmware no es confiable? Si no, ¿cómo probaré en el laboratorio que diseñamos nuestro componente de firmware para que sea confiable?
Sí, son 100% correctos.
El software/firmware crítico para la seguridad y el diseño del sistema requieren consideraciones especiales. Puede encontrar que vale la pena eludir el problema utilizando un límite de sobretemperatura mecánico aprobado como medida de seguridad, y el límite del software se convierte en una especie de juguete: si funciona, evita que el fusible térmico o lo que sea falle, si no, nadie . muere _ Esa sería probablemente mi recomendación si estuviera diseñando un sistema de este tipo. Un sensor analógico como el LM335 podría alimentarse en paralelo a un comparador, así como a sus cosas digitales, lo que sería mucho más fácil de certificar, pero como dije, podría ser más fácil simplemente insertar un corte térmico aprobado en el circuito de alimentación y terminar con eso.
Tiene sentido certificar el software en productos de gran volumen, como controladores de puertas de garaje, sistemas de control de encendido y purga de quemadores de gas, etc., donde no puede eludir fácilmente los problemas de seguridad, o en sistemas de bajo volumen y alto precio, como sistemas industriales o controles de transporte, pero en un sistema relativamente económico de bajo volumen probablemente tenga sentido minimizar los costos de NRE.
UL1998 es un estándar con el que estoy algo familiarizado, esta página de UL puede resultarle útil; tiene indicaciones para algunos de los estándares IEC, de los cuales uno u otro probablemente sea aplicable en su situación particular.
Muchas cosas pueden salir mal con la ejecución del firmware, y hay formas de reducir la probabilidad de un desastre: programar la memoria no utilizada con saltos para el arranque en frío, verificar todo tipo de cosas antes de patear ciegamente un Watchdog Timer (WDT) (la mayoría de las personas sabe usar un WDT, pero generalmente no se usa con el mejor efecto), actualizando las ubicaciones internas y los puertos externos con regularidad en lugar de asumir que siempre permanecerán imperturbables. Eso es sólo algunas cosas.. hay más.
Esteban Collings