当前位置: 首页> 专利交易> 详情页
    待售中

    车载设备通信方法、装置、系统和车辆[ZH]

    专利编号: ZL202505080185

    收藏

    拟转化方式: 转让;普通许可;独占许可;排他许可;作价投资;质押融资;其他(其他)

    交易价格:面议

    专利类型:发明专利

    法律状态:授权

    技术领域:智能网联汽车

    发布日期:2025-05-08

    发布有效期: 2025-05-08 至 2041-12-29

    专利顾问 — 伍先生

    微信咨询

    扫码微信咨询

    电话咨询

    咨询电话

    18273488208

    专利基本信息
    >
    申请号 CN202111632778.0 公开号 CN114363370A
    申请日 2021-12-29 公开日 2022-04-15
    申请人 中汽创智科技有限公司 专利授权日期 2023-12-26
    发明人 秦民;丁晓武;周澍 专利权期限届满日 2041-12-29
    申请人地址 211100 江苏省南京市江宁区秣陵街道胜利路88号 最新法律状态 授权
    技术领域 智能网联汽车 分类号 H04L67/12
    技术效果 可靠性 有效性 有效(授权、部分无效)
    专利代理机构 广州三环专利商标代理有限公司 44202 代理人 苗芬芬
    专利技术详情
    >
    01

    专利摘要

    本公开涉及车载设备通信方法、装置、系统和车辆。上述方法包括:若发送模式为单帧模式,且发送队列不为空,从发送队列的队首获取第一帧发送报文,并发送第一帧发送报文至接收端,若在第一预设时间内接收到对应第一帧发送报文的第一确认应答帧,将发送队列进行一次出队操作;若发送模式为双帧模式,且发送队列包括至少两个待发送报文,从发送队列的队首获取第二帧发送报文和第三帧发送报文,并发送第二帧发送报文和第三帧发送报文至接收端,若在第二预设时间内接收对应第三帧发送报文的第二确认应答帧,将发送队列进行两次出队操作。本公开针对车载设备之间的通信协议进行优化,实现了一个轻量级的高可靠性的通信方法。
    展开 >
    02

    专利详情

    技术领域 本公开涉及汽车电子电器架构通信领域,尤其涉及车载设备通信方法、装置、系统和车辆。 背景技术 随着汽车电子技术的飞速发展,汽车电子的需求也是朝着多样化、复杂化进行发展,整车内的电子控制单元(Electronic Control Unit,EUC)数量持续增加,外加上自动驾驶技术的不断发展,车载通信的带宽需求也是不断增长。传统的车载通信方式已经无法满足整车通信带宽的需求。 车载以太网的通信协议栈同样是采用了征求意见稿(Request For Comments,RFC)的标准4层传输控制协议/网际协议(Transmission Control Protocol/InternetProtocol,TCP/IP)协议栈,从底层到上层包括网络驱动(Ethernet Driver,ETH DRIVER)、网络接口(Ethernet Interface,ETH INTERFACE)、网际互联协议(Internet Protocol,IP)、用户数据包协议(User Datagram Protocol,UDP)、传输控制协议(TransmissionControl Protocol,TCP)和套接字适配器(Socket Adaptor)等模块。对于传输层,车载以太网同样支持UDP和TCP,UDP为应用程序发送和接收数据包,与TCP不同的是,UDP是不可靠的,它不能保证数据报能安全无误的到达最终目的地。但是TCP协议相对于UDP内部机制复杂很多,而且中间的重传机制也是效率比较低,对于车载微电子控制单元(MicrocontrollerUnit,MCU)来说,如果要完全使用TCP的所有功能特性,那么对于MCU的CPU负荷以及硬件随机存取寄存器(Random Access Memory,RAM)和多媒体软件平台(FLASH)资源都是消耗比较大的,会大大影响整车软件的运行效率。 发明内容 为了解决上述提出的至少一个技术问题,本公开提出了车载设备通信方法、装置、系统和车辆。 根据本公开的一方面,提供了一种车载设备通信方法,应用于发送端,其包括: 在接收端和发送端建立连接的情况下,根据发送端窗口的大小和接收端窗口的大小,确定数据的发送模式; 若所述发送模式为单帧模式,且所述发送队列不为空,从所述发送队列的队首获取待发送报文,作为第一帧发送报文,并发送所述第一帧发送报文至所述接收端,若在第一预设时间内接收到所述接收端发送的对应所述第一帧发送报文的第一确认应答帧,将所述发送队列进行一次出队操作; 若所述发送模式为双帧模式,且所述发送队列包括至少两个待发送报文,从所述发送队列的队首获取两个所述待发送报文,作为第二帧发送报文和第三帧发送报文,并发送所述第二帧发送报文和所述第三帧发送报文至所述接收端,若在第二预设时间内接收所述接收端发送的对应所述第三帧发送报文的第二确认应答帧,将所述发送队列进行两次出队操作。 在一些可能的实施方式中,所述发送所述第二帧发送报文和所述第三帧发送报文至所述接收端之后,还包括: 若在所述第二预设时间内接收到所述接收端发送的对应所述第二帧发送报文的第三确认应答帧,将所述发送队列进行一次出队操作,并重新发送所述第三帧发送报文; 若在所述第二预设时间内未接收到所述第二确认应答帧和所述第三确认应答帧,将所述发送模式由所述双帧模式转换为所述单帧模式。在一些可能的实施方式中,所述发送所述第一帧发送报文至接收端之后,还包括: 若在所述第一预设时间内未接收到所述第一确认应答帧,则重新发送所述第一帧发送报文。 在一些可能的实施方式中,所述根据发送端窗口的大小和接收端窗口的大小,确定发送队列的发送模式之前,所述方法还包括: 获取待存储报文; 若所述发送队列中所述待发送报文的数量小于第一预设值,将所述待存储报文插入所述发送队列的队尾,作为待发送报文。 在一些可能的实施方式中,所述方法还包括: 若所述待存储报文成功插入所述发送队列的队尾,利用第一发送序列号标识所述待存储报文,所述第一发送序列号为第二发送序列号加1,所述第二发送序列号为所述待存储报文在所述发送队列的前一个报文的发送序列号。 在一些可能的实施方式中,所述方法还包括: 响应于接收到所述第一确认应答帧的情况,校验所述第一确认应答帧的第一接收序列号与第三发送序列号是否相同,所述第三发送序列号为所述第一帧发送报文在所述发送队列的后一个报文的发送序列号; 若不相同,重新发送第一帧发送报文; 响应于接收到所述第二确认应答帧的情况,校验所述第二确认应答帧的第二接收序列号与第四发送序列号是否相同,所述第四发送序列号为所述第三帧发送报文在所述发送队列的后一个报文的发送序列号; 若不相同,重新发送第二帧发送报文和第三帧发送报文。 在一些可能的实施方式中,所述接收端和发送端建立连接的过程包括: 发送第一次连接请求至所述接收端; 接收所述接收端发送的第二次连接请求和所述第一次连接请求的确认信号; 发送所述第二次连接请求的确认信号至所述接收端; 确定与所述接收端建立连接。 根据本公开的第二方面,提供一种车载设备通信装置,所述装置包括: 发送模式确定模块,用于在接收端和发送端建立连接的情况下,根据发送端窗口的大小和接收端窗口的大小,确定数据的发送模式; 单帧模式发送模块,用于若所述发送模式为单帧模式并且所述发送队列不为空,从所述发送队列的队首获取待发送报文,作为第一帧发送报文,并发送所述第一帧发送报文至所述接收端,若在第一预设时间内接收到所述接收端发送的对应所述第一帧发送报文的第一确认应答帧,将所述发送队列进行一次出队操作; 双帧模式发送模块,用于若所述发送模式为双帧模式并且所述发送队列不为空包括至少两个待发送报文,从所述发送队列的队首获取两个所述待发送报文,作为第二帧发送报文和第三帧发送报文,并发送所述第二帧发送报文和所述第三帧发送报文至所述接收端,若在第二预设时间内接收所述接收端发送的对应所述第三帧发送报文的第二确认应答帧,将所述发送队列进行两次出队操作。 根据本公开的第三方面,提供一种车载设备通信系统,所述系统包括发送端和接收端,所述发送端执行上述的车载设备通信方法。 根据本公开的第四方面,提供一种车辆,包括上述的车载设备通信系统。 应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,而非限制本公开。 实施本公开,具有以下有益效果: 相比于传统车载总线技术,本公开是一种轻量级的高可靠性的通信方法,根据对端窗口的大小,采取不同传输模式,避免传输中出现拥塞,并且通过发送接收确认机制保证了通信的可靠性,可以满足汽车制造商对于带宽的需求,且相对于具有可靠性但消耗较多系统资源的TCP协议,可以降低车内的网络成本。 根据下面参考附图对示例性实施例的详细说明,本公开的其它特征及方面将变得清楚。 附图说明 为了更清楚地说明本说明书实施例或现有技术中的技术方案和优点,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本说明书的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它附图。 图1示出根据本公开实施例的UDPCM模块的结构示意图; 图2示出根据本公开实施例的车载设备通信方法的流程示意图; 图3示出根据本公开实施例的车载设备发送报文的流程示意图; 图4示出根据本公开实施例的发送端发送报文的流程示意图; 图5示出根据本公开实施例的车载设备通信方法中协议头的结构示意图; 图6示出根据本公开实施例的建立连接的流程示意图; 图7示出根据本公开实施例的启动连接的流程示意图; 图8示出根据本公开实施例的接收报文的流程示意图; 图9示出根据本公开实施例的一种电子设备的框图; 图10示出根据本公开实施例的另一种电子设备的框图。 具体实施方式 下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本发明保护的范围。 需要说明的是,本发明的说明书和权利要求书及上述附图中的术语 " 第一 " 、 " 第二 " 等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语 " 包括 " 和 " 具有 " 以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。 以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面,但是除非特别指出,不必按比例绘制附图。 在这里专用的词 " 示例性 " 意为 " 用作例子、实施例或说明性 " 。这里作为 " 示例性 " 所说明的任何实施例不必解释为优于或好于其它实施例。 本文中术语 " 和/或 " ,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中术语 " 至少一种 " 表示多种中的任意一种或多种中的至少两种的任意组合,例如,包括A、B、C中的至少一种,可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。 另外,为了更好地说明本公开,在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解,没有某些具体细节,本公开同样可以实施。在一些实例中,对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述,以便于凸显本公开的主旨。 请参阅图1,本公开主要是针对车载以太网UDP通信模式进行了优化,在汽车开放系统架构(CP AUTOSAR)的以太网协议栈中新增模块用户数据包协议控制管理单元(UDPCM),UDPCM包括的连接控制模块(CONNECTION CONTROL MODULE)和通信控制模块(COMMUNICATION CONTROL MODULE),连接控制模块负责连接功能,通信控制模块负责通信功能,通信控制模块包括发送管理模块(Transmit Manage Module)和接收管理模块(Receive Manage),UDPCM负责UDP协议可靠性相关的功能,其中包括建立连接、发送确认机制和接收拥塞处理等。基础软件层BSW模块初始化过程中,会根据配置信息决定是否对UDPCM模块进行初始化。如果确认使能了该功能,那么就需要对UDPCM模块进行相应的初始化,其中包括初始化发送队列,初始化接收队列等。 UDPCM模块对于发送功能进行了一定的优化,每个发送端都有一个发送队列链表,具体队列链表的最大深度主要是看实际网络的带宽需求以及系统可用随机存取存储器(RAM)资源。发送功能主要包括两个,一个是发送缓存拥塞处理,另一个是重传机制。 图2示出根据本公开实施例的一种车载设备通信方法的流程示意图,如图2和图3所示,上述方法应用于发送端,其包括: S101、在接收端和发送端建立连接的情况下,根据发送端窗口的大小和接收端窗口的大小,确定数据的发送模式; 针对发送缓存拥塞处理,UDPCM模块会根据发送端的窗口大小以及对端窗口的大小即接收端窗口的大小进行发送模式选择,所述发送端窗口的大小为发送端窗口的缓存大小,所述接收端窗口的大小为接收端窗口的缓存大小,针对接收端不同的缓存大小,发送端需要采取一定发送拥塞处理方式,发送队列是采用链表方式存储,接收端窗口的大小主要是用于指示接收端缓存的大小,对于普通的发送模式即单帧模式,若发送端和接收端的窗口大小正常,UDPCM模块会持续进行单帧发送;对于多帧传输的模式即双帧模式,UDPCM会检查当前发送队列中报文数量,以及发送端和接收端的接收窗口的大小,如果发送端和接收端的接收窗口的大小较大,检查通过,UDPCM模块会启动双帧传输模式,发送端同时发送两帧报文,提高报文传输的效率。另外,正常的面向服务SOAD待存储报文发送到UDP后不直接发送给接收端,需要将待存储报文进行入队到发送队列的操作,如果发送队列已满,则直接丢弃待存储报文,并通过返回值通知上层即应用层当前待存储报文发送失败,若发送队列未满,将待存储报文插入发送队列的队尾,作为发送队列中的待发送报文;针对数据的发送端和接收端的窗口大小,确定发送模式,避免接收端的窗口过小而无法同时接收双帧报文时导致双端的数据传输进入拥塞状态。 S102、若所述发送模式为单帧模式,且所述发送队列不为空,从所述发送队列的队首获取待发送报文,作为第一帧发送报文,并发送所述第一帧发送报文至所述接收端,若在第一预设时间内接收到所述接收端发送的对应所述第一帧发送报文的第一确认应答帧,将所述发送队列进行一次出队操作; 当发送模式为单帧模式时,从发送队列的队首获取第一个待发送报文,将该待发送报文作为第一帧发送报文,将第一帧发送报文发送至接收端,接收端成功接收到第一帧发送报文后,先检测第一帧发送报文是否具有双帧标志位,接收端检测出第一帧发送报文不具有双帧标志位,表明当前发送模式为单帧模式,接收端针对第一帧发送报文返回第一确认应答帧,以通知发送端成功接收到第一帧发送报文,若发送端接收到接收端在接收到第一帧发送报文后发送的第一确认应答帧,确认接收端已接收到第一帧发送报文后,则对发送队列进行出队操作,并继续从发送队列的队首获取待发送报文,继续发送至接收端,直至发送队列为空,停止发送。 若发送端没有接收到第一确认应答帧,则启动重传机制,重新发送第一帧发送报文,直至成功接收到接收端接收到第一帧发送报文后发送的第一确认应答帧,确定接收端接收到第一帧发送报文后,再对发送队列进行出队操作,当发送端的窗口和接收端的窗口比较小,选择单帧模式,避免数据传输出现拥塞。 S103、若所述发送模式为双帧模式,且所述发送队列包括至少两个待发送报文,从所述发送队列的队首获取两个所述待发送报文,作为第二帧发送报文和第三帧发送报文,并发送所述第二帧发送报文和所述第三帧发送报文至所述接收端,若在第二预设时间内接收所述接收端发送的对应所述第三帧发送报文的第二确认应答帧,将所述发送队列进行两次出队操作。 当发送模式为双帧模式时,从发送队列的队首依次获取两个待发送报文,将第一个获取的待发送报文作为第二帧发送报文,将第二个获取的待发送报文作为第三帧发送报文,并将第二帧发送报文和第三帧发送报文发送至接收端,接收端成功接收到发送端发送的第二帧发送报文后,检测第二帧发送报文是否具有双帧标志位,接收端判断出第二发送报文具有双帧标志位,表明当前发送模式为双帧模式;因此,接收端不针对第二帧发送报文进行应答,等待接收下一帧发送报文即第三帧发送报文,当接收端成功接收到第三帧发送报文时会返回第二确认应答帧,以通知发送端成功接收到第二帧发送报文和第三帧发送报文,发送端接收到接收端发送的第二确认应答帧后,确认接收端成功接收第二帧发送报文和第三帧发送报文后,对发送队列进行两次出队操作,当发送队列进行两次出队操作后,发送端继续从发送队列的队首获取两个待发送报文,继续发送至接收端,直至发送队列为空,停止发送。 通信双端即发送端和接收端发送数据报文时,会根据配置决定是否开启重传机制或者双帧发送模式等,接收方需要对接收到的数据包进行应答。对于出现超时问题时,那么发送端需要进行重传发送。当发送端和接收端的窗口足够大时,选择双帧模式,提高数据传输的效率,可以满足汽车制造商对于带宽的需求,且降低因为传输效率过慢导致拥塞的概率。 在汽车开放系统架构(CP AUTOSAR)的以太网协议栈中增加UDPCM模块,对轻量级的UDP通信协议进行了改善,根据对端窗口的大小,采取不同传输模式,避免传输中出现拥塞,并且通过发送接收确认机制保证了通信的可靠性。 在一个实施例中,所述发送所述第二帧发送报文和所述第三帧发送报文至所述接收端之后,还包括: 若在所述第二预设时间内接收到所述接收端发送的对应所述第二帧发送报文的第三确认应答帧,将所述发送队列进行一次出队操作,并重新发送所述第三帧发送报文; 若在所述第二预设时间内未接收到所述第二确认应答帧和所述第三确认应答帧,将所述发送模式由所述双帧模式转换为所述单帧模式。 当发送模式为双帧模式时,从发送队列的队首依次获取两个待发送报文,将第一个获取的待发送报文作为第二帧发送报文,将第二个获取的待发送报文作为第三帧发送报文,并将第二帧发送报文和第三帧发送报文发送至接收端,接收端成功接收到发送端发送的第二帧发送报文后,判断出第二帧发送报文具有双帧标志位,因此,接收端不针对第二帧发送报文进行应答,等待接收下一帧发送报文即第三帧发送报文,当接收端未在预设时间内接收到第三帧发送报文,则针对第二帧发送报文返回第三确认应答帧,以通知发送端成功接收到第二帧发送报文但未接收到第三帧发送报文,当发送端接收到第三确认应答帧后,确认接收端接收到第二帧发送报文但未接收到第三帧发送报文,开启重传机制,发送端继续发送第三帧发送报文,直至成功接收到第二确认应答帧,若发送端连续发送三次第三帧发送报文后都未在预设时间接收到第二确认应答帧,则停止发送,并对发送队列进行一次出队操作,出队操作完成后,继续从发送队列获取两个待发送报文,发送至发送端,直至发送队列为空。 若发送端未接收到接收端发送的针对第二帧发送报文的第三确认应答帧以及针对第三帧发送报文的第二确认应答帧,则将发送模式从双帧模式转换为单帧模式,持续进行单帧发送。 本发明实施例中双帧模式采用发送接收确认机制,即发送端每发送两个报文至接收端后,等待对端发送确认接收的应答帧,保证对端成功接收报文,提高了报文发送的可靠性。 在一个实施例中,所述发送所述第一帧发送报文至接收端之后,还包括: 若在所述第一预设时间内未接收到所述第一确认应答帧,则重新发送所述第一帧发送报文。 当发送模式为单帧模式时,首先从发送队列的队首获取待发送报文,将该待发送报文作为第一帧发送报文,并将第一帧发送报文发送至接收端,若发送端在预设时间内未接收到接收端发送的针对第一帧发送报文的第一确认应答帧,则重新发送第一帧发送报文,直至接收到第一确认应答帧,若连续发送三次后,还未接收到第一确认应答帧,则停止发送,并等待接收端窗口信息,以进行下一步操作。 本发明实施例中单帧模式也采用发送接收确认机制,提高报文发送的可靠性。 在一个实施例中,所述根据发送端窗口的大小和接收端窗口的大小,确定发送队列的发送模式之前,所述方法还包括: 获取待存储报文; 若所述发送队列中所述待发送报文的数量小于第一预设值,将所述待存储报文插入所述发送队列的队尾,作为待发送报文。 UDPCM获取面向服务的分析和设计SOAD报文,作为待存储报文,获取待存储报文后,需要进行发送队列的入队操作,首先判断发送队列中的发送报文是否已满,若发送队列已满,则直接丢弃待存储报文,并通过返回值通知上层即应用层当前待存储报文发送失败,若未满则将待存储报文插入发送队列的后端即发送队列的队尾,作待发送报文。UDPCM模块对于发送功能进行了一定的优化,每个发送端都有一个发送队列链表,具体队列的最大深度主要是看实际网络的带宽需求以及系统可用RAM资源,在传输过程中增加滑动窗口,允许多帧报文同时发送,大大提升了网络吞吐量。 在一个实施例中,所述方法还包括: 若所述待存储报文成功插入所述发送队列的队尾,利用第一发送序列号标识所述待存储报文,所述第一发送序列号为第二发送序列号加1,所述第二发送序列号为所述待存储报文在所述发送队列的前一个报文的发送序列号。 将待存储报文插入发送队列时,利用第一发送序列号标识待存储报文,作为待发送报文,每存储一个待存储报文,发送序列号便加1,该待存储报文的第一发送序列号比待存储报文在发送队列的前一个报文的第二发送序列号大1,发送队列的前端为队首端,发送序列号标识待发送报文发送的顺序,方便校验,保证了双端数据传输的可靠性。 在一个实施例中,所述方法还包括: 响应于接收到所述第一确认应答帧的情况,校验所述第一确认应答帧的第一接收序列号与第三发送序列号是否相同,所述第三发送序列号为所述第一帧发送报文在所述发送队列的后一个报文的发送序列号; 若不相同,重新发送第一帧发送报文; 响应于接收到所述第二确认应答帧的情况,校验所述第二确认应答帧的第二接收序列号与第四发送序列号是否相同,所述第四发送序列号为所述第三帧发送报文在所述发送队列的后一个报文的发送序列号; 若不相同,重新发送第二帧发送报文和第三帧发送报文。 请参阅图4,在一个实施例中,接收端接收到发送端发送的发送报文,需要检测发送报文是否具有双帧标志位,以确认是单帧模式还是双帧模式,若发送报文中不具有双帧标志位,则说明发送模式为单帧模式,若发送报文中具有双帧标志位,则说明发送模式为双帧模式,对于不同的发送模式,接收端针对发送端发送的报文反馈确认应答帧的处理方式不同; 在一个实施例中,在单帧模式下,发送队列中的每一个待发送报文都被发送序列号标识,且每一个待发送报文的发送序列号是发送队列中前一个待发送报文的发送序列号加1,例如,从发送队列队首的第一个待发送报文开始,若第一个待发送报文的发送序列号为N,则队首的第二个待发送报文的序列号为N+1,第三个待发送报文的序列号为N+2,以此类推;当发送端将第一个待发送报文作为第一帧发送报文发送到发送端,第一帧发送报文的发送序列号为N,接收端接收到第一帧发送报文,检测第一帧发送报文是否具有双帧标志位,未检测出第一帧发送报文具有双帧标志位,对第一帧发送报文进行确认,返回第一确认应答帧,第一确认应答帧包括第一接收序列号,第一接收序列号为接收到的第一帧发送报文的发送序列号加1,即第一接收序列号为N+1,接收序列号为接收端通知发送端下一个将要发送的报文的发送序列号,因此,发送端接收到接收端发送的第一确认应答帧后,校验第一接收序列号与第一帧发送报文在所述发送队列的后一个报文的发送序列号即第三发送序列号是否相同,若相同,说明接收端反馈的第一确认应答帧是与第一帧发送报文相匹配,两端数据发送正常,若不同,说明两端数据发送异常,则重新发送第一帧发送报文。本发明实施例中通过发送序列号标识待发送报文发送的顺序,接收序列号标识下一个将要发送的报文的序列号,保证了双端数据传输的可靠性。 在一个实施例中,在双帧模式下,发送队列中的每一个待发送报文都被发送序列号标识,且每一个待发送报文的发送序列号是发送队列中前一个待发送报文的发送序列号加1,例如,从发送队列队首的第一个待发送报文开始,若第一个待发送报文的发送序列号为N,则队首的第二个待发送报文的序列号为N+1,第三个待发送报文的序列号为N+2,以此类推;当发送端将第一个待发送报文作为第二帧发送报文发送到发送端,第二帧发送报文的发送序列号为N,当发送端将第二个待发送报文作为第三帧发送报文发送到发送端,第三帧发送报文的发送序列号为N+1,接收端接收到第二帧发送报文,检测第二帧发送报文是否具有双帧标志位,判断出第二帧发送报文具有双帧标志位,因此,等待接收下一帧发送报文即第三帧发送报文,接收到第三帧发送报文后,返回第二确认应答帧,第二确认应答帧包括第二接收序列号,第二接收序列号为接收到的第三帧发送报文的发送序列号加1,即第一接收序列号为N+2,接收序列号为接收端通知发送端下一个将要发送的报文的发送序列号,因此,发送端接收到接收端发送的第二确认应答帧后,校验第二接受序列号与第三帧发送报文在所述发送队列的后一个报文的发送序列号即第四发送序列号是否相同,若相同,说明两端数据发送正常,若不同,说明两端数据发送异常,则重新发送第二帧发送报文和第三帧发送报文。本发明实施例中通过发送序列号标识待发送报文发送的顺序,接收序列号标识下一个将要发送的报文的序列号,保证了双端数据传输的可靠性。 在一个实施例中,所述接收端和发送端建立连接的过程包括: 发送第一次连接请求至所述接收端; 接收所述接收端发送的第二次连接请求和所述第一次连接请求的确认信号; 发送所述第二次连接请求的确认信号至所述接收端; 确定与所述接收端建立连接。 当驾驶员选择利用UDPCM模块进行车载设备之间通信的相关功能,通过UDPCM模块建立连接、发送接收确认机制和接收拥塞处理等。UDPCM中的连接控制模块(CONNECTIONCONTROL MODULE)主要负责对于UDP连接的管理,连接控制模块会有一个专用的容器对每次连接进行标识,每次连接相当于是一个多元组,包括目标端口、源端口、源地址、目的地址、连接状态、接收端/发送端窗口的大小、发送序列号或接收序列号,其中连接状态包括悬挂PENDING状态、等待WAITING状态、连接CONNECTED状态或断开DISCONNECTED状态,UDPCM模块报文的协议头格式包括发送序列号SENDSEQ、接收序列号RECSEQ、拥塞窗口CWND、窗口大小WINDOW、标志位FLAGS、校验字段CHECKSUM,如图5所示。 首先发送端和接收端通信两端首次建立连接时候,发送端和接收端都处于悬挂PENDING状态,需要经历三次消息交互完成一次握手流程,连接双方需要通过特定握手报文进行交换,如图6所示,具体为,发送端的UDPCM模块发送第一次握手申请即第一次连接请求至接收端的UDPCM模块,发送的第一次连接请求中包括发送序列号,以使得接收端得知发送端的起始序列号,接收端成功接收到发送端发送的第一次连接请求后,发送第二次握手申请即第二次连接请求以及第一次连接请求的确认信号,第二次连接请求包括发送序列号和接收序列号,接收序列号是使得发送端得知接收端的起始序列号,每一次连接都会包含发送序列号和接收序列号,以标识每一次连接的顺序,第一次连接请求的确认信号是通知发送端已经接收到第一次连接请求,发送端接收到第二次连接请求和第一次连接请求的确认信号后,发送第二次连接请求的确认信号至接收端,此时,发送端和接收端成功建立连接,发送端和接收端开始正常通信。握手双方需要告知对方各自发送起始序列号,以及本端的接收窗口的大小。发送端和接收端断开连接的过程同样需要经历三次消息交互,发送端发起结束连接的请求,接收端收到结束请求的报文后,会停止正常数据报文发送工作,发送结束确认报文给发送端,发送端收到接收端的结束请求以及应答报文后,会进入DISCONNECTED状态,并发送确认报文给接收端,接收端收到确认报文后同样会将自己的状态设为DISCONNECTED,这样两端就完成了简单的挥手的协议,就可以等待下一次的建立连接请求。 如果通信双端针对特定的套接字socket使用了UDPCM模块的扩展功能,那么在双方首次通信时,UDPCM模块会根据当前连接状态进行检查,如果发现是未连接状态,那么就会触发握手交互协议,双方会协商发送序号、窗口的大小等信息。握手完成后更新双方的状态为CONNECTION状态。对于UDP连接的管理,UDPCM模块使用特定的内存块进行管理,内存块大小以及内存块数量由用户配置决定,建立连接时,UDPCM模块会动态申请内存块,如图7所示。通信结束,UDP模块通知UDPCM模块双方通信结束可以关闭当前连接,通信一方通过UDPCM模块发起挥手的协议流程,经过三次挥手流程结束后,UDPCM模块认为通信结束,那么UDPCM模块会将当前连接状态更改为DISCONNECTTED,随后可以直接释放当前连接的内存块。 当前这套UDP建立连接以及解除连接的请求是一套相对简易的连接请求机制,对于连接的管理采用容器进行了管理,容器中的资源实现动态申请分配,每个连接采用多元组进行管理,对于连接的信息集中管理,相对于TCP来说,这套机制简化了很多,对于链路的可靠性有一定的改善作用,但是也不会过于占用微控制单元(MCU)的硬件资源。 在一个实施例中,接收端接收到发送端发送的发送报文后,检测发送报文是否具有双帧标志位,若不具有双帧标志位,则判断发送模式为单帧模式,即接收端接收到的发送报文为第一帧发送报文,当成功接收到第一帧发送报文时,判断接收队列是否已满,接收队列中的报文是以链表形式存储,接收队列中存储的报文为待接收报文,若接收队列中的数量小于第二预设值或未满,将发送报文即第一帧发送报文存储至接收队列的队尾即接收队列的队尾,作为接收报文,并更新当前接收端窗口的大小,并向接收端发送接收到第一帧发送报文的确认报文即第一确认应答帧,以通知发送端已成功接收到第一帧发送报文,第一确认应答帧包括第一接收序列号,第一接收序列号为第一帧发送报文中第一发送序列号加1,第一接收序列号为接收端通知发送端下一个需要发送的报文的发送序列号;接收端将接收队列的接收报文从所述接收端的通信模块发送至所述接收端的应用模块,并将所述接收队列进行出队操作,直至接收队列的所有发送报文皆成功发送至应用模块,即接收队列为空,接收完成; 当接收端检测出发送报文具有双帧标志位后,判断当前发送模式为双帧模式时,即接收端接收到的发送报文为第二帧发送报文和第三帧发送报文时,判断接收队列是否已满,接收队列中的报文是以链表形式存储,接收队列中存储的报文为待接收报文,若接收队列中的数量小于第二预设值或未满,将发送报文即第二帧发送报文和第三帧发送报文存储至接收队列的队尾即接收队列的队尾,作为接收报文,更新当前接收端窗口的大小,并向接收端发送接收到第三帧发送报文的确认报文即第二确认应答帧,以通知发送端已成功接收到第二帧发送报文和第三帧发送报文,第二确认应答帧包括第二接收序列号,第二接收序列号为第三帧发送报文中的第五发送序列号加1,第二接收序列号,用于通知发送端下一个发送的报文的发送序列号;接收端将接收队列的接收报文从所述接收端的通信模块发送至所述接收端的应用模块,并将所述接收队列进行出队操作,直至接收队列的所有发送报文皆成功发送至应用模块,即接收队列为空,接收完成,如图8所示; 在一个实施例中,所述发送报文对应的确认应答帧之后,启动窗口定时器进行计时操作;若在所述第三预设时间内,未接收到所述发送报文,则发送预设报文至所述发送端,以保持与所述发送端的连接关系。启动窗口定时器进行计时操作;若在第三预设时间内,接收到所述发送端发送的发送报文,所述发送报文包括第一帧发送报文、第二帧发送报文或第三帧发送报文,将所述窗口定时器进行清零,并重新计时;若在所述第三预设时间内,未接收到所述发送报文,则发送预设报文至所述发送端,以保持与所述发送端的连接关系。 UDPCM模块对于接收功能同样是使用了专用的接收队列进行管理,队列的最长的深度同样是由实际网络带宽需求以及系统的RAM资源决定。接收组件主要包括两个功能,一个是接收滑动窗口功能,另一个是接收确认机制。 对于接收滑动窗口功能,主要利用队列链表对接收数据报进行管理,每当接收到对端发过来的数据报之后,并且校验成功后,会将数据报进行入队操作,随后会向对端发送接收应答帧。同时会将队列中的数据向上层的发送,发送成功后会对接收队列进行出队操作;同时启动窗口定时器,如果在窗口定时器超时的第三预设时间即窗口期内,收到对端发送数据包请求,那么窗口定时器清零重启计时,如果窗口定时器超时后,会向对端发送当前窗口大小的特定报文帧,保持与对端的连接关系。 对于接收确认机制就是近似于TCP的ACK确认包,UDPCM模块会对每一帧UDP报文发送确认帧报文,确保与发送端数据报传输的正确性,接收端接收到发送端发送的报文后,先检测发送报文中是否具有双帧标志位,若不具有双帧标志位,则确定是单帧发送模式,对于单帧发送模式,就正常的对发送报文的发送序列号进行确认,如果发送报文具有标志位就不进行应答,等待接收到第二个发送报文后才进行发送确认的操作,即双帧模式下,接收到第一帧发送报文后具有双帧的标志位,则等到成功接收到第三帧发送报文后再发送应答帧即第二确认应答帧。 对于车载以太网相关的技术,CP AUTOSAR中针对TCP/IP这块的标准也是主要参考RFC文档中的相关说明,并没有自有的一些相关特性。对于传输层这块也是支持传统的TCP以及UDP协议。对于可靠性来说,TCP是基于连接的,并支持重传而且有着一套完善的接收以及发送拥塞处理方式,对于一些要求比较高的网络来说是首选的,但是CP AUTOSAR软件是运行在MCU上的,MCU不论是RAM以及FLASH资源相对于MPU或者SOC都是要紧张很多的,运行TCP这套完善的机制会消耗比较多的系统资源,CPU的工作负荷就会比较高,而且TCP中重传机制相对也是比较慢的,实时性不高。本公开主要是针对车载以太网UDP通信模式进行了优化,在CP AUTOSAR(汽车开放系统架构)以太网协议栈中新增模块UDPCM,负责UDP协议可靠性相关的功能,其中包括建立连接,发送接收确认机制,接收拥塞处理等等,是一种轻量级的高可靠性的通信方法,根据对端窗口的大小,采取不同传输模式,避免传输中出现拥塞,并且通过发送接收确认机制保证了通信的可靠性,可以满足汽车制造商对于带宽的需求,且相对于具有可靠性但消耗较多系统资源的TCP协议,可以降低车内的网络成本。 在一个实施例中,若所述接收队列不为空,从所述接收队列的队首获取第一个接收报文,作为第一帧接收报文;并将所述第一帧接收报文发送至应用层,发送完成后将所述发送队列进行一次出队操作。 接收端接收到发送端发送的发送报文后,发送报文包括第一帧发送报文、第二帧发送报文或第三帧发送报文,将所述发送报文插入到接收队列中,更新当前接收端窗口的大小,并向发送端发送确认报文,同时发送端从发送队列的队首获取第一个接收报文,作为第一帧接收报文,并将第一帧接收报文发送到应用层,发送成功后,对发送队列进行一次出队操作,判断发送队列是否为空,若发送队列不为空,继续从发送队列的队首获取第二帧接收报文,并将第二帧接收报文发送至应用层,发送成功后,对发送队列再次进行出队操作,直至发送队列为空,即所有的接收报文均发送至应用层。 根据本公开的第三方面,提供一种车载设备通信系统,所述系统包括发送端和接收端,所述发送端执行上述的车载设备通信方法。 根据本公开的第四方面,提供一种车辆,包括上述的车载设备通信系统。 应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,而非限制本公开。 根据本公开的第五方面,提供一种车载设备通信装置,所述装置包括: 发送模式确定模块,用于在接收端和发送端建立连接的情况下,根据发送端窗口的大小和接收端窗口的大小,确定数据的发送模式; 单帧模式发送模块,用于若所述发送模式为单帧模式,且所述发送队列不为空,从所述发送队列的队首获取待发送报文,作为第一帧发送报文,并发送所述第一帧发送报文至所述接收端,若在第一预设时间内接收到所述接收端发送的对应所述第一帧发送报文的第一确认应答帧,将所述发送队列进行一次出队操作; 双帧模式发送模块,用于若所述发送模式为双帧模式,且所述发送队列包括至少两个待发送报文,从所述发送队列的队首获取两个所述待发送报文,作为第二帧发送报文和第三帧发送报文,并发送所述第二帧发送报文和所述第三帧发送报文至所述接收端,若在第二预设时间内接收所述接收端发送的对应所述第三帧发送报文的第二确认应答帧,将所述发送队列进行两次出队操作。 在一些实施例中,本公开实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法,其具体实现可以参照上文方法实施例的描述,为了简洁,这里不再赘述。 本公开实施例还提出一种计算机可读存储介质,上述计算机可读存储介质中存储有至少一条指令或至少一段程序,上述至少一条指令或至少一段程序由处理器加载并执行时实现上述方法。计算机可读存储介质可以是非易失性计算机可读存储介质。 本公开实施例还提出一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,上述处理器被配置为上述方法。 电子设备可以被提供为终端、服务器或其它形态的设备。 图9示出根据本公开实施例的一种电子设备的框图。例如,电子设备800可以是移动电话,计算机,数字广播终端,消息收发设备,游戏控制台,平板设备,医疗设备,健身设备,个人数字助理等终端。 参照图9,电子设备800可以包括以下一个或多个组件:处理组件802,存储器804,电源组件806,多媒体组件808,音频组件810,输入/输出(I/O)的接口812,传感器组件814,以及通信组件816。 处理组件802通常控制电子设备800的整体操作,诸如与显示,电话呼叫,数据通信,相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令,以完成上述的方法的全部或部分步骤。此外,处理组件802可以包括一个或多个模块,便于处理组件802和其他组件之间的交互。例如,处理组件802可以包括多媒体模块,以方便多媒体组件808和处理组件802之间的交互。 存储器804被配置为存储各种类型的数据以支持在电子设备800的操作。这些数据的示例包括用于在电子设备800上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。 电源组件806为电子设备800的各种组件提供电力。电源组件806可以包括电源管理系统,一个或多个电源,及其他与为电子设备800生成、管理和分配电力相关联的组件。 多媒体组件808包括在上述电子设备800和用户之间的提供一个输出接口的屏幕。在一些实施例中,屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板,屏幕可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。上述触摸传感器可以不仅感测触摸或滑动动作的边界,而且还检测与上述触摸或滑动操作相关的持续时间和压力。在一些实施例中,多媒体组件808包括一个前置摄像头和/或后置摄像头。当电子设备800处于操作模式,如拍摄模式或视频模式时,前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。 音频组件810被配置为输出和/或输入音频信号。例如,音频组件810包括一个麦克风(MIC),当电子设备800处于操作模式,如呼叫模式、记录模式和语音识别模式时,麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中,音频组件810还包括一个扬声器,用于输出音频信号。 I/O接口812为处理组件802和外围接口模块之间提供接口,上述外围接口模块可以是键盘,点击轮,按钮等。这些按钮可包括但不限于:主页按钮、音量按钮、启动按钮和锁定按钮。 传感器组件814包括一个或多个传感器,用于为电子设备800提供各个方面的状态评估。例如,传感器组件814可以检测到电子设备800的打开/关闭状态,组件的相对定位,例如上述组件为电子设备800的显示器和小键盘,传感器组件814还可以检测电子设备800或电子设备800一个组件的位置改变,用户与电子设备800接触的存在或不存在,电子设备800方位或加速/减速和电子设备800的温度变化。传感器组件814可以包括接近传感器,被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器,如CMOS或CCD图像传感器,用于在成像应用中使用。在一些实施例中,该传感器组件814还可以包括加速度传感器,陀螺仪传感器,磁传感器,压力传感器或温度传感器。 通信组件816被配置为便于电子设备800和其他设备之间有线或无线方式的通信。电子设备800可以接入基于通信标准的无线网络,如WiFi,2G、3G、4G、5G或它们的组合。在一个示例性实施例中,通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,上述通信组件816还包括近场通信(NFC)模块,以促进短程通信。例如,在NFC模块可基于射频识别(RFID)技术,红外数据协会(IrDA)技术,超宽带(UWB)技术,蓝牙(BT)技术和其他技术来实现。 在示例性实施例中,电子设备800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现,用于执行上述方法。 在示例性实施例中,还提供了一种非易失性计算机可读存储介质,例如包括计算机程序指令的存储器804,上述计算机程序指令可由电子设备800的处理器820执行以完成上述方法。 图10示出根据本公开实施例的另一种电子设备的框图。例如,电子设备1900可以被提供为一服务器。参照图10,电子设备1900包括处理组件1922,其进一步包括一个或多个处理器,以及由存储器1932所代表的存储器资源,用于存储可由处理组件1922的执行的指令,例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理组件1922被配置为执行指令,以执行上述方法。 电子设备1900还可以包括一个电源组件1926被配置为执行电子设备1900的电源管理,一个有线或无线网络接口1950被配置为将电子设备1900连接到网络,和一个输入输出(I/O)接口1958。电子设备1900可以操作基于存储在存储器1932的操作系统,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM或类似。 在示例性实施例中,还提供了一种非易失性计算机可读存储介质,例如包括计算机程序指令的存储器1932,上述计算机程序指令可由电子设备1900的处理组件1922执行以完成上述方法。 本公开可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质,其上载有用于使处理器实现本公开的各个方面的计算机可读程序指令。 计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身,诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如,通过光纤电缆的光脉冲)、或者通过电线传输的电信号。 这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备,或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令,并转发该计算机可读程序指令,以供存储在各个计算/处理设备中的计算机可读存储介质中。 用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码,上述编程语言包括面向对象的编程语言—诸如Smalltalk、C+等,以及常规的过程式编程语言—诸如 " C " 语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中,通过利用计算机可读程序指令的状态信息来个性化定制电子电路,例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA),该电子电路可以执行计算机可读程序指令,从而实现本公开的各个方面。 这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解,流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合,都可以由计算机可读程序指令实现。 这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器,从而生产出一种机器,使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时,产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中,这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作,从而,存储有指令的计算机可读介质则包括一个制造品,其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。 也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上,使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤,以产生计算机实现的过程,从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。 附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分,上述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中,方框中所标准的功能也可以以不同于附图中所标准的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。 以上已经描述了本公开的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。 车载设备通信方法、装置、系统和车辆
    展开 >
    交易服务流程
    >

    挑选中意的板块

    ----

    客服确认选择专利的交易信息和价格并支付相应款项

    办理转让材料

    ----

    协助双方准备相应的材料

    签订协议

    ----

    协助卖家签订协议

    办理备案手续

    ----

    买卖双方达成一致后

    交易完成

    ----

    交易完成可投入使用

    过户资料 & 安全保障 & 承诺信息
    >

    过户资料

    买卖双方需提供的资料
    公司 个人
    买家 企业营业执照
    企业组织机构代码证
    身份证
    卖家 企业营业执照
    专利证书原件
    身份证
    专利证书原件
    网站提供 过户后您将获得
    专利代理委托书
    专利权转让协议
    办理文件副本请求书
    发明人变更声明
    专利证书
    手续合格通知书
    专利登记薄副本

    安全保障

    承诺信息

    我方拟转让所持标的项目,通过中国汽车知识产权交易平台公开披露项目信息和组织交易活动,依照公开、公平、公正和诚信的原则作如下承诺:

    1、本次项目交易是我方真实意思表示,项目标的权属清晰,除已披露的事项外,我方对该项目拥有完全的处置权且不存在法律法规禁止或限制交易的情形;
    2、本项目标的中所涉及的处置行为已履行了相应程序,经过有效的内部决策,并获得相应批准;交易标的涉及共有或交易标的上设置有他项权利,已获得相关权利 人同意的有效文件。
    3、我方所提交的信息发布申请及相关材料真实、完整、准确、合法、有效,不存在虚假记载、误导性陈述或重大遗漏;我方同意平台按上述材料内容发布披露信息, 并对披露内容和上述的真实性、完整性、准确性、合法性、有效性承担法律责任;
    4、我方在交易过程中自愿遵守有关法律法规和平台相关交易规则及规定,恪守信息发布公告约定,按照相关要求履行我方义务;
    5、我方已认真考虑本次项目交易行为可能导致的企业经营、行业、市场、政策以及其他不可预计的各项风险因素,愿意自行承担可能存在的一切交易风险;
    6、我方在平台所组织交易期间将不通过其他渠道对标的项目进行交易;
    7、我方将按照平台收费办法及相关交易文件的约定及时、足额支付相关费用,不因与受让方争议或合同解除、终止等原因拒绝、拖延、减少交纳或主张退还相关费用。