Flashing software onto hardware and directly delivering the hardware. This has been a common black-box delivery model in the automotive electronics software industry. At the same time, the main line of the ECU development process is basically centered around sample delivery.
Of course, nowadays, with the increasing decoupling of software and hardware, the popularity of OTA, and the emergence of entertainment software, the delivery model is increasingly focused on software delivery, and the implication of suppliers selling parts is becoming weaker, which will not be discussed in this article.
Here, we will discuss the classification of sample maturity with software, but will also involve descriptions of mechanical and hardware-software states, namely the ABCD samples.
This may help everyone gain a better understanding of the project process.
1
Sample A
Sample A is generally an early-stage immature product.
The sample production methods are not standardized, such as handmade parts, 3D printing, other sample replacements, modifications of existing samples, etc.
It is generally only used for very basic functional testing, such as appearance confirmation, structural matching, packaging development, HIL (Hardware in Loop) testing, bench testing, or other basic principle confirmations, and definitely cannot be used for durability environmental testing.
The software may not be developed or may only have very simple basic functionality or interface testing.
2
Sample B
Sample B is a further maturity compared to Sample A; this concept can be understood as a transitional phase, somewhat vague, making it difficult to draw a clear line with Sample A.
Generally speaking, the key parts of the production method (compared to mass production processes), functional status, and testing completion have basically met the requirements.
However, there are still some non-critical parts remaining, such as non-matching dimensions, non-formal production line outputs, etc.
Typically, it can also be tested in vehicles, and running limited road tests is not a problem. Additionally, the commonly mentioned DV (Design Verification) uses parts from this stage.
The software may still have some non-critical modules that are not fully developed or may still contain some bugs, and calibration may still be in the adjustment phase.
But at least it meets the conditions for testing, with most functions operational, for example, the ECU’s communication diagnostic function must be present, meaning the remaining work is mainly engineering refinement.
It can be said that during the development phase, most modules are in a Sample B state.
3
Sample C
Sample C represents a sample state where the design is complete and verified, all functional requirements are met, and the hardware or mechanical parts are from formal molds or production lines.
However, it cannot be used for sales at this time, as it can only prove that a qualified product can be produced in a non-mass production way (or in small quantities).
In fact, the qualified product here has an implicit prerequisite, which is that it needs to pass PV (Production Validation).
For the software development team, all requirements have been executed, and all sub-functions have been verified; even if there are known bugs (software without bugs does not exist), they are not serious, and relevant parties can reach a deviation allowance.
From the perspective of supplier development, the development work is complete, and the technical aspects can be released, but there is still the last step—customer confirmation (validation), such as vehicle or production line confirmation; if problems are found, an iteration may still be needed.
In simple terms, Sample C is technically okay (including product and production).
4
Sample D
Even though Sample C is okay, the automotive industry emphasizes procedural “justice” and mass production stability, which leads to the final sample concept—Sample D.
Sample D refers to samples that have undergone small-batch trial production (mass production processes) and have received necessary approvals (such as PPAP).
At this point, the sample not only has the design approved, but the process, organization, and workflow have also been recognized. Thus, it proves that the organization has the potential to supply batch qualified products.
At this time, the software has naturally completed all confirmations.
Sample D will then enter the mass production supply phase.
5
Conclusion
Overall, the classification of R&D samples is defined according to their design and verification maturity.
Different companies will have different definitions and habits based on their development processes and product characteristics, and different people within the same company may also have different detailed understandings, so we provide a commonly used differentiation method above.
In summary, as shown in the table below.
6
Final Thoughts
Following a step-by-step maturity process is a theoretical concept; in actual work, even for mechanical products, it is generally difficult to follow this rhythm step by step.
For the increasing number of software products, this is even more true, with frequent version iterations, bugs arising one after another, and it is possible that even at the Sample D stage, there are still many bugs to be resolved, requiring further replacements, flashing, and SOP becoming meaningless.
The so-called agility has become a forced choice and reality, compelling us to continuously reform the automotive development process.