In the field of CAN, aside from functional interaction and communication matrix design control, there is also the low-level testing of CAN, which mainly includes aspects such as CAN hardware, protocol stack, and software.
As automotive manufacturers and suppliers, we often focus on functional design implementation and the signal interactions related to functional implementation; these are our core tasks that directly determine the vehicle’s performance and whether the functions operate normally.These “signal interactions” refer to the CAN application layer design, such as how signals are defined, how transmission and reception are handled, how to manage disconnections, and how to integrate these into functional logic, etc.; these are the main tasks of automotive manufacturers.
There is also a part of the CAN bus content that is more focused on low-level software and hardware, known as “CAN consistency testing.” This means that we have set standards for the low-level software and hardware of CAN, and we need to find ways to see how well suppliers meet these requirements. For example, if we stipulate that a CAN node must not go bus-off after 10 seconds of not receiving an ACK, we need to design corresponding test cases and methods based on our requirements to check whether the controllers delivered by suppliers meet such requirements.Overall, this part of the work is quite challenging, tedious, and difficult to manage; it requires strong innovation ability, research capability, and a sense of responsibility to do well. Therefore, most automotive manufacturers do not engage in this much.Usually, they just provide suppliers with general requirements and later review the test reports submitted by the suppliers. If issues arise in the vehicle, then further actions can be taken.
01
What Does CAN Testing Include?
The basic content of CAN testing is outlined in the CAN protocol standards, primarily based on the ISO 11898 international standard, focusing on hardware and link layer aspects. For example, the following is a list of CAN physical layer test items we found on the website of Zhiyuan Electronics:
The advanced content of CAN testing mainly includes communication diagnostics and network management.What is called “communication diagnostics” refers to monitoring the quality of CAN communication. If abnormalities are detected, they need to be handled promptly. For example, if a received message drops, how should the node respond, what fault should be reported, and how to handle scenarios where a node cannot recover normally after going bus-off, or when the node’s transmission CheckSum and RollingCounter are abnormal, all fall under communication diagnostics.Of course, these contents need further detailed definitions, such as how long counts as a dropout? Is the communication monitoring function enabled?What is called “network diagnostics” mainly involves CAN sleep and wake-up. When the conditions for triggering are met, the master node sends a wake-up message, and when all conditions are not met, it sends a sleep command; when a slave node receives the wake-up message, it enters working mode, and when it receives the sleep command, it enters sleep mode…Again, these contents also need further detailed definitions, such as who is the master node and who is the slave node? What are the wake-up IDs, which signals are related to network management, etc., as well as several timing parameters for network management. Moreover, aside from mainstream management specifications like AutoSAR and OSEK, there are many custom standards derived from these two standards and those completely unrelated to them, so specific issues need specific analysis…Overall, these two types of testing are quite complex, simulating their working conditions is challenging, and companies with insufficient business proficiency cannot handle them, especially in recent years, the complexity of vehicle communication has significantly increased, the number of nodes has markedly risen, and the amount of signals has noticeably grown. Using methods from five years ago to handle these tasks seems somewhat amateurish!
02
Methods for Testing Basic CAN Content
Basic CAN testing can be conducted according to the requirements set by the ISO 11898 international standard, using a multimeter, oscilloscope, programmable power supply, etc., to test and observe the results, which can usually be managed.
03
Methods for Testing Advanced CAN Content
Advanced CAN testing, as previously mentioned, involves communication diagnostics and network management, and their testing is relatively complex. In terms of equipment, programmable power supplies, interference devices, waveform analyzers, etc., are needed, and flexible control of CAN node modes and real-time invocation of message transmission and reception states are also required.Therefore, although I really want to cheer for domestic products, in this field, considering software stability, completeness, and hardware reliability, it is still recommended to use the full suite of Vector equipment, including CANoe, VN1640, Vector programmable power supply, CANstress interference device, etc. If necessary, diagnostic invocation modules like DIVA should also be included; the full set should be prepared!However, even if the full set is purchased, achieving good results in this area is still quite difficult!Because CAPL is really hard to use! Modifying CAPL programs is very inefficient; I even feel that CAPL code is very likely a trap set by imperialism to make our users unable to proceed with their work ๐
, leaving users in a difficult position. Moreover, I hear that some suppliers use graphical testing tools internally that call CAPL programs in the background, which is convenient, but the code delivered to customers is pure CAPL code, and the graphical content is converted to pure code ๐
๐
.I estimate that there is an emotional attachment here, unwilling to let this user go; they want to make it so that users cannot do without it. If they leave, they will find it difficult to move forward ๐
๐
๐
.
In the field of advanced CAN content testing, the Lion Team recommends adopting an automated testing method based on the full suite of Vector systems, mainly consisting of two approaches:Invocation MethodTest case parameters for CAN testing can be written into Excel (the parameters are not too many and are mostly intuitive), then read by Matlab to access these parameters and call CANoe, solving the problem without needing to modify CAPL programs but instead modifying Simulink programs.Generation MethodUsing the same test cases written in Excel, and with the help of Matlab or Excel’s VBA, translating the test cases into CAPL code, then copying it to the testing project’s code interface, compiling, and running the tests!
04
Conclusion
Whether using the “Invocation Method” or the “Generation Method,” both have certain difficulties and require a lot of comprehensive knowledge.However, this work must be done; otherwise, if not done, we can only wait for issues to arise after the vehicle is offline and then scramble to put out fires, which could lead to “wildfires that cannot be extinguished, spring winds blowing again,” and market sales could also be affected~Of course, if suppliers shield these fault monitoring functions, they won’t report faults when they shouldn’t, and they won’t report when they should (regardless of the situation), and if the master node tells them to sleep, they just sleep… After cheating like this, while the problems may not fall on me, from the company’s perspective and vehicle reliability standpoint, it is certainly inappropriate.Fortunately, there are some peers in the industry who have completely developed such fully automated, high-efficiency testing solutions. They directly reuse the full set of Vector tools, but without modifying CAPL programs; they only need to modify Excel spreadsheets. This simplifies complex tasks to an extreme level; as long as the CAPL program can implement the tests, it can handle them.This is worth promoting throughout the industry!We will briefly introduce such a solution next, and partners who need it can consult and communicate~ใRecommended ReadingใHIL43 Talks, Matlab also has a powerful real-time platform, at Shanghai Yisu and SpeedGoat
HIL48 Talks, Two Types of ADAS Testing, The Story of the Prince and the Commoner
HIL55 Talks, Basic Principles and Testing Technologies of Autonomous Driving
HIL56 Talks, How Germans Conduct Testing