何为“软件定义汽车”？每个人可能都有自己的独特见解，毋庸置疑的是软件在汽车电子中开始占据主导性地位。
20世纪80年代初，一辆轿车的电子系统只有几万行代码，今天一辆高端豪华汽车电子系统有数千万行代码，而未来一辆智能网联汽车电子系统可能会有上亿行代码，这一现象说明了软件发展与汽车创新的必然关联趋势。
汽车功能由最初的机械方式实现，到后来的电子化方式实现，未来可能更多的功能可以在不改变硬件的条件下由软件来实现。根据福布斯报道，估算以后自动驾驶汽车60%的价值将源于软件，而今天汽车软件的价值占比只有10%。
“软件定义汽车”将把汽车变得像手机一样，只要是一个智能机，我们就能在此基础上方便添加不同的应用，实现不同的功能，并且能够在线更新升级软件。然而汽车与手机在用途上又有着本质的不同，手机质量只影响通讯和娱乐，而汽车质量关系到人们的生命财产安全，所以“软件定义汽车”背景下的汽车软件质量如何保障，如何适应新功能、新平台的快速软件开发，是当下汽车软件开发需要深度思考的问题。
关于快速变化的软件架构思考
随着智能网联汽车的发展和汽车电子电气架构的演变，整车电子电气架构逐渐从分布式架构转变为集中式的控制架构，多个传统ECU功能集中在一个域控制器，甚至还有跨域整合的概念，这种情况下，对于一个域控制器中的软件要求越来越高，软件的规模也越来越复杂，所以一个具有强大兼容性、达到解耦、可扩展的软件架构至关重要。
“解耦”分为两个层次，一个是软硬件之间的解耦，一个是软件架构内部模块之间的解耦。
软硬件解耦即软件架构设计时考虑跨硬件的目标因素，把硬件作为一个黑盒子，构建一个通用的软件框架，对接口设备做抽象化处理，并兼容不同的接口。另外，软件架构应是一个分层化模块化的设计，应该做到模块之间的解耦，对接口进行标准化处理。软件框架上可以加载不同的算法和软件模块。
为了应对当下汽车软件需求的快速变化，软件架构设计应是一个“种树”的行为，而不能是“种草”。也就是说，要把整体软件构建成一棵大树，可以不断扩展或删减枝叶，但不会对主干造成影响，而不能设计一个软件系统就种一棵草。
为了实现可扩展目标，软件架构设计时要有全局观，确保软件架构的兼容性设计。软件架构设计时需要充分分析数据流和控制流，软件资源占用情况。软件架构就像人体的血管和神经网络，连接各部分肢体，传输信息和营养，只有保证这些数据流和控制流的正确实施，才能实现一个健康的架构。
总之，软件架构设计时要秉承一个目标：软件是复杂的，架构是简单的，用简单明了的架构去承载不断扩充的软件模块以满足快速变化的需求。
关于软件质量挑战与保障的思考
随着智能网联汽车的发展，汽车软件开发面临着巨大挑战。新功能新需求的出现，没有过多的经验可以遵循，造成软件需求不断迭代；软件架构需要支撑不断变化的需求；软件复杂庞大的代码量可能引入更多的缺陷；复杂场景组合与庞大代码量使得测试验证的充分性难以保证......
面对这些挑战，汽车软件质量到底应如何保证。软件的特殊性在于它的质量无法量化，质量缺陷不光是通过技术引入，也可能通过开发过程的不规范性引入，而这些通过过程引入的风险看不见摸不着不可预测，所以保障汽车软件质量总结起来可以分为三个方面：流程保障、方法保障和工具保障。
首先，流程上需要建立完善的软件质量管理体系，例如基于ASPICE的软件开发过程、质量管理过程、配置管理过程、变更管理过程等，这些都直接关系到软件的质量，软件开发过程需要遵循这些质量管理要求。完善的流程也能够保障需求的稳定性，例如在建立需求时需要经过充分的调研和确认，需求要经过多方评审，可以从一定程度减少需求的不合理变动；另一方面，流程上做好需求的基线管理和变更管理，识别需求变化的影响范围，并针对影响范围制定相关的应对措施。
在方法上，主要是指技术方法和方法论。例如：在制定需求的时候，可以通过HAZOP分析补充安全需求，识别需求是否全面，通过需求的双向追溯确保软件开发与需求的一致性；在软件架构设计阶段可以通过层次化、模块化设计和高内聚低耦合的方法降低软件质量风险，通过数据流分析、控制流分析来验证架构的完善性；在软件编码阶段遵循编码规范的方法要求；在测试时确保测试覆盖率，并采取性能测试、雪崩测试、故障插入测试来充分验证软件功能与性能。方法有很多，无法一一列举，需要在软件开发过程中充分挖掘。
另外，工具也是软件质量保障很重要的一个方面。完善的工具链可以让软件开发工作事半功倍。比如自动化测试工具，代码与详设文档的转化工具，有了这些工具之后，可以对需求变化带来工作量进行快速响应。从功能安全角度考虑，软件工具本身可能会引入系统性失效问题，所以安全可靠的工具是确保软件质量的基础。
关于敏捷开发的思考
虽然当下敏捷开发变成了热门话题，敏捷或许是个好的方法，可以让软件提前得到验证，但敏捷不是万能的。
首先，对于当下软件开发需求变化快、进度紧张等问题，不是单纯靠敏捷开发就能解决，敏捷方法的使用需要匹配合适的项目，例如可以穿插应用于一些小的软件模块的开发过程中，并要配合一定的自动化测试方法，否则会让测试验证的工作量剧增。
笔者个人不建议敏捷作为一个复杂软件系统开发的主线方式，对于越是复杂的软件，越是要做好全局规划，但是在具体详细设计与实现层面可以适当运用敏捷方法。
汽车行业与某些互联网开发思路是不同的，前期还是会有相对比较明确的需求，包括功能和接口，并不是可以完全随意增减，而互联网产品开发过程可能突发灵感，会加入很多创意的内容，从而增加新的需求，这种需求迭代就像滚雪球，各方面不断加入新元素，不断扩充完善，所以应用敏捷开发可能更适合某些互联网产品。而汽车领域，即使是现在的智能网联汽车领域，需求框架相对也是明确稳定的，这个过程更像是建房子，是应该先建好整体地基，再逐层建高楼，才能保证质量。而不能每一层快速盖一点，靠盖好后的楼来验证地基。所以对于是否采用敏捷开发，需要先识别这是一个滚雪球的项目还是建房子的项目。
虽然智能网联汽车有一些汽车与ICT的融合元素，但是综合来看还是更偏向于“建房子”的比重。敏捷适用于“未知的未知”探索性项目，而智能汽车软件开放属于“已知的未知”探索性项目，还是有些差别。
并且从软件质量和功能安全角度考虑，敏捷开发过程中通过充分沟通精简过程与文档这种方式可能会引入不可评估的系统性失效，所以针对汽车行业新功能、新平台的复杂软件开发至少在架构阶段以前个人建议还是采用瀑布式开发，在详细设计以及基线后的需求迭代过程中可以适当考虑敏捷开发。
关于软件测试的思考
面对日益膨胀、复杂化的汽车软件系统，传统的测试人海战术也许在某些时候有一定作用，但不够高效。软件测试需要“融合”，即对于复杂化的软件系统，要注重人工测试与自动化测试相融合。用自动化来进行持续集成与交付，可以起到事半功倍的效果，但是自动化测试也需要一定的测试人员来编写脚本和人工验证，目前自动化测试并不能完全代替人，例如现在有一些单元测试的自动化测试工具，覆盖率可以达到百分之百，但是从软件质量角度来考虑，单纯用这个工具测试并不足够，因为软件的逻辑是否正确还是需要人去验证。但是对于代码量巨大的复杂软件系统，单纯靠人海战术也是不可行的，浪费人力资源且效率低下，因此以自动化测试为主，以人工为辅的“融合”化测试可能才是比较正确高效的途径。