詹德凯，高 越

基于PREEvision的SOA设计

詹德凯1，高 越2

（1.辽宁省交通高等专科学校 智能网联协同创新中心，辽宁 沈阳 110122；2.沈阳东信创智科技有限公司，辽宁 沈阳 110111）

随着汽车新“四化”的深入发展，电子电气系统越来越复杂，电子电气架构革新和拓展势在必行。汽车面向服务的架构（SOA）、基于模型的开发方式（MBD）、AutoSAR和以太网等已成为电子电气架构的发展趋势。文章通过阐述基于PREEvision工具实现服务及接口定义、软件架构、网络拓扑、服务部署、以太网通讯、以太网SoAd模块和SOMEIP序列化等设计，实现面向服务的架构开发，通过建模之后导出ARXML文件完成输出。开发过程符合模型的开发方式和AutoSAR的技术要求。促进了软件定义汽车的实现，形成并完善了新的电子电气架构平台。

面向服务的架构（SOA）；PREEvision；基于模型的开发（MBD）；AutoSAR；SOMEIP；以太网

电子电气架构是支持智能网联汽车发展的基础技术，体现了整车电气系统集成能力[1]。随着智能互联、自动驾驶、电动汽车及共享出行的发展，软件、计算能力和先进传感器正逐渐取代发动机的统治地位。差异化（或独特性）将不再仅仅停留于传统的车辆硬件方面，而更多地通过由软件和先进电子技术赋能的用户交互界面和体验层面来体现[2]。未来汽车电子电气架构的发展方向是集成化越来越高的域控制器架构或者中央计算单元的环形网络架构，以高速率以太网作为骨干网，支持基于模型的开发方式（Model Based Design, MBD），支持软件架构标准AutoSAR, 支持面向服务的架构（Service-oriented Architecture, SOA）[3]。本文将介绍如何基于PREEvision工具进行SOA模型创建，该模型符合经典的自动恒星平台（Classic AutoSAR Platform, CP）的要求，绑定的是以太网中间件协议SOMEIP。

1 概念介绍

1.1 AutoSAR

AutoSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（Electr- onic Control Unit, ECU）标准软件架构。由此提升原始设备制造商Original Equipment Manufacturer, OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理[4]。

为此，AutoSAR做了以下三件事情：

第一，对应用软件与底层软件之间以及应用软件之间的接口进行标准化。

第二，给出一个控制器软件参考架构。

第三，规范分布式开发流程中的交换格式。

当前AutoSAR包含两个平台，Classic AutoSARPlatform（CP）和Adaptive AutoSAR Platform（AP）。

1.2 SOA

SOA，全称为Service-Oriented Architecture，是一种架构风格，也是一种软件架构开发方法，其特点是拥有标准的服务接口，服务和服务之间是松耦合的，具有灵活性。可扩展性和互操作性，而这些特性恰恰是软件定义汽车必不可少的[5]。某个功能或系统由一组服务组成，并且其中的总服务包可以依次使用其他的多个子服务，面向服务的架构SOA的出现可以打破车内静态交互模型，并且建立功能灵活治理的系统架构。确保新增功能的实现可以与车辆原有的系统架构、驱动方式、通信方式相匹配[6-7]。

1.3 SOMEIP

SOMEIP，全称为Scalable service-Oriented Middleware over IP，是AutoSAR组织针对汽车领域应用制定的一组中间件框架。以Server-Client服务形式进行通信，为应用层协议运行于车载以太网OSI模型四层以上，作为以太网通信中间件来实现应用层和IP层的数据交互，其不依赖于操作系统，兼容AutoSAR和非AutoSAR平台[8]。主要包含了RPC协议；服务相关的查找申请订阅停止等相关服务（Service Discovery）；数据序列化的定义（SOME/IP Transformer）等三部分内容。

1.4 PREEvision

PREEvision 是一款自上而下（Top-Down）用于实现电子电气架构设计构想的计算机辅助设计软件工具[9]。其核心技术就是基于模型的开发，符合AutoSAR标准，实现了层与层之间相互渗透和数据的可追溯性。它的功能包括需求开发、逻辑功能设计、网络和部件架构等[10]。

2 基于PREEvision的SOA设计

面向服务的架构（SOA）在汽车电子领域的实现方法，是采用 AutoSAR 的方案，基于模型MBD的开发方法实现的。基于Vector架构开发工具PREEvision进行SOA建模，完全符合AutoSAR的要求。图1是PREEvision工具推荐的SOA建模工作流程，主要包括服务及服务接口定义、软件架构设计、网络拓扑设计、服务部署、以太网通信设计、以太网SoAd的设计、SOMEIP序列化、SOMEIP SD、导出ARXML。

图1 SOA建模工作流程

2.1 服务及服务接口设计

服务及服务接口设计主要包括定义服务、定义服务的标准接口、绑定网络通讯协议和定义数据类型。

2.1.1定义服务

定义服务内容就是搭建一个系统功能架构，从整车层面按照功能需求定义并划分服务。服务有两个角色，服务的提供者（service provider）和服务的消费者（service consumer）。服务的提供者和服务的消费者之间是关联关系（useage）。如图2所示，定义一个服务SpeedLimiter。服务提供者为SpeedLimiter_sp，服务的消费者为SpeedLimi- ter_sc。

图2 SpeedLimiter服务定义

2.1.2定义服务接口

服务以标准化的接口提供功能，服务接口是一种通信内容定义，其目的在于将服务从功能架构过渡到软件技术架构, 软件模块之间的关系需被清晰地定义出来，将服务内容封装成相应的接口被实际调用。服务接口可分为方法（Method）、属性（Property）、事件（Event）三种类型。Method包含了请求后有应答的Method（Request&Res- ponse）和请求后没有应答的Method（Fire&For- get）。Property表示Getter/Setter/Notifier某种属性或者状态。Event表示某种事情发生后，服务端向客户端发送的Message。

如图3所示，SpeedLimiter这个服务，包含一个VehicleSpeed的Method（request&response）, 一个speedLimitSet的Property（此属性支持getter, setter和notifier），一个speedLimitStatus的Event。

图3 SpeedLimiter服务接口定义

2.1.3绑定SOMEIP协议

服务及服务接口定义完成之后，需要绑定网络通讯协议，可以绑定DDS、SOMEIP、或者用户自定义的协议，这里绑定专门针对汽车领域SOA设计的轻量化的SOMEIP协议。服务SpeedLimiter需要定义SOMEIP协议的相关参数如下：

Interface ID：同Service ID 的0x1001；

Major version：主版本号定义为1；

Minor version：副版本号定义为0；

Method/Event ID：两个byte数据，最高位是0代表method，最高位是1代表event；

Event Group：用来进行publish/subscribe处理Events和Fields（Notifier）的通信的逻辑组。每个Events或者Fields（Notifier）至少存在于一个Event Group中。同时需要为每个Event Group定义ID。本示例中的一个event和一个notifier同时属于一个Event Group：speedLimiter_EG，Event Group ID为0x01。

2.1.4定义数据类型

AutoSAR按照不同的抽象级别，定义了对数据进行描述的三个不同的层次[11]，分别如下：

应用数据类型（Application Data Type, ADT）：从应用逻辑的角度描述数据，体现该数据在现实中的物理语义、物理取值范围、物理单位等。在ADT中通常会关联一个计算公式（Computation Method, CM），描述数据从物理（值）范围到内部数字（位）级别的转换关系。一般地，在功能定义的过程中，我们会使用ADT的方式对数据进行描述。

实现数据类型（Implementation Data Type, IDT）：从代码实现的角度描述数据，尽管IDT仍是一层抽象概念，但可近似认为IDT为从实际代码实现（如C语言）的角度，对数据类型的定义。

基本类型（Base Type）：从Bit或Byte的角度描述底层平台（Platform）支持的原生类型，这些原生类型最终构建了IDT的实现。

完整的AutoSAR数据类型定义包含ADT、IDT和Base Type，且ADT和IDT之间需要定义映射关系，IDT和Base Type之间需要定义关联关系。

图4是服务speedLimiter定义的数据类型，其中关于vehicleSpeed Method定义了四个输入参数和一个输出参数。

图4 数据类型定义及赋予

2.2 软件架构设计

系统软件架构描述了整车各个系统功能的逻辑实现方式，包含传感器（源），功能，技术相关的逻辑架构。PREEvision工具中系统软件架构包括了各种符合AutoSAR标准的软件组件技术规范的定义，从而能与 AutoSAR更好地保持一致性。

AutoSAR CP（Classic Platform）中的软件架构设计是为不同的服务角色创建对应的不同软件类型software type、定义接口类型interface type、定义端口类型port type，连接相应的port，最后为了满足下游工具设置runnable的需求，这里需要设置SWC的internal behavior[12]。

接口类型interface type定义如图5所示。

图5 service interface定义

R&R method的Interface用 Server-Client Interface 实现；

F&F method Interface用Sender-Receiver Inter face 实现；

Properties中的get/set用Server-Client Inter- face实现；

Properties中的Notifier用Sender-Receiver Interface实现；

Event 用 Sender-Receiver Interface 实现。

端口类型port type的定义与接口类型定义相对应，Port type主要包括：

Sender port type；

Receiver port type；

Client port type；

Server port type。

端口类型port type定义完之后，为相应的Port分配Interface，并连接相应的端口。如图6所示。

图6 软件架构原理图

2.3 网络拓扑设计

网络拓扑设计用于确定各以太网节点的连接方式和配置方式[13]，建立连接硬件部件的概念中最顶层的抽象连接关系，用于指导后续以太网的设计和开发工作，如图7所示。主要内容包括：

确定以太网节点，是ECU类型还是computer类型；

确定Switch位置，是在以太网节点内部还是以太网节点外部，如果是在以太网节点内部，是在哪个节点内部。

分配Bus Connection Type为Ethernet Types；

分配Connector Type为Ethernet Connector Types；

将Bus Systems分配给Ethernet Cluster；

利用Switch Configuration将物理网络划分成逻辑网络VLAN。

图7 网络拓扑结构图

2.4 服务部署

服务部署包括软件和硬件的映射和信号路由两部分内容。

2.4.1软件与硬件映射

软件与硬件映射即是将Software Component分配到硬件ECU中，通过Software Type实例化得到具体的Software Component。

2.4.2信号路由

通过信号路由将实现服务的软件部件间的虚拟通信转变成真实的Ethernet总线通信，通过PREEvision的信号路由功能，可自动生成PDU, Signal, PDU Transmission和Signal Transmission等一系列构件。

然后针对新生成的构件配置参数，signal需要配置的参数如下：

Signal Length设置根据实际长度进行设置；

Data Type Policy设置为TRANSFORMINIGI- SIGNAL；

Signal IPDU参数设置：

Bit Length设置根据实际长度进行设置；

在Signal IPDU下创建Timing Mode On True →Event Controlled Timing，将Number of Repetiti- ons设置为0。

Signal-IPDU-Assignment参数设置：

Start Position设置为0；

Byte Order设置为Opaque；

Transfer Property设置为Trigger或Trigger Without Repetitions；

Update Indication Bit Position不设置。

2.5 以太网通信设计

以太网通讯设计包括以太网物理层、数据链路层、网络层和传输层等底层协议的参数配置[14]。

Physical layer type：包括100 BASE T1、1000 BASE T1，100BASE TX等；这是一种以太网标准，100表示理论上最大的传输速率，单位：Mbit/s。Base是Baseband的缩写，表示使用基带传输,没有进行调制和频分复用。T表示twisted pair cable，表明传输的介质是双绞线。

CNB（Connection Negotiation Behavior）：车内的协商机制都采用主从形式，为每个控制器选择主从节点配置。

MAC-Address：以太网采用介质访问控制（Medh Access Control, MAC）地址进行物理寻址。MAC地址为硬件地址，它采用48位（6字节）的十六进制格式。

MAC Kind：包括Hardware类型和可以刷写的Flashed类型。

PCP：概率可检测证明（Probabilistically Che- ckable Proofs, PCP），包含在VLAN tag中，在PCP列可以设置优先级，范围0至7，数值越小优先级越低。

VLAN：虚拟局域网（Virtual Local Area Network, VLAN）的中文名为“虚拟局域网”。虚拟局域网（VLAN）是一组逻辑上的设备和用户，这些设备和用户并不受物理位置的限制。VLAN限制了广播域，广播帧只允许在域内广播，合理的划分VLAN有利于网络通讯安全及负载分配。VLAN ID表示VLAN的唯一数据标识符。

互联网协议（Internet Protocol, IP），是TCP/IP协议栈中最核心的协议之一，通过IP地址，保证了联网设备的唯一性，实现了网络层的寻址。车内网络节点一般都使用IPv4协议，它为互联网协议的第四版本，地址由4个字节的数据组成。另外车内IP地址是预先定义的，不会使用动态分配IP地址的方式。在AutoSAR协议中IP地址包含在网络终端（Network End Point, NEP）下。

TCP/UDP：用户数据报User Datagram Protocol, UDP是一种简单的、无连接、不可靠的传输协议，若某进程需要发送一个不关心其可靠性的报文，可使用UDP，UDP没有流量控制机制，数据长度最大为1 400 byte，可以支持组播和单播；而TCP不同于UDP，TCP是一种面向连接的、可靠的传输协议，它能够保证两端通信主机之间的信息可达，TCP带有流量控制机制，可以传输比UDP更长的数据，只支持单播。如果要基于UDP传输大于1 400 byte的数据，可以使用SOMEIP TP将数据分包。

端口号（Port Number）：所谓的端口号，就好像是门牌号一样，客户端可以通过IP地址找到对应的服务器端，但是服务器端是有很多端口的，每个应用程序对应一个端口号，通过类似门牌号的端口号，客户端才能真正的访问到该服务器。

Socket address：Socket address由IP地址，传输协议TCP或者UDP及对应的端口号组成。

图8是使用PREEvision工具进行的以太网通讯OSI模型1层至4层的设计。

2.6 以太网SoAd的设计

在AutoSAR协议中，SoAd模块的主要目的是在PDU和基于Socket的TCP/IP堆栈之间创建一个接口。建立起Socket与PDU之间的数据传输。TCP/IP的数据接收时通过SoAd的接口可以将数据转换成PDU的形式，在发送的时候可以将具体的PDU数据转化成Socket的形式在TCP/IP协议层进行发送。定义PDU的Header ID区分不同的Socket与PDU的交互，即在同一个socket中关联多个不同的PDU；Socket Connection是连接目标Socket（PDU）和源PDU（Socket）的路由关系，每一个Connection都关联到有特定的TCP、UDP中，一方面用来控制以太网通信中TCP、UDP连接的打开还是关闭，另一方面定义了TCP、UDP数据如何被接收和发送。

2.7 SOMEIP序列化（SOMEIP Serializer）

SOMEIP Serializer是AutoSAR协议Trans- former模块中的一个功能模块，用于数据的序列化，即进行以太网并行的结构化数据和线性数据的转换[15]。图9为SOMEIP Serializer的过程，在AutoSAR中，发送端SWC发送数据到RTE，RTE调用SOMEIP Serializer模块将结构化的数据按照一定的规则转换成线性数据，再传输到COM模块；在接收端，数据按照相同的规则进行反序列化后再发送给SWC。

以太网结构化数据包括结构体、数组、联合体和字符串等[17]。结构体和数组的区别是，结构体所有数据元素的数据类型是不同的，数组所有数据元素的数据类型必须是相同的。图10为带有长度域的结构体数据类型序列化示例，结构体的长度域是可选的，可在结构体之前添加一个8位，16位或32位的长度字段；如果未指定长度域的长度，则必须假定长度为0，并且报文中不包含长度；如果长度段大于实际长度，则仍会解析，只解析接口规范中定义的字节；如果是嵌套结构体每个结构体前都要添加长度域。

图9 SOMEIP Serializer视图

图10 结构体数据序列化示例

在PREEvision工具创建SOMEIP 序列化包括配置SOMEIP Transformer，配置SOMEIP Trans- formation properties，分配SOMEIP Transformation Properties给各个接口元素。

2.7.1SOMEIP Transformer

SOMEIP Transformer需要设置的相关参数如下：

Protocol设置为SOMEIP；

Transformer Class选择SERIALIZER；

Version设置为1.0.0；

Header Length设置为64；

Alignment设置根据实际域控制器状态填写，比如车身域控制器一般为32位对齐，座舱域控制器一般为64位对齐；

Byte Order选择也需要根据实际情况填写，不能选择opaque类型，为与以太网header保持一致，通常选择Motorola Big Endian类型。

3.7.2SOMEIP Transformation properties

创建SOMEIP Transformation properties构件，并配置相关参数。如存在多种不同的配置参数，需要对应创建多个不同的SOMEIP Transformation properties。每个SOMEIP Transformation properties都要关联SOMEIP Transformer。SOMEIP Transfor- mation properties需要配置的相关参数如下：

Interface version：1；

Message type：报文类型，位于SOMEIPheader中；

Implements SOMEIP String Handling：用于说明string类型的数据是否兼容SOMEIP规范的定义；

各类型数据长度域长度设置

最后将SOMEIP Transformation Properties分配给各个接口元素即可。

2.8 SOMEIP SD

服务发现（Service Discovery, SD）是服务的信息清单及管理机制，也是一种服务，主要实现服务寻址及事件订阅两种功能[16]。SD用来对服务进行寻址时，服务提供者（Server端）通过服务发现（SD）通知其他ECU（Client端）某服务可用，并间接地通知该服务的地址（Server端地址）；服务消费者（Client端）了解到某服务状态后，能够调用该服务的相关内容。SD用来事件订阅时，专门针对Event类型的接口，可以通过SD实现对Event所在的Event group进行订阅、停止订阅等操作。SD最突出的优点是需要的时候才会提供/订阅服务，节省带宽和CPU资源。可支持动态的布置服务，符合SOA架构的灵活性、可复用性和可移植性。

通过PREEvision工具会生成SD相关构件，然后配置相关参数，包括如下内容：

SD PDU配置：每一个以太网节点都会生成三个general purpose PDU：用于接收单播SdInstance UnicastRxPdu，用于接收组播的SdInstanceMuticast RxPdu，及用于发送的SdInstanceTxPdu，PDU的类别为SD。

SD socket address的配置，包括单播IP地址，组播IP地址，SD端口号推荐为30490。如图11所示。

图11 SOMEIP SD Socket定义

2.8.1服务器端SOMEIP SD通信行为

服务器端SOMEIP SD通信行为主要包括四个阶段：Down Phase，Initial Wait Phase，Repetition Phase，Main Phase。需要配置的时间参数示例可参看图12。

图12 Server时间参数示例

Down Phase：在这个阶段，Service是不可用的，即服务端无法提供服务。

Initial Wait Phase：当服务准备完毕（Availa- ble）后，进入此阶段；如果此阶段收到Find Service报文，服务端忽略此消息，不做任何处理。需要配置的时间参数+为INITIAL_DELAY时间（最大和最小值之间的随机值）。

Repetition Phase：为了让客户端快速找到有哪些Service，此阶段重复发送OfferService，重复次数由REPETITIONS_MAX决定；发送间隔以REPETITIONS_BASE_DELAY为基本时间，每发送一次，间隔是前一间隔的2倍；如果收到某客户端的FindService，不影响当前阶段的发送计数和计时，延迟一定时间（REQUEST_RESPONSE_ DELAY）后，单独发送单播Offer Service给服务请求端；如果收到Subscribe Eventgroup后，发送单播Ack/Nack，启动此订阅Entry的晶体管-晶体管逻辑Transistor-Transistor Logic, TTL）计时器；如果收到Stop Subscribe Eventgroup后，停止此订阅Entry的TTL计时器；如果服务不可用，离开此阶段进入Down Phase，并发送Stop Offer Service通知所有客户端。

Main Phase：此阶段将周期性发送Offer Service，周期时间为Offer Cyclic Delay。如图13所示。

图13 providedServiceInstance时间参数

2.8.2客户端的通信行为

客户端SOMEIP SD通信行为主要包括四个阶段：Down Phase，Initial Wait Phase，Repetition Phase，Main Phase。需要配置的时间参数示例可参看图14所示。

图14 SOMEIP Client 时间参数示例

Down Phase：服务未被应用请求；

Initial Wait Phase：服务被请求后，进入此阶段；等待INITIAL_DELAY时间（最大和最小值之间的随机值）；如果此时收到Offer Service，则取消计时器，直接进入Main Phase；计时器超时后，发送第一个Find service，进入下一阶段。

Repetition Phase：重复发送Find service，重复次数由REPETITIONS_MAX决定；发送间隔以REPETITIONS_BASE_DELAY为基时间，每发送一次间隔加倍；收到Offer Service，停止发送计数和计时，立即进入Main Phase；触发发送Subscribe Eventgroup（延迟一定时间）；如果服务请求被释放，进入Down Phase；若有订阅，则发送StopSub- scribeEventgroup。

Main Phase：不再发送Find Service。

2.9 导出ARXML

当所有的建模设计完成后，即可导出Auto- SAR System Description，ECU extract, ECU System Description三种ARXML。PREEvision导出的格式文件ARXML可以准确地、可靠地导入到下游工具Simulink或者Vector DaVinci中，以便后续在开发过程中使用[18]。图15中导出的是ECU extract的arxml，共有7个AR-package，按字母顺序排列有Communication, DataTypeMappingSets, DataTypes, SoAdRoutingGroups, SoftwareTypes, System, Topo- logy。

图15 ECU Extract arxml层级结构

3 结束语

本文主要介绍了基于PREEvision 工具和Classic AutoSAR的面向服务的电子电气架构设计方法，PREEvision能够保证数据一致性和整个模型的一致性，同时能够进行数据的跟踪和一致性检查[19]。PREEvision工具自带1 000多条的AutoSAR的检查规则，是目前应用最多的AutoSAR模型创建工具。PREEvision快速推进了国内软件定义汽车的步伐，为国内很多主机厂搭建了电子电气架构平台，加快了国内面向SOA架构的智能网联汽车的开发进度[20]。

[1] 王文伟,徐匡一.智能汽车电子架构分析与研究[J].时代汽车,2020(4):43-46.

[2] 孟天闯,李佳幸,黄晋,等.软件定义汽车技术体系的研究[J].汽车工程,2021,43(4):10.

[3] 华一丁,龚进峰,戎辉,等.国外智能汽车电子电气架构综述及分析[J].汽车电器,2018(12):8.

[4] 孙升,宋珂,章桐.AutoSAR标准发展及应用现状[J].机电一体化,2014(12):33-38,44.

[5] 李丹,吕颖,李骏,等.面向服务的体系架构[J].汽车文摘,2021(10):52-57.

[6] UGELE S,OBERGFELL P,BROY M,et al.On Service- orientation for Automotive Software[C]//2017 IEEE International Conference on Software Architecture Piscataway: IEEE,2017:193-202.

[7] RUMEZ M,GRIMM D,KRIESTEN R,et al.An Over- view of Automotive Service-oriented Architectures and Implications for Security Countermeasures[J].IEEE access,2020(8):221852-221870.

[8] 张海涛,胡胜,仇林至.基于AutoSAR的SOMEIP通信及其多核应用的实现[J].上海汽车,2021(1):17-22,28.

[9] 匡小军,唐香蕉,周涛,等.基于PREEvision的汽车电子电气架构工具链研究[J].汽车电器,2019(8):3.

[10] 冯香枝,胡朝峰,张海涛.基于PREEVISION的汽车电子电气架构设计[J].汽车电器,2013(10):43-46.

[11] AutoSAR.System Template.AutoSAR Classic PlatformR20-11[R].Redmond:AutoSAR Foundation.2020:2130- 2190.

[12] AutoSAR. Software Component Template. AutoSAR Classic Platform Release 4.3.0[R].Redmond:AutoSAR Foundation.2016:65-220.

[13] 袁仲楠.基于PREEvison的电子电气架构开发研究[J].电子测试,2020(3):55-57,130.

[14] 符丹丹,赵杰,美少楠,等.基于商用车的车载以太网通信技术应用[J].汽车电器,2021(7):34-35,39.

[15] AutoSAR. Specification of SOME/IP Transformer. AutoSAR Classic Platform Release 4.3.1[R]. Redmond: AutoSAR Foundation.2017:26-44.

[16] AutoSAR.SOME/IP Service Discovery Protocol Spe- cification Release 20-11[S].Redmond:AutoSAR Fou- ndation,2020.

[17] 崔晓通,陈宇鹏,张亮,等.车载以太网类型及测试[J].西安邮电大学学报,2020(4):90-96.

[18] 刘敏,郭永斌,童菲,等.基于PREEvison的AutoSAR软件建模[J].机电一体化,2014(11):74-76.

[19] 王永辉.基于PREEvision的汽车电子电气架构设计介绍[J].汽车实用技术,2019,44(15):111-112.

[20] 矫莉,章日欣.PREEvision提供从电子电气架构设计到系列开发阶段的支持[J].汽车与配件,2014(10):56- 58.

Service-oriented Architecture Design Based on PREEvision

ZHAN Dekai1, GAO Yue2

( 1.Collaborative Innovation Center for ICV, Liaoning Provincial College of Communications,Shenyang 110122, China; 2.Shenyang DoTrust Technologies Company Limited, Shenyang 110111, China )

With the in-depth development of the new "four modernizations" of automobiles, electronic and electrical systems are becoming more and more complex, and the innovation and expansion of electronic and electrical architecture is imperative. Service-oriented architecture(SOA),model based design(MBD), AutoSAR and Ethernet have become trends for development of the electronic and electrical architecture. The article describes how to realize the developing contents based on the PREEvision software for the service-oriented architecture design. The contents included service and service interface, software architecture, network topology, service deployment, Ethernet protocols, Ethernet SoAD module and SOMEIP serializer,etc. The ARXML files should be produced after building the module. The development process met the technical requirement of the MBD and AutoSAR. It promoted the realization of software-defined vehicles and formed and improved new electronic and electrical architecture platforms.

Service-oriented architecture(SOA);PREEvision;Model based design(MBD);AutoSAR;SOMEIP; Ethernet

U462.1

A

1671-7988(2022)23-62-09

U462.1

A

1671-7988(2022)23-62-09

10.16638/j.cnki.1671-7988.2022.023.012

詹德凯（1973—），男，高级工程师，研究方向为智能网联汽车、新能源汽车、汽车电子电气，E-mail:zhan dekai@163.com。