汽车软件设计时容易忽略的点 -- 观ETAS Webinar有感

目录

1.忽略汽车软件网络安全

2.软件功能安全难以保证

3.文档和注释匮乏

4.无效\不充分测试

5.忽略实时性控制

抽时间回顾了ETAS Webinar，特别讲到了在汽车MCU的软件开发中常见问题，结合之前经验，深有感触。总结总结，与君共勉。

1.忽略汽车软件网络安全

在以往汽车ECU软件开发中，网络\信息安全一直被忽视，大多控制器在系统架构设计时就忽略了威胁与风险分析。

在汽车信息安全--攻破SecOC，就在今天！中提到：黑客利用升级时下载Flash Driver缺乏有效验证机制这一漏洞，植入shellcode，从而提取到SecOC密钥。

这就是很典型的例子，个人猜想Bootloader和App是两个不同小组开发，这两个组件之间是否存在漏洞就处于三不管地带。

因此，在Vehicle CyberSecurity普遍成为强制标准的今天，将网络安全开发流程贯穿到汽车开发、生产、售后、运维、报废等整个生命周期，对于新产品的开发是十分必要的。

据统计，

• 中国于2024年8月23日发布GB44495—2024《汽车整车信息安全技术要求》：要求从2026年1月起，对于新申请型式批准的车型强制执行GB44495—2024；2028年1月起，对于已获得型式批准的车型强制执行GB44495—2024。
• 欧盟规定2022年7月起，所有新车型强制要求满足R.155法规；2024年7月起，所有新车辆强制要求满足R.155法规。日本与欧盟同步。

当然目前来看，如何实施网络安全流程还不是很明朗，从OEM角度如何将这些流程分解出来给到供应商，我们拭目以待。

2.软件功能安全难以保证

很难说我们是按照ISO26262-6类似的标准进行代码\模型开发，通常情况开发者都是先以实现功能为首要目标，功能实现之后再考虑如何添加措施从而加固系统。

之前遇到过一个系统需求，要求在当前ECU做子网关，下挂多个节点，路由延迟不超过1ms。

在开发时就直接利用协议栈提供的callout在IF层处理了，没有考虑功能安全，系统工程师没有提任何DFEMA的要求，也没有提功能安全等级要求。

在设计时，将接口限制到什么数量、该模块设计的大小和复杂度、接口的调度层次、各接口的调度特性，都凭经验实施，因此也很难说满足了什么样的ASIL等级。

当然，待的是小公司，大一点的公司应该会有一套自上而下的需求分解理论。

3.文档和注释匮乏

工程师最怕的工作，没有之一，那就是文档和代码注释。

同第二点一样，除了部分复杂模块，大部分开发都是先写代码，后补设计文档，文档也是流于形式；代码缺乏注释，过个把月回头看自己代码，完全不知道当时为什么这么写，大家应该都有这种体验。

我遇到过交接的代码完全没有注释，光理解和调试就耗费大量精力，还不敢大改，毕竟有个传说：代码能跑就不要动它。

那么如何写文档和注释，浅薄见解：保证追溯性、设计文档先行、注释写清楚设计目的或者来源、找组内大佬review。

4.无效\不充分测试

软件测试不充分，在小开发团队表现得尤为明显。

绝大多数情况，开发人员既要开发还要自测，如果配备的测试人员对功能点或者需求理解不一致，就会难以保证最终的测试用例完备性。

因此，从单元测试、集成测试、漏洞扫描再到功能测试，无不考验着一个软件开发测试团队的综合实力。

之前遇到过可以算得上是一个事故，自家开发、测试和架构共同review过的测试用例，也修复了所有bug，但在实际用户使用时代码跑飞了。

我们私下在想：你怎么可以这么用？但客户确实这么用了。

因此，测试通常意义要和开发并行，甚至应该测试左移，以此驱动开发。

5.忽略实时性控制

车规MCU的大多数应用都有实时性限制，开发时很难考虑掉这点，大家普遍认为，自己这点代码，CPU几下就给处理完毕了，结果常常造成系统级别的灾难。

之前遇到过总线负载过高导致整体任务周期不准的问题，从应用层架构设计分析再到RTE集成代码分析，最后再到MCU硬件cache、分支预测等分析，几乎撸了一遍才解决。

这就是开发时没有考虑worst-case performance，也是做架构设计时没有考虑任务拆分，更没有考虑本身MCU硬件存储器自身访问效率导致。

例如，考虑堆栈和共享变量部署位置时，需要掌握CPU到存储器（例如TC3xx DSPR\PSPR、R52 A\B\CTCM、M7 I\DTCM、System SRAM、Flash）的访问延迟；在考虑任务分配时，在不同调度层级拆分任务，然后通过测试评估是否有效。

忽略实时性控制，是早期开发最常见到的问题。性能问题也基本都是在HIL阶段才会发现。

不多说，回顾《嵌入式软件的时间分析》。