1.扫盲系列-- 4 汽车控制器软件开发的常用工具2
2.企业级自动代码静态分析器Helix QAC--从应用层级保证代码质量和安全（二）
3.什么是代码覆盖率？
4.vscode识别autosar代码
5.万字长文。详细讲解OSEK直接网络管理，并对比Autosar网管。
6.AUTOSAR Ethernet Driver（以太网驱动程序）

扫盲系列-- 4 汽车控制器软件开发的常用工具2

       本文章聚焦于汽车控制器软件开发的底层工具，旨在为开发者提供专业指导。底层工具与系统和应用软件开发工具在需求管理、共享单车 开发 源码架构设计、代码编辑与版本管理方面相似，但在详细设计与测试方面存在显著差异。

       首先，推荐一款广泛使用的比较工具——BeyondCompare。这款工具适用于软件工程师，能够高效地比较不同版本的代码内容，辅助开发者进行版本控制。

       文件夹对比功能在底层软件开发中尤为重要，它帮助工程师全面了解代码差异，确保项目的一致性和稳定性。

       底层软件开发常用的调试工具有：劳特巴赫调试工具。它提供了嵌入式开发全生命周期支持，包括Bootloader、Firmware开发、OS和App调试以及后续测试。劳特巴赫工具允许实时跟踪代码运行状态，观察寄存器、内存、C源码、变量等资源，从而验证功能是否符合设计要求。

       Vector三件套提供了CANlyzer与CANape。CANlyzer支持报文模拟与验证，有助于检测通讯和诊断功能。CANape则实时监测TCU内外部变量，并允许调整标定变量数值，确保功能验证的准确性和完整性。

       底层软件开发还依赖于特定设备，如调试器、仿真器等，以确保代码在实际环境中的正确运行。

       汽车控制器通常采用AutoSAR标准开发，因此在上述工具基础上，还需增加满足AutoSAR标准的工具。Vector的qq等级源码6达芬奇、ETAS的ISOLAR、EB的Tresos是市场主流选择。Vector提供了整体工具方案，具体采用哪种方案取决于公司实际情况。

企业级自动代码静态分析器Helix QAC--从应用层级保证代码质量和安全（二）

       继续关注企业级代码质量与安全守护者--Helix QAC。这款强大的自动代码静态分析工具以其广泛支持的编码规范，如MISRA C/C++、AUTOSAR C++、CERT C/C++、CWE C/C++等，赢得了全球多家汽车厂商和供应商的信任。

       Helix QAC遵循“早期发现，频繁检查”的原则，确保在软件开发初期发现并修复数据流和控制流问题、不一致性、危险使用以及违反编码标准的情况，有效降低后期风险。

       通过提供一个自动化且高效的环境，Helix QAC能实时检测并报告不符合编码规范的情况，生成定制化的报告，包括代码审查、度量、合规性和抑制报告，帮助开发团队优化代码质量，提升可维护性、可复用性和安全性，从而简化开发流程，节省成本。

       编码规范方面，MISRA编码规范针对安全系统开发提供最佳实践，AUTOSAR Coding Guidelines则适用于现代C++语言的嵌入式系统开发，确保符合ISO标准。CERT规范则关注网络安全和设计错误，CWE则帮助识别和预防常见的软件安全漏洞。

       Helix QAC Dashboard作为团队质量管理平台，通过网页端集成，支持协作与共享，满足开发人员、项目管理者乃至高级管理人员的不同需求，实时监控代码质量变化和合规性。

       对于开发者来说，波段指标源码6关键在于理解代码库的合规状态，项目经理和QA则需要跨项目质量概览，供应商和客户则需要代码质量的详细配置信息。Helix QAC Dashboard整合所有这些视角，提供一致的质量分析。

       Helix QAC的架构包括客户端-服务器设计，带有诊断注释的源代码查看，灵活的诊断抑制机制，以及与Jenkins、JIRA等工具的集成。其资质认证如SGS-TÜV SAAR，适用于安全相关软件开发，满足IEC 、ISO 等标准，加速产品认证过程。

       想要体验Helix QAC的强大功能？直接联系北汇信息或发送邮件至info@polelink.com获取免费试用。更多动态和深入学习资源，请关注我们的更新：

       Helix QAC 年最新版本功能介绍

       鸿蒙智能汽车静态代码分析

       自动化静态测试实战指南

       汽车信息安全：代码静态测试的重要性

       C++与AUTOSAR编码规范结合，守护汽车安全

什么是代码覆盖率？

       代码覆盖率是一种通过计算测试过程中被执行的源代码占全部源代码的比例，间接度量软件质量的方法。它在保证测试质量的同时，也潜在地保证了实际产品的质量。通过这种方法，可以在程序中找出没有被测试用例测试过的地方，进一步创建新的测试用例来增加覆盖率。它属于白盒测试的范畴，主要依据源代码的内部结构来设计测试用例，通过设计不同的输入来测试软件的不同部分。

       根据评价的标准和方法不同，代码覆盖率测试可以分为语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、路径覆盖、多条件覆盖和修正条件判定覆盖等。针对不同的测试层次，代码覆盖率主要有单元级或架构级。单元级测试较为基础且使用方便，因此应用非常广泛。

       语句覆盖是代码覆盖率中最常用的一种度量方式，它度量被测代码中每个可执行语句是java 记账平台 源码否被执行到了。设计输入可以保证条件判断的两个分支分别都能执行到，从而实现语句覆盖度达到%。

       判定覆盖又称分支覆盖，它度量程序中每一个判定的分支是否都被测试到了。所谓判定，是指一条判断语句的结果，而不考虑其中包含的子判断的结果和组合情况。

       条件覆盖报告每一个子表达式的结果的true或false是否测试到了。即构造测试用例时，要使得每个判定语句中每个逻辑条件的可能值至少满足一次。

       修正条件判定覆盖要求在一个程序中每一种输入输出至少得出现一次，在程序中的每一个条件必须产生所有可能的输出结果至少一次，并且每一个判定中的每一个条件必须能够独立影响一个判定的输出。

       对于代码覆盖率的选择，对于大多数项目而言，-%的覆盖率较为合理，更高则非常不切实际。单元测试级覆盖率需要比系统级的高-%。具体地，代码覆盖率指标的设定需要考虑代码失效的成本、测试相关资源、可测性设计和开发迭代状况等，需要结合具体情况分析。

       参照汽车行业软件标准，如misra c/c++，autosar和ISO中也有涉及代码覆盖率的介绍。例如，ISO中推荐在单元测试中采用语句覆盖、判定覆盖和修正条件判定覆盖，根据ASIL（汽车安全完整性等级）的不同又有所不同。

       对于集成测试，ISO推荐采用函数覆盖率和调用覆盖率。

       综上所述，代码覆盖率是一种重要的测试方法，通过计算测试过程中被执行的源代码占全部源代码的比例，间接度量软件质量。在实际应用中，需要根据具体情况选择合适的覆盖率指标，并参照相关行业标准进行测试。

vscode识别autosar代码

       VSCode是一款流行的开源文本编辑器，提供了丰富的插件和扩展，以支持多种编程语言和开发框架。在VSCode中识别和编辑AUTOSAR（Automotive Open System Architecture）代码，你可以使用相关的插件和工具来实现。

       ç›®å‰ï¼Œæœ‰ä¸€äº›æ’件可以帮助你在VSCode中识别和编辑AUTOSAR代码，例如：

       1. AUTOSAR Language Support：这是一个提供基本AUTOSAR代码语法高亮和代码片段的插件，可以方便地编写AUTOSAR代码。

       2. Eclipse Embedded CDT：这是一个在VSCode上使用的插件，提供了一个AUTOSAR生成工具，用于生成具有AUTOSAR架构的C源代码。

       3. Polarion AVS：这个插件提供了AUTOSAR的验证环境和测试工具，可以在VSCode中进行AUTOSAR代码的验证和测试。

       è¿™äº›æ’件可以帮助你在VSCode中更好地识别和编辑AUTOSAR代码，提高开发效率。你可以在VSCode的插件市场中搜索并安装适合你的插件。不过需要注意的是，这些插件的功能和稳定性可能因版本和作者而有所差异，建议在选择插件时进行仔细评估和测试。

万字长文。详细讲解OSEK直接网络管理，js table样式源码并对比Autosar网管。

       在复杂的嵌入式系统中，网络管理是关键，特别是OSEK和Autosar的网络管理。让我们一起来探讨一下这两种网络管理方式的差异，特别是针对直接网络管理的详细解析。

       Osek的网络管理以其直接网络架构而闻名，特别是其网管报文和节点地址的管理。逻辑环是理解其工作原理的重要概念，每个节点按照顺序发送报文，地址信息存储在Byte0。理解逻辑环的建立、新节点的加入、节点异常退出以及结束逻辑环的流程，能帮助我们深入理解Osek的网络管理机制。报文包含了Source ID、Dest.ID（指向下一个节点的地址）、OpCode，数据内容则由用户自定义。逻辑环的建立涉及同步机制，如同起同睡，确保节点间有序通信。

       向CAN总线发送的Alive报文在逻辑环建立中扮演重要角色。当节点收到首帧Alive报文，它会被唤醒并回应。节点通过比较报文源和当前后继节点，更新后继节点。逻辑顺序Ring报文的发送则由"TTyp"定时器控制，环路完成后，网管状态进入NMRESET/NMNORMAL。在休眠模式下，节点使用SleepInd位来控制，无需考虑其他节点的状态。

       Osek的网管报文设置SleepInd位，表示ECU可能进入睡眠状态。当所有ECU无需工作时，通过SleepInd和SleepAck位触发休眠流程，所有节点最终进入NMBusSleep状态。在正常流程中，从唤醒到休眠的网管管理涉及环路建立和休眠。然而，新节点加入或ECU退出时，需要特殊处理，如新加入的节点通过发送Alive报文加入环，而退出的节点会影响Ring报文的发送和接收。

       相比之下，Autosar网管的管理更为简洁。唤醒状态仅依赖于网管报文的存在。新节点加入时，它会检测是否被逻辑环跳过，通过发送Alive报文进行同步。ECU异常退出时，环路中的节点会根据接收到的Ring报文数量调整，"TMax"定时器用于检测节点退出情况。

       Osek的复杂性体现在其LimpHome状态，它在特定错误条件下执行，如发送或接收失败。而Autosar的唤醒机制更为直接，主动节点发送报文后，被动节点响应。两者在网管报文内容的处理和唤醒流程上有着显著的差别。

       最后，虽然Osek的网络管理更为复杂，但本文仅是初稿，我们将在后续分享更多细节。如果你对这些技术感兴趣，可以访问我分享的OSEK NM源代码链接：/ruiyanganqing/OSEK_NM。关注我，以小白视角深入理解，让你的嵌入式开发之路更加顺畅。现在，让我们转向Autosar BSW开发笔记的目录，继续探索更多技术细节。

AUTOSAR Ethernet Driver（以太网驱动程序）

       AUTOSAR Ethernet Driver（以太网驱动程序）在汽车电子系统中扮演着关键角色，它作为Microcontroller Abstraction Layer（微控制器抽象层）的通信驱动，提供硬件独立的接口，使得上层网络接口能统一访问底层总线系统。其主要功能包括初始化、配置和数据传输，配置需考虑特定通信控制器特性，支持多控制器且可能需要与交换机驱动协作。驱动程序遵循one-fits-all原则，通过目标代码交付，允许无需修改源代码的配置。

       以太网驱动程序的开发基于AUTOSAR提供的通用规范，如SWS BSW General，确保了其在汽车行业的适用性。它存在一些约束，如单线程执行，不能处理大数据量，以及可能需要根据硬件异步/同步特性调整API。以太网驱动模块与多个模块交互，如交换机驱动程序，共同构建复杂的网络堆栈结构。

       功能规范方面，驱动程序提供了丰富的API，如初始化、设置控制器模式、获取物理地址，以及处理数据传输、时间同步和错误处理等功能。API设计注重性能和灵活性，如支持协议校验和计算和丢弃，以及接收数据和发送确认的处理机制。

       总的来说，AUTOSAR Ethernet Driver是一个高度标准化和可配置的以太网驱动解决方案，为汽车电子系统的高效通信提供了坚实的基础。

基于Embedded Coder 的AUTOSAR代码生成及MIL SIL PIL验证

       生成符合 AUTOSAR 标准的 C 代码和 ARXML 描述，通过使用 Simulink 编码器和 Embedded Coder 软件，可以构建 AUTOSAR 组件模型。此模型将生成算法 C 代码，并导出符合 AUTOSAR 经典平台规范的 ARXML 描述。在 Simulink 中进行测试或集成到 AUTOSAR 运行时环境中。

       首先打开要从中生成 AUTOSAR C 代码和 ARXML 说明的组件模型。使用 open_system(“autosar_swc”) 来打开一个示例模型。若要优化代码生成的模型配置设置，推荐使用 Embedded Coder 快速入门。通过从“应用”选项卡中打开该应用，并在 “AUTOSAR” 选项卡上单击“快速启动”来完成快速启动过程。选择“输出”窗口中的符合 AUTOSAR 的输出选项 C 代码。快速入门软件将指导您完成配置步骤。

       在生成代码之前，请检查 AUTOSAR 字典中的 XML 选项设置。在“AUTOSAR”选项卡上，选择“代码接口”> AUTOSAR 字典”。在 AUTOSAR 字典中，选择“XML 选项”。配置参数包括将“导出的 XML 文件”打包设置为“模块化”，以便将 ARXML 导出到模块化文件中。这样将生成 modelname_component.arxml、modelname_datatype.arxml 和 modelname_interface.arxml 等文件。

       完成模型的配置后，生成符合经典平台规范的 AUTOSAR C 代码和 XML 组件说明。在模型窗口中按 Ctrl+B 生成模型。生成过程将 C 代码和 ARXML 说明生成到模型生成文件夹中。生成完成后，将打开代码生成报告。通过执行这些步骤，可以确保模型的正确配置和生成。

       要从已配置为 AUTOSAR 经典平台的模型生成符合 AUTOSAR 标准的 C 代码和 ARXML 组件说明，需确保模型的架构版本与 AUTOSAR 标准相匹配。首次导入或为模型选择 AUTOSAR 系统目标文件会将架构版本参数设置为默认值 4.3。导入 ARXML 文件时，导入程序将检测模式版本并在模型中设置模式版本参数。例如，基于架构 4.3 修订版 4.3.0 或 4.3.1 的导入将设置架构版本参数为 4.3。

       生成 AUTOSAR 模型时，代码生成器会导出 ARXML 说明并生成符合当前架构版本的 C 代码。例如，架构版本为 4.3 时，导出将使用架构 4.3（修订版 4.3.1）的导出架构修订版。在导出 AUTOSAR 软件组件前，检查所选架构版本。如有需要更改，可使用模型配置参数为架构版本生成 XML 文件。

       最大短名称长度的指定范围为 到 个字符（包括 和 ）。默认值为 个字符。使用模型配置参数“最大短名称长度”来设置此值。启用 AUTOSAR 编译器抽象宏可以独立于平台生成编译器指令，这有助于在 位平台上优化代码效率，而无需为每个编译器单独移植源代码。

       根级矩阵 I/O 配置允许在生成的 C 代码中保留多维数组的维度，增强代码集成。如果应用设计需要列主数组布局，则可以配置 ARXML 导出以支持根级矩阵 I/O。默认情况下，对于列主阵列布局，软件不允许根级矩阵 I/O。启用此功能，可以指定支持使用一维数组的根级矩阵 I/O。

       配置完成 AUTOSAR 代码生成和 XML 选项后，生成代码。通过生成组件模型，将生成符合 AUTOSAR 的 C 代码和 AUTOSAR XML 描述到模型生成文件夹中。生成过程会生成一个或多个型号名称 *.arxml 文件，具体取决于“导出的 XML 文件打包”设置为“单个文件”还是“模块化”。这些文件将包含模型名称、组件描述和其他相关组件信息。

       将 AUTOSAR XML 组件描述合并回 AUTOSAR 创作工具中，以便利用已分区的文件结构进行合并。在 AUTOSAR 创作工具和基于 Simulink 模型的设计环境中，代码生成器保留 AUTOSAR 元素及其通用唯一标识符（UUID），以支持模型的往返传输。

       使用 AUTOSAR 4.0 代码替换库，可以生成与 AUTOSAR 标准紧密一致的函数。此代码替换库允许自定义代码生成器以生成兼容 AUTOSAR 标准的 C 代码。在 MATLAB 和 Simulink 查找表索引与 AUTOSAR MAP 索引之间存在差异时，代码替换软件会转置 AUTOSAR MAP 例程的输入参数。浏览支持的 AUTOSAR 库例程并配置代码生成器使用 AUTOSAR 4.0 代码替换库。

       为了支持 AUTOSAR 模型的 MATLAB 主机代码验证，AUTOSAR Blockset 提供了 IFX、IFL、MFX 和 MFL 例程的主机实现。使用这些实现作为模型启用软件在环（SIL）验证，而处理器在环（PIL）验证则适用于在生产目标硬件上验证目标代码。

       配置并运行模型的 SIL 仿真，以验证生成的 AUTOSAR C 代码。使用测试工具执行相关操作以检查组件模型与生成代码之间的等效性。对于多实例软件组件，可构建配置为多个实例化的 AUTOSAR 软件组件模型，并导入先前版本中的 AUTOSAR 代码进行观察。

       在进行 AUTOSAR 代码生成时，需注意以下限制：未选中“仅生成代码”复选框时，生成模型时会提示只有在使用 AUTOSAR 系统目标文件构建可执行文件的情况下才能使用 AUTOSAR 系统目标文件。此外，总线元素尺寸保留在导出的 ARXML 中，并在模型配置为“以行为主”时生成代码。C++ 为 AUTOSAR 自适应应用生成的样式范围枚举类在头文件中生成，以方便集成。

       了解这些关键步骤和注意事项后，即可高效地利用 Embedded Coder 和 Simulink 进行基于 AUTOSAR 的代码生成、验证和部署过程。

autosar E2E 源码解析

       在多年的实践应用中，我们曾利用E2E技术来确保车速和转速信息的准确性，通过在报文里加入Check和RollingCounter信号，监测信号的完整性和一致性。虽然起初可能觉得这种额外的使用是资源浪费，但其实是对总线负载的有效管理。E2E的核心其实并不复杂，本质上是CRC校验和滚动计数器的结合，不同厂商可能在位序和配置上有所差异，但原理相通。

       具体到源码操作，发送E2E报文的过程如下：首先从SWC获取E2E信号值，然后通过vector库进行处理，校验AppData的指针，配置报文，组织msg，更新E2E buffer，并进行CRC和滚动计数器的更新。最后，通过RTE接口发送信号。

       接收E2E报文则与发送过程相反，包括准备接收缓冲区，调用库函数读取数据，验证数据和计数器，将接收到的数据结构赋值，检查接收和本地滚动计数器的匹配，以及校验CRC结果。整个过程旨在确保数据的完整性和正确性。