技术领域
[0001] 本申请涉及车辆技术领域，尤其涉及一种车与车之间的通信方法、车辆、电子设备及存储介质。
相关背景技术
[0002] 当用户驾驶现有车辆行驶在道路上时，用户无法通过当前车辆与周围的周边车辆进行交互沟通，导致不同车辆之间不能交流，不能交换信息，用户的使用体验较差。
具体实施方式
[0026] 为了能够更清楚地理解本申请的上述目的、特征和优点，下面结合附图和具体实施方式对本申请进行详细描述。需要说明的是，在不冲突的情况下，本申请的实施方式及实施方式中的特征可以相互组合。
[0027] 在下面的描述中阐述了很多具体细节以便于充分理解本申请，所描述的实施方式仅是本申请一部分实施方式，而不是全部的实施方式。
[0028] 除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施方式的目的，不是旨在于限制本申请。
[0029] 进一步需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
[0030] 本申请中“至少一个”是指一个或者多个，“多个”是指两个或多于两个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不是用于描述特定的顺序或先后次序。
[0031] 在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
[0032] 请参考图1，为本申请实施例提供的车与车之间的通信方法的流程示意图，本实施例应用于车辆，包括以下步骤：
[0033] 步骤101、响应于车辆通信请求，获取车辆当前的运行状态；其中，运行状态至少包括车辆的行驶速度。
[0034] 在一些实施例中，车辆通信请求通过车内乘客或驾驶员的操作得到。具体的说，车辆包括车机娱乐系统以及与车机娱乐系统匹配的车机娱乐显示屏，乘客或驾驶员在车机娱乐显示屏上进行触控操作，以生成车辆通信请求。例如，乘客或驾驶员在车机娱乐显示屏上点击“开启打招呼”按键，车辆响应于对“开启打招呼”按键的点击操作，开启车辆的打招呼功能，并获取车辆当前的运行状态。
[0035] 可以理解的是，用户也可以通过语音等其他操作方式生成车辆通信请求，本实施例并不对车辆通信请求的生成方式做具体限定。
[0036] 需要说明的是，关于运行状态的具体细分在后续实施例中有详细描述，为了避免重复，此处不再赘述。
[0037] 步骤102、根据运行状态确定车辆的信息发送策略；其中，信息发送策略至少包括信息发送频率。
[0038] 在一些实施例中，以运行状态包括车辆的行驶速度，信息发送策略包括信息发送频率为例，通过以下方式确定车辆的信息发送策略：检测行驶速度是否大于第一预设速度且小于第二预设速度；在检测到行驶速度大于第一预设速度且小于第二预设速度时，确定信息发送频率为第一频率；在检测到行驶速度小于或等于第一预设速度时，确定信息发送频率为第二频率；其中，第二频率大于第一频率；在检测到行驶速度大于或等于第二预设速度时，确定信息发送频率为第三频率；其中，第三频率小于第一频率。
[0039] 为了便于理解，下面以第一预设速度为60km/h，第二预设速度为80km/h，第一频率为5Hz，第二频率为10Hz，第三频率为1Hz为例，对本实施例如何确定信息发送策略进行具体说明：
[0040] 在检测到车辆的行驶速度大于60km/h且小于80km/h时，此时车辆的行驶速度正常，将信息发送频率设置为5Hz；在检测到车辆的行驶速度小于或等于60km/h时，此时车辆的行驶速度较慢，将信息发送频率设置为10Hz；在检测到车辆的行驶速度大于80km/h时，此时车辆的行驶速度较快，将信息发送频率设置为1Hz。
[0041] 值得说明的是，车辆的行驶速度越快，对预警类功能消息发送的需求越大。因此，通过根据不同的行驶速度设置不同的信息发送频率，即行驶速度越快将信息发送频率设置的越低，使得后续步骤中第一招呼消息的发送不会对其他预警类功能消息的发送造成影响，从而能够在实现车与车之间的信息交互的同时，不影响车辆其他预警类功能消息的发送。
[0042] 在一些实施例中，不对第一预设速度、第二预设速度的大小做具体限定。
[0043] 在一些实施例中，不对第一频率、第二频率以及第三频率的大小做具体限定，仅需确保第二频率大于第一频率，且第一频率大于第三频率即可。
[0044] 步骤103、根据预设车辆选择规则确定与车辆进行通信的目标车辆。
[0045] 在一些实施例中，预设车辆选择规则包括车辆品牌选择规则以及范围设置规则；根据预设车辆选择规则确定与车辆进行通信的目标车辆，包括：根据范围设置规则确定在车辆预设范围内的所有初始车辆；根据车辆品牌选择规则从初始车辆中确定目标车辆。
[0046] 为了便于理解，下面对本实施例如何确定目标车辆进行具体的说明：
[0047] 用户通过前述步骤提及的车机娱乐显示屏对预设范围以及车辆品牌进行设置，例如，设置预设范围为500米，设置车辆品牌为品牌A、品牌B和品牌C，则目标车辆为车辆500米范围内的所有品牌为品牌A、品牌B和品牌C的车辆。
[0048] 可以理解的是，本实施例不对预设车辆选择规则的类型做具体限定，例如预设车辆选择规则还可以包括车牌号选择规则、车辆类型选择规则等，可以根据实际需求设置，以进一步提高用户的使用体验。
[0049] 步骤104、根据信息发送策略向目标车辆发送第一招呼信息。
[0050] 在一些实施例中，第一招呼信息的类型包括但不限于文字信息、语音信息、灯光信息等。
[0051] 具体的说，用户可以在车机娱乐显示屏上设置第一招呼信息的内容，内容类型可以包括text、emoji、voice、light等其中一个。更具体的，text类型为：一串用户自定义短消息字符串；emoji类型为：用户选择的某一个表情，如笑脸等；voice类型为：用户发送的一段语音或者音乐；light类型为：用户设置的灯语，如灯光打出笑脸等。
[0052] 在一些实施例中，车辆通过CV2X(cellular vehicle to everything，蜂窝车联网)技术将第一招呼信息传输至附近的车辆。
[0053] 值得说明的是，采用CV2X技术实现车辆之间的通信具有如下优点：
[0054] 1、采用CV2X技术可以实现更长距离(数百米至数千米)内的直接通信传输招呼消息，并且可以穿越障碍物进行可靠传输，满足长距离覆盖，突破蓝牙WIFI的通信范围限制。
[0055] 2、采用CV2X技术低时延高可靠性：能够快速响应并提供高度可靠的招呼数据交换服务。
[0056] 3、CV2X技术采用了加密算法来确保招呼数据安全，并且支持身份验证机制来防止恶意攻击者伪造信息或篡改数据，安全保密性好。
[0057] 4、CV2X技术采用专用频段。
[0058] 5、CV2X已经成为国际标准(如3GPP LTE‑V2X)，得到了广泛认可并正在逐步推广应用。这使得不同厂商开发出来的设备具备互操作性，并促进了整个行业生态系统发展。
[0059] 为了便于理解，下面结合图2和图3对本申请的车辆如何向目标车辆发送第一招呼信息进行具体的说明：
[0060] 请参考图2，为本申请实施例提供的CV2X无线通信系统的通信示意图。CV2X无线通信系统不需要重新设计新的硬件，如果原车装有CV2X系统，只需要在本车消息集的协议栈中增加当前招呼信息的数据即可，数据通过短程无线传输系统传输，PC5接口实现一定范围内车辆之间的直连通信。
[0061] 具体的说，Uu接口是通过基站实现的车联网通信方式。它主要通过无线网络连接，实现车辆、道路基础设施和其他设备之间的数据传输。Uu接口在覆盖范围内可以提供较高的通信质量，适用于大多数场景。PC5接口是一种直连通信方式，无需通过基站。它主要用于车辆与附近其他车辆、道路基础设施以及行人之间的短距离通信。PC5接口可以作为没有无线网络覆盖时直接车车通信的途径，具有较高的实时性和可靠性。
[0062] 在一些实施例中，CV2X无线通信系统传输的第一招呼信息包括时间戳、消息索引号、车辆ID、位置、车辆品牌、招呼类型、描述、数据、MsgForwarding(消息是否继续转发)等。
[0063] 请参考图3，为本申请实施例提供的车辆的硬件结构图。车辆包括车载中央网关10、车机娱乐显示屏20、TBOX(Telematics Box，车载网络终端)30、车外音响40以及车灯50。
[0064] 车机娱乐显示屏20与车辆的车机娱乐系统连接，包含车载导航地图的应用程序，能够设置第一招呼信息的招呼类型：如短消息、语音、表情等；还能够设置车外灯语、车外音响40播放的音乐类型等。
[0065] TBOX30用于处理基于CV2X技术发送或接收的消息，以及招呼模式逻辑处理，接收与发送招呼数据内容。
[0066] 车载中央网关10用于实现TBOX30、车机娱乐系统车外音响40以及车灯50之间的数据交互。
[0067] 车外音响40用于播放招呼音乐；车灯50用于显示灯语。
[0068] 在车辆上电后，用户通过车机娱乐显示屏20开启车辆的打招呼功能，并设置打招呼的内容，内容类型可以包括text、emoji、voice、light等其中一个。用户还可以通过车机娱乐显示屏20设置接收车辆哪个方位的招呼信息(前方、后方、左前方、右前方、左后方以及右后方共六个方位)。车机娱乐系统在感应到用户在车机娱乐显示屏20上的操作后，将用户操作对应的信息传输至车载中央网关10，车载中央网关10向TBOX30发送工作指令。TBOX30基于用户设置的内容类型，生成第一招呼信息，并将第一招呼信息发送至目标车辆。
[0069] 与相关技术相比，本申请实施例至少具有以下优点：通过获取车辆的运行状态，由于运行状态至少包括车辆的行驶速度，因此能够基于运行状态得知车辆是否处于高速行驶状态。再通过运行状态确定车辆的信息发送策略，由于信息发送策略至少包括信息发送频率，因此能够基于车辆不同的行驶速度确定不同的信息发送频率，从而有效避免了“当车辆行驶速度较快时，若信息发送频率较高，会影响车辆预警类功能消息的发送”的情况的发生，提高了车辆行驶过程中的安全性。此外，通过预设车辆选择规则确定与车辆进行通信的目标车辆，再向目标车辆发送第一招呼信息，能够有针对性的基于用户需求向特定车辆打招呼，提高了用户在行车过程中的驾驶体验。
[0070] 请参考图4，图4是本申请一实施例提供的车与车之间的通信方法的流程示意图，本实施例是在前述实施例的基础上做的进一步改进，主要改进之处在于，在本实施例中，运行状态还包括车辆的行驶加速度，还会根据行驶加速度的大小确定车辆的信息发送策略。通过此种方式，能够进一步提高车辆在行驶过程中的安全性。
[0071] 本实施例应用于车辆，具体流程如图4所示，包括以下步骤：
[0072] 步骤201、响应于车辆通信请求，获取车辆当前的运行状态；其中，运行状态至少包括车辆的行驶速度和行驶加速度。
[0073] 步骤202、检测行驶速度是否大于第一预设速度且小于第二预设速度；在检测到行驶速度大于第一预设速度且小于第二预设速度时，执行步骤203；在检测到行驶速度小于或等于第一预设速度时，执行步骤204；在检测到行驶速度大于或等于第二预设速度时，执行步骤205。
[0074] 步骤203、确定信息发送频率为第一频率。
[0075] 步骤204、检测行驶加速度是否大于第一预设加速度且小于第二预设加速度；在检测到行驶加速度大于第一预设加速度且小于第二预设加速度时，执行步骤203；在检测到行驶加速度小于或等于第一预设加速度时，执行步骤206；在检测到行驶加速度大于或等于第二预设加速度时，执行步骤205。
[0076] 在一些实施例中，不对第一预设加速度和第二预设加速度的大小做具体限定，可以根据实际需求设置。
[0077] 步骤205、确定信息发送频率为第三频率。
[0078] 步骤206、确定信息发送频率为第二频率。
[0079] 步骤207、根据信息发送频率向目标车辆发送第一招呼信息。
[0080] 为了便于理解，下面以第一预设速度为60km/h，第二预设速度为80km/h；第一预设2 2
加速度为10m/s，第二预设加速度为20m/s；第一频率为5Hz，第二频率为10Hz，第三频率为
1Hz为例，对本实施例如何确定信息发送策略进行具体说明：
[0081] 在检测到车辆的行驶速度大于60km/h且小于80km/h时，此时车辆的行驶速度正常，将信息发送频率设置为5Hz。
[0082] 在检测到车辆的行驶速度小于或等于60km/h时，此时车辆的行驶速度较慢，检测2 2
车辆的行驶加速度的大小。若车辆的行驶加速度大于10m/s且小于20m/s，表明车辆虽然目前行驶速度较慢但会在较短时间内加速至某一速度值，将信息发送频率设置为5Hz；若车辆
2
的行驶加速度大于或等于20m/s ，表明车辆虽然目前行驶速度较慢但会在更短的时间内加
2
速至某一速度值，将信息发送频率设置为1Hz；若车辆的行驶加速度小于或等于10m/s，表明车辆不仅目前行驶速度较慢且提速速度也慢，将信息发送频率设置为10Hz。
[0083] 在检测到车辆的行驶速度大于80km/h时，此时车辆的行驶速度较快，将信息发送频率设置为1Hz。
[0084] 值得说明的是，车辆的行驶速度越快或加速度越大，对预警类功能消息发送的需求越大。因此，通过综合考量车辆当前的行驶速度和行驶加速度，在行驶速度和行驶加速度中的一者大于设定值时便降低信息发送频率，使得后续步骤中第一招呼消息的发送不会对其他预警类功能消息的发送造成影响，从而能够在实现车与车之间的信息交互的同时，不影响车辆其他预警类功能消息的发送，进一步提高了车辆行驶的安全性。
[0085] 与相关技术相比，本申请实施例至少具有以下优点：通过获取车辆的运行状态，由于运行状态至少包括车辆的行驶速度，因此能够基于运行状态得知车辆是否处于高速行驶状态。再通过运行状态确定车辆的信息发送策略，由于信息发送策略至少包括信息发送频率，因此能够基于车辆不同的行驶速度确定不同的信息发送频率，从而有效避免了“当车辆行驶速度较快时，若信息发送频率较高，会影响车辆预警类功能消息的发送”的情况的发生，提高了车辆行驶过程中的安全性。此外，通过预设车辆选择规则确定与车辆进行通信的目标车辆，再向目标车辆发送第一招呼信息，能够有针对性的基于用户需求向特定车辆打招呼，提高了用户在行车过程中的驾驶体验。
[0086] 请参考图5，图5是本申请一实施例提供的车与车之间的通信方法的流程示意图，本实施例是在前述实施例的基础上做的进一步改进，主要改进之处在于，在本实施例中，运行状态还包括车辆的网络负载，还会根据网络负载的大小确定车辆的信息发送策略。通过此种方式，能够进一步提高车辆在行驶过程中的安全性。
[0087] 本实施例应用于车辆，具体流程如图5所示，包括以下步骤：
[0088] 步骤301、响应于车辆通信请求，获取车辆当前的运行状态；其中，运行状态至少包括车辆的行驶速度和行驶加速度。
[0089] 步骤302、检测行驶速度是否大于第一预设速度且小于第二预设速度；在检测到行驶速度大于第一预设速度且小于第二预设速度时，执行步骤303；在检测到行驶速度小于或等于第一预设速度时，执行步骤304；在检测到行驶速度大于或等于第二预设速度时，执行步骤305。
[0090] 步骤303、确定信息发送频率为第一频率。
[0091] 步骤304、检测行驶加速度是否大于第一预设加速度且小于第二预设加速度；在检测到行驶加速度大于第一预设加速度且小于第二预设加速度时，执行步骤303；在检测到行驶加速度小于或等于第一预设加速度时，执行步骤306；在检测到行驶加速度大于或等于第二预设加速度时，执行步骤305。
[0092] 步骤305、确定信息发送频率为第三频率。
[0093] 步骤306、检测网络负载是否大于第一负载阈值且小于第二负载阈值；在检测到网络负载大于第一负载阈值且小于第二负载阈值时，执行步骤303；在检测到网络负载小于或等于第一负载阈值时，执行步骤307；在检测到网络负载大于或等于第二负载阈值时，执行步骤305。
[0094] 可以理解的是，在网络通信中，网络负载是一个至关重要的概念，它直接反映了网络在某一时间段内的工作强度和压力。网络负载用G表示，具体来说，它是指在网络通信系统中，单位时间内所有节点总共发送的数据帧的平均数量。网络带宽负载率计算：带宽负载率＝(实际使用带宽/总带宽)*100％：其中，实际使用带宽是指在某一时刻，网络传输的数据量；总带宽是指网络的理论最大传输速度。带宽负载率的值越大，说明网络的利用率越高，也可能意味着网络可能出现拥堵情况。
[0095] 在一些实施例中，不对第一负载阈值和第二负载阈值的大小做具体限定，可以根据实际需求设置。
[0096] 步骤307、确定信息发送频率为第二频率。
[0097] 为了便于理解，下面以第一预设速度为60km/h，第二预设速度为80km/h；第一预设2 2
加速度为10m/s，第二预设加速度为20m/s；第一负载阈值为50％，第二负载阈值为80％；第一频率为5Hz，第二频率为10Hz，第三频率为1Hz为例，对本实施例如何确定信息发送策略进行具体说明：
[0098] 在检测到车辆的行驶速度大于60km/h且小于80km/h时，此时车辆的行驶速度正常，将信息发送频率设置为5Hz。
[0099] 在检测到车辆的行驶速度小于或等于60km/h时，此时车辆的行驶速度较慢，检测2 2
车辆的行驶加速度的大小。若车辆的行驶加速度大于10m/s且小于20m/s，表明车辆虽然目前行驶速度较慢但会在较短时间内加速至某一速度值，将信息发送频率设置为5Hz；若车辆
2
的行驶加速度大于或等于20m/s ，表明车辆虽然目前行驶速度较慢但会在更短的时间内加
2
速至某一速度值，将信息发送频率设置为1Hz；若车辆的行驶加速度小于或等于10m/s，表明车辆不仅目前行驶速度较慢且提速速度也慢，此时检测车辆的网络负载大小。
[0100] 在检测到网络负载大于50％且小于80％时，表明车辆处于通信需求较高的区域，将信息发送频率设置为5Hz；在检测到网络负载大于或等于80％时，表明车辆处于通信需求特别高的区域，将信息发送频率设置为1Hz；在检测到网络负载小于或等于50％时，表明车辆处于通信需求较低的区域，将信息发送频率设置为10Hz。
[0101] 在检测到车辆的行驶速度大于80km/h时，此时车辆的行驶速度较快，将信息发送频率设置为1Hz。
[0102] 在一些实施例中，还可以通过某一固定周期实时检测车辆的行驶速度、行驶加速度以及网络负载，例如每隔5秒检测一次，即每次修改的信息发送频率最小使用为5秒。以在能够及时更新信息发送频率，确保信息发送频率的可靠性的同时，避免频繁检测车辆的行驶速度、行驶加速度以及网络负载，导致信息发送频率频繁变化，而造成车辆使用算力过大。
[0103] 通过实时监测车辆行为以及网络负载情况，车辆可以动态设置打招呼功能的信息发送频率。例如，在车辆密集或通信需求高的区域，可以减低打招呼功能的信息发送频率率，避免影响其他预警类功能消息的发送；而在车辆稀疏或通信需求低的区域，则可以增加打招呼功能的信息发送频率。
[0104] 步骤308、根据信息发送频率向目标车辆发送第一招呼信息。
[0105] 与相关技术相比，本申请实施例至少具有以下优点：通过获取车辆的运行状态，由于运行状态至少包括车辆的行驶速度，因此能够基于运行状态得知车辆是否处于高速行驶状态。再通过运行状态确定车辆的信息发送策略，由于信息发送策略至少包括信息发送频率，因此能够基于车辆不同的行驶速度确定不同的信息发送频率，从而有效避免了“当车辆行驶速度较快时，若信息发送频率较高，会影响车辆预警类功能消息的发送”的情况的发生，提高了车辆行驶过程中的安全性。此外，通过预设车辆选择规则确定与车辆进行通信的目标车辆，再向目标车辆发送第一招呼信息，能够有针对性的基于用户需求向特定车辆打招呼，提高了用户在行车过程中的驾驶体验。
[0106] 请参考图6，图6是本申请一实施例提供的车与车之间的通信方法的流程示意图，本实施例是在前述实施例的基础上做的进一步改进，主要改进之处在于，在本实施例中，预设车辆选择规则包括车辆ID选择规则，若基于车辆ID选择规则确定的目标车辆在车辆的通信范围外时，会将第一招呼信息发送至车辆的通信范围内的转发车辆，再由转发车辆将第一招呼信息转发至目标车辆，通过此种方式，能够实现更远距离的车与车之间的通信，从而进一步提高了用户的使用体验。
[0107] 本实施例应用于车辆，具体流程如图6所示，包括以下步骤：
[0108] 步骤401：响应于车辆通信请求，获取车辆当前的运行状态；其中，运行状态至少包括车辆的行驶速度。
[0109] 步骤402、根据运行状态确定车辆的信息发送策略；其中，信息发送策略至少包括信息发送频率。
[0110] 步骤403、根据车辆ID选择规则确定目标车辆。
[0111] 在一些实施例中，用户在车机娱乐显示屏上输入车牌号，车辆将车牌号对应的车辆作为目标车辆。
[0112] 在一些实施例中，车辆能够识别预设范围内的所有车辆并显示在车机娱乐显示屏上，用户点击车机娱乐显示屏的某个车辆的头像，即可确定该车辆为目标车辆。
[0113] 步骤404、检测目标车辆是否在车辆的通信范围内；在检测到目标车辆在通信范围内时，执行步骤405；否则，执行步骤406。
[0114] 步骤405、根据信息发送策略向目标车辆发送第一招呼信息。
[0115] 步骤406、确定通信范围内的转发车辆。
[0116] 在一些实施例中，转发车辆通过用户预先设置的车辆选择规则确定，例如用户预先设置了仅将第一招呼信息发送至品牌A的车辆，则在进行第一招呼信息的转发时，确定的转发车辆也为品牌A的车辆。
[0117] 步骤407、根据信息发送策略向转发车辆发送第一招呼信息，以使转发车辆向目标车辆转发第一招呼信息。
[0118] 在一些实施例中，第一招呼信息中携带MsgForwarding(消息是否继续转发)，MsgForwarding能够允许转发车辆进行一次消息转发，转发车辆将第一招呼信息转发后，MsgForward数值改为false，即目标车辆在接收到第一招呼信息后，不能够再将第一招呼信息进行二次转发。
[0119] 在一些实施例中，也可以不对第一招呼信息的转发次数做具体限定。
[0120] 与相关技术相比，本申请实施例至少具有以下优点：通过获取车辆的运行状态，由于运行状态至少包括车辆的行驶速度，因此能够基于运行状态得知车辆是否处于高速行驶状态。再通过运行状态确定车辆的信息发送策略，由于信息发送策略至少包括信息发送频率，因此能够基于车辆不同的行驶速度确定不同的信息发送频率，从而有效避免了“当车辆行驶速度较快时，若信息发送频率较高，会影响车辆预警类功能消息的发送”的情况的发生，提高了车辆行驶过程中的安全性。此外，通过预设车辆选择规则确定与车辆进行通信的目标车辆，再向目标车辆发送第一招呼信息，能够有针对性的基于用户需求向特定车辆打招呼，提高了用户在行车过程中的驾驶体验。
[0121] 请参考图7，图7是本申请一实施例提供的车与车之间的通信方法的流程示意图，本实施例是在前述实施例的基础上做的进一步改进，主要改进之处在于，在本实施例中，车辆还会接收其他车辆发送的第二招呼信息，并在检测到其他车辆在预设车辆白名单内时，展示第二招呼信息。
[0122] 本实施例应用于车辆，具体流程如图7所示，包括以下步骤：
[0123] 步骤501、响应于车辆通信请求，获取车辆当前的运行状态；其中，运行状态至少包括车辆的行驶速度。
[0124] 步骤502、根据运行状态确定车辆的信息发送策略；其中，信息发送策略至少包括信息发送频率。
[0125] 步骤503、根据预设车辆选择规则确定与车辆进行通信的目标车辆。
[0126] 步骤504、根据信息发送策略向目标车辆发送第一招呼信息。
[0127] 本实施例的步骤501至步骤504与前述实施例的步骤101至步骤104类似为了避免重复，此处不再赘述。
[0128] 步骤505、接收其他车辆发送的第二招呼信息。
[0129] 在一些实施例中，第二招呼信息通过CV2X无线通信系统发送。第二招呼信息的内容类型可以包括text、emoji、voice、light等其中一个。
[0130] 具体的说，车辆的TBOX在接收到其他车辆发送的第二招呼信息后，TBOX对第二招呼信息进行消息验签，在验证消息有效后，再进行后续的检测其他车辆是否在预设车辆白名单内。
[0131] 步骤506、检测其他车辆是否在预设车辆白名单内，若其他车辆在预设车辆白名单内，执行步骤507；否则，执行步骤508。
[0132] 在一些实施例中，用户可以通过车机娱乐显示屏预设车辆白名单。例如，用户设置接收本车某一范围内的车辆发送的第二招呼信息，如设置接收本车400米内的车辆发送的第二招呼信息；用户还可以设置接收本车哪个方位的第二招呼信息，车辆包括前方、后方、左前方、右前方、左后方、右后方，六个方位；用户还可以设置接收某个品牌的车辆发送的第二招呼信息；用户还可以设置拒绝接收某一车辆的第二招呼信息。需要说明的是，本实施例不对预设车辆白名单的设置方式进行具体限定，可以根据用户的实际需求设置。
[0133] 为了便于理解，下面对本实施例如何检测其他车辆是否在预设车辆白名单内进行具体的举例说明：
[0134] 假设本车接收到车辆A发送的第二招呼消息，第二招呼信息中携带车辆A的车辆ID、车辆位置信息。
[0135] 本车的TBOX检测车辆ID是否为用户禁止招呼的车辆ID，如果车辆ID是用户禁止招呼的车辆ID，则检测车辆A不在预设车辆白名单内，如果车辆ID不是用户禁止招呼的车辆ID，则TBOX继续根据车辆位置信息计算车辆A相对于本车的方位，检测该方位是否为用户设置的方位，如果是，则表明车辆在预设车辆白名单内。
[0136] 步骤507、展示第二招呼信息。
[0137] 在一些实施例中，第二招呼信息的类型为文本消息或表情消息时，通过车机娱乐显示屏显示第二招呼信息；第二招呼信息的类型为声音消息时，检测本车是否允许车外音响播放，如果允许则将第二招呼信息传输至车外音响控制器进行播放，或播放本车用户设置的车外音响回复消息。
[0138] 在一些实施例中，车机娱乐显示屏还会显示其他车辆的ID以及相对本车的方位信息，以进一步提高用户的使用体验。
[0139] 步骤508、丢弃第二招呼信息。
[0140] 为了便于理解，下面结合图8，对本实施例的应用场景进行具体的说明：
[0141] 请参考图8，为本申请实施例提供的车机娱乐显示屏显示的远车示意图。
[0142] 以某个SMART车型为例，定制本车型的车辆实现自动招呼功能。假设用户驾驶的是SMART车型的车辆B，用户开启招呼功能；车辆B的车机默认仅接收左前方和右前方、200米内、本品牌的车辆的招呼消息；当车辆B收到远车发送的招呼消息时，按照上述流程，判断车辆为左前方、距离200米内、是本品牌车辆，则车辆B自动播放外置灯语以及外置音响的欢迎语音“Nice to meet you，I'm SMART Tom。”，并在车机娱乐显示屏上显示如图8所示的远车示意图。
[0143] 与相关技术相比，本申请实施例至少具有以下优点：通过获取车辆的运行状态，由于运行状态至少包括车辆的行驶速度，因此能够基于运行状态得知车辆是否处于高速行驶状态。再通过运行状态确定车辆的信息发送策略，由于信息发送策略至少包括信息发送频率，因此能够基于车辆不同的行驶速度确定不同的信息发送频率，从而有效避免了“当车辆行驶速度较快时，若信息发送频率较高，会影响车辆预警类功能消息的发送”的情况的发生，提高了车辆行驶过程中的安全性。此外，通过预设车辆选择规则确定与车辆进行通信的目标车辆，再向目标车辆发送第一招呼信息，能够有针对性的基于用户需求向特定车辆打招呼，提高了用户在行车过程中的驾驶体验。
[0144] 请参考图9，为本申请实施例提供的车辆100的结构示意图。车辆100包括：状态获取模块1、发送策略确定模块2、车辆确定模块3以及通信模块4；状态获取模块1用于响应于车辆通信请求，获取车辆当前的运行状态；其中，所述运行状态至少包括所述车辆的行驶速度；发送策略确定模块2用于根据所述运行状态确定所述车辆的信息发送策略；其中，所述信息发送策略至少包括信息发送频率；车辆确定模块3用于根据预设车辆选择规则确定与所述车辆进行通信的目标车辆；通信模块4用于根据所述信息发送策略向所述目标车辆发送第一招呼信息。
[0145] 请参考图10，为本申请实施例提供的电子设备1000的硬件结构示意图。如图10所示，电子设备1000可以包括处理器1001、存储器1002。存储器1002用于存储一个或多个计算机程序1003。一个或多个计算机程序1003被配置为被该处理器1001执行。该一个或多个计算机程序1003包括指令，上述指令可以用于实现在电子设备1000中执行上述的车与车之间的通信方法。
[0146] 可以理解的是，本实施例示意的结构并不构成对电子设备1000的具体限定。在另一些实施例中，电子设备1000可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。
[0147] 处理器1001可以包括一个或多个处理单元，例如：处理器1001可以包括应用处理器(application processor，AP)，调制解调器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural‑network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
[0148] 处理器1001还可以设置有存储器，用于存储指令和数据。在一些实施例中，处理器1001中的存储器为高速缓冲存储器。该存储器可以保存处理器1001刚用过或循环使用的指令或数据。如果处理器1001需要再次使用该指令或数据，可从该存储器中直接调用。避免了重复存取，减少了处理器1001的等待时间，因而提高了系统的效率。
[0149] 在一些实施例中，处理器1001可以包括一个或多个接口。接口可以包括集成电路(inter‑integrated circuit，I2C)接口，集成电路内置音频(inter‑integrated circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general‑purpose input/output，GPIO)接口，SIM接口，和/或USB接口等。
[0150] 在一些实施例中，处理器1001用于执行单指令多数据(SIMD)、超长指令字(VLIW)等加速方案。
[0151] 在一些实施例中，存储器1002可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
[0152] 本实施例还提供一种存储介质，该存储介质中存储有计算机指令，当该指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的车与车之间的通信方法。
[0153] 其中，本实施例提供的电子设备、存储介质均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
[0154] 实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
[0155] 在本申请所提供的几个实施例中，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例是示意性的，例如，该模块或单元的划分，为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0156] 该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0157] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0158] 该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read‑Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
[0159] 以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。
