|
Expand Infinite Possibilities |
Platform Architecture
The logic and steps of the Alabi OTA platform are roughly as follows:
Establish Vehicle Database and ECU Database
For a vehicle to perform OTA, a backend database must first be established, where vehicle ECU version information, s19 files, etc., are bound to the ECU.
This part is preparatory work for testing, not the focus of the test, so we will briefly mention it.
Vehicle Registration and Network Activation
For example, purchasing data packages, IVI writing certificates, part numbers, VINs, etc., are also preparatory work for testing, which we will briefly mention.
Create Strategy
The so-called strategy refers to which vehicle series to upgrade, which ECUs, to what version, and under what signal conditions to upgrade (speed, engine speed, etc.).
Create Tasks
Creating tasks means specifying which vehicles to upgrade, whether to upgrade secretly or actively, and setting upgrade times, etc.
All of these steps involve cumbersome manual operations, are time-consuming, mentally taxing, and prone to errors.
Automation testing, as a good solution, has great practical value; it can completely separate the nearly 20 steps above, conduct abnormal condition tests for each step, and determine the reliability of the entire system under various scenarios.
Second Development Demonstration
Due to the involvement of server interface calls, vehicle technology primarily chooses Python, as Python is still a very powerful tool in the internet field; we must respect its status and not stick to conventions.
The above image shows the OTA interface function developed over two months based on Python, along with part of its complete calling process, perfectly achieving cloud automation.
By this point, automation should be around 70%, which is basically sufficient; the remaining 30% is not necessarily something that must be tackled, as it may not be beneficial for oneself or the team.
For specific logic and industry unspoken rules, please refer to the article below:
Full Automation and Semi-Automation in Testing: Overall Innovation vs. Fragmented Innovation
After all, our goal in scaling new heights and tackling tough problems is to make our work easier and more comfortable, improve work quality, increase efficiency, and leave work earlier, rather than to self-torture or to only gnaw on bones without eating meat.
Creating some small tools and making automation attempts to enhance one’s work efficiency is sufficient.
As for whether to make it zero-based foolproof operation, it depends on the company’s style and one’s own moral standards.
Python Has Its Shortcomings
During the actual development process mentioned above, we further felt the power of Python and gained a clearer understanding of why it is so popular!
If you only need to validate a piece of code or create a temporary small function, then Python is indeed quite excellent; you can copy a piece of code from the internet, modify the parameters, and run it.
However, if you need to create a large testing system that requires frequent upgrades and maintenance, often modifying code logic, especially when high-performance and real-time calls from third parties are needed, then Python is not a good choice for the following reasons:
Dislike for Coding
Shizi No. 1 really dislikes coding; I am a vehicle engineer, not a software engineer. My goal is to use software to solve problems, not to study software code.
Seeing software code gives me a headache; my patience runs out when I see lengthy code online. At this point, I tend to look at the official API documentation, which often turns out to be concise, which is quite strange.
Low Performance of Python
Python has never claimed to be fast; its advantages do not lie in speed.
Python lacks the concept of “multithreading”; handling multi-task concurrency is quite ineffective. For high real-time tasks, such as precise sending of CAN messages and physical signal simulation, it is simply helpless.
Python Doesn’t Want to Be a Sidekick
Using Python is quite difficult to call.
Shizi No. 1 once tried to compile it into a DLL to be called by other languages, but there were significant limitations, and third-party libraries could not be used.
It can only be a protagonist; it doesn’t want to be a supporting role. If it can’t be the protagonist, it throws a tantrum; what good is that?
LabVIEW + .NET DLL
In practical work, to make the modification and upgrade of the testing system more intuitive and convenient and to better support third-party peripherals such as Excel, serial ports, CAN, ADB, programmable power supplies, etc., we switched to the famous LabVIEW.
Its graphical interface and clear logical design, along with strong support for third-party software and hardware worldwide, make it a top IDE in the testing field, unmatched.
Even CANoe can be easily managed, perfectly invoking CAPL to handle complex tasks, making everything possible.
The Bus 22 Talk, a tutorial on calling CANoe with LabVIEW, is generously provided.
As for the cloud invocation part already implemented by Python, we used C# to generate a .NET DLL, which is then called in LabVIEW.
Thus, after another month, vehicle technology fully implemented the same functionality as Python using C# .NET DLL.
Below is a function list developed based on C#, as shown in the following image:
The C# DLL, when called in LabVIEW, has the most impressive feature of automatically listing the parameters, making it hard to make mistakes!
As for use case handling, report generation, condition simulation, etc., they can all be easily implemented in LabVIEW.
Moreover, after compiling the C# DLL, it packages all the libraries it uses along with the generated DLL into the release folder, making it very convenient to copy to other computers as a callable functional module.
This is significantly stronger than Python, which is too aloof and unwilling to play a supporting role and cannot achieve this.
For ADB simulation, we also used C# for encapsulation, and it remains smooth, reliable, and easy to use.
As for other parts, such as message processing and device invocation, we will not make alternative innovations and will directly use the scheme that vehicle technology has previously promoted, which is equally effective.
Feasibility Summary
This article aims to demonstrate the feasibility of the full-chain automation testing solution based on LabVIEW for OTA, enhancing the confidence of peers in the industry.
Do not be confused or hesitant; this path is entirely feasible.
Some countries can complete in 2 to 3 years what the US and the Soviet Union took 15 years to accomplish, because the US and the Soviet Union spent 12 years determining the uncertain aspects, proving that this path is feasible, allowing subsequent followers to skip the validation and exploration and get straight to work.
Compared to the mainstream CANoe + Python solutions currently on the market, it has the following advantages:
Lower Cost
No need to purchase Vector, saving quite a bit of money.
Moreover, the OTA functionality primarily concerns the CAN application layer, not involving link layer and physical layer testing, so there is no need to adopt the Vector system.
However, this matter needs to be analyzed on a case-by-case basis; sometimes spending less money might lead the company to undervalue this task.
Higher Integration
LabVIEW serves as the main IDE, while others are sub-modules, making the work content simple and pure, facilitating modular troubleshooting.
Some solutions on the market trigger CANoe through CMD commands, setting up to automatically run certain scripts in CANoe… In my view, this is just a loose temporary stage, feeling very shaky and difficult to manage later.
Easier Third-Party Extensions
LabVIEW is a global benchmark for cross-industry testing IDEs, with many software and hardware suppliers providing secondary development demos based on LabVIEW, offering unparalleled support for third-party software and hardware.
Complex Condition Simulation
LabVIEW’s graphical interface makes modifications easy and comfortable, giving it a significant inherent advantage in simulating complex conditions and achieving results quickly.
Compared to Hengrun’s OTA testing solution based on TAE, the advantages are also considerable.
Let’s comment on Hengrun’s OTA automation testing solution and set up a group.
Peer Communication
The Alabi solution holds a high market share; we welcome peers to communicate in the background, to learn and improve together, and strive to make this part of simulation testing even better.
If you need the same C# encapsulated DLL, feel free to reach out to communicate; we can explore better secondary development methods together.
Bus Talk 10, the best Excel to DBC tool in the Eastern Hemisphere, always free to give away
