V-Model (where V stands for verification and validation) splits the development process into two parts – the left arm of the V consists of requirement analysis, function design, and software development while the right arm concentrates on the verification and validation activities followed by the release.
The role of electronic systems in the automotive industry is continuously expanding. As the number of electronic functions increases, so do the number of ECUs in the vehicle. This increase in ECUs and electronic functions results in the associated software becoming more complex and expansive.
According to Markets and Markets, the global automotive software market is projected to grow to USD 37 billion by 2025, from USD 16.9 billion in 2020, at a CAGR of 16.9%. Statistics show that software plays a vital role in various vehicle functions, and this role is expected to proliferate in the future.
As a mission-critical industry, the automotive development process must adhere to regulatory standards such as ISO 26262 and ASPICE to minimize the risk of failure. Following standard development procedures can have a positive outcome on the success of automotive functions and software. V-Model is one of the widely used software development processes in the automotive industry.
To put it simply, V-Model (where V stands for verification and validation) splits the development process into two parts – the left arm of the V consists of requirement analysis, function design, and software development while the right arm concentrates on the verification and validation activities followed by the release. The V-model is an extension of the waterfall methodology. V-Model emphasizes testing, particularly the need for early test planning. Each phase of the V-model aligns with the ASPICE standard and helps in clearly defining a life cycle.
Requirements Engineering: This is the first step in the V-model process and entails establishing and documenting requirements. It includes clearly defining and noting the task/s that the automotive function/feature will perform and how. The success of the design and development phase depends significantly on this phase being well executed.
However, many a time, the requirement document may not contain details about the implementation. Since the development process follows this phase, it is best to involve the development team while preparing the requirements document to ensure clarity.
System Design and Development: The next step is the actual design and development of the function/feature for which the requirement was gathered in the first phase. In the development phase, the functionalities are designed and tested using the model-based development environment. The function/functionality needs to be tested as it is being developed, ensuring that bugs and errors are fixed early on.
In the model-based development environment, simulation tools such as MATLAB/Simulink can simulate real-world scenarios. The potential bugs and errors are highlighted and rectified during this phase. These tests are called Model in the Loop (MIL) since the testing is done in a controlled environment using models. Once the development process and testing are complete and the results are satisfactory, the model – a block diagram – is then sent to the software development team.
Developing Software: The software piece is created according to the model. There may be different versions of the software depending upon the use case. Model-based design tools can generate automatic code; most of the hand (written) codes are written in C language, and most ECUs are also developed using C. The software development input can either be in the form of the model or a requirement document, both of which give a detailed description of the function/feature.
The document for software development contains details regarding the software architecture, its modularity, the number of functions in the module, its periodicity, and a flowchart of the entire software, among others. Once the software development process and testing are complete, we progress to the next phase.
Software Integration and Function/Feature Integration: Since there are different ECUs, most may have their own control software. The engineer combines all the software modules during the software integration phase and checks the interaction between them. The impact on the legacy code and other software modules is also monitored. Again, the testing in this phase is done with the help of simulations using Hardware in a Loop (HiL) environments.
The engineer then needs to assess whether the newly integrated function affects any other modules’ functioning. However, the testing here is done in a physical environment (in-vehicle test). The most important aspect of testing, in this case, is ensuring that the implementation is done correctly, with no flaws or unwanted consequences.
Therefore, a test scenario must be defined and prepared to test the function in the vehicle. Next, the ECU is connected to a computer loaded with the prescribed tools via different communication protocols. This validation process helps in confirming that the product can perform as required. The integration phase is followed by function calibration; this involves fine-tuning the software parameters to enable top field performance.
The V-model is simple and easy to use, but it is also rigid and does not allow for any shortcuts in case of an emergency. It helps in clearly defining a cycle and efficient implementation if the requirements are clearly established in the requirement gathering phase. A strong team with adequate knowledge and experience aids success.
eInfochips is an ISO 26262 and ASPICE certified systems and software partner for various automotive companies across the world. We have experience in successfully developing automotive systems and subsystems for our clients. To know more about our expertise, please get in touch with us.
