SOA架构与传统EEA开发有何区别？

电子电气架构的正向开发流程

国外的OEM在多年的Know-how积累下，其在规划新一代电子电气架构平台时，基本完全按照正向的流程来开发，例如VW的MEB E3架构，Volvo的SPA2等，伴随其正向电子电气架构开发的需要，诞生了强大的工具供应商，比如Vector的PREEvision，其囊括了电子电气开发的整个流程，从需求分析、逻辑功能架构、软件架构、硬件架构到电气原理设计、线束原理设计、几何拓扑设计以及线束2D图纸设计，同时包含通讯设计、功能安全开发、变形管理等，提供了电子电气开发的集成平台，需求工程师、功能工程师、软件工程师，通信工程师、架构工程师、电气工程师、功能安全工程师可以在这个平台彼此协作开发，数据无缝传递，每个专业的输入可通过上游设计的输出数据重构生成，数据可在全流程追溯，在应对目前电子电气的复杂性上确实具有领先性。

下面以PREEvision为例来简单介绍下电子电气架构的正向开发流程是什么样的：

需求工程和需求管理

在电子电气架构开发的概念阶段，我们需要明确开发的目标及范围，需要收集客户对车辆的功能需求、法规需求以及其他非功能需求，在这个阶段涉及两个重要的概念：

lCustomer Feature：在高层级描述车辆的特征，通常是客户可以感知的功能，比如自动空调，自动启停，自动泊车、自适应巡航等。

lRequirements:需求Requirement 是对Customer Feature的进一步细化，包括功能需求，技术需求（工作温度范围等），法规需求（排放法规等）；

同时可以将Requirement和Customer Feature进行映射关联，从而实现追溯，另外Customer Feature和Requirement在向下映射过程也是有差别的，Customer Feature通常和逻辑架构层（Logical Function Architecture）的元素(Activity Chain)进行映射,而Requirement通常和软件架构层（Software Architecture）的元素以及硬件架构层（Harware Architecture）的元素进行映射。

逻辑功能架构（Logical Function Archtecture）

逻辑功能架构设计阶段，就是根据需求阶段定义的Customer Feature，为每一个Feature设计功能的实现逻辑，设计的Activity Chain提供了一个功能的抽象视图，只从功能实现的角度划分Sensor（Input）、Logical Function(Process)、Actuator（Output），并不关心具体的软件实现、以及硬件实现，在该阶段设计完成的逻辑组件（Logical Component）会分配到硬件架构中的组件（ECU、传感器、执行器等）以及软件架构中组件（Application Software Component等）。

软件架构（Software Architecture）

在汽车行业嵌入式软件开发领域绕不开AUTOSAR（Automotive Open System Architecture）,其定义了一套分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准方案，AUTOSAR的核心思想“统一标准、分散实现、集成配置”，即提供统一、开放的软件架构标准和平台，软件构建在不同的汽车平台上复用，应用软件整合到ECU 中，建立独立于硬件的、分层的软件架构，针对AUTOSAR Classic的系统和软件架构设计在PREEvision中可以分为如下步骤：

同时，在目前SDV趋势下，PREEvision同时支持面向服务的架构设计（SOA）以及Adaptive AutoSAR系统和软架构设计，并提供SOA&Ethernet Explorer（Classic Platform）和Adaptive AutoSAR Explorer（Adaptive Platform）支持新的设计需求。

硬件架构（Hardware Architecture）

硬件架构的设计分为三层：硬件组件（Hardware components）和网络拓扑（Network topology），电气原理和线束原理。

硬件组件（Hardware Component）架构，设计硬件组件（例如ECU、传感器、执行器）之间的硬线连接，包括硬线信号（PWM、高低电平等），总线连接（CANFD/CAN/LIN等），以及电源连接和接地连接，另外也设计ECU内部的细节，比如MCU、SBC、RAM等。

网络拓扑（Network Topology）

电气原理（Electric Circuit）,电气原理层将硬件架构层的数据进行重构，重新定义硬件组件之间的连接，并关注与线束设计相关的电气属性，例如电源供应、接地连接等，其可设计电源分配的保险、继电器以及接地分配电路。

线束原理（Wiring Harness）将电气原理数据进行细化，将逻辑连接转换为导线，同时添加导线之间的焊接点（Splice），内部连接器（Inline），端子（Terminal），线束端连接器（Female Connector）。

几何拓扑（Geometric Topology）

几何拓扑层是整车电器的2.5D布局视图，其可以通过将3D CAD工具（Dassault Catia等）设计完成的3D线束通过KBL格式导入，展平为2D视图，表达各电器的安装位置，线束分段，然后将线束原理层中各组件映射到几何拓扑层，从而进行导线的路由规划，从而为最终的架构评估提供线束的长度、重量等数据支撑。

线束设计（Harness Design）

将几何拓扑中完成导线路由的线束总成，在Wire Harness Diagram中进行数据重构，同时添加卡扣、胶带以及其他固定件、防护件，可生成线束2D图纸，指导线束供应商进行线束的工艺转化，然后进行线束的生产和制造。

通讯设计（Communication）

在完成软件组件到硬件的Mapping后，可进行信号的路由，并进行网络通讯设计，PREEvision提供了多种通信设计编辑器来应对同步的通信类型，比如CAN Bus Editor,LIN Scheduling Editor,FlexRay Schedulling 和Ethernet Explorer。

上述基于模型的系统工程方法（MBSE）同时可导出文档，作为供应商开发的输入，比如可导出ECU的软件需求规范SWRS（Software Requirement Specification）用于指导供应商进行软件设计，导出ARXML文件用于供应商生成应用层软件框架代码，生成DBC/LDF文件用于总线仿真及测试等。

国内OEM的电子电气架构开发过程

而国内OEM通常采用基于文档的电子电气架构的开发流程，基于模型的正向开发流程通常很难真正的实施下去的，因为在过去几十年分布式架构下形成的OEM、Tier1的产业供应链是很固化的，目前市面上车型搭载的ECU大部分都是由国外头部Tier1在供应，特别是在底盘、动力领域，ESP、Ibooster、ECM这些零部件的核心Know-how都掌握在Bosch、Continental、APTIV等掌握在这些零部件巨头手里，国内OEM的电子电气架构团队自己的积累太少，并不能在此领域提出足够支配供应商的需求，另外这些供应商开发的零部件基本是平台化的，相同的零件应用在多家主机厂的车型上，收发信号都是定义好OEM根据需求信号进行匹配，因此我们的架构团队写的功能规范（子系统功能规范），迫于无奈要根据零部件实际的功能情况去更改适配，架构输出规范的作用更多的是梳理目前整车已有的功能，而不是去正向设计整车的功能，但是近些年我们国内的OEM也在一直成长，并尝试建立正向的电子电子电气架构开发流程：

在需求阶段进行市场调研、法规标准分析、竞品分析、新技术分析、基础平台分析，定义整车架构目标，输出Function List，并针对每个功能编制功能需求规范FRS（Function Requirement Spefication）,进行功能描述，场景定义，功能系统框图设计等；
在功能实现阶段，把功能需求分解并分配给子系统设计团队（功能需求+子系统交互图）；
在子系统设计阶段，输出子系统需求描述SRD（System Requirement Description）；
在零部件设计阶段输出零部件技术规范CTS（Component Technical Spefication）。

通过上述规范的输出，国内OEM掌握的Know-how也越来越多，并在新一代电子电气架构中，逐渐掌握主动权，不管是Domain架构还是Zonal架构，要实现SOA是大家达成的共识，同时在新的面向服务的架构中，主机厂要掌握车端、和云端可以提供的服务，并将服务开放给第三方应用开发者，从而创建SOA的开发生态，因此作为主机厂的电子电气架构团队在新的SOA趋势下，其作用显得越来越重要，其要从整车功能需求来设计整车的服务，并将服务分配到不同的Domain，由不同Domain的应用软件开发团队来实现。

面向服务的电子电气架构开发方法

面向服务的架构SOA（Service-Orientied Architecture）是一种软件设计范式，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间良好定义的接口和协议联系起来，接口采用中立的方式进行定义，他独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。

设计范式是设计解决方案逻辑的一种方法，在构建分布式解决方案逻辑时，设计方法通过一种称为“关注点分离”的软件工程理论实现，简而言之，这个理论说明，将更大的问题分解为一组较小的问题或关注点时，这个问题就能得到更有效的解决，这让我们产生了将解决方案逻辑划分为多个功能的想法，每个功能都旨在解决单一的关注点，相关功能可以分组为解决方案逻辑单元。分布式解决方案逻辑存在不同的设计范式，面向服务体现在：面向服务执行关注点分离的方式以及如何塑造具有特定特性和支持特定目标状态解决方案逻辑的单个单元。从根本上说，面向服务将合适的解决方案逻辑单元整合为企业资源，其可以被设计为解决即时问题，同时对更大的问题保持不可知，这就为我们提供了不断的机会来重新利用那些单元内的功能并解决其他问题。

在面向服务持续应用于软件程序设计时，一系列战略目标和优势共同代表了我们所期望实现的目标状态，理解这些目标和优势是非常有益的，因为它们可以为我们提供连续不断的总体背景和理由，以维持我们长期面向服务的投入。

增加本征互操作性:即增加数据共享，软件程序的互操作性越高，其之间的信息交换越容易；
增强联合:即服务的联合，软件资源和应用程序联合在一起，同时保持其各自的自主性和自治性；
增加供应商的多元化选择：即供应商多元化能力，指组织必须选择“最佳品种”的供应商产品和技术创新；
同步提升业务与技术领域：即应用程序的设计和实现不仅要满足初始业务需求，也应满足未来随业务性质和方向变化时的也业务需求；
提高投资回报率：即衡量自动化解决方案投资回报率（ROI）是决定应用程序或系统实际成本效益的关键因素；
提高组织的业务敏捷性：即组织能够对变化做出反应的效率，以适应行业变化并超越竞争对手；
减少研发成本：即减少浪费和冗余，缩小规模和运营成本，减少与其治理和演进相关开销等。

面向服务的设计原则

(1)标准化服务合约原则

面向服务架构体系中，服务通过一个服务合约来表达他们的目标和能力，标准化服务合作设计原则是面向服务中最基本的原则之一，其本质上是在设计一个服务的公开技术接口，或评估作为服务正式合约的一部分而发布的内容特性和数量时，给予特殊考虑指导方法。

服务合约设计时，需要重点考虑服务能力的表达方式、数据类型和数据模型，以及服务策略、服务端点的一致性、可靠性和可治理性。

(2)服务松耦合原则

耦合是指两个事务之间的关联和联系，这一原则主张在服务的边界之内和之外创建特定类型的关系时，要始终强调减少服务合约、服务实现和服务消费者之间的依赖关系（车载领域尤其需要关注感知、决策和执行的耦合关系），在服务设计过程中存在各种数据类型的耦合关系，每一个都会影响合约的内容和粒度，需要依靠原则指导和实际经验获得一个适当的耦合级别。

(3)服务抽象原则

这个原则强调尽量隐藏服务的更多细节，服务需要一致地抽象关于技术、逻辑和功能的相关信息，不会展现给外部世界（服务逻辑开发上之外的世界），届时，服务合约需要抽象仅仅包含服务不要对外发布公开的信息，如必要的交互需求、约束和必须的服务元数据。

(4)服务可复用性原则

服务可复用性原则强调在无关的功能性上下文环境中，把服务定位为企业的资源，确保服务是无关单个应用和业务流程，具有无关功能性和通用性，可以在无关服务环境中被定义，并且可以保证它们能促进必要的复用环境，可以被多个消费者程序提供访问。

(5)服务自治性原则

为了让服务能够持续可靠地提供服务能力，底层的方案逻辑要求对环境和资源进行相当程度的控制，这一原则涉及服务逻辑设计及服务实际实施环境的各类问题，合理利用可以增加服务的可靠性和行为的可预测性的设计特性，可以对其他设计原则在实际开发过程中的有效应用提供足够的支持。在车载领域，由于涉及不同安全等级和实时性要求，尤其要关注隔离级别和服务规范化，针对不同应用领域一起可以达到各自适合程度的自治，对于经常需要共享的可复用服务来说尤其重要。

(6)服务无状态性原则

就服务而言，管理过多的状态信息会导致服务可用性和伸缩性潜力的破坏，在理想情况下，服务只应该在必要时保持状态。

(7)服务可发现性原则

将服务定位为可服用资产时，若复用机会出现，服务可以被发现并理解。服务发现机制（SOME/IP-SD等）和服务自身的设计（尤其服务端点）都需要将服务的“交流质量”和其自身能力考虑在内。

(8)服务可组合性原则

面向服务的解决方案的复杂程度在持续增长，位于其下的服务组合配置的复杂度也在持续增长，车载领域也面临同样的问题，能够有效组合服务能力是面向服务计算的一些基本目标的关键要求，复杂的服务组合对服务设计提出了要求，服务有望作为有效的组合成员参与，无论他们是否需要立即加入组合。

面向服务的设计方法

在面向服务的架构开发时，分析和设计服务架构的过程是从客户需求到SOA架构产出的分析过程，相对于传统汽车软件开发采用的基于功能分解的面向过程分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。

（1）需求分析

用例（Use Case）驱动的开发方法指从用户的角度而非开发人员的角度考虑功能需求和系统实现，重视从系统外部观察对系统的使用，由用例驱动的开发活动，可建立需求和系统功能之间清晰的追溯关系，更好的应对智能汽车产品需求的快速迭代更新。

（2）功能设计

在功能设计阶段我们用产品能力（Product Capability）描述功能实现的逻辑，产品能力是连接功能设计和软件设计的桥梁，在功能设计层面，借助UML动态图（序列图、活动图、状态机）运用产品能力PC描述每个UseCase的功能实现链路；在软件架构设计阶段，通过将产品能力分配到不同的软件模块，从而明确各软件模块的职责范围，作为软件开发的输入，同时各软件模块中的服务也根据PC描述的功能范围来设计。

（3）软件架构设计

软件分层

为了更好地管理依赖关系和构建软件架构，应该使用分层软件架构，对于SOA的应用软件架构分层可采用如下原则:

a.分离HMI和核心应用软件

HMI行为比核心应用功能更容易改变，因此，将核心应用软件和HMI之间的分离将使设计更容易更改，特别是在开发期间的后期更改，或在HMI适应新产品时，此外，开发核心应用软件和HMI设计需要不同的的能力技能，分开时应该更容易处理，基本的策略是将HMI功能与其他应用软件（功能）的核心部分分离，为了实现这一点，MVC(Model-View-Controller)模式需要被使用，这意味着核心应用软件不应该意识到任何HMI，而是HMI应该对模型做出反应并呈现给用户，用户输入由Controller处理，Controller解释用户的意图并操作模型。

b.分离传感器/执行器软件和应用软件

将硬件逻辑，例如传感器和执行器逻辑与应用程序逻辑分开，以便能够在中央系统中分配应用程序，同时保持传感器/执行器尽可能的具体，这将促进能够在应用程序之间使用SOA，及时传感器和执行器不支持，更容易将传感器/执行器作为现有组件来采购，从而降低价格；更容易处理中央系统的可变性；将战略软件与中央系统分开，以更好地控制，并在需要时更容易进行内部开发；此策略目的在于提高上层应用软件关键功能的复用性，将依赖硬件的功能与逻辑控制功能分离。

c.分离的设备抽象层

这一层包含了对设备的抽象，即设备代理（Device Proxy）和设备驱动程序（Device Driver）,这里的模块将在需要时，对信号到服务之间进行转换，并处理设备层中的可变性，这一层不应该包含任何车辆功能，只管理设备，在这一层的Device Driver不允许直接彼此通信，必须通过DP或车辆控制层，DP和DD可以使用一些平台服务，如日志、诊断等。

d.分离平台服务和主应用软件

与所有系统一样，需要一些更偏向支持的功能，这是所有模块都可以使用的公共服务，如日志记录，资源管理等。

e.应用软件分为多层

即便我们已经将HMI 、Platform Service、Sensor/actuator和Device Abstraction与核心应用进行分离，针对庞大的核心应用功能的开发，对于开发部门来讲还是很复杂的，为了促进高效的开发工作，这个核心应用功能需要以某种方式进行分割，根据核心应用功能软件特点，公司组织结构等，可根据需要将核心应用功能软件划分为多个层次：

车辆应用层：这一层包含的软件部件，对本车应用负有总体责任，例如如何使用各种能源策略的定义，他们更像是应用程序类型的SWC，使用其他层中的服务，而不向其他层提供服务接口；
车辆协调层：这一层包含协调特定范围内（Domain内）功能的软件部件，例如协调不同类型的电气能量的使用；
车辆控制层：这一层包含控制功能范围更有限的软件部件，例如门窗控制，门锁控制等，除分层外，核心应用功能，或部分的核心应用功能也可以根据开发组织进行分离，例如：Connectivity，Energy,Motion，Control,Safety,Body和Infotainment，不同的企业可以采用不同的定义方案。

(4)服务设计

a.服务分层

硬件抽象服务：基于ECUs功能和硬件外围设备（传感器/执行器），定义硬件抽象服务，这些服务应该在软件平台级别提供。
平台核心服务：所有跨应用程序集群和域的公共服务都需要在软件平台级别定义和提供；
域核心服务：在一个应用集群中，跨不同应用程序的公共服务应定义为域核心服务，
应用程序服务：特定于系统的每个应用程序或功能的服务，需要定义为应用程序服务；

b.服务类型

根据服务提供功能的特点，可以分为基础型服务与功能型服务。

基础型服务：提供与业务无关的通用系统服务能力，包括操作系统、基础软件、通用中间件提供的功能；
功能型服务，提供具体业务功能相关的服务，包括与域控相关的专用中间件、应用层提供的功能。

c.服务框架

Service Framework是对通用基础软件的扩充，在基于不同种类的操作系统及基础软件平台之上提供系统级服务调用及整车级功能设计视图，其次对AutoSAR的服务管理框架进行扩展，向应用层提供更多基于服务开发需要的功能，最后提供基于引擎的动态服务配置方法，基于预设的静态服务，通过云端对静态服务进行编排，实现更加丰富的业务功能。

原子服务：不可拆分的服务，一般为执行单一操作的功能，不同功能节点可以提供针对业务的原子服务；
SOA+：基于AutoSAR的服务框架扩展，向应用层提供更多基于服务开发需要的功能，其中包括服务转换、服务调试、服务同步、服务权限管理和基于Andorid的SOA协议栈；
系统基础服务：系统可以提供的基础服务，体现该系统可以提供的能力，需要依赖通用基础软件提供的功能，可以通过API或服务的形式提供给上层，针对不同异构系统分别提供软件包；
整车级系统基础服务：整车角度需要多个控制器协同实现的功能
动态服务：基于原子服务及系统服务提供的功能进行组合，实现服务的级联，包括动态服务配置接口：提供给调用者实现动态服务的可配置接口；动态服务引擎，根据配置接口的输入，执行动态服务的核心功能。

d.服务定义

车载SOA软件接口是服务提供者或使用者之间数据交换的定义，它定义了向使用者公开的服务的属性、方法和事件等，服务定义定义服务之间的依赖关系，以及服务的接口（Require Interface Provide Interface）。

(5)物理架构设计

定义整车的网络拓扑以及硬件架构类型（功能域架构、中央计算单元+区域架构），综合各家OEM的下一代电子电气架构分析，车载计算单元+自动驾驶域控制器+智能座舱域控制器+区域控制器的架构形态被大多数的OEM所采用。

(6)网络通信设计

可在PREEvision中定义SOME/IP服务矩阵，设计Machine，SWC to Machine Mapping, Machine Deployment,Application Deployment,Servcie Instance Design,可导出Service Interface Description ARXML文件，该文件可以包含一个或多个服务接口的详细信息，如Method/Event/Property以及对应的数据类型等内容。该文件可以将服务接口信息准确的传递给其他工具，如DaVinci Adaptive IDE，用于生成服务接口的头文件。

同时可导出Execution Manifest包含了Adaptive Application部署到目标AUTOSAR Adaptive平台上所需的信息，比如进程启动配置，进程与Machine的映射等内容，导出Machine Manifest包含Machine部署相关的信息，比如网络配置信息，计算资源等，导出Service Instance Manifest包含基于服务的通信相关信息，如应用层及相应的传输层、网络层通信参数信息。

(7)应用层软件开发

将PREEvision导出的SWC Description ARXML文件导入MatLab Simunlink 创建模型框架，配置服务发现机制，确认AutoSAR属性，生成代码。

接下来需要利用基础软件供应商提供的开发工具（例如DaVinCi Adaptive tool Suite）和AP中间件（例如MICROSAR）进行集成、配置，详细的过程我们后续再来探讨。

以上简单的描述了传统电子电气架构的开发过程，以及在新一代SOA架构中，我们采取的以用例驱动的，以服务设计为核心的电子电气架构开发流程，在新的架构中需要探索新的适合每个OEM的开发方法，开发工具链以及与供应商的合作方式（包括芯片供应商、基础软件供应商、零部件供应商等），行业在变革，作为电子电气架构工程师的我们应该直面困难和挫折，寻找一条清晰的发展道路。

原创文章，作者：guozi，如若转载，请注明出处：https://www.sudun.com/ask/90479.html

SOA架构与传统EEA开发有何区别？

相关推荐

网站被攻击了怎么办，网站被攻击能报案吗

网站可以屏蔽用户吗，网站会屏蔽某些ip地址吗

CMS选择

如何使用IFS命令来解析字符串？

发表回复