AaronFU
AaronFU - 认证专家
每天进步一点点

注册于 2 years ago

回答
9
文章
23
关注者
5

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

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

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

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

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

Overview

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

项目贡献方编程语言代码状态参考链接
LedaBoschC/C++暂未发布https://github.com/eclipse-leda, https://projects.eclipse.org/projects/automotive.leda
VelocitasBoschPythonv0.2.0https://github.com/eclipse-velocitas/, https://websites.eclipseprojects.io/velocitas/
eCALContiC++/Pythonv5.10.1https://github.com/continental/ecal, https://projects.eclipse.org/projects/automotive.ecal
ChariottMicroSoft?暂未发布https://projects.eclipse.org/projects/automotive.chariott
SommRCariadC++暂未发布https://projects.eclipse.org/projects/automotive.sommr
ADAAAZFC++暂未发布https://projects.eclipse.org/projects/automotive.adaaa
MutoEteration暂未发布https://projects.eclipse.org/projects/automotive.muto

按照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等内存空间的检测开设专门的章节,如下图所示。
image.png

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

  • 双存储测试法: 针对关键的变量均额外定义对应的补码变量,由于这些变量都存储有各自的补码,因此,检查方法就是对其自身和其补码进行一致性检查。
  • 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文件,开发专用的内部工具自动完成。下图展示了一个由工具自动生成的资源报告实例:
image.png

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

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

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

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

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

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

发布
问题