|
I don't know where you get your information, but you've completely missed what automotive software development looks like. The amount of verification and validation, and the number of standards (most of them are self-imposed, not a legal or homologation requirement) is absurdly high. Here's a scenario. You're nominated to be an ECU supplier or a software sub-supplier for a VW brand, first thing they hit you with is requirements which span 1000 pages for a simple system (door, seat, HVAC), or 10x more for a more complex one (infotainment, engine ECU, "main" vehicle ECU etc.). 1 of those requirements is "SW shall comply with VW 8xxxxx norm" which is one of many VW norms that they deliver to you. The other requirement is "SW shall comply with KGAS", KGAS stands for "Konzerngrundanforderungen Software" which translates to "Group Basic Software Requirements", (group is VW), and both, you guessed it, are thousands upon thousands of requirements. Then there's Functional Safety, or FUSA, which is a reference to ISO26262 (based on IEC 61508). Then there's also ASPICE (ISO/IEC 15504). New thing is UNECE R155 (cybersecurity). These three prescribe a very detailed development process commonly known as the "V model" for system and software development, which means you need to elicit requirements, define system requirements, system architecture, software requirements, software architecture and software detailed design. After that, you get to coding. For each of those there's a validation method: unit tests, software integration, software qualification, system integration and system qualification. ASPICE 4.0 has expanded to cover Embedded Hardware and Mechanical design as well. Other than the engineering processes they also cover other areas such as project management, configuration management, supplier monitoring, problem & change management etc. Then come the external and internal audits, pardon, assessments. Your internal Quality department needs to monitor all engineering activities and report them to the customer, customer's Quality dept. will do their own audits, you and them will also hire an independent company to audit/assess you so that there's no bias. BUT guess what - almost none of this is required for non mission critical software, so your infotainment is actually the only thing developed in a way you've described it. Brakes, ABS, ESP, Engine ECU or the EV powertrain (BMS, inverter etc.) are all written according to what I described above. There's no need for more bureaucracy, the automotive industry (especially German one) is very good at self-regulating and would make an average web developer throw up on his first day. Failures of the UX/UI in modern vehicles is just a business problem - guys who spent decades building and selling options like leather seats, and checking spreadsheets at the end of a fiscal period are still at the helm or their business processes still live on in those companies. |