谈谈汽车软件的复杂性.docVIP

谈谈汽车软件的复杂性 在汽车新四化的背景下，软件无可置疑的是汽车发展的核心部分。然而随着功能的不断增加，潜在的软件复杂性也在逐渐的增长，但是由于软件的不可见性，导致工程人员对软件复杂性的重要性不能充分理解。 然而随着时间推移，软件复杂性将以大量缺陷报告、维修成本激增的形式呈现出来。 软件大小 对于软件的复杂性，通常想到的就是软件的大小，但是并不是所有大型软件都很复杂。不过软件大小也是表示软件复杂性最直接的属性。 软件大小通常用代码行数来表示，这样就可以把软件复杂性形象化，利于大家的理解。例如一行代码相当于书中的一行文字，假设某个ECU软件的大小为300页，每页50行，而简·奥斯汀的《傲慢与偏见》刚好差不多这个数，这样人们就可以将该软件的大小类比于《傲慢与偏见》。 沃尔沃表示，至2020年，其旗下汽车的代码行数约为1亿行，这意味一辆车上的代码行数相当于6000本普通图书，够城镇图书馆的馆藏，这1亿行代码实现了电子燃油喷射、传动控制、发动机控制、巡航控制、动力系统控制、自适应悬架、多路网络、导航系统、稳定性控制、信息娱乐、避碰、高级驾驶员辅助系统、主动安全、互联以及许多更先进的功能。 统计表明，从2000年开始，汽车软件的大小每10年增长一个数量级。下一个10年，随着万物互联和自动驾驶功能的加入，到2030年，汽车上软件的大小将达到麻省理工大学科幻小说社会图书馆的馆藏数。 软件的系统复杂性 一个系统的复杂性是由系统元素数量和类型以及交互构成。复杂性是赋予系统功能和特性的基本要素，但是复杂性也是造成系统难以理解的原因。在代码中，运算符、局部变量、全局变量、条件语句、预处理、指针、函数调用等数百万个元素的相互连接创建了复杂的单元和大规模的抽象层。此外，代码与相应的软件版本、需求、测试、变更和电子组件的依赖关系在汽车软件中造就了惊人的复杂性。 然而。复杂性通常是由于非优化设计决策和未意识到的业务需求而在系统中积累起来的。这种复杂性并不能增加软件的功能;但是会消耗了大量的工作并产生软件缺陷。 那从软件层面来看，复杂有哪几方面呢？下面就一一道来。 源码的复杂性 沃尔沃的统计显示，到2020年，整个源代码中有1000万条条件语句。这些是决策块和循环块。在整个源代码中定义了大约300万个函数，这些函数在源代码中大约3000万个位置被调用。这些功能中的许多在车辆运行时执行任务。函数产生错误结果的概率取决于程序员的技能、代码的整洁性、测试的质量等等。即使概率非常小，例如0.0001，开发后缺陷仍然会数以百计。这不是因为开发人员不熟练，也不是因为测试不好，而是因为总的复杂性是惊人的。巨大的复杂性纯粹是有可能产生缺陷的。 函数调用和条件语句引入了基本的复杂性。这些元素对于编写一段代码来解决问题是必不可少的。更令人生畏的是偶然出现的复杂性，特别是祖传代码的复杂性。20-30年前编写的代码引入了深度嵌套的代码区域。对嵌套的统计，显示汽车上20%的功能中，最原始的功能区域嵌套次数很高。构建在其原始框架之上的新代码将成为冗长讨论的来源，旧代码应该被重构还是保持不变? 随着人们越来越意识到高复杂性的影响，软件工程师越来越重视开发简单代码。遵循编码准则已经成为比以往任何时候都更加严格的实践。一段代码不能合并到主代码分支，除非它符合复杂性管理准则;深度嵌套的代码、交叉信号、指针和全局变量的不正确使用、不一致的名称、冗长的行以及其他意外的复杂性触发都将被拒绝。尽管静态分析工具并不完美，但它们试图系统地帮助工程师完成这项任务。遗留代码经过彻底测试，并尽可能保持隔离和不变。 架构的复杂性 统计显示，在一辆现代沃尔沃汽车中，大约有7000个外部信号连接着120多个电子控制单元(ECU)。此外，连接软件组件的内部信号的数量要比外部信号的数量大两个数量级。软件架构设计中的一个重要任务是，架构组件应该以有序的方式很好地彼此隔离，创建具有合理层次结构和相对独立的系统隔间。这对于今后在现有功能的基础上开发新功能是至关重要的。另一个同样重要的任务是做出架构决策，支持维护诸如安全性、可靠性、高性能、可用性等属性。 相较于权衡上述共存的两项任务，问题在于存在不同层面的架构考虑，例如从功能角度对ECU功能进行分配以及之间的交互，从需求层面保证相互之间合理配合，从软件设计角度保证软件组件设计以及组件间的交互，考虑不同层面的合集，已合理的方式处理是一个挑战。 随着复杂性的挑战不断增加，已经有人提出了解决它的技术，例如AUTOSAR架构的推出，以及SOA。 至少软件抽象级别上，AUTOSAR是简化复杂性的又一步。通过统一汽车领域的专业知识，可以为软件体系结构开发标准的关注点分离，使基本软件、运行时环境和自适应服务分离。 相对于AUTOSAR，面向服务的体系结构(SOA)在降低复杂性方面相对成功。它