En el Día 331 configuramos AWS IoT para recibir las ventas. Pero, ¿qué ocurre si una máquina en Zapopan no envía ninguna venta en todo el domingo? ¿El despachador está descompuesto o simplemente no han habido clientes? En IoT, la ausencia de datos es un problema crítico. La solución es el MQTT Heartbeat (Latido). Cada 60 segundos, la máquina envía un pequeño paquete JSON a la nube indicando: "Estoy viva, este es mi Uptime, esta es mi Temperatura Interna, y este es mi estatus de error." En la Tesis, esto demuestra la capacidad de Monitorización Remota Continua (Condition Monitoring).
El fluido del Gas LP se expande con el calor. El estándar de facturación legal exige que el volumen se cobre referenciado a $20^\circ C$. Si tu PT100 marca $35^\circ C$, un litro medido por la turbina en realidad tiene menos masa de gas. En tu Capítulo de Pruebas, debes colocar una gráfica de Grafana (o similar) que muestre la divergencia entre el "Volumen Bruto" (Raw) y el "Volumen Facturado" (Compensated) a lo largo del día. La diferencia entre ambas líneas es el ROI (Retorno de Inversión) puro de tu hardware metrológico.
Paso 1: Recolección de Telemetría.
En el Capítulo 4 de tu tesis, no puedes simplemente poner fotos de tu placa. Debes ejecutar la máquina durante 72 horas ininterrumpidas. Configura el ESP32 para que reciba el JSON de latido del STM32 y lo publique en AWS IoT cada minuto. Usa Grafana o AWS QuickSight para graficar estos datos históricos y expórtalos como figuras para tu documento LaTeX.
Paso 2: Análisis de Resultados (Discusión).
Toma el volumen bruto despachado a las 3:00 PM (hora de máximo calor) y compáralo con el volumen neto facturado. Traduce esa diferencia de litros a Pesos Mexicanos (MXN). En tu tesis, concluye que el costo del desarrollo del hardware se amortiza (ROI) en menos de 3 meses gracias a esta corrección algorítmica.
Este código ensambla el "Latido" del sistema utilizando las técnicas de concatenación rápida que aprendimos en el Día 336 (evitando sprintf para datos críticos). Sin embargo, dado que el Heartbeat es una tarea de muy baja prioridad (ocurre 1 vez por minuto en estado IDLE), podemos darnos el lujo de formatearlo limpiamente para pasarlo al ESP32 por UART.
/**
* @file scada_telemetry_heartbeat.c
* @brief Generación del paquete de estado vital para validación IoT (Pruebas Tesis)
*/
#include "stm32f4xx_hal.h"
#include <string.h>
// Variables globales del sistema actualizadas por otras tareas
extern uint32_t current_uptime_seconds;
extern float current_fluid_temp_c;
extern uint64_t daily_raw_volume_mL;
extern uint64_t daily_compensated_volume_mL;
extern uint8_t system_error_code;
// Funciones de utilidad ligera (Día 336)
extern uint8_t Fast_IntToStr_FixedPoint(uint32_t value, char* buffer, uint8_t decimal_places);
// =========================================================================
// ENSAMBLAJE DE TELEMETRÍA (HEARTBEAT)
// =========================================================================
/**
* @brief Se ejecuta periódicamente (Ej. cada 60 seg) vía Timer/FSM.
* Genera un JSON minificado para transmisión MQTT a AWS IoT Core.
*/
void Telemetry_Send_Heartbeat(void) {
char json_payload[128];
char temp_str[10];
char raw_vol_str[15];
char comp_vol_str[15];
// Convertimos la temperatura (multiplicada por 100 para evadir floats)
uint32_t temp_fixed = (uint32_t)(current_fluid_temp_c * 100.0f);
Fast_IntToStr_FixedPoint(temp_fixed, temp_str, 2);
// Convertimos los volúmenes (que están en mililitros) a Litros con 3 decimales
Fast_IntToStr_FixedPoint((uint32_t)(daily_raw_volume_mL), raw_vol_str, 3);
Fast_IntToStr_FixedPoint((uint32_t)(daily_compensated_volume_mL), comp_vol_str, 3);
// Ensamblaje manual ligero (Evitamos el pesado sprintf de la stdlib)
strcpy(json_payload, "{\"hb\":1,\"up\":");
char uptime_str[12];
Fast_IntToStr_FixedPoint(current_uptime_seconds, uptime_str, 0);
strcat(json_payload, uptime_str);
strcat(json_payload, ",\"t\":");
strcat(json_payload, temp_str);
strcat(json_payload, ",\"v_raw\":");
strcat(json_payload, raw_vol_str);
strcat(json_payload, ",\"v_net\":");
strcat(json_payload, comp_vol_str);
strcat(json_payload, ",\"err\":");
char err_str[4];
Fast_IntToStr_FixedPoint(system_error_code, err_str, 0);
strcat(json_payload, err_str);
strcat(json_payload, "}\r\n");
// Enviar al co-procesador ESP32 vía UART (Día 313 / Día 337)
// Salida esperada: {"hb":1,"up":259200,"t":34.20,"v_raw":10500.500,"v_net":10350.250,"err":0}
HAL_UART_Transmit(&huart2, (uint8_t*)json_payload, strlen(json_payload), 100);
}
Objetivo del día: Validación Empírica, Capítulo 4 de Tesis y Demostración de ROI.
El Capítulo 4 de tu tesis ("Pruebas y Resultados") es el clímax de tu investigación. Aquí demuestras que el algoritmo de cálculo API-54 que escribimos en el Día 298 no es solo un ejercicio académico en C, sino una herramienta financiera activa. A las 3:00 PM, bajo el sol de Jalisco, el sensor PT100 intrínsecamente seguro detecta $34.2^\circ C$. La turbina gira y marca $10,500$ litros brutos. Pero el STM32 interviene, aplica la matriz térmica y factura $10,350$ litros netos al cliente (porque el gas está dilatado).
Al enviar estos datos a través del MQTT Heartbeat, generas pruebas auditables en AWS IoT y Grafana. Estas gráficas en tu documento de tesis prueban visualmente la superioridad de tu Arquitectura de Hardware/Software. Demuestras que tu máquina resuelve un problema millonario en la industria petroquímica con la precisión de un sistema embebido Bare-Metal. El jurado no solo aprobará tu diseño electrónico; aplaudirá tu impacto comercial.