基于架构建模工具的通信模型生成方法、系统及电子设备

技术领域

本申请涉及通信领域，尤其涉及一种基于架构建模工具的通信模型生成方法、系统及电子设备。

背景技术

随着汽车智能化和网络化的发展，汽车自动驾驶、车载娱乐、远程诊断升级等技术对车载通信提出了更高的要求。车载以太网通信协议SomeIP(Scalable service-OrientedMiddlewareover IP)将以太网通信作为通信中间层运用到了车载通信领域。

在SomeIP协议实现的过程中，面向服务的发现和服务路由的底层实现比较固定，而面向业务应用的通信中间层实现起来复杂多变，需要对服务中包含的一组不同类型的接口进行实现和开发。若逐一对不同使用场景及业务数据进行服务接口的开发，会导致由于通信中间层的复杂多变而使得整个业务应用开发过程出现开发周期长、成本高等问题。

发明内容

有鉴于此，本申请提供一种基于架构建模工具的通信模型生成方法、系统及电子设备，其具体方案如下：

一种基于架构建模工具的通信模型生成方法，包括：

确定车载通信协议的客户端与服务端的通信时序；

确定车载通信协议的选定元素与建模元素之间的映射关系；

通过架构建模工具利用建模语言，基于所述通信时序及所述选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；

基于车载通信协议的需求服务信息对所述车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。

进一步的，所述确定车载通信协议的选定元素与建模元素之间的映射关系，包括：

基于车载通信协议的关键元素确定车载通信协议的选定元素；

基于所述选定元素确定与所述选定元素匹配的车载通信协议的建模元素；

建立所述车载通信协议的选定元素与建模元素之间的映射关系。

进一步的，所述基于车载通信协议的需求服务信息对所述车载通信协议的客户端与服务端的模型模板进行替换，包括：

从通信矩阵定义文件及配置文件获得车载通信协议的需求服务信息；

基于所述需求服务信息对所述车载通信协议的客户端与服务端的模型模板进行替换。

进一步的，所述基于所述需求服务信息对所述车载通信协议的客户端与服务端的模型模板进行替换，包括：

确定所述车载通信协议的客户端与服务端的模型模板的可变部分；

基于所述需求服务信息对所述车载通信协议的客户端与服务端的模型模板的可变部分进行替换。

进一步的，还包括：

获得所述客户端与服务端通信模型对应的代码信息；

确定编译测试环境；

在所述编译测试环境下对所述客户端与服务端通信模型对应的代码信息进行编译测试，确定所述编译测试是否通过。

进一步的，还包括：

若确定所述编译测试通过，则确定所述编译测试结束；

若确定所述编译测试未通过，则基于所述编译测试未通过时的编译提示信息调整所述客户端与服务端通信模型。

进一步的，还包括：

确定运行测试环境；

基于所述客户端与服务端通信模型在所述运行测试环境中部署协议栈及协议栈配置文件，以及应用及应用配置文件，其中，所述应用为由所述客户端或服务端通信模型编译得到的应用程序；

在所述运行测试环境下，基于所述协议栈运行所述应用，确定所述应用是否能够通过所述客户端与服务端通信模型进行通信，得到判断结果，基于所述判断结果确定所述运行测试是否通过。

进一步的，所述确定所述应用是否能够通过所述客户端与服务端通信模型进行通信，包括：

确定所述应用是否能够运行成功；

若确定所述应用能够运行成功，确定所述客户端与服务端通信模型中客户端的应用与服务端的应用是否能够通信成功；

若确定所述客户端的应用与服务端的应用运行不成功，确定所述应用及应用配置文件中服务实例名称是否一致，在确定所述应用及应用配置文件中服务实例名称不一致时，调整所述服务实例名称为一致后，重新启动所述应用。

一种基于架构建模工具的通信模型生成系统，包括：

第一确定单元，用于确定车载通信协议的客户端与服务端的通信时序；

第二确定单元，用于确定车载通信协议的选定元素与建模元素之间的映射关系；

模板构建单元，用于通过架构建模工具利用建模语言，基于所述通信时序及所述选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；

模型获得单元，用于基于车载通信协议的需求服务信息对所述车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。

一种电子设备，包括：

处理器，用于确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于所述通信时序及所述选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；基于车载通信协议的需求服务信息对所述车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型；

存储器，用于存储所述处理器执行上述处理过程的程序。

从上述技术方案可以看出，本申请公开的基于架构建模工具的通信模型生成方法、系统及电子设备，确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。本方案通过基于架构建模工具实现客户端与服务端的通信模型的建立，实现了自动进行通信模型的建立，降低了开发成本，将建立的通信模型作为通信中间层提高了通信中间层的开发效率，避免了开发人员基于不同场景或业务数据构建不同的通信中间层导致的开发周期延长的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种基于架构建模工具的通信模型生成方法的流程图；

图2为一种业务应用开发的模块示意图；

图3为本申请实施例公开的一种客户端与服务端的通信时序的示意图；

图4为本申请实施例公开的一种C/S通信模型在架构建模工具中实现的示意图；

图5为本申请实施例公开的一种基于架构建模工具的通信模型生成方法的流程图；

图6为本申请实施例公开的一种客户端与服务端的模型模板的示意图；

图7为本申请实施例公开的一种基于架构建模工具的通信模型生成方法的流程图；

图8为本申请实施例公开的一种服务端及客户端运行测试的示意图；

图9为本申请实施例公开的一种基于架构建模工具的通信模型生成及测试方法的流程图；

图10为本申请实施例公开的一种基于架构建模工具的通信模型生成系统的结构示意图；

图11为本申请实施例公开的一种电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请公开了一种基于架构建模工具的通信模型生成方法，其流程图如图1所示，包括：

步骤S11、确定车载通信协议的客户端与服务端的通信时序；

步骤S12、确定车载通信协议的选定元素与建模元素之间的映射关系；

步骤S13、通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；

步骤S14、基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。

SOMEIP是车载以太网的一种通信协议，在业务应用开发的过程中，通信协议的实现变动会导致业务应用变化，大大增加业务应用开发人员的负担。

以自动驾驶领域为例，在进行业务应用开发时，涉及到的主要功能模块及功能模块之间的关系如图2所示，包括：调度模块21，数据获取通信模块22，算法模块23及数据发送通信模块24。其中，业务应用由多个子系统组成每个子系统包括一个数据获取通信模块22、一个算法模块23及一个数据发送通信模块24。调度模块用于产生周期信号，来控制不同子系统的执行；在子系统内部，数据获取通信模块用于获取外部控制器的实时数据，并传递给算法模块；算法模块进行数据处理，处理完成后将数据传递给数据发送通信模块；数据发送通信模块负责将处理后的数据发送出去。

上述各模块的开发均是由应用开发工具实现的，即上述任一模块发生变化时，均需要业务应用开发人员对业务应用进行重新开发，由于业务应用中，通常通信中间层较为复杂多变，因此，对业务应用进行重新开发大多是由于通信中间层的变化导致的，如：通信协议的接口或信号发生变化，从而导致由于通信中间层的实现多变而使得业务应用的开发效率低的问题。

基于此，本方案公开的通信模型生成方法中，直接基于架构建模工具进行通信模型的生成，而对于业务开发过程中除通信中间层之外的算法部分，则由算法开发工具实现，这就使得本实施例公开的方案能够基于实际需求自动实现通信模型的生成，而业务开发人员仅需要关注算法模块的开发即可，无需考虑通信中间层及通信协议适配的问题，大大提高了业务应用的开发效率，并且，通过自动生成通信模型的方式还能够降低开发成本。

确定车载通信协议SOMEIP的客户端与服务端C/S的通信时序，即服务端驱动、服务端、车载以太网、客户端、客户端驱动之间数据发送与接收的时序。服务端与客户端之间的数据交互使用到事件(Event)和方法(Method)两种方式。具体的，可以如图3所示，即使用不同的数据传递方式时客户端与服务端C/S的通信时序。

具体的，在服务发现过程中，客户端寻找车载以太网中可用的服务实例，服务端通过车载以太网为客户端提供服务，客户端通过车载以太网进行事件订阅。

使用事件进行数据交互时，服务端驱动和服务端通过端口进行连接，客户端驱动与客户端通过端口进行连接。服务端驱动通过端口发送携带数据的Rhapsody事件，服务端接收到Rhapsody事件后触发调用事件类的send方法，通过车载以太网向外发送数据；客户端从车载以太网获取数据，并通过端口发送携带数据的Rhapsody事件至客户端驱动，客户端驱动接收到Rhapsody事件后触发并执行相关操作。

其中，Rhapsody可以为架构建模工具。

使用FF方法(Fire&Forget“发后即忘”)进行数据交互时，服务端驱动和服务端通过端口进行连接，客户端驱动与客户端通过端口进行连接。客户端驱动通过端口发送携带数据的Rhapsody事件，客户端接收到Rhapsody事件后触发并执行操作，通过车载以太网向外发送数据并调用服务端的FF方法；服务端执行FF方法，通过车载以太网获取数据并通过端口发送携带数据的Rhapsody事件，服务端驱动接收到Rhapsody事件后触发并执行操作。

使用RR方法(Request&Response请求&响应)进行数据交互时，服务端驱动和服务端通过端口进行连接，客户端驱动与客户端通过端口进行连接。服务端驱动通过端口发送携带数据1的Rhapsody事件，服务端接收到Rhapsody事件后触发接收数据1并保存的操作；客户端驱动通过端口发送携带数据2的Rhapsody事件，客户端接收到Rhapsody事件后触发调用操作，通过车载以太网向外发送数据2，调用服务端的RR方法；服务端执行RR方法，通过车载以太网获取数据2并返回数据1给客户端。

在获得通信时序后，还需要获得车载通信协议SOMEIP的选定元素与建模UML元素之间的映射关系，之后可直接基于通信时序及该映射关系构建SOMEIP的C/S的模型模板。

由于本实施例公开的方案，直接在架构建模工具上构建通信模型，则直接在架构建模工具Rhapsody上，利用建模语言构建SOMEIP的C/S的模型模板，而模型模板的构建需要利用获得的客户端与服务端之间的通信时序以及选定元素与建模元素之间的映射关系，因此，在架构建模工具上，利用建模语言，通过确定的通信时序以及映射关系构建SOMEIP的C/S的模型模板。

在SOMEIP的C/S的模型模板构建完成后，要实现由模型模板到通信模型的变化，需要替换模型模板中的部分内容，需要替换的内容为车载通信协议SOMEIP的需求服务信息，将模型模板中的SOMEIP的服务信息部分替换为实际的需求服务信息，从而得到构建完成的SOMEIP的客户端与服务端C/S通信模型。

通过生成的C/S通信模型作为通信中间层，该C/S通信模型在架构建模工具中实现，如图4所示，调度模块及通信模块均在架构建模工具中实现，只有算法模块在算法开发工具中实现，业务开发人员只需要关注算法模块中算法的开发即可，而对于架构建模工具中的调度模块及数据获取通信模块、数据发送通信模块，则通过架构建模工具自动生成。其中，本实施例中的客户端与服务端C/S通信模型由图4中的调度模块、数据获取通信模块及数据发送通信模块组成。

本实施例中，通过需求服务信息填充模型模板，从而得到C/S通信模型的自动生成，提高了开发效率，并且，复用性高，可维护性好。

本实施例公开的基于架构建模工具的通信模型生成方法，确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。本方案通过基于架构建模工具实现客户端与服务端的通信模型的建立，实现了自动进行通信模型的建立，降低了开发成本，将建立的通信模型作为通信中间层的实现提高了通信中间层的开发效率，避免了开发人员基于不同场景或业务数据构建不同的通信模型导致的开发周期延长的问题。

本实施例公开了一种基于架构建模工具的通信模型生成方法，其流程图如图5所示，包括：

步骤S51、确定车载通信协议的客户端与服务端的通信时序；

步骤S52、确定车载通信协议的选定元素与建模元素之间的映射关系；

步骤S53、通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；

步骤S54、从通信矩阵定义文件及配置文件获得车载通信协议的需求服务信息；

步骤S55、基于需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。

通信矩阵通常由整车厂完成定义，车辆网络中的各个节点需要遵循该通信矩阵才能完成信息的交互和共享。

通信矩阵定义文件中包含服务信息和对应该服务信息的服务方法接口信息，服务信息为服务名称，服务方法接口信息包括方法接口类型、方法接口名、方法接口参数等；配置文件中包含服务名称、服务类别和服务实例名称等信息。

若要获得需求服务信息，可直接通过解析通信矩阵定义文件和配置文件即可获得，通过需求服务信息填充C/S模型模板以生成相应服务接口的类模型。

确定需求服务信息是为了对车载通信协议SOMEIP的客户端与服务端C/S的模型模板中的信息进行补充，以使得最终获得的C/S通信模型能够更符合实际需求。因此，确定需求服务信息实际是从通信矩阵定义文件及配置文件中选取符合实际需求的服务信息作为需求服务信息，以填充至C/S模型模板中。

进一步的，确定车载通信协议的选定元素与建模元素之间的映射关系，可以为：

基于车载通信协议的关键元素确定车载通信协议的选定元素；基于选定元素确定与选定元素匹配的车载通信协议的建模元素；建立车载通信协议的选定元素与建模元素之间的映射关系。

车载通信协议SOMEIP中的关键元素有多个，车载通信协议的建模UML元素也有很多。根据通信模型的实际需求从SOMEIP中的多个关键元素中选择需求的元素，将选择的SOMEIP中的需求的元素确定为选定元素。选定元素确定后，可根据SOMEIP中的选定元素从UML元素中选择部分元素作为当前需求的通信模型进行模型模板构建的建模元素。

在根据通信模型的实际需求确定SOMEIP中的关键元素中的选定元素及UML元素中的建模元素后，建立选定元素与建模元素之间的映射关系，如表1所示，为选定元素与建模元素之间的映射关系。

表1

根据表1所示，当SOMEIP中的关键元素选定为ServiceInterface(服务接口)时，则可从UML元素中确定Class为对应的建模元素；当SOMEIP中的关键元素选定为Event(事件)时，则可从UML元素中确定EventReception为对应的建模元素等。

在SOMEIP的选定元素与UML中的建模元素建立映射关系后，在架构建模工具上，利用UML建模语言，搭建与SOMEIP的选定元素及UML中的建模元素以及通信时序对应的模型模板，如图6所示。

另外，还可以为：直接基于架构建模工具Rhapsody提供的JavaAPI接口进行插件开发，而插件预定义了C/S模型模板，在进行通信模型的构建时，直接从插件预定义的多个C/S模型模板中选择需求的C/S模型模板，基于实际的需求服务信息对选择的C/S模型模板进行填充，以获得实际需求的C/S通信模型。通过这样的方式能够提高C/S通信模型的创建速度，提高了开发效率。

其中，C/S模型模板中包括可变部分和不可变部分，不可变部分是每一个C/S通信模型的通用部分，无需对其进行调整或填充，而可变部分是能够根据实际需求的服务信息进行确定的，即将从通信矩阵定义文件及配置文件中获取的需求服务信息填充至C/S模型模板的可变部分中，以生成C/S通信模型，或者，也可以直接利用需求服务信息替换C/S模型模板的可变部分，从而生成C/S通信模型。

本实施例公开的基于架构建模工具的通信模型生成方法，确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；从通信矩阵定义文件及配置文件获得车载通信协议的需求服务信息，基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。本方案通过基于架构建模工具实现客户端与服务端的通信模型的建立，实现了自动进行通信模型的建立，降低了开发成本，将建立的通信模型作为通信中间层的实现提高了通信中间层的开发效率，避免了开发人员基于不同场景或业务数据构建不同的通信模型导致的开发周期延长的问题。

本实施例公开了一种基于架构建模工具的通信模型生成方法，其流程图如图7所示，包括：

步骤S71、确定车载通信协议的客户端与服务端的通信时序；

步骤S72、确定车载通信协议的选定元素与建模元素之间的映射关系；

步骤S73、通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；

步骤S74、基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型；

步骤S75、获得客户端与服务端通信模型对应的代码信息；

步骤S76、确定编译测试环境；

步骤S77、在编译测试环境下对客户端与服务端通信模型对应的代码信息进行编译测试，确定编译测试是否通过。

在车载通信协议SOMEIP的客户端与服务端C/S通信模型构建完成后，需要对其进行编译，而在编译之前，可首先进行编译测试，只有当编译测试通过后，才进行实际编译。

具体的，在编译测试过程中，首先构建编译测试环境，可通过开源应用容器引擎Docker作为编译测试环境进行编译测试；并且，基于生成的客户端与服务端C/S通信模型进行代码生成，以获得C/S通信模型对应的代码信息。在构建的编译测试环境下对代码信息进行编译测试，以确定编译测试是否通过，是否需要对C/S通信模型进行调整。

可具体在编译测试环境下执行CMake和Make命令进行代码编译，若能够生成二进制文件，则表明编译测试通过，即编译测试结束；若未能生成二进制文件，则表明编译测试未通过。

当编译测试未通过时，输出编译提示信息，该编译提示信息用于表明编译出现问题的提示信息，如：编译测试未通过原因，或者，编译错误类型等。

当编译测试未通过时，可基于编译提示信息调整客户端与服务端C/S通信模型的相关实现，之后再重新生成调整后的C/S通信模型的代码，基于重新生成的代码进行重新编译，以确定调整后的C/S通信模型是否通过编译测试。

进一步的，当编译测试完成后，还可进行运行测试，具体的：

确定运行测试环境；基于客户端与服务端通信模型在运行测试环境中部署协议栈及协议栈配置文件，以及应用及应用配置文件，其中，应用为由客户端或服务端通信模型编译得到的应用程序；在运行测试环境下，基于协议栈运行应用，确定应用是否能够通过客户端与服务端通信模型进行通信，得到判断结果，基于判断结果确定运行测试是否通过。

在运行测试过程中，首先构建运行测试环境，可通过开源应用容器引擎Docker作为运行测试环境进行运行测试；之后将协议栈及协议栈配置文件部署至运行测试环境中，以完成运行测试环境中的协议栈及协议栈配置文件的部署；另外，还需要将应用及应用配置文件部署到运行测试环境，以完成运行测试环境中的应用及应用配置文件的部署。

在运行测试环境中完成协议栈及协议栈配置文件的部署，以及，应用及应用配置文件的部署后，能够在运行测试环境中执行运行测试，此时，可启动应用，确定应用是否运行成功，若应用运行成功，则需测试C/S通信模型是否能够通信，若应用运行不成功，则需要检查应用及应用配置文件中的服务实例名称是否一致，若不一致，则需调整应用及应用配置文件中的服务实例名称为一致，之后将调整后的应用及应用配置文件重新配置到运行测试环境中，在完成应用及应用配置文件的部署后，重新启动应用，对应用运行是否成功进行判断。

若应用运行成功，则检查C/S通信模型是否能够通信，即客户端的应用与服务端的应用能够进行通信，且通信成功。若客户端的应用与服务端的应用能够互相收发数据，并且收发数据正确，则可确定通信成功，即通过运行测试；若通信失败，如：客户端的应用与服务端的应用不能互相收发数据，或者，客户端的应用与服务端的应用互相收发数据，但是互相收发的数据不准确，则确定通信失败，此时，检测客户端所在的运行测试环境及服务端所在的运行测试环境的网络连接是否正常，即是否能够互相Ping通，若确定客户端所在的运行测试环境及服务端所在的运行测试环境的网络连接正常，则可检测应用及应用配置文件中的服务实例名称是否一致，并在一致时，重复执行将应用及应用配置文件部署到运行测试环境中，并启动应用，进行应用运行及C/S通信的测试，以便于当运行测试不成功时，能够及时调整，保证运行测试的完成。

具体的，可以如图8所示，分别为服务端及客户端搭建运行测试环境，服务端的运行测试环境为Docker1，客户端的运行测试环境为Docker2，服务端的应用部署在Docker1上，客户端的应用部署在Docker2上，服务端的应用包括：服务端驱动测试TestDrive_S及服务端Server，客户端的应用包括：客户端驱动测试TestDrive_C及客户端Client，通过网络配置实现Docker之间的通信，在Docker1和Docker2上分别配置了ara::com通信堆栈，启动后可以在不同容器的应用之间建立通信路径，图8中虚线标识双向的数据链路。

在以事件进行数据传输时，服务端应用的TestDrive_S发送携带数据的事件，Server收到TestDrive_S发送的事件后触发向外发送数据的操作，通过Docker1和Docker2之间的通信路径传输该数据，客户端应用的Client通过以太网获取数据并将其发送给TestDrive_C；

在以方法进行数据传输时，客户端应用的TestDrive_C发送携带数据的事件，Client收到TestDrive_C发送的事件后触发并调用Server提供的方法，Server将接收到的数据发送给TestDrive_S。

TestDrive_S和TestDrive_C将发送和获取的数据记录到日志文件中。若TestDrive_S生成的日志文件中记录的发送数据和TestDrive_C生成的日志文件中记录的接收数据完全一致，则可确定通信成功。

另外，本实施例公开的基于架构建模工具的通信模型生成方法，其完整的开发及测试流程可以如图9所示，包括：1、定制SOMEIP概要文件；2、添加SOMEIP概要文件，完成C/S建模；3、模型到代码生成；4、编译、运行测试；5、概要文件优化。

其中，1、定制SOMEIP概要文件；2、添加SOMEIP概要文件，完成C/S建模；3、模型到代码生成；及5、概要文件优化，这些步骤均属于模型搭建的过程，而编译、运行测试，则属于应用部署的过程。

SOMEIP概要文件可以为：完成C/S建模，即生成C/S通信模型。

通过将用于生成C/S通信模型的数据作为SOMEIP概要文件的输入，以生成C/S通信模型，其中用于生成C/S通信模型的数据可以为：需求服务信息，通信时序、映射关系等；另外，还可以对概要文件进行优化，即基于编译测试结果和/或运行测试结果对C/S通信模型的概要文件进行优化，以达到对C/S通信模型的调整。

本方案通过在C/S通信模型生成后，进行编译测试及运行测试，以达到对C/S通信模型及代码的功能性校验的目的。

本实施例公开的基于架构建模工具的通信模型生成方法，确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型；确定编译测试环境；获得客户端与服务端通信模型对应的代码信息；在编译测试环境下对客户端与服务端通信模型对应的代码信息进行编译测试，确定编译测试是否通过。本方案通过基于架构建模工具实现客户端与服务端的通信模型的建立，实现了自动进行通信模型的建立，降低了开发成本，将建立的通信模型作为通信中间层的实现提高了通信中间层的开发效率，避免了开发人员基于不同场景或业务数据构建不同的通信中间层导致的开发周期延长的问题；另外，本实施例公开的方案不仅能够生成通信模型，还能够对通信模型进行测试，并在未通过编译测试或运行测试时，对通信模型进行调整，保证了通信模型能够正常编译和运行，提高了开发效率。

本实施例公开了一种基于架构建模工具的通信模型生成系统，其结构示意图如图10所示，包括：

第一确定单元101，第二确定单元102，模板构建单元103及模型获得单元104。

其中，第一确定单元101用于确定车载通信协议的客户端与服务端的通信时序；

第二确定单元102用于确定车载通信协议的选定元素与建模元素之间的映射关系；

模板构建单元103用于通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；

模型获得单元104用于基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。

进一步的，第二确定单元用于：

基于车载通信协议的关键元素确定车载通信协议的选定元素；基于选定元素确定与选定元素匹配的车载通信协议的建模元素；建立车载通信协议的选定元素与建模元素之间的映射关系。

进一步的，模型获得单元用于：

从通信矩阵定义文件及配置文件获得车载通信协议的需求服务信息；基于需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换。

进一步的，模型获得单元用于：

确定车载通信协议的客户端与服务端的模型模板的可变部分；基于需求服务信息对车载通信协议的客户端与服务端的模型模板的可变部分进行替换。

进一步的，本实施例公开的系统还可以包括：

编译测试单元，用于获得客户端与服务端通信模型对应的代码信息；确定编译测试环境；在编译测试环境下对客户端与服务端通信模型对应的代码信息进行编译测试，确定编译测试是否通过。

进一步的，编译测试单元还用于：

若确定编译测试通过，则确定编译测试结束；若确定编译测试未通过，则基于编译测试未通过时的编译提示信息调整客户端与服务端通信模型。

进一步的，本实施例公开的系统还可以包括：

运行测试单元，用于确定运行测试环境；基于客户端与服务端通信模型在运行测试环境中部署协议栈及协议栈配置文件，以及应用及应用配置文件，其中，应用为由客户端或服务端通信模型编译得到的应用程序；在运行测试环境下，基于协议栈运行所述应用，确定应用是否能够通过客户端与服务端通信模型进行通信，得到判断结果，基于判断结果运行编译测试是否通过。

进一步的，运行测试单元还用于：

确定应用是否能够运行；若确定应用能够运行，确定客户端与服务端通信模型中客户端的应用与服务端的应用是否能够通信成功。

进一步的，运行测试单元还用于：

若确定客户端的应用与服务端的应用通信失败，确定客户端的运行测试环境与服务端的运行测试环境之间是否网络连通。

本实施例公开的基于架构建模工具的通信模型生成系统是基于上述实施例公开的基于架构建模工具的通信模型生成方法实现的，在此不再赘述。

本实施例公开的基于架构建模工具的通信模型生成系统，确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。本方案通过基于架构建模工具实现客户端与服务端的通信模型的建立，实现了自动进行通信模型的建立，降低了开发成本，将建立的通信模型作为通信中间层实现提高了通信中间层的开发效率，避免了开发人员基于不同场景或业务数据构建不同的通信中间层导致的开发周期延长的问题。

本实施例公开了一种电子设备，其结构示意图如图11所示，包括：

处理器111及存储器112。

其中，处理器111用于确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型；

存储器112用于存储处理器执行上述处理过程的程序。

本实施例公开的电子设备是基于上述实施例公开的基于架构建模工具的通信模型生成方法实现的，在此不再赘述。

本实施例公开的电子设备，确定车载通信协议的客户端与服务端的通信时序；确定车载通信协议的选定元素与建模元素之间的映射关系；通过架构建模工具利用建模语言，基于通信时序及选定元素与建模元素之间的映射关系构建车载通信协议的客户端与服务端的模型模板；基于车载通信协议的需求服务信息对车载通信协议的客户端与服务端的模型模板进行替换，获得车载通信协议的客户端与服务端通信模型。本方案通过基于架构建模工具实现客户端与服务端的通信模型的建立，实现了自动进行通信模型的建立，降低了开发成本，将建立的通信模型作为通信中间层实现提高了通信中间层的开发效率，避免了开发人员基于不同场景或业务数据构建不同的通信模型导致的开发周期延长的问题。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。