CN112585931A - 车辆通信方法和通信装置 - Google Patents
车辆通信方法和通信装置 Download PDFInfo
- Publication number
- CN112585931A CN112585931A CN202080004605.1A CN202080004605A CN112585931A CN 112585931 A CN112585931 A CN 112585931A CN 202080004605 A CN202080004605 A CN 202080004605A CN 112585931 A CN112585931 A CN 112585931A
- Authority
- CN
- China
- Prior art keywords
- message
- frame
- vehicle
- sent
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9063—Intermediate storage in different physical parts of a node or terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computer Security & Cryptography (AREA)
- Small-Scale Networks (AREA)
Abstract
本申请提供了一种车辆通信方法和通信装置,涉及车辆通信领域。该方法包括:接收第一报文,第一报文包括校验字段和唯一标识符,唯一标识符包括帧标识ID和互联网协议IP地址;根据第一报文的校验字段,对第一报文进行检查;将通过检查的第一报文根据帧ID存储到帧ID所对应的缓存空间。该方法应用在网联汽车、智能汽车、自动驾驶汽车等车辆上,通过为报文设置唯一标识符,实现报文的识别,从而保证了报文的同步发送和实现报文的甄别。且对于车载设备的精度要求没有过于严格的要求,完全不需要对齐时间,所以适用于现有的车辆中的车载设备。此外,为每个帧ID设置独立的缓存空间,使得报文的存储和读取都更为方便快捷。
Description
技术领域
本申请涉及车辆通信领域,并且具体地,涉及一种车辆通信方法和通信装置。
背景技术
随着汽车技术的不断发展,对于车载设备之间的通信需求越来越高。为了满足通信需求,通常需要对车载设备采用冗余连接的方式,对接入链路进行冗余备份。在这种冗余连接方式下,对于报文的发送和接收期间的处理方式都提出了更高的要求,例如,如何将报文同步、如何甄别报文等等。举例说明,某个车载设备先发送相同内容的两帧报文至网络中进行传输,这两帧报文最终抵达目标设备(例如可以是另外一个车载设备或者上位机设备等等)的指定网口和指定端口,但在这期间该车载设备需要建立有效机制和逻辑,保证可以同步发送上述相同内容的两帧报文,而该目标设备又需要在同一周期内完成对上述两帧报文的甄别。要想实现上述过程,通常需要制定一整套完整的协议机制来保证其发送和接收的可靠性,以及应用逻辑的可判断性,最终实现报文在以太网网络层的实时传输和冗余仲裁。
通用工业协议(common industrial protocol,CIP)是一种应用在工业自动化的通信协定,但由于这种基于连接的通信通常需要建立通信通路,且通常是点对点的通信方式,会占用很多的连接资源,且传输能力也非常局限,所以无法在车领域中得到广泛应用。为了实现车载设备之间的良好通信,汽车以太网应运而生,例如采用常见的可扩展的面向服务的协议栈(scalable service-oriented middleware over internet protocol,SOME/IP)(即位于IP协议层以上的一种面向服务的可伸缩的中间件),虽然SOME/IP具有比CIP更好的性能,但是SOME/IP的协议深度太深且具有较大的独立性,尤其对于应用层来说复杂度较高,此外,目前的SOME/IP依然无法满足上述冗余机制的需求,也就是说,无法满足上述冗余机制对于报文同步和甄别的要求。
而如果直接将现有的通信领域的通信机制应用于车领域的通信,即基于时间同步来实现上述车领域的以太网的实时传输,则过于复杂繁琐。
因此,如何更好地实现车载设备的冗余数据的实时传输是亟待解决的技术问题。
发明内容
本申请提供一种车辆通信方法和通信装置,能够更好地实现车载设备的冗余数据的实时传输。
第一方面,提供了一种车辆通信的方法,该方法包括:接收第一报文,第一报文包括校验字段和唯一标识符,该唯一标识符包括帧标识ID和互联网协议IP地址;根据第一报文的校验字段,对第一报文进行检查;若第一报文通过检查,根据帧ID将第一报文存储到帧ID所对应的缓存空间。
在本申请技术方案中,通过为报文设置唯一标识符,实现报文的识别,从而保证了报文的同步发送和实现报文的甄别。本申请技术方案相比于基于时间同步的通信方式,不要求接收端和发送端的时间同步,同时避免了不同设备的时间精度不同和时间误差等导致的报文甄别错误,也就是说,对于车载设备的精度要求没有过于严格的要求,完全不需要对齐时间,所以适用于现有的车辆中的车载设备。此外,为每个帧ID设置独立的缓存空间,是非常适用于车辆通信场景的方案,使得报文的存储和读取都更为方便快捷。
结合第一方面,在第一方面的某些实现方式中,可选地,若第一报文没有通过检查,将第一报文丢弃。
可选地,在上述检查报文、存储报文或丢弃报文的过程中,可以根据接收到的报文(例如第一报文)的校验字段,检查报文是否正确,当报文正确的时候对报文进行进一步处理,当报文存在错误的时候,可以将报文丢弃。也就是说,当报文正确的时候认为检查结果为“通过”,对报文进行进一步处理(例如存储到帧ID对应的缓存空间中);当报文错误的时候认为检查结果为“未通过”,将报文丢弃。这是因为,为了保证接收到的报文所承载的数据是正确的,往往会设置校验字段,该校验字段与承载的内容存在对应关系,因此,当接收到的报文存在错误时,根据承载的数据推算出的校验字段与发送报文时承载的校验字段就会不一致,就可以认为该报文存在错误,就可以将报文进行丢弃。
在存储报文时,以从两个数据传输通道接收报文为例,例如可以将从网口0和网口1接收的第一报文传送至应用程序的两个独立的缓存区,应用程序会给每一个帧ID在对应的网口下分别创建一个独立的缓存空间。当接受到报文后,将这些报文根据帧ID投送到对应缓存区间储存。每一个帧ID只分配一个对应大小的缓存空间,在每个缓存空间接收的报文都会被覆盖存储。即当前最新接收到的报文会覆盖上一次存在该缓存区的报文。
可选地,还可以对发送的报文进行计数,也就是说,对每帧报文进行编号,或者可以理解为设置报文帧的时间顺序标识。也就是说,第一报文是带有发送时的时间顺序的标识的。
可选地,可以定义帧序列计数(sequence counter),将帧序列计数作为报文的顺序识别码。可以在发送报文的一端进行累加,每发送一帧报文,帧序列计数器累加1。
需要说明的是,在本申请实施例中,帧序列计数用于表示发送报文的先后顺序,可以理解为是发送报文的时间次序(顺序)。例如某个报文帧序列计数为5相当于该报文是第5次发送的,假设另外一个报文的帧序列计数为7相当于该报文是第7次发送的,还可以知道该报文是在帧序列计数为5的报文发送之后发送的,可以看作是,帧序列计数为7的报文的发送时间晚于帧序列计数为5的报文。应理解,上述只是为了说明帧序列计数的含义的一种示例,不存在限定。
还需要说明的是,在本申请中,报文的发送次序可以理解为发送报文的先后顺序,并不是报文的实际发送时间。换而言之,在现有的通讯中是用时间戳作为报文的发送时间顺序的,这是实际发送时间的先后,而在本申请中只是报文发送次序的先后,并不对应实际时间,可以将其看作是对每个发送报文的排序。正是由于通过发送次序来区分报文的新鲜度,而不需要对应实际的时间,才使得本申请的方案不需要严格要求所有设备的时间同步。需要说明的是,在本申请实施例中,主要利用帧序列计数来辅助读取报文,使得可以选择更新(时间较晚)的报文,该报文选择规则非常适用于车辆通信的这一特殊应用场景,而这种方法在常见的通信(例如手机等终端之间的通信)并不适用,因为常见的通信场景涉及的数据量非常庞大,如果采用计数的方式很容易出现,帧序列计数已经达到最大值,却还有数据没有办法存储的情况,导致数据丢失等等问题。且本申请中需要为每个帧ID配置独立的缓存空间,这也是常见的通信场景无法满足的。正因为上述原因,在常见的通信场景中目前均采用时间同步的方式,而无法采用计数的方式。如果将基于时间同步的通信方式应用到车领域通信,则相比于本申请的方案会非常繁琐,没有本申请的方案简洁和易于实现。
可选地,还可以对存储的报文进行读取,例如可以在接收到应用程序发出的读取请求时,从相应的帧ID的缓存空间中读取出报文。
结合第一方面,在第一方面的某些实现方式中,上述唯一标识符还包括帧序列计数,可以获取读取请求,读取请求包括待读取报文的帧ID;从待读取报文的帧ID所对应的缓存空间中读取至少一个第一报文,该至少一个第一报文的帧序列计数的值用于表示其被发送次序;从至少一个存储的报文中选中对应的帧序列计数的值最大的报文且返回该第二报文。
可选地,可以根据存储的报文的上述帧序列计数,从这至少一个第一报文(即上述接收的第一报文中被存储起来的报文)中选择出合适的报文作为第二报文,第二报文可以理解为响应读取请求所读取出来的报文,或者可以理解为返回给读取请求的发起者的报文。
也就是说,当应用程序通过接口函数读取指定帧ID报文时,程序在对应的帧ID缓存区获取来自不同网口的报文。并且按照设定的仲裁逻辑进行冗余报文仲裁,仲裁获胜的报文,通过接口函数返回给用户应用层。在报文读取时会保护该缓冲区,对缓冲区进行加锁互斥处理,当读取过程中有写入请求,则将该请求挂起,当数据拷贝完成立即释放,并写入新接收的报文。
可选地,为了使得接收报文和读取报文不会互相影响,可以在接收报文的过程中不响应读取请求,在读取报文的过程中暂停存储报文。
结合第一方面,在第一方面的某些实现方式中,还可以将至少一个第一报文中未被选中的报文丢弃。也就是说,在读取报文的时候,丢弃没有被选中的报文,这样可以释放缓存空间,降低存储开销。
从上文可以看出,每帧报文的帧ID是相同的,帧序列计数也是相同的。但是每帧报文从多个数据传输通道的网口发送出去之前,会装载MAC地址和IP地址,所以从多个网口发出去的报文的MAC地址和IP地址是不同的,因此报文的帧ID和IP地址可以构成报文的唯一标识符。且帧序列计数也可以作为唯一标识符的组成部分。因此对于接收端来说,接收到的第一报文可可能会出现帧ID相同但IP地址不同的情况。
结合第一方面,在第一方面的某些实现方式中,第一报文是车辆通信装置从多个数据传输通道的网口之一发送的,多个数据传输通道的IP地址互不相同。
也就是说,第一报文是利用本申请实施例所提供的具有多个数据传输通道的车辆通信装置发送的。
可选地,上述报文,例如第一报文、第二报文、存储的报文等等,可以存在多种报文结构(格式)。例如在明文传输的时候可以没有加密相关的字段,在密文传输的时候可以包括加密相关的字段。
结合第一方面,在第一方面的某些实现方式中,第一报文可以包括:IP首部、用户数据报协议UDP首部、协议数据单元PDU首部和数据区。
可选地,上述唯一标识符的IP地址可以是被装载在IP首部中的,唯一标识符的其他元素(例如帧ID、帧序列计数)可以是被装载在PDU首部中的。
结合第一方面,在第一方面的某些实现方式中,第一报文还可以包括安全数据传输协议区。
结合第一方面,在第一方面的某些实现方式中,第一报文还可以包括数字签名区首部和密钥区。
第二方面,提供了一种车辆通信的方法,该方法包括:将第一待发送报文进行数据装载,第一待发送报文包括帧标识ID;将第一待发送报文传递给多个数据传输通道,多个数据传输通道的互联网协议IP地址互不相同;为第一待发送报文装载多个数据传输通道的IP地址,得到多个第二待发送报文;在同一发送周期内,发送该多个第二待发送报文。
在本申请技术方案中,通过为报文设置唯一标识符,实现报文的识别,从而保证了报文的同步发送和实现报文的甄别。唯一标识符例如可以包括上述帧ID和IP地址。本申请技术方案相比于基于时间同步的通信方式,不要求接收端和发送端的时间同步,同时避免了不同设备的时间精度不同和时间误差等导致的报文甄别错误,也就是说,对于车载设备的精度要求没有过于严格的要求,完全不需要对齐时间,所以适用于现有的车辆中的车载设备。此外,为每个帧ID设置独立的缓存空间,是非常适用于车辆通信场景的方案,使得报文的存储和读取都更为方便快捷。
需要说明的是,在同一个发送周期内发送报文可以理解为同时发送报文。这些第二待发送报文中装载的数据、帧ID相同,但是IP地址不同。
还需要说明的是,第一方面所述第一报文是指接收端的车辆通信装置所接收到的报文,而第二方面所述第一待发送报文是发送端的车辆通信装置在发送报文前生成的报文。
可选地,当第一待发送报文传送到不同的数据传输通道后,可以分别把数据传输通道的IP地址装载进第一待发送报文,从而得到第二待发送报文。也就是说,第二待发送报文是在第一待发送报文的基础上装载了IP地址得到的。
需要说明的是,第一方面所述第二报文是指接收端的车辆通信装置在读取报文时,从帧ID的缓存空间中读取到的报文,而第二方面所述第二待发送报文是发送端的车辆通信装置在发送报文前,在第一待发送报文的基础上经过进一步处理得到的报文。
可选地,还可以为第一待发送报文装载帧序列计数,使得第二待发送报文中包括帧序列计数。可以理解为,对发送的报文进行计数,也就是说,对每帧报文进行编号,或者可以理解为设置报文帧的时间顺序标识。也就是说,第一报文是带有发送时的时间顺序的标识的。
可选地,可以定义帧序列计数,将帧序列计数作为报文的顺序识别码。可以在发送报文的一端进行累加,每发送一帧报文,帧序列计数器累加1。
需要说明的是,在本申请实施例中,帧序列计数用于表示发送报文的先后顺序,可以理解为是发送报文的时间次序(顺序)。例如某个报文帧序列计数为5相当于该报文是第5次发送的,假设另外一个报文的帧序列计数为7相当于该报文是第7次发送的,还可以知道该报文是在帧序列计数为5的报文发送之后发送的,可以看作是,帧序列计数为7的报文的发送时间晚于帧序列计数为5的报文。应理解,上述只是为了说明帧序列计数的含义的一种示例,不存在限定。
结合第二方面,在第二方面的某些实现方式中,还可以为第二待发送报文装载帧序列计数,帧序列计数用于表示第二待发送报文的发送次序。
结合第二方面,在第二方面的某些实现方式中,可以设置帧序列计数初始值为0,且帧序列计数小于或等于预设阈值。
可选地,可以每发送一次第二待发送报文,帧序列计数的值累加1,且当帧序列计数的值累加到大于或等于预设阈值时,将帧序列计数的值归零。
可选地,上述报文,例如第一待发送报文、第二待发送报文,可以存在多种报文结构(格式)。例如在明文传输的时候可以没有加密相关的字段,在密文传输的时候可以包括加密相关的字段。
从上文可以看出,每帧报文的帧ID是相同的,帧序列计数也是相同的。但是每帧报文从多个数据传输通道的网口发送出去之前,会装载MAC地址和IP地址,所以从多个网口发出去的报文的MAC地址和IP地址是不同的,因此报文的帧ID和IP地址可以构成报文的唯一标识符。且帧序列计数也可以作为唯一标识符的组成部分。
结合第二方面,在第二方面的某些实现方式中,第一待发送报文和第二待发送报文均包括:IP首部、用户数据报协议UDP首部、协议数据单元PDU首部和数据区,帧ID被装载在第一待发送报文的PDU首部和第二待发送报文的PDU首部中,IP地址被装载在第二待发送报文的IP首部中。
结合第二方面,在第二方面的某些实现方式中,IP地址被装载在第二待发送报文的PDU首部中。
结合第二方面,在第二方面的某些实现方式中,第二待发送报文还包括安全数据传输协议区。
结合第二方面,在第二方面的某些实现方式中,第二待发送报文还包括数字签名区首部和密钥区。
第三方面,提供了一种车辆通信的装置,包括用于执行第一方面或第二方面任一种可能实现方式中的方法的单元。
第四方面,提供了一种车辆通信的装置,包括处理器。该处理器与存储器耦合,可用于执行存储器中的指令或者数据,以实现上述第一方面或第二方面任一种可能实现方式中的方法。可选地,该通信装置还包括存储器。可选地,该通信装置还包括通信接口,处理器与通信接口耦合。
第五方面,提供了一种计算机程序产品,所述计算机程序产品包括:计算机程序(也可以称为代码,或指令),当所述计算机程序被运行时,使得计算机执行上述第一方面或第二方面任一种可能实现方式中的方法。
第六方面,提供了一种计算机可读介质,所述计算机可读介质存储有计算机程序(也可以称为代码,或指令)当其在计算机上运行时,使得计算机执行上述第一方面或第二方面任一种可能实现方式中的方法。
附图说明
图1是本申请实施例适用的一种车辆的功能框图。
图2是本申请实施例适用的一种自动驾驶***的示意图。
图3是本申请实施例的一种云侧指令自动驾驶车辆的应用示意图。
图4是本申请实施例的车辆通信装置的多数据传输通道冗余通信的示意图。
图5是本申请实施例的接收冗余报文的处理流程示意图。
图6是本申请实施例的接收冗余报文的处理流程示意图。
图7是本申请实施例的发送冗余报文的处理流程示意图。
图8是本申请实施例的一种报文帧的格式示意图。
图9是本申请实施例的另一种报文帧的格式示意图。
图10是本申请实施例的又一种报文帧的格式示意图。
图11是本申请实施例的车辆通信装置在同一网络的连接示意图。
图12是本申请实施例的车辆通信装置在不同网络的连接示意图。
图13是本申请实施例的PDU报文格式的示意图。
图14是本申请实施例的冗余报文的发送流程示意图。
图15是本申请实施例的冗余报文的接收流程示意图。
图16是本申请实施例的一种车辆通信装置的示意性框图。
图17是本申请实施例的一种车辆通信装置的硬件结构示意图。
图18是本申请实施例的一种车辆通信装置的示意图。
图19是本申请实施例的一种车辆通信装置的硬件结构示意图。
具体实施方式
本申请实施例所提供的车辆通信方法和/或车辆通信装置可以应用于各类车辆。这些方法和/或装置既可以应用于人工驾驶,又可以应用于辅助驾驶,还可以应用于自动驾驶。下面结合附图,对本申请实施例的技术方案进行介绍。
图1是本申请实施例适用的一种车辆的功能框图。其中,车辆100可以是人工驾驶车辆,或者可以将车辆100配置可以为完全或部分地自动驾驶模式。
在一个示例中,车辆100可以在处于自动驾驶模式中的同时控制自车,并且可通过人为操作来确定车辆及其周边环境的当前状态,确定周边环境中的至少一个其他车辆的可能行为,并确定其他车辆执行可能行为的可能性相对应的置信水平,基于所确定的信息来控制车辆100。在车辆100处于自动驾驶模式中时,可以将车辆100置为在没有和人交互的情况下操作。
车辆100中可以包括各种子***,例如,行进***110、传感***120、控制***130、一个或多个***设备140以及电源160、计算机***150和用户接口170。
可选地,车辆100可以包括更多或更少的子***,并且每个子***可包括多个元件。另外,车辆100的每个子***和元件可以通过有线或者无线互连。
示例性地,行进***110可以包括用于向车辆100提供动力运动的组件。在一个实施例中,行进***110可以包括引擎111、传动装置112、能量源113和车轮114/轮胎。其中,引擎111可以是内燃引擎、电动机、空气压缩引擎或其他类型的引擎组合;例如,汽油发动机和电动机组成的混动引擎,内燃引擎和空气压缩引擎组成的混动引擎。引擎111可以将能量源113转换成机械能量。
示例性地,能量源113可以包括汽油、柴油、其他基于石油的燃料、丙烷、其他基于压缩气体的燃料、乙醇、太阳能电池板、电池和其他电力来源。能量源113也可以为车辆100的其他***提供能量。
示例性地,传动装置112可以包括变速箱、差速器和驱动轴;其中,传动装置112可以将来自引擎111的机械动力传送到车轮114。
在一个实施例中,传动装置112还可以包括其他器件,比如离合器。其中,驱动轴可以包括可耦合到一个或多个车轮114的一个或多个轴。
示例性地,传感***120可以包括感测关于车辆100周边的环境的信息的若干个传感器。
例如,传感***120可以包括定位***121(例如,全球定位***(globalpositioning system,GPS)、北斗***或者其他定位***)、惯性测量单元(inertialmeasurement unit,IMU)122、雷达123、激光测距仪124、相机125以及车速传感器126。传感***120还可以包括被监视车辆100的内部***的传感器(例如,车内空气质量监测器、燃油量表、机油温度表等)。来自这些传感器中的一个或多个的传感器数据可用于检测对象及其相应特性(位置、形状、方向、速度等)。这种检测和识别是自主车辆100的安全操作的关键功能。
其中,定位***121可以用于估计车辆100的地理位置。IMU 122可以用于基于惯性加速度来感测车辆100的位置和朝向变化。在一个实施例中,IMU 122可以是加速度计和陀螺仪的组合。
示例性地,雷达123可以利用无线电信号来感测车辆100的周边环境内的物体。在一些实施例中,除了感测物体以外,雷达123还可用于感测物体的速度和/或前进方向。
示例性地,激光测距仪124可以利用激光来感测车辆100所位于的环境中的物体。在一些实施例中,激光测距仪124可以包括一个或多个激光源、激光扫描器以及一个或多个检测器,以及其他***组件。
示例性地,相机125可以用于捕捉车辆100的周边环境的多个图像。例如,相机125可以是静态相机或视频相机。
示例性地,车速传感器126可以用于测量车辆100的速度。例如,可以对车辆进行实时测速。测得的车速可以传送给控制***130以实现对车辆的控制。
如图1所示,控制***130为控制车辆100及其组件的操作。控制***130可以包括各种元件,比如可以包括转向***131、油门132、制动单元133、计算机视觉***134、路线控制***135以及障碍规避***136。
示例性地,转向***131可以操作来调整车辆100的前进方向。例如,在一个实施例中可以为方向盘***。油门132可以用于控制引擎111的操作速度并进而控制车辆100的速度。
示例性地,制动单元133可以用于控制车辆100减速;制动单元133可以使用摩擦力来减慢车轮114。在其他实施例中,制动单元133可以将车轮114的动能转换为电流。制动单元133也可以采取其他形式来减慢车轮114转速从而控制车辆100的速度。
如图1所示,计算机视觉***134可以操作来处理和分析由相机125捕捉的图像以便识别车辆100周边环境中的物体和/或特征。上述物体和/或特征可以包括交通信号、道路边界和障碍物。计算机视觉***134可以使用物体识别算法、运动中恢复结构(structurefrom motion,SFM)算法、视频跟踪和其他计算机视觉技术。在一些实施例中,计算机视觉***134可以用于为环境绘制地图、跟踪物体、估计物体的速度等等。
示例性地,路线控制***135可以用于确定车辆100的行驶路线。在一些实施例中,路线控制***135可结合来自传感器、GPS和一个或多个预定地图的数据以为车辆100确定行驶路线。
如图1所示,障碍规避***136可以用于识别、评估和避免或者以其他方式越过车辆100的环境中的潜在障碍物。
在一个实例中,控制***130可以增加或替换地包括除了所示出和描述的那些以外的组件。或者也可以减少一部分上述示出的组件。
如图1所示,车辆100可以通过***设备140与外部传感器、其他车辆、其他计算机***或用户之间进行交互;其中,***设备140可包括无线通信***141、车载电脑142、麦克风143和/或扬声器144。
在一些实施例中,***设备140可以提供车辆100与用户接口170交互的手段。例如,车载电脑142可以向车辆100的用户提供信息。用户接口116还可操作车载电脑142来接收用户的输入;车载电脑142可以通过触摸屏进行操作。在其他情况中,***设备140可以提供用于车辆100与位于车内的其它设备通信的手段。例如,麦克风143可以从车辆100的用户接收音频(例如,语音命令或其他音频输入)。类似地,扬声器144可以向车辆100的用户输出音频。
如图1所述,无线通信***141可以直接地或者经由通信网络来与一个或多个设备无线通信。例如,无线通信***141可以使用3G蜂窝通信;例如,码分多址(code divisionmultiple access,CDMA))、EVD0、全球移动通信***(global system for mobilecommunications,GSM)/通用分组无线服务(general packet radio service,GPRS),或者4G蜂窝通信,例如长期演进(long term evolution,LTE);或者,5G蜂窝通信。无线通信***141可以利用无线上网(WiFi)与无线局域网(wireless local area network,WLAN)通信。
在一些实施例中,无线通信***141可以利用红外链路、蓝牙或者紫蜂协议(ZigBee)与设备直接通信;其他无线协议,例如各种车辆通信***,例如,无线通信***141可以包括一个或多个专用短程通信(dedicated short range communications,DSRC)设备,这些设备可包括车辆和/或路边台站之间的公共和/或私有数据通信。
需要说明的是,本申请实施例所提供的通信方案主要适用于车载设备之间利用以太网进行通信的场景,可以是同一车辆的不同车载设备之间的通信,也可以是不同车辆的车载设备之间的通信。在本申请实施例中,车辆通信装置可以是上述无线通信***141中的任意设备,也可以是集成在任意车载设备中的一个通信装置,例如可以是集成在制动单元133中的一个通信装置,不再一一列举。
如图1所示,电源160可以向车辆100的各种组件提供电力。在一个实施例中,电源160可以为可再充电锂离子电池或铅酸电池。这种电池的一个或多个电池组可被配置为电源为车辆100的各种组件提供电力。在一些实施例中,电源160和能量源113可一起实现,例如一些全电动车中那样。
示例性地,车辆100的部分或所有功能可以受计算机***150控制,其中,计算机***150可以包括至少一个处理器151,处理器151执行存储在例如存储器152中的非暂态计算机可读介质中的指令153。计算机***150还可以是采用分布式方式控制车辆100的个体组件或子***的多个计算设备。
例如,处理器151可以是任何常规的处理器,诸如商业可获得的中央处理器(central processing unit,CPU)。
可选地,该处理器可以是诸如专用集成电路(application specific integratedcircuit,ASIC)或其它基于硬件的处理器的专用设备。尽管图1功能性地图示了处理器、存储器、和在相同块中的计算机的其它元件,但是本领域的普通技术人员应该理解该处理器、计算机、或存储器实际上可以包括可以或者可以不存储在相同的物理外壳内的多个处理器、计算机或存储器。例如,存储器可以是硬盘驱动器或位于不同于计算机的外壳内的其它存储介质。因此,对处理器或计算机的引用将被理解为包括对可以或者可以不并行操作的处理器或计算机或存储器的集合的引用。不同于使用单一的处理器来执行此处所描述的步骤,诸如转向组件和减速组件的一些组件每个都可以具有其自己的处理器,所述处理器只执行与特定于组件的功能相关的计算。
在此处所描述的各个方面中,处理器可以位于远离该车辆并且与该车辆进行无线通信。在其它方面中,此处所描述的过程中的一些在布置于车辆内的处理器上执行而其它则由远程处理器执行,包括采取执行单一操纵的必要步骤。
在一些实施例中,存储器152可包含指令153(例如,程序逻辑),指令153可以被处理器151来执行车辆100的各种功能,包括以上描述的那些功能。存储器152也可包括额外的指令,比如包括向行进***110、传感***120、控制***130和***设备140中的一个或多个发送数据、从其接收数据、与其交互和/或对其进行控制的指令。
示例性地,除了指令153以外,存储器152还可存储数据,例如,道路地图、路线信息,车辆的位置、方向、速度以及其它这样的车辆数据,以及其他信息。这种信息可在车辆100在自主、半自主和/或手动模式中操作期间被车辆100和计算机***150使用。
如图1所示,用户接口170可以用于向车辆100的用户提供信息或从其接收信息。可选地,用户接口170可以包括在***设备140的集合内的一个或多个输入/输出设备,例如,无线通信***141、车载电脑142、麦克风143和扬声器144。
在本申请的实施例中,计算机***150可以基于从各种子***(例如,行进***110、传感***120和控制***130)以及从用户接口170接收的输入来控制车辆100的功能。例如,计算机***150可以利用来自控制***130的输入以便控制制动单元133来避免由传感***120和障碍规避***136检测到的障碍物。在一些实施例中,计算机***150可操作来对车辆100及其子***的许多方面提供控制。
可选地,上述这些组件中的一个或多个可与车辆100分开安装或关联。例如,存储器152可以部分或完全地与车辆100分开存在。上述组件可以按有线和/或无线方式来通信地耦合在一起。
可选地,上述组件只是一个示例,实际应用中,上述各个模块中的组件有可能根据实际需要增添或者删除,图1不应理解为对本申请实施例的限制。
可选地,车辆100可以是在道路行进的自动驾驶汽车,可以识别其周围环境内的物体以确定对当前速度的调整。物体可以是其它车辆、交通控制设备、或者其它类型的物体。在一些示例中,可以独立地考虑每个识别的物体,并且基于物体的各自的特性,诸如它的当前速度、加速度、与车辆的间距等,可以用来确定自动驾驶汽车所要调整的速度。
可选地,车辆100或者与车辆100相关联的计算设备(如图1的计算机***150、计算机视觉***134、存储器152)可以基于所识别的物体的特性和周围环境的状态(例如,交通、雨、道路上的冰等等)来预测所述识别的物体的行为。
可选地,每一个所识别的物体都依赖于彼此的行为,因此,还可以将所识别的所有物体全部一起考虑来预测单个识别的物体的行为。车辆100能够基于预测的所述识别的物体的行为来调整它的速度。换句话说,自动驾驶汽车能够基于所预测的物体的行为来确定车辆将需要调整到(例如,加速、减速、或者停止)稳定状态。在这个过程中,也可以考虑其它因素来确定车辆100的速度,诸如,车辆100在行驶的道路中的横向位置、道路的曲率、静态和动态物体的接近度等等。
除了提供调整自动驾驶汽车的速度的指令之外,计算设备还可以提供修改车辆100的转向角的指令,以使得自动驾驶汽车遵循给定的轨迹和/或维持与自动驾驶汽车附近的物体(例如,道路上的相邻车道中的轿车)的安全横向和纵向距离。
上述车辆100可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车、和手推车等,本申请实施例不做特别的限定。
在一种可能的实现方式中,上述图1所示的车辆100可以是自动驾驶车辆,下面对自动驾驶***的进行详细描述。
图2是本申请实施例适用的一种自动驾驶***的示意图。
如图2所示的自动驾驶***包括计算机***201,其中,计算机***201包括处理器203,处理器203和***总线205耦合。处理器203可以是一个或者多个处理器,其中,每个处理器都可以包括一个或多个处理器核。显示适配器207(video adapter),显示适配器可以驱动显示器209,显示器209和***总线205耦合。***总线205可以通过总线桥211和输入输出(I/O)总线213耦合,I/O接口215和I/O总线耦合。I/O接口215和多种I/O设备进行通信,比如,输入设备217(如:键盘,鼠标,触摸屏等),媒体盘221(media tray),(例如,CD-ROM,多媒体接口等)。收发器223可以发送和/或接受无线电通信信号,摄像头255可以捕捉景田和动态数字视频图像。其中,和I/O接口215相连接的接口可以是USB端口225。
其中,处理器203可以是任何传统处理器,比如,精简指令集计算(reducedinstruction set computer,RISC)处理器、复杂指令集计算(complex instruction setcomputer,CISC)处理器或上述的组合。
可选地,处理器203可以是诸如专用集成电路(ASIC)的专用装置;处理器203可以是神经网络处理器或者是神经网络处理器和上述传统处理器的组合。
可选地,在一些实施例中,计算机***201可位于远离自动驾驶车辆的地方,并且可与自动驾驶车辆无线通信。在其它方面,本申请所述的一些过程在设置在自动驾驶车辆内的处理器上执行,其它由远程处理器执行,包括采取执行单个操纵所需的动作。
计算机***201可以通过网络接口229和软件部署服务器249通信。网络接口229可以是硬件网络接口,比如,网卡。网络227可以是外部网络,比如,因特网,也可以是内部网络,比如以太网或者虚拟私人网络(virtual private network,VPN)。可选地,网络227还可以是无线网络,比如WiFi网络,蜂窝网络等。
需要说明的是,本申请实施例所提供的通信方案主要适用于车载设备之间利用以太网进行通信的场景,可以是同一车辆的不同车载设备之间的通信,也可以是不同车辆的车载设备之间的通信。在本申请实施例中,车辆通信装置可以是独立于车载设备之外的通信装置,也可以是集成在任意车载设备中的通信装置。
如图2所示,硬盘驱动接口和***总线205耦合,硬件驱动器接口231可以与硬盘驱动器233相连接,***内存235和***总线205耦合。运行在***内存235的数据可以包括操作***237和应用程序243。其中,操作***237可以包括解析器(shell)239和内核(kernel)241。shell 239是介于使用者和操作***之内核(kernel)间的一个接口。shell可以是操作***最外面的一层;shell可以管理使用者与操作***之间的交互,比如,等待使用者的输入,向操作***解释使用者的输入,并且处理各种各样的操作***的输出结果。内核241可以由操作***中用于管理存储器、文件、外设和***资源的那些部分组成。直接与硬件交互,操作***内核通常运行进程,并提供进程间的通信,提供CPU时间片管理、中断、内存管理、IO管理等等。应用程序243包括控制汽车自动驾驶相关的程序,比如,管理自动驾驶的汽车和路上障碍物交互的程序,控制自动驾驶汽车路线或者速度的程序,控制自动驾驶汽车和路上其他自动驾驶汽车交互的程序。应用程序243也存在于软件部署服务器249的***上。在一个实施例中,在需要执行自动驾驶相关程序247时,计算机***201可以从软件部署服务器249下载应用程序。
例如,应用程序243还可以是自动驾驶汽车和路上车道线交互的程序,也就是说可以实时跟踪车道线的程序。
例如,应用程序243还可以是控制自动驾驶车辆进行自动泊车的程序。
示例性地,传感器253可以与计算机***201关联,传感器253可以用于探测计算机201周围的环境。
举例来说,传感器253可以探测路上的车道,比如可以探测到车道线,并能够在车辆移动(如正在行驶)过程中实时跟踪到车辆前方一定范围内的车道线变化。又例如,传感器253可以探测动物,汽车,障碍物和人行横道等,进一步传感器还可以探测上述动物,汽车,障碍物和人行横道等物体周围的环境,比如:动物周围的环境,例如,动物周围出现的其他动物,天气条件,周围环境的光亮度等。
可选地,如果计算机201位于自动驾驶的汽车上,传感器可以是摄像头,红外线感应器,化学检测器,麦克风等。
示例性地,在车道线跟踪的场景中,传感器253可以用于探测车辆前方的车道线,从而使得车辆能够感知在行进过程中车道的变化,以据此对车辆的行驶进行实时规划和调整。
示例性地,在自动泊车的场景中,传感器253可以用于探测车辆周围的库位和周边障碍物的尺寸或者位置,从而使得车辆能够感知库位和周边障碍物的距离,在泊车时进行碰撞检测,防止车辆与障碍物发生碰撞。
在一个示例中,图1所示的计算机***150还可以从其它计算机***接收信息或转移信息到其它计算机***。或者,从车辆100的传感***120收集的传感器数据可以被转移到另一个计算机对此数据进行处理,下面以图3为例进行介绍。
图3是本申请实施例的一种云侧指令自动驾驶车辆的应用示意图。如图3所示,来自计算机***312的数据可以经由网络被传送到云侧的服务器320用于进一步的处理。网络以及中间节点可以包括各种配置和协议,包括因特网、万维网、内联网、虚拟专用网络、广域网、局域网、使用一个或多个公司的专有通信协议的专用网络、以太网、WiFi和HTTP、以及前述的各种组合;这种通信可以由能够传送数据到其它计算机和从其它计算机传送数据的任何设备,诸如调制解调器和无线接口。
在一个示例中,服务器320可以包括具有多个计算机的服务器,例如负载均衡服务器群,为了从计算机***312接收、处理并传送数据的目的,其与网络的不同节点交换信息。该服务器可以被类似于计算机***312配置,具有处理器330、存储器340、指令350、和数据360。
示例性地,服务器320的数据360可以包括车辆周围道路情况的相关信息。例如,服务器320可以接收、检测、存储、更新、以及传送与车辆道路情况的相关信息。
例如,车辆周围道路情况的相关信息包括与车辆周围的其它车辆信息以及障碍物信息。
现有的一些车辆通信方式要么需要点对点的复杂连线且传输能力过于局限(例如CIP),要么需要涉及复杂的通信协议(例如SOME/IP),且均无法满足冗余通信的需求。也就是说,对于冗余通信,现有技术无法很好的实现报文同步,以及无法对冗余报文进行甄别。虽然可以采用现有的通信领域的基于时间同步的通信方式来实现实时传输,但这种方式过于复杂繁琐,且对于冗余报文的甄别依然难以适应车辆通信的特殊要求。
针对上述技术问题,本申请实施例提供一种车辆冗余通信的方案,既能够实现车辆的冗余数据的实时传输,又易于实现。主要通过设置多网口冗余通信装置,实现报文的冗余发送和接收,以及通过为报文设置唯一标识符和/或设置报文编号,实现报文的识别,从而保证了报文的同步发送和实现报文的甄别。本申请技术方案相比于基于时间同步的通信方式,不要求接收设备和发送设备的时间同步,同时避免了不同设备的时间精度不同和时间误差等导致的报文甄别错误,也就是说,对于车载设备的精度要求没有过于严格的要求,完全不需要对齐时间,所以适用于现有的车辆中的车载设备。
图4是本申请实施例的车辆通信装置的多数据传输通道冗余通信的示意图。如图4所示该车辆通信装置接入网络中通讯时,采用双路以太网接口收发数据,在链路上实现传输数据冗余。每一路以太网具有独立的介质访问控制(media access control,MAC)地址、端口物理层(physical layer,PHY)芯片以及独立的以太网接口(ethernet interface,ETH)。
该车辆通信装置与车载设备的微控制单元(microcontroller unit,MCU)连接,使得可以实现车载设备之间的通信。需要说明的是,可以是同一车辆的不同车载设备之间进行通信,也可以是不同车辆的车载设备之间进行通信。
可选地,车载设备可以理解为车载终端设备,在本申请实施例中主要是指具有通信功能的、可以完成一定功能的车载设备,例如,图1所示传感***120中的各个设备、控制***130中的各个子***以及各个子***中的设备、***设备140中的各个设备、计算机***150等等。但应理解,图1只是一种示例,车载设备还可以包括各类可以用于控制车辆的单元、***中的任意设备,例如,车辆接口控制单元(vehicle interface unit,VIU)、车辆识别单元(vehicle integration unit,VIU)、车辆动态控制(vehicle dynamics contral)设备、电子控制单元(electronic control unit,ECU)、电子转向控制***(electricalpower steering,EPS)、电子制动控制***(electronically controlled brake system,EBS)、制动防抱死控制***(antilock brake system,ABS)等等。
还需说明的是,车辆通信装置可以是独立于车载设备之外的装置,也可以是集成在车载设备内部(即是车载设备的一部分)的装置。例如车辆通信装置可以是图1所示无线通信***141中的装置,又例如,车辆通信装置可以是集成在上述任意一种车载设备之中。
如图4所示,车载设备的MCU可以依次通过车辆通信装置中的MAC0、PHY0以及网口0发送数据(报文),还可以依次通过网口0、PHY0以及MAC0接收数据(报文)。车载设备的MCU还以依次通过车辆通信装置中的MAC1、PHY1以及网口1发送数据(报文),还可以依次通过网口1、PHY1以及MAC1接收数据(报文)。
也就是说,图4所示的车辆通信装置包括两个数据传输通道,其中一个数据传输通道包括上述MAC0、PHY0以及网口0,另一个数据传输通道包括上述MAC1、PHY1以及网口1。
可选地,两路数据传输通道能够独立处理收发数据或合并处理收发数据。
可选地,可以给每帧报文定义帧标识(identity,ID),也就是说,每帧报文都具有唯一的帧ID,然后就可以利用图4所示两个数据传输通道将带有同一帧ID的报文发送到目标设备/装置(接收报文的设备/装置)。
可选地,还可以对发送的报文进行计数,也就是说,对每帧报文进行编号,或者可以理解为设置报文帧的时间顺序标识。
可选地,可以定义帧序列计数(sequence counter),将帧序列计数作为报文的顺序识别码。可以在发送报文的一端进行累加,每发送一帧报文,帧序列计数器累加1。
需要说明的是,在本申请实施例中,帧序列计数用于表示发送报文的先后顺序,可以理解为是发送报文的时间次序(顺序)。例如某个报文帧序列计数为5相当于该报文是第5次发送的,假设另外一个报文的帧序列计数为7相当于该报文是第7次发送的,还可以知道该报文是在帧序列计数为5的报文发送之后发送的,可以看作是,帧序列计数为7的报文的发送时间晚于帧序列计数为5的报文。应理解,上述只是为了说明帧序列计数的含义的一种示例,不存在限定。
可选地,在本申请实施例中,数据装载可以按照互联网协议(internet protocol,IP)首部、用户数据报协议(user datagram protocol,UDP)首部和协议数据单元(protocoldata unit,PDU)的顺序进行装载。PDU数据由协议栈或应用程序装载,主要负责帧序列计数和帧ID已经传输数据的装载。
可选地,当PDU报文准备好后,可以将其传递给发送层,然后通过两路数据通道同时发送出去。当PDU传递至UDP和IP层发送时,由协议栈装载IP首部和UDP首部。这样在报文发送至网络中,由IP首部和帧ID组成一个唯一标识的报文。
可选地,为了进行数据链路的隔离,可以将车辆通信装置的两个网口分配在不同的网段中。可选地,可以使得网口0与网口1的目的地址也处于不同的网段。
当报文经过交换机等网络设备投递到接收端。接收端就可以根据设定的端口对报文进行监听接收。
可选地,车载通信装置可以按照固定的周期发送报文。也就是说,在同一时刻会有两个报文被发送端的车辆通信装置由两个网口同时发送至网络中。该两帧报文装载有相同的PDU内容、帧序列计数和帧ID,且UDP首部相同。但是该两帧报文的IP首部不同。由于该两帧报文是由不同的网口发出的,所以被装载了不同源IP地址和MAC地址,由于设定的目的地址也不同,所以IP首部的目的IP地址和目的MAC地址也不相同。
当图4所示车辆通信装置进行报文接收的时候,或者可以理解为当图4所示车辆通信装置为接收端的车辆通信装置时,可以从网口0和网口1分别接收报文,并根据接收到的报文的帧ID和帧序列计数对报文进行选择,具体对于接收报文的处理过程会在图5中进行介绍。
图5是本申请实施例的接收冗余报文的处理流程示意图。下面对图5所示各个步骤进行介绍。
510、接收报文。
可选地,接收的报文可以包括校验字段和唯一标识符,其中,唯一标识符可以包括帧标识ID和IP地址。
可选地,可以从多个(例如两个)数据传输通道的网口接收报文(例如接收第一报文),多个数据传输通道的接收过程是相互独立的。
需要说明的是,每个数据传输通道均可以包括其各自的MAC、PHY和网口,当为两个数据传输通道时,可以采用于图4所示相同的数据传输通道的结构。
可以看出,步骤510对于接收的报文的数量不存在限定。
可选地,唯一标识符还可以包括帧序列计数,帧序列计数用于表示接收的报文(例如第一报文)在被发送时的发发送次序。
还需要说明的是,在本申请中,报文的发送次序可以理解为发送报文的先后顺序,并不是报文的实际发送时间。换而言之,在现有的通讯中是用时间戳作为报文的发送时间顺序的,这是实际发送时间的先后,而在本申请中只是报文发送次序的先后,并不对应实际时间,可以将其看作是对每个发送报文的排序。正是由于通过发送次序来区分报文的新鲜度,而不需要对应实际的时间,才使得本申请的方案不需要严格要求所有设备的时间同步。
520、检查报文,当检查结果为“通过”时,转为执行步骤540;当检查结果为“未通过”时,执行步骤530。
可选地,可以根据接收到的报文(例如第一报文)的校验字段,检查报文是否正确,当报文正确的时候对报文进行进一步处理,当报文存在错误的时候,可以将报文丢弃。也就是说,当报文正确的时候认为检查结果为“通过”,对报文进行进一步处理(例如转为执行步骤540);当报文错误的时候认为检查结果为“未通过”,将报文丢弃(执行步骤530)。这是因为,为了保证接收到的报文所承载的数据是正确的,往往会设置校验字段,该校验字段与承载的内容存在对应关系,因此,当接收到的报文存在错误时,根据承载的数据推算出的校验字段与发送报文时承载的校验字段就会不一致,就可以认为该报文存在错误,就可以将报文进行丢弃。
530、丢弃报文。
可选地,可以将接收的报文(例如第一报文)中没有通过校验(检查)的报文进行丢弃。
需要说明的是,步骤530可以不执行,也就是说,报文的丢弃,可以考虑也可以不考虑。
540、存储报文。
可选地,当接收到的报文通过检查后,可以将报文进行存储。结合图4所示场景举例说明如下。
例如可以将从网口0和网口1接收的第一报文传送至应用程序的两个独立的缓存区,应用程序会给每一个帧ID在对应的网口下分别创建一个独立的缓存空间。当接受到报文后,将这些报文根据帧ID投送到对应缓存区间储存。每一个帧ID只分配一个对应大小的缓存空间,在每个缓存空间接收的报文都会被覆盖存储。即当前最新接收到的报文会覆盖上一次存在该缓存区的报文。
550、读取报文。
可选地,当需要读取报文时,可以根据从报文的缓存区(存储区),读取相应帧ID的缓存区所存储的报文。
可选地,可以是在获取到读取请求的之后执行步骤550和步骤560。该读取请求可以包括待读取报文的帧ID。
可选地,在获取读取请求后,可以根据读取请求中指定的待读取报文的帧ID找到对应的缓存空间,然后从缓存空间中读取里面存储的报文。
可选地,可以读取出帧ID对应的缓存空间中的至少一个存储的报文,该至少一个存储的报文中包括上述第一报文。需要说明的是,在步骤510和步骤520的执行过程中,通过检查的第一报文会被存储,所以此处存储在每个帧ID的缓存空间中的报文就包括了上述通过检查的第一报文,因此也可以理解为,每个帧ID的缓存空间中存储有至少一个第一报文。但应理解,缓存空间中也可以没有报文,这种情况相当于会读取失败,或者是返回一个没有报文的指示。
560、选择报文,当报文未被选中时执行步骤530,当报文被选中时执行步骤510。
可选地,可以根据存储的报文的上述帧序列计数,从这至少一个存储的报文中选择出合适的报文作为第二报文,第二报文可以理解为响应读取请求所读取出来的报文,或者可以理解为返回给读取请求的发起者的报文。
也就是说,当应用程序通过接口函数读取指定帧ID报文时,程序在对应的帧ID缓存区获取来自不同网口的报文。并且按照设定的仲裁逻辑进行冗余报文仲裁,仲裁获胜的报文,通过接口函数返回给用户应用层。在报文读取时会保护该缓冲区,对缓冲区进行加锁互斥处理,当读取过程中有写入请求,则将该请求挂起,当数据拷贝完成立即释放,并写入新接收的报文。
可选地,可以根据报文的帧序列计数,选择较大帧序列计数的报文,例如可以选择缓存空间中帧序列计数的值最大的报文作为上述第二报文。
可选地,可以设置报文的帧序列计数的值可以取从0至最大值之间的值,当计数达到最大值时继续从0开始计数,因此,当同时存在最大值和0时,认为0是较大的计数。
需要说明的是,图5所示各个步骤并不需要完全执行,例如可以只执行步骤510至步骤540,也就是说,为每一帧报文设置独立的缓存空间,并将报文进行存储。而步骤550和步骤560是在需要进行报文读取的时候(接收到读取请求的时候)才会执行的。或者可以理解为,步骤550和步骤560是读取报文的过程,不是接收报文的过程,而步骤510至步骤540才是接收报文的过程。还可以理解为,步骤510至步骤540是每次需要接收报文的时候执行的,而步骤550和步骤560是每次需要读取报文的时候执行的。
可选地,还可以将至少一个第一报文中未被选中的报文丢弃。也就是说,在读取报文的时候,丢弃没有被选中的报文,这样可以释放缓存空间,降低存储开销。
可选地,为了使得接收报文和读取报文不会互相影响,可以在接收报文的过程中不响应读取请求,在读取报文的过程中暂停存储报文,可以理解为,可以使得步骤540和步骤550不同时执行。
从上文可知,多个数据传输通道的收发报文是相互独立的,下面结合图6,以两个数据传输通道为例进行介绍。
图6是本申请实施例的接收冗余报文的处理流程示意图。下面对图6所示各个步骤进行介绍。
需要说明的是,图5可以看作是对于处理流程的概括性描述,而图6则相当于当有两个网口分别接收报文的时候的处理流程,从图6中可以看出两路报文的处理过程是独立的,只有在根据帧序列选择报文的时候,两路可以共享帧序列,从而从接收的报文中选择报文。还应理解,由于两路数据通道对于报文的处理过程是独立的,所以不存在先后顺序的限制。
511、网口0接收报文。
可选地,可以采用步骤510所提供的方法执行步骤511。
512、网口1接收报文。
可选地,可以采用步骤510所提供的方法执行步骤512。
521、检查报文。
可选地,可以采用步骤520所提供的方法执行步骤521。
522、检查报文。
可选地,可以采用步骤520所提供的方法执行步骤522。
531、丢弃报文。
可选地,可以采用步骤530所提供的方法执行步骤531。
532、丢弃报文。
可选地,可以采用步骤530所提供的方法执行步骤532。
541、存储报文。
可选地,可以采用步骤540所提供的方法执行步骤541。
542、存储报文。
可选地,可以采用步骤540所提供的方法执行步骤542。
551、读取报文。
可选地,可以采用步骤550所提供的方法执行步骤551。
552、读取报文。
可选地,可以采用步骤550所提供的方法执行步骤552。
561、选择报文,并将未被选中的报文丢弃。
可选地,可以采用步骤560所提供的方法执行步骤561。
562、选择报文,并将未被选中的报文丢弃。
可选地,可以采用步骤560所提供的方法执行步骤562。
需要说明的是,两个数据传输通道在执行上述各个步骤是相互独立的,只有在选择报文时(即步骤561和步骤562)时可以共享帧序列计数。
图7是本申请实施例的发送冗余报文的处理流程示意图。下面对图7的各个步骤进行介绍。
701、将第一待发送报文进行数据装载,该第一待发送报文包括帧ID。
需要说明的是,上文所述第一报文(图5、图6所示)是指接收端的车辆通信装置所接收到的报文,而步骤701所述第一待发送报文是发送端的车辆通信装置在发送报文前生成的报文。
可选地,可以在第一待发送报文中装载待发送的数据,以及在其首部装载帧ID。
需要说明的是,对于具体将数据、帧ID、帧序列计数等装载在报文的哪个位置会在下文详细介绍,在此不再展开。
702、将第一待发送报文传递给多个数据传输通道,该多个数据传输通道的IP地址互不相同。
703、为第一待发送报文装载上述多个数据传输通道的IP地址,得到多个第二待发送报文。
可选地,当第一待发送报文传送到不同的数据传输通道后,可以分别把数据传输通道的IP地址装载进第一待发送报文,从而得到第二待发送报文。也就是说,第二待发送报文是在第一待发送报文的基础上装载了IP地址得到的。
需要说明的是,上文所述第二报文(图5、图6所示)是指接收端的车辆通信装置在读取报文时,从帧ID的缓存空间中读取到的报文,而步骤703所述第二待发送报文是发送端的车辆通信装置在发送报文前,在第一待发送报文的基础上经过进一步处理得到的报文。
可选地,还可以为第一待发送报文装载帧序列计数,使得第二待发送报文中包括帧序列计数。对于帧序列计数的含义、用途、设置方法等可以参照上文相关介绍,为了简洁,不再重复。还应理解,帧序列计数的装载可以在步骤701值步骤703之前、期间、之后的任意时刻,只要在执行步骤704之前执行即可,不存在其他限定。
704、在同一个发送周期内,发送多个第二待发送报文。
可选地,在发送第二待发送报文时,可以从多个数据传输通道的每个数据传输通道的网口发送第二待发送报文。
需要说明的是,在同一个发送周期内发送报文可以理解为同时发送报文。第二待发送报文中装载的数据、帧ID相同,但是IP地址不同。
图8是本申请实施例的一种报文帧的格式示意图。如图8所示,一帧报文的长度小于或等于1500字节。
可选地,报文帧可以包括:IP首部(header)、UDP首部、PDU首部、数字签名区(signature optional)首部、数据(data)区、安全数据传输协议区、密钥区。
标准的IP首部包括20个字节,标准的UDP首部包括8个字节,如图8中所示,IP首部和UDP首部共计28个字节。
PDU首部包括32个字节,在本申请是实施例中,在PDU首部加入了报文序列计数、帧ID两个量,对于其他PDU的组成部分可以采用与现有的PDU首部相同的设置,例如可以在PDU中设置数据类型、数据长度、帧校验序列等,具体的内容会在图13中进行介绍,在此不再展开。
可选地,帧ID是PDU用户数据结构的唯一标识符,在协议栈中具有唯一性。
可选地,帧ID可以与源IP一起构成PDU内唯一的标识符。
可选地,报文序列计数是对发送报文进行计数,将该报文序列计数从0开始计数,每发送一个PDU报文,该报文计数累加1,当计数到最大值时重新从0开始。
可选地,可以为每一个帧ID都设置一个独立的报文序列计数。
可选地,PDU报文首部包括校验字段,例如可以包括帧校验序列(frame checksequence,FCS)。
数字签名区包括首部和密钥区,其中,数字签名区的首部位于PDU首部之后,密钥区位于报文帧的结束端,首部和密钥区的字节长度均不是固定的,可以根据实际情况设置。
可选地,数字签名区可以用于传输加密的公钥。可以任意选取不同安全等级的加密算法对报文进行加密。例如RSA安全加密算法、HAL安全加密算法,以及可以自定义校验加密算法。
数据(data)区是指用于传输数据的区域。报文长度(数据的字节长度与上述各个部分的字节长度的总和)不超过网络传输的要求,例如可以设置为报文的字节长度小于或等于1500。
可选地,每一个报文的数据区可以根据实际使用的字节数自定义长度。报文长度装载在PDU首部的报文长度字段内。以便做接收确认。数据区根据传输数据类型需要可以自定义信号量的类型,例如按位偏移定义信号,或字节偏移定义不同的信号。
需要说明的是,数据区可以根据传输数据的需要,选择密文传输或明文传输。
安全数据传输协议(safe data transmit protocol)区用于储存安全传输的校验信息。安全传输数据区支持不同的安全数据传输协议,例如可以采用SDTV2协议。安全数据传输协议区可以包括16个字节。
需要说明的是,图8只是报文帧格式的一个示例,也可以采用其他的报文帧格式,例如可以采用图9或图10所示的报文帧的格式。
图9是本申请实施例的另一种报文帧的格式示意图。如图9所示,一帧报文的长度小于或等于1500字节。
可选地,图9所示报文帧可以包括:IP首部、UDP首部、PDU首部、数据区、安全数据传输协议区。图9可以看作是只对报文进行加密但不对安全传输进行校验的一种报文形式,或者可以理解为一种密文传输的方式。
图10是本申请实施例的又一种报文帧的格式示意图。如图10所示,一帧报文的长度小于或等于1500字节。
可选地,图10所示报文帧可以包括:IP首部、UDP首部、PDU首部、数字签名区首部、数据区、密钥区。
需要说明的是,图9和图10只是另外两种报文格式的示例,也可以存在其他情况,例如可以既没有安全数据传输协议,又没有数字签名认证要求。也就是说,报文还可以只包括:IP首部、UDP首部、PDU首部和数据区,数据区的数据长度可以为0-1440个字节。
图11是本申请实施例的车辆通信装置在同一网络的连接示意图。如图11所示,设备#1和设备#2均为车载设备,二者均包括车辆通信装置,但应理解,二者也可以是独立的车辆通信装置。二者之间通过多个交换机分两路连接。
可选地,设备#1和设备#2之间的第一路中包括N个交换机,N为正整数,设备#1和设备#2之间的第二路中包括M个交换机,M为正整数。为了对两路中的交换机进行区分,将第一路中的N个交换机从1至N进行编号,将第二路中的交换机从N+1到N+M进行编号。
需要说明的是,图11所示是在同一网络中,所以上述两路是指同一网络中的两路,并不是两个网络。最直观的区别在于,图11所示的两路的交换机之间是有连接的,例如交换机#1与交换机#N+1连接,这种方式能够防止交换机故障或链路故障导致的通讯丢失。
可选地,设备#1和设备#2分别具有两个网口,该两个网口的IP地址不同,且传输过程中是隔开的。
图12是本申请实施例的车辆通信装置在不同网络的连接示意图。如图12所示,设备#1、设备#2和设备#3均为车载设备,三者均包括车辆通信装置,但应理解,三者也可以是独立的车辆通信装置。设备#1、设备#2和设备#3分别接入到网络A和网络B两个网络中。
可选地,网络A中包括多个交换机,可以用交换机Ai进行编号,其中i为正整数。
可选地,网络B中包括多个交换机,可以用交换机Bj进行编号,其中j为正整数。
需要说明的是,图12所示是在不同网络中,所以上述网络A和网络B是不同的网络。最直观的区别在于,图12所示的网络A和网络B的交换机之间是隔离的,例如交换机A1与网络B中的任意交换机都没有连接。
还需要说明的是,图12只是一种示例,但是对于设备的数量、网络的数量、网络中交换机的数量等等均不存在限定。
在图12所示场景中,设备#1、设备#2和设备#3的一个网络口接入到网络A中,另一个网口接入到网络B中。设备#1、设备#2和设备#3可以同时将数据由两路网口按照本申请实施例所定义的报文格式将相同的报文发送至两个网络中。另一个设备的两个网口也接入到网络中,即可完成对报文的接收和仲裁。无论哪一网口的报文优先抵达均可以完成本周期的传输,充分利用了冗余网络中的数据链路特性,提高整个网络中数据的传输时效和可靠性。
下面对接收和发送报文的过程进行举例说明。
首先是对网络拓扑及数据流的设置。将车载设备的两个网口的IP分别分配在不同的网段内,并且将两个网口均接入交换机网络中(包括图11所示网络和图12所示网络)。
假设将设备#1的网口1的IP配置为10.0.0.10/21,将设备#1的网口0的IP配置为10.0.8.10/21,将设备#2的网口1的IP配置为10.0.0.20/21,将设备#2的网口0的IP配置为10.0.8.20/21。
当车载设备发送报文时,车载设备可以在同一个通讯周期内同时从网口1和网口0发送相同的PDU报文。该PDU报文的帧ID与帧序列计数相同。该PDU报文的UDP首部由***装载记录源端口与目的端口及报文长度。通过实现方式的不同源端口可能不同,但是目的端口值相同。数据长度亦相同。该PDU报文从网口1和网口0发出去之前IP首部由该网口的协议栈按照该网口的IP信息进行装载,因此两个网口发送出去的PDU报文的IP首部内容不同。
当车载设备从网口1和网口0接收到报文时,网口1和网口0所在的数据传输通道可以独立对于接收的报文进行处理,例如,可以独立地检查报文,以及根据检查结果决定丢弃报文或存储报文。
图13是本申请实施例的PDU报文格式的示意图。如图13所示,PDU报文帧包括:帧首部和数据区,其中帧首部包括32个字节,数据区可以包括小于或等于1440个字节的数据。
帧首部包括帧序列计数(sequence counter)、帧ID、协议版本(protocolversion)、数据类型(data type)、数据长度(data length)、保留字段(reserve)、保留字段01、保留字段02、保留字段03、数据区(data)、帧校验序列。
帧序列计数是由发送端的车辆通信装置来进行计数和更新的,接收端的车辆通信设备则主要可以利用帧序列计数来读取报文。
帧序列计数从0开始累加,发送端的车辆通信装置每发送一帧报文,帧序列计数累加1,当达到最大值后归零(即当大于或等于预设阈值时归零),重新从零开始计数。
可选地,预设阈值(最大值)可以设置为0xFFFF FFFF。
需要说明的是,在本申请实施例中,主要利用帧序列计数来辅助读取报文,使得可以选择更新(时间较晚)的报文,该报文选择规则非常适用于车辆通信的这一特殊应用场景,而这种方法在常见的通信(例如手机等终端之间的通信)并不适用,因为常见的通信场景涉及的数据量非常庞大,如果采用计数的方式很容易出现,帧序列已经达到最大值,却还有数据没有办法存储的情况,导致数据丢失等等问题。且本申请中需要为每个帧ID配置独立的缓存空间,这也是常见的通信场景无法满足的。正因为上述原因,在常见的通信场景中目前均采用时间同步的方式,而无法采用计数的方式。如果将基于时间同步的通信方式应用到车领域通信,则相比于本申请的方案会非常繁琐,没有本申请的方案简洁和易于实现。
可选地,接收端的车辆通信装置可以根据帧序列计数对报文新鲜度进行仲裁,帧序列计数值越大数据越新鲜。当接收端的车辆通信装置的两个独立网口接收到的数据帧序列计数不一致时,选取帧序列计数值较大的报文进行解析,而帧序列计数值较小的报文则可以丢弃。假设两个网口帧序列计数值相同,则可以设置为选取指定默认网口的报文进行解析。例如可以指定在数值相同的时候选择网口0的报文,或者可以指定在数值相同的时候选择网口1的报文,或者可以指定在数值相同的时候选择网口0和网口1中较早到达的网口的报文,或者可以指定在数值相同的时候选择网口0和网口1中较晚到达的网口的报文,等等,不再一一列举。
可选地,可以设置报文的唯一标识符包括报文的帧ID和源IP。从上文可以看出,每帧报文的帧ID与帧序列计数是相同的。但是每帧报文从多个数据传输通道的网口发送出去之前,会装载MAC地址和IP地址,所以从多个网口发出去的报文的MAC地址和IP地址是不同的,因此报文的帧ID和IP地址可以构成报文的唯一标识符。且帧序列计数也可以作为唯一标识符的组成部分。
协议版本主要用于定义PDU版本信息,以确定其兼容性。
数据类型是指PDU通讯数据类型,通常定义为过程数据和消息数据。
数据长度可以理解为数据帧长度,是指实际PDU报文的数据场长度,不包含20字节的报文头。
帧校验序列是指用于校验PDU首部的协议序列。可选地,可以采用通用FCS进行循环冗余校验(cyclic redundancy check,CRC)校验。
数据区的数据大小可以为0~1440字节,也就是说,数据大小只要不超过PDU报文总的字节长度限制即可,且需要将报文总字节长度的限制扣除报文首部的长度。可选地,信号表映射可以由附录中子协议定义。
可选地,如果使用安全数据传输协议和安全加密,则数据区可以包括上述安全传输校验区、数字签名区和密钥区。
图14是本申请实施例的冗余报文的发送流程示意图。下面对图14各个步骤进行介绍。
1401、发布报文。
可以理解为,当需要发送报文的时候,将报文发布出来。当车载设备的车辆通信装置需要发送指定的PDU报文时,PDU的数据区在应用程序中装载。以PDU 101为例,对PDU 101而言,数据来自车载设备的MCU。当将这些数据装载在数据区后,就可以将报文分别传递到不同的数据传输通道,由数据传输通道执执行后续的装载帧ID、装载帧序列计数、发送报文等操作。
可选地,当数据区装载好后,可以继续装载报文的帧首部的信息,以及可以根据当前帧首部信息,计算FCS,从而完成数据装载,之后可以把打包好的报文传送至不同网络传输通道的协议栈。在协议栈中加入各自网口的IP首部及MAC地址信息。
可选地,可以利用定时器进行出发报文的发发送,等待定时器的触发,当定时器触发后,报文从不同数据传输通道的不同网口同时发送出去,并且帧序列计数值累加1。无论发送失败与否,帧序列计数都在发送行为执行后累加,不受发送成功与否的影响。也就是说,步骤1411和步骤1421的循环计数操作是再每次发送行为执行之后进行操作的。
1411、网口0循环计数。
可选地,网口0可以利用计数器对发送报文的次数进行循环计数。
1421、网口1循环计数。
可选地,网口0可以利用计数器对发送报文的次数进行循环计数。
需要说明的是,步骤1411-1415是网口0所在的数据传输通道执行的操作,步骤1421-1424是网口1所在的数据传输通道执行的操作,两个数据传输通道的操作是互相独立的。
当帧序列计数的值达到最大值时(大于或等于最大值时),执行步骤1412或步骤1421,将计数器清零(即将帧序列计数的值归零),无论发送失败与否,均执行步骤1413或步骤1423,对PDU报文进行更新。
帧序列计数的值由发送计数器产生,在上电期间是持续不断累加的状态。
可选地,为了以避免在网络中产生发送报文的仲裁冲突,可以设置为该帧序列计数是不支持外部软件修改的。上电时,发送计数器置0,即帧序列计数的初始值为0,之后每发送一次报文,计数器加1,帧序列计数的值累加1,直到帧序列计数的值累加到大于或等于预设阈值的时候,计数器清零,帧序列计数的值归零,重新从0开始计数。
可选地,可以根据安全数据传输协议的算法,在本地通过SID计算出数据传输字段后,将其装载在数据区。
数字签名区装载以上字段完成后,完成报文数据区加密,并传输至发送层。由协议栈发送区进行发送。
当报文全部装在好后,执行步骤1415和步骤1422,分别从网口0和网口1将报文发送出去。如果发送失败的时间间隔或次数超过预设值可以执行步骤1403,取消发布报文。
需要说明的时,PDU ID、帧序列计数、IP和MAC构成了这帧报文在网络中的位移标识符。在同一个发送周期内,PDU ID与帧序列计数相同的报文有两帧。在同一个发送周期内,两个PDU ID相同的报文,IP首部与MAC地址均不相同,因此两个相同的报文的标识符具有唯一性。
应理解,图14是发送冗余报文的流程的一个示例,具体过程可以参照图7的相关介绍,因此为了简洁,不再赘述。
图15是本申请实施例的冗余报文的接收流程示意图。下面对图15各个步骤进行介绍。
1501、PDU订阅。
需要说明的是,PDU订阅可以理解为接收报文的触发条件之一,也可以理解为启动接收报文流程的信息。
1502、模式选择,当选择RT模式时执行步骤1504,当选择SDT或安全模式时,执行步骤1503。
需要说明的是,RT模式可以理解为上文所述明文传输,也就是说,报文没有被加密,此时不需要执行解密的操作。SDT和安全模式可以理解为上文所述密文传输,也就是说,报文是被加密的,此时需要先对报文进行解密。
1503、对报文进行解密。
需要说明的是,只有经过加密的报文才需要执行该步骤1503。
1504、对接收的报文进行解析。
可以理解为将接收到的报文中的内容读取出来,以便于利用接收到的报文的校验字段检查报文是否存在错误。
1505、检查报文。
可选地,可以利用图5中步骤520所提供的方法执行该步骤1505。
1506、读取和选择报文。
可选地,可以利用图5中步骤550和步骤560的方法执行该步骤1506。
应理解,图15是接收冗余报文和读入报文的流程的一个示例,具体过程可以参照图5或图6的相关介绍,因此为了简洁,不再赘述。
上文对本申请实施例的车辆通信方法进行了介绍,下面对本申请实施例的车辆通信装置进行介绍。应理解,下文中介绍的车辆通信装置能够执行本申请实施例的车辆通信方法的各个过程,下面在介绍装置的实施例时,会适当省略重复的描述。
图16是本申请实施例的一种车辆通信装置的示意图,该装置2000包括接收单元2001和处理单元2002。该装置2000可以用于执行本申请实施例的车辆通信方法中接收端的车辆通信装置执行的各步骤。
例如,接收单元2001可以用于执行图5所示方法中的步骤510、步骤550,处理单元2002可以用于执行图5所示方法中的步骤520至步骤540、步骤560。又例如,接收单元2001可以用于执行图6所示方法中的步骤511、512和步骤551、552,处理单元2002可以用于执行图6所示方法中的步骤521、522、531、532、541、542和步骤561、562。又例如,接收单元2001可以用于执行图15所示方法中的步骤1501,处理单元2002可以用于执行图15所示方法中的步骤1502至步骤1506。
上述装置2000可以为图4所示车辆通信装置。
图17是本申请实施例的一种车辆通信装置的硬件结构示意图。该装置3000包括存储器3001、处理器3002、通信接口3003以及总线3004。其中,存储器3001、处理器3002、通信接口3003通过总线3004实现彼此之间的通信连接。
装置3000可以用于执行上文车辆通信方法中接收端的车辆通信装置执行的各个步骤。
可选地,存储器3001可以是只读存储器(read only memory,ROM),静态存储设备,动态存储设备或者随机存取存储器(random access memory,RAM)。存储器3001可以存储程序,当存储器3001中存储的程序被处理器3002执行时,处理器3002和通信接口3003用于执行本申请实施例的车辆通信方法的各个步骤。
可选地,存储器3001可以具有图1所示存储器152的功能或者具有图2所示***内存235的功能,或者具有图4所示存储器340的功能,以实现上述存储程序的功能。可选地,处理器3002可以采用通用的CPU,微处理器,ASIC,图形处理器(graphic processing unit,GPU)或者一个或多个集成电路,用于执行相关程序,以实现本申请实施例的车辆通信装置中的单元所需执行的功能,或者执行本申请实施例的车辆通信方法的各个步骤。
可选地,处理器3002可以具有图1所示处理器151的功能或者具有图2所示处理器203的功能,或者具有图3所示处理器330的功能,以实现上述执行相关程序的功能。
可选地,处理器3002还可以是一种集成电路芯片,具有信号的处理能力。在实现过程中,本申请实施例的车辆通信方法的各个步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。
可选地,上述处理器3002还可以是通用处理器、数字信号处理器(digital signalprocessing,DSP)、专用集成电路(ASIC)、现成可编程门阵列(field programmable gatearray,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成本申请实施例的车辆通信装置中包括的单元所需执行的功能,或者执行本申请实施例的车辆通信方法的各个步骤。
可选地,通信接口3003可以使用例如但不限于收发器一类的收发装置,来实现装置与其他设备或通信网络之间的通信。
总线3004可包括在装置各个部件(例如,存储器、处理器、通信接口)之间传送信息的通路。
图18是本申请实施例的一种车辆通信装置的示意图,该装置4000包括发送单元4001和处理单元4002。该装置4000可以用于执行本申请实施例的车辆通信方法中发送端的车辆通信装置执行的各步骤。
例如,发送单元4001可以用于执行图7所示方法中的步骤704,处理单元4002可以用于执行图7所示方法中的步骤701至步骤703。又例如,发送单元4001可以用于执行图14所示方法中的步骤1414和步骤1424,处理单元4002可以用于执行图14所示方法中的其他步骤。
上述装置4000可以为图4所示车辆通信装置。
图19是本申请实施例的一种车辆通信装置的硬件结构示意图。该装置5000包括存储器5001、处理器5002、通信接口5003以及总线5004。其中,存储器5001、处理器5002、通信接口5003通过总线5004实现彼此之间的通信连接。
装置5000可以用于执行上文车辆通信方法中发送端的车辆通信装置执行的各个步骤。
可选地,存储器5001可以是ROM,静态存储设备,动态存储设备或者RAM。存储器5001可以存储程序,当存储器5001中存储的程序被处理器5002执行时,处理器5002和通信接口5003用于执行本申请实施例的车辆通信方法的各个步骤。
可选地,存储器5001可以具有图1所示存储器152的功能或者具有图2所示***内存235的功能,或者具有图4所示存储器340的功能,以实现上述存储程序的功能。可选地,处理器5002可以采用通用的CPU,微处理器,ASIC,GPU或者一个或多个集成电路,用于执行相关程序,以实现本申请实施例的车辆通信装置中的单元所需执行的功能,或者执行本申请实施例的车辆通信方法的各个步骤。
可选地,处理器5002可以具有图1所示处理器151的功能或者具有图2所示处理器203的功能,或者具有图3所示处理器330的功能,以实现上述执行相关程序的功能。
可选地,处理器5002还可以是一种集成电路芯片,具有信号的处理能力。在实现过程中,本申请实施例的车辆通信方法的各个步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。
可选地,上述处理器5002还可以是通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成本申请实施例的车辆通信装置中包括的单元所需执行的功能,或者执行本申请实施例的车辆通信方法的各个步骤。
可选地,通信接口5003可以使用例如但不限于收发器一类的收发装置,来实现装置与其他设备或通信网络之间的通信。
总线5004可包括在装置各个部件(例如,存储器、处理器、通信接口)之间传送信息的通路。
本申请实施例还提供一种包含指令的计算机程序产品,该指令被计算机执行时使得该计算机实现上述方法实施例中的方法。
上述提供的任一种车辆通信装置中相关内容的解释及有益效果均可参考上文提供的对应的方法实施例,此处不再赘述。
除非另有定义,本申请所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本申请中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的,不是旨在于限制本申请。
本申请实施例并未对本申请实施例提供的方法的执行主体的具体结构进行特别限定,只要能够通过运行记录有本申请实施例提供的方法的代码的程序,以根据本申请实施例提供的方法进行通信即可。
本申请的各个方面或特征可以实现成方法、装置或使用标准编程和/或工程技术的制品。本申请中使用的术语“制品”可以涵盖可从任何计算机可读器件、载体或介质访问的计算机程序。例如,计算机可读介质可以包括但不限于:磁存储器件(例如,硬盘、软盘或磁带等),光盘(例如,压缩盘(compact disc,CD)、数字通用盘(digital versatile disc,DVD)等),智能卡和闪存器件(例如,可擦写可编程只读存储器(erasable programmableread-only memory,EPROM)、卡、棒或钥匙驱动器等)。
本申请描述的各种存储介质可代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于:无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。
需要说明的是,当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时,存储器(存储模块)可以集成在处理器中。
还需要说明的是,本申请描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本领域普通技术人员可以意识到,结合本申请中所公开的实施例描述的各示例的单元及步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的保护范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。此外,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上,或者说对现有技术做出贡献的部分,或者该技术方案的部分,可以以计算机软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,该计算机软件产品包括若干指令,该指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。前述的存储介质可以包括但不限于:U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。
Claims (32)
1.一种车辆通信的方法,其特征在于,包括:
接收第一报文,所述第一报文包括校验字段和唯一标识符,所述唯一标识符包括帧标识ID和互联网协议IP地址;
根据所述第一报文的校验字段,对所述第一报文进行检查;
若所述第一报文通过检查,根据所述帧ID,将所述第一报文存储到所述帧ID所对应的缓存空间。
2.如权利要求1所述的方法,其特征在于,若所述第一报文没有通过检查,将所述第一报文丢弃。
3.如权利要求1或2所述的方法,其特征在于,所述唯一标识符还包括帧序列计数,所述方法还包括:
获取读取请求,所述读取请求包括待读取报文的帧ID;
从所述待读取报文的帧ID所对应的缓存空间中读取至少一个第一报文,所述至少一个第一报文的帧序列计数的值用于表示所述至少一个第一报文的被发送次序;
从所述至少一个第一报文中选中所述帧序列计数的值最大的报文为第二报文且返回所述第二报文。
4.如权利要求3所述的方法,其特征在于,所述方法还包括:
将所述至少一个第一报文中未被选中的第一报文丢弃。
5.如权利要求1至4中任意一项所述的方法,其特征在于,所述第一报文包括:IP首部、用户数据报协议UDP首部、协议数据单元PDU首部和数据区,所述唯一标识符的所述IP地址是被装载在所述IP首部中的,所述唯一标识符的其他元素是被装载在所述PDU首部中的。
6.如权利要求5所述的方法,其特征在于,所述第一报文还包括:安全数据传输协议区。
7.如权利要求5或6所述的方法,其特征在于,所述第一报文还包括:数字签名区首部和密钥区。
8.一种车辆通信的方法,其特征在于,包括:
将第一待发送报文进行数据装载,所述第一待发送报文包括帧标识ID;
将所述第一待发送报文传递给多个数据传输通道,所述多个数据传输通道的互联网协议IP地址互不相同;
为所述第一待发送报文装载所述多个数据传输通道的IP地址,得到多个第二待发送报文;
在同一发送周期内,发送所述多个第二待发送报文。
9.如权利要求8所述的方法,其特征在于,所述方法还包括:
为所述多个第二待发送报文装载帧序列计数,所述帧序列计数用于表示所述第二待发送报文的发送次序。
10.如权利要求9所述的方法,其特征在于,所述帧序列计数初始值为0,且所述帧序列计数小于或等于预设阈值,所述方法还包括:
每发送一次所述第二待发送报文,所述帧序列计数的值累加1,且当所述帧序列计数的值累加到大于或等于所述预设阈值时,将所述帧序列计数的值归零。
11.如权利要求8至10中任一项所述的方法,其特征在于,所述第一待发送报文和所述第二待发送报文均包括:IP首部、用户数据报协议UDP首部、协议数据单元PDU首部和数据区,所述帧ID被装载在所述第一待发送报文的PDU首部和所述第二待发送报文的PDU首部中,所述IP地址被装载在所述第二待发送报文的IP首部中。
12.如权利要求11所述的方法,其特征在于,所述帧序列计数被装载在所述第二待发送报文的PDU首部中。
13.如权利要求11或12所述的方法,其特征在于,所述第二待发送报文还包括:安全数据传输协议区。
14.如权利要求11至13中任一项所述的方法,其特征在于,所述第二待发送报文还包括:数字签名区首部和密钥区。
15.一种车辆通信的装置,其特征在于,包括:
接收单元,用于接收第一报文,所述第一报文包括校验字段和唯一标识符,所述唯一标识符包括帧标识ID和互联网协议IP地址;
处理单元,用于根据所述第一报文的校验字段,对所述第一报文进行检查;
若所述第一报文通过检查,所述处理单元还用于,根据所述帧ID,将所述第一报文存储到所述帧ID所对应的缓存空间。
16.如权利要求15所述的装置,其特征在于,若所述第一报文没有通过检查,所述处理单元还用于,将所述第一报文丢弃。
17.如权利要求15或16所述的装置,其特征在于,所述唯一标识符还包括帧序列计数,所述接收单元还用于,获取读取请求,所述读取请求包括待读取报文的帧ID;
所述处理单元还用于,从所述待读取报文的帧ID所对应的缓存空间中读取至少一个第一报文,所述至少一个第一报文的帧序列计数的值用于表示所述至少一个第一报文的被发送次序;
所述处理单元还用于,从所述至少一个第一报文中选中对应的所述帧序列计数的值最大的报文为第二报文且返回所述第二报文。
18.如权利要求17所述的装置,其特征在于,所述处理单元还用于,将所述至少一个第一报文中未被选中的第一报文丢弃。
19.如权利要求15至18中任意一项所述的装置,其特征在于,所述第一报文包括:IP首部、用户数据报协议UDP首部、协议数据单元PDU首部和数据区,所述唯一标识符的所述IP地址是被装载在所述IP首部中的,所述唯一标识符的其他元素是被装载在所述PDU首部中的。
20.如权利要求19所述的装置,其特征在于,所述第一报文还包括:安全数据传输协议区。
21.如权利要求19或20所述的装置,其特征在于,所述第一报文还包括:数字签名区首部和密钥区。
22.一种车辆通信的装置,其特征在于,包括:
处理单元,用于将第一待发送报文进行数据装载,所述第一待发送报文包括帧标识ID;
所述处理单元还用于,将所述第一待发送报文传递给多个数据传输通道,所述多个数据传输通道的互联网协议IP地址互不相同;
所述处理单元还用于,为所述第一待发送报文装载所述多个数据传输通道的IP地址,得到多个第二待发送报文;
发送单元,用于在同一发送周期内,发送所述多个第二待发送报文。
23.如权利要求22所述的装置,其特征在于,所述处理单元还用于,为所述多个第二待发送报文装载帧序列计数,所述帧序列计数用于表示所述第二待发送报文的被发送次序。
24.如权利要求23所述的装置,其特征在于,所述帧序列计数初始值为0,且所述帧序列计数小于或等于预设阈值,所述处理单元还用于:
每当所述发送单元发送一次所述第二待发送报文,所述处理单元将所述帧序列计数的值累加1,且当所述帧序列计数的值累加到大于或等于所述预设阈值时,所述处理单元将所述帧序列计数的值归零。
25.如权利要求22至24中任一项所述的装置,其特征在于,所述第一待发送报文和所述第二待发送报文均包括:IP首部、用户数据报协议UDP首部、协议数据单元PDU首部和数据区,所述帧ID被装载在所述第一待发送报文的PDU首部和所述第二待发送报文的PDU首部中,所述IP地址被装载在所述第二待发送报文的IP首部中。
26.如权利要求25所述的装置,其特征在于,所述帧序列计数被装载在所述第二待发送报文的PDU首部中。
27.如权利要求25或26所述的装置,其特征在于,所述第二待发送报文还包括:安全数据传输协议区。
28.如权利要求25至27中任一项所述的装置,其特征在于,所述第二待发送报文还包括:数字签名区首部和密钥区。
29.一种车辆通信的装置,其特征在于,包括:
处理器,用于执行存储器中存储的计算机指令,以使得所述装置执行:如权利要求1至7中任一项所述的方法。
30.一种车辆通信的装置,其特征在于,包括:
处理器,用于执行存储器中存储的计算机指令,以使得所述装置执行:如权利要求8至14中任一项所述的方法。
31.一种计算机存储介质,其特征在于,其上存储有计算机程序,所述计算机程序被计算机执行时,以使得实现如权利要求1至7中任一项所述的方法。
32.一种计算机存储介质,其特征在于,其上存储有计算机程序,所述计算机程序被计算机执行时,以使得实现如权利要求8至14中任一项所述的方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2020/116393 WO2022056894A1 (zh) | 2020-09-21 | 2020-09-21 | 车辆通信方法和通信装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN112585931A true CN112585931A (zh) | 2021-03-30 |
Family
ID=75145417
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202080004605.1A Pending CN112585931A (zh) | 2020-09-21 | 2020-09-21 | 车辆通信方法和通信装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN112585931A (zh) |
WO (1) | WO2022056894A1 (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113840001A (zh) * | 2021-09-23 | 2021-12-24 | 中车株洲电力机车有限公司 | Mvb网络下的故障数据处理方法、通信***及轨道交通车辆 |
CN114205398A (zh) * | 2021-12-10 | 2022-03-18 | 奇瑞汽车股份有限公司 | 车辆通信方法及*** |
CN114338847A (zh) * | 2021-11-26 | 2022-04-12 | 国网北京市电力公司 | 数据处理方法、装置、电子设备及计算机可读存储介质 |
CN115037683A (zh) * | 2022-05-11 | 2022-09-09 | 小马易行科技(上海)有限公司 | 一种ecu信息传输方法、***、计算机设备和存储介质 |
CN115694747A (zh) * | 2022-09-29 | 2023-02-03 | 成都赛力斯科技有限公司 | 一种数据冗余保护方法、装置、计算机设备和存储介质 |
CN116155863A (zh) * | 2023-04-14 | 2023-05-23 | 小米汽车科技有限公司 | 车辆以太网地址分配方法、装置、车辆、介质及芯片 |
CN116959289A (zh) * | 2023-09-21 | 2023-10-27 | 山东通维信息工程有限公司 | 一种基于车路协同技术的智慧停车***及方法 |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114900515B (zh) * | 2022-03-25 | 2024-04-02 | 中国铁道科学研究院集团有限公司电子计算技术研究所 | 一种列车文件回传方法、列车主机、站点及控制中心 |
CN114745339B (zh) * | 2022-04-07 | 2023-10-20 | 潍柴动力股份有限公司 | 多包报文数据的传输方法、传输装置和传输*** |
CN115442173B (zh) * | 2022-06-07 | 2024-02-06 | 北京车和家信息技术有限公司 | 车辆报文转发、处理方法、装置、电子设备及存储介质 |
CN115208712B (zh) * | 2022-06-13 | 2024-06-21 | 深圳市科陆电子科技股份有限公司 | 一种控制方法、电池堆管理***、设备及介质 |
CN115022418A (zh) * | 2022-07-12 | 2022-09-06 | 南京懂玫驱动技术有限公司 | 电助力自行车的数据交互方法、装置、***及存储介质 |
CN114968827B (zh) * | 2022-08-01 | 2023-06-02 | 江铃汽车股份有限公司 | 车辆总线信号信息校验方法及*** |
CN115955356A (zh) * | 2023-01-03 | 2023-04-11 | 重庆长安汽车股份有限公司 | 一种域间安全通信方法、***、设备和介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106911436A (zh) * | 2015-12-23 | 2017-06-30 | 南京南瑞继保电气有限公司 | 一种并行双网冗余的实现方法 |
CN109728985A (zh) * | 2017-10-30 | 2019-05-07 | 北京精密机电控制设备研究所 | 一种基于rs422和can总线异构的实时冗余通信*** |
CN110808816A (zh) * | 2019-11-05 | 2020-02-18 | 中国铁道科学研究院集团有限公司通信信号研究所 | 一种铁路车地冗余无线数据通信方法 |
CN111263333A (zh) * | 2018-11-30 | 2020-06-09 | 北京图森智途科技有限公司 | 一种协同自动驾驶车队的冗余通信方法、装置及*** |
CN111416690A (zh) * | 2019-01-07 | 2020-07-14 | 株洲中车时代电气股份有限公司 | 基于以太网的列车冗余网络通信***及方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5448564A (en) * | 1994-01-31 | 1995-09-05 | Advanced Micro Devices, Inc. | Modular architecture for fast-packet network |
CN107395396A (zh) * | 2017-06-22 | 2017-11-24 | 中国科学院西安光学精密机械研究所 | 基于fpga的冗余双网口可配置以太网ip核 |
CN109412968B (zh) * | 2018-10-08 | 2023-04-07 | 西安微电子技术研究所 | 一种时间触发以太网端节点的冗余通信接收管理***及方法 |
-
2020
- 2020-09-21 WO PCT/CN2020/116393 patent/WO2022056894A1/zh active Application Filing
- 2020-09-21 CN CN202080004605.1A patent/CN112585931A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106911436A (zh) * | 2015-12-23 | 2017-06-30 | 南京南瑞继保电气有限公司 | 一种并行双网冗余的实现方法 |
CN109728985A (zh) * | 2017-10-30 | 2019-05-07 | 北京精密机电控制设备研究所 | 一种基于rs422和can总线异构的实时冗余通信*** |
CN111263333A (zh) * | 2018-11-30 | 2020-06-09 | 北京图森智途科技有限公司 | 一种协同自动驾驶车队的冗余通信方法、装置及*** |
CN111416690A (zh) * | 2019-01-07 | 2020-07-14 | 株洲中车时代电气股份有限公司 | 基于以太网的列车冗余网络通信***及方法 |
CN110808816A (zh) * | 2019-11-05 | 2020-02-18 | 中国铁道科学研究院集团有限公司通信信号研究所 | 一种铁路车地冗余无线数据通信方法 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113840001A (zh) * | 2021-09-23 | 2021-12-24 | 中车株洲电力机车有限公司 | Mvb网络下的故障数据处理方法、通信***及轨道交通车辆 |
CN114338847A (zh) * | 2021-11-26 | 2022-04-12 | 国网北京市电力公司 | 数据处理方法、装置、电子设备及计算机可读存储介质 |
CN114205398A (zh) * | 2021-12-10 | 2022-03-18 | 奇瑞汽车股份有限公司 | 车辆通信方法及*** |
CN114205398B (zh) * | 2021-12-10 | 2023-08-22 | 奇瑞汽车股份有限公司 | 车辆通信方法及*** |
CN115037683A (zh) * | 2022-05-11 | 2022-09-09 | 小马易行科技(上海)有限公司 | 一种ecu信息传输方法、***、计算机设备和存储介质 |
CN115694747A (zh) * | 2022-09-29 | 2023-02-03 | 成都赛力斯科技有限公司 | 一种数据冗余保护方法、装置、计算机设备和存储介质 |
CN116155863A (zh) * | 2023-04-14 | 2023-05-23 | 小米汽车科技有限公司 | 车辆以太网地址分配方法、装置、车辆、介质及芯片 |
CN116155863B (zh) * | 2023-04-14 | 2023-07-04 | 小米汽车科技有限公司 | 车辆以太网地址分配方法、装置、车辆、介质及芯片 |
CN116959289A (zh) * | 2023-09-21 | 2023-10-27 | 山东通维信息工程有限公司 | 一种基于车路协同技术的智慧停车***及方法 |
CN116959289B (zh) * | 2023-09-21 | 2024-03-22 | 山东通维信息工程有限公司 | 一种基于车路协同技术的智慧停车***及方法 |
Also Published As
Publication number | Publication date |
---|---|
WO2022056894A1 (zh) | 2022-03-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112585931A (zh) | 车辆通信方法和通信装置 | |
CN209842367U (zh) | 一种基于自动驾驶***的网络架构的集散式域控制器*** | |
EP4030751A1 (en) | Method, device, and system for video stitching | |
WO2023019761A1 (zh) | 一种面向混合交通流的路网运行状态检测***及方法 | |
CN112638738B (zh) | 车辆测速装置的故障诊断方法和故障诊断装置 | |
WO2022041122A1 (zh) | 一种数据传输方法以及装置 | |
US10339807B2 (en) | Apparatus using sync and balanced V2V communication | |
CN107547578A (zh) | 数据的推送方法、装置和设备 | |
CN113859265B (zh) | 一种驾驶过程中的提醒方法及设备 | |
JP2019106674A (ja) | 自動運転制御システム、自動運転制御方法、及び車両 | |
CN112534483A (zh) | 预测车辆驶出口的方法和装置 | |
CN115878343A (zh) | 一种进程间通信方法及相关装置 | |
WO2022134965A1 (zh) | 一种算力资源的配置方法及设备 | |
CN114179822A (zh) | 用于控制配备有自动化驾驶功能的车辆的操作的方法、计算机程序和设备 | |
CN112238862A (zh) | 用于自主驾驶平台的开放和安全监视*** | |
CN114056347A (zh) | 车辆运动状态识别方法及装置 | |
CN112585045A (zh) | 电子机械制动方法和电子机械制动装置 | |
CN117917881A (zh) | 一种流量调度方法、装置及车辆 | |
CN115039095A (zh) | 目标跟踪方法以及目标跟踪装置 | |
CN115297461B (zh) | 数据交互方法、装置、车辆、可读存储介质及芯片 | |
CN114782638B (zh) | 生成车道线的方法、装置、车辆、存储介质及芯片 | |
EP4394325A1 (en) | Navigation method and related apparatus | |
RU2736572C2 (ru) | Способ передачи данных между бортовым устройством, выполненным с возможностью получения данных, касающихся параметров движения и/или управления транспортного средства, и удаленным центром обработки | |
US11539621B2 (en) | Controller area network messages in an autonomous vehicle | |
CN114764980A (zh) | 一种车辆转弯路线规划方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210330 |
|
RJ01 | Rejection of invention patent application after publication |