一种车载服务通信方法和相关装置与流程

1.本技术涉及车辆技术领域，特别是涉及一种车载服务通信方法和相关装置。


背景技术：

2.随着车辆技术的不断发展，车辆已不仅仅具有交通运输功能，同时兼具音乐、通讯以及娱乐等多种功能，此时便需要服务提供端提供服务，而服务执行端通过查询服务提供端提供的服务，以执行该服务对应的功能。
3.相关技术多通过建立组播组的方式实现服务提供与服务查询，即将服务提供端提供的服务以组播的形式向组播组发送，如果服务执行端需要执行服务对应的功能，则在组播组中查询相应服务并执行功能。
4.但是，如果有其他终端接入组播组内，则其他终端也可以通过服务查询的方式，使相关服务执行端执行相应功能，从而给车辆带来极大的安全隐患。


技术实现要素：

5.为了解决上述技术问题，本技术提供了一种车载服务通信方法和相关装置。本技术实施例公开了如下技术方案：
6.第一方面，本技术实施例公开了一种车载服务通信方法，所述方法包括：
7.接收服务执行端发送的目标服务查询请求；所述目标服务查询请求包括用于标识所述服务执行端的执行端标识；
8.根据所述执行端标识，对所述服务执行端进行校验；
9.接收服务提供端发送的服务提交请求；
10.若所述校验通过，根据所述服务查询请求，查询与所述目标服务查询请求对应的目标服务提交请求；
11.将所述目标服务提交请求向所述服务执行端发送。
12.可选的，所述方法应用于目标服务器，所述目标服务器预存了用于标志服务执行端的执行端标志；
13.所述根据所述执行端标识，对所述服务执行端进行校验，包括：
14.将所述执行端标识与所述执行端标志进行比对；
15.若所述执行端标识与所述执行端标志一致，确定所述服务执行端校验通过。
16.可选的，所述方法还包括：
17.若所述执行端标识与所述执行端标志不一致，将所述服务执行端的执行端标识存储到所述目标服务器中。
18.可选的，所述服务提交请求为多个；
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.图1为本技术实施例提供的一种车载服务通信方法的流程图；
62.图2为本技术实施例提供的一种车载服务通信方法的报文收发示意图；
63.图3为本技术实施例提供的一种车载服务通信方法的报文接收与处理流程图；
64.图4为本技术实施例提供的一种车载服务通信方法的报文处理流程图；
65.图5为本技术实施例提供的一种车载服务通信方法的主阶段服务处理的逻辑图；
66.图6为本技术实施例提供的一种车载服务通信方法的重复阶段服务处理的逻辑图；
67.图7为本技术实施例提供的一种车载服务通信装置的结构框图；
68.图8为本技术实施例提供的一种用于车载服务通信的计算机设备的结构框图。
具体实施方式
69.下面结合附图，对本技术的实施例进行描述。
70.本技术的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不比用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本技术的实施例中对相同属性的对象在描述时所采用的区分方式。
71.为了便于理解本技术的技术方案，下面对本技术涉及的一些技术术语进行介绍。
72.随着车辆技术的不断发展，车辆功能越来越繁多，自然也就需要更多服务提供端用以提供服务，而同时也就需要更多服务执行端用来执行繁多的车辆功能，这也就需要一种方法实现服务提供端与服务执行端的车载服务通信。目前，车载以太网的服务通信模式通常为面向服务的架构(service-oriented architecture，soa)，即按照服务提供与需求，通过发送请求的方式实现服务提供方与服务执行方之间的服务通信，以向服务执行方提供服务。
73.相关技术中的服务通信多通过组播的形式向组播组发送，或者仅针对特定服务执行端进行单播发送。但是，随着车辆功能的逐渐增多，提供的服务种类越来越多，如果采用单播形式进行发送，会使得整个车载服务通信系统变的非常复杂，容易出现误通信的现象；而如果采用组播形式发送，又无法防止其他接入组播组的终端也能够根据组播发送的服务提交请求，使得相关服务执行端执行相应功能，使得车辆存在极大的安全隐患。
74.为了解决上述相关技术带来的技术问题，本技术提供了一种服务通信方法，在针对服务查询请求对相应服务提交请求进行查询之前，对服务查询请求进行校验，只有校验通过的服务查询请求才会在服务提交请求中查询以获得所需的服务，从而提高了服务执行的安全性。
75.接下来，将结合附图，对本技术实施例提供的一种车载服务通信方法进行介绍，本技术实施例提供的车载服务通信方法可以应用于车载服务器或云服务器中。为方便描述，本技术将以车载服务器作为车载服务通信方法的应用载体，以车载soa服务通信模式为例，对本技术提供的方法进行介绍。
76.请参阅图1，图1为本技术实施例提供的一种车载服务通信方法的流程图，所述方法包括：
77.s101：接收服务执行端发送的目标服务查询请求。
78.其中，接收目标服务查询请求可以是预置在车载服务器中的服务网关，将soa服务网关作为soa服务的注册中心，负责服务的管理和收发。
79.其中，服务执行端可以是电子控制单元客户端(electronic control unit client，ecu client)，进而通过ecu client根据提供的服务控制相关设备实现该服务对应的功能。
80.其中，目标服务查询请求可以是以find报文的形式进行发送与接收。
81.在本实施例中，目标服务查询请求包括用于标识服务执行端的执行端标识。执行端标识可以是服务执行端的端口号，或者ecu client的标号，也可以是车载以太网中服务执行端的网际互连协议(internet protocol，ip)地址。
82.s102：根据执行端标识，对服务执行端进行校验。
83.在本实施例的一些可能的实现方式中，可以在服务网关中预置数据结构，例如列表、键值对(key-value pair，k-v pair)或字典等方式，用于存储车辆中所有服务执行端的执行端标志，该执行端标志用于标志车辆中的服务执行端，以备与获取到的目标服务查询请求中的执行端标识进行比对。
84.作为一种可能的实现方式，可以在soa服务网关中预置一张服务注册表，在该服务注册表中存储了所有具有查询服务需求的ecu client的ip地址，也就是说，只有在服务注
册表中存储的ecu client才具有查询服务并获取服务的权限，其他目标服务查询请求均无相应权限。在某个服务执行端向soa服务网关发送目标服务查询请求时，soa服务网关根据目标服务查询请求中携带的服务执行端的ip地址，与服务注册表中存储的ecu client的ip地址进行比对，若比对一致，则确定该目标服务查询请求具有相应权限，则继续执行后续相关步骤；若比对不一致，则不为该目标服务查询请求提供相关服务。
85.在本实施例的另外一些可能的实现方式中，soa服务网关可以集成在车辆本身的中央智能网关上，可以通过与其他集成模块分时复用的方式，借助中央智能网关的算力实现校验，从而加快校验速度，降低通信时延，提高通信效率。
86.s103：接收服务提供端发送的服务提交请求。
87.与目标服务查询请求相似，服务提交请求可以以offer报文的形式向soa服务网关发送。
88.服务提供端可以是电子控制单元服务端(electronic control unit server，ecu server)，从而通过服务提交请求获取ecu server能够提供的服务。
89.在本实施例的一些可能的实现方式中，soa服务网关实时接收车辆中所有ecu server发送的服务提交请求，以供接收到目标服务查询请求后，在服务提交请求中查询哪一个服务提供端能够提供需求的目标服务。
90.在本实施例的另外一些可能的实现方式中，ecu server按照some/ip协议配置，并向soa服务网关发送服务提交请求。此时每个ecu server可以以3分钟为间隔时间，即每间隔3分钟向soa服务网关发送一次服务提交请求。
91.此时，soa服务网关接收和发出的报文，即目标服务查询请求和服务提交请求，均为some/ip协议报文。
92.在本实施例的另外一些可能的实现方式中，soa服务网关在接收ecu server发送的服务提交请求之后，同样可以通过例如列表、字典或键值对等形式的数据结构，将所有服务提交请求进行存储，使之作为查询基础以供soa服务网关进行查询。
93.s104：若校验通过，根据服务查询请求，查询与目标服务查询请求对应的目标服务提交请求。
94.其中，校验通过可以是目标服务查询请求的来源，即服务执行端具有相关权限，允许服务执行端查询对应的目标服务提交请求。
95.在本实施例的一些可能的实现方式中，查询方式可以是遍历存储服务提交请求的数据结构，查询哪一个服务提交请求可以提供目标服务，从而将该服务提交请求作为目标服务提交请求。
96.s105：将目标服务提交请求向服务执行端发送。
97.在本实施例的一些可能的实现方式中，在查询到需要向服务执行端发送的offer报文之后，将offer作为目标服务提交请求发送给服务执行端，从而通过offer报文与find报文收发的方式实现服务提供端与服务执行端之间的通信，以使服务执行端能够根据服务提供端提供的服务，控制相关执行器执行相应的功能。
98.在某种特殊工况下，例如车辆进行改装或优化时，需要增设一些功能，自然也就需要增设与这些功能相关的服务执行端，而这些服务执行端在目标服务器中并未存储，也就无法通过相应校验，因此为适应车辆改装优化，基于上述实施例，进一步，所述方法应用于
目标服务器中，所述方法还包括：
99.若所述执行端标识与所述执行端标志不一致，将所述服务执行端的执行端标识存储到所述目标服务器中。
100.其中，目标服务器可以是车载服务器，也可以是与车辆通过网络有线或无线连接的云服务器。
101.在存储过程中，服务执行端的执行端标识可以存储到目标服务器中soa服务网关的服务注册表中，作为标志该服务执行端的执行端标志存储下来，从而在后续获取相关服务并执行功能时可以直接查询到相关服务，不再需要通过技术人员手动修改soa服务网关中存储的服务注册表，减少了车辆优化的优化步骤。
102.为节约服务提交请求发送占用的网络通道，减少无用服务提交请求的发送，基于上述实施例，进一步，所述方法还包括：
103.若接收所述服务提交请求后达到预定时间，所述服务提交请求未向所述服务执行端发送，停止接收所述服务提交请求。
104.在注册中心接收服务提供端发送的服务提交请求后，可以存储起来以备服务执行端查询并获取服务。但若一定时间后仍无服务执行端查询到该服务提交请求，说明该服务提交请求已无被执行的需求，此时已无服务执行端需要该服务提交需求，此时soa服务网关可以不再接收服务提交请求，以节约网络通道的占用，提高报文传送效率。
105.为提高服务执行端的响应速度，减少报文传送时间，将目标服务提交请求向服务执行端发送，包括：
106.间隔预设时间，将目标服务提交请求向服务执行端重复发送。
107.在本实施例的一些可能的实现方式中，可以通过倍增间隔时间重复发送的方式，向服务执行端发送目标服务提交请求。例如，从服务执行端接收到第一个offer报文开始，soa服务网关间隔1s向服务执行端发送第二个offer报文，间隔2s向服务执行端发送第三个offer报文，间隔4s向服务执行端发送第四个offer报文，以此类推，实现将offer报文向服务执行端的冗余发送。
108.在本实施例的另外一些可能的实现方式中，也可以采用相同间隔时间的方式向服务执行端发送目标服务提交请求。
109.为减少直接经过soa服务网关的请求收发过程，针对已通过校验并查询到相应服务提供端的服务执行端，基于上述实施例，进一步，所述目标服务提交请求包括用于标识服务提供端的提供端标识；
110.所述方法还包括：
111.根据服务端标识与执行端标识，建立服务提供端与服务执行端之间的连接。
112.与执行端标识相似，服务端标识可以用于标识服务提供端，根据服务端标识可以确定发送目标服务查询请求的是哪一个服务执行端。
113.在soa服务网关校验服务执行端通过，并将目标服务提交请求发送给服务执行端之后，可以通过车辆以太网直接建立服务执行端与服务提供端之间的连接，使得服务执行端与服务提供端直接通过目标服务查询请求与目标服务提交请求进行通信，不再需要经过soa服务网关的校验与收发，以节约soa服务网关的资源，减少soa服务网关的请求收发过程。
114.在本实施例的一些可能的实现方式中，
115.当某一服务执行端需同时执行多项服务时，也就需要同时在多个服务提供端获取多个服务提交请求，为节约请求收发占用的资源，提高服务执行效率，所述目标服务提交请求为多个；
116.在将目标服务提交请求向服务执行端发送之前，所述方法还包括：
117.将多个目标服务提交请求合并，获得目标服务提交请求包；
118.所述将目标服务提交请求向服务执行端发送包括：
119.将目标服务提交请求包向服务执行端发送。
120.在本实施例的一些可能的实现方式中，可以通过将offer报文打包的方式将多个服务提交请求打包合并，进而发送给服务执行端。
121.通过将发送给同一服务执行端的offer报文进行打包合并的方式进而统一进行发送，从而节约请求收发占用的资源，提高服务执行效率。
122.请参阅图2，图2为本技术实施例提供的一种车载服务通信方法的报文收发示意图。接下来将结合图2，根据一种实际场景中应用的报文收发过程，介绍一次完整的报文收发流程。
123.服务提供端(server)按照安全数码(secure digital memory，sd)协议向注册中心发送具有服务提交请求的offer报文，之后间隔一定时间便向注册中心发送一次同样的offer报文。
124.当服务执行端(client)具有执行服务的需求时，便向注册中心发送具有目标服务查询请求的find报文，之后注册中心根据目标服务查询请求中携带的执行端标识(服务执行端的ip地址)校验服务执行端是否通过，若通过，则向服务执行端发送能够提供目标服务的offer报文。若不通过，则将find报文中的服务执行端的ip地址替换成注册中心的ip地址，并将替换ip地址之后的find报文发送给服务提供端。
125.在执行中心向服务执行端发送offer报文时，可以通过多次发送的方式以保证服务执行端尽快接收offer报文。例如可以通过间隔时间倍增这一代理规则发送offer报文，在注册中心查询到目标服务提交请求的offer报文并第一次向服务执行端发送报文开始，间隔1秒向服务执行端发送第二个offer报文，间隔2秒向服务执行端发送第三个offer报文，间隔4秒向服务执行端发送第四个offer报文，以此类推，在向服务执行端发送第八个offer报文之后，则以三分钟为周期向服务执行端发送offer报文，即每隔三分钟，向服务执行端发送一次offer报文。其中，向服务执行端发送的offer报文都是相同的，前述所有的发送过程均为重复发送。
126.若服务提供端发送的服务提交请求的offer报文在一定时间内没有被服务执行端查询，或服务提供端因故障等原因在预设时间内没有向注册中心发出服务提交请求的offer报文，则服务提供端停止提供服务并向注册中心发送停止提供服务报文(stopoffer报文)，则向正在周期性接收该服务提供端发送的offer报文的服务执行端发送stopoffer报文，以告知通过校验的服务执行端，该服务提供端已停止提供相应服务。
127.请参阅图3，图3为本技术实施例提供的一种车载服务通信方法的报文接收与处理流程图。该方法包括s301-s306：
128.s301：开始；
129.s302：判断是否为首次收到该服务的服务提交请求所对应的offer报文；若为是，则转到s304；若为否，则转到s303；
130.s303：刷新服务注册表，并记录收到offer报文的时间；
131.s304：在服务注册表中新增该服务并将该服务初始化；
132.s305：给查询该服务的合法用户发送第一个offer报文并记录下发送时间；
133.s306：结束。
134.请参阅图4，图4为本技术实施例提供的一种车载服务通信方法的报文处理流程图。该方法包括s401-s405：
135.s401：注册中心接收服务执行端发送的find报文；
136.s402：判断服务执行端是否已存储在服务注册表中；若为是，则转到s404；若为否，则转到s403；
137.s403：查找服务提供端ip地址，并根据服务提供端ip地址将find报文发送给服务提供端；
138.s404：以单播形式回复服务执行端一个offer报文，将服务注册表的状态转到主阶段；
139.s405：结束。
140.请参阅图5，图5为本技术实施例提供的一种车载服务通信方法的主阶段服务处理的逻辑图。该方法包括s501-s504：
141.s501：定时器开始；
142.s502：判断是否存在服务超出更新时间；若为是，则转到s503；若为否，则转到s504；
143.s503：针对超出更新时间的服务，向注册中心发送停止提供服务报文；
144.s504：以3分钟作为更新时间周期，扫描所有处在主阶段的服务，给所有查询目标服务的合法用户发送offer报文。
145.请参阅图6，图6为本技术实施例提供的一种车载服务通信方法的重复阶段服务处理的逻辑图。该方法包括s601-s609：
146.s601：开始；
147.s602：判断是否存在超出更新时间的服务；若为是，则转到s603；若为否，则转到s604；
148.s603：在服务注册表中删除该服务；
149.s604：遍历所有服务，判断是否有服务在重复阶段超时；若为是，则转到s605；若为否，则转到s606；
150.s605：服务进入主阶段，在重复阶段发送最后一个offer报文；
151.s606：判断目标服务是否达到发送offer报文的时间；若为是，则转到s607；若为否，则转到s608；
152.s607：发送offer报文；
153.s608：等待达到时间后发送offer报文；
154.s609：结束。
155.请参阅图7，图7为本技术实施例提供的一种车载服务通信装置的结构框图，所述
装置包括：
156.第一请求接收单元710，用于接收服务执行端发送的目标服务查询请求；所述目标服务查询请求包括用于标识所述服务执行端的执行端标识；
157.校验单元720，用于根据所述执行端标识，对所述服务执行端进行校验；
158.第二请求接收单元730，用于接收服务提供端发送的服务提交请求；
159.请求查询单元740，用于若所述校验通过，根据所述服务查询请求，查询与所述目标服务查询请求对应的目标服务提交请求；
160.请求发送单元750，用于将所述目标服务提交请求向所述服务执行端发送。
161.作为一种可能的实现方式，所述方法应用于目标服务器，所述目标服务器预存了用于标志服务执行端的执行端标志；
162.所述校验单元，还用于：
163.将所述执行端标识与所述执行端标志进行比对；
164.若所述执行端标识与所述执行端标志一致，确定所述服务执行端校验通过。
165.作为一种可能的实现方式，所述装置还包括：
166.标识存储单元，用于若所述执行端标识与所述执行端标志不一致，将所述服务执行端的执行端标识存储到所述目标服务器中。
167.作为一种可能的实现方式，所述装置还包括：
168.停止请求接收单元，用于若接收所述服务提交请求后达到预定时间，所述服务提交请求未向所述服务执行端发送，停止接收所述服务提交请求。
169.作为一种可能的实现方式，所述请求发送单元，还用于：
170.间隔预设时间，将所述目标服务提交请求向所述服务执行端重复发送。
171.作为一种可能的实现方式，所述目标服务提交请求包括用于标识所述服务提供端的提供端标识；
172.所述装置还包括：
173.连接建立单元，用于根据所述服务端标识与所述执行端标识，建立所述服务提供端与所述服务执行端之间的连接。
174.作为一种可能的实现方式，所述目标服务提交请求为多个；
175.所述装置还包括：
176.请求合并单元，用于将多个所述目标服务提交请求合并，获得目标服务提交请求包；
177.所述请求发送单元，还用于：
178.将所述目标服务提交请求包向所述服务执行端发送。
179.由上述技术方案可以看出，通过接收服务执行端发送的目标服务查询请求；目标服务查询请求包括用于标识服务执行端的执行端标识；根据执行端标识，对服务执行端进行校验；接收服务提供端发送的服务提交请求；若校验通过，根据服务查询请求，查询与目标服务查询请求对应的目标服务提交请求；将目标服务提交请求向服务执行端发送。即通过服务提供端提交服务和服务执行端查询所需服务的方式实现通信，同时根据执行端标识对服务执行端的合法性进行校验，当校验通过时才会根据其发送的服务查询请求获取所需的服务，从而提高了服务执行的安全性。
180.请参阅图8，图8为本技术实施例提供的一种用于车载服务通信的计算机设备的结构框图。所述计算机设备包括处理器810以及存储器820：
181.所述存储器820用于存储程序代码，并将所述程序代码传输给所述处理器；
182.所述处理器810用于根据所述程序代码中的指令执行上述实施例提供的任意一种车载服务通信方法。
183.本技术实施例还公开了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序在被处理器执行时用于执行上述实施例提供的任意一种车载服务通信方法。
184.可以理解的是，该方法可以应用于处理设备上，该处理设备为能够进行动作控制的处理设备，例如可以为具有动作控制功能的终端设备或服务器。该方法可以通过终端设备或服务器独立执行，也可以应用于终端设备和服务器通信的网络场景，通过终端设备和服务器配合执行。其中，终端设备可以为计算机、手机等设备。服务器可以理解为是应用服务器，也可以为web服务器，在实际部署时，该服务器可以为独立服务器，也可以为集群服务器。
185.本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质可以是下述介质中的至少一种：只读存储器(英文：read-only memory，缩写：rom)、ram、磁碟或者光盘等各种可以存储程序代码的介质。
186.需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
187.以上所述，仅为本技术的一种具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应该以权利要求的保护范围为准。

技术特征：
1.一种车载服务通信方法，其特征在于，所述方法包括：接收服务执行端发送的目标服务查询请求；所述目标服务查询请求包括用于标识所述服务执行端的执行端标识；根据所述执行端标识，对所述服务执行端进行校验；接收服务提供端发送的服务提交请求；若所述校验通过，根据所述目标服务查询请求，查询与所述目标服务查询请求对应的目标服务提交请求；将所述目标服务提交请求向所述服务执行端发送。2.根据权利要求1所述的方法，其特征在于，所述方法应用于目标服务器，所述目标服务器预存了用于标志服务执行端的执行端标志；所述根据所述执行端标识，对所述服务执行端进行校验，包括：将所述执行端标识与所述执行端标志进行比对；若所述执行端标识与所述执行端标志一致，确定所述服务执行端校验通过。3.根据权利要求2所述的方法，其特征在于，所述方法还包括：若所述执行端标识与所述执行端标志不一致，将所述服务执行端的执行端标识存储到所述目标服务器中。4.根据权利要求1所述的方法，其特征在于，所述方法还包括：若接收所述服务提交请求后达到预定时间，所述服务提交请求未向所述服务执行端发送，停止接收所述服务提交请求。5.根据权利要求1所述的方法，其特征在于，所述将所述目标服务提交请求向所述服务执行端发送，包括：间隔预设时间，将所述目标服务提交请求向所述服务执行端重复发送。6.根据权利要求1所述的方法，其特征在于，所述目标服务提交请求包括用于标识所述服务提供端的提供端标识；所述方法还包括：根据所述服务端标识与所述执行端标识，建立所述服务提供端与所述服务执行端之间的连接。7.根据权利要求1所述的方法，其特征在于，所述目标服务提交请求为多个；在将所述目标服务提交请求向所述服务执行端发送之前，所述方法还包括：将多个所述目标服务提交请求合并，获得目标服务提交请求包；所述将所述目标服务提交请求向所述服务执行端发送包括：将所述目标服务提交请求包向所述服务执行端发送。8.一种车载服务通信装置，其特征在于，所述装置包括：第一请求接收单元，用于接收服务执行端发送的目标服务查询请求；所述目标服务查询请求包括用于标识所述服务执行端的执行端标识；校验单元，用于根据所述执行端标识，对所述服务执行端进行校验；第二请求接收单元，用于接收服务提供端发送的服务提交请求；请求查询单元，用于若所述校验通过，根据所述服务查询请求，查询与所述目标服务查询请求对应的目标服务提交请求；
请求发送单元，用于将所述目标服务提交请求向所述服务执行端发送。9.一种计算机设备，其特征在于，所述计算机设备包括处理器以及存储器：所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；所述处理器用于根据所述程序代码中的指令执行权利要求1-7中任意一项所述的车载服务通信方法。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，所述计算机程序在被处理器执行时用于执行权利要求1-7中任意一项所述的车载服务通信方法。

技术总结
本申请实施例公开了一种车载服务通信方法及相关装置，所述方法包括：接收服务执行端发送的目标服务查询请求；目标服务查询请求包括用于标识服务执行端的执行端标识；根据执行端标识，对服务执行端进行校验；接收服务提供端发送的服务提交请求；若校验通过，根据服务查询请求，查询与目标服务查询请求对应的目标服务提交请求；将目标服务提交请求向服务执行端发送。即通过服务提供端提交服务和服务执行端查询所需服务的方式实现通信，同时根据执行端标识对服务执行端的合法性进行校验，当校验通过时才会根据其发送的服务查询请求获取所需的服务，从而提高了服务执行的安全性。从而提高了服务执行的安全性。从而提高了服务执行的安全性。


技术研发人员：宋婵
受保护的技术使用者：上海汽车集团股份有限公司
技术研发日：2023.06.28
技术公布日：2023/8/13