Nos resulta más fácil evaluar un sistema de alumbrado público solar con IA e IoT si dividimos sus funciones en capas. En la documentación del producto, describimos un sensor capaz de detectar el flujo de tráfico y las condiciones meteorológicas, un controlador MPPT con IA e IoT que incluye funciones de control remoto y de iluminación para PC/aplicación móvil, así como gestión mediante web o aplicación móvil para consultar el estado y ejecutar comandos. También describimos la integración escalable con cámaras de seguridad, sistemas de alerta temprana y equipos de monitorización meteorológica. Estas descripciones definen límites arquitectónicos útiles, pero no demuestran un protocolo de comunicación, proveedor de nube, API, modelo de cámara ni diseño de permisos específicos.

En este artículo, explicamos cómo encajan estos componentes. Para la decisión sobre el concepto y la adecuación al proyecto, consulte ¿Qué son las farolas solares con IA e IoT? Tecnologías, funciones y ventajas explicadas.Para una licitación o implementación real, recomendamos confirmar cada función con respecto al modelo seleccionado y el diseño del proyecto.

¿Qué papel desempeña cada componente en un sistema de alumbrado público solar con IA e IoT?

Los sensores proporcionan información

En nuestro HC-CZSL-39 En la descripción del producto, indicamos que el sensor detecta el flujo de tráfico y las condiciones climáticas, y permite el ajuste automático del brillo y la temperatura del color. A nivel de arquitectura, consideramos el sensor como la capa de entrada. Observa una condición que puede influir en la decisión de iluminación. Nuestro registro no especifica un modelo de sensor universal, la precisión de la medición, la posición de instalación, el intervalo de muestreo ni el algoritmo. Por lo tanto, dejamos esos detalles como preguntas del proyecto.

El controlador realiza trabajos de iluminación local.

Nuestro registro de producto incluye un controlador MPPT de IA para IoT con funciones para PC/aplicación, control de iluminación y control remoto. MPPT se refiere a la carga solar y la gestión de energía; el control de iluminación y el control remoto se refieren al funcionamiento. Ubicamos el controlador cerca del punto de iluminación en la arquitectura de alto nivel, donde conecta el hardware de energía e iluminación con el flujo de trabajo de gestión. No inferimos ningún protocolo, chip, estándar inalámbrico ni diseño de bucle de control a partir de las palabras "IA para IoT".

La plataforma de gestión expone el estado y los comandos.

En nuestras preguntas frecuentes, indicamos que una plataforma web o móvil permite ajustar el brillo, la temperatura del color, el estado de encendido/apagado y los limpiaparabrisas, y que tanto los navegadores web como las aplicaciones móviles admiten la visualización de datos. En el flujo de trabajo de un proyecto, nuestra plataforma permite a un operador autorizado revisar el estado, enviar comandos y responder a alertas. Aún se requiere confirmación para definir las pantallas, los roles de usuario, las reglas de retención de datos y las dependencias de red.

Las cámaras y otros dispositivos son objetivos de integración.

Nuestro material comparativo describe la integración escalable con cámaras de videovigilancia, sistemas de alerta temprana, equipos de monitoreo meteorológico y otros requisitos. Esto nos sirve de guía para el diseño. No se trata de afirmar que todas las farolas solares incorporan una cámara ni que todos los modelos incluyen una interfaz de cámara preconfigurada. Consideramos los dispositivos externos como un proceso de integración independiente, con sus propios requisitos de alimentación, montaje, ancho de banda, datos, privacidad y aceptación.

¿Cómo intercambian información los componentes?

Nuestro modelo de alto nivel más seguro es:

detección → control local → visibilidad del estado → comando remoto → respuesta de campo

1. Nuestro sensor observa condiciones como el flujo de tráfico o el clima.
2. Nuestro controlador aplica la lógica de iluminación y energía disponible en el poste o la luminaria.
3. La información operativa se hace visible a través de nuestra capa de gestión configurada.
4. Un operador autorizado puede enviar un comando compatible, como un ajuste o una instrucción de encendido/apagado.
5. Verificamos el resultado localmente y registramos el evento para su mantenimiento o aceptación.

Este modelo nos ayuda, tanto a nosotros como a nuestros clientes, a formular las preguntas adecuadas sin necesidad de inventar una arquitectura técnica compleja. ¿Qué datos se recopilan? ¿Qué decisiones se toman localmente? ¿Qué comandos se permiten de forma remota? ¿Qué sucede si se interrumpe la conectividad? ¿Se registra el comando? ¿Quién puede modificarlo? ¿Qué dispositivo externo recibe los datos? Estas preguntas son más útiles que asumir que «plataforma en la nube» implica una arquitectura estándar.

¿Qué funciones corresponden al punto de iluminación y cuáles a la plataforma?

Esta separación se utiliza para evitar dos errores comunes. Primero, una función de la plataforma no debe presentarse como prueba de que todos los postes tienen el mismo hardware. Segundo, una característica del hardware no debe presentarse como prueba de que un proyecto tiene acceso remoto, cobertura de red o permiso para usarla.

¿Qué debería verificar un equipo de proyecto antes de adoptar esta arquitectura?

Recomendamos utilizar una lista de verificación de arquitectura específica para cada modelo.

Verifique el hardware exacto

Confirmamos el número de modelo, el tipo de controlador, la disposición del panel y la batería, el método de instalación, la altura de montaje, el área de iluminación y los límites ambientales. Por ejemplo, nuestro registro HC-CZSL-39-100W indica montaje en poste o pared, una altura de montaje de 4 a 6 m, una caja de batería externa LiFePO4 y un rango de temperatura de color ajustable mediante IA de 3000 K a 6000 K. Estos valores corresponden únicamente al registro de ese producto.

Verificar el requisito de detección

Definimos si el proyecto requiere datos de tráfico, clima, nivel de luz, ocupación u otra información. Preguntamos dónde se instala el sensor, qué condiciones puede detectar, cómo se toma la decisión y qué sucede cuando no se dispone de la lectura. No convertimos una simple mención a un sensor en una especificación de rendimiento sin pruebas que lo respalden.

Verifique la ruta de control y de red.

Documentamos los controles locales, los controles remotos, los comandos compatibles, el método de conectividad, la cobertura, el comportamiento sin conexión, el proceso de actualización del firmware y el registro de comandos. Además, verificamos si el acceso web y a la aplicación móvil están incluidos en la configuración seleccionada y qué roles de usuario pueden modificar los ajustes.

Verifique los dispositivos externos por separado.

Para cámaras, transmisiones o dispositivos meteorológicos, verificamos el presupuesto de energía, el montaje, la interfaz, el ancho de banda, la propiedad de los datos, los requisitos de privacidad, el almacenamiento y las pruebas de aceptación. Nuestros materiales permiten considerar estos aspectos como requisitos de integración escalables; sin embargo, no eliminan la necesidad de una revisión de la interfaz específica para cada proyecto.

Verifique el flujo de trabajo de mantenimiento

La descripción de nuestro producto hace referencia a comprobaciones del estado de funcionamiento en tiempo real, posicionamiento GPS, actualizaciones remotas de firmware, supervisión del sistema 24/7 e identificación única de lámparas. Confirmamos cuáles de estos están incluidos a través de la Servicio de monitorización remota y gestión inteligente de IoT mediante IA, qué límites de servicio se aplican y cómo una alerta se convierte en una acción de campo. Un panel sin un responsable, una regla de escalamiento y un registro de cierre no constituye un proceso de mantenimiento completo.

¿En qué casos las afirmaciones arquitectónicas requieren pruebas específicas del producto?

Utilizamos tres niveles de evidencia:

6. Confirmado en un registro de producto con nombre:controlador específico del modelo, batería, montaje, área de iluminación o función de control indicada.
7. Confirmado en el material del sistema del cliente, pero sujeto a condiciones:Gestión web/aplicación móvil, alertas, posicionamiento o funciones de firmware remoto.
8. Una dirección de integración del proyecto:cámaras, sistemas de transmisión, equipos meteorológicos, API, red, permisos y gobernanza de datos.

Redactamos los dos primeros niveles como declaraciones de capacidad del cliente solo cuando el alcance exacto permanece visible. Redactamos el tercer nivel como un requisito para verificar. Esta distinción es especialmente importante para Farolas solares con montaje en poste: el poste, la luminaria, el controlador, el sensor, la red y el dispositivo externo pueden ser suministrados o configurados por diferentes flujos de trabajo.

Transferencia de la arquitectura al proyecto

Antes de la aprobación, preparamos un paquete de evidencias de una página que incluye el número de modelo, la lista de componentes, el diagrama de control, las suposiciones de red, la lista de dispositivos externos, los roles de usuario, el flujo de trabajo de alertas, la prueba de puesta en marcha y la evidencia de aceptación. Marcamos cada línea como confirmada, configurada o pendiente de verificación. Esta sencilla etiqueta de estado evita que un diagrama conceptual se convierta accidentalmente en una promesa de producto.

Cuando planifique un proyecto de iluminación solar conectada, comparta con nuestro equipo las condiciones del sitio, las necesidades de sensores y cámaras, el flujo de trabajo de monitoreo, el método de conectividad, la disposición de montaje y las restricciones de integración a través de Descripción general del sistema global de IA e IoT de Werise o el Página de contacto de WeriseCreemos que una arquitectura sólida no es la que tiene más módulos, sino aquella en la que cada módulo tiene una función verificada, un propietario responsable y una transición clara a la siguiente etapa.