¿PUEDE o no PUEDE?.

RS485 ha sido y sigue siendo durante mucho tiempo muy popular en los sistemas de seguridad para comunicaciones de nivel medio. Casi todos los sistemas lo utilizan al menos parcialmente, en al menos una de las versiones. En el nivel inferior, reinan los contactos secos y, a veces, los bucles direccionables especializados, en el nivel superior, Ethernet y el principal caballo de batalla, RS485.
Sí, no todos los sistemas dependen de RS485. Algunos usan Ethernet directamente en los controladores junior, algunos son completamente autónomos, pero en la mayoría de los sistemas, si era necesario conectar varios módulos, se usaba con mayor frecuencia RS485.
¿Por qué?

Es relativamente barato de implementar, relativamente poco exigente para la calidad de la línea de cable (calidad de la instalación) y, sin embargo, proporciona un buen rendimiento y rango de transmisión. Digamos simplemente, rendimiento aceptable y rango de transmisión suficiente.
En comparación, Ethernet es mucho más caro, para cualquier distancia razonable es necesario construir una infraestructura de enrutadores, conmutadores y varios tipos de cableado (óptica, etc.) y es muy exigente con la calidad de la red de cable. Finalmente, Ethernet (en la versión de par trenzado de cobre) ahora no se puede utilizar en sistemas automáticos contra incendios, porque los cables resistentes al fuego económicos (y según las normas técnicas vigentes, todos los cables en los sistemas automáticos contra incendios deben ser resistentes al fuego) no pueden mantener calidad (categoría) en un incendio. Como regla general, la resistencia al fuego se logra debido a la presencia de una delgada trenza de alambre o película no inflamable que protege los cables de cortocircuitos en caso de que se queme el aislamiento; no habrá cortocircuito, pero no es necesario Hable sobre el cumplimiento de los requisitos de Categoría 5 después de que se queme la funda.
Entonces, ¿realmente no existe ninguna alternativa y todavía no se ha inventado nada mejor que el estándar RS485 de 1983?
Por supuesto, se les ocurrió una alternativa, e incluso más de una. Por ejemplo, el estándar CAN, desarrollado inicialmente por Bosch para aplicaciones de automoción, parece muy interesante. Después del lanzamiento de la segunda versión de la especificación en 1991, el estándar se volvió internacional y se extendió bastante fuera de la industria original (automotriz).
Hace unos 10 años se hizo popular en la industria de la seguridad; aparecieron numerosos informes sobre el desarrollo de equipos de sistemas de seguridad basados ​​no en RS485, sino en CAN. Pero por alguna razón, en el último tiempo, no han aparecido muchos sistemas de este tipo en uso real, y la mayoría de los inicialmente anunciados han desaparecido sin dejar rastro.
¿CAN es realmente tan diferente de RS485? No. Lo que comúnmente se conoce como CAN es en realidad solo una de las capas físicas definidas en el estándar CAN, destinada a la transmisión a través de cobre de par trenzado: ISO 11898-2. Y, de hecho, este es un RS485 más complicado (y, en consecuencia, menos resistente al ruido y más lento).
Variantes existentes de la capa física CAN (aquellas que han recibido el estatus de estándares internacionales están marcadas).
CAN High-Speed ​​​​(ISO 11898-2)
CAN Low -Velocidad (ISO 11519-1)
Transceptores tolerantes a fallas (ISO 11898-3)
Transceptor de camión/remolque (ISO 11992)
Un solo cable (SAE 2411)
Transmisión por Fibra Óptica
Transmisión inalámbrica
Transmisión con fuente de alimentación
Cabe decir que CAN, a diferencia del RS485, que define únicamente el nivel físico (valores de tensión, corrientes, etc.), es un conjunto de muchos niveles de especificación. Por regla general, para una aplicación de seguridad no es necesario implementar todas las capas (mecanismos) CAN. Además, muchas funciones son completamente automotrices; simplemente no son apropiadas en un sistema de seguridad. Por ejemplo, la estandarización de los códigos de “intermitente izquierdo” o “temperatura del disco de freno trasero derecho”. Por supuesto, existe una organización llamada CAN en automatización, que desarrolla recomendaciones sobre cómo usar CAN en áreas distintas a la original, pero sus recomendaciones son en realidad un conjunto de deseos muy burdos, en muchos detalles completamente inútiles para los sistemas de seguridad (porque está enfocado a tareas de automatización industrial, lo que se acerca más a los problemas de seguridad, pero dista mucho de ser lo mismo).

Entonces, ¿qué es útil en CAN, por qué es mejor que RS485 y qué ¿Puedo usarlo?
Hay conceptos erróneos comunes de que CAN puede llegar más lejos y más rápido. De nada. La física de la transmisión de datos es incluso peor en comparación con RS485. Lo que comúnmente se conoce como CAN es ISO 11898-2. Es casi RS485, pero modificado y en absoluto para aumentar el alcance. Una modificación es una complicación del protocolo realizada para permitir que muchos dispositivos voten simultáneamente. La idea es que el controlador esté hecho para parecerse a un colector abierto, de modo que varios dispositivos puedan transmitir simultáneamente sin temor a quemar las salidas de cada uno al transmitir diferentes señales (en el proceso de desmontaje, quién superará a quién). De hecho, en CAN, los bits «0» se transmiten como en 485, pero los bits «1» no se transmiten en absoluto; los propios receptores deben adivinarlos por la ausencia de la señal «0». Está claro que la calidad de transmisión (alcance y velocidad permitida) de estos transmisores, por decirlo suavemente, no es mejor que la del 485.
El alcance de 5 km, del que se habla a menudo, es un alcance lógico: parece que en Ethernet existe el concepto de «dominio de colisión», cuyo tamaño para una red de 10 megabits es de 2 km, pero esto no significa en absoluto que es posible transmitir una señal Ethernet a lo largo de 2 km. Simplemente significa que ningún medio, ni siquiera la fibra óptica, puede transmitir más de 2 km en modo CSMA-CD. Igual que CAN. 5 km es la distancia máxima; en realidad es inalcanzable (excepto quizás en la versión de fibra óptica nunca aprobada de la interfaz física CAN). Y para el nivel físico ISO 11898-2, el alcance, como ya se mencionó, es siempre menor que para RS485 en las mismas condiciones. De hecho, la especificación no recomienda el uso de líneas de cable de cobre de más de 200 m, mientras que para RS485 se conocen condiciones en las que es posible transmitir una señal a lo largo de 3 km y 5 km.
¿Por qué CAN es mejor? Realmente, uno. El mismo mecanismo por el cual los parámetros físicos de CAN se «estropearon» en comparación con RS485. CAN tiene un mecanismo de «interrupción», cuando un dispositivo que tiene información urgente que transmitir puede requerir servicio, y si hay varios de estos dispositivos, entonces el mecanismo de arbitraje del bus garantizará su servicio secuencial.
¿Bien? Indudablemente. El procesamiento de la primera alarma se puede acelerar considerablemente. En sistemas deficientes basados ​​en RS485, este tiempo puede ser de hasta 10 segundos. Para los sistemas basados ​​en CAN, este tiempo se puede reducir a 10 a 20 milisegundos. Esto es realmente bueno. Es cierto que “se puede acortar” y “reducir” son dos grandes diferencias. No todos los que declararon el uso de CAN lograron implementarlo. Además, existen formas de reducir este tiempo a unos 200 ms en un RS485 normal. Existen tales sistemas, los conozco (los hice yo mismo).
Por otro lado, hay otro parámetro: el número máximo de alarmas que el sistema puede procesar por segundo. Este parámetro es peor para CAN; después de todo, cada alarma no solo debe transmitirse, sino que primero debe participar en el proceso de arbitraje. Este parámetro es menos importante; se considera seriamente sólo en sistemas para objetos muy serios, cuando, entre muchos, consideran un escenario como falsas alarmas masivas en un flanco, en cuyo contexto se realiza un avance preciso en el otro. . El sistema está obligado a detectar este avance preciso, a pesar de estar lleno de señales de alarmas que distraen deliberadamente. El escenario no es tan increíble. Una falsa alarma se puede provocar de forma remota de muchas maneras, desde interferencias de radio hasta, por ejemplo, disparar a un elemento sensor de vibración desde una pistola de aire comprimido.
No discutamos, la capacidad de solicitar servicio de forma asincrónica es buena para los sistemas de seguridad.
¿Qué más es CAN mejor? Por desgracia, nada. Entonces comienzan las desventajas.
El primero es el tamaño de trama limitado, es decir, la cantidad de datos transmitidos en un paquete. Como resultado, las transferencias grandes, como la configuración del controlador, toman un tiempo considerable y causan enormes dificultades de programación. Inconveniente es una categoría completamente material. Si es inconveniente para el programador, significa que el programa tendrá más errores y menos comodidad para el usuario.
El segundo inconveniente es el paradigma inusual. Los datos en CAN se caracterizan principalmente no por la fuente y el receptor, sino por la información que transmiten. En la tecnología del automóvil esto probablemente sea conveniente. La cantidad de diferentes tipos de datos es limitada, todas las situaciones se conocen de antemano, pero se puede ver inmediatamente lo que está sucediendo. Por ejemplo, el comando «reducir la velocidad». Y no importa si la orden proviene del pedal (del conductor) o del sensor de distancia por radar al coche que circula delante. Sí, por supuesto, puedes cambiar todo y usar en secreto las direcciones habituales de los dispositivos en lugar de los tipos de comandos. Pero esto también requiere violencia contra el programador y no mejora la calidad del programa.
El último inconveniente (pero no el menor) es el precio. Los microcontroladores que admiten CAN siguen siendo mucho más caros que sus homólogos, que no tienen soporte para el novedoso protocolo a bordo.
¿Qué vemos como resultado? La mayoría de sistemas que aparecieron (o al menos se anunciaron) cuando se puso de moda CAN han desaparecido sin dejar rastro. Esto se debe a que estas deficiencias (de una forma u otra reduciéndose a las palabras «inconvenientes para el programador») les rompieron la espalda. Los esfuerzos para perfeccionar los sistemas resultaron ser inaceptablemente grandes, y las empresas de desarrollo prefirieron modernizar ampliamente sus sistemas RS485 en lugar de cambiar a sistemas basados ​​en CAN nuevos y completamente incompatibles (lógicamente incompatibles, en términos de estructura de conceptos).
En los últimos años, el número de sistemas que utilizan CAN ha vuelto a aumentar. Ahora esto ya no es una moda, ahora lo utilizan aquellos desarrolladores que se han acostumbrado a ello en otras áreas, por ejemplo, los ingenieros que llegaron a un lugar seguro desde la electrónica automotriz. Es más fácil y más común para ellos usar CAN – bueno, gracias a Dios. También hay una serie de ingenieros, especialmente los jóvenes, a quienes generalmente no les importa qué usar, no tienen experiencia con ninguno de los dos. Sin embargo, ahora se están creando muchos más equipos que utilizan Ethernet. El costo de los microcontroladores integrados Ethernet está cayendo rápidamente (de hecho, se ha vuelto igual al costo de CAN), y su conveniencia y estandarización (compatibilidad, idoneidad para la transmisión mediante sistemas de terceros) son incomparables con RS485 o CAN.
A modo de comparación, ¿recuerda cuánto esfuerzo requirió crear un sistema de videovigilancia de 100 cámaras de vídeo hace 10 años? ¿Y ahora? Enciendes tu portátil (o sacas tu smartphone del bolsillo) y, sin siquiera pensar en las dificultades de integración, utilizas el sistema de videovigilancia de miles de cámaras web ubicadas en todo el mundo.
Entonces, aunque CAN es mejor (teóricamente) que RS485, es poco probable que los sistemas basados ​​en él sean mejores que los sistemas basados ​​en RS485, al menos es poco probable que mejoren antes de que ambos desaparezcan bajo el ataque de las ubicuas tecnologías de Internet.