¿Cómo construir un gran sistema WIFI dentro de una fábrica que admita miles de dispositivos? [cerrado]

5

Soy un novato en la red y estoy tratando de encontrar una arquitectura para un sistema WI-FI que se despliegue en un área grande (más de 50,000 metros cuadrados) y conecte 1000-2000 dispositivos con un servidor.

Cada uno de los dispositivos es un robot y navegará dentro de la fábrica. El servidor se comunicará con cada robot, leerá los datos del robot y controlará el comportamiento de los robots. El servidor se conecta a los robots a través de WI-FI.

Los requisitos de los sistemas son:

  1. Los robots navegarán dentro de la fábrica de 50,000 metros cuadrados (200m * 250m);
  2. Los robots deben estar conectados al servidor todo el tiempo. Si hay alguna desconexión y reconexión, se producirá en 100 ms;

  3. El retraso de los datos será de alrededor de 100 ms;

  4. La velocidad de comunicación es de alrededor de 5Hz, lo que significa que hay un envío y recepción desde el robot al servidor cada 200 ms;

  5. La cantidad de datos para cada comunicación es de alrededor de 1 KB;

Lo que estoy pensando

1.El servidor se conectará con varios puntos de acceso inalámbricos que se encuentran en el techo de la fábrica. Los AP cubrirán toda el área de la fábrica.

2. Cada robot tendrá dos módulos WI-FI en él. Los dos módulos WI-FI siempre se conectan a diferentes AP para garantizar que cuando hay una transición de la cobertura de un AP a la cobertura de otro AP, siempre haya una conexión establecida.

Cualquier comentario / perspectiva será realmente apreciado

    
pregunta richieqianle

3 respuestas

7

Hagamos algunos cálculos de respaldo del sobre:

Tienes 2000 dispositivos. Si usa WiFi de 5 GHz, tendrá alrededor de 45 canales no superpuestos disponibles para los EE. UU., Un poco menos en la UE, si está usando solo 20 MHz por canal. Esto es, por supuesto, asumiendo que tiene un equipo que admite adecuadamente la selección dinámica de frecuencia, y esto podría ser un problema (¡o fue hace 4-5 años, cuando lo miré por lo menos!).

Ahora, si intentamos poner un número razonable de dispositivos por punto de acceso, esto nos dará alrededor de 10 dispositivos por AP (este número se puede ajustar un poco si se deben hacer cálculos más precisos). Así que tendrás que ajustar 200 puntos de acceso en 45 canales. He visto la siguiente fórmula para el número de sectores hexagonales en un clúster: \ $ N = a + ab + b \ $ Por lo tanto, debería elegir a y b para que la N sea la más cercana posible al número de Canales permitidos en su región. Creo que la derivación se explicó en Comunicaciones inalámbricas de Theodore Rappaport. Este libro también incluirá algunos cálculos sobre la utilización máxima y promedio de un sistema de red, por lo que puede obtener algunas estimaciones sobre el rendimiento que realmente necesita, cuando tenemos en cuenta el número promedio de solicitudes por minuto por AP.
Todo esto debería ser factible, por ejemplo con 5 a 6 grupos, pero probablemente necesitará usar antenas de sector altamente direccionales que apunten hacia abajo desde el techo y una potencia de transmisión muy baja, para no molestar a las estaciones de canal en los grupos cercanos.

Luego está también la parte que no recuerdo muy bien y así es como es posible hacer esto con los protocolos reales de la red WiFi. Mi sensación es que la tasa de actualización de 200 ms es un poco alta. Quizás valga la pena intentar que el sistema funcione de manera confiable con algunas actualizaciones perdidas, por si acaso.

Además, hay ciertos períodos de espera definidos en los estándares que afectarán su operación. No recuerdo los valores reales en este momento, pero busque SIFS, PIFS, DIFS, EIFS, AIFS y cómo interactúan. A continuación, comentó sobre la relajación del requisito de 1 KiB. Yo personalmente no encuentro eso tan razonable. De hecho, recomiendo ir incluso más alto que 1 paquete KiB. Es decir, con cada datagrama que envíe, tendrá una sobrecarga adicional antes de que alcance el nivel de trama y salga al resto. No recuerdo los valores exactos ahora, pero mantener sus datos útiles al tamaño de alrededor de 1.3 KiB es relativamente bueno. El tamaño máximo de cuadro para WiFi es un poco más alto que 2 KiB, pero para Ethernet, es alrededor de 1.5 KiB (sí, hay marcos jumbo que rondan los 9 KiB, pero usarlos requiere problemas, a menos que puedas 100 % de garantía de que todos los dispositivos de la red los admitirán). Si sus datagramas tienen alrededor de 1.3 KiB, tendrá espacio más que suficiente para Wi-Fi y aún podrá encajar el marco en Ethernet. Para este tipo de cálculos, encontré los libros de Matthew S. Gast muy útiles. Escribió 802.11 Wireless Networks, 802.11n: A Survival Guide y 802.11ac: A Survival Guide, que forman una serie.

También como consejo, asegúrese de realizar los cálculos, seleccione qué estándar de red desea utilizar y habilite SOLAMENTE ese único estándar y desactive la compatibilidad con versiones anteriores. El tema es el llamado "tiempo de aire". Básicamente, si tiene habilitada la compatibilidad con versiones anteriores, algunos de los datos del servicio se enviarán a la velocidad a la que incluso el dispositivo compatible más antiguo podrá recibirlos. Me ocurrió que una vez que una red WiFi bajó de categoría a IEEE 802.11 sin velocidad de letras! El resultado es que a bajas velocidades, incluso los pequeños paquetes de mantenimiento necesarios para mantener la red en funcionamiento tardarán mucho tiempo en transmitirse.
La compatibilidad con versiones anteriores fue obligatoria en los estándares hasta hace poco (no recuerdo si 802.11n o 802.11ac fue quien rompió eso), pero el equipo que permite romper ese requisito existe y puede encontrarse comúnmente.

A continuación, no olvide que para algo como esto, necesitará una infraestructura de red cableada seria para admitir todo lo que desea. No entro mucho en eso aquí, pero solo diré que la parte cableada puede ser tan compleja como la WiFi, si quieres que funcione correctamente. También mencionas "el servidor". Para que esto funcione, probablemente necesitará varios servidores físicos que ejecuten una sola máquina virtual de manera redundante. Incluso esta parte será muy complicada.

    
respondido por el AndrejaKo
5

@AndrejaKo explicó muy bien por qué es problemático usar una infraestructura WiFi para tantos dispositivos.

Iría un paso más allá y diría: está mal para tu aplicación.

Su aplicación es una navegación de tiempo / control / automatización de procesos críticos. WiFi es un esquema de múltiples usuarios para evitar colisiones que ofrece absolutamente ninguna garantía sobre si una sola estación podrá enviar la menor cantidad de datos dentro de un tiempo limitado.

Por lo tanto, en un escenario de congestión, algunos robots simplemente no podrán comunicarse, incluso si otros ven un "tiempo de canal de repuesto" que podría usarse. Esto no es aceptable para su aplicación y es fundamental para el funcionamiento de WiFi.

Lo que necesita es un sistema que garantice que todas las estaciones puedan obtener acceso al canal en un período de tiempo limitado, y debe hacerlo para una gran cantidad de dispositivos. Por lo tanto, necesita algo que se parezca mucho más a una red celular, o redes de token ring clásicas. Los dispositivos celulares tienen una unidad de arbitraje central y posiciones espectrales / temporales definidas donde las estaciones pueden solicitar acceso al canal para la transmisión de datos y se garantiza que lo obtendrán dentro de un período de tiempo definido; esto requiere, sin embargo, una infraestructura completamente diferente a la de WiFi. Admito que sus restricciones de demora son relativamente laxas, pero también veo que la probabilidad de que no se cumplan en una red de redes WiFi es realmente alta. Como dijo AndrejaKo, esencialmente necesitarías 45 canales. WiFi tiene un máximo de 12 o 13 canales. Las cosas se pondrán peludas.

De hecho, hay una investigación / desarrollo serio en este momento para 5G, que, en lo que se refiere a las palabras de moda, debería convertirse en la base infraestructural de "Industria 4.0", es decir, exactamente lo que describen sus robots.

En cualquier caso, el problema general "Tengo muchas estaciones y requisitos de latencia estrictos, pero solo un espectro limitado" no es fácil, pero el WiFi definitivamente no es una opción viable aquí, no en ninguna modificación o restricción a un sub-estándar único. Piense más en los modos de los buses de automatización inalámbricos, ¡que ya existen!

    
respondido por el Marcus Müller
1

MQTT es un buen protocolo que puede usar en este proyecto para fines de comunicación. El protocolo es bastante transparente y fácil de enviar / transmitir mensajes entre robots. Puede usar un software para controlar estos dispositivos instalando la biblioteca MQTT.

El protocolo está disponible en casi todos los lenguajes de programación para adaptarse a cualquier sistema (controlador, PC, teléfonos inteligentes, web, etc.)

    
respondido por el Sanu - Open Maker

Lea otras preguntas en las etiquetas