CAN Bus, which stands for Controller Area Network Bus, is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a host computer. It was originally developed by Bosch in the 1980s for use in automotive applications, but has since been adopted in a variety of other contexts.
With competitive price and timely delivery, sonnepower sincerely hope to be your supplier and partner.
The CAN Bus system is a message-based protocol, characterized by its multi-master design, which means that multiple devices, known as nodes, can communicate on the same network. It is well-regarded for its high resistance to interference, its ability to function over long distances, and its efficient communication between numerous nodes.
Reliability and Fault Tolerance
: CAN Bus is designed to be highly reliable, capable of detecting errors and isolating faulty nodes to prevent the entire network from being affected.Efficiency
: It allows for real-time data transmission with minimal delays, making it ideal for critical systems in vehicles where timing is crucial.Flexibility
: The network can be extended with new devices without significant changes to the existing system architecture.Low Cost
: Compared to other communication protocols, CAN Bus is relatively inexpensive to implement, requiring fewer wires and simpler connectors.Widespread Adoption
: Originally designed for automotive applications, CAN Bus is now used in industrial automation, medical equipment, and other embedded systems.CAN Bus plays a critical role in modern automotive electronics, handling the communication between various systems such as engine management units, active suspension, ABS, airbags, lighting, and many others. Its durability and simplicity have made it a standard in complex systems where reliable communication is essential.
CAN Bus has broad applications across several industries, owing to its reliability and efficient communication capabilities:
Automotive Industry
: It is extensively used in modern vehicles for communication between various electronic control units (ECUs) such as engine control modules, transmission, ABS, airbags, and more.Industrial Automation
: CAN Bus facilitates communication between machinery and sensors in manufacturing and automation systems.Medical Equipment
: In medical devices, CAN Bus is used for reliable data transmission between different components of complex equipment.Marine and Aviation Electronics
: It is employed in marine and aviation systems for monitoring and controlling navigation, engine, and other vital systems.Building Automation
: CAN Bus is also used in building automation systems for controlling lighting, HVAC, and other building management systems.The widespread adoption of CAN Bus can be attributed to several key benefits:
Robustness and Reliability
: CAN Bus provides a reliable communication channel, even in environments with high electromagnetic interference, crucial for automotive and industrial applications.Reduced Wiring Complexity
: Its multi-master network capability reduces the need for extensive wiring, simplifying system design and reducing costs.Real-time Communication
: It enables real-time data transmission, essential in critical control and safety systems.Scalability
: The network can be expanded with additional nodes without significant changes to the infrastructure, offering excellent scalability.Ease of Troubleshooting
: Error detection and handling capabilities of CAN Bus simplify maintenance and troubleshooting of network issues.By enabling efficient and dependable communication between various electronic components, CAN Bus plays a pivotal role in enhancing the functionality and performance of complex systems across these diverse sectors.
What is a CAN Bus system?
What makes CAN Bus suitable for automotive applications?
How does CAN Bus improve safety in vehicle systems?
Can CAN Bus be used in non-automotive applications?
What are the limitations of CAN Bus?
How is CAN Bus integrated into existing systems?
How do I check my CAN Bus?
What does CAN network stand for?
The Controller Area Network (CAN bus) is a message-based protocol designed to allow the Electronic Control Units (ECUs) found in today’s automobiles, as well as other devices, to communicate with each other in a reliable, priority-driven fashion. Messages or “frames” are received by all devices in the network, which does not require a host computer. CAN is supported by a rich set of international standards under ISO 11898.
CAN bus network schematicCAN FD is a “Flexible Data (Rate)” version of the CAN bus. The standard length of each message has been increased by 800% to 64 bytes, and the maximum data rate has been similarly increased from 1 Mbps to 8 Mbps. The “flexible” part refers to the fact that ECUs can dynamically change their transmission rates and select larger or smaller message sizes, based on real-time requirements.
Despite all of these advances, CAN FD is still completely backwardly compatible with standard CAN 2.0. Today, CAN FD is found in very high-performance vehicles, but it is expected to migrate across all or most vehicles eventually.
This video provides excellent background information about vehicle data buses, including CAN:
The CAN bus standard is widely accepted and is used in practically all vehicles and many machines. This is mainly due to below key benefits:
Simple and low cost: ECUs communicate via a single CAN system instead of via direct complex analog signal lines - reducing errors, weight, wiring, and costs. CAN chipsets are readily available and affordable.
Fully centralized: the CAN bus provides one point of entry to communicate with all network ECUs - enabling central diagnostics, data logging, and configuration.
Extremely robust: the system is robust towards electric disturbances and electromagnetic interference - ideal for safety-critical applications (e.g. vehicles)
Efficient: CAN frames are prioritized by ID numbers. The top priority data gets immediate bus access, without causing interruption of other frames.
Reduced vehicle weight: by the elimination of kilometres of heavily insulated electrical wires and their weight from the vehicle.
Easy deployment: a proven standard with a rich support ecosystem.
Resistant to EMI: this makes CAN ideal for critical applications in vehicles.
CAN has excellent control and fault detection capabilities. Detecting an error is easily done, and thus transmitted data gets to where it needs to go.
It is an ideal protocol when distributed control of a complex system is required. It reduces heavy wiring and thus costs and weight. The cost of the chips is low, and implementing CAN is relatively easy because of the clean design of the protocol.
Another advantage to using CAN is that the first two layers: the physical layer and the data link layer, are implemented in inexpensive microchips, available in several configurations.
Today, applications for CAN are dominated by the automotive and motor vehicle world, but they are not limited to that. CAN is found across virtually every industry. You can find the CAN protocol being used in:
Every kind of vehicle: motorcycles, automobiles, trucks...
Heavy-duty fleet telematics
Airplanes
Elevators
Manufacturing plants of all kinds
Ships
Medical equipment
Predictive maintenance systems
Washing machines, dryers, and other household appliances.
When you flip a switch in your house to turn on the lights, electricity flows through the switch to the lights. As a result, the switches and wiring need to be heavy and insulated enough to handle the maximum expected current. The walls of your house are filled with this heavy, insulated wiring.
Cars and trucks used to be wired exactly the same way: ever since Henry Ford got the idea to add lights and an electric horn to his cars in 1915, electricity flowed from the battery through switches to the lights and other devices. By the 1960s there were thousands of heavy wires running throughout every vehicle. Every bit of extra weight reduces a vehicle’s fuel efficiency.
Following the oil embargoes of the 1970s, there was increasing pressure on automobile manufacturers to improve their fuel efficiency. So they started looking for ways to reduce the weight of the cars they were making.
Typical electrical wiring in a passenger carBy the early 1980s, cars had more and more ECUs (electronic control units) inside them, and companies like Robert Bosch company of Germany were looking for a type of bus communication system that could be used as a communication system between multiple ECUs and vehicle systems. They searched the market but couldn’t find exactly what they needed, so they began developing the “Controller Area Network” in partnership with automobile manufacturer Mercedes-Benz and semiconductor maker Intel®, and several universities in Germany.
In 1986, Bosch introduced the CAN standard at the SAE Congress in Detroit. One year later Intel Corporation began shipments of the first CAN controller chips, and the automotive world was changed forever. Looking back, the weight savings that resulted from the development of CAN were almost a lucky by-product, but very real nonetheless.
The heavy cable is replaced with lightweight 2-wire CAN in today’s cars and trucksDevices on a CAN bus are called “nodes.” Each node consists of a CPU, CAN controller, and a transceiver, which adapts the signal levels of both data sent and received by the node. All nodes can send and receive data, but not at the same time.
Nodes cannot send data directly to each other. Instead, they send their data onto the network, where it is available to any node to which it has been addressed. The CAN protocol is lossless, employing a bitwise arbitration method to resolve contentions on the bus.
All of the nodes are synchronized so that they all sample data on the network simultaneously. However, data is not transmitted with clock (time) data, so CAN is not truly a synchronous bus, such as EtherCAT, for example.
With CAN, all data are sent in frames, and there are four types:
Data frames transfer data to one or many receiver nodes
Remote frames ask for data from other nodes
Error frames report errors
Overload frames report overload conditions
There are two variants of the message length: standard and extended. The real difference is the additional 18-bit identifier in the arbitration field.
Standard and Extended frame of the CAN data message architectureThe arbitration field contains the message identification number and remote transmission request bit. More important messages have lower ID numbers.
If multiple nodes transmit at the same time, they start a simultaneous arbitration. The node with the lowest message ID number gets priority. Dominant bits overwrite recessive bits on the CAN bus.
The message identifier can be 11-bit (Standard CAN, 2048 different message identifiers) or 29-bit in length (Extended CAN, 537 million different message identifiers). The remote transmission request bit is dominant and indicates that data is being transmitted.
In most systems, logical 1 represents a high, and logical 0 represents a low. But this is the other way around on the CAN bus. CAN transceivers therefore typically use a pull-up on the driver inputs and receiver outputs, so that devices have defaulted to a recessive bus state.
The ISO 11898 standard defines several versions of CAN. The dominant CAN types used within the automobile industry are:
Low Speed CAN
High Speed CAN
CAN FD (Flexible Data Rate CAN)
Used for fault-tolerant systems that do not require high update rates. The maximum data transfer rate is 125 kbps, but the wiring is thus more economical than high-speed CAN. In automotive applications, low-speed CAN is used for diagnostics, dashboard controls and displays, power windows, etc.
Used for communications between critical subsystems that require high update rates and high data accuracy (e.g., anti-lock braking system, electronic stability control, airbags, engine control units, etc). Data transfer speeds of high-speed CAN range from 1 kbit to 1 Mbit per second.
High-speed CAN is faster than low speed, but the bandwidth requirement of new automotive applications is increasing every year, so automobile OEMs are now installing CAN FD into new cars. CAN FD has been described tongue-in-cheek as “CAN on steroids.”
The latest version of CAN introduces a flexible data rate, more data per message, and much higher speed transmissions. The data length within each standard (low speed and high speed) CAN message is 8 bytes, but with CAN FD this has been increased by 800% to 64 bytes of data. In addition, the maximum data rate has also been increased dramatically from 1 Mbps to 8 Mbps.
CAN FD data frame formatCAN FD is also backwardly-compatible and supports the CAN 2.0 communication protocol as well as special protocols such as SAE J1939, where CAN out is used as read-only. CAN FD is essentially an extension of the original CAN standard as specified in ISO 11898-1, and is fully compatible with classical CAN systems.
CAN FD is an important step forward because it allows ECUs to dynamically change their transmission rates and select larger or smaller message sizes, based on real-time requirements. It is found now in high-performance vehicles, but as ECU performance rises and CAN FD hardware costs fall, it is only a matter of time before CAN FD makes its way into virtually all vehicles.
Why do we need additional standards and protocols “on top” of CAN? It’s simply because while CAN is an elegant and reliable protocol, that’s really all it is. It is a messaging system, but it does not include any way to analyze or understand the data within the messages. This is why several companies have created additional standards and protocols that run within or on top of CAN, providing additional functionalities. The best known of these include:
The SAE J1939 protocol was developed originally to be used by heavy trucks and tractor-trailer rigs in the USA. Today it is used by diesel engine makers all over the world. J1939 is a higher-level protocol that runs on the CAN physical layer. It provides some useful functions specific to heavy trucks such as 18-wheel trucks.
SAE on CAN schematicThe protocol has a few restrictions that were intentionally put in place to promote the highest possible reliability, including limiting the message identifier to 29-bits and limiting the bus speed to either 250 or 500 kbps.
CAN bus setup screen in DewesoftX software. Notice the J1939 checkbox near the top-left.DewesoftX software allows the engineer to select J1939 decoding via a checkbox on the CAN setup screen for any available CAN port. Of course, this assumes that the messages on the CAN bus are formatted according to the J1939 standard. Data messages are the same length as the extended CAN standard.
The arbitration field contains an additional source and destination address, and the baud rate is limited to 250 kbps or 500 kbps, depending on the J1939 standard version being used. J1939 is a selection on the standard Dewesoft X CAN setup screen - no additional hardware or software is required.
Learn more:
This on-board diagnostics port is found in all cars made since 1989. Usually located within 2 feet (0.61 meters) of the steering wheel, it’s an interface that allows automobile repair shops as well as vehicle owners to diagnose vehicle problems by connecting a scanning tool to its 16-pin connector. (Pictured here under the steering wheel in the 2016 Toyota 4Runner).
OBD II connector on a vehicleScanning tools can read the DTC (diagnostic trouble codes) reported by the vehicle. The OBD II interface is required to carry dozens of channels of real-time data, such as RPM, vehicle speed, coolant temperature, and more. Dewesoft CAN interfaces can be connected to this OBD II connector as shown below, and can read out, display, and record any or all of these channels in sync with the other data being recorded.
OBD II connector (left) connected to a Dewesoft CAN interface connector (right)Just part of the ODB II setup screen in DewesoftX softwareDecoding, displaying, and recording ODB II messages in Dewesoft systems require an additional ODB II software plugin. You can scan DTC (diagnostic trouble codes) and much more with this system.
Learn more:
The Universal Measurement and Calibration Protocol (XCP) was designed to connect ECUs to calibration systems. The “universal” in its name refers to the fact that it can run on top of the CAN bus, CAN FD, FlexRay, Ethernet, and more. It is the successor to the original CAN Calibration Protocol (CCP) developed in the 1990s.
Dewesoft supports XCP/CCP protocols via XCP/CCP Master and XCP/CCP Slave plugins that run in DewesoftX DAQ software. Standard Dewesoft CAN (and ethernet) interface hardware can be used.
If you are looking for more details, kindly visit what is can bus systems in vehicles.
Dewesoft XCP presentation video
In addition to these XCP Slave and Master plugins, Dewesoft’s SIRIUS XHS and IOLITE LX data acquisition systems can natively serve data via XCP on Ethernet without the need for any additional software. Please watch this short introductory video for more information about Dewesoft XCP Data Acquisition Systems and XCP Data Loggers:
Learn more:
CANopen is a higher-layer protocol that is used for embedded control applications. Because it is based on the CAN messaging protocol, DAQ systems and data loggers that can read and record CAN data can also access data from CANopen.
CANopen was invented to provide easy interoperability among devices in motion control systems. Communication among and between devices is implemented at a high level, and device configuration is also supported. It’s heavily used in motion control, robotics, and motor control applications.
CANopen is managed by the international organization CAN in Automation - CiA. Established in Germany in 1992, CiA is a non-profit international users/manufacturers group for CAN. They take pride in being an unbiased platform for the development of the CAN protocol, and for promoting the image of CAN technology.
CANopen provides several additional concepts, including:
Three basic communication models
Master/Slave - where one node is the “master” and all others are slaves.
Client/Server - somewhat similar to master/slaves, except that the nodes are servers of data upon request to a client node.
Producer/Consumer - where certain nodes are configured to produce certain kinds of data automatically, while other nodes are configured to consume it.
Two basic communication protocols
SDOs for node configuration
PDOs for sending real-time data
Device profiles
CiA 401 Input/output modules
CiA 402 motion-control for vendor independence
Object dictionary
There is an OD (Object Dictionary) for each device on the network. The OD has a standard configuration for the data that defines the configuration of each device on the network.
Device states
A master node is capable of changing or resetting the state of devices on the network.
Electronic data sheets (EDS)
The EDS is a standard file format for OD entries - allowing e.g. service tools to update devices
Connections among CANopen concepts and capabilitiesIn addition to CAN and the protocols that run on it described in the previous sections, there are other communication buses that are used for vehicle applications:
MOST (Media-Oriented Systems Transport)
Automotive Ethernet
SENT SAE-J2716
FlexRAY
LIN Bus - Local Interconnect Network
Today's modern vehicles use a combination of multiple data buses. Let's take a look at each one of these and see how they compare to a CAN bus.
Multiple buses used in today’s vehiclesEveryone expects their new car to have a better, more capable entertainment system than their previous car. The old-fashioned AM/FM radio that was standard for more than 50 years has been transformed to accept removable media, from the old days of cassette and 8-track tapes to compact discs (CD) and removable flash media. Today the focus is on streaming content from mobile devices as well as satellite radio (SIRIUS/XM® in North America).
MOST bus - Media-orientated Systems TransportMedia-Oriented Systems Transport (MOST) is a standard bus used to interconnect vehicle entertainment and information systems developed by a partnership of carmakers called MOST Cooperation. It offers data rates of 25, 50, and 150 Mb/s. But it should be noted that these are aggregate rates that are divided among all of the nodes on the bus.
MOST is used in nearly every car brand around the world. Up to 64 devices can be connected to a MOST ring network, which allows devices to be connected or disconnected easily. Other topologies are also possible, including virtual stars. There are various versions of MOST, including:
MOST25 offers a 23 MB maximum streaming rate, which is really limited to about 10 kB/s due to protocol overhead and other limitations.
MOST50 doubles the bandwidth of MOST25.
MOST150 triples the bandwidth of MOST50 and adds a physical layer that allows ethernet to be added.
MOST is facing increasing competition from Automotive Ethernet, which is discussed below.
New technologies such as driver assistance and even self-driving/autonomous vehicle functionalities require higher and higher bandwidth in order to work. This need for speed, coupled with the low cost of Ethernet hardware, has been a big factor in promoting Automotive Ethernet among carmakers. Other motivations for automotive ethernet include the transfer rates needed for LIDAR and other sensors, raw camera data, GPS data, map data, and higher and higher resolution flatscreen displays.
Automotive EthernetBut unlike our comfortable home and office environments, a vehicle is subject to a much wider range of temperatures, shocks, and continuous vibrations. In addition, there is EMI and RFI that must be blocked so that critical data is not interfered with, especially those related to driver assistance and collision avoidance.
The term “Automotive Ethernet” does not refer to a specific standard per se. It includes any Ethernet-based network used within vehicles. It is also meant to refer to the OPEN Alliance BroadR-Reach standard developed by Broadcom, and to IEEE 802.3bw-2015 aka 100Base-T1.
Despite its obvious advantages of speed and worldwide popularity, until recent years ethernet was only used for diagnostic applications in cars - in other words when the car was under service and not moving. Why? Because of its susceptibility to EMI (electromagnetic interference) and RFI (radio frequency interference), lack of inherent deterministic time synchronization, and susceptibility to connector failure due to the vibration. Standard CAT5 connectors, for example, cannot survive in automobiles under normal use.
However, these issues are being addressed by the IEEE 802.3 and 802.1 working groups. In the meantime, chipmaker Broadcom has developed BroadR-Reach™, which adapts Ethernet technology for automotive use. BroadR-Reach provides 100 Mb/s speed using unshielded twisted-pair cabling up to 15 meters, or up to 40 meters when a shield is added to the cables.
BroadR-Reach Automotive Ethernet topology. Broadcom's PHY chips simultaneously send and receive data bi-directionallyBroadR-Reach has been adopted by some carmakers for infotainment systems, driver assistance, on board-diagnostics, and even ADAS applications. It offers 100 Mbps data rates per port, which is much higher than MOST’s 150 Mbps aggregate rate, for example.
The BroadR-Reach standard is overseen by the OPEN (One-Pair Ether-Net) Alliance, which advocates for the adoption of Automotive Ethernet.
Ethernet AVB (Audio Video Bridging) is the IEEE standard AVB1.0. It is moving toward acceptance for use with cameras and multimedia systems. AVB2.0 is aimed at vehicle control applications. AVB is promoted by the AVnu Alliance.
Ethernet TSN (Time-Sensitive Networking) is the IEEE 802.1 standard designed to allow deterministic messaging across standard Ethernet. Not a protocol per se, TSN is a standard implemented at Layer 2 of the Ethernet OSI - i.e., the Data layer (AVB is also a Layer 2 standard).
As an extension of Ethernet AVB described above, TSN focuses on the kind of time synchronization, scheduling, and packet shaping that are necessary for self-driving vehicle applications. Because TSN is all about “time,” Precision Time Protocols (PTP) IEEE 802.1AS and IEEE 802.1ASRev have been selected to provide a shared concept of time across devices.
Learn more:
According to Gartner, in 2017 there were a total of 19.3 million ethernet ports installed in consumer vehicles. By 2020 this has risen to 122.8 million, a number that is projected to double by 2023.
SENT SAE-J2716 (Single Edge Nibble Transmission) was designed to be a low-cost protocol alternative to CAN or LIN. It’s a one-way transmission protocol that allows sensors to send their data to ECUs.
Data is encoded using pulse code modulation (PCM) and transmitted on a single wire. There are three wires in total: signal, ground, and power. Data is encoded in 4-bit “nibbles.”
A typical SENT message is 32 bits (8 nibbles), comprised of:
Signal data: 24 bits (6 nibbles)
CRC error detection: 4 bits (1 nibble)
Status info: 4 bits (1 nibble)
It is also possible to configure messages of 20 bits (5 nibbles), where the data is only 12-bits (3 nibbles).
Due to its modulated data design, SENT is ideal for use in electrically noisy environments.
Dewesoft systems support SENT SAE-J2716 data using counter channels to read a SENT signal that is being transmitted by a sensor. Two fast channels and any number of slow channels can be detected automatically. Engineers can decode SENT signals from multiple sensors simultaneously where each sensor is using a different counter, by adding multiple module windows. SENT channels are available as Dewesoft channels.
Learn more:
FlexRAY is a protocol used for dynamic automotive applications such as chassis control. It was created in 2005 by the FlexRAY Consortium but has since been standardized under ISO 17458-1 to 17458-5.
FlexRAY transmits data over one or two unshielded, twisted pair cables. It runs at 10 Mbps and supports one or two-wire configurations. Bus, star, and hybrid network topologies are supported, at speeds up to 10 Mbps. Differential signalling keeps noise low without the need for shielded cables, which adds cost and weight.
As with CAN, only one node can write to a FlexRAY bus at the same time. CAN uses an arbitration bit to determine which data gets priority and is allowed to proceed. FlexRAY, on the other hand, uses a Time Division Multiple Access (TDMA) method where each time-synchronized node must wait for its turn to send a message. This avoids collisions and allows higher overall throughput of data across the bus due to the high overall data rate of the bus.
FlexRAY is often implemented in the classic multi-drop topology shared by LIN and CAN, however, it can also be configured in a star topology. Star topology has the advantage of not allowing a wiring fault to affect more than one node. FlexRAY can also be implemented in a mixed topology, as shown below.
Network topologies: Left: Multi-drop, Center: Star, Right: MixedFlexRAY is used most often for high-performance powertrain, safety, and active chassis control applications. FlexRAY is more expensive than a CAN bus implementation.
However, when dual pairs of parallel data lines are used, this provides redundancy: when a line is damaged, the second line can take over. This is important in mission-critical applications like steering and braking. FlexRAY applications that are not mission-critical typically use a single twisted pair.
Dewesoft systems can easily acquire FlexRAY data using the FIBEX library import option. A software plugin is available to support all Vector FlexRay interface cards.
LIN bus is an inexpensive alternative to the CAN bus. It’s very simple but necessarily limited to one master and 15 slave nodes. LIN is a serial unidirectional messaging system, where the slaves listen for message identifiers addressed to them.
Because of its lower bandwidth and node count limitations, LIN is normally used to control small electric motors and controls. LIN is limited to 19.2 kbps or 20 kbps data rate.
Adjustable car seat controls in a Mercedes-BenzLIN is a single-wire network defined by ISO 9141. It is used for low-bandwidth applications such as electric windows, lights, door locks, keycard entry systems, electric mirrors, power seats, and similar.
The LIN bus plugin for DewesoftX allows engineers to connect and listen to communication on multiple LIN networks. Using Vector brand LIN BUS hardware, it mimics listen-only slaves that listen to all data transmission on the bus. Decoding can be done in three different forms:
Analog data with extensive scaling options
Discrete data
A mixture of both
The plugin supports importing the configuration from LIN description files (LDF). To read the LIN bus, a Vector LIN BUS card is required.
Notes: * UTP = unshielded twisted pair
As with any networking and interoperable system, automotive bus choice is best driven by the requirements of the application, while keeping an eye on cost and projected industry requirements and trends. Clearly, carmakers don’t want to implement old buses in new designs, when there are better buses available at an equivalent or better deployment cost.
The CAN bus interfaces provided as standard or optional with Dewesoft systems provide a high level of capability, as well as extensibility to additional protocols.
Dewesoft SIRIUS DAQ module recording analog, digital, and CAN bus vehicle dataAll Dewesoft CAN interface are galvanically isolated, protecting the instrument and connected devices from ground loops and other electrical disturbances. All Dewesoft CAN interface utilize the high-speed CAN 2.0b standard. Dewesoft also offers a CAN FD device.
All Dewesoft CAN interfaces can both read and write CAN messages, allowing engineers to put messages onto the bus, in order to request data from CAN devices on the network and more.
All Dewesoft CAN interfaces can be configured in seconds, because the included DewesoftX data acquisition software can import DBC files. DBC files are a standard format that allows engineers to parse the data stream into individual channels with names, scaling, proper engineering units, and more.
DewesoftX can bus channelsClicking the “Setup” button on the far right of any message row opens the CAN channel setup screen shown below:
DewesoftX CAN bus channel setup screen, showing five different channels contained within a single messageDewesoftX makes it extremely easy to configure CAN channels. The software can import and export CAN DBC or XML files. DBC files are common files for CAN messages and channel definitions. After the import software will automatically set up all available CAN channels and decode CAN messages.
Advanced CAN recording, storing, and analysis
On-line monitoring and decoding of CAN messages
Off-line CAN message decoding
Visual display for displaying CAN data
Online and offline math analysis of CAN channels
CAN DBC file import and export
OBDII on CAN, J1939, and XCP/CCP support
CAN transmit functionality
Dewesoft was among the first DAQ system makers to fully implement CAN bus interfaces with their analog data acquisition system. Nearly every Dewesoft DAQ system has at least one CAN bus interface built-in as standard. Additional dedicated CAN interface can be added internally, externally, or both, while still maintaining perfect synchronization with analog data.
Dewesoft CAN bus interfacesAs mentioned before, nearly every Dewesoft DAQ system has at least one CAN port built-in as standard, and all systems can be outfitted with CAN if it’s not standard, according to this table:
*Externally means that one or more external and synchronizable CAN interfaces can be added. These include the DS-CAN2, SIRIUSim-4X-CAN, SIRIUSf-8x-CAN, and KRYPTONi-1xCAN-FD.ModelCAN port(s) standard?Additional CAN ports?DEWE-43A2 CAN bus ports Externally*MINITAURs1 CAN bus or CAN FD portExternally*SIRIUS XHS1 CAN bus or CAN FD portExternally*SIRIUS modular1 CAN bus or CAN FD portExternally*SIRIUS rack (R2, R3, R4, R8, R1DB, R2DB, R8DB)1 CAN bus or CAN FD port per amplifier moduleExternally*SIRIUS miniNoExternally*SIRIUS WaterproofYesExternally*KRYPTONDedicated KRYPTON CAN and CAN FD modulesExternally*IOLITENoExternally*IOLITE LXYes, 1 CAN port is standardExternally*IOLITE modularNoExternally*In addition to the CAN port(s) built into nearly every Dewesoft DAQ system, separate synchronizable 2, 4, and 8-port CAN interfaces are available. These connect to either a Windows PC running DewesoftX software or directly to a Dewesoft DAQ system.
The latest member of the Dewesoft CAN bus family is the KRYPTONi-1xCAN-FD. This is a single-port CAN FD device that connects to the DAQ system via the EtherCAT® interface. It supports high-speed CAN data rates up to 8 Mbps. In addition, CAN FD supports the CAN 2.0 communication protocol as well as special protocols such as J1939.
KRYPTON 1xCAN FDKRYPTONi-1xCAN-FD has galvanically isolated communication lines and an isolated sensor supply of +5 V and +12 V. The power limit of the sensor supply is 1.4 watts. It can withstand extreme environmental conditions, such as an operating temperature range of -40°C and +85 °C (-40 to +185° F), and is sealed against dust and liquids according to IP67.
For more can network automotiveinformation, please contact us. We will provide professional answers.