Al desarrollar scripts en CANoe usando CAPL, los eventos como on signal y on signal_update pueden causar comportamientos inesperados si no se comprenden sus diferencias fundamentales. Este artículo explora técnicas avanzadas para evitar trampas y optimizar el rendimiento.

1. Manejo eficiente de eventos de señales

La elección entre on signal y on signal_update impacta directamente en la eficiencia del script. Mientras que on signal solo se activa al detectar un cambio real en el valor de la señal, on signal_update se ejecuta en cada actualización de la señal, independientemente de si el valor ha variado. Esto último puede generar sobrecarga innecesaria en entornos con alta frecuencia de actualización.

// Ejemplo incorrecto: uso de on signal_update que causa degradación del rendimiento
on signal_update RevolucionesMotor {
    // Este bloque se ejecuta en cada actualización, incluso sin cambio de valor
    // Lo que puede saturar el procesamiento en casos críticos
}

En situaciones donde solo se necesita reaccionar a cambios de valor, es preferible utilizar on signal para reducir la carga computacional.

1.1 Gestión adecuada de temporizadores

Los temporizadores en CAPL son útiles, pero su incorrecta administración puede llevar a fugas de memoria. Un patrón común es iniciar un temporizador sin implementar una lógica de parada clara.

variables {
    msTimer temporizadorPrincipal;
    int estadoTemporizador = 0;
}

on key 'b' {
    estadoTemporizador = !estadoTemporizador;
    if (estadoTemporizador) {
        setTimer(temporizadorPrincipal, 200); // Inicia el temporizador
    }
    // Falta lógica para detener el temporizador en caso necesario
}

on timer temporizadorPrincipal {
    if (estadoTemporizador) {
        setTimer(temporizadorPrincipal, 200); // Reconfiguración continua
    }
    // Lógica de negocio aquí...
}

2. Optimización en el procesamiento de mensajes

El manejo de mensajes CAN es una tarea central en CANoe, pero muchos scripts no aprovechan técnicas de filtrado y asignación de canales que mejoran la eficiencia.

2.1 Asignación explícita de canales

En configuraciones multicanales, especificar el canal de origen y destino evita errores de enrutamiento.

// Especificación clara del canal para mensajes entrantes
on message CAN1.0x200 {
    // Procesar solo mensajes en el canal CAN1
    message CAN2.0x300 mensajeReenviado;
    mensajeReenviado = this;
    output(mensajeReenviado); // Reenviar al canal CAN2
}

Existen dos enfoques para asignar canales:

1. Asignación posterior: ``` message * mensajeReenviado; mensajeReenviado = this; mensajeReenviado.CAN = 2; // Modificar el canal después output(mensajeReenviado);

2. Declaración directa: ``` message CAN2.* mensajeReenviado; mensajeReenviado = this; output(mensajeReenviado); // Más claro y menos propenso a errores

2.2 Estrategias de filtrado y muestreo

Monitorear todos los mensajes puede ser ineficiente. Implementar un filtrado por ID o un muestreo controlado equilibra la cobertura y el rendimiento.

variables {
    message 0x150 mensajeFiltrado;
    int contadorMuestras = 0;
}

on message 0x150 {
    // Procesar una de cada diez instancias para reducir carga
    if (contadorMuestras++ % 10 == 0) {
        mensajeFiltrado = this;
        analizarMensaje(mensajeFiltrado);
    }
}

3. Pruebas automatizadas: evitar problemas comunes

La estabilidad de los scripts de prueba depende de una gestión cuidadosa de temporización, recursos y condiciones.

3.1 Diseño robusto de casos de prueba

testcase VerificarCicloDeMensajes() {
    float limiteInferior = 90.0;  // Límite mínimo aceptable (ms)
    float limiteSuperior = 110.0; // Límite máximo aceptable (ms)
    long idVerificacion;
    
    testCaseTitle("TC-101", "Validar ciclo de mensajes entre 90 y 110 ms");
    
    idVerificacion = ChkStart_MsgAbsCycleTimeViolation(DatosMotor, limiteInferior, limiteSuperior);
    testAddCondition(idVerificacion);
    testWaitForTimeout(6000); // Ventana de prueba de 6 segundos
    testRemoveCondition(idVerificacion);
    
    if (ChkQuery_NumEvents(idVerificacion) > 0) {
        testStepFail("El ciclo de mensajes no cumple con los límites establecidos");
    } else {
        testStepPass("El ciclo de mensajes es válido");
    }
    
    ChkControl_Destroy(idVerificacion); // Liberar recursos explícitamente
}

Problemas temporales frecuentes incluyen condiciones de carrera, tiempos de espera mal configurados y fugas de recursos por no destruir condiciones de verificación.

3.2 Control dinámico de carga de bus

Mantener una carga de bus estable durante pruebas prolongadas requiere ajustes en tiempo real.

variables {
    float cargaObjetivo = 25.0; // Porcentaje de carga deseada
    float cargaActual = 0.0;
    msTimer temporizadorAjuste;
}

on start {
    setTimer(temporizadorAjuste, 1500); // Ajustar cada 1.5 segundos
}

on timer temporizadorAjuste {
    cargaActual = @sysvar::_Statistics::CAN1::Busload;
    
    if (cargaActual < cargaObjetivo) {
        incrementarTrafico(); // Función definida por el usuario
    } else if (cargaActual > cargaObjetivo) {
        reducirTrafico(); // Función definida por el usuario
    }
    
    write("Carga de bus actual: %.1f%%, objetivo: %.1f%%", cargaActual, cargaObjetivo);
    setTimer(temporizadorAjuste, 1500);
}

4. Técnicas avanzadas de depruación y optimización

Un enfoque sistemático para identificar cuellos de botella mejora significativamente la eficiencia de los scripts.

4.1 Sistema de registro estructurado

variables {
    char bufferLog[512];
}

void RegistrarEvento(const char mensaje[]) {
    long marcaTemporal[9];
    getLocalTime(marcaTemporal);
    
    snprintf(bufferLog, elcount(bufferLog), 
             "[%02d:%02d:%02d] %s", 
             marcaTemporal[2], marcaTemporal[1], marcaTemporal[0], 
             mensaje);
             
    write(bufferLog);
    putValueToControl("VentanaLog", "TextoLog", bufferLog);
}

on message * {
    if (this.ID == 0x456) {
        RegistrarEvento("Mensaje crítico 0x456 recibido");
    }
}

Los niveles de registro recomendados son: DEBUG para trazas detalladas, INFO para eventos clave, WARNING para anomalías no críticas y ERROR para fallos graves.

4.2 Identificación de cuellos de botella de rendimiento

Los problemas comunes surgen de eventos de alta frecuencia, cálculos complejos dentro de manejadores y operaciones ineficientes con memoria.

Lista de verificación de optimización:

• [ ] Todos los temporizadores tienen condiciones de parada definidas
• [ ] Los eventos frecuentes contienen operaciones simplificadas
• [ ] Se usa almacenamiento en caché para cálculos repetitivos
• [ ] Las operaciones con cadenas asignan buffers suficientes de antemano

// Antes de optimizar: formateo de cadenas en cada activación
on signal_update VelocidadActual {
    char mensaje[60];
    snprintf(mensaje, elcount(mensaje), "Velocidad actual: %f", $VelocidadActual);
    write(mensaje);
}

// Después de optimizar: procesamiento solo en cambios de valor
on signal VelocidadActual {
    char mensaje[60];
    snprintf(mensaje, elcount(mensaje), "Velocidad cambiada a: %f", $VelocidadActual);
    write(mensaje);
}

En un escenario real, un script mostraba degradación de rendimiento tras un tiempo prolongado. Mediante el análisis con CAPL Profiler de CANoe, se descubrió que una consulta a base de datos innecesaria en un manejador de on signal_update era el culpable. Al migrar a on signal, el rendimiento mejoró en un 65%.