CN110955412B - 面向服务的智能座舱系统及其设计方法和设计系统 - Google Patents

Abstract

本发明公开了一种面向服务的智能座舱系统及其设计方法和设计系统，智能座舱系统包括若干电子控制单元；设计方法包括：S1、对智能座舱系统的功能业务流程进行服务抽象，以得到若干服务和若干业务流程；业务流程用于封装多个服务，以完成所需的业务逻辑组合；S2、对若干服务进行分类，以得到实体服务和公共服务；实体服务为从功能逻辑抽象得出的服务，实体服务包括若干公共服务；公共服务为不限于从功能逻辑中抽象得出的服务，公共服务为不可拆分的服务；S3、将若干业务流程、若干服务分别部署至若干电子控制单元中的一个。本发明兼顾智能座舱系统服务化需求与对遗留资产的有效利用，为座舱系统架构向SOA范式过渡提供有效方案。

Description

面向服务的智能座舱系统及其设计方法和设计系统

技术领域

本发明涉及智能座舱领域，特别涉及一种面向服务的智能座舱系统及其设计方法和设计系统。

背景技术

传统的智能座舱系统架构设计是基于功能业务流程实现的，也就是直接由功能逻辑设计工程师完成功能业务流程的定义后将其交至ECU(Electronic Control Unit，电子控制单元)工程师实现控制器功能。车内软件之间通过静态交互实现量产预定义的功能。伴随智能座舱的网联化、智能化、软件快速迭代等需求，车内软件需要处理来自车辆外部访问，适配车内新增或升级的软件模块，这是传统智能座舱系统架构设计方法所不满足的。

发明内容

本发明要解决的技术问题是为了克服现有技术中传统的智能座舱系统架构设计无法满足智能座舱的网联化、智能化、软件快速迭代等需求的缺陷，提供一种能够满足智能座舱的网联化、智能化、软件快速迭代等需求的面向服务的智能座舱系统及其设计方法和设计系统。

本发明是通过下述技术方案来解决上述技术问题：

本发明第一方面提供了一种面向服务的智能座舱系统的设计方法，所述智能座舱系统包括若干电子控制单元；所述设计方法包括：

S1、对所述智能座舱系统的功能业务流程进行服务抽象，以得到若干服务和若干业务流程；所述业务流程用于封装多个所述服务，以完成所需的业务逻辑组合；

S2、对若干所述服务进行分类，以得到实体服务和公共服务；所述实体服务为从功能逻辑抽象得出的服务，所述实体服务包括若干所述公共服务；所述公共服务为不限于从功能逻辑中抽象得出的服务，所述公共服务为不可拆分的服务；

S3、将若干所述业务流程、若干所述服务分别部署至若干所述电子控制单元中的一个。

本方案整合了智能座舱服务层，提供了适用于智能座舱系统的服务分类方法，形成任务服务子层、实体服务子层、公共服务子层的服务管理体系，其中任务服务子层与服务抽象后得到的业务流程相对应。

本方案中，通过系统架构工程师对功能业务流程进行服务分析，以实现服务抽象，得到服务抽象的结果，对于该结果进行服务管理时可归为三类，分类原则如下：业务流程：单一用途的父业务流程，用于封装多个其他服务以完成其任务所需的逻辑组合，其中包含明确服务调用逻辑断点。是一种非不可知的功能上下文服务，具体可以使用业务流程库管理管理。实体服务：从功能逻辑抽象得出，具有与一个或多个相关逻辑模块相关联得服务，允许服务之间得嵌套，是一种不可知功能上下文的可重用服务。具体可以使用实体服务库管理。公共服务：该类型服务封装了底层的技术功能，不限于从功能逻辑模型中得出，是一种具有不可知功能上下文的可重用服务，常见于与物理硬件绑定或操作系统提供的服务，具体使用公共服务库管理。

其中，业务流程库、实体服务库、公共服务库各自独立，以保证访问时互不冲突，进而提高数据库中数据读取的效率。

本方案在传统汽车系统架构开发流程下，设计了一套面向服务的智能座舱系统的设计方法，实现自上而下的业务驱动的手段，满足了智能座舱系统的网联化、智能化、软件快速迭代等面向服务的需求。使得智能座舱承载的功能从流程关系转变为服务调用关系，从而有效降低智能座舱系统架构耦合度；提升智能座舱产品软件服用度，降低软件开发、升级成本，缩短开发周期；新增功能调用原有可复用服务，提升智能座舱产品应用扩展性。

较佳地，所述设计方法还包括以下步骤：

S0、对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程。

本方案以传统开发流程中的功能逻辑设计层为起点，根据智能座舱系统的功能业务需求，完成功能业务流程定义，即一个功能业务对应一个功能业务流程，功能业务流程的具体表现形式可以是流程图，也可以是其它的表现形式。

较佳地，步骤S0包括以下步骤：

使用基于模型的系统工程工具对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程；

其中，所述功能业务流程为可视化功能逻辑模型。

本方案进一步限定使用基于模型的系统工程工具，形成可视化功能逻辑模型，其中可视化功能逻辑模型为功能业务流程的具体表现形式。

较佳地，步骤S3包括以下步骤：

基于所述智能座舱系统的物理拓扑将每个所述电子控制单元分为面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的一类节点；

根据预设的服务部署策略将若干所述业务流程、若干所述服务分别部署至所述面向服务的网络节点、所述非面向服务的网络节点和所述面向服务的网络边缘节点中的至少一个节点上；

所述面向服务的网络节点为完全处于面向服务的网络当中的节点；

所述非面向服务的网络节点为完全处于非面向服务的网络当中的节点；

所述面向服务的网络边缘节点为处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力的节点。

本方案融合传统智能座舱系统开发流程，扩展定义面向服务的系统架构开发层级任务和角色；适用于当前基于功能逻辑的架构向基于服务的架构过渡阶段，可实现自上而下的业务驱动的手段和自下向上遗留资产分析的手段综合应用，兼顾智能座舱系统服务化需求与遗留资产的有效利用。

本方案中，服务部署工作一般由ECU工程师与系统架构工程师合作完成。系统架构工程师按照功能业务流程分析抽象服务实现自上而下的业务驱动的手段，完成服务拆解，提供合理的服务部署策略。但是，智能座舱系统架构仍处于向面向服务的架构过渡阶段，存在大量的系统遗留资产，意味着智能座舱系统内的电子控制单元并不都具备完全满足面向服务的软硬件能力。本方案中，ECU工程师采用自下向上对智能座舱遗留资产进行分析，判定电子控制单元能否承载系统架构工程师部署的服务。综合ECU工程师与系统架构工程师的分析后的服务部署方案，才能同时满足智能座舱功能服务化的需求和合理集成系统遗留资产。

较佳地，所述根据预设的服务部署策略将若干所述业务流程、若干所述服务分别部署至所述面向服务的网络节点、所述非面向服务的网络节点和所述面向服务的网络边缘节点中的至少一个节点上的步骤包括：

将所述业务流程部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

将所述实体服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

判断所述公共服务是否需要部署于所述非面向服务的网络节点，若否，则将所述公共服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点；若是，则将所述公共服务拆解为服务代理和服务能力，将所述服务能力部署于所述非面向服务的网络节点，将所述服务代理部署于所述面向服务的网络边缘节点中。

本方案中，面向服务的网络节点可直接承载部署至其上的业务流程，实体服务和公共服务；面向服务的网络边缘节点可直接承载部署至其上的业务流程，实体服务和公共服务，还可以为部署在非服务网络的功能模块提供服务代理，实现部署于非服务网络功能的服务化；当通过业务流程抽象出的公共服务需要非面向服务的网络节点实现时，需将公共服务拆解为服务代理和服务能力两个部分，然后将服务代理部署于面向服务的网络边缘节点，服务能力部署于非面向服务的网络节点上，并将服务代理添加至专门的服务代理库中进行管理。

本方案中，对无法满足功能服务化需求的静态交互网络，使用核心控制器进行服务代理，保证智能座舱系统内的所有功能对外完全服务化；基于本方案提供的服务分类方法和网络节点分类方法，进一步设计了一套服务部署规则，简化服务部署复杂度，界定了不同类服务的软件动态能力。

较佳地，所述面向服务的网络节点对应的所述电子控制单元包括网关或远程处理信息终端或云端中处于以太网或Wi-Fi(无线上网)/4G(第四代的移动信息系统)网络中的节点；

所述非面向服务的网络节点对应的所述电子控制单元包括座椅控制器或功放控制器或氛围灯或阅读灯中处于CAN(Controller Area Network，控制器局域网络)、LIN(针对汽车分布式电子系统而定义的一种低成本的串行通讯网络)或A2B(汽车音频总线)网络中的节点；

所述面向服务的网络边缘节点对应的所述电子控制单元包括智能座舱控制器中处于面向服务的网络以太网和非面向服务的网络CAN和LIN之间的节点。

本方案中，采用自下向上遗留资产分析从智能座舱系统的物理拓扑着手，可将电子控制单元划分为3类：第一类，面向服务的网络节点，该类型节点完全处于面向服务的网络当中。智能座舱中，常见的面向服务的网络类型有以太网(Eth)、Wi-Fi、4G/5G(第五代的移动信息系统)、蓝牙、(USBUniversal Serial Bus，通用串行总线)等。第二类，非面向服务的网络节点，该类型节点完全处于非面向服务的网络当中。智能座舱中，常见的非面向服务的网络类型有CAN、LIN、Flexray(一种车载网络标准)或A2B等。第三类，面向服务的网络边缘节点，该类型节点处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力。

较佳地，所述业务流程包括调用的所述服务的逻辑断点。

本发明第二方面提供了一种面向服务的智能座舱系统的设计系统，所述智能座舱系统包括若干电子控制单元；所述设计系统包括：

服务抽象模块，用于对所述智能座舱系统的功能业务流程进行服务抽象，以得到若干服务和若干业务流程；所述业务流程用于封装多个所述服务，以完成所需的业务逻辑组合；

服务分类模块，用于对若干所述服务进行分类，以得到实体服务和公共服务；所述实体服务为从功能逻辑抽象得出的服务，所述实体服务包括若干所述公共服务；所述公共服务为不限于从功能逻辑中抽象得出的服务，所述公共服务为不可拆分的服务；

部署模块，用于将若干所述业务流程、若干所述服务分别部署至若干所述电子控制单元中的一个。

较佳地，所述设计系统还包括流程生成模块；

所述流程生成模块用于对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程。

较佳地，所述流程生成模块用于使用基于模型的系统工程工具对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程；

其中，所述功能业务流程为可视化功能逻辑模型。

较佳地，所述部署模块包括节点分类单元和部署单元；

所述节点分类单元用于基于所述智能座舱系统的物理拓扑将每个所述电子控制单元分为面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的一类节点；

所述部署单元用于根据预设的服务部署策略将若干所述业务流程、若干所述服务分别部署至所述面向服务的网络节点、所述非面向服务的网络节点和所述面向服务的网络边缘节点中的至少一个节点上；

所述面向服务的网络节点为完全处于面向服务的网络当中的节点；

所述非面向服务的网络节点为完全处于非面向服务的网络当中的节点；

所述面向服务的网络边缘节点为处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力的节点。

较佳地，所述部署单元包括业务流程部署子单元、实体服务部署子单元和公共服务部署子单元；

所述业务流程部署子单元用于将所述业务流程部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

所述实体服务部署子单元用于将所述实体服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

所述公共服务部署子单元用于判断所述公共服务是否需要部署于所述非面向服务的网络节点，若否，则将所述公共服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点；若是，则将所述公共服务拆解为服务代理和服务能力，将所述服务能力部署于所述非面向服务的网络节点，将所述服务代理部署于所述面向服务的网络边缘节点中。

较佳地，所述面向服务的网络节点对应的所述电子控制单元包括网关或远程处理信息终端或云端中处于以太网或Wi-Fi/4G网络中的节点；

所述非面向服务的网络节点对应的所述电子控制单元包括座椅控制器或功放控制器或氛围灯或阅读灯中处于CAN、LIN或A2B网络中的节点；

所述面向服务的网络边缘节点对应的所述电子控制单元包括智能座舱控制器中处于面向服务的网络以太网和非面向服务的网络CAN和LIN之间的节点。

较佳地，所述业务流程包括调用的所述服务的逻辑断点。

本发明第三方面提供了一种面向服务的智能座舱系统，所述智能座舱系统使用如第一方面所述的面向服务的智能座舱系统的设计方法设计得到。

本发明的积极进步效果在于：

本发明在传统汽车系统架构开发流程下，扩展设计了一套面向服务的智能座舱系统的设计方法，将传统面向功能流程的智能座舱电子电器架构重构为面向服务的智能座舱电子电器架构，实现从业务逻辑中抽象服务。实现自上而下的业务驱动的手段和自下向上遗留资产分析的手段综合应用，兼顾智能座舱系统服务化需求与对遗留资产的有效利用，为座舱系统架构向SOA(面向服务的架构)范式过渡提供有效方案。使智能座舱承载的功能从流程关系转变为服务调用关系，从而有效降低智能座舱系统架构耦合度；提升智能座舱产品软件服用度，降低软件开发、升级成本，缩短开发周期；新增功能调用原有可复用服务，提升智能座舱产品应用扩展性。

附图说明

图1为本发明实施例1的一种面向服务的智能座舱系统的设计方法的流程图。

图2为实施例1中步骤S3的流程图。

图3为基于实施例1的构思实现的面向服务的系统架构开发流程示意图。

图4为实施例1中使用的服务部署逻辑示意图。

图5为智能座舱系统中驾驶员进入智能座舱流程示意图。

图6为对图5所示的驾驶员进入智能座舱流程进行服务抽象的过程示意图。

图7为对图5所示的驾驶员进入智能座舱流程进行服务抽象的结果示意图。

图8为常规的智能座舱拓扑示意图。

图9为对图5所示的驾驶员进入智能座舱流程的服务部署的结果示意图。

图10为本发明实施例2的一种面向服务的智能座舱系统的设计系统的模块示意图。

图11为图10中部署模块的模块示意图。

图12为图11中部署单元的模块示意图。

具体实施方式

下面通过实施例的方式进一步说明本发明，但并不因此将本发明限制在所述的实施例范围之中。

实施例1

如图1所示，本实施例提供了一种面向服务的智能座舱系统的设计方法，智能座舱系统包括若干电子控制单元；设计方法包括：

步骤S0、使用基于模型的系统工程工具对智能座舱系统按照功能业务进行流程的定义，以形成若干与功能业务一一对应的功能业务流程；其中，功能业务流程为可视化功能逻辑模型。

步骤S1、对智能座舱系统的功能业务流程进行服务抽象，以得到若干服务和若干业务流程；业务流程用于封装多个服务，以完成所需的业务逻辑组合；业务流程包括调用的服务的逻辑断点。

步骤S2、对若干服务进行分类，以得到实体服务和公共服务；实体服务为从功能逻辑抽象得出的服务，实体服务包括若干公共服务；公共服务为不限于从功能逻辑中抽象得出的服务，公共服务为不可拆分的服务。

步骤S3、将若干业务流程、若干服务分别部署至若干电子控制单元中的一个。

如图2所示，本实施例中步骤S3具体包括以下步骤：

步骤S301、基于智能座舱系统的物理拓扑将每个电子控制单元分为面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的一类节点。

步骤S302、根据预设的服务部署策略将若干业务流程、若干服务分别部署至面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的至少一个节点上。步骤S302具体包括：将业务流程部署于面向服务的网络节点或面向服务的网络边缘节点中；将实体服务部署于面向服务的网络节点或面向服务的网络边缘节点中；判断公共服务是否需要部署于非面向服务的网络节点，若否，则将公共服务部署于面向服务的网络节点或面向服务的网络边缘节点；若是，则将公共服务拆解为服务代理和服务能力，将服务能力部署于非面向服务的网络节点，将服务代理部署于面向服务的网络边缘节点中。

本实施例中，面向服务的网络节点为完全处于面向服务的网络当中的节点，面向服务的网络节点对应的电子控制单元包括网关或远程处理信息终端或云端中处于以太网或Wi-Fi/4G网络中的节点。非面向服务的网络节点为完全处于非面向服务的网络当中的节点，非面向服务的网络节点对应的电子控制单元包括座椅控制器或功放控制器或氛围灯或阅读灯中处于CAN、LIN或A2B网络中的节点。面向服务的网络边缘节点为处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力的节点。面向服务的网络边缘节点对应的电子控制单元包括智能座舱控制器中处于面向服务的网络以太网和非面向服务的网络CAN和LIN之间的节点。

本实施例提供的设计方法，融合传统智能座舱系统开发流程，扩展定义面向服务的智能座舱系统架构开发层级任务和角色；将传统面向功能流程的智能座舱电子电器架构重构为面向服务的智能座舱电子电器架构，实现从业务逻辑中抽象服务；整合智能座舱服务层，形成任务服务子层、实体服务子层、公共服务子层的服务管理体系；基于本实施例中的服务管理体系，进一步设计了一套服务部署规则，简化服务部署复杂度；对无法满足功能服务化需求的静态交互网络，使用核心控制器进行服务代理，保证智能座舱系统内的所有功能对外完全服务化；本实施例提供的设计方法可实现自上而下的业务驱动的手段和自下向上遗留资产分析的手段综合应用，兼顾智能座舱系统服务化需求与遗留资产的有效利用。

为了进一步说明本实施例提供的设计方法所保护的技术方案及其实现的技术效果，现结合附图3对本实施例进一步解释说明。

如图3所示，其为基于本实施例的构思实现的面向服务的系统架构开发流程的示意图，本设计方法以传统EEA开发流程中的功能逻辑设计层101为起点，功能逻辑设计工程师102完成功能业务流程103定义。建议使用基于模型的系统工程工具，如Vector(维克多汽车技术)公司的PREEvision(一种基于模型的计算机辅助设计软件工具)等，形成可视化功能逻辑模型。

系统架构工程师104负责对功能业务流程进行服务分析113，进行服务抽象105，可抽象成服务的业务单元用106或107表示。抽象服务时，需要在保证不损失或损害内聚性、一致性和完整性的情况下，尽可能地进行粗粒度建模，以平衡可复用度、系统灵活性与系统易用性之间的关系。据此，服务可由单一业务流程步骤106或组合业务流程107抽象得出。进一步，系统架构工程师104可得到服务抽象后剩余的业务流程108，并在调用服务处设置逻辑断点。

通过系统架构工程师104根据服务分析113的结果，对服务抽象后的模块进行服务管理114，服务抽象后的模块可归为三类模块，分类原则如下：

1)业务流程：单一用途的父业务流程，用于封装多个其它服务以完成其任务所需的逻辑组合，其中包含明确服务调用逻辑断点。是一种非不可知的功能上下文服务，使用父业务逻辑库109管理，如其中存放的业务流程108对应的模块。

2)实体服务：从功能逻辑抽象得出，具有与一个或多个相关逻辑模块相关联得服务，允许服务之间的嵌套，是一种不可知功能上下文的可重用服务。使用实体服务库110管理。

3)公共服务：该类型服务封装了底层的技术功能，不限于从功能逻辑模型中得出，是一种具有不可知功能上下文的可重用服务，常见于与物理硬件绑定或操作系统提供的服务。使用公共服务库111管理。

服务部署(Service Deployment)115由ECU工程师116与系统架构工程师104合作完成。系统架构工程师104对智能座舱系统的每个功能业务流程进行服务分析113，实现自上而下的业务驱动的手段，完成服务拆解，提供合理的服务部署策略。但是，智能座舱系统架构仍处于向面向服务的架构过渡阶段，存在大量的系统遗留资产，意味着智能座舱系统内的电子控制单元并不都具备完全满足面向服务的软硬件能力。因此，ECU工程师116需要自下向上对智能座舱遗留资产进行分析，判定电子控制单元能否承载系统架构工程师104部署的服务。综合ECU工程师116与系统架构工程师104的分析后的服务部署方案，才能同时满足智能座舱功能服务化的需求和合理集成系统遗留资产。

自下向上遗留资产分析从智能座舱系统的物理拓扑117着手，可以将智能座舱系统中的电子控制单元划分为3类：

第一类：面向服务的网络节点118，该类型节点完全处于面向服务的网络当中。智能座舱中，常见的面向服务的网络类型有以太网(Eth)、Wi-Fi、4G/5G、蓝牙、USB等。

第二类：非面向服务的网络节点120，该类型节点完全处于非面向服务的网络当中。智能座舱中，常见的非面向服务的网络类型有CAN、LIN、Flexray或A2B等。

第三类：面向服务的网络边缘节点119，该类型节点处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力。

根据ECU工程师116完成的电子控制单元分类与系统架构工程师104完成的服务分类，可参照图4定义的服务部署逻辑规则完成服务部署，以降低服务部署的复杂度。面向服务的网络节点118可直接承载部署至其上的业务流程，实体服务和公共服务；面向服务的网络边缘节点119可直接承载部署至其上的业务流程，实体服务和公共服务，还可以为部署在非服务网络的功能模块提供服务代理，实现部署于非服务网络功能的服务化；当通过功能业务流程抽象出的公共服务需要非面向服务的网络节点120实现时，需拆解为服务代理和服务能力两个部分。如将公共服务库111中的公共服务106部署于非面向服务的网络节点120时，拆分为服务代理即106代理部署于面向服务的网络边缘节点119和服务能力即106能力部署于非面向服务的网络节点120上，并将服务代理添加于专门的服务代理库112中管理。

下面以智能座舱系统中的驾驶员进入座舱这一功能业务对应的流程为例进行举例说明，如图5所示为功能逻辑工程师对驾驶员进入座舱这一功能业务进行流程定义后形成的功能业务流程，即驾驶员进入智能座舱流程。在图3描述的开发流程中，与功能业务流程101环节对应。本用例驾驶员进入智能座舱流程描述如下：驾驶员打开主驾侧车门后，主驾测座椅调整至迎宾位置，同时阅读灯点亮，氛围灯进入迎宾模式；座椅判断驾驶员是否入座，待驾驶员入座后，主驾侧座椅调整至推荐位置；然后进行驾驶员面部识别，根据面部识别结果获取驾驶员信息，并致欢迎词；阅读灯关闭，驾驶员进入座舱流程结束。

功能逻辑工程师将上述驾驶员进入智能座舱流程需求交由系统架构工程师，系统架构工程师进行服务抽象，在图3描述的开发流程中，与服务分析113环节对应。抽象服务时，需要在保证不损失或损害内聚性、一致性和完整性的情况下，尽可能地进行粗粒度建模，以平衡可复用度、系统灵活性和易用性。用例的服务抽象过程如图6所示。服务可由单一业务单元404抽象得出，也可由组合业务单元411抽象得出。

服务抽象结果如图7所示。在驾驶员进入座舱流程下，将调整主驾侧座椅至迎宾位置401、调整主驾侧座椅调整至推荐位置405动作抽象为座椅调节服务503；点亮阅读灯402、关闭阅读灯407动作抽象为阅读灯调节服务504；氛围灯进入欢迎模式403动作抽象为氛围灯调节服务505；进行驾驶员面部识别406、面部识别成功判断407、获取用户信息408、播放用户欢迎词409、语音提示识别失败410动作抽象为面部识别实体服务502；驾驶员是否入座判断404动作抽象为驾驶员入座状态服务506；获取用户信息动作408抽象为驾驶员信息服务507；播放用户欢迎词409、语音提示识别失败410动作抽象为语音播报服务508。进而将上述从功能业务流程中的服务抽象结果进行模块分类，存储于父业务逻辑库109、实体服务库110、和公共服务库111中。在图3描述的开发流程中，与服务管理114环节对应。

系统架构工程师完成服务提取任务后会与ECU工程师共同完成服务部署环节。在图3描述的开发流程中与服务部署115环节对应。由于智能座舱系统架构向SOA范式过渡过程中，存在合理集成遗留系统的问题，系统架构工程师进行上述自上而下的业务驱动的服务抽象的同时，需要ECU工程师对系统遗留资产进行自下而上的分析，该分析从智能座舱系统的物理拓扑着手，常规智能座舱拓扑可由图8代表。参照图3中物理拓扑117中定义的网络节点分类方法对图8中的电子控制单元分类，结果如下：

第一类：面向服务的网络节点118，如网关601、远程处理信息终端(T-box)602、云端604等处于以太网(Eth)或Wi-Fi/4G网络中的节点；

第二类：非面向服务的网络节点120，如座椅控制器605、功放控制器606、氛围灯607、阅读灯608等处于CAN、LIN或A2B网络中的节点；

第三类：面向服务的网络边缘节点119，如智能座舱控制器603，该节点处于面向服务的网络以太网(Eth)和非面向服务的网络CAN和LIN之间。

以图4定义的服务部署逻辑规则为准则，从驾驶员进入智能座舱流程抽象的服务部署结果如图9所示。

典型部署场景如下：

1)业务流程类模块直接部署于面向服务的网络节点或边缘节点中，如用户进入车舱流程501部署于智能座舱控制器603；

2)实体服务类模块直接部署于面向服务的网络节点或边缘节点中，如面部识别服务502部署于智能座舱控制器603；

3)公共服务类模块直接部署于面向服务的网络节点或边缘节点中，如驾驶员信息服务507部署于云端604；

4)公共服务类模块部署于非面向服务的网络节点，拆解为服务代理和服务能力实现部分，如座椅调节服务505拆解为座椅调节服务代理505代理和座椅调节能力505能力实现，505代理部署于智能座舱控制器603，505能力实现部署于座椅控制器605中。

本实施例在传统汽车系统架构开发流程下，扩展设计了一套面向服务的系统架构设计方法，实现自上而下的业务驱动的手段和自下向上遗留资产分析的手段综合应用，兼顾智能座舱系统服务化需求与对遗留资产的有效利用，为座舱系统架构向SOA范式过渡提供有效方案。使用本实施例所述的设计方法使智能座舱承载的功能从流程关系转变为服务调用关系，从而有效降低智能座舱系统架构耦合度；提升智能座舱产品软件服用度，降低软件开发、升级成本，缩短开发周期；新增功能调用原有可复用服务，提升智能座舱产品应用扩展性。

实施例2

如图10所示，本实施例提供了一种面向服务的智能座舱系统的设计系统，智能座舱系统包括若干电子控制单元；设计系统包括：流程生成模块1、服务抽象模块2、服务分类模块3和部署模块4。

流程生成模块1用于使用基于模型的系统工程工具对智能座舱系统按照功能业务进行流程的定义，以形成若干与功能业务一一对应的功能业务流程。其中，功能业务流程为可视化功能逻辑模型。

服务抽象模块2用于对智能座舱系统的功能业务流程进行服务抽象，以得到若干服务和若干业务流程；业务流程用于封装多个服务，以完成所需的业务逻辑组合。业务流程包括调用的服务的逻辑断点。

服务分类模块3用于对若干服务进行分类，以得到实体服务和公共服务；实体服务为从功能逻辑抽象得出的服务，实体服务包括若干公共服务；公共服务为不限于从功能逻辑中抽象得出的服务，公共服务为不可拆分的服务。

部署模块4用于将若干业务流程、若干服务分别部署至若干电子控制单元中的一个。

如图11所示，本实施例中，部署模块4包括节点分类单元41和部署单元42。其中节点分类单元41用于基于智能座舱系统的物理拓扑将每个电子控制单元分为面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的一类节点；部署单元42用于根据预设的服务部署策略将若干业务流程、若干服务分别部署至面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的至少一个节点上。面向服务的网络节点为完全处于面向服务的网络当中的节点；非面向服务的网络节点为完全处于非面向服务的网络当中的节点；面向服务的网络边缘节点为处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力的节点。

如图12所示，本实施例中，部署单元42包括业务流程部署子单元4201、实体服务部署子单元4202和公共服务部署子单元4203。业务流程部署子单元4201用于将业务流程部署于面向服务的网络节点或面向服务的网络边缘节点中；实体服务部署子单元4202用于将实体服务部署于面向服务的网络节点或面向服务的网络边缘节点中；公共服务部署子单元4203用于判断公共服务是否需要部署于非面向服务的网络节点，若否，则将公共服务部署于面向服务的网络节点或面向服务的网络边缘节点；若是，则将公共服务拆解为服务代理和服务能力，将服务能力部署于非面向服务的网络节点，将服务代理部署于面向服务的网络边缘节点中。

本实施例中，面向服务的网络节点对应的电子控制单元包括网关或远程处理信息终端或云端中处于以太网或Wi-Fi/4G网络中的节点；非面向服务的网络节点对应的电子控制单元包括座椅控制器或功放控制器或氛围灯或阅读灯中处于CAN、LIN或A2B网络中的节点；面向服务的网络边缘节点对应的电子控制单元包括智能座舱控制器中处于面向服务的网络以太网和非面向服务的网络CAN和LIN之间的节点。

本实施例整合了智能座舱服务层，提供了适用于智能座舱系统的服务分类方法，形成任务服务子层、实体服务子层、公共服务子层的服务管理体系，其中任务服务子层与服务抽象后得到的业务流程相对应。

本实施例提供的设计系统，融合传统智能座舱系统开发流程，扩展定义面向服务的系统架构开发层级任务和角色；将传统面向功能流程的智能座舱电子电器架构重构为面向服务的智能座舱电子电器架构，实现从业务逻辑中抽象服务；整合智能座舱服务层，形成任务服务子层、实体服务子层、公共服务子层的服务管理体系；基于本实施例中的服务管理体系，进一步设计了一套服务部署规则，简化服务部署复杂度；对无法满足功能服务化需求的静态交互网络，使用核心控制器进行服务代理，保证智能座舱系统内的所有功能对外完全服务化；本实施例提供的设计系统可实现自上而下的业务驱动的手段和自下向上遗留资产分析的手段综合应用，兼顾智能座舱系统服务化需求与遗留资产的有效利用。

本实施例在传统汽车系统架构开发流程下，扩展设计了一套面向服务的系统架构设计系统，实现自上而下的业务驱动的手段和自下向上遗留资产分析的手段综合应用，兼顾智能座舱系统服务化需求与对遗留资产的有效利用，为座舱系统架构向SOA范式过渡提供有效方案。使用本实施例所述的设计系统使智能座舱承载的功能从流程关系转变为服务调用关系，从而有效降低智能座舱系统架构耦合度；提升智能座舱产品软件服用度，降低软件开发、升级成本，缩短开发周期；新增功能调用原有可复用服务，提升智能座舱产品应用扩展性。

实施例3

本实施例提供了一种面向服务的智能座舱系统，智能座舱系统使用实施例1所公开的面向服务的智能座舱系统的设计方法设计得到。

本实施例提供的智能座舱系统承载的功能从流程关系转变为服务调用关系，从而有效降低智能座舱系统架构耦合度；提升智能座舱系统软件服用度，降低软件开发、升级成本，缩短开发周期；新增功能调用原有可复用服务，提升智能座舱产品应用扩展性。

虽然以上描述了本发明的具体实施方式，但是本领域的技术人员应当理解，这仅是举例说明，本发明的保护范围是由所附权利要求书限定的。本领域的技术人员在不背离本发明的原理和实质的前提下，可以对这些实施方式做出多种变更或修改，但这些变更和修改均落入本发明的保护范围。

Claims (9)

1.一种面向服务的智能座舱系统的设计方法，所述智能座舱系统包括若干电子控制单元；

其特征在于，所述设计方法包括：

S1、对所述智能座舱系统的功能业务流程进行服务抽象，以得到若干服务和若干业务流程；所述业务流程用于封装多个所述服务，以完成所需的业务逻辑组合；

S2、对若干所述服务进行分类，以得到实体服务和公共服务；所述实体服务为从功能逻辑抽象得出的服务，所述实体服务包括若干所述公共服务；所述公共服务为从功能逻辑中抽象得出的服务，所述公共服务为不可拆分的服务；

S3、将若干所述业务流程、若干所述服务分别部署至若干所述电子控制单元中的一个；

步骤S3包括以下步骤：

基于所述智能座舱系统的物理拓扑将每个所述电子控制单元分为面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的一类节点；

根据预设的服务部署策略将若干所述业务流程、若干所述服务分别部署至所述面向服务的网络节点、所述非面向服务的网络节点和所述面向服务的网络边缘节点中的至少一个节点上；

所述面向服务的网络节点为完全处于面向服务的网络当中的节点；

所述非面向服务的网络节点为完全处于非面向服务的网络当中的节点；

所述面向服务的网络边缘节点为处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力的节点；

所述根据预设的服务部署策略将若干所述业务流程、若干所述服务分别部署至所述面向服务的网络节点、所述非面向服务的网络节点和所述面向服务的网络边缘节点中的至少一个节点上的步骤包括：

将所述业务流程部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

将所述实体服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

判断所述公共服务是否需要部署于所述非面向服务的网络节点，若否，则将所述公共服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点；若是，则将所述公共服务拆解为服务代理和服务能力，将所述服务能力部署于所述非面向服务的网络节点，将所述服务代理部署于所述面向服务的网络边缘节点中；

所述面向服务的网络节点对应的所述电子控制单元包括网关或远程处理信息终端或云端中处于以太网或Wi-Fi/4G网络中的节点；

所述非面向服务的网络节点对应的所述电子控制单元包括座椅控制器或功放控制器或氛围灯或阅读灯中处于CAN、LIN或A2B网络中的节点；

所述面向服务的网络边缘节点对应的所述电子控制单元包括智能座舱控制器中处于面向服务的网络以太网和非面向服务的网络CAN和LIN之间的节点。

2.如权利要求1所述的面向服务的智能座舱系统的设计方法，其特征在于，所述设计方法还包括以下步骤：

S0、对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程。

3.如权利要求2所述的面向服务的智能座舱系统的设计方法，其特征在于，步骤S0包括以下步骤：

使用基于模型的系统工程工具对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程；

其中，所述功能业务流程为可视化功能逻辑模型。

4.如权利要求1所述的面向服务的智能座舱系统的设计方法，其特征在于，所述业务流程包括调用的所述服务的逻辑断点。

5.一种面向服务的智能座舱系统的设计系统，所述智能座舱系统包括若干电子控制单元；

其特征在于，所述设计系统包括：

服务抽象模块，用于对所述智能座舱系统的功能业务流程进行服务抽象，以得到若干服务和若干业务流程；所述业务流程用于封装多个所述服务，以完成所需的业务逻辑组合；

服务分类模块，用于对若干所述服务进行分类，以得到实体服务和公共服务；所述实体服务为从功能逻辑抽象得出的服务，所述实体服务包括若干所述公共服务；所述公共服务为从功能逻辑中抽象得出的服务，所述公共服务为不可拆分的服务；

部署模块，用于将若干所述业务流程、若干所述服务分别部署至若干所述电子控制单元中的一个；

所述部署模块包括节点分类单元和部署单元；

所述节点分类单元用于基于所述智能座舱系统的物理拓扑将每个所述电子控制单元分为面向服务的网络节点、非面向服务的网络节点和面向服务的网络边缘节点中的一类节点；

所述部署单元用于根据预设的服务部署策略将若干所述业务流程、若干所述服务分别部署至所述面向服务的网络节点、所述非面向服务的网络节点和所述面向服务的网络边缘节点中的至少一个节点上；

所述面向服务的网络节点为完全处于面向服务的网络当中的节点；

所述非面向服务的网络节点为完全处于非面向服务的网络当中的节点；

所述面向服务的网络边缘节点为处于面向服务的网络和非面向服务的网络边缘，具备连接非服务网络能力的节点；

所述部署单元包括业务流程部署子单元、实体服务部署子单元和公共服务部署子单元；

所述业务流程部署子单元用于将所述业务流程部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

所述实体服务部署子单元用于将所述实体服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点中；

所述公共服务部署子单元用于判断所述公共服务是否需要部署于所述非面向服务的网络节点，若否，则将所述公共服务部署于所述面向服务的网络节点或所述面向服务的网络边缘节点；若是，则将所述公共服务拆解为服务代理和服务能力，将所述服务能力部署于所述非面向服务的网络节点，将所述服务代理部署于所述面向服务的网络边缘节点中；

所述面向服务的网络节点对应的所述电子控制单元包括网关或远程处理信息终端或云端中处于以太网或Wi-Fi/4G网络中的节点；

所述非面向服务的网络节点对应的所述电子控制单元包括座椅控制器或功放控制器或氛围灯或阅读灯中处于CAN、LIN或A2B网络中的节点；

所述面向服务的网络边缘节点对应的所述电子控制单元包括智能座舱控制器中处于面向服务的网络以太网和非面向服务的网络CAN和LIN之间的节点。

6.如权利要求5所述的面向服务的智能座舱系统的设计系统，其特征在于，所述设计系统还包括流程生成模块；

所述流程生成模块用于对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程。

7.如权利要求6所述的面向服务的智能座舱系统的设计系统，其特征在于，所述流程生成模块用于使用基于模型的系统工程工具对所述智能座舱系统按照功能业务进行流程的定义，以形成若干与所述功能业务一一对应的所述功能业务流程；

其中，所述功能业务流程为可视化功能逻辑模型。

8.如权利要求5所述的面向服务的智能座舱系统的设计系统，其特征在于，所述业务流程包括调用的所述服务的逻辑断点。

9.一种面向服务的智能座舱系统，其特征在于，所述智能座舱系统使用如权利要求1至4任一项所述的面向服务的智能座舱系统的设计方法设计得到。