一种汽车服务化模型框架生成方法、装置、设备及介质

技术领域

本申请涉及软件开发技术领域，具体涉及一种汽车服务化模型框架生成方法、装置、设备及介质。

背景技术

随着汽车电气化、智能化、网联化的不断发展，形成了软件定义汽车的趋势，传统的软件架构已经不能完全满足汽车对智能化的需求，SOA(Service-OrientedArchitecture，面向服务的架构)逐渐应用于汽车上。

SOA使得汽车上众多的场景功能由服务组成，服务可以是算法也可以是方法。现有的技术中，针对众多不同类型的服务对应的模型进行人工开发时，不仅会因为服务庞大的数量导致开发效率低下，还会因为人工开发导致命名错误、参数配置错误等低级软件缺陷。

因此，如何高效开发服务化模型并降低开发时的低级软件缺陷，是目前亟需解决的问题。

发明内容

鉴于以上所述现有技术的缺点，本申请的目的在于提供一种汽车服务化模型框架生成方法、装置、设备及介质，用于解决现有技术中如何高效开发服务化模型并降低开发时的低级软件缺陷的问题。

为实现上述目的及其他相关目的，本申请提供一种汽车服务化模型框架生成方法，所述方法包括：

获取汽车域控制器配置信息和汽车软件系统功能场景需求信息；

根据所述汽车域控制器配置信息和汽车软件系统功能场景需求信息，将汽车功能划分为多个服务，并调用所述多个服务对应的服务接口配置信息；

根据所述服务接口配置信息和预先配置的脚本，构建所述多个服务对应的多个初始模型框架，并在所述多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，以生成多个完整的汽车服务化模型框架。

于本申请的一实施例中，所述服务接口配置信息包括：

服务清单信息，所述服务清单信息包括服务名称、服务接口名称、服务接口类型、接口参数名称；

接口参数定义信息，所述接口参数定义信息包括接口参数数据类型、接口参数数值定义。

于本申请的一实施例中，调用所述多个服务对应的服务接口配置信息之后，还包括：

将所述服务清单信息转换为第一变量，将所述接口参数定义信息转化为第二变量，所述第一变量和第二变量用于添加所述初始化模块、主函数模块、服务调用接口和通知接口时的信息调用。

于本申请的一实施例中，构建所述多个服务对应的多个初始模型框架，并在所述多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，包括：

调用所述第一变量，遍历所述第一变量以确定所述多个服务的服务清单信息；

根据所述多个服务清单的服务清单信息和所述第二变量，构建每个服务对应的初始模型框架，并在所述每个服务对应的初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口。

于本申请的一实施例中，所述构建每个服务对应的初始模型框架之后，还包括：

根据所述服务名称，对每个所述初始模型框架命名，得到命名后的多个初始模型框架；

根据所述汽车软件系统功能场景需求信息，设置所述命名后的多个初始模型框架的初始配置参数，所述初始配置参数包括求解器类型参数、求解器配置参数、固定步长中的至少一种。

于本申请的一实施例中，所述在所述每个服务对应的初始模型框架中添加初始化模块，包括：

将预先配置的模型搭建环境库中的初始化函数添加至所述初始模型框架中的第一位置，并根据所述服务名称和预设的第一后缀，对所述初始化函数命名；

删除命名后的初始化函数中除事件侦听器外的内容，完成所述初始化模块的添加。

于本申请的一实施例中，在所述每个服务对应的初始模型框架中添加主函数模块，包括：

在所述初始模型框架中添加一个初始子系统，根据所述服务名称和预设的第二后缀对所述初始子系统命名，并删除命名后的所述初始子系统中的内容，得到目标子系统；

将第一触发器添加至所述目标子系统，以通过所述第一触发器获取预设的触发器函数并进行触发类型选取和调用；

将第一输入子模块添加至所述初始模型框架，根据所述服务名称对所述第一输入子模块命名，并根据预设的周期参数设置所述第一输入子模块的运行周期，得到配置完成的所述第一输入子模块；

将配置完成的所述第一输入子模块与所述第一触发器的接口连接，完成所述主函数模块的添加。

于本申请的一实施例中，所述服务调用接口包括第一类服务调用接口，在所述每个服务对应的初始模型中添加服务调用接口，包括：

根据所述服务接口配置信息中的服务接口类型，判断所述服务调用接口是否为服务端回复响应报文接口或客户端请求获取状态接口；

若所述服务调用接口为服务端回复响应报文接口或客户端请求获取状态接口，则确定所述服务调用接口为第一类服务调用接口；

在所述初始模型框架中添加第一初始模型搭建环境函数，并通过所述服务名称和所述第一类服务调用接口的名称对所述第一初始模型搭建环境函数进行命名，得到第一目标模型搭建环境函数；

删除所述第一目标模型搭建环境函数中除第二触发器之外的内容，根据所述服务名称和所述第一类服务调用接口的名称对所述第二触发器的函数名称进行命名，并设置所述第二触发器的可见性为全局可见；

根据所述第二变量，通过预设的入参模块的库路径和出参模块的库路径为所述第一目标模型搭建环境函数添加入参和出参，完成所述服务调用接口的添加。

于本申请的一实施例中，所述根据所述第二变量，通过预设的入参模块的库路径和出参模块的库路径为所述第一目标模型搭建环境函数添加入参和出参，包括：

根据所述第一服务调用接口的名称，确定所述入参模块和所述出参模块中的目标参数，所述目标参数的参数名称与所述第一服务调用接口的名称一致；

在所述第二变量中搜索所述第一服务调用接口的名称，确定所述第一类服务调用接口对应的配置参数的第一数据类型，并根据所述第一数据类型确定所述入参模块和出参模块的数据类型字符串；

根据所述入参模块和出参模块的数据类型字符串，将所述目标参数通过预设的入参模块的库路径和出参模块的库路径传输至所述第一目标模型搭建环境函数。

于本申请的一实施例中，其特征在于，所述服务调用接口包括第二类服务调用接口，在所述每个服务对应的初始模型中添加服务调用接口，包括：

根据所述服务接口配置信息中的服务接口类型，判断所述服务调用接口是否为客户端请求设置状态接口；

若所述服务调用接口为客户端请求设置状态接口，则确定所述服务调用接口为第二类服务调用接口；

将第二初始模型搭建环境函数添加至所述初始模型框架，并通过所述服务名称和所述第二类服务调用接口的名称对所述第二初始模型搭建环境函数进行命名，得到第二目标模型搭建环境函数；

删除所述第二目标模型搭建环境函数中除第二触发器之外的内容，根据所述服务名称和所述第二类服务调用接口的名称对所述第二触发器的函数名称进行命名，并设置所述第二触发器的可见性为全局可见；

根据所述第二变量，通过预设的出参模块的库路径为所述第二目标模型搭建环境函数添加出参；

在所述第二目标模型搭建环境函数中添加第二输入子模块，并将所述主函数模块的通知接口与所述第二输入子模块的输入接口连接。

于本申请的一实施例中，所述通知接口包括第一通知接口和第二通知接口，在所述多个初始模型框架中添加通知接口，包括：

在所述主函数模块中添加第一初始输出子模块，并根据所述服务名称和通知接口的名称对所述第一初始输出子模块命名，得到第一目标输出子模块；

在所述第二变量中搜索所述通知接口的参数名称，确定所述通知接口对应的参数的第二数据类型，并通过所述第二数据类型设置所述第一目标输出子模块的数据类型字符串，完成所述主函数模块内部第一通知接口的添加；

搜索所述主函数模块中的全部输出子模块，根据搜索结果在所述主函数模块外添加第二通知接口，并将名称相同的所述第一通知接口和所述第二通知接口相连接，完成所述通知接口的添加。

于本申请的一实施例中，所述将名称相同的所述第一通知接口和所述第二通知接口相连接之后，还包括：

将所述第二类服务调用接口与所述通知接口对应连接，并将所述第二类服务调用接口的出参与所述通知接口的输入参数保持一致。

于本申请的一实施例中，还提供了一种汽车服务化模型框架生成装置，所述装置包括：

信息获取模块，用于获取汽车域控制器配置信息和汽车软件系统功能场景需求信息；

服务接口配置信息确定模块，用于根据所述汽车域控制器配置信息和汽车软件系统功能场景需求信息，将汽车功能划分为多个服务，并调用所述多个服务对应的服务接口配置信息；

模型生成模块，用于根据所述服务接口配置信息和预先配置的脚本，构建所述多个服务对应的多个初始模型框架，并在所述多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，以生成多个完整的汽车服务化模型框架。

于本申请的一实施例中，还提供了一种电子设备，所述电子设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现如上所述的汽车服务化模型框架生成方法。

于本申请的一实施例中，还提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被计算机的处理器执行时，使计算机执行如上所述的汽车服务化模型框架生成方法。

本发明的有益效果：

首先获取汽车域控制器配置信息和汽车软件系统功能场景需求信息；然后根据所述汽车域控制器配置信息和汽车软件系统功能场景需求信息，将汽车功能划分为多个服务，并调用所述多个服务对应的服务接口配置信息；最后根据所述服务接口配置信息和预先配置的脚本，构建所述多个服务对应的多个初始模型框架，并在所述多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，以生成多个完整的汽车服务化模型框架。本发明中，可通过预先配置的脚本在模型搭建环境中实现服务化模型框架的生成，能够自动完成服务化模型框架开发过程中重复性规则性的工作，提高了服务化模型的开发效率，另外通过脚本还能降低开发过程中的低级软件缺陷，整体节约汽车SOA架构下软件开发项目的时间成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是本申请的一示例性实施例示出的汽车服务化模型框架生成方法的实施环境示意图；

图2是本申请的一示例性实施例示出的汽车服务化模型框架生成方法的流程示意图；

图3是本申请的一示例性实施例示出的汽车服务化模型框架生成装置的框图；

图4示出了适于本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

以下将参照附图和优选实施例来说明本发明的实施方式，本领域技术人员可由本说明书中所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。应当理解，优选实施例仅为了说明本发明，而不是为了限制本发明的保护范围。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

在下文描述中，探讨了大量细节，以提供对本发明实施例的更透彻的解释，然而，对本领域技术人员来说，可以在没有这些具体细节的情况下实施本发明的实施例是显而易见的，在其他实施例中，以方框图的形式而不是以细节的形式来示出公知的结构和设备，以避免使本发明的实施例难以理解。

首先需要说明的是，随着汽车新四化的趋势，现在新的汽车消费群体对车的要求也已经发生了巨大的改变，车在全面实现网联、自动驾驶、数据驱动的同时，也更趋向于直接触达用户，提升体验、服务，满足用户的个性化需求。SOA是一种软件架构，同时一种软件设计的思想，在SOA架构中，服务是最核心的抽象手段和系统最基础的单元。每个服务具备独立的功能，服务之间的接口遵循统一的标准，可互相访问，可组合扩展。基于SOA，将汽车整体的场景功能划分为众多服务以供调用时，需要针对不同的服务生成对应的模型。在人工生成服务化模型时，需要进行大量具有重复性和/或规律性的工作，例如模型参数设置、模块命名、参数命名、数据类型设置，而当人工进行上述工作时会因服务数量的庞大产生命名错误、参数设置错误等低级软件缺陷，同时大量模型生成工作将会增加汽车软件开发项目的整体时间成本。

以下对本申请中的各技术名词进行说明：

Simulink：Simulink是MATLAB(一种数学软件)中的一种可视化仿真工具。Simulink是一个模块图环境、模型搭建环境，用于多域仿真以及基于模型的设计。它支持系统设计、仿真、自动代码生成以及嵌入式系统的连续测试和验证。Simulink提供图形编辑器、可自定义的模块库以及求解器，能够进行动态系统建模和仿真。Simulink与MATLAB相集成，能够在Simulink中将MATLAB算法融入模型，还能将仿真结果导出至MATLAB做进一步分析。Simulink应用领域包括汽车、航空、工业自动化、大型建模、复杂逻辑、物理逻辑，信号处理等方面。

Subsystem：即为子系统，随着模型大小和复杂性的增加，可以通过将块分组为子系统。子系统是一组分组到单个子系统块中的块。使用子系统时，遵循以下步骤：建立分层框图，其中子系统块在一层上，构成子系统的块在另一层；将功能相关的块保持在一起；帮助减少模型窗口中显示的块数；建立与输入和输出的接口。子系统可以是虚拟的，也可以是非虚拟的。虚拟子系统在模型中提供图形层次结构。非虚拟子系统提供图形层次结构，并作为模型中的一个单元执行。

Function Visbility：即为函数可见性，可见性是从对标识符的引用的角度来谈的概念。可见性表示从内层作用域向外层作用域＂看＂时能看见什么，如果标识在某处可见，则就可以在该处引用此标识符。标识符应声明在前，引用在后。如果某个标识符在外层中声明，且在内层中没有同一标识符的声明，则该标识符在内层可见。对于两个嵌套的作用域，如果在内层作用域内声明了与外层同名的则在内层不可见。

OutDataTypeStr：即为数据类型字符串，“数据类型字符串”参数用于指定数据类型。与任何封装参数类似，数据类型字符串可以从封装编辑器添加到封装对话框中。将数据类型字符串添加到封装对话框将允许模块的最终用户为关联的编辑类型参数指定可接受的数据类型。在定义封装时，可以为编辑类型参数指定单个或多个数据类型，模块的最终用户可以从这些数据类型中选择。为编辑参数指定数据类型可为通过封装对话框提供的输入值定义规则。数据类型字符串还允许为编辑参数指定最小值和最大值，通过使用最小和最大封装参数并将这些参数与数据类型字符串关联。

图1是本申请的一示例性实施例示出的汽车服务化模型框架生成方法的实施环境示意图。

参照图1所示，实施环境中可以包括汽车服务化模型框架生成终端101、云端102和信息存储终端103。汽车服务化模型框架生成终端101可包括平板电脑、笔记本电脑、台式电脑等电子设备，用于服务划分和服务化模型的生成。云端102可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器，可用于存储汽车域控制器配置信息和汽车软件系统功能场景需求信息。信息存储终端103用于与开发人员交互以获取汽车软件系统功能场景需求信息，并对汽车域控制器配置信息和汽车软件系统功能场景需求信息进行存储。

另外，本申请实施例提供的技术方案可以应用于汽车服务化模型框架生成终端101，汽车服务化模型框架生成终端101用于通过网络连接云端102和信息存储终端103并获取汽车域控制器配置信息和汽车软件系统功能场景需求信息，同时云端102和信息存储终端103还接收汽车服务化模型框架生成终端101生成的服务化模型框架并存储。

在本申请的一实施例中，汽车服务化模型框架生成终端101获取汽车域控制器配置信息和汽车软件系统功能场景需求信息；根据所述汽车域控制器配置信息和汽车软件系统功能场景需求信息，将汽车功能划分为多个服务，并调用所述多个服务对应的服务接口配置信息；根据所述服务接口配置信息和预先配置的脚本，构建所述多个服务对应的多个初始模型框架，并在所述多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，以生成多个完整的汽车服务化模型框架。本实施例中，可通过预先配置的脚本在模型搭建环境中实现服务化模型框架的生成，能够自动完成服务化模型框架开发过程中重复性规则性的工作，提高了服务化模型的开发效率，另外通过脚本还能降低开发过程中的低级软件缺陷，整体节约汽车SOA架构下软件开发项目的时间成本。

以上部分介绍了应用本申请技术方案的示例性实施环境的内容，接下来继续介绍本申请的汽车服务化模型框架生成方法。

为解决现有技术中如何高效开发服务化模型并降低开发时的低级软件缺陷的问题，本申请的实施例分别提出一种汽车服务化模型框架生成方法、一种汽车服务化模型框架生成装置、一种电子设备、一种计算机可读存储介质以及一种计算机程序产品，以下将对这些实施例进行详细描述。

请参阅图2，图2是本申请的一示例性实施例示出的汽车服务化模型框架生成方法的流程示意图，该方法可以应用于图1所示的实施环境。应理解的是，该方法也可以适用于其它的示例性实施环境，并由其它实施环境中的设备具体执行，本实施例不对该方法所适用的实施环境进行限制。

如图2所示，在一示例性的实施例中，汽车服务化模型框架生成方法至少包括步骤S210至步骤S230，详细介绍如下：

在步骤S210中，获取汽车域控制器配置信息和汽车软件系统功能场景需求信息。

首先需要说明的是，根据汽车电子部件功能将整车划分为动力总成、智能座舱和自动驾驶等几个域，利用处理能力更强的多核CPU/GPU芯片相对集中的控制每个域，以取代目前分布式电子电气架构。通过汽车域控制器配置信息，能够确定在当前配置下域控制器主要负责的功能；通过汽车软件系统功能场景需求信息，能够确定在不同的场景下ECU(Electronic Control Unit，电子控制单元)需要实现的功能。本申请实施例中，基于汽车域控制器配置信息和汽车软件系统功能场景需求信息，可将整车功能划分为多个不同的服务，服务中可包括实现某种具体分支功能的算法或方法，然后通过同一规范确定的接口进行相互调用，以实现特定场景下的功能。

另外，在将功能划分为服务后，需要针对大量的不同服务构建模型，再将当前实际参数输入模型中进行计算、仿真等。

在步骤S220中，根据汽车域控制器配置信息和汽车软件系统功能场景需求信息，将汽车功能划分为多个服务，并调用多个服务对应的服务接口配置信息。

需要说明的是，服务接口配置信息包括：服务清单信息，包括服务名称、服务接口名称、服务接口类型、接口参数名称；接口参数定义信息，包括接口参数数据类型、接口参数数值定义。本申请实施例中对服务接口配置信息的说明仅做示例，并不局限于此，可以理解的，在本申请实施例之外的具体实施方案中，可根据当前场景的需求确定本申请实施例之外的其他服务接口配置信息。

在步骤S230中，根据服务接口配置信息和预先配置的脚本，构建多个服务对应的多个初始模型框架，并在多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，以生成多个完整的汽车服务化模型框架。

需要说明的是，本申请实施例中服务化模型框架的生成过程是在基于Simulink和MATLAB相集成的环境中实现的。预先配置的脚本为m语言脚本，m语言脚本是以.m拓展名的程序文件，在这些文件中，可以编写一系列要一起执行的命令。脚本不接受输入，不返回任何输出。它们对MATLAB工作空间中的数据进行操作。本申请实施例中，通过m语言脚本来进行参数设置、模块命名、参数命名、数据类型设置等具有规律性和重复性的工作，进一步提高了汽车软件系统开发的效率。

另外，在服务化模型框架生成后，开发人员后续可根据系统需求，在服务调用接口中添加逻辑，为主函数模块添加输入，在主函数模块中添加逻辑，完成完整服务化模型的生成。

由上述步骤S210至S230可知，本实施例提出的方案，通过m语言脚本在Simulink环境中实现服务化模型框架的生成，能够自动完成服务化模型框架开发过程中重复性规则性的工作，提高了服务化模型的开发效率，另外通过m语言脚本还能降低开发过程中的低级软件缺陷，整体节约汽车SOA架构下软件开发项目的时间成本。

在本申请的一实施例中，图2所示步骤S220中的调用所述多个服务对应的服务接口配置信息之后，还包括如下步骤：

将所述服务清单信息转换为第一变量，将所述接口参数定义信息转化为第二变量，所述第一变量和第二变量用于添加所述初始化模块、主函数模块、服务调用接口和通知接口时的信息调用。

示例性的，将服务接口配置信息通过表数据的方式进行传输，其中，sheet1(表1)中存储服务清单信息，sheet2(表2)中存储接口参数定义信息。通过m语言脚本获取并读取两张表中的内容，并使用两个变量将两个表中的内容存储在Matlab工作空间中，以供后续使用。

在本申请的一实施例中，图2所示的步骤S230中的构建所述多个服务对应的多个初始模型框架，并在所述多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，包括如下步骤：

调用所述第一变量，遍历所述第一变量以确定所述多个服务的服务清单信息；

根据所述多个服务清单的服务清单信息和所述第二变量，构建每个服务对应的初始模型框架，并在所述每个服务对应的初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口。

示例性的，每一个服务对应着一个模型，通过m语言脚本在第一变量中对不同名称的服务进行遍历，并对每一个服务都执行初始模型框架构建、模块添加、接口添加的步骤，以避免在每个服务化模型框架的生成过程中出现低级软件缺陷。

在本申请的一实施例中，构建每个服务对应的初始模型框架之后，还包括如下步骤：

根据所述服务名称，对每个所述初始模型框架命名，得到命名后的多个初始模型框架；

根据所述汽车软件系统功能场景需求信息，设置所述命名后的多个初始模型框架的初始配置参数，所述初始配置参数包括求解器类型参数、求解器配置参数、固定步长中的至少一种。

需要说明的是，构建初始模型框架后，以当前服务的名称对初始模型框架命名，再根据汽车软件系统功能场景需求信息配置SolverType、Solver、FixedStep等初始配置参数。其中，SolverType为求解器类型参数，Solver为求解器配置参数，FixedStep为固定步长。

本申请实施例中，通过对求解器的相关参数进行设置，以搭建初始模型框架中的初始环境，为后续添加模块和接口做准备，求解器的配置影响着Simulink环境中生成的模型的质量。求解器是Simulink提供的一组程序，每个求解器代表一种特定的模型解算方法。模型的合适求解器取决于以下特性：系统动态特性、解稳定性、计算速度、求解器稳健性。

求解器可大致按两个属性分类：

(1)按计算步长类型分类

定步长求解器使用相同的步长从仿真开始到仿真结束来解算模型，可以指定步长，也可以让求解器选择步长。一般情况下，减小步长将提高结果的准确性，并增加系统仿真所需的时间。变步长求解器会在仿真过程中改变长。变步长求解器减小步长，以提高某些事件(如快速状态变化、过零事件等)的精度。另外，当模型状态变化缓慢时，求解器将增加步长以避免执行不必要的步长。

(2)按模型状态分类

连续求解器用数值积分方法，根据模型在上一个时间步的状态和状态导数来计算模型在当前时间步的连续状态，连续求解器依赖单个模块来计算模型在每个时间步的离散状态值。离散求解器主要用于解算纯离散模型，只计算模型的下一个仿真时间步。

在本申请的一实施例中，在所述每个服务对应的初始模型框架中添加初始化模块，包括如下步骤：

将预先配置的模型搭建环境库中的初始化函数添加至所述初始模型框架中的第一位置，并根据所述服务名称和预设的第一后缀，对所述初始化函数命名；

删除命名后的初始化函数中除事件侦听器外的内容，完成所述初始化模块的添加。

示例性的，在模型指定位置添加初始化模块，即将simulink库中的InitializeFunction添加至指定位置，并以服务名称加“_Init”命名，然后删除初始化函数中自带的内容，仅保留Event Listener。其中，Initialize Function即为初始化函数，_Init即为第一后缀，Event Listener即为事件侦听器。

在本申请的一实施例中，在所述每个服务对应的初始模型框架中添加主函数模块，包括如下步骤：

在所述初始模型框架中添加一个初始子系统，根据所述服务名称和预设的第二后缀对所述初始子系统命名，并删除命名后的所述初始子系统中的内容，得到目标子系统；

将第一触发器添加至所述目标子系统，以通过所述第一触发器获取预设的触发器函数并进行触发类型选取和调用；

将第一输入子模块添加至所述初始模型框架，根据所述服务名称对所述第一输入子模块命名，并根据预设的周期参数设置所述第一输入子模块的运行周期，得到配置完成的所述第一输入子模块；

将配置完成的所述第一输入子模块与所述第一触发器的接口连接，完成所述主函数模块的添加。

示例性的，首先，添加一个Subsystem，并以服务名称加“_Ctrl”命名，并删除Subsystem中自带的内容；然后，在Subsystem中添加Trigger，并将TriggerType设置为function-call；最后，添加输入模块In1，以“TMT10ms_”加服务名称命名，10ms为运行周期，并设置OutputFunctionCall为ON，SampleTime为0.01，再将In1与Subsystem的Trigger接口连线。其中，Subsystem为子系统，_Ctrl为第二后缀，Trigger为触发器，TriggerType为触发器类型，function-call为函数调用(表示通过触发器函数对触发器进行选取和调用)，OutputFunctionCall为输出函数调用开关，SampleTime为采样时间。

在本申请的一实施例中，所述服务调用接口包括第一类服务调用接口，在所述每个服务对应的初始模型中添加服务调用接口，包括如下步骤：

根据所述服务接口配置信息中的服务接口类型，判断所述服务调用接口是否为服务端回复响应报文接口或客户端请求获取状态接口；

若所述服务调用接口为服务端回复响应报文接口或客户端请求获取状态接口，则确定所述服务调用接口为第一类服务调用接口；

在所述初始模型框架中添加第一初始模型搭建环境函数，并通过所述服务名称和所述第一类服务调用接口的名称对所述第一初始模型搭建环境函数进行命名，得到第一目标模型搭建环境函数；

删除所述第一目标模型搭建环境函数中除第二触发器之外的内容，根据所述服务名称和所述第一类服务调用接口的名称对所述第二触发器的函数名称进行命名，并设置所述第二触发器的可见性为全局可见；

根据所述第二变量，通过预设的入参模块的库路径和出参模块的库路径为所述第一目标模型搭建环境函数添加入参和出参，完成所述服务调用接口的添加。

示例性的，第一类服务调用接口为RR_Method类和Setter类服务调用接口，对于RR_Method类和Setter类服务调用接口，在模型中添加Simulink Function，以服务名称加“_”加接口名称命名，并删除其中自带的内容，仅保留Trigger，并设置Trigger的FunctionName为服务名称加“_”加接口名称，设置FunctionVisibility为global。然后根据该接口的参数信息，为Simulink Function添加入参和出参，入参模块的库路径为“simulink/User-Defined Functions/Simulink Function/u”，出参模块的库路径为“simulink/User-Defined Functions/Simulink Function/y”。

其中，RR_Method类服务调用接口为服务端回复响应报文接口，Setter类服务调用接口为客户端请求获取状态接口，Simulink Function为simulink函数，FunctionName为函数名称，FunctionVisibility为函数可见性，global为全局可见。

在本申请的一实施例中，所述根据所述第二变量，通过预设的入参模块的库路径和出参模块的库路径为所述第一目标模型搭建环境函数添加入参和出参，包括如下步骤：

根据所述第一服务调用接口的名称，确定所述入参模块和所述出参模块中的目标参数，所述目标参数的参数名称与所述第一服务调用接口的名称一致；

在所述第二变量中搜索所述第一服务调用接口的名称，确定所述第一类服务调用接口对应的配置参数的第一数据类型，并根据所述第一数据类型确定所述入参模块和出参模块的数据类型字符串；

根据所述入参模块和出参模块的数据类型字符串，将所述目标参数通过预设的入参模块的库路径和出参模块的库路径传输至所述第一目标模型搭建环境函数。

示例性的，参数模块的ArgumentName设置为第一变量中该接口的参数名称，然后通过在参数定义变量中搜索参数名称，获得该参数的数据类型，用以设置参数模块的OutDataTypeStr。其中，ArgumentName为函数名称，OutDataTypeStr为数据类型字符串。

在本申请的一实施例中，所述服务调用接口包括第二类服务调用接口，在所述每个服务对应的初始模型中添加服务调用接口，包括如下步骤：

根据所述服务接口配置信息中的服务接口类型，判断所述服务调用接口是否为客户端请求设置状态接口；

若所述服务调用接口为客户端请求设置状态接口，则确定所述服务调用接口为第二类服务调用接口；

将第二初始模型搭建环境函数添加至所述初始模型框架，并通过所述服务名称和所述第二类服务调用接口的名称对所述第二初始模型搭建环境函数进行命名，得到第二目标模型搭建环境函数；

删除所述第二目标模型搭建环境函数中除第二触发器之外的内容，根据所述服务名称和所述第二类服务调用接口的名称对所述第二触发器的函数名称进行命名，并设置所述第二触发器的可见性为全局可见；

根据所述第二变量，通过预设的出参模块的库路径为所述第二目标模型搭建环境函数添加出参；

在所述第二目标模型搭建环境函数中添加第二输入子模块，并将所述主函数模块的通知接口与所述第二输入子模块的输入接口连接。

示例性的，第二类服务调用接口为Getter类服务调用接口，Getter类服务调用接口与RR_Method类和Setter类服务调用接口的添加方式一样，也是添加SimulinkFunction，但是Getter类服务调用接口只有出参。由于Getter类服务调用接口的出参就是通知的事件参数，所以需要在该Simulink Function中添加In1模块，然后将主函数模块的通知接口，与对应的Getter类服务调用接口的Simulink Function的输入接口相连，并在连线上设置名称，以“IRV_”加通知Out1模块名称命名。其中，Getter类服务调用接口为客户端请求设置状态接口。

在本申请的一实施例中，所述通知接口包括第一通知接口和第二通知接口，在所述多个初始模型框架中添加通知接口，包括如下步骤：

在所述主函数模块中添加第一初始输出子模块，并根据所述服务名称和通知接口的名称对所述第一初始输出子模块命名，得到第一目标输出子模块；

在所述第二变量中搜索所述通知接口的参数名称，确定所述通知接口对应的参数的第二数据类型，并通过所述第二数据类型设置所述第一目标输出子模块的数据类型字符串，完成所述主函数模块内部第一通知接口的添加；

搜索所述主函数模块中的全部输出子模块，根据搜索结果在所述主函数模块外添加第二通知接口，并将名称相同的所述第一通知接口和所述第二通知接口相连接，完成所述通知接口的添加。

示例性的，首先在主函数模块中添加输出Out1模块，同样命名为服务名称加“_”加接口名称，再通过在第二变量中搜索该通知接口的事件参数名称，获得该参数的数据类型，用以设置输出Out1模块的OutDataTypeStr。通过搜索主函数模块中的全部Out1模块，在主函数模块外面再次添加通知接口，并将同名接口相连。

在本申请的一实施例中，所述将名称相同的所述第一通知接口和所述第二通知接口相连接之后，还包括如下步骤：

将所述第二类服务调用接口与所述通知接口对应连接，并将所述第二类服务调用接口的出参与所述通知接口的输入参数保持一致。

示例性的，在接口设计时，将Getter类服务调用接口与通知接口一一对应，Getter类服务调用接口的出参与通知接口的事件参数保持一致。本实施例中，在添加主函数模块外部的通知接口的时候，可同时添加该通知接口对应的Getter类服务调用接口。

图3是本申请的一示例性实施例示出的汽车服务化模型框架生成装置的框图。该装置可以应用于图1所示的实施环境。该装置也可以适用于其它的示例性实施环境，并具体配置在其它设备中，本实施例不对该装置所适用的实施环境进行限制。

如图3所示，该示例性的汽车服务化模型框架生成装置包括：

信息获取模块301，用于获取汽车域控制器配置信息和汽车软件系统功能场景需求信息；

服务接口配置信息确定模块302，用于根据所述汽车域控制器配置信息和汽车软件系统功能场景需求信息，将汽车功能划分为多个服务，并调用所述多个服务对应的服务接口配置信息；

模型生成模块303，用于根据所述服务接口配置信息和预先配置的脚本，构建所述多个服务对应的多个初始模型框架，并在所述多个初始模型框架中添加初始化模块、主函数模块、服务调用接口和通知接口，以生成多个完整的汽车服务化模型框架。

在该示例性的汽车服务化模型框架生成装置中，通过m语言脚本在Simulink环境中实现服务化模型框架的生成，能够自动完成服务化模型框架开发过程中重复性规则性的工作，提高了服务化模型的开发效率，另外通过m语言还能降低开发过程中的低级软件缺陷，整体节约汽车SOA架构下软件开发项目的时间成本。

需要说明的是，上述实施例所提供的汽车服务化模型框架生成装置与上述实施例所提供的汽车服务化模型框架生成方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。上述实施例所提供的汽车服务化模型框架生成装置在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制。

本申请的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述各个实施例中提供的汽车服务化模型框架生成方法。

图4示出了适于本申请实施例的电子设备的计算机系统的结构示意图。需要说明的是，图4示出的电子设备的计算机系统400仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图4所示，计算机系统400包括中央处理单元(Central Processing Unit，CPU)401，其可以根据存储在只读存储器(Read-Only Memory，ROM)402中的程序或者从储存部分408加载到随机访问存储器(Random Access Memory，RAM)403中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 403中，还存储有系统操作所需的各种程序和数据。CPU 401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(Input/Output，I/O)接口405也连接至总线404。

以下部件连接至I/O接口405：包括键盘、鼠标等的输入部分406；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分407；包括硬盘等的储存部分408；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分409。通信部分409经由诸如因特网的网络执行通信处理。驱动器410也根据需要连接至I/O接口405。可拆卸介质411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器410上，以便于从其上读出的计算机程序根据需要被安装入储存部分408。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分409从网络上被下载和安装，和/或从可拆卸介质411被安装。在该计算机程序被中央处理单元(CPU)401执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被计算机的处理器执行时，使计算机执行如前所述的汽车服务化模型框架生成方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的汽车服务化模型框架生成方法。

上述实施例仅示例性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，但凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。