知识分享 | 使用MXAM进行AUTOSAR模型的静态分析：Embedded Coder与TargetLink模型

知识分享

在知识分享栏目中，我们会定期与读者分享来自MES模赛思的基于模型的软件开发相关Know-How干货，关注公众号，随时掌握基于模型的软件设计的技术知识。

使用MXAM进行AUTOSAR模型的静态分析：Embedded Coder与TargetLink模型

文章内容来源：MES模赛思官方网站

AUTOSAR（AUTomotive Open System ARchitecture）是由电子、半导体和软件行业的汽车制造商、供应商和其他公司组成的全球开发合作伙伴关系。AUTOSAR标准旨在实现软件标准化、可重用性和互操作性。AUTOSAR标准提供了支持当前和下一代汽车ECU（Electronic Control Unit）的开发平台：AUTOSAR Classic Platform支持传统的内部应用，如动力总成、底盘、车身和内饰电子设备；AUTOSAR Adaptive Platform支持新的基于服务的应用，例如自动驾驶、车联网、OTA（over-the-air）等。AUTOSAR Adaptive Platform支持Classic AUTOSAR、Adaptive AUTOSAR和non-AUTOSAR ECU在单车内的交互操作。

在过去的二十年中，AUTOSAR已成为汽车行业开发SWC（Software Component）最重要的标准之一，因为它支持在各种ECU上分布式开发和部署SWC。同时，基于模型的开发方法（Model Based Development）已成为许多行业和组织的标准开发方法，当然也包括汽车行业。在这一点上，我们不得不提到汽车行业主流建模框架（如Simulink），以及代码生成框架（如TargetLink和Embedded Coder等），在Classic和Adaptive平台上都集成了对AUTOSAR的支持。与此同时，当我们考虑基于模型的软件开发或者通用的软件开发时，必须考虑全面的模型静态分析方法，以确保相关软件在模型和代码层面的质量。

此外，软件安全本身也是我们对汽车产品的一项基本要求。汽车软件的开发同样必须符合安全标准的相关要求，例如安全相关的汽车软件开发必须符合ISO 26262标准。确保基于模型的软件质量需要专业的质量保证工具。例如业内广泛应用的工具MES Model Examiner (MXAM)，可为质量保证提供综合全面的静态分析方案。在视频“使用MXAM进行符合AUTOSAR标准的建模”展示了MXAM与AUTOSAR如何协同工作以实现合规性。接下来，本文将提供更深入的分析。

MES模赛思的MES Model Examiner (MXAM)如何支持我们进行模型的静态分析？

首先我们来简要概述一下MXAM的工作流。MXAM的工作流主要包括：新建或打开一个现有项目，选择模型和设置规范文档，运行分析，查看结果，在指导下自动或手动修复违反建模规范的情况，通过注释功能批注规范违反原因，最后保存并导出合规性报告。其具体过程详见图1。

图1：MXAM执行静态分析的工作流

MXAM支持多种模型类型的检查：Simulink模型、 dSPACE TargetLink模型或ASCET模型。新建或打开MXAM模型检查项目时，可在GUI（Graphical User Interface）下自动获取当前Simulink中处于活动状态的模型，如图2所示。在持续集成环境中，我们还可以通过编辑Windows或MATLAB脚本指定待测的模型工件。

图2：MXAM待分析工件选择

加载模型工件后，必须考虑在静态模型分析方法中要验证哪些规范。在MXAM项目中，规范以规范文档的形式设置和管理。规范文档源于行业和企业标准的建模规范。 来自MES模赛思的工具为各规范专门开发了相应的规范检查例程。在一个功能安全相关的开发项目中，我们可以选择与功能安全相关的MES功能安全规范。如果我们需要验证模型与MISRA规范的一致性，可以设置MISRA SLSF规范文档，或者如果我们使用TargetLink作为代码生成器，那么就需要选用dSPACE TargetLink建模规范中的相关规范。除了MXAM提供的行业和企业标准建模规范集，我们应根据项目的实际要求合理选择、设置或自定制企业或部门专用的规范文档，如图3所示。

图3：编辑设置自定义规范文档

此外，关于如何选择或自定义规范，MXAM提供了高效的规范文档创建助手，帮助我们根据模型工作环境和项目需求快速创建专属的规范文档，为企业和部门层面的管理和引用提供支持，如图4所示。

图4：自定义规范文档创建助手

运行分析前，如有必要，我们还可作进一步的模型设置，如设置当前项目检查规范，如图5所示。

图5：设置当前项目检查规范

再如当模型的某些模型组件或模型要素与所分析的软件无关时，我们可以通过添加并设置忽略列表，选择性地将某些模型要素忽略在某规范集的分析之外，如图6所示。

图6：设置忽略列表

此外，通过恰当的参数设置，如图7所示，我们可以更灵活地运用MXAM提供的自动化规范检查例程，满足特定项目对定制参数的模型检查需求。

图7：MXAM的可定制参数设置

完成规范集和相应参数配置后，通过MXAM工具界面中的分析按钮、Simulink窗口的菜单栏或模型上下文中的MXAM命令，可进行静态分析。在未启动MXAM工具的情况下，我们还可以通过运行MATLAB脚本或Windows批处理脚本，进行批处理模式下的模型或工件的静态分析。如图8所示，MXAM通过GUI和脚本命令行，高度智能化地集成在MATLAB中，从而实现MXAM与MATLAB间的快捷互操作。

图8：MXAM在MATLAB中的智能集成

分析结束后，即得到分析报告。分析报告为我们提供了总体分析的概览以及各部分内容的详细描述，包括MXAM项目中所分析模型对相应设置的规范集的所有一致性结果及其完整信息。对于报告中的违规项，我们可以使用MXAM的自动修复功能自动更正模型，确保我们所建立的模型符合规范集和自定义参数设定的要求，如图9所示。

图9：互动式报告与自动修复

此外，MXAM提供的注释功能可与标准评审流程无缝集成，支持项目中模型的评审和偏差接受机制，如图10所示。

图10：MXAM注释与评审机制

然后，我们保存并导出报告或重新运行分析，直至最后得到完善的模型，并能根据不同需求导出对应格式的报告，如图11所示。

图11：灵活的报告输出

按照上述的工作流程，MXAM可为AUTOSAR模型审查和优化提供高效支持，尤其对于大型和复杂的Simulink/TargetLink AUTOSAR模型系统。当我们使用Embedded Coder或TargetLink作为代码生成器时，MXAM是如何支持我们进行AUTOSAR软件模型开发过程的呢？

首先，SWC和Runnable是使用子系统建立AUTOSAR模型的基础，SWC/Runnable在Simulink中建模为子系统。例如，如果我们使用TargetLink建立AUTOSAR 模型，图12的示例给出了TargetLink模型中的部分内容，一个AUTOSAR SWC包括若干子系统和一些接口设置，在子系统中定义Runnable算法并添加TargetLink Function模块，将子系统设置为AUTOSAR Runnable，这就是TargetLink创建AUTOSAR Runnable的方式。另一方面，对于Embedded Coder，我们通常使用原子子系统或Function调用子系统来进行周期性或非周期性的AUTOSAR Runnable建模。 这里我们主要关注由子系统对AUTOSAR Runnable进行建模的用例。

图12：SWC/Runnables建模

AUTOSAR字典给出了模型与AUTOSAR设置之间的关联。 对于TargetLink，AUTOSAR设置包含在标准的TargetLink数据字典中，Simulink支持专用的AUTOSAR字典，通过AUTOSAR字典，我们可以设置和分解SWC或Runnable项，以及接口设置、应用或实现数据类型的设置。

两种代码生成器都支持往返机制，即如果在模型中导入AUTOSAR描述文件（ARXML），例如SWC描述，则可以生成框架模型或更新当前模型。相反，一个SWC Runnable的模型更改后，可以更新对应SWC的描述。

在使用Embedded Coder开发模型时，对自动生成的模型部分执行静态测试可能会导致大量时间和资源的浪费。MXAM v10.0已扩展了分析参数（见图13）。如果该参数设置为"True"，MXAM将仅分析可运行子系统内的模型元素。

图13：全局分析参数“Global.AnalyzeAutosarRunnablesSubsystemsOnly”

在开发AUTOSAR模型的过程中，工程师通常使用ARXML文件启动模型生成和框架构建。因此，系统会自动生成多个层级的结构和附加文件。然而，自动生成的模型部分并不一定需要进行静态测试，因为它们必须遵循预定义的AUTOSAR结构。对这些固定部分执行静态测试将消耗不必要的时间和精力。 新的全局参数使工程师能够仅分析AUTOSAR Runnables内的模型和函数，从而使开发者能够将模型分析重点放在特定应用和可修改的部分上，显著提高效率并节省宝贵时间。

以上的设置方法属于静态的设置，我们也可以采取动态的方法来搜索相关工件对象并运行分析。为此，我们需要确定一些常见的标识符表征的链接。这也相当容易，因为我们只需搜索Runnable的Function模块，如使用Simulink API，然后可以自动找到与我们的分析相关的子系统，只需分析模型中实际对应于Runnable子系统的那些要素即可。

上面的示例内容是关于MXAM如何支持TargetLink的AUTOSAR建模。接下来，让我们具体看看MXAM如何支持使用Embedded Coder开发SWC模型。

在Embedded Coder中，系统目标文件被设置为autosar.tlc或autosar_adaptive.tlc，为AUTOSAR用例启用代码生成，作为Embedded Coder提供的标准ERT系统目标文件的扩展设置，如图14所示。这里可以看到两个在生成SWC ARXML描述文件方面影响AUTOSAR代码生成的选项：启用AUTOSAR编译器抽象宏，使生成的代码以独立于平台的方式抽象16位平台的编译器指令；最后一个选项为确定软件是否通过将矩阵实现为一维数组来支持根级的矩阵输入输出。

图14：Embedded Coder AUTOSAR代码生成设置

通常在项目中，我们希望这些代码生成选项的设置保持一致。当然，这些统一性设置也适用于AUTOSAR代码生成选项。MXAM怎样支持我们呢？MXAM通过提供检查项mes_cgec_9004来检查代码生成选项中相关设置的一致性。其检查的原理是通过附带的一个专用的自动检查项来查看Excel列表中的所有代码生成选项的预设值，特别是对于AUTOSAR相关设置项，并将模型的值与此Excel工作表中的给定值进行比较。如果发现不一致，MXAM会报告失败结果，并可应用自动修复功能。相关选项的预设属性值可以根据具体项目需求进行设置。

图15：AUTOSAR Blockset中的模块

我们需要了解的重要信息是：MXAM支持AUTOSAR模块用于应用软件模型到代码生成的过程，特别是对于AUTOSAR库例程中的查表库。进一步查看Simulink自带的AUTOSAR模块库，如图15所示，这些用于AUTOSAR额外封装的查表例程模块主要包括曲线查表，曲线预查表，映射查表和映射预查表等。代码生成时，AUTOSAR例程将替换这些库模块。

模块的属性设置会对AUTOSAR代码产生直接的影响，如果查看这些模块的相应属性，如图16所示，那我们会发现这些是查表模块库中带封装和对话框的标准模块，并且封装与模块参数之间数据类型得以同步。MXAM支持正确读取相应模块属性， 可完全支持Simulink的AUTOSAR查表库例程模块集的代码生成过程。

图16：AUTOSAR模块集的查表模块属性

在Embedded Coder的情况下，Simulink使用右侧描述的数据类型，与AUTOSAR平台类型之间存在固定映射关系。如表1所示。

表1：Simulink模型数据类型和AUTOSAR平台类型之间的映射

因此在Embedded Coder的代码生成框架下，MXAM并不需要区分AUTOSAR和non-AUTOSAR模型，这对于数据类型一致性的检查等实施场景非常重要。比如对于MAB规范检查项na_0002，布尔量信号的端口只能用布尔量信号而不是数值信号来馈送。 现在，这条规范在MXAM中已经集成为标准库的规范，MXAM完全支持Embedded Coder中AUTOSAR代码生成过程中的数据类型映射机制，其描述如图17所示。

图17：Embedded Coder平台AUTOSAR/non-AUTOSAR模型代码生成数据类型映射

在TargetLink模型框架下，TargetLink AUTOSAR模块库用于AUTOSAR代码生成。TargetLink AUTOSAR模块库（图18）中我们可以看到通用的接口，输入/输出端口和总线、TargetLink数据存储模块、TargetLink Runnable模块、SWC接收方端口和发送方端口模块等。此外，还有接收方和发送方comSpeck模块，用来与RTE（Run-Time Environment）进行仿真交互。 MXAM支持TargetLink AUTOSAR模块库中的模块用于Classic和Adaptive平台的应用开发。

图18：TargetLink AUTOSAR模块库

TargetLink的AUTOSAR用例方法与Embedded Coder略有不同，TargetLink允许从同一个模型为AUTOSAR和non-AUTOSAR用例生成代码。 我们可以理解为TargetLink AUTOSAR库中所有相关模块接口设置包含两个层面，如输入/输出端口模块和数据存储模块的接口设置中包含标准的输出端口的接口设置和AUTOSAR接口设置，我们还可以看到这些模块中的数据设置也有所不同。例如图19中的AUTOSAR模块设置，开发人员已经选择了使用平台数据类型如int16，以及固定的LSB（Least Significant Bit）。

图19：AUTOSAR模块设置

同时，如图20中non-AUTOSAR设置标签下，设置了不同的数据类型和缩放比例。 总而言之，在TargetLink AUTOSAR和non-AUTOSAR情形下可以并行指定数据，当然，这些指定的数据可能不同。

图20：标准模块设置

静态分析工具MXAM如何处理这些AUTOSAR模块？事实上，MXAM会自动区分AUTOSAR和non-AUTOSAR用例，并且MXAM分析模块数据设置或用于静态分析的决策基于AUTOSAR代码生成模式和所分析的模块的AUTOSAR设置。如图21所示，TargetLink主对话框中设置的代码生成模式为Classic AUTOSAR。

图21：TargetLink主对话框中代码生成模式设置

如图22中所示的相应模块的AUTOSAR模式设置，这两处设置都必须针对AUTOSAR进行，以便MXAM可采用相应的AUTOSAR设置。在其他情况下，我们希望尽量保持与标准代码生成的一致性。对于标准用例，MXAM会自动采用输出端口设置的模块数据。

图22：模块的AUTOSAR模式设置

图23：Product模块关于MAB na_0002规范的一致性

这里我们介绍一个简单的例子。对于MXAM规范库中的na_0002规范，规范要求逻辑信号不得连接到对数值信号操作的模块。例如图23中的Product模块，按照规范要求，该模块的第一端口应满足端口信号须为数值信号。然而，由于在源信号的设置中，总线输入模块的设置成了布尔信号（如图23-26所示），因此违反了该规范。在MXAM中进行静态分析，获得的结果会有所不同，具体取决于我们在模型中设置的代码生成模式类型。

图24：Product模块输入源信号的输出端口类型设置

图25：输入源信号的AUTOSAR端口设置

图26：TargetLink主对话窗代码生成模式设置为Standard

让我们再深入检查相关设置：在这里有uint16定义。

如果设置为标准模式，同时将相应信号提供端口设置为布尔类型时，就会出现违反na_0002规范要求的情况，如图27所示。 通过使用静态分析工具MXAM运行检查，报告中得到违规项结果如图：端口应由数值信号输入，但实际被设置为布尔值。

然而，在TargetLink主对话窗口设置为AUTOSAR模式的情况下，如图28所示，这是没问题的，结果如图29所示。

图27：TargetLink主对话窗代码生成模式设置Standard时MXAM规范na_0002的检查结果

图28：TargetLink主对话窗代码生成模式设置为AUTOSAR

图29：TargetLink主对话窗口设置为AUTOSAR模式时MXAM规范na_0002的检查结果

如果还记得有关Embedded Coder代码生成选项的设置内容，那么对于TargetLink的设置也是类似的。如图30中所示，Classic AUTOSAR平台的TargetLink代码生成选项的相关设置会影响RTE API调用方式。所以在TargetLink代码生成之前对相关Runnable进行接口设置的检查显得尤其重要。

图30：Classic AUTOSAR代码生成模式下的严格接口检查设置

此外，实际项目中可能具有对代码生成设置项的特定设置要求，自动检查例程可通过MXAM库中的规范mes_cgtl_9002检查所需的预设值，相关设置项的自定义设置可参看规范中描述的Excel参数表附件，如图31所示。当然，对于Simulink/Embedded Coder，我们会看到类似的参数表。

图31：TargetLink参数设置检查表

对于AUTOSAR模型的静态分析的问题，我们在此做个小结。首先，模型静态分析工具如MXAM的应用可高效地支持Adaptive和Classic AUTOSAR模型的快速分析。其次，无论是TargetLink AUOTSAR模型还是Embedded Coder AUTOSAR模型，MXAM都能支持从AUTOSAR模型到代码的静态分析过程。特别对于TargetLink存在不同的设置，区分AUTOSAR和non-AUTOSAR的情况，不同模块的适用数据直接基于AUTOSAR设置。如果我们已经为AUTOSAR代码生成设置了模型 ，则MXAM采用AUTOSAR设置，如果没有进行相应的代码生成设置，模型默认采用标准设置。最后，我们可以通过设置MXAM自带的工具配置参数表，进行项目代码生成选项设置的自动化检查与设置修正。

总而言之，在模型开发早期引入工具MXAM，可以帮助我们在模型开发过程中及早发现模型的错误并加以修正。对于需要特殊配置的AUTOSAR模型，及早发现模型中的配置错误并自动修正，可以极大地提高模型开发的效率，保障模型到生成的代码质量，以及符合ISO 26262功能安全标准的一致性要求。