开通VIP，畅享免费电子书等14项超值服
首页
好书
留言交流
下载APP
联系客服
2024.01.25重庆
国外的OEM在多年的Know-how积累下，其在规划新一代电子电气架构平台时，基本完全按照正向的流程来开发，例如VW的MEBE3架构，Volvo的SPA2等，伴随其正向电子电气架构开发的需要，诞生了强大的工具供应商，比如Vector的PREEvision，其囊括了电子电气开发的整个流程，从需求分析、逻辑功能架构、软件架构、硬件架构到电气原理设计、线束原理设计、几何拓扑设计以及线束2D图纸设计，同时包含通讯设计、功能安全开发、变形管理等，提供了电子电气开发的集成平台，需求工程师、功能工程师、软件工程师，通信工程师、架构工程师、电气工程师、功能安全工程师可以在这个平台彼此协作开发，数据无缝传递，每个专业的输入可通过上游设计的输出数据重构生成，数据可在全流程追溯，在应对目前电子电气的复杂性上确实具有领先性。
下面以PREEvision为例来简单介绍下电子电气架构的正向开发流程是什么样的：
01
需求工程和需求管理
在电子电气架构开发的概念阶段，我们需要明确开发的目标及范围，需要收集客户对车辆的功能需求、法规需求以及其他非功能需求，在这个阶段涉及两个重要的概念：
lCustomerFeature：在高层级描述车辆的特征，通常是客户可以感知的功能，比如自动空调，自动启停，自动泊车、自适应巡航等。
lRequirements:需求Requirement是对CustomerFeature的进一步细化，包括功能需求，技术需求（工作温度范围等），法规需求（排放法规等）；
同时可以将Requirement和CustomerFeature进行映射关联，从而实现追溯，另外CustomerFeature和Requirement在向下映射过程也是有差别的，CustomerFeature通常和逻辑架构层（LogicalFunctionArchitecture）的元素(ActivityChain)进行映射,而Requirement通常和软件架构层（SoftwareArchitecture）的元素以及硬件架构层（HarwareArchitecture）的元素进行映射。
02
逻辑功能架构（LogicalFunctionArchtecture）
逻辑功能架构设计阶段，就是根据需求阶段定义的CustomerFeature，为每一个Feature设计功能的实现逻辑，设计的ActivityChain提供了一个功能的抽象视图，只从功能实现的角度划分Sensor（Input）、LogicalFunction(Process)、Actuator（Output），并不关心具体的软件实现、以及硬件实现，在该阶段设计完成的逻辑组件（LogicalComponent）会分配到硬件架构中的组件（ECU、传感器、执行器等）以及软件架构中组件（ApplicationSoftwareComponent等）。
03
软件架构（SoftwareArchitecture）
在汽车行业嵌入式软件开发领域绕不开AUTOSAR（AutomotiveOpenSystemArchitecture）,其定义了一套分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准方案，AUTOSAR的核心思想“统一标准、分散实现、集成配置”，即提供统一、开放的软件架构标准和平台，软件构建在不同的汽车平台上复用，应用软件整合到ECU中，建立独立于硬件的、分层的软件架构，针对AUTOSARClassic的系统和软件架构设计在PREEvision中可以分为如下步骤：
同时，在目前SDV趋势下，PREEvision同时支持面向服务的架构设计（SOA）以及AdaptiveAutoSAR系统和软架构设计，并提供SOA&EthernetExplorer（ClassicPlatform）和AdaptiveAutoSARExplorer（AdaptivePlatform）支持新的设计需求。
04
硬件架构（HardwareArchitecture）
硬件架构的设计分为三层：硬件组件（Hardwarecomponents）和网络拓扑（Networktopology），电气原理和线束原理。
硬件组件（HardwareComponent）架构，设计硬件组件（例如ECU、传感器、执行器）之间的硬线连接，包括硬线信号（PWM、高低电平等），总线连接（CANFD/CAN/LIN等），以及电源连接和接地连接，另外也设计ECU内部的细节，比如MCU、SBC、RAM等。
网络拓扑（NetworkTopology）
线束原理（WiringHarness）将电气原理数据进行细化，将逻辑连接转换为导线，同时添加导线之间的焊接点（Splice），内部连接器（Inline），端子（Terminal），线束端连接器（FemaleConnector）。
05
几何拓扑（GeometricTopology）
几何拓扑层是整车电器的2.5D布局视图，其可以通过将3DCAD工具（DassaultCatia等）设计完成的3D线束通过KBL格式导入，展平为2D视图，表达各电器的安装位置，线束分段，然后将线束原理层中各组件映射到几何拓扑层，从而进行导线的路由规划，从而为最终的架构评估提供线束的长度、重量等数据支撑。
06
线束设计（HarnessDesign）
将几何拓扑中完成导线路由的线束总成，在WireHarnessDiagram中进行数据重构，同时添加卡扣、胶带以及其他固定件、防护件，可生成线束2D图纸，指导线束供应商进行线束的工艺转化，然后进行线束的生产和制造。
07
通讯设计（Communication）
在完成软件组件到硬件的Mapping后，可进行信号的路由，并进行网络通讯设计，PREEvision提供了多种通信设计编辑器来应对同步的通信类型，比如CANBusEditor,LINSchedulingEditor,FlexRaySchedulling和EthernetExplorer。
上述基于模型的系统工程方法（MBSE）同时可导出文档，作为供应商开发的输入，比如可导出ECU的软件需求规范SWRS（SoftwareRequirementSpecification）用于指导供应商进行软件设计，导出ARXML文件用于供应商生成应用层软件框架代码，生成DBC/LDF文件用于总线仿真及测试等。
国内OEM的电子电气架构开发过程
而国内OEM通常采用基于文档的电子电气架构的开发流程，基于模型的正向开发流程通常很难真正的实施下去的，因为在过去几十年分布式架构下形成的OEM、Tier1的产业供应链是很固化的，目前市面上车型搭载的ECU大部分都是由国外头部Tier1在供应，特别是在底盘、动力领域，ESP、Ibooster、ECM这些零部件的核心Know-how都掌握在Bosch、Continental、APTIV等掌握在这些零部件巨头手里，国内OEM的电子电气架构团队自己的积累太少，并不能在此领域提出足够支配供应商的需求，另外这些供应商开发的零部件基本是平台化的，相同的零件应用在多家主机厂的车型上，收发信号都是定义好OEM根据需求信号进行匹配，因此我们的架构团队写的功能规范（子系统功能规范），迫于无奈要根据零部件实际的功能情况去更改适配，架构输出规范的作用更多的是梳理目前整车已有的功能，而不是去正向设计整车的功能，但是近些年我们国内的OEM也在一直成长，并尝试建立正向的电子电子电气架构开发流程：
通过上述规范的输出，国内OEM掌握的Know-how也越来越多，并在新一代电子电气架构中，逐渐掌握主动权，不管是Domain架构还是Zonal架构，要实现SOA是大家达成的共识，同时在新的面向服务的架构中，主机厂要掌握车端、和云端可以提供的服务，并将服务开放给第三方应用开发者，从而创建SOA的开发生态，因此作为主机厂的电子电气架构团队在新的SOA趋势下，其作用显得越来越重要，其要从整车功能需求来设计整车的服务，并将服务分配到不同的Domain，由不同Domain的应用软件开发团队来实现。
面向服务的电子电气架构开发方法
面向服务的架构SOA（Service-OrientiedArchitecture）是一种软件设计范式，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间良好定义的接口和协议联系起来，接口采用中立的方式进行定义，他独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。
在面向服务持续应用于软件程序设计时，一系列战略目标和优势共同代表了我们所期望实现的目标状态，理解这些目标和优势是非常有益的，因为它们可以为我们提供连续不断的总体背景和理由，以维持我们长期面向服务的投入。
面向服务的设计原则
(1)标准化服务合约原则
面向服务架构体系中，服务通过一个服务合约来表达他们的目标和能力，标准化服务合作设计原则是面向服务中最基本的原则之一，其本质上是在设计一个服务的公开技术接口，或评估作为服务正式合约的一部分而发布的内容特性和数量时，给予特殊考虑指导方法。
服务合约设计时，需要重点考虑服务能力的表达方式、数据类型和数据模型，以及服务策略、服务端点的一致性、可靠性和可治理性。
(2)服务松耦合原则
(3)服务抽象原则
(4)服务可复用性原则
服务可复用性原则强调在无关的功能性上下文环境中，把服务定位为企业的资源，确保服务是无关单个应用和业务流程，具有无关功能性和通用性，可以在无关服务环境中被定义，并且可以保证它们能促进必要的复用环境，可以被多个消费者程序提供访问。
(5)服务自治性原则
(6)服务无状态性原则
就服务而言，管理过多的状态信息会导致服务可用性和伸缩性潜力的破坏，在理想情况下，服务只应该在必要时保持状态。
(7)服务可发现性原则
将服务定位为可服用资产时，若复用机会出现，服务可以被发现并理解。服务发现机制（SOME/IP-SD等）和服务自身的设计（尤其服务端点）都需要将服务的“交流质量”和其自身能力考虑在内。
(8)服务可组合性原则
面向服务的解决方案的复杂程度在持续增长，位于其下的服务组合配置的复杂度也在持续增长，车载领域也面临同样的问题，能够有效组合服务能力是面向服务计算的一些基本目标的关键要求，复杂的服务组合对服务设计提出了要求，服务有望作为有效的组合成员参与，无论他们是否需要立即加入组合。
面向服务的设计方法
在面向服务的架构开发时，分析和设计服务架构的过程是从客户需求到SOA架构产出的分析过程，相对于传统汽车软件开发采用的基于功能分解的面向过程分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。
（1）需求分析
用例（UseCase）驱动的开发方法指从用户的角度而非开发人员的角度考虑功能需求和系统实现，重视从系统外部观察对系统的使用，由用例驱动的开发活动，可建立需求和系统功能之间清晰的追溯关系，更好的应对智能汽车产品需求的快速迭代更新。
（2）功能设计
在功能设计阶段我们用产品能力（ProductCapability）描述功能实现的逻辑，产品能力是连接功能设计和软件设计的桥梁，在功能设计层面，借助UML动态图（序列图、活动图、状态机）运用产品能力PC描述每个UseCase的功能实现链路；在软件架构设计阶段，通过将产品能力分配到不同的软件模块，从而明确各软件模块的职责范围，作为软件开发的输入，同时各软件模块中的服务也根据PC描述的功能范围来设计。
（3）软件架构设计
软件分层
为了更好地管理依赖关系和构建软件架构，应该使用分层软件架构，对于SOA的应用软件架构分层可采用如下原则:
a.分离HMI和核心应用软件
HMI行为比核心应用功能更容易改变，因此，将核心应用软件和HMI之间的分离将使设计更容易更改，特别是在开发期间的后期更改，或在HMI适应新产品时，此外，开发核心应用软件和HMI设计需要不同的的能力技能，分开时应该更容易处理，基本的策略是将HMI功能与其他应用软件（功能）的核心部分分离，为了实现这一点，MVC(Model-View-Controller)模式需要被使用，这意味着核心应用软件不应该意识到任何HMI，而是HMI应该对模型做出反应并呈现给用户，用户输入由Controller处理，Controller解释用户的意图并操作模型。
b.分离传感器/执行器软件和应用软件
将硬件逻辑，例如传感器和执行器逻辑与应用程序逻辑分开，以便能够在中央系统中分配应用程序，同时保持传感器/执行器尽可能的具体，这将促进能够在应用程序之间使用SOA，及时传感器和执行器不支持，更容易将传感器/执行器作为现有组件来采购，从而降低价格；更容易处理中央系统的可变性；将战略软件与中央系统分开，以更好地控制，并在需要时更容易进行内部开发；此策略目的在于提高上层应用软件关键功能的复用性，将依赖硬件的功能与逻辑控制功能分离。
c.分离的设备抽象层
这一层包含了对设备的抽象，即设备代理（DeviceProxy）和设备驱动程序（DeviceDriver）,这里的模块将在需要时，对信号到服务之间进行转换，并处理设备层中的可变性，这一层不应该包含任何车辆功能，只管理设备，在这一层的DeviceDriver不允许直接彼此通信，必须通过DP或车辆控制层，DP和DD可以使用一些平台服务，如日志、诊断等。
d.分离平台服务和主应用软件
与所有系统一样，需要一些更偏向支持的功能，这是所有模块都可以使用的公共服务，如日志记录，资源管理等。
e.应用软件分为多层
即便我们已经将HMI、PlatformService、Sensor/actuator和DeviceAbstraction与核心应用进行分离，针对庞大的核心应用功能的开发，对于开发部门来讲还是很复杂的，为了促进高效的开发工作，这个核心应用功能需要以某种方式进行分割，根据核心应用功能软件特点，公司组织结构等，可根据需要将核心应用功能软件划分为多个层次：
(4)服务设计
a.服务分层
b.服务类型
根据服务提供功能的特点，可以分为基础型服务与功能型服务。
c.服务框架
ServiceFramework是对通用基础软件的扩充，在基于不同种类的操作系统及基础软件平台之上提供系统级服务调用及整车级功能设计视图，其次对AutoSAR的服务管理框架进行扩展，向应用层提供更多基于服务开发需要的功能，最后提供基于引擎的动态服务配置方法，基于预设的静态服务，通过云端对静态服务进行编排，实现更加丰富的业务功能。
d.服务定义
车载SOA软件接口是服务提供者或使用者之间数据交换的定义，它定义了向使用者公开的服务的属性、方法和事件等，服务定义定义服务之间的依赖关系，以及服务的接口（RequireInterfaceProvideInterface）。
(5)物理架构设计
定义整车的网络拓扑以及硬件架构类型（功能域架构、中央计算单元区域架构），综合各家OEM的下一代电子电气架构分析，车载计算单元自动驾驶域控制器智能座舱域控制器区域控制器的架构形态被大多数的OEM所采用。
(6)网络通信设计
可在PREEvision中定义SOME/IP服务矩阵，设计Machine，SWCtoMachineMapping,MachineDeployment,ApplicationDeployment,ServcieInstanceDesign,可导出ServiceInterfaceDescriptionARXML文件，该文件可以包含一个或多个服务接口的详细信息，如Method/Event/Property以及对应的数据类型等内容。该文件可以将服务接口信息准确的传递给其他工具，如DaVinciAdaptiveIDE，用于生成服务接口的头文件。
(7)应用层软件开发
将PREEvision导出的SWCDescriptionARXML文件导入MatLabSimunlink创建模型框架，配置服务发现机制，确认AutoSAR属性，生成代码。
接下来需要利用基础软件供应商提供的开发工具（例如DaVinCiAdaptivetoolSuite）和AP中间件（例如MICROSAR）进行集成、配置，详细的过程我们后续再来探讨。
以上简单的描述了传统电子电气架构的开发过程，以及在新一代SOA架构中，我们采取的以用例驱动的，以服务设计为核心的电子电气架构开发流程，在新的架构中需要探索新的适合每个OEM的开发方法，开发工具链以及与供应商的合作方式（包括芯片供应商、基础软件供应商、零部件供应商等），行业在变革，作为电子电气架构工程师的我们应该直面困难和挫折，寻找一条清晰的发展道路。