D14 · L3 · 01 — L2 · IoT, Sensors & Connected OperationsL2 · IoT, Sensores y Operación Conectada

Industrial IoT architecture: sensors, gateways & cloud connectivity in supply chainArquitectura IIoT industrial: sensores, gateways y conectividad cloud en SC

A sensor on the asset creates the data that never existed before — and that AI needs.

El sensor que mide en el activo y transmite al sistema crea el dato que antes no existía — y que la IA necesita.

01What it isQué es

Industrial IoT architecture is the stack that turns physical conditions — temperature, location, vibration, fill level — into data the supply chain can act on: sensors capture it, networks carry it, edge devices filter it and a platform feeds it into the WMS, TMS and ERP.

La arquitectura de IoT industrial es el stack que convierte condiciones físicas — temperatura, ubicación, vibración, nivel de llenado — en datos sobre los que la cadena de suministro puede actuar: los sensores los capturan, las redes los transportan, los dispositivos edge los filtran y una plataforma los lleva al WMS, TMS y ERP.

02Why it mattersPor qué importa

Most planning and AI models run on data that someone typed in after the fact; IoT creates the first-hand record of what is actually happening to the asset. The literature on IoT in supply chains shows its value comes from integrating sensor data into decisions, not from the sensors themselves (Ben-Daya, Hassini and Bahroun, 2019 — International Journal of Production Research). A shared reference model keeps vendors and layers interoperable (ISO/IEC 30141, 2018 — ISO/IEC).

La mayoría de los modelos de planeación y de IA corren sobre datos que alguien capturó después del hecho; el IoT crea el registro de primera mano de lo que realmente le ocurre al activo. La literatura sobre IoT en cadenas de suministro muestra que su valor proviene de integrar el dato del sensor en las decisiones, no de los sensores en sí (Ben-Daya, Hassini y Bahroun, 2019 — International Journal of Production Research). Un modelo de referencia común mantiene interoperables a proveedores y capas (ISO/IEC 30141, 2018 — ISO/IEC).

03How it is doneCómo se hace

1
Set the latency SLA. Decide how fast each use case must react — seconds for a cold chain excursion, hours for utilization analytics — before choosing any hardware.
2
Match network to asset. Use cellular for moving assets, LoRaWAN for remote fixed sensors, Wi-Fi or BLE inside the warehouse, based on power, range and data rate.
3
Wire alerts into workflows. Route every alert through APIs to the WMS, TMS or ERP and to a named owner, and alarm on sensors that go silent.
1
Fija el SLA de latencia. Decide qué tan rápido debe reaccionar cada caso de uso — segundos para una excursión de cadena de frío, horas para analítica de utilización — antes de elegir cualquier hardware.
2
Ajusta la red al activo. Usa celular para activos en movimiento, LoRaWAN para sensores fijos remotos y Wi-Fi o BLE dentro del almacén, según energía, alcance y tasa de datos.
3
Conecta alertas a flujos. Envía cada alerta vía API al WMS, TMS o ERP y a un responsable con nombre, y genera alarma cuando un sensor deja de reportar.

04The concept in depthEl concepto a fondo

📡Industrial IoT architecture: the 4-layer stack for supply chain sensing›
A supply chain IIoT system has 4 layers: (1) Sensing layer: physical sensors and RFID readers that capture the state of the supply chain — temperature, location, weight, vibration, humidity, fill level. (2) Connectivity layer: network infrastructure that transmits sensor data — cellular (4G/5G), LoRaWAN, Wi-Fi 6, BLE, or Zigbee depending on data frequency and energy requirements. (3) Edge computing layer: local compute that processes data before sending to the cloud, enabling real-time response (<100ms) without cloud round-trip latency. (4) Cloud/platform layer: the platform that stores, processes, and visualizes sensor data and integrates it with the WMS, TMS, ERP, and AI models.
📊Connectivity technology selection guide for supply chain IIoT›
Choose based on 3 parameters: update frequency, power availability, and coverage area. Cellular 4G/5G: best for mobile assets (trucks, cold chain containers) — high bandwidth, continuous coverage, higher cost. LoRaWAN: best for fixed sensors in rural or low-connectivity areas — 10-year battery, 10–15 km range, low data rate. Wi-Fi 6: best for high-density sensor environments in the warehouse where infrastructure exists. BLE: best for short-range asset tracking (forklift location, operator safety) — low power, 1–3 meter precision.
🔢The data latency SLA: the first design constraint to define›
Before selecting any IIoT technology, define the data latency SLA: how quickly does the system need to act on sensor data? Cold chain excursion detection: <30 seconds (edge processing required). Inventory level monitoring: <5 minutes (cloud processing acceptable). Asset utilization analytics: <1 hour (batch processing acceptable). The latency requirement determines connectivity technology, edge vs. cloud processing, and ultimately system cost.
🏆Intermediate vs. Advanced›
Intermediate: works with IIoT dashboards and alerts; escalates sensor anomalies and connectivity issues.

Advanced: designs the IIoT architecture for supply chain use cases; leads sensor and gateway selection; manages cloud platform integration with WMS/TMS/ERP.
📡Arquitectura de IoT industrial: el stack de 4 capas para el sensado en la cadena de suministro›
Un sistema IIoT de cadena de suministro tiene 4 capas: (1) Capa de sensado: sensores físicos y lectores RFID que capturan el estado de la cadena — temperatura, ubicación, peso, vibración, humedad, nivel de llenado. (2) Capa de conectividad: la infraestructura de red que transmite los datos de los sensores — celular (4G/5G), LoRaWAN, Wi-Fi 6, BLE o Zigbee, según la frecuencia de datos y los requerimientos de energía. (3) Capa de edge computing: cómputo local que procesa los datos antes de enviarlos a la nube y permite respuesta en tiempo real (<100 ms) sin la latencia de ida y vuelta a la nube. (4) Capa de nube/plataforma: la plataforma que almacena, procesa y visualiza los datos de sensores y los integra con el WMS, TMS, ERP y los modelos de IA.
📊Guía de selección de tecnología de conectividad para IIoT en la cadena de suministro›
Se elige con base en 3 parámetros: frecuencia de actualización, disponibilidad de energía y área de cobertura. Celular 4G/5G: lo mejor para activos móviles (camiones, contenedores refrigerados) — alto ancho de banda, cobertura continua, mayor costo. LoRaWAN: lo mejor para sensores fijos en zonas rurales o de baja conectividad — batería de hasta 10 años, alcance de 10–15 km, baja tasa de datos. Wi-Fi 6: lo mejor para entornos de alta densidad de sensores dentro del almacén donde ya existe infraestructura. BLE: lo mejor para rastreo de activos de corto alcance (ubicación de montacargas, seguridad del operador) — bajo consumo, precisión de 1–3 metros.
🔢El SLA de latencia de datos: la primera restricción de diseño que hay que definir›
Antes de seleccionar cualquier tecnología IIoT, se debe definir el SLA de latencia de datos: ¿qué tan rápido necesita actuar el sistema sobre los datos del sensor? Detección de excursiones en cadena de frío: <30 segundos (requiere procesamiento en el edge). Monitoreo de niveles de inventario: <5 minutos (procesamiento en la nube aceptable). Analítica de utilización de activos: <1 hora (procesamiento por lotes aceptable). El requerimiento de latencia determina la tecnología de conectividad, el procesamiento edge vs. nube y, en última instancia, el costo del sistema.
🏆Intermedio vs. Avanzado›
Intermedio: trabaja con dashboards y alertas de IIoT; escala anomalías de sensores y problemas de conectividad.

Avanzado: diseña la arquitectura IIoT para casos de uso de cadena de suministro; lidera la selección de sensores y gateways; gestiona la integración de la plataforma en la nube con WMS/TMS/ERP.

05In practiceEn la práctica

📡Define the data latency SLA before selecting any IIoT technology — the latency requirement determines the architecture›
Starting an IIoT project by selecting a sensor platform before defining the latency requirement is the most common IIoT project failure mode. Latency drives everything: connectivity, edge vs. cloud, and cost.
🔢Design for sensor failure from the start — alert when a sensor stops reporting›
A sensor that fails silently (stops transmitting without generating an alert) is more dangerous than one that generates a false positive. Every IIoT system must alert when a sensor has not reported within 2× its scheduled reporting interval.
🔗Integrate the IIoT platform with WMS and TMS via APIs — sensor data only generates value when it flows into operational decisions›
A cold chain excursion alert on a dashboard that nobody monitors generates no value. The alert must flow to the person with authority to intervene and trigger an automatic workflow (NCR creation, shipment hold).
📊Plan for sensor calibration from go-live — uncalibrated sensors drift and generate false readings within 6–12 months›
For regulated (GxP) products, sensor calibration must be documented at installation and repeated at the interval defined by the quality system — typically at least annually.
📡Definir el SLA de latencia de datos antes de seleccionar cualquier tecnología IIoT — el requerimiento de latencia determina la arquitectura›
Arrancar un proyecto IIoT eligiendo una plataforma de sensores antes de definir el requerimiento de latencia es el modo de falla más común en estos proyectos. La latencia lo define todo: conectividad, edge vs. nube y costo.
🔢Diseñar para la falla de sensores desde el inicio — alertar cuando un sensor deja de reportar›
Un sensor que falla en silencio (deja de transmitir sin generar alerta) es más peligroso que uno que genera un falso positivo. Todo sistema IIoT debe alertar cuando un sensor no ha reportado en 2× su intervalo de reporte programado.
🔗Integrar la plataforma IIoT con el WMS y el TMS vía APIs — el dato del sensor solo genera valor cuando llega a las decisiones operativas›
Una alerta de excursión de cadena de frío en un dashboard que nadie monitorea no genera valor. La alerta debe llegar a la persona con autoridad para intervenir y disparar un flujo automático (creación de NCR, retención del embarque).
📊Planear la calibración de sensores desde el arranque — los sensores sin calibrar se desvían y generan lecturas falsas en 6–12 meses›
Para productos regulados (GxP), la calibración de sensores debe documentarse en la instalación y repetirse con la frecuencia que defina el sistema de calidad — normalmente al menos una vez al año.

06Illustrative caseCaso ilustrativo

Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Illustrative case: Cold chain IIoT implementation — pharmaceutical distributor, 280 temperature-sensitive shipments/month
The company implements a 4-layer IIoT system for real-time cold chain monitoring, with electronic temperature records designed to meet FDA 21 CFR Part 11 for its US pharmaceutical export program.
IIoT layerImplementation decisionBusiness result
Sensing layerTMP117 sensors (±0.1°C precision, NIST-traceable) in each cold box + RFID tag for container identity · Reading frequency: every 60 seconds100% of temperature excursions detected within 90 seconds · 0 undetected excursions in 12 months
Connectivity layerLTE-M cellular (Telcel) + LoRa backup for rural areas · Gateway in each refrigerated truck99.4% data transmission success rate · 0.6% gap filled by local edge storage
Cloud platformAWS IoT Core + real-time alert to logistics coordinator when temperature leaves the 2–8°C range for >5 minutes · API integration with ERP for automatic NCR generation18 cold-chain shipments saved in first 6 months · $4.8M MXN product loss avoided · NCR generation time: 4 hours (manual) → 8 minutes (automatic)
Result: Total IIoT investment: $1.8M MXN. Annual value: $8.4M MXN (product loss avoidance + compliance + NCR cost). Payback: 2.6 months. Customer quality audit: electronic records and electronic signatures met 21 CFR Part 11 expectations.
Illustrative case built from typical industry values — not data from a specific company.Caso ilustrativo construido con valores típicos de la industria — no son datos de una empresa específica.
Caso ilustrativo: implementación de IIoT para cadena de frío — distribuidor farmacéutico, 280 embarques sensibles a temperatura al mes
La empresa implementa un sistema IIoT de 4 capas para monitorear la cadena de frío en tiempo real, con registros electrónicos de temperatura diseñados para cumplir con FDA 21 CFR Part 11 en su programa de exportación farmacéutica a EE. UU.
Capa IIoTDecisión de implementaciónResultado de negocio
Capa de sensadoSensores TMP117 (precisión ±0.1 °C, trazables a NIST) en cada caja fría + tag RFID para identificar el contenedor · Frecuencia de lectura: cada 60 segundos100% de las excursiones de temperatura detectadas en menos de 90 segundos · 0 excursiones no detectadas en 12 meses
Capa de conectividadCelular LTE-M (Telcel) + respaldo LoRa para zonas rurales · Gateway en cada camión refrigerado99.4% de éxito en la transmisión de datos · el 0.6% de huecos se cubre con almacenamiento local en el edge
Plataforma en la nubeAWS IoT Core + alerta en tiempo real al coordinador logístico cuando la temperatura sale del rango de 2–8 °C por >5 minutos · Integración vía API con el ERP para generar NCR automáticamente18 embarques de cadena de frío salvados en los primeros 6 meses · $4.8M MXN de pérdida de producto evitada · Tiempo de generación de NCR: 4 horas (manual) → 8 minutos (automático)
Resultado: Inversión total en IIoT: $1.8M MXN. Valor anual: $8.4M MXN (pérdida de producto evitada + cumplimiento + costo de NCR). Recuperación: 2.6 meses. Auditoría de calidad del cliente: los registros y firmas electrónicas cumplieron con lo esperado por 21 CFR Part 11.

07How it is measuredCómo se mide

📡Sensor Data Transmission Success Rate %›
Sensor Data Transmission Success Rate %
(Sensor readings successfully transmitted to the platform / Total sensor readings generated) × 100
Benchmark: >99% data transmission success rate for critical cold chain and quality monitoring sensors · <95% indicates connectivity infrastructure issues
⚠️ A 5% transmission failure rate means 5% of temperature excursions may go undetected. For pharmaceutical cold chain, any undetected excursion generates regulatory risk.
📊Sensor-to-Alert Latency (seconds from excursion to alert)›
Sensor-to-Alert Latency (seconds from excursion to alert)
Average time from when a sensor reading exceeds the threshold to when the alert reaches the responsible person
Benchmark: <60 seconds for cold chain excursion alerts with edge processing · <5 minutes for non-critical supply chain alerts with cloud processing
🔑 Cold chain excursion latency >5 minutes means the product may be irreversibly compromised before the team can intervene. Edge processing at the gateway is mandatory for pharmaceutical cold chain compliance.
📡Tasa de éxito de transmisión de datos de sensores %›
Tasa de éxito de transmisión de datos de sensores %
(Lecturas transmitidas con éxito a la plataforma / Total de lecturas generadas por los sensores) × 100
Referencia: >99% de éxito de transmisión para sensores críticos de cadena de frío y calidad · <95% indica problemas en la infraestructura de conectividad
⚠️ Una tasa de falla de transmisión de 5% significa que hasta 5% de las excursiones de temperatura podrían pasar inadvertidas. En cadena de frío farmacéutica, cualquier excursión no detectada genera riesgo regulatorio.
📊Latencia sensor-alerta (segundos desde la excursión hasta la alerta)›
Latencia sensor-alerta (segundos desde la excursión hasta la alerta)
Tiempo promedio desde que una lectura rebasa el umbral hasta que la alerta llega al responsable
Referencia: <60 segundos para alertas de excursión de cadena de frío con procesamiento en el edge · <5 minutos para alertas no críticas de cadena de suministro con procesamiento en la nube
🔑 Una latencia de excursión >5 minutos significa que el producto podría quedar comprometido de forma irreversible antes de que el equipo intervenga. El procesamiento en el edge, en el gateway, es indispensable para el cumplimiento en cadena de frío farmacéutica.

08What you would useQué se usa

📌 Industrial IoT Platforms
🟦AWS IoT Core / Azure IoT Hub›
Module: Cloud IIoT Platforms for Supply Chain

The two major hyperscaler IIoT platforms used in supply chain (Google retired Cloud IoT Core in 2023). AWS IoT Core offers broad integration with enterprise systems (SAP, Oracle, Salesforce) through its partner ecosystem. Azure IoT Hub integrates natively with Power BI for real-time dashboards.
🟦Sensitech TempTale / DeltaTrak FlashLink / Dickson IQQ›
Module: Specialized Cold Chain IoT Systems

Purpose-built cold chain monitoring systems with FDA 21 CFR Part 11 support built in. Sensitech (part of Carrier) is one of the leading vendors for pharmaceutical cold chain compliance.
📌 Plataformas de IoT industrial
🟦AWS IoT Core / Azure IoT Hub›
Módulo: Plataformas IIoT en la nube para cadena de suministro

Las dos principales plataformas IIoT de hiperescaladores usadas en cadena de suministro (Google retiró Cloud IoT Core en 2023). AWS IoT Core ofrece amplia integración con sistemas empresariales (SAP, Oracle, Salesforce) a través de su ecosistema de socios. Azure IoT Hub se integra de forma nativa con Power BI para dashboards en tiempo real.
🟦Sensitech TempTale / DeltaTrak FlashLink / Dickson IQQ›
Módulo: Sistemas IoT especializados en cadena de frío

Sistemas de monitoreo de cadena de frío diseñados a propósito, con soporte integrado para FDA 21 CFR Part 11. Sensitech (parte de Carrier) es uno de los proveedores líderes para el cumplimiento en cadena de frío farmacéutica.
The bottom lineEn corto

A sensor is only worth what the decision it triggers is worth — design the decision first.

Un sensor vale lo que vale la decisión que dispara: diseña primero la decisión.

All D14 componentsTodos los componentes de D14D14 artifactsArtifacts de D14SCRA