标签: 电子电气架构

伴随着电动化、智能化、网联化等技术发展的时代背景，各行各业电子电气架构都在发生深度变革。新型架构逐渐取代传统架构，比如汽车、工程机械、储能、船舶等领域，电子电气架构从传统分布式向域集中式，甚至向着中央集中式发展，控制器功能呈现集中化、复杂化的特点。为了提升开发效率、提高软件的稳定性以及便于平台移植，基于 AutoSar 架构开发复杂软件已成为行业共识。 另外，行业内竞争愈发激烈，开发周期大大压缩，加之软件复杂度的提升，在快速迭代的情况下确保软件质量是一个重要课题。加之 ASPICE、ISO26262 等过程体系和法规标准的要求，如何开发符合 AutoSar 架构的应用软件、评估软件质量和性能、优化软件结构、验证压力场景下的 ECU 稳定性成为各厂商面临的新挑战。 本文重点介绍符合 AutoSar 架构的应用软件开发、MBD 开发模式下的软件质量评估与优化方案、复杂场景下的 ECU 性能压力测试方案。 符合 AutoSar 架构的应用软件开发介绍 对于 AutoSar 软件架构，分为经典平台 AutoSar CP 和自适应平台 AutoSar AP，二者应用场景存在一定差别：AutoSar CP 具有高安全、高实时性，其通常部署在微控制器 MCU 类型芯片或多核异构芯片 M 核；AutoSar AP 具有动态性和可扩展性，适用于大数据并行处理和高性能计算等应用场景，通常部署在 MPU 或多核异构芯片 A 核。目前从行业内来看，无论是域控制器还是中央 + 区域控制器，通常都是多核的，甚至是多核异构的，不同核根据实际使用需求部署 AutoSar CP 或 AP，基础软件通常采用标准的 BSW 协议栈。下图所示是 AutoSar 软件架构示例： AutoSar 软件架构 那对于应用层软件来说，如果要开发符合 AutoSar 架构的软件，需要考虑以下两个重要问题： · 采用何种开发工具链 · 采用何种开发模式 对于应用软件开发工具链，通常涉及 SWC 软件架构设计工具和软件编程实现工具。SWC 软件架构设计工具主要对应用层软件架构进行实现，定义 SWC、配置 SWC 的交互接口、配置 Runnable、导出 ARXML 文件等，一般不同品牌的协议栈都有对应的 SWC 软件架构设计工具，经纬恒润自研 AutoSar 协议栈提供工具链方案为 EAS-SWCDesigner。 EAS-SWCDesigner 界面 而软件编程实现可基于图形化编程自动生成代码或手写代码的方式，AutoSar CP 和 AP 架构应用层软件开发实现方法略有差别，CP 架构应用层更多采用基于模型设计方法开发，工具链通常采用 Matlab/Simulink，其对 CP 架构应用层开发的支持比较完善且成熟，但是由于其对 AP 架构应用软件开发支持还存在不完善的点，故 AP 架构应用层软件开发目前更多还是基于手写 C++ 代码的方式，工具链基于一些代码编辑工具比如 Vscode。 对于应用软件开发模式，分为自上而下开发、自下而上开发和双向开发模式。自上而下开发比较适用于正向开发流程，在有 EE 架构输入的情况下采用该模式，这种模式的好处是可以继承 EE 架构的工作产品，但是缺点是工作链路会比较长，应用层和底层软件开发都需要依耐 SWC 架构设计导出的 ARXML 文件作为输入，影响开发迭代效率；自下而上开发是直接在软件编程工具实现软件，然后配置 AutoSar 接口，再导出 ARXML，然后对 ARXML 文件进行合并，这种方式比较适用于没有 EE 架构输入的情况，应用软件开发工程师独立配置 AutoSar 接口，这种模式的好处是不依耐 AutoSar 工具链，比较灵活，但是缺点是对每个应用软件开发人员 AutoSar 知识要求高些；双向开发模式就是结合自上而下和自下而上开发模式的优点，针对第一版软件采用自上而下开发模式，后续版本软件更新迭代采用自下而上开发模式。 应用软件开发模式 MBD 开发模式下的软件质量评估与优化方案 MBD 全称是 Model Based Design（基于模型设计），是一种以可视化模型开发为主的开发方式，区别于传统的以文本编码为媒介的代码开发。采用模型化的方式来描述控制算法设计，无论是可读性、可维护性、可移植性、测试验证的便利性等方面，相比于从前手工 C 代码都有长足的进步。基于以上基于模型开发的特点基于 Simulink 的模型化 + 自动代码生成的开发方式在汽车电子行业正在逐渐演变成开发的标准配置。接踵而来如何保证 MBD 开发方式下软件质量问题也成为现阶段人们热议的话题。 针对软件质量直接有效的手段便是开展完备的测试或在软件开发过程中优化软件结构减少问题的引入。 如何开展完备的模型测试？ 模型验证方法可以分为静态验证和动态验证，模型静态验证，是一种通过 MAAB 和 dSPACE 等建模公司提供的建模规则指南来验证模型设计是否符合规则的测试方法。此外，还有一种模型度量元指标检查方法，可以分析模型的复杂程度，以此评判模型在可维护性、可移植性、可重用性等不同维度的质量特性。综上所述，在模型静态验证部分，可以看出有两种方法：建模规范规则检查和模型度量元指标检查。与模型静态验证不同，模型动态验证可以通过比较在执行实际模型时的输出值来进行验证。通过根据用户输入预期结果值对比实际模型结果值来动态验证模型。通过检查模型的覆盖率，可以提高测试用例针对需求的覆盖率以及测试用例的充分性。此外借助 ASPICE 过程管理的思维，在整个测试过程中加入过程管理思维，确保测试过程、测试环境、测试策略的可靠性以及测试用例的充分性、一致性、追溯性，以此确保模型质量。 如何优化软件结构？ 现阶段我们模型生成的代码是否会存在以下问题： · 生成代码一个函数可能会上万行代码 · 看不懂 matlab 生成代码后的变量的定义及过程转化 · 要不要针对模型生成的代码做修改 优化软件的前提是已经开展静态测试优化完毕模型结构。确保模型结构的规范性。针对每一个软件设计单元生成独立函数、每一个软件组件生成与之相对应的 C 文件可以确保模型生成代码的结构清晰。同时不对模型生成的代码做任何的修改是 MBD 开发过程中的软件维护准则。 综上让我们一起来期待恒润针对 MBD 开发模式下的软件质量评估与优化的解决方案。 复杂场景下的 ECU 性能压力测试方案 随着控制器数量的激增和模块交互复杂度的提升，只针对软件基础功能验证的效果存在一定的缺陷，越来越多的项目实践表明，软件的偶发性故障需要从软件性能指标、压力场景来进行补充验证，以确保软件产品的质量。 性能测试针对 ECU 电控软件的内存（堆栈、RAM/ROM/FLASH）、CPU 负载进行最差工况的分析，保证资源占用的合理性；压力测试构建通信、IO 驱动、诊断、网络管理等模块的异常注入、总线故障、高频触发等场景，保证软件功能在压力场景下不存在致命风险。 基于 AbsInt 的静态性能分析 ◾ 客户收益 · 评估资源使用率，指导芯片选型和工程优化 · 保证软件的任务、中断预留堆栈空间和分配周期合理性 · 保证芯片内存占用率和 CPU 负载在阈值范围内 · 开展符合功能安全和 ASPICE 流程要求的测试 ◾ 测试内容 · 内存：自动化分析最差工况的堆栈用量、RAM/ROM/Flash 占用率 · WCET：分析最差工况下的执行时间，测试周期稳定性和任务实时性 · 调度仿真：模拟任务调度，建模仿真 CPU 负载率和任务占比 ◾ 方案特点 · 借助 AbsInt 工具，针对工程二进制可执行文件进行自动化分析，无需依赖源码 · 支持 PPC、V850、Tricore、ARM 等多种架构芯片的堆栈、时间分析 · 分析遍历工况，结果涵盖程序的各个入口 · 图形化展示最差工况下的执行路径和占比用量，指导性能优化 · 不依赖测试用例，执行效率高，项目周期短 · AbsInt 工具满足 ASIL D 等级功能安全标准 基于 AbsInt 的测试流程 函数调用关系及用量显示 数据化表格用量展示 基于 RVS 的动态性能测试 ◾ 客户收益 · 在 PIL、HIL、车载环境下进行时序分析，确保软件行为安全 · 可视化监测任务调度和 CPU 负载，为系统升级提供优化参考 · 保证多任务和多核运行的合理性，规避优先级反转、死锁等时序问题 · 开展符合功能安全和 ASPICE 流程要求的测试 ◾ 测试内容 · WCET：分析任务 / 中断的最差工况执行时间，测试周期稳定性和响应实时性 · 任务调度：评估 WCRT，监测任务时序特征，图形化显示多核、多任务调度关系 · 负载率：基于实际工况对 CPU 负载率进行实时统计和分析，评估极限负载下的 CPU 负载率占用情况 ◾ 方案特点 · 借助 RVS 分析套件进行实时数据采集和分析，还原实际环境下的执行工况 · 支持全量数据采集和长时间监测运行，追踪定位软硬件交互情况 · 自定义程度高，项目复用性强，可针对任意函数、模块或代码段进行时序分析 · 支持集成多种处理器 + 编译器环境，实现 PIL/HIL/ 车载环境下分析 · RVS 工具可以支持产品功能安全认证等级 ASIL D 基于 RVS 的测试流程 时序调度分析 基于自动化测试框架的压力测试 ◾ 客户收益 · 保证通信、诊断、操作系统、IO 驱动、网络管理等模块在压力场景下不存在致命风险 · 作为功能验证的补充，发现软件质量潜在问题，确保软件鲁棒性、稳定性 · 构建标准化的压力测试用例模板，有助于形成符合功能安全要求的测试流程 · 测试用例搭载自动化测试框架进行测试执行、用例管理、问题追溯 ◾ 测试内容 · 针对 NVM、IO 驱动、CAN、LIN、ETH、COM 等模块进行压力场景构建 · 分析系统不同组件间的时延特性，验证模块运行时间稳定性 · 验证在异常注入、高频触发、总线故障等因素影响下的功能稳定性 · 验证极限工况下的核心功能有效性及软件后续响应的合理性 ◾ 方案特点 · 借助自动化测试框架执行测试用例，测试周期短、测试效率高、测试复用性强 · 支持软硬件交互，可监测底层函数、上层报文、外部信号等 · 支持在 PIL/HIL 环境下开展测试，可同步注入多种激励进行测试验证 测试流程示意 测试框架示意 了解更多 请致电 010-64840808转6117或发邮件至market_dept@hirain.com（联系时请说明来自面包房社区）

PREEvision工具为用户提供了一个完整的协同开发平台，不仅支持从电子电气系统需求阶段到产品系列开发的全过程，同时包括了对产品线及模型元素管理方面的内容。 图1 PREEvision工具EEA设计流程 本文重点围绕PREEvision工具在EEA设计阶段各层功能及建模要点进行描述（主要在EE perspective下）。 1PREEvision 产品目标（Product Goal） 产品目标（Product Goal）用于描述产品的设计目标，主要从设计需求层面开展建模设计。包括三个维度，即客户特征（Customer Feature）、需求（Requirements）以及用户用例（User Cases），是以三种不同视角以层次化及图形化去构建整车电子电气功能与非功能方面的需求。 1.1 客户特征（Customer Feature） 客户特征（Customer Feature）是作为整车电子电气系统设计第一步，也是工具建模开始的第一层，它以整车的feature与function清单为基础，在PREEvision工具中以图表的格式，按需求工程的层次来进行录入的。 模型开发要点： 1、统一的命名规则，包含对模型各层中全部Artifact的命名，便于协同工作时的统一性（以下各层相同）； 2、如果涉及变量管理，则需要在这一层就开始同步定义变量及变量之间的关系，继而模型化。 图2 客户特征（Customer Feature） 1.2 需求（Requirements） 需求（Requirements）用于描述具体功能与非功能需求，可以包括技术需求、结构需求、布置需求、法规需求、性能需求、EMC需求（或目标）等。目前最新版本9.5.3已经在属性定义上与需求管理工具Doors更加一致。 支持树形结构编辑及表格界面编辑的同时，还支持相关设计文档的嵌入。 模型开发要点： 1、应保证需求的准确性、完整性以及一致性； 2、需求层的Attribution定义尽可能的按需求的类型进行分包定义，对需求按类型划分层级； 3、应该对需求的级别进行定义，如Shall、Must、Will、Should等。 图3需求（Requirements） 1.3 用户用例（User Cases） 用户用例（User Cases）是站在用户的视角，涵盖角色，关联关系以及功能因果链关系的模型。这个模块目前在国内各个PREEvision用户中使用相对较少，但是随着正向开发以及SOA的发展应用，用户用例及场景分析将越来越重要，因此在这一层的建模工程将逐步应用起来。 图4 用户用例（User Cases）模型（图片来源：Vector） PREEvision的需求层为第三方工具提供了功能丰富的导入和导出功能，例如在需求层可导入导出DOORS、Excel格式的需求描述文件。 2PREEvision 逻辑功能架构（Logical Function Architecture） PREEvision工具在这一层是对功能逻辑进行建模，主要包括传感模块、逻辑模块以及执行模块的模型元素，通过接口（Interface）定义模型元素彼此之间的关系，通过数据（Data）定义彼此之间交互的具体信息，并最终形成逻辑架构模型。 模型开发要点： 1、定义好建模规范，尤其是模型的整体风格要求，如模型元素的尺寸、颜色、布置等要求（以下各层相同）； 2、在Library中按系统划分方式或负责人分工方式定义package，各负责人在定义好的package中定义好接口及数据类型（需要遵从集团级的命名方式），以跨系统间的接口调用； 3、定义Activity chain，以便更好的理解完整的功能链。 图5 功能逻辑模型 3PREEvision 软件架构（Software Architecture） PREEvision工具在这一层支持软件行为（Software behavior）模型设计、面向服务的架构（SOA）模型设计、软件架构模型设计以及面向对象的软件设计、诊断模型的设计。其中基于AUTOSAR Adaptive 的SOA设计是PREEvision在软件定义汽车概念中的一项最佳实践，主要的设计内容：服务定义、服务接口设计、SOA架构、软件架构、以太网通讯设计、服务部署/软件映射、Switch配置等内容。 模型开发要点： 1、PREEvision工具的软件层模型重点面向应用层的设计； 2、在Library中按系统划分方式或负责人分工方式定义package，各负责人在定义好的package中定义好接口及数据类型（需要遵从集团级的命名方式），以跨系统间的接口调用3、SOA设计过程中VLAN尽量定义为10的倍数，避免后期产生错误； 4、SOA设计中，注意自动生成的设置数据如果与设计数据不符，应及时调整； 5、必须确保ADT与相应的IDT的数据类型是兼容的，否则无法实现有效映射； 6、AUTOSAR的“依赖（Dependency）”关系无法实现导入导出。 图6 SOA及软件设计流程与工作产品 图7 SOA、以太网及Switch设计编辑界面 图8 软件架构模型 通过这一层的建模，最终可导出ARXML格式的应用层软件文件，用于后续的软件详细开发，同时关乎设计的技术规范，如服务矩阵、以太网通讯矩阵、软件架构等也可通过报告形式自动生成。 4PREEvision 硬件网络架构（Hardware Network Architecture） PREEvision工具在网络架构层是面向车载总线通讯的网络的建模设计。主要包括网络拓扑模型设计、通讯报文、信号路由模型设计，其中通讯设计涵盖了目前主流的CAN/CAN FD，LIN、Flexray以及Ethernet的通讯模型设计。 在这一层中， PREEvision 还支持 ARXML/DBC/LDF/F IBEX 等数据库文件的无缝导入导出 ，如CANoe，Davinci等。 模型开发要点： 1、模块化的部件、总线、接口、信号等的artifact与其类属性尽量在Library中创建，以便产品的复用； 2、如果有特殊的路由规则及相关评估权重，需要在信号路由前对规则进行定义。 图9 网络拓扑模型 图10 通讯设计流程 图11 CAN总线通讯报文设计 5PREEvision 硬件部件架构（Hardware Component Architecture） PREEvision工具在硬件部件层是面向ECU、系统/子系统电气原理、线束的建模设计。主要包括ECU架构模型设计、系统/子系统电气原理模型设计、电源分配模型设计、接地分配模型设计、线束原理模型设计。 在这一层中，PREEvision支持KBL文件的导出，通过二次开发实现与线束设计工具的无缝衔接，如Capital Design。 模型开发要点： 1、电源分配、线束中用到的元器件（device）种类较多，且重用度高，尽量在Library中定义模型元素，以便复用； 2、注意cable、core、schematicpin、splice、header、wiring connector、wiring harness inlineconnector、slot、cavity的区别与定义； 3、定义Header的Connector Prototype的时候需要确认对应线束端的Connector Type是否定义了对应的Connector Prototype; 4、注意pin脚定义时不同连接类型应使用不同的pin类型； 5、如果需要属性完整的KBL文件导出，Connector的slot和cavity必须定义完整； 6、线束模型设计中变量定义对“Must-Use”的应用 图12部件模型 图13 部件原理模型 图14 电源分配模型 图15 线束原理模型 6 PREEvision 物理架构（Geometry） PREEvision工具在物理架构层是面向整车E/E系统（包括电子电器零部件、线束路由、线束分段、连接器、线束内嵌式连接器等）的安装布置信息的设计，可用于生成线束图(3D信息)，其中的相关属性信息可用于对线束系统的计算评估。 在这一层中，PREEvision支持KBL文件的导入与导出，以实现与线束设计/生产工具的无缝衔接，如Capital Design。 模型开发要点： 1、需要分别在两个图中实现物理拓扑（三维数据布置）的设计和接插件的设计； 2、需要把硬件层的部件与安装位置的部件进行映射； 3、线束原理图（硬件层）、线束图及布置图的设计对专业要求较高，因此，建模人员尽量以线束设计人员为主。 图16 物理架构模型（图片来源：Vector） 7 映射（Mapping） PREEvision提供了电子电气系统设计的上下游关联关系的功能，涵盖了从需求层到最后的物理架构层的全部模块内容，主要用于保证设计的一致性和可追溯性，在应用PREEvision工具进行架构开发时，应尽可能的定义好上下游的映射关系。 相应的，可以在每个模型元素（artifact）的属性中Mapping下查阅与其相关的全部映射关系，也可以在mapping view的模式下查阅全局的映射关系。 同时模型的一致性检查功能也可以实现对模型的检索，以提供未实现映射的内容。 8 信号路由(Signal Routing)/线束路由(WH Routing) 系统逻辑架构/软件架构描述并提供了通信需求，硬件架构描述了ECU网络。逻辑架构或软件架构到硬件层（部件网络）的ECU映射完成后，相关的数据信息传递链就清晰了，继而系统信号也相应的产生了。 信号路由支持以下功能： 1、单独的算法支持计算信号最佳路由路径 2、用户自定义的权重函数进行路由成本的计算 3、网关自动路由支持 4、总线信号的实例化（信号传输） 5、路由结果分析 图17 线信号路由设计流程（图片来源：Vector） PREEvision的线束路由提供了一种自动化机制，该机制将部件原理层的原理图连接嵌入到车辆的物理结构中，从而生成及调整线束，使其完全适合基础车辆物理结构，继而将部件和连接关系映射到车辆物理结构中的实际物理位置，形成物理架构，以及包含的物理参数信息。最终生成线束图及关键设计参数。 写在最后： PREEvision 可以说集成了完整的汽车电子电气开发流程各环节的设计与管理工具链，功能十分强大，同时随着我们对此工具应用的逐步深入，也将在建模过程中发现更多的需要标准化操作与注意事项的建模要点。此外 Vector 中国的 Ready to Use 方案也很贴近本土客户使用习惯 ， 将 来PREEvision工具在模型敏捷开发中将带来更好的用户体验。 PREEvision是德国Vector公司的一款面向汽车电子电气架构设计、开发及管理的专业工具，被OEM和零部件系统供应商的架构工程师、系统工程师、软件工程师等广泛使用。 北汇信息作为Vector中国的合作伙伴，不仅提供相应的工具和技术支持服务及培训， 还 针对不同的应用提供相应的解决方案，助力中国客户的研发效率提升，后续还会为大家带来进一步的案例介绍。 参考文档 1， PREEvisionManual 2， 文中部分图片来自于Vector