Comprender la decisión de interfaz

Un sistema de supervisión que consulta lentamente puede no observar nunca un estado de corta duración. Un contador de eventos correctamente definido puede conservar evidencia de esa transición, pero solo si se conoce su comportamiento de incremento, reinicio y persistencia. Las consultas repetidas de una alarma activa no deben confundirse con eventos repetidos.

El rendimiento del control depende del significado de las señales, de la temporización y de los límites operativos aprobados. Mantenga la optimización normal separada de las restricciones de protección e identifique qué función es responsable de cada decisión. La documentación de la turbina y del controlador seleccionados debe definir los ajustes reales.

Incorporar estos datos al registro de revisión

Utilice una hoja específica del proyecto para recoger la información siguiente. En cada entrada, indique el documento, la revisión y la persona responsable de resolver cualquier incertidumbre.

• La condición exacta que cambia el valor de estado. Identifique la configuración exacta y el documento de respaldo.
• La transición que incrementa el contador de eventos correspondiente. Mantenga visibles las hipótesis de diseño en el registro del proyecto.
• El comportamiento de reinicio, desbordamiento con retorno al inicio del conteo y almacenamiento no volátil. Indique el revisor responsable y resuelva cualquier información pendiente.
• Cómo asocia el software de supervisión los cambios del contador con el tiempo y la configuración. Especifique cómo se verificará esta entrada durante la aceptación.

Definir el alcance de aceptación

Acepte la interfaz solo después de que ambas representaciones tengan su semántica documentada. Pruebe una condición sostenida por separado de las entradas repetidas en esa condición. El comportamiento resultante debe coincidir con la definición del evento, no con la frecuencia de consulta del sistema de supervisión.

Mantenga visibles los reinicios de contadores en los informes. Una vuelta inexplicada a cero no debe interpretarse como una mejora de fiabilidad, y un estado activo persistente no debe crear nuevos incidentes simplemente porque se haya recogido otra muestra en el panel.