德国嵌入式时序专家Gliwa给出的建议见：汽车电子领域中多核MCU应用指南

汽车软件开发是多种工程学科的相互综合与应用，例如机械工程、电子工程和软件技术等，涉及众多领域。

推荐入门经典书籍：《Automotive Software Engineering》，也有译文版《汽车软件工程:原理·过程·方法·工具》，该书由德国Bosch（ETAS）专家Joerg Schaeuffele, Thomas Zurawka编写，系统地阐述汽车电子系统和软件开发的过程、方法和工具。

下图是一个传统的汽车电子开发的参考知识框架：

而面对汹涌的软件定义汽车浪潮，由于与IT领域的融合，涉及的技术栈就更多了。国外还有极客以地铁图的形式，画了一幅软件定义汽车的技术图谱，可参考 SDV涉及哪些技术栈？一张地铁图告诉你

以下信息供参考，建议经常关注官网，获取最新状态。

Overview

https://projects.eclipse.org/projects/automotive，Last Update @ 22/07/01

按照AUTOSAR标准中的说法，“development error detection”的初衷是“Extended error detection for debugging and especially integration” 量产后确实可以关闭。不过实际软件中，各家AUTOSAR供应商提供的相关检查对于系统的可靠性还是很有必要的，因此不建议删除。举个例子：如下DIO模块中在读对应Port通道前针对形参ChannelId检查就很有必要，否则如果传入一个超范围值而被函数Dio_Ipw_ReadChannel使用，则可能导致数组溢出等情况，出现难以预计的后果。

Dio_LevelType Dio_ReadChannel (Dio_ChannelType ChannelId )
{
....
#if (STD_ON == DIO_DEV_ERROR_DETECT)
    Std_ReturnType Valid = Dio_ValidateChannel(ChannelId, DIO_READCHANNEL_ID);
    if ((Std_ReturnType)E_OK == Valid)
    {
#endif
        ChannelLevel = Dio_Int_ReadChannel(ChannelId);
#if (STD_ON == DIO_DEV_ERROR_DETECT)
    }
#endif

除了关闭与打开两个选择，某大厂则采用了第三种方案，继续以上述代码为例：

    ......
    Std_ReturnType Valid = Dio_ValidateChannel(ChannelId, DIO_READCHANNEL_ID);
    if ((Std_ReturnType)E_OK != Valid)
    {
    #if (STD_ON == DIO_DEV_ERROR_DETECT)
        Det_ReportError(xxxx);       
    #endif
    }
    else
    {
        ChannelLevel = Dio_Int_ReadChannel(ChannelId);
    }
    ......

也就是将Error的“Dectection”和“Report”两个动作分开，Detection动作不论量产前后都做，而Report动作则在量产后关闭。当然，这种做法对于减少代码空间作用不大。

以上思路供参考。

使用ARM M核的MCU其Boot功能要比Uboot少很多，而且各家Tier1对Boot功能的需求差异非常大，这应该也是AUTOSAR CP中没有对Boot进行标准化的原因。个人预计未来可能性也不大，以下文章供参考：

汽车基础软件的起源与演进

标准《Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units》中的Level3 控制器监控层没有就ROM/RAM等内存空间的检测开设专门的章节，如下图所示。

有关内存空间的检测要求分散在上图中各部分章节，具体实现方法没有指定。实际开发中，常见的测试方法有：

• 双存储测试法： 针对关键的变量均额外定义对应的补码变量，由于这些变量都存储有各自的补码，因此，检查方法就是对其自身和其补码进行一致性检查。
• IFA9 测试法：这种方法通常针对一段RAM空间，测试其是否可以正常读写。具体实现方法为：1 按照地址递增的顺序向待检测的RAM区域写入测试码； 2 验证写入的测试码，并将测试码的反码写入到RAM中； 3 验证上一步中写入的测试码的反码，并再次将测试码写入到RAM中； 4 验证上一步中写入的测试码，并将测试码的反码按照地址递减的顺序写入到RAM； 5 验证上一步中写入的测试码的反码，并再次将测试码按照地址递减的顺序写入到RAM中，并验证。其中用到的测试码有两种：0xAAAA AAAA/0x5555 5555 和 0x0000 0000/0xFFFF FFFF；
• 单点RAM测试法：这种方法主要针对具体某处RAM地址，测试其是否可以正常读写。具体实现方法为：1保存要检查RAM处的数值；2 写入0x55555555，读出测试是否为0x55555555；3 写入0xAAAAAAAA，读出测试是否为0xAAAAAAAA；4 恢复RAM区的原始数值。
• ROM测试法：这种方法主要针对存储在Flash空间内的程序代码和标定数据，采用某种算法计算指定区域的Checksum，然后与本就保存在Flash中的Checksum进行对比，确认数据是否有损坏。需要注意的是，保存在Flash中的Checksum是在软件编译过程中由专用工具计算出来并保存在最终生成的Hex文件中，随之刷入Flash内的。

实际开发过程中，应当根据不同的检查区域的特点，采用不同的检查算法，主要考虑的因素有：

1. 提前确定检测区域，这需要在内存空间分配时就进行相应设计；
2. 对于采用Checksum校验的测试方法，还需提前离线计算出对应的Checksum；
3. 根据功能安全技术需求，选择恰当的测试执行时机，如启动阶段、关机阶段或运行过程中周期性；
4. 注意测试耗时对系统的影响，必要时分批测试，避免ECU启动时间过长或CPU负荷偏高；
5. 根据功能安全技术需求，定义恰当的失效响应机制，如轻的可以仅记录故障，严重的则需触发系统复位；

-

控制器越复杂，参与软件开发的人员或组织越多，软件集成的难度越高。ECU资源不足就是软件集成时常见的一种典型状况。这类问题原因很明确，但解决起来却非常不易。由于软件集成操作属于整个开发过程的后期，通常会面临时间紧、难协调、成本高等困难。

为了提高软件集成的“可控性”，引入ECU资源管理活动是非常有必要的。以RAM和Flash两种常见的存储资源为例，软件中占用这些存储资源的的元素主要有五种：

• 代码
• 常量
• 全局变量
• 临时变量（堆栈）
• 标定数据

在每个软件模块的开发伊始就应当围绕这些元素进行资源预算，向架构师提出申请，得到批准后再进行开发，再完成编码后，应进行资源使用情况的实际测试，提供存储资源的实际消耗数据。软件集成工程师在集成过程中，对全部软件的资源消耗情况进行统计和监控，从而形成资源管理的闭环。

PS：资源统计和分析通常可基于编译后生成的Map或Elf文件，开发专用的内部工具自动完成。下图展示了一个由工具自动生成的资源报告实例：

简单来说，只有开发ASIL-C和ASIL-D等级的控制器，ISO26262才强烈建议对于TCL3的软件开发工具进行认证。而属于TCL3这一分类的软件开发工具其实是很少的，通常只有两类：

1. 编译器
2. 代码自动生成工具

因此，对于开发高安全等级的控制器，编译器应该选择已通过ISO26262认证的产品，如果还用到了Target Link，dSPACE等基于模型开发的代码自动生成工具，则也应选择已通过ISO26262认证的产品。

PS：之所以编译器和代码自动生成工具这两类工具被归入到TCL3，主要原因在于它们会直接影响控制器所运行的可执行代码，而其它的软件开发工具通常不会直接介入代码的生成过程，如FMEA分析工具Medini analyze、代码静态检查工具QAC、单元测试工具Tessy等，所以不需要考虑认证的问题。

我所了解到的主要有以下几家，欢迎大家共同补充完善：

• 东软睿驰（已有量产案例）
• 经纬恒润
• 普华基础软件（开发中）