Last week, a colleague mentioned that she was misled by a rather dominant supplier.
She vented her frustrations to me, and I quickly offered her a lollipop for comfort.
After listening to the details of the situation, it turned out to be quite typical and worth sharing, hoping it can provide some insights for everyone.
01
The situation is as follows
In this project, she was responsible for the HCU functionality, while a domestic supplier starting with the character “Bo” was in charge of developing the EMS software.
Of course, the EMS needs to interact with the HCU, as anyone knowledgeable would know.
Later, Bo sent over a communication protocol, which the colleagues on the EMS side were thrilled about, but Bo did not provide much explanation or answers to questions.
Eventually, the HCU needed to use the engine speed signal, so they looked for it in the communication protocol.
They found a signal named EngineRotSpeed, and the range, coefficient, and unit all seemed appropriate, so they assumed it represented the “engine speed” and incorporated it into the HCU control strategy.
However, during real vehicle testing, the HCU software developers found that this functionality was not working correctly, which was quite puzzling.
The HCU software developers then asked this young lady, who in turn consulted Bo about the issue.
Upon learning that the HCU was using this signal for engine slip start, Bo reacted somewhat strongly, stating that this functionality should not be implemented this way, and that this signal could not be used for such a function, which would require additional work from EMS and incur additional development costs… and so on.
The young lady asked, “Isn’t your signal named EngineRotSpeed?”
Bo replied:
“You cannot take it literally; you cannot assume what this signal represents just by a few abbreviations, and you certainly cannot generically assume that this signal can be used indiscriminately for various functions. Different functions have different requirements for signal quality and definitions. The functionality you described requires additional work from EMS, which will cost 200,000 in development fees.”
The young lady was quite frustrated and said, “Then what is the use of this protocol you provided?” Bo replied, “For reference only.”
The young lady was in tears…
01
Deep Reflection
I thought about it again, and this situation is not just about the supplier being dominant.
It may be a typical example of some automotive companies being charged an intelligence tax due to inadequate and careless work, and it is also a microcosm of the Chinese automotive industry.
Bo might think that if you are so bold and carefree, not paying attention to details, it would seem disrespectful not to ask for more money.
In business, technical issues need to be taken seriously. If you don’t take it seriously, do you expect others to be considerate and voluntarily give you money?
Therefore, regarding the signals in the communication protocol, especially key signals, we need to do our work meticulously, clearly define the signal specifications with the supplier, and it is best for the automotive company to issue the protocol to the supplier.
If the supplier refuses to use the communication protocol issued by the automotive company and insists on using its own, then a dedicated discussion must be held to clearly write down the detailed definitions of the key signals.
We cannot just write casually with an abbreviation, nor can we let the supplier throw a communication protocol at us without paying attention; this is a big pitfall.
In fact
In most cases, this kind of protocol has clear remarks and definitions within the supplier, including its applicable environment, accuracy, real-time indicators, etc., but when sent to customers, these are likely to be deleted.
Facing Challenges
Having the automotive company lead the protocol creation does involve a certain workload. First, three types of errors must not occur.
-
Basic errors, such as ID conflicts, signal overlaps, naming duplicates, dbc writing errors, etc.
- Intermediate errors, such as unreasonable signal parameter definitions, loose signal arrangements, unreasonable ID priority planning, etc.
- Advanced errors, such as unclear signal meanings, uncontrolled routing management, uncontrolled load rates, etc.
For this kind of communication-heavy and labor-intensive work, face-to-face communication is clearly very inefficient and often leads to disputes.In some companies’ development processes, bus engineers might just give up and ignore it, passing the buck when problems arise.In such cases, using certain tools to assist in design and thoroughly solve these issues is a very wise choice.Tools like PREEvision, SystemWeaver, and Hengrun’s VDE, as well as Hangzhou Zhonghui’s CANDE, are among them.Among these, Hangzhou Zhonghui’s CANDE offers the best cost-performance ratio, is the most practical, and aligns perfectly with the principle of “spending less and achieving more.”Saving money is making money; being able to accomplish tasks with less expenditure is a skill.Moreover, it is said that Hangzhou Zhonghui can provide source code delivery, which is very suitable for companies to master core technologies, conduct secondary development, and build their own information management systems.If needed, you can contact them, or communicate with the editor in the background for recommendations.
Bus Talk 38: Comparison of CAN_DE and a certain Beijing Run VDE functionality
03
Conclusion
It is time to take some measures to improve the quality of vehicle design; otherwise, we will be eliminated by the brutal market competition.
【Recommended Reading】
Manufacturer Talk 2: Shanghai Tongxing Intelligent, the new generation leader of self-owned brand CAN cards
Manufacturer Talk 3: The past and present of Hongke Automotive Electronics Division
HIL Talk 43: Matlab also has a powerful real-time platform, in Shanghai Yisu and SpeedGoat
HIL Talk 48: Two types of ADAS testing, the story of the prince and the commoner
HIL Talk 31: A beginner’s tutorial on the principles and applications of automated testing methods
Bus Talk 38: Comparison of CAN_DE and a certain Beijing Run VDE functionality