作者：窦明佳
一、前言
今天的电子电气架构相对于以往发生了重要变化，首先相对于以往分布式架构中众多计算资源有限的ECU而言，新的架构引入了高性能计算单元HPC，同时车辆不再是封闭的系统，而是整个IoT(物联网)的一部分，另外在车辆软件层面，在传统Classic AutoSAR及其他RTOS系统的基础上，引入了Adaptive AutoSAR平台、Linux、QNX等车载中间件及操作系统，以支持高性能运算，同时在电子电气架构设计层面，在以前面向信号的设计方法基础上同步要进行面向服务SOA的设计，对于OEM功能工程师（Function Designer）和系统工程师（System Developer）提出了新的挑战。二、新一代电子电气架构
- 最低一层包含众多的传感器/执行器ECU，这些ECU在功能层面主要承担车辆的基础逻辑控制，包括闭环控制、故障诊断、运行监测等，在软件层面Classic AutoSAR或其他RTOS被应用在这里；
- 第二层主要是包含集成ECU（域控制器或区域控制器），这些ECU主要承担高一层级的集成功能控制，例如面向功能域的控制器（BDCU、CDC、ADC），或者面向车辆分区的区域控制器（PDC、VIU等）
注：但是我觉得如果不能做到有效的软硬解耦，区域控制器VIU/PDC不做智能配电（eFuse）、不能将车辆众多的传感器（Camera/Radar/Lidar）及执行器（H-Bridge）与中央计算平台进行隔离，不能真正的降低线束的长度、重量及安装空间，并不能发挥Central&Zone方案的价值；- 第三层是高性能计算单元，Adaptive AutoSAR被在这里使用，同时Classic AutoSAR也会存在以满足功能安全Fail-operational场景需求，同时在多核异构芯片上运行Hypervisor以为Adaptive AutoSAR、Linux、Android提供虚拟机。
- 第四层即云平台，包括新能源车法规平台、OTA平台、远程诊断平台、自动驾驶云平台、售后服务平台、客户运营平台等；
而我们通常所说的SOA主要是在第二（Integration Layer）及以上层级实施，采用面向服务的架构设计方式，而在第一（Sensor/Actuator Layer）层级主要采用面向信号的设计方式，那面向信号和面向服务架构设计方法的主要差别在哪里呢？通过上图可以看到面向服务架构在逻辑功能架构（Logical Function Library&Function Architecture）和软件架构层（Software Architect）之间插入了服务架构层（Service Oriented Architecture）,在服务架构层进行服务的抽象、服务划分、服务接口设计、服务编排、服务部署等工作。三、面向信号与面向服务混合架构设计
电子电气架构主要提供了整车功能的开发框架，无论面向信号还是面向服务起点都是Customer Feature，最近几年在电子电气架构领域基于模型的开发方法（MBSE）被大家广泛采用，基于模型用例驱动能够更好跟踪用户需求与最终的技术实现（软件、硬件设计）。采用基于模型的开发虽然各家的开发方法论及工具链细节上存在差异，但是总体的流程基本一致。3.1 用户特征及需求（Customer Feature and Requirements ）这一步是站在用户视角，分析所有相关方对功能的需求，借助于用例（Use Case） 场景（包含基础路径、替代路径、异常路径及行为者、前提条件、后置条件等）分析系统需求，包括：
a)功能需求（Function Requirements）
Ø功能激活条件
Ø激活/关闭/进行中的系统行为
Ø功能激活/关闭的条件
b)非功能需求（Non-Function Requirements）
Ø系统时间及性能需求
Ø法规相关需求
Ø功能安全相关需求
Ø信息安全相关需求
c)平台/跨域需求（Platform/Domain Requirements）
Ø车辆配置需求
Ø人机交互需求
这一步的主要输出物是用例图及用例描述，同时用例和需求要做Mapping，输出FRD（Function Requirements Document）。
3.2 逻辑功能架构(Logical Architecture)
基于上一步的用例及功能需求，我们针对每个Feature（Use Case）进行逻辑功能架构设计，在这一步我们会划分逻辑功能组件LC（Logical Component），LC是一个抽象的组件它独立于具体的硬件和软件实现，同时LC在整个架构平台是一个重要的数据库，应该形成一个LC Library，并且LC的创建、更新由架构工程师（System Architect）来统一负责，功能工程师（Function Designer）在进行逻辑架构设计时向架构工程师（SA）提出LC的需求，同时架构工程师（SA）负责LC向系统的分配。
我们来看一个具体的例子，如下图有两个整车Feature X和Feature Y，Feature X在逻辑功能架构设计时由Sensorfunction1、Function1和ActuatorFunction1 三个LC实现，Feature Y在逻辑功能架构设计时由SensorFunction1、Function1、Function2、SensorFunction2、Function3、Function4、Function5、Function6等9个LC组成；为了保证逻辑功能架构与后面AutoSAR软件架构的继承性，逻辑组件LC的接口设计应遵循AutoSAR的标准，在逻辑功能架构设计阶段，不同的方法论和工具链会有些许的差异，例如PREEvision中我们通常会针对每个Feature创建Activity Chain，另外像BEG等用IBM工具链的厂家会在Rhapsody中创建整车层级、系统层级到逻辑组件层级的泳道图，从而进行功能的细化分解形成LC，最后进行LC的部署，上述逻辑架构图中的每个逻辑组件都将被分配到对应的Sensor、Actuator、ECU或计算单元中，将图7中的逻辑组件分配到图3中的架构层级各节点中，形成的矩阵如下：至此完成功能层面的需求分析及功能设计，可导出FRS（Function Requirement Specification）,上述过程无论是面向信号还是面向服务的架构设计都是必须进行中的，同时上述内容将成为OEM的核心资产。注：上述逻辑功能架构阶段，还有功能安全工程师、信息安全工程师的参与进行功能安全概念（FSC）、信息安全等相关工作；3.3 服务架构(Service Architecture)
上面我们说到SOA主要是在第二（Integration Layer）及以上层级（Computing Layer、IT-Backend Layer and external Devices）实施，采用面向服务的架构设计方式，经过上述LC的部署，我们可以看到Fucntion2、Function4、Function5、Backup Function6和Function6分别被部署到了Integration ECU2、High-Performance Computer1以及Backend Server1上，同时我们经过各方面的评估（实时性、安全性、可扩展性等）认为Function4、Function5、和Function6适合服务化，可将其抽象为服务，并设计Service Interface（Method、Event、Properties）及服务的参与者（Service Provider/Service Consumer）,同时根据逻辑功能架构的设计服务的依赖关系，如下图9：3.4 软件架构(Software Architecture)
在设计完服务Service，并将服务部署到对应的运行环境中，如将Service4部署到Integration ECU2的Classic AutoSAR运行环境，则对应到软件层面Service4 Port将转换为一簇Sender/Receiver/Client/Server Ports端口，并通过SOA Adaptor（S2S）与部署到Adaptive AutoSAR运行环境的Service5、Service6交互，完成服务部署，服务的参数者（Service Provider/Service Consumer）将转换为对应的应用软件组件（Application SWC/Adaptive Application SWC），如下图10为对应Feature Y的软件架构：从上图我们可以看到对应部署在Sensor Actuator ECU1的Fucntion1，部署在Integration ECU2的Fucntion2、以及部署在Sensor Actuator ECU3的Function3等非服务化的逻辑组件LC，其在软件层面会设计对应的Classic AutoSAR Application SW Component,以及S/R Interface及C/S Interface。3.5 通信架构(Communication Architecture)
基于上述过程我们可以导出信号列表和服务列表，导入下游的通信设计工具进行CAN（FD）、LIN、Ethernet的设计，从而输出DBC、LDF、ARXML文件，在此不详细描述。
四、结语
在当前阶段，电气化、智能化、网联化、共享化的需求推动电子电气架构的变革，OEM想在这场变革中掌握主动权，希望更多的软件自主化，从而在软件定义汽车SDV的浪潮中站稳脚跟，另一方面却是过去的开发模式造成在人员、组织架构、知识储备方面的缺失，大多数的企业还是根据自己的情况逐步构建新一代的电子电气架构，在这种情况下怎么将自上而下的正向功能开发与自下而上（继承已有的供应链资源）的开发有效结合是一个挑战，而基于模型的开发可有效的衔接各个开发角色以应对新一代电子电气架构的复杂性。
