To CAN Or Not To CAN?.

RS485 has long been and remains very popular in security systems for organizing mid-level communications. Almost all systems use it at least partially, in at least one of the designs. At the lower level, dry contacts and sometimes specialized addressable loops reign supreme, at the upper level — Ethernet, and the main workhorse is RS485.
Yes, not all systems rely on RS485. Some use Ethernet right away on the junior controllers, some are completely autonomous, but in most systems, if it was necessary to connect several modules, RS485 was most often used.
Why?

It is relatively cheap to implement, relatively undemanding to the quality of the cable line (quality of installation), and at the same time provides good speed and transmission range. Let's say, acceptable speed and sufficient transmission range.
In comparison, Ethernet is much more expensive, for any reasonable distances it is necessary to build an infrastructure of routers, switches and different types of wiring (optics, etc.) and it is very demanding on the quality of the cable network. Finally, Ethernet (in the copper twisted pair version) cannot be used in fire-fighting automation systems now, because inexpensive fire-resistant cables (and according to the current technical regulations, all cables in fire-fighting automation systems must be fire-resistant) cannot maintain their quality (category) in a fire. As a rule, fire resistance is achieved due to the presence of a thin non-flammable braid made of wire or film that protects the wires from short circuits in the event of insulation burnout — there will be no short circuit, but there is no point in talking about compliance with Category-5 requirements after the shell burns out.
So is there really no alternative and nothing better than the RS485 standard of 1983 has been invented to this day?
Of course, they came up with an alternative, and not just one. For example, the CAN standard, originally developed by Bosch for automotive applications, seems very interesting. After the release of the second version of the specification in 1991, the standard became international and was widely distributed beyond the original industry (automotive manufacturing).
About 10 years ago, it became popular in the security industry, and there were numerous reports of the development of security system equipment based not on RS485, but on CAN. But for some reason, over the past time, not so many such systems have appeared in real use, and most of those originally announced have disappeared without a trace.
Is CAN really that different from RS485? No. What is commonly called CAN is in fact just one of the physical layers defined in the CAN standard, designed for transmission over copper twisted pair: ISO 11898-2. And in fact, it is a more complicated (and, accordingly, less noise-immune and slower) RS485.
Existing variants of the CAN physical layer (those that have received the status of international standards are marked).
CAN High-Speed ​​(ISO 11898-2)
CAN Low-Speed ​​(ISO 11519-1)
Fault-Tolerant Transceivers (ISO 11898-3)
Truck/Trailer Transceiver (ISO 11992)
Single-Wire (SAE 2411)
Fiber Optical Transmission
Wire-Less Transmission
Power-Supply Transmission
It should be said that CAN, unlike RS485, which defines only the physical level (voltage values, currents, etc.), is a set of many specification levels. As a rule, there is no need to implement all CAN levels (mechanisms) for use in a security system. Moreover, many functions are completely automotive, they are simply inappropriate for a security system. For example, standardization of codes «left turn signal» or «temperature of the right rear brake disc». Of course, there is an organization CAN in automation, which develops recommendations on how to use CAN in areas other than the original, but its recommendations are actually a very crude set of wishes, in many details completely useless for security systems (since they are focused on industrial automation tasks, which is closer to security tasks, but far from the same thing).

So what is useful in CAN, how is it better than RS485 and what can be used from it?
There is a common misconception that CAN can work further and faster. Not at all. The physics of data transmission is even worse than RS485. What is usually called CAN is ISO 11898-2. It is almost RS485, but modified, and not at all to increase the range. Modification is a complication of the protocol, made to allow multiple devices to vote simultaneously. The idea is that the driver is made similar to an open collector, so that several devices can transmit simultaneously without fear of burning each other's outputs when transmitting different signals (in the process of disassembling who will beat whom). In fact, in CAN, the «0» bits are transmitted as in 485, and the «1» bits are not transmitted at all — the receivers themselves must guess about them by the absence of the «0» signal. It is clear that the quality of transmission (range and permissible speed) of such transmitters, to put it mildly, is no better than that of 485.
The 5 km range that is often mentioned is a logical range — it seems that in Ethernet there is a concept of «collision domain», the size of which for a 10-megabit network is 2 km, but this does not mean that an Ethernet signal can be transmitted over 2 km via a twisted pair of category 3. It simply means that no medium, even fiber optics, can transmit more than 2 km in CSMA-CD mode. Similar to CAN. 5 km is the maximum distance, in reality it is unattainable (except for the never-approved fiber optic version of the CAN physical interface). And for the ISO 11898-2 physical layer, the range, as already mentioned, is always less than for RS485 under the same conditions. In fact, the specification does not recommend using copper cable lines longer than 200 m. While for RS485, conditions are known in which a signal can be transmitted over both 3 km and 5 km.
Why is CAN better? In fact, one thing. The same mechanism for which the physical parameters of CAN were “spoiled” compared to RS485. CAN has an “interruption” mechanism, when a device with urgent information to transmit may require servicing, and if there are several such devices, the bus arbitration mechanism will provide their sequential servicing.
Good? Certainly. The processing of the first alarm signal can be greatly accelerated. In bad RS485-based systems, this time can reach 10 seconds. For CAN-based systems, this time can be reduced to 10–20 milliseconds. This is really good. However, “can be reduced” and “reduced” are two very different things. Not everyone who declared the use of CAN managed to implement this. In addition, there are ways to reduce this time to about 200 ms on a regular RS485. Such systems exist, I know them (I made them myself).
On the other hand, there is another parameter — the maximum number of alarms that the system can process per second. This parameter is worse for CAN — after all, each alarm must not only be transmitted, but must first participate in the arbitration process. This parameter is less important, it is seriously considered only in systems for very serious objects, when, among many, such a scenario is considered as massive false alarms on one flank, against the background of which a pinpoint breakthrough occurs on the other. The system is obliged to process this pinpoint breakthrough, despite the litter of signals from deliberately created distracting alarms. The scenario is not so improbable. A false alarm can be remotely triggered in many ways, ranging from radio interference to, for example, shooting at a vibration sensitive element with an air gun.
Let's not nitpick, the ability to asynchronously call service is good for security systems.
What else is CAN better? Alas, nothing. Then the disadvantages begin.
The first is the limited frame size, i.e. the amount of data transferred in one packet. As a result, the transfer of large volumes, for example, configuring a controller, takes a significant amount of time and causes jaw-dropping difficulties in programming. Inconvenient — this is a very material category. Inconvenient for the programmer, it means that the program will have more errors and less convenience for the user.
The second drawback is the unfamiliar paradigm. Data in CAN is characterized primarily not by the source and receiver, but by the information they transmit. In automotive technology, this is probably convenient. The number of different types of data is limited, all situations are known in advance, but it is immediately clear what is happening. For example, the command «brake». And it does not matter whether the command is from the pedal (from the driver) or from the radar sensor of the distance to the car in front. Yes, of course, you can turn everything upside down and secretly use the usual device addresses instead of command types. But this also requires violence against the programmer and does not improve the quality of the program.
The last (but far from the smallest) drawback is the price. Microcontrollers that support CAN are still significantly more expensive than their counterparts that do not have support for the newfangled protocol on board.
What do we see as a result? Most of the systems that appeared (or at least were announced) when CAN became fashionable, disappeared without a trace. This is because the above-mentioned shortcomings (one way or another boiled down to the words «inconvenience for the programmer») broke their backs. The efforts to fine-tune the systems turned out to be unacceptably large, and the development companies preferred to extensively modernize their RS485 systems, rather than switch to new and completely incompatible (logically incompatible, in terms of the structure of concepts) systems based on CAN.
In recent years, the number of systems using CAN has been growing again. It is no longer a fad, it is now used by those developers who are accustomed to it in other areas, for example, engineers who came to security from automotive electronics. It is easier and more familiar for them to use CAN — well, thank God. There are still a number of engineers, especially young ones, who do not care at all what to use, they have no experience with either. However, now incomparably more equipment is being created that uses Ethernet. The cost of Ethernet on board microcontrollers is rapidly falling (practically equal to the cost of CAN), and its convenience and standardness (compatibility, suitability for transmission by third-party systems) are incomparable with either RS485 or CAN.
For comparison, remember — what effort did it take 10 years ago to create a video surveillance system from 100 video cameras? And now? You turn on your laptop (or take your smartphone out of your pocket) and, without even thinking about any integration complexities, use a video surveillance system of thousands of webcams placed around the world.
So, although CAN is better (theoretically) than RS485, systems based on it are unlikely to become better than systems based on RS485, at least they are unlikely to have time to become better before both die out under the onslaught of ubiquitous Internet technologies.