一种数据交互的方法、系统、装置、设备和存储介质与流程

1.本技术涉及数据交互的领域，具体而言，涉及一种数据交互的方法、系统、装置、设备和存储介质。


背景技术：

2.随着汽车行业的更新迭代，汽车行业正不断向着智能化、电动化、数字化发展。
3.但是，随着研发的不断深入，为了使软件能满足更复杂的应用场景需求，功能迭代频繁，目前软件和系统实现的功能相对更加固定，每一套软件和系统都需要最新的开发，造成资源的浪费。
4.因此，如何节省软件和系统开发的资源，是一个需要解决的技术问题。


技术实现要素：

5.本技术实施例的目的在于提供一种数据交互的方法，通过本技术的实施例的技术方案可以达到节省软件和系统开发的资源的效果。
6.第一方面，本技术实施例提供了一种数据交互的方法，应用于soa架构系统，当系统应用于车端时，所述方法包括，获取车端的应用场景需求，其中，应用场景需求包括对车端操作控制的需求；基于应用场景需求，获取应用场景需求对应的配置文件；基于配置文件，获取应用场景需求对应的应用程序。
7.在上述过程中，根据场景需求，配置对应的配置文件，进而生成不同功能的应用程序，可以达到节省软件和系统开发的资源的效果。
8.一种实施例中，基于应用场景需求，获取应用场景需求对应的配置文件，包括：
9.基于应用场景需求，修改车端应用程序对应的配置文件，得到修改后的配置文件；
10.或者
11.将应用场景需求发送给云端，并接收云端发送的修改后的配置文件，其中修改后的配置文件是云端根据应用场景需求对车端的应用程序对应的配置文件进行修改得到的。
12.在上述过程中，车端和云端都可以实现配置文件的配置，进而实现不同场景需求下的不同的软件功能，节省了软件和系统开发的资源。
13.一种实施例中，基于配置文件，获取应用场景需求对应的应用程序，包括：
14.基于配置文件，生成配置文件对应的应用程序；
15.或者
16.基于配置文件，获取云端发送的应用程序，其中，应用程序是云端根据修改后的配置文件生成的应用程序。
17.在上述过程中，车端和云端可以根据得到的配置文件生成不同功能的应用程序，来满足不同场景的需求。
18.第二方面，本技术实施例提供了一种数据交互的方法，应用于soa架构系统，当系统应用于云端时，所述方法包括，接收车端发送的应用场景需求，其中，应用场景需求包括
对车端操作控制的需求；基于应用场景需求修改配置文件，得到修改后的配置文件。
19.在上述过程中，云端可以对配置文件进行修改，可以得到不同功能的配置文件，进而实现不同场景下不同需求的功能，节省了应用程序开发的资源。
20.一种实施例中，在基于应用场景需求修改配置文件，得到修改后的配置文件之后，还包括：
21.利用修改后的配置文件，在数字孪生原型车中验证配置文件对应程序的功能。
22.在上述过程中，云端可以根据模型车进行程序的验证，可以保证程序开发满足不同场景下的需求。
23.一种实施例中，在基于应用场景需求修改配置文件，得到修改后的配置文件之后，还包括：
24.基于修改后的配置文件，生成应用程序，将应用程序发送给车端；
25.或者
26.将修改后的配置文件发送给车端。
27.在上述过程中，云端可以将配置文件发送给车端，车端根据配置文件生成新的功能，云端也可以直接根据修改的配置文件生成新的应用程序，实现不同场景需求下不同的功能。
28.第三方面，本技术实施例提供了一种数据交互的系统，包括：车端和云端；
29.车端包括基础软件和应用软件；
30.基础软件部分包括基础软件模块和通信协议接口模块；
31.应用软件包括第一服务引擎模块、数据引擎模块、第一场景引擎模块、服务路由模块和车端应用模块；
32.云端包括数据服务器模块、数据存储库模块、数字孪生原型车模块、数据挖掘套件模块、第二场景引擎模块、第二服务引擎模块、升级模块和云端应用模块。
33.一种实施例中，基础软件模块，用于提供构建汽车开放系统架构的标准软件平台；
34.通信协议接口模块，用于提供传输数据信息的通信接口；
35.第一服务引擎模块，用于转换通信接口，以信号的形式传输数据信息；
36.数据引擎模块，用于收集车端的数据信息，并筛选、过滤出感兴趣的应用场景需求发送给云端；
37.第一场景引擎模块，用于确定应用场景需求中车端操作控制的需求；
38.服务路由模块，用于将车内协议的服务接口转换成车外协议的服务接口；
39.车端应用模块，用于编辑应用程序的接口；
40.数据服务器模块，用于接收车端发送的应用场景需求；
41.数据存储库模块，用于将应用场景需求分类存储；
42.数字孪生原型车模块，用于验证应用程序的功能；
43.数据挖掘套件模块，用于组合应用场景需求中车端操作控制的需求；
44.第二场景引擎，用于确定应用场景需求中车端操作控制的需求；
45.第二服务引擎模块，用于转换通信接口，以信号的形式传输数据信息；
46.升级模块，用于向车端发送不同功能的应用程序；
47.云端应用模块，用于根据用户需求自定义应用程序的功能。
48.第四方面，本技术实施例提供了一种数据交互的装置，包括：
49.第一获取模块，用于获取车端的应用场景需求，其中，应用场景需求包括对车端操作控制的需求；
50.第二获取模块，用于基于应用场景需求，获取应用场景需求对应的配置文件；
51.第三获取模块，用于基于配置文件，获取应用场景需求对应的应用程序。
52.可选的，第二获取模块具体用于：
53.基于应用场景需求，修改车端应用程序对应的配置文件，得到修改后的配置文件；
54.或者
55.将应用场景需求发送给云端，并接收云端发送的修改后的配置文件，其中修改后的配置文件是云端根据应用场景需求对车端的应用程序对应的配置文件进行修改得到的。
56.可选的，第三获取模块具体用于：
57.基于配置文件，生成配置文件对应的应用程序；
58.或者
59.基于配置文件，获取云端发送的应用程序，其中，应用程序是云端根据修改后的配置文件生成的应用程序。
60.第五方面，本技术实施例提供了一种数据交互的装置，包括：
61.接收模块，用于接收车端发送的应用场景需求，其中，应用场景需求包括对车端操作控制的需求；
62.修改模块，用于基于应用场景需求修改配置文件，得到修改后的配置文件。
63.可选的，所述装置还包括：
64.验证模块，用于所述修改模块在基于应用场景需求修改配置文件，得到修改后的配置文件之后，利用修改后的配置文件，在数字孪生原型车中验证配置文件对应程序的功能。
65.可选的，所述装置还包括：
66.发送模块，用于所述修改模块在基于应用场景需求修改配置文件，得到修改后的配置文件之后，基于修改后的配置文件，生成应用程序，将应用程序发送给车端；
67.或者
68.将修改后的配置文件发送给车端。
69.第六方面，本技术实施例提供一种电子设备，包括处理器以及存储器，所述存储器存储有计算机可读取指令，当所述计算机可读取指令由所述处理器执行时，运行如上述第一方面或第二方面提供的所述方法中的步骤。
70.第七方面，本技术实施例提供一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时运行如上述第一方面或第二方面提供的所述方法中的步骤。
71.本技术的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本技术实施例了解。本技术的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
72.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使
用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
73.图1为本技术实施例提供的一种数据交互的方法的流程图；
74.图2为本技术实施例提供的另一种数据交互的方法的流程图；
75.图3为本技术实施例提供的一种数据交互的系统的示意框图；
76.图4为本技术实施例提供的一种采用服务引擎的方案和不采用服务引擎的方案对比的示意图；
77.图5为本技术实施例提供的一种采用数据引擎的方案的示意图；
78.图6为本技术实施例提供的一种数据交互的装置的示意框图；
79.图7为本技术实施例提供的另一种数据交互的装置的示意框图；
80.图8为本技术实施例提供的一种数据交互的装置的结构示意框图；
81.图9为本技术实施例提供的另一种数据交互的装置的结构示意框图。
具体实施方式
82.下面将结合本技术实施例中附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。通常在此处附图中描述和显示出的本技术实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本技术的实施例的详细描述并非旨在限制要求保护的本技术的范围，而是仅仅表示本技术的选定实施例。基于本技术的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
83.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本技术的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
84.首先对本技术实施例中涉及的部分用语进行说明，以便于本领域技术人员理解。
85.soa：service-oriented architecture,一种面向服务的架构开发理念，是一个组件模型，它将应用程序的不同功能单元(称为服务)进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
86.cp：classic platform，经典平台。
87.ap：adaptive platform，自适应平台。是满足autosar标准的软件平台。
88.some/ip：(scalable service-oriented middleware over ip)，基于ip的可扩展面向服务的中间件，提供面向服务的通信接口。
89.tcp/ip：(transmission control protocol/internet protocol，传输控制协议/网际协议)，是能够在多个不同网络间实现信息传输的协议簇。
90.ota：(over the air，空中升级)模块实现ota云端部分功能，云端可通过ota模块将更新的应用程序向车端发放。
91.本技术应用于数据交互的场景，具体场景为通过车端、云端中场景引擎和服务引
擎等模块之间的配合，根据场景的需求，配置不同的功能的配置文件，根据配置文件省生成不同功能的软件和系统。
92.但是，随着研发的不断深入，为了使软件能满足更复杂的应用场景需求，功能迭代频繁，目前软件和系统实现的功能相对更加固定，每一套软件和系统都需要最新的开发，造成资源的浪费。
93.为此本技术通过获取车端的应用场景需求，其中，应用场景需求包括对车端操作控制的需求；基于应用场景需求，获取应用场景需求对应的配置文件；基于配置文件，获取应用场景需求对应的应用程序。通过该方法可以达到节省软件和系统开发的资源的效果。
94.本技术实施例中，执行主体可以为数据交互系统中的数据交互设备，实际应用中，数据交互设备可以为车端设备、云端设备、终端设备和服务器等电子设备，在此不做限制。
95.下面结合图1对本技术实施例的数据交互的方法进行详细描述。
96.请参看图1，图1为本技术实施例提供的一种数据交互的方法的流程图，应用于soa架构系统，当系统应用于车端时，如图1所示的数据交互的方法包括：
97.步骤110：获取车端的应用场景需求。
98.在上述过程中，根据不同的场景需求，车端可以采集对应的驾驶需求和用户操作需求等。
99.其中，应用场景需求包括对车端操作控制的需求，例如，当用户左转时，对应的应用场景需求可以为开启左转向灯；当用户临时停车时，对应的应用场景需求可以为打开双闪灯；当检测为夜间行驶时，对应的应用场景需求可以为开启近光灯。
100.步骤120：基于应用场景需求，获取应用场景需求对应的配置文件。
101.在上述过程中，不同的场景下的配置文件不同，通过获取不同功能场景下的配置文件，可以实现更多的场景功能，节省应用程序开发的资源。
102.其中，配置文件为场景需求的配置文件，通过修改配置文件中各个功能的组合，可以实现更多新的功能。
103.具体的，在执行步骤120时，可以采用以下步骤：
104.基于应用场景需求，修改车端应用程序对应的配置文件，得到修改后的配置文件；或者将应用场景需求发送给云端，并接收云端发送的修改后的配置文件。
105.在上述过程中，车端和云端都可以实现配置文件的配置，进而实现不同场景需求下的不同的软件功能，节省了软件和系统开发的资源。
106.其中修改后的配置文件是云端根据应用场景需求对车端的应用程序对应的配置文件进行修改得到的。
107.步骤130：基于配置文件，获取应用场景需求对应的应用程序。
108.在上述过程中，根据场景需求，获取对应的应用程序，实现场景需求对应的场景功能。
109.其中，车端可以根据自身的配置文件或者云端发送的配置文件生成对应功能的应用程序，也可以直接获取云端发送的应用程序，实现对应的功能。
110.具体的，在执行步骤130时，可以采用以下步骤：
111.基于配置文件，生成配置文件对应的应用程序；或者基于配置文件，获取云端发送的应用程序。
112.在上述过程中，车端和云端可以根据得到的配置文件生成不同功能的应用程序，来满足不同场景的需求。
113.其中，应用程序是云端根据修改后的配置文件生成的应用程序。
114.在上述过程中，根据场景需求，配置对应的配置文件，进而生成不同功能的应用程序，可以达到节省软件和系统开发的资源的效果。
115.请参看图2，图2为本技术实施例提供的另一种数据交互的方法的流程图，应用于soa架构系统，当系统应用于云端时，如图2所示的数据交互的方法包括：
116.步骤210：接收车端发送的应用场景需求。
117.在上述过程中，云端通过接收车端发送的场景需求，可以根据需求配置不同功能的要应用程序，节省开发应用程序的时间。
118.其中，应用场景需求包括对车端操作控制的需求。
119.步骤220：基于应用场景需求修改配置文件，得到修改后的配置文件。
120.在上述过程中，云端可以对配置文件进行修改，可以得到不同功能的配置文件，进而实现不同场景下不同需求的功能，节省了应用程序开发的资源。
121.进一步的，在执行步骤220之后，还可以采用以下步骤：
122.利用修改后的配置文件，在数字孪生原型车中验证配置文件对应程序的功能。
123.在上述过程中，云端可以根据模型车进行程序的验证，可以保证程序开发满足不同场景下的需求。
124.其中，孪生原型车中是根据实际车辆中配置出的原型车模型。
125.进一步的，在执行步骤220之后，还可以采用以下步骤：
126.基于修改后的配置文件，生成应用程序，将应用程序发送给车端；或者将修改后的配置文件发送给车端。
127.在上述过程中，云端可以将配置文件发送给车端，车端根据配置文件生成新的功能，云端也可以直接根据修改的配置文件生成新的应用程序，实现不同场景需求下不同的功能。
128.一种实施例中，本技术在系统上有了很大的改进，下面对系统有关的内容进行详细的描述。
129.传统方式下，车端向云端上传数据的数据内容、上传周期都是固定好的，无法快速进行上传数据的数据内容、上传周期的更改。例如，预设好的上传策略是：当出现转向系统故障(报出特定的转向系统故障码)的时候，车端将转向系统的3个信号按照100ms的周期向云端上传，这个策略是固定的，传统方式下不易更改。而在实际应用过程中，为了排查故障问题，可能需要新增第4个信号，同时为了分析问题，需将第4个信号的上传周期设定为50ms。应对这种场景需求，可以通过本案中的场景引擎器实现新增信号、上传周期的更改，并通过更改数据引擎中的过滤配置表(实现动态更新上传的数据内容)、存储配置表(实现动态更新上传数据的周期)，最终实现此场景需求。
130.此外，场景引擎器中的数据没有与数据处理模块进行共享，现有产品场景引擎器中的数据获取与数据处理模块的数据处理相互独立，造成资源浪费。场景引擎和数据处理模块是独立的，即场景引擎负责对场景进行编辑、管理，数据处理模块负责对数据进行过滤、存储、上传，这两个模块是独立的，场景引擎编辑的内容不影响(或不关联)数据处理模
块。而在本案中，场景引擎与数据处理模块(即数据引擎)进行关联及共享，场景引擎通过更新过滤配置表、存储配置表，控制数据引擎对于数据的过滤、存储，由车端数据引擎、云端数据引擎进行数据交互，实现了场景与数据间的关联，可以通过场景编辑结果有效控制数据的过滤、存储、压缩、上传，实现数据资源、上传带宽的有效利用。(详见下文对于场景引擎的描述)。
131.最后，存在数据处理模块与服务处理模块强耦合问题，目前数据处理模块对服务类型的数据进行获取过程中，通过自身创建服务连接的方式，耦合度高，不利于软件复用。即，上层应用通过数据处理模块来获取数据，传统方案是通过创建服务连接的方式来获取，这样会创建多个服务连接，不利于对服务的统一调度和管理。本案中，通过引入服务引擎，实现数据处理模块与服务处理模块的解耦。(详见下文对于服务引擎的描述)。
132.下面结合图3-图5描述数据交互的装置，对装置中各个模块进行详细的描述。
133.请参照图3，为本技术实施例中提供的一种数据交互的系统300的示意框图，该系统300包括：车端和云端；
134.车端包括基础软件和应用软件；
135.基础软件部分包括基础软件模块和通信协议接口模块；
136.应用软件包括第一服务引擎模块、数据引擎模块、第一场景引擎模块、服务路由模块和车端应用模块；
137.云端包括数据服务器模块、数据存储库模块、数字孪生原型车模块、数据挖掘套件模块、第二场景引擎模块、第二服务引擎模块、升级模块和云端应用模块。
138.一种实施例中，基础软件模块，用于提供构建汽车开放系统架构的标准软件平台；
139.通信协议接口模块，用于提供传输数据信息的通信接口；
140.第一服务引擎模块，用于转换通信接口，以信号的形式传输数据信息；
141.数据引擎模块，用于收集车端的数据信息，并筛选、过滤出感兴趣的应用场景需求发送给云端；
142.第一场景引擎模块，用于确定应用场景需求中车端操作控制的需求；
143.服务路由模块，用于将车内协议的服务接口转换成车外协议的服务接口；
144.车端应用模块，用于编辑应用程序的接口；
145.数据服务器模块，用于接收车端发送的应用场景需求；
146.数据存储库模块，用于将应用场景需求分类存储；
147.数字孪生原型车模块，用于验证应用程序的功能；
148.数据挖掘套件模块，用于组合应用场景需求中车端操作控制的需求；
149.第二场景引擎，用于确定应用场景需求中车端操作控制的需求；
150.第二服务引擎模块，用于转换通信接口，以信号的形式传输数据信息；
151.升级模块，用于向车端发送不同功能的应用程序；
152.云端应用模块，用于根据用户需求自定义应用程序的功能。
153.其中，基础软件包括，cp、some/ip和tcp/ip等。场景引擎的作用是执行功能的判断逻辑，场景引擎的触发条件和状态条件需要的数据可以从数据引擎获取。场景引擎的执行动作，可以影响数据引擎的数据处理方式以及数据上传逻辑。服务路由的作用是将车内协议的服务接口(some/ip)转换为车外协议(http超文本传输协议、mqtt消息队列遥测传输)
的服务接口，实现云端与车端的服务的协议转换。数据存储库在云端部署，可采用redis(远程字典服务)存储或hbase(分布式的、面向列的开源数据库)存储方案，将车端上传的数据进行分类存储。数据挖掘套件是针对大数据应用提供的套件，例如，车辆驾驶行为(转向行为、制动行为、驱动行为)相关数据上传后，可通过数据挖掘套件挖掘驾驶习惯，对驾驶习惯进行评分，从而为ubi(usage-based insurance，基于使用量而定义的保险)提供定价依据。第二服务引擎的作用与车端服务引擎类似，车端的服务通过服务路由模块转换为http服务或mqtt服务后，在云端通过云端服务引擎转换为ipc(inter-process communication，进程间通信)服务供云端应用使用。ota(over the air，空中升级)模块实现ota云端部分功能，云端可通过ota模块将更新的应用程序向车端发放。
154.请参照图4，图4为本技术提供的一种采用服务引擎的方案和不采用服务引擎的方案对比的示意图，图4所示的方法包括：
155.图4中左侧为图未采用服务引擎的方案，在此方案下，每个应用程序(app，application)需要分别与soa软件平台创建服务连接(即调用服务接口)，即每新增一个app需要新增一个服务连接，这种方式下，会占用系统资源(建立连接、撤销连接会占用较多资源)，不利于对服务整体的管理(因为是分别建立连接的，不利于统一的调度管理)，不利于服务操作权限的安全隔离(分别建立连接，上层app可直接操作服务接口，不利于实现安全隔离)。图4右侧为采用服务引擎的方案，在这个方案下，增加了服务引擎，将面向服务的接口转换为面向信号的接口，使每个上层部件(app)可以通过获取信号的形式获取信息，通过数据总线和服务引擎与soa软件平台创建服务连接(即调用服务接口)，不需要创建和管理服务连接，以节省系统资源消耗。
156.在上述过程中，服务引擎以安全和灵活的方式实现多个上层部件对于相同服务需求的共享(服务引擎可以对服务接口的操作进行统一的调度、权限、管理)，可保证高优先级任务的及时处理，屏蔽了因为上层部件直接操作服务接口带来的不可预期的影响。
157.请参照图5，图5为本技术提供的一种采用数据引擎的方案的示意图，图5所示的方法包括：
158.车端数据引擎中的“数据汇总”模块，可获取车内的数据，包括can(控制器域网，controller area network)、多个udp(用户数据报协议，user datagram protocol)、some/ip(传输协议，scalable service-oriented middleware over ip)等格式的数据，“数据过滤”模块依据过滤配置表的信息(过滤配置表的信息可由服务引擎进行更新)，对数据进行过滤，筛选出有用的数据。“数据存储”模块依据存储配置表的信息(存储配置表的信息可由服务引擎进行更新)，对数据进行存储，存储配置表中同时有数据发送的方式(如：按照一定时间周期发送、依据特定事件触发式发送等)。“数据压缩”模块对数据进行压缩，压缩后的压缩数据包被上传到云端，由云端进行数据存储，并进行数据挖掘等应用。云端的数据服务队压缩数据包等级管理，云端的数据存储模块对压缩数据包进行存储汇总，云端的数据挖掘套件对数据压缩包进行解压，之后进行数据回放和编写脚本，实现数据的处理。
159.前文通过图3-图5描述了数据交互的系统，下面结合图6-图9描述数据交互的装置。
160.请参照图6，为本技术实施例中提供的一种数据交互的装置600的示意框图，该装置600可以是电子设备上的模块、程序段或代码。该装置600与上述图1方法实施例对应，能
够执行图1方法实施例涉及的各个步骤，该装置600具体的功能可以参见下文中的描述，为避免重复，此处适当省略详细描述。
161.可选的，所述装置600包括：
162.第一获取模块610，用于获取车端的应用场景需求，其中，应用场景需求包括对车端操作控制的需求；
163.第二获取模块620，用于基于应用场景需求，获取应用场景需求对应的配置文件；
164.第三获取模块630，用于基于配置文件，获取应用场景需求对应的应用程序。
165.可选的，第二获取模块具体用于：
166.基于应用场景需求，修改车端应用程序对应的配置文件，得到修改后的配置文件；
167.或者
168.将应用场景需求发送给云端，并接收云端发送的修改后的配置文件，其中修改后的配置文件是云端根据应用场景需求对车端的应用程序对应的配置文件进行修改得到的。
169.可选的，第三获取模块具体用于：
170.基于配置文件，生成配置文件对应的应用程序；
171.或者
172.基于配置文件，获取云端发送的应用程序，其中，应用程序是云端根据修改后的配置文件生成的应用程序。
173.请参照图7，为本技术实施例中提供的另一种数据交互的装置700的示意框图，该装置700可以是电子设备上的模块、程序段或代码。该装置700与上述图2方法实施例对应，能够执行图2方法实施例涉及的各个步骤，该装置700具体的功能可以参见下文中的描述，为避免重复，此处适当省略详细描述。
174.可选的，所述装置700包括：
175.接收模块710，用于接收车端发送的应用场景需求，其中，应用场景需求包括对车端操作控制的需求；
176.修改模块720，用于基于应用场景需求修改配置文件，得到修改后的配置文件。
177.可选的，所述装置还包括：
178.验证模块，用于所述修改模块在基于应用场景需求修改配置文件，得到修改后的配置文件之后，利用修改后的配置文件，在数字孪生原型车中验证配置文件对应程序的功能。
179.可选的，所述装置还包括：
180.发送模块，用于所述修改模块在基于应用场景需求修改配置文件，得到修改后的配置文件之后，基于修改后的配置文件，生成应用程序，将应用程序发送给车端；
181.或者
182.将修改后的配置文件发送给车端。
183.请参照图8为本技术实施例中提供的一种数据交互的装置800的结构示意框图，该装置可以包括存储器810和处理器820。可选的，该装置还可以包括：通信接口830和通信总线840。该装置与上述图1方法实施例对应，能够执行图1方法实施例涉及的各个步骤，该装置具体的功能可以参见下文中的描述。
184.具体的，存储器810，用于存储计算机可读指令。
185.处理器820，用于处理存储器存储的可读指令，能够执行图1方法中的各个步骤。
186.通信接口830，用于与其他节点设备进行信令或数据的通信。例如：用于与服务器或者终端的通信，或者与其它设备节点进行通信，本技术实施例并不限于此。
187.通信总线840，用于实现上述组件直接的连接通信。
188.其中，本技术实施例中设备的通信接口830用于与其他节点设备进行信令或数据的通信。存储器810可以是高速ram存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器810可选的还可以是至少一个位于远离前述处理器的存储装置。存储器810中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器820执行时，电子设备执行上述图1所示方法过程。处理器820可以用于装置600上，并且用于执行本技术中的功能。示例性地，上述的处理器820可以是通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，本技术实施例并不局限于此。
189.请参照图9为本技术实施例中提供的另一种数据交互的装置900的结构示意框图，该装置可以包括存储器910和处理器920。可选的，该装置还可以包括：通信接口930和通信总线940。该装置与上述图2方法实施例对应，能够执行图2方法实施例涉及的各个步骤，该装置具体的功能可以参见下文中的描述。
190.具体的，存储器910，用于存储计算机可读指令。
191.处理器920，用于处理存储器存储的可读指令，能够执行图2方法中的各个步骤。
192.通信接口930，用于与其他节点设备进行信令或数据的通信。例如：用于与服务器或者终端的通信，或者与其它设备节点进行通信，本技术实施例并不限于此。
193.通信总线940，用于实现上述组件直接的连接通信。
194.其中，本技术实施例中设备的通信接口930用于与其他节点设备进行信令或数据的通信。存储器910可以是高速ram存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器910可选的还可以是至少一个位于远离前述处理器的存储装置。存储器910中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器920执行时，电子设备执行上述图2所示方法过程。处理器920可以用于装置700上，并且用于执行本技术中的功能。示例性地，上述的处理器920可以是通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，本技术实施例并不局限于此。
195.本技术实施例还提供一种可读存储介质，所述计算机程序被处理器执行时，执行如图1或图2所示方法实施例中电子设备所执行的方法过程。
196.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。
197.综上所述，本技术实施例提供一种数据交互的方法、装置、电子设备和可读存储介质，该方法包括，获取车端的应用场景需求，其中，应用场景需求包括对车端操作控制的需
求；基于应用场景需求，获取应用场景需求对应的配置文件；基于配置文件，获取应用场景需求对应的应用程序。通过该方法可以达到节省软件和系统开发的资源的效果。
198.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
199.另外，在本技术各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
200.所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
201.以上所述仅为本技术的实施例而已，并不用于限制本技术的保护范围，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
202.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应所述以权利要求的保护范围为准。
203.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。