【行业资讯】面向下一代电子电气架构进行基于模型的车辆功能开发
一方面，一些长期存在的束缚（如车内有限的计算能力）将被解除；另一方面，AUTOSAR Adaptive和Automotive-Over-The-Air的连通性能够带来全新功能与服务，例如软件升级、软件更新和远程诊断功能。
本文将重点介绍系统与功能开发中的相关角色以及开发过程。未来会涉及到哪些设计角色？哪些基于模型的方法最适合用来描述系统和功能的具体要求？对于系统开发、功能开发及软件开发，如何创建一套具有面向未来的前瞻性开发流程？什么会变，什么不会变？在必要的开发工具的相关需求背后，蕴藏着什么含义？
现代电子电气架构
当前电子电气架构在四个层次中的典型布局如图1所示：
最底层包含传感器/执行器ECU，以及传感器和执行器。未来，AUTOSAR Classic也将用于这一层中。这些ECU所管理的传感器和执行器在整个车辆中有着广泛的物理安装分布，可实现一些与开环/闭环控制、监视及诊断相关的简单功能。
第二层中包含域控制器。AUTOSAR Classic和AUTOSAR Adaptive均在该层得到使用。这些域控制器为下层的传感器/执行器ECU提供更高级的集成功能，通过CAN/CAN FD、LIN等成熟可靠的总线技术连通起来。集成的范围可通过一种功能导向型的方式来定义，如果目标是最大限度控制线束成本，也可将安装空间作为关注重点。
第三层由高性能计算机组成，主要使用AUTOSAR Adaptive，并有AUTOSAR Classic提供支持，即使出现故障也能正常运行，同时还有Linux或其它操作系统。域控制器通过以太网实现互联。
高性能计算机通过互联设备与第四层连接，包括IT后端的服务器以及移动端设备。高性能计算机往往含有一组微处理器和微控制器，如图2所示。在微处理器上，采用Hypervisor作为各种虚拟机的主机，同时也可作为虚拟交换机。每个虚拟机上都可以使用一种不同的操作系统（本例中为AUTOSAR Adaptive和Android系统）。微控制器上一般使用AUTOSAR Classic。
产品线中车辆功能特性模型
电子电气架构为车辆功能的设计提供框架。如前文所述，先确定产品线方法，然后进行开发设计。开发对象是一个系统或一项功能，但其并非仅仅用于一台车辆，而是面向涵盖诸多不同动力系统、车身和设备选项的整个平台车型。开发系统和功能时，首先要定义该产品线的车辆功能特性，并收集必要的变型。这项工作可以在一个列表中完成，但如果能使用功能特性模型则更加理想。
在AUTOSAR中，一项功能特性集合与其子功能特性之间存在四种不同的逻辑分解关系：
强制（Must Use）；
可替代（Requires Xor）；
多个（Requires Or）；
可选（Optional）。
此外，在构成集合树中任何功能特性之间还可使用排除（exclude）和必备（require）逻辑关系。战略性产品规划负责创建一些用于设定电子电气架构关键需求的功能特性模型。
分布式网络系统的功能开发
系统和功能开发是在指定的功能特性模型框架内以及相关车辆产品线的电子电气架构内执行。对于基于需求的系统规范说明而言，基于模型的功能关系规范说明可成为有益补充，近年来一直很受欢迎。这种方式自始至终（从相关传感器到实际功能和必要的执行器）都以客户功能为中心。
在战略逻辑层面采用框图方式进行描述，很大程度上摆脱了对后续软件和硬件实现情况的依赖。尽管硬件和软件实现会受到汽车换代周期的影响，但对于许多功能而言，逻辑架构的稳定性几乎可以维持数代之久，其中很多功能分布整个ECU网络中。其原因是多方面的，且有很多优点，以下列举一二：
同样的传感器和/或执行器可用于多种不同功能； 通过硬件冗余实现功能安全； 几何布局可覆盖车内间隔较远的传感器和执行器，
而且线束成本可通过分布式实现得到降低。
一个简单的逻辑架构涉及X和Y两个车辆功能特性（图4）：功能特性X通过3个块（传感器功能1、功能1和执行器功能1）的因果链实现；功能特性Y通过9个块实现。两个功能特性之间存在重叠部分。在组织上，这些块被分配给A和B两个系统，且其分配具有唯一性。
为确保逻辑架构后续在软件实现中的通用性，逻辑功能的接口按照AUTOSAR标准定义。AUTOSARClassic和AUTOSAR Adaptive均被使用。此外，系统设计中还必须考虑到被视为“车外”部分（即车外的IT后端）的功能性内容。功能6即是此种情况：它为车内的功能5提供一项服务，并使用功能5的另一项服务。除实际功能之外，可能还需要定义功能安全设计概念。此外，还必须定义功能诊断与信息安全设计概念。最后，必须将各功能模块映射到相关的传感器、执行器、ECU和计算节点，从而形成系统组件矩阵。
信号导向与服务导向
AUTOSAR Classic的信号导向式设计适用于CAN/CAN FD和LIN等传统总线（涉及发送器接收器接口、数据元素、信号、PDU、帧等）。在以太网网络中，服务导向式设计提供另一种设计角度，在AUTOSAR Classic和AUTOSAR Adaptive中都可能会用到。在此情况下有一件重要的任务，即定义服务接口（方法、属性和事件）。在AUTOSAR Adaptive中，软件架构包含此用途的服务提供者端口和服务使用者端口。
在AUTOSAR Classic中，有一个服务端口被作为一个端口包来建模，包含发送器、接收器、客户端和服务器端口。对于跨平台软件关系，也可通过正确的端口适配器来建模（图5）。
从软件平台提取的SOA（服务导向式架构）示意图可用于定义各项服务之间的相互作用。与对应不同逻辑功能块的各种参与者一道，描述因Service Discovery（服务发现）而可能出现的各种场景，以及备选服务提供者及其它服务使用者。此外还可在此描述一个层次架构中允许的服务依赖关系以及服务分类（图6）。作为一个常用功能，可以使用符合统一建模语言（UML）的类图进行软件规范说明。
结论与展望
系统开发者负责功能规范说明，定义功能变型，向车内和后端的各ECU及计算节点分配功能模块，创建功能安全、诊断和安全设计概念。基于模型的逻辑架构功能规范具有多方面优点：与软件架构师及开发人员一道调节功能组件，并与通信专家共同调节通信需求。必要的功能变型来自于较高层级的功能特性模型。如今，电子电气架构设计拥有更大的空间：在传感器-执行器、ECU和域控制器方面，电子电器架构包含车内信号导向式软件架构。随之而来的是车辆域控制器和高性能计算平台以及IT后端中的服务导向式软件架构（图7）。
AUTOSAR Classic、AUTOSAR Adaptive以及其它软件平台并行使用。车内的服务导向式软件架构通过AUTOSAR Classic和AUTOSAR Adaptive实现。因此，SOA层级上的抽象建模如同AUTOSAR Classic与AUTOSAR Adaptive软件组件整合一样不可或缺。在系统设计早期阶段，需要认真地权衡各种软件平台的优势和局限。例如，只有和必要的功能安全与信息安全设计概念相结合，方可通过AUTOSAR Adaptive进行软件无线升级和更新的相关新功能。
当车辆异常情况的应对得到充分考虑和实现，方可利用IT后端功能整合所带来的机会。即使网络出现故障，也能保障总体功能的正确。系统和功能开发现在是，并且以后仍将是，整车开发过程中最具创造性和复杂性的任务之一。只有当系统和功能关系得到精确收集并且对于所有参与者都是透明的，才能取得成功并保持前瞻性。
从上面例子中可以得出，只有通过基于模型的方法才能实现这一点，而基于文本的规范说明是无法做到的。在上诉需求的驱动下以及AUTOSAR的启发下，PREEvision作为电子电气系统开发环境提供一个多用户协同平台并支持所描述的建模概念：对电子电气架构、功能特性模型、系统、功能、服务、软件模块和硬件模块进行说明。
PREEvision还为相关应用领域提供普遍的一致性开发环境，包括需求与测试规范说明以及通信设计和线束设计。最后，从整车范围的模型层级上看，PREEvision允许整车厂自动生成一致的零部件规范说明，并生成供应商所需的文件以及相关交换格式（如ReqIF和AUTOSAR）。
原文刊载于2 0 2 0 年第2 期《汽车电子》（Elektronik automotive）杂志（2020年2月）