CN117749624A - 一种车辆数据采集可配置化的方法 - Google Patents

Abstract

本发明提供了一种车辆数据采集可配置化的方法，包括以下步骤：S1，将T‑BOX端的配置文件上传到TSP平台；将根据通信协议和信号矩阵制定的包含信号信息的信号规则表配置到配置文件中，并将配置文件传输至NAD端，NAD端根据TSP平台下发的最新的配置文件对配置文件进行更新并存储；S2，根据更新的配置文件NAD端对配置文件进行解析得到信号规则表；能够灵活采集车辆信息、灵活配置数据采集的时间及周期、降低数据传输负载，不仅提升了数据采集效率，同时减少负载率，大大保证了数据传输的实时性、准确性和安全性。

Description

一种车辆数据采集可配置化的方法

技术领域

本发明涉及车辆数据处理技术领域，更具体地说，涉及一种车辆数据采集可配置化的方法。

背景技术

汽车数据采集是指通过车辆搭载的传感器、摄像头、雷达等设备收集车辆周围环境、车辆状态和驾驶行为等数据。这些数据可以包括图像、视频、激光雷达扫描、惯性测量单元(IMU)数据、GPS位置信息等。汽车数据采集的目的是提供实时、准确的车辆和环境数据作为自动驾驶系统的输入，用于感知、决策和控制。现有的数据采集方案往往通过车载数据采集终端(T-BOX)固件中的采集功能或自行编写的采集程序对车辆数据进行采集。往往采集程序所采集到的车身信息在车载终端上表现为固化的。在智能万物互联的时代之前，需要采集的数据种类少、即使进行全量采集的话其负载也能够承受，所以运用这种采集逻辑是可行的。

但是，随着智能车联网技术的快速发展，其整车网络拓扑也呈现出越来越复杂，采集的数据所呈现出的现状表现为：可采集的数据规模越来越大，对数据的采集频率从秒级向毫秒级转变，数据的维度也变得越来越多，例如总线信号、传感器内部状态、软件埋点、用户行为、道路和环境感知数据等等，数据质量要求更高，要解决在传统模式下丢失、乱序、跳变、延时等严重影响业务分析数据的问题。在传统的数据采集方式下，其具体表现为数据采集的方式固定，根本无法灵活地变更采集的数据，数据采集量少，采集以及分析成本高，采集周期长。

车身信息可采集的数据越来越多，假如进行全量采集的话，其表现出采集数据量过大，从而会占据宝贵的带宽资源。

现有专利号为CN115225422A的一种CAN总线数据采集方法，基于集成在车载控制器中的数据采集器对数据进行采集，其更侧重于采集方法的实现。

现有专利号为CN113459971A公开了一种数据采集方法来对车辆数据信息进行采集，着重于数据采集的方法和传输效率。

现有专利号为CN116224871A公开了一种数据采集装置，通过提高硬件集成度,减少设备的冗余和线束布置,节约成本,并能将数据采集、刷写功能集成到单一硬件系统,实现车上及离线数据刷写,能将多通道的数据进行深度融合,大大提升数据处理效率。

现有专利号为CN115107784A公开了一种驾驶数据采集及分析方法，侧重于对驾驶数据的采集和分析，从而帮助客户针对性改善存在的不良习惯，进而使客户的行为更加规范和经济。

发明内容

本发明要解决的技术问题在于，针对上述技术方案存在的不足，提供一种提高数据采集效率，同时减少负载率的车辆数据采集可配置化的方法。

本发明提供一种车辆数据采集可配置化的方法，所述方法包括以下步骤：

S1，将T-BOX端的配置文件上传到TSP平台；将根据通信协议和信号矩阵制定的包含信号信息的信号规则表配置到配置文件中，并将配置文件传输至NAD端，NAD端根据TSP平台下发的最新的配置文件对配置文件进行更新并存储；

S2，根据更新的配置文件NAD端对配置文件进行解析得到信号规则表；

S3，将DBC文件导入到MCU端的Autosar BSW模块中，通过ZSAR Studio工具对Autosar BSW模块进行配置，并对配置后的Autosar BSW模块进行验证，验证后的AutosarBSW模块通过ZSAR Studio的工作机制得到对应的车辆数据信息，最后根据对应的车辆数据信息生成可供上层调用的RTE接口；；

S4，MCU端根据生成的可供上层调用的RTE接口对信号进行全量检测，NAD端根据步骤S2中所解析出的信号规则表，将信号规则表中所包含的信号信息同步给信号检测后的MCU端；

S5，MCU端根据NAD端所同步的信号区分出触发和周期型的信号，从而调用不同的函数来进行数据打包，MCU同时把触发的相关信号自动发送至NAD端，NAD端对MCU打包过来的信号进行抽象处理，并按照制定的车载终端通信协议上传车辆数据信息到TSP平台。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S2中所述信号规则表包括信号发送或接收周期、信号长度与信号发送类型。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S3中所述AutosarBSW模块通过SGW方式与不同车载的ECU进行信号的发送和接收。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S3中所述AutosarBSW模块包括CAN层、CANIF层、PDUR层与COM层。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S3中通过ZSARStudio工具从下至上对CAN层、CANIF层、PDUR层与COM层进行配置，并对配置后的CAN层、CANIF层、PDUR层与COM层进行验证，验证后的CAN层、CANIF层、PDUR层与COM层通过ZSARStudio的工作机制得到对应的车辆数据信息，最后根据对应的车辆数据信息生成可供上层调用的RTE接口。

本发明所述的车辆数据采集可配置化的方法中；所述步骤S6包括以下步骤：

S51，MCU端将NAD端发送来的信号信息与调用对比函数对信号数据信息进行对比，并根据RTE接口类型的不同划分出触发类型和周期类型的信号函数。

本发明所述的车辆数据采集可配置化的方法中；所述步骤S6还包括以下步骤：

S52，将划分出的触发类型和周期类型的信号函数进行打包组成信号数据包。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S6中NAD端根据配置文件中所包含信号中最快的频率去请求周期数据。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S5中NAD端按照国家车载通信标准所制定的车载终端通信协议将车辆数据信息通过4G或5G网络上传到TSP平台。

本发明的车辆数据采集可配置化的方法能够灵活采集车辆信息、灵活配置数据采集的时间及周期、降低数据传输负载，不仅提升了数据采集效率，同时减少负载率，大大保证了数据传输的实时性、准确性和安全性。

附图说明

图1是本发明车辆数据采集可配置化的方法实施例的流程示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

以下是本发明相关术语和定义：

T-BOX端：车联网智能终端T-BOX(Telematics BOX)，也称远程信息处理控制单元(Telematics Control Unit,TCU)，集成GPS、外部通信接口、电子处理单元、微控制器、移动通信单元和存储器等功能模块。其主要功能有车辆数据信息收集、车辆故障监控、车况报告、远程开锁车窗、远程启停车辆、远程开关空调、远程调整座椅、信息分享、通信、安全防盗、车辆诊断、远程升级等。

MCU：微控制单元(Micro Controller Unit)，是指随着大规模集成电路的出现及其发展，将计算机的CPU、RAM、ROM、定时数器和多种I/O接口集成在一片芯片上，形成芯片级的计算机，为不同的应用场合做不同组合控制。

NAD端：网络接入设备(Network Access Device)，负责终端能够与基站连接，确保基站可以联网的一个设备，接收MCU打包来的数据，通过网络上传至基站。

AUTOSAR：汽车开放系统架构(AUTomotive Open System Architecture)，它的目的就是解决当前汽车电子电气架构复杂多样性，同一汽车电子架构标准。使得整个产品生命周期可维护，车辆的整个生命周期内软件可以不断更新和升级、软硬件分离，开发灵活、重用基础软件、重用性可覆盖整个网络节点，甚至可以跨不同的整车厂。

ECU：电子控制器单元(Electronic Control Unit)，其用途就是控制汽车的行驶状态以及实现其各种功能。主要是利用各种传感器、总线的数据采集与交换，来判断车辆状态以及司机的意图并通过执行器来操控汽车。

TSP平台：汽车远程服务提供商(Telematics Service Provider)，是一种提供基于互联网和通信网络的汽车智能化服务的服务提供商。主要涉及到车辆安全、车辆监控、导航、通讯、信息娱乐、驾驶行为分析等方面的功能。

DBC文件：(Data Base CAN)文件，导入到AUTOSAR工程中，其目的是被用来描述CAN网络中各逻辑节点信息，依据该文件可以开发出监视和分析CAN网络中所有逻辑节点的运行状态。

Autosar BSW：基础软件层(Basic Software Layer)，在AUTOSAR三层架构中的最底层，BSW主要为各软件模块提供服务。

Can层：控制器局域网(Controller Area Network)，主要执行对硬件访问，并且向上层提供与硬件无关的API，即仅有CanIf层能够访问Can模块，当Can模块发起传输时，会调用CanIf模块的回调函数来通知事件，独立于硬件。

CanIf层：Can接口层(Can Interface)该模块会提供独特的接口来管理不同的CAN硬件，如CAN控制器和CAN收发器，CanIf满足PduR和AUTOSAR COM栈上层通信模块的控制流和数据流要求。

PduR层：协议数据单元路由(Protocol Data Unit Router)，该模块的主要功能类操作有，PDU接收到本地模块：从底层模块接收I-PDU(Interaction Layer Protocol Data)协议层的网络协议数据单元并将其传递到一个或多个上层模块；从本地模块传输PDU：根据上层模块的请求，将I-PDU传递到一个或多个底层模块；PDU网关：1)从接口模块接收I-PDU，并立即通过相同或其他通信接口模块传输I-PDU；2)从传输协议模块接收I-PDU，并通过相同或其他传输协议模块传输I-PDU。

Com层：通信模块(Communication)，它主要功能是负责管理PDU的发送和接收，可以将PDU从一个ECU发送到另一个ECU，并处理PDU的封装和解封装；该模块可以提供信号级别的处理，如信号打包和解包、信号转换、信号过滤等功能；负责管理ECU之间的通信连接，建立和维护通信连接；同样它还可以提供诊断支持功能，包括故障码的传输和诊断报文的处理。为汽车控制单元应用软件提供了统一的通信环境，为内部和外部通信定义了公共的软件通信接口和行为，增强了应用软件模块的可移植性。

RTE接口：实时运行环境(Runtime Environment)，是AUTOSAR架构中的核心部分，它实现了上层应用软件和下层基础软件之间的通信，它封装了基础软件层的通信和服务，为应用层的软件组件提供标准化的基础软件和通信接口，使的应用层可以通过API函数调用基础软件的服务。

如图1所示，是本发明一种车辆数据采集可配置化的方法实施例的流程示意图。提供一种车辆数据采集可配置化的方法，包括以下步骤：

在步骤S1中，将T-BOX端的配置文件上传到TSP平台；将根据通信协议和信号矩阵制定的包含信号信息的信号规则表配置到配置文件中，并将配置文件传输至NAD端，NAD端根据TSP平台下发的最新的配置文件对配置文件进行更新并存储；

在步骤S2中，根据更新的配置文件NAD端对配置文件进行解析得到信号规则表；

在步骤S3中，将DBC文件导入到MCU端的Autosar BSW模块中，通过ZSAR Studio工具对Autosar BSW模块进行配置，并对配置后的Autosar BSW模块进行验证，验证后的Autosar BSW模块通过ZSAR Studio的工作机制得到对应的车辆数据信息，最后根据对应的车辆数据信息生成可供上层调用的RTE接口；；

在步骤S4中，MCU端根据生成的可供上层调用的RTE接口对信号进行全量检测，NAD端根据步骤S2中所解析出的信号规则表，将信号规则表中所包含的信号信息同步给信号检测后的MCU端；

在步骤S5中，MCU端根据NAD端所同步的信号区分出触发和周期型的信号，从而调用不同的函数来进行数据打包，MCU同时把触发的相关信号自动发送至NAD端，NAD端对MCU打包过来的信号进行抽象处理，并按照制定的车载终端通信协议上传车辆数据信息到TSP平台。

在一实施例中，在所述步骤S2中所述信号规则表包括信号发送或接收周期、信号长度与信号发送类型。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S3中所述AutosarBSW模块通过SGW方式与不同车载的ECU进行信号的发送和接收。

本发明所述的车辆数据采集可配置化的方法中；在所述步骤S3中所述AutosarBSW模块包括CAN层、CANIF层、PDUR层与COM层。

在一实施例中，在所述步骤S3中通过ZSAR Studio工具从下至上对CAN层、CANIF层、PDUR层与COM层进行配置，并对配置后的CAN层、CANIF层、PDUR层与COM层进行验证，验证后的CAN层、CANIF层、PDUR层与COM层通过ZSAR Studio的工作机制得到对应的车辆数据信息，最后根据对应的车辆数据信息生成可供上层调用的RTE接口。MCU根据导入的DBC文件，运用ZSAR Studio工具自下而上对CAN层、CANIF层、PDUR层、COM层进行手动配置，通过对配置工程的验证，对验证过后的工程依据ZSAR Studio的工作机制会产生对应的.c和.h文件，最后依据对应的.c和.h文件会生成可供上层调用的RTE接口。

在一实施例中，所述步骤S6包括以下步骤：

S51，MCU端将NAD端发送来的信号信息与调用对比函数对信号数据信息进行对比，并根据RTE接口类型的不同划分出触发类型和周期类型的信号函数。目的是把信号的每个字节都依据MCU&NAD之间的通信协议进行定义，将定义后的每个信号写进对应的函数，组成信号数据包。

在一实施例中，所述步骤S6还包括以下步骤：

S52，将划分出的触发类型和周期类型的信号函数进行打包组成信号数据包。

在一实施例中，在所述步骤S6中NAD端根据配置文件中所包含信号中最快的频率去请求周期数据。NAD端依据配置文件中所包含信号中最快的频率如1ms、5ms、10ms、50ms等去请求周期数据，是因为周期信号的不同其数据上传频率也不同，会依次请求并叠加不同周期的信号。

在一实施例中，在所述步骤S5中NAD端按照国家车载通信标准所制定的车载终端通信协议将车辆数据信息通过4G或5G网络上传到TSP平台。

MCU端整个逻辑架构是自下而上分层实现的，一个或多个ECU通过SGW方式与上层AUTOSAR架构中BSW模块进行交互。

依据CAN矩阵所制作的DBC文件导入到ZSAR工程中，通过Zsar工具对CAN层、CANIF层、PDUR层、COM层进行配置，最后对DBC文件中所包含的信号逐个进行映射，最后生成RTE接口供应用层进行调用，最终目的是通过调用接口，MCU会事先将全量触发上传的信号做检测，会依据信号类型是触发型或周期型而提供不同的调用函数，进而为数据打包做准备。

T-BOX登录时，会上传配置文件到TSP平台；导入DBC文件到MCU端中的Autosar BSW模块中，其是因为DBC为CAN的数据库文件，它把CAN通讯的信号信息定义的很完整，CAN网络的通讯是依据该标准文件进行的，为所需要传输的信号提供标准信息，同时也为步骤S2中的信号规则表提供信号对比依据；

NAD端根据NAD&MCU之间的通信协议，从MCU端读取各种CAN数据，然后把读取到的数据通过4G/5G通道上传给TSP平台。

在传统的数据上传逻辑中，每10S作为一个周期(周期可在后台更改)上传整车数据、报警信号支持触发上传、远程控制后立即上传一帧整车数据；在本申请中可配置单个信号是否上传、单独信号可配置上传周期、部分信号可触发上传、支持后台配置可上传的信号量等。

随着智能车联网技术的发展，使得车辆产生的数据量大幅增加，车辆产生的数据包含了大量与电池、电机、能量管理以及各种传感器所采集到周围的环境信息。这些车辆产生的大规模数据需要进行采集、传输、存储和分析，其目的就是满足车辆控制、性能优化和安全保障等需求；

同时随着新能源汽车和自动驾驶技术的迅速发展，引入了各种新的数据类型。如电动汽车需要采集电池的状态和性能数据以便对电池和充电策略进行实时优化。自动驾驶车辆需要采集环境感知数据、车辆状态数据和行为数据以便支持决策的自主性和行驶控制性。本申请在一定程度上可以扩大对多样化数据的采集；

本申请支持对数据安全和隐私保护，伴随着车辆数据信息量的增加，数据安全和隐私保护越来越成为更重要的问题。如车辆的具体位置、驾驶行为及车辆性能等。所以车辆数据信息采集系统需要采取相应的安全措施来保护数据的机密性和完整性，防止数据泄露和滥用。

传统模式下，数据采集一直存在延时问题，对自动驾驶车辆来说，对实时数据的需求显得更加迫切。如车辆需要实时采集和处理传感器所采集到的周围数据以便对周围环境进行自主性决策和行驶控制。因此申请具备快速、高效地对数据采集的能力，进一步增强实时性要求。

随着新能源汽车和自动驾驶技术的发展，在数据采集的过程中可能会面临所采集的数据质量参差不齐，准确性达不到要求等问题。如传感器的误差、故障等可能会导致所采集到的数据不准确或者不完整，因此，本申请在数据采集的精度更高、延时更低、更可靠。

本申请基于在原先的架构基础上更新了该架构，基于此架构开发出一套针对车辆数据信息可配置的方法，在传统的车辆数据信息上传及采集的基础上更新了配置功能，支持TSP平台向T-BOX配置整车数据，包括数据上传周期、单独数据是否上传、配置部分数据是否触发上传，然后T-BOX会响应TSP平台配置整车数据；支持T-BOX向TSP平台发送数据可配置生效报告，TSP平台响应T-BOX数据可配置生效报告等。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

因此，以上所述，仅为本发明较佳的具体实施方式，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内，本发明的保护范围应该以权利要求的保护范围为准。

Claims (9)

1.一种车辆数据采集可配置化的方法，其特征在于，所述方法包括以下步骤：

S1，将T-BOX端的配置文件上传到TSP平台；将根据通信协议和信号矩阵制定的包含信号信息的信号规则表配置到配置文件中，并将配置文件传输至NAD端，NAD端根据TSP平台下发的最新的配置文件对配置文件进行更新并存储；

S2，根据更新的配置文件NAD端对配置文件进行解析得到信号规则表；

S3，将DBC文件导入到MCU端的Autosar BSW模块中，通过ZSAR Studio工具对AutosarBSW模块进行配置，并对配置后的Autosar BSW模块进行验证，验证后的Autosar BSW模块通过ZSAR Studio的工作机制得到对应的车辆数据信息，最后根据对应的车辆数据信息生成可供上层调用的RTE接口；

S4，MCU端根据生成的可供上层调用的RTE接口对信号进行全量检测，NAD端根据步骤S2中所解析出的信号规则表，将信号规则表中所包含的信号信息同步给信号检测后的MCU端；

S5，MCU端根据NAD端所同步的信号区分出触发和周期型的信号，从而调用不同的函数来进行数据打包，MCU同时把触发的相关信号自动发送至NAD端，NAD端对MCU打包过来的信号进行抽象处理，并按照制定的车载终端通信协议上传车辆数据信息到TSP平台。

2.根据权利要求1所述的车辆数据采集可配置化的方法，其特征在于，在所述步骤S2中所述信号规则表包括信号发送或接收周期、信号长度与信号发送类型。

3.根据权利要求2所述的车辆数据采集可配置化的方法，其特征在于，在所述步骤S3中所述Autosar BSW模块通过SGW方式与不同车载的ECU进行信号的发送和接收。

4.根据权利要求3所述的车辆数据采集可配置化的方法，其特征在于，在所述步骤S3中所述Autosar BSW模块包括CAN层、CANIF层、PDUR层与COM层。

5.根据权利要求4所述的车辆数据采集可配置化的方法，其特征在于，在所述步骤S3中通过ZSAR Studio工具从下至上对CAN层、CANIF层、PDUR层与COM层进行配置，并对配置后的CAN层、CANIF层、PDUR层与COM层进行验证，验证后的CAN层、CANIF层、PDUR层与COM层通过ZSAR Studio的工作机制得到对应的车辆数据信息，最后根据对应的车辆数据信息生成可供上层调用的RTE接口。

6.根据权利要求5所述的车辆数据采集可配置化的方法，其特征在于，所述步骤S5包括以下步骤：

S51，MCU端将NAD端发送来的信号信息与调用对比函数对信号数据信息进行对比，并根据RTE接口类型的不同划分出触发类型和周期类型的信号函数。

7.根据权利要求6所述的车辆数据采集可配置化的方法，其特征在于，所述步骤S5还包括以下步骤：

S52，将划分出的触发类型和周期类型的信号函数进行打包组成信号数据包。

8.根据权利要求7所述的车辆数据采集可配置化的方法，其特征在于，在所述步骤S5中NAD端根据配置文件中所包含信号中最快的频率去请求周期数据。

9.根据权利要求8所述的车辆数据采集可配置化的方法，其特征在于，在所述步骤S5中NAD端按照国家车载通信标准所制定的车载终端通信协议将车辆数据信息通过4G或5G网络上传到TSP平台。