Embrace requirement driven development, the best one-stop approach of ISO26262 in practice level
Although the current domestic automotive electronic software development process is more based on the ASPICE-based V process, the actual landing is more focused on software design, implementation and testing (such as the red box PART B), At the user level, the final implementation of the system (such as the blue box PART A) is based on the patchwork method of coping with thoughts. Originally, Part B should come from the decomposition of Part A, but the actual operation of Part B is isolated separately, resulting in the loss of functional requirements, the continuous bugs, and the difficulty of evaluating potential security risks when Part B is integrated into Part A.
Investigating the root causes of these problems, we can clearly trace back to the lack of output of Part B to Part B, or the output of the product is difficult to use by Part B. We further decompose Part A, and we will see that Part A's activities mainly include two major parts, each level of requirements engineering (such as customer level, system level, software abstraction layer, etc.) and corresponding test engineering, tested here. The project is derived from demand engineering, which is the starting point for all activities.
This presentation will focus on how to improve the efficiency of development engineering and test engineering based on the requirements of functional safety, and to achieve high quality and high security products.