CAN Newsletter magazine
The CAN Newsletter magazine reported already in its cover story of the December 1996 issue about the FDR1-CAN flight data recording system. Nowadays, CAN is used in Boeing and Airbus aircrafts, in helicopters, in drones, and even in satellites in the outer space.
In 1996, the Aviat Pitts Special S-2B aircraft tested the CAN-connected flight data recorder for 28 flight hours without any problems. The modular system was developed by Michael Stock. He is also the main inventor of the CANaerospace higher-layer protocol. It is suitable for airborne systems employing the line-replaceable unit (LRU) concept. In order to avoid unacceptable frame transmission delays, CANaerospace recommends to limit the bandwidth usage to 50 percent. This means even in case of error frames, there is enough margin to overcome temporary fault situations.
CAN has also been used in flight simulators for entertainment or training purposes. These systems reproduced the cockpit of an aircraft as realistically as possible. Traditional architectures of flight simulators use several personal computers and point-to-point connections to link the cockpit devices with the simulation software. A paper from CAN in Automation’s (CiA) 16th international CAN Conference (iCC) from 2017, described the development of CAN-based modules for A320 flight simulators. The recorded presentation can be watched here.
The used application layer is based on the above-mentioned CANaerospace and provides users with the ability to ask for the identification of the devices, to change the Node-ID, to configure some of the modules and to automatically configure the bit rate. Another paper of the 16th iCC introduced CAN FD in aviation. It can be watched here. The international CAN Conference is a platform for presentations of CAN developments. Experts from all over the world and from the most-diversified application areas have met for years at this international event.
Another iCC paper in 2006 from Airbus introduced CAN-connected smoke detectors. The company, explained: Within the fire protection system on an Airbus, smoke detectors are installed in various areas overall in the pressurized zones of the aircraft such as lavatories, equipment bays, and cargo compartments. As the CAN defines only layers 1 and 2 of the OSI communication model, additional higher layer features are necessary to achieve the level of operational assurance required for a safety critical application, namely fire protection on an aircraft. This paper particularly focused on the development of a safety critical CAN network with strict configuration control of smoke detectors in the scope of an aircraft application.
In 2012, Airbus again was part of the iCC and reported about the standardization of CAN networks for airborne use through Arinc 825. The Arinc 825 higher-layer protocol is based on some ideas from CANaerospace. The first usage was in the Airbus A350 aircraft. Of course, applicable regulatory documents published by the FAA, EASA and/or other regulatory bodies need to be considered, too. In some aircrafts such as the Airbus A380 and Boeing 787, are about 80 to 250 CAN networks in duty. They are often connected to an Ethernet-based backbone network compliant with the Arinc 664 (AFDX) specification. Arinc 825 uses only the data frames with 29-bit identifiers. In the Supplement 4 of the Arinc 825 the usage of CAN FD is specified. The bit rate is 4 Mbit/s.
Modern unmanned aerial vehicles (UAV) debuted as an important weapon system in the early 1980s. Israeli Defense Forces fitted small drones resembling large model airplanes with trainable television and infrared cameras and with target designators for laser-guided munitions, all downlinked to a control station. Nowadays, many of such combat drones use embedded CAN networks, the CAN Newsletter Online reported. But also drones for leisure purposes are equipped with embedded CAN networks. The drone community has developed the open-source UAVCAN higher-layer protocol. It is a simple application layer. DroneCAN was created to continue the development of the UAVCAN v0 protocol.
The proposed introduction of the UAVCAN version 1 protocol involved changes to UAVCAN that increased complexity and did not offer a smooth migration path for existing deployments. DroneCAN is the CAN-based high-layer protocol used by the Ardupilot and PX4 projects for communication with CAN peripherals. It is an open protocol with open communication, specification, and multiple open implementations. It supports CAN FD as well as Classical CAN.
The included DroneCAN transport layer supports unconfirmed multi-segment broadcast communication as well as a confirmed multi-segment communication. In the multi-segment approach an embedded CRC (cyclic redundancy check) sequence is transmitted in the first segment. Additionally, a toggle-bit ensures the detection of double-transmission of frames in case of a dominantly-detected last bit of the End-of-Frame field by the sender. DroneCAN does not require nodes to undergo any specific initialization upon connecting to the network – a node is free to begin functioning immediately once it is powered up. The only application-level function that every node needs to support is the periodic broadcasting of the node status message.
The open-source higher-layer protocol references some CiA documents such as CiA 303-1 for connector pin-assignments and CiA 103 for the physical layer. It is recommended to provide two identical parallel connectors for each CAN interface per device, so that the device can be connected to the network without the need to use T-connectors. They should be avoided, because they add an extra point of failure, increase the stub length and weight.
Mission-critical devices and non-mission critical devices often need to co-exist on the same DroneCAN network. Therefore, all devices should be connected to the primary CAN network. The mission-critical ones are connected to one or two additional backup CAN networks. DroneCAN is bit rate agnostic, so technically any bit rate can be used as long as it is suitable for the chosen network topology. However, only the recommended bit rates (1 Mbit/s, 500 kbit/s, 250 kbit/s, or 125 kbit/s) should be used to ensure compatibility. The sample-point should be located at 75 % of the bit time. The given maximum network length recommendations seem to be optimistic.
Designers are encouraged to implement automatic bit rate detection with reference to the CiA 801 application node. CiA 801 CANopen automatic bit rate detection, describes the recommended practice and gives application hints for implementing automatic bit rate detection in CANopen devices. With the layer setting services (LSS) it is possible to change the bit rate in CANopen networks.
The European Space Agency (ESA) has chosen CAN as embedded network in some of its satellites. Additionally, ESA and satellite suppliers have developed a CANopen subset as higher-layer protocol. This subset is specified in the ECSS-E-ST-50-15C document. ESA organized several “CAN in space” workshops. In summer 2017, they organized one in the south of Italy. It took place in the facilities of CiA member Sitael implementing CAN and CANopen completely in Asics.
News and reports