CN117022146A - 一种客运车辆的双域电子电气架构、工作方法及客运车辆 - Google Patents

一种客运车辆的双域电子电气架构、工作方法及客运车辆 Download PDF

Info

Publication number
CN117022146A
CN117022146A CN202310895409.3A CN202310895409A CN117022146A CN 117022146 A CN117022146 A CN 117022146A CN 202310895409 A CN202310895409 A CN 202310895409A CN 117022146 A CN117022146 A CN 117022146A
Authority
CN
China
Prior art keywords
vehicle
data
information
domain
driving
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.)
Granted
Application number
CN202310895409.3A
Other languages
English (en)
Other versions
CN117022146B (zh
Inventor
张世强
孙宏飞
张达
栾丰
钱贵涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hualu Zhida Technology Co Ltd
Original Assignee
Hualu Zhida Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hualu Zhida Technology Co Ltd filed Critical Hualu Zhida Technology Co Ltd
Publication of CN117022146A publication Critical patent/CN117022146A/zh
Application granted granted Critical
Publication of CN117022146B publication Critical patent/CN117022146B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60RVEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231Circuits relating to the driving or the functioning of the vehicle
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Traffic Control Systems (AREA)

Abstract

本发明提供一种客运车辆的双域电子电气架构、工作方法及客运车辆,所述架构包括:车辆智能座舱控制域、车辆行车驾驶控制域、中央控制器和云平台;所述车辆智能座舱控制域用于接收多个车辆信息采集设备上传的信息,所述多个采集设备之间具备网关的协议转换功能;所述车辆行车驾驶控制域接收车辆行驶执行结构的参数所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果获取车辆行驶的控制实施流程以及车辆行驶的控制或操作指示。本发明通过双域结构的域控制器架构实现了各个域控制器的密切协同,同时能够和平台进行业务的深度融合和全场景联动。

Description

一种客运车辆的双域电子电气架构、工作方法及客运车辆
技术领域
本发明涉及车辆控制技术领域,尤其涉及一种客运车辆的双域电子电气架构、工作方法及客运车辆。
背景技术
随着汽车智能驾驶技术的发展,越来越多的驾驶辅助技术在乘用车上量产,驾驶辅助技术的集成度越来越高。驾驶辅助技术是辅助驾驶员驾驶的安全技术,提升驾驶安全性和舒适性。随着驾驶辅助技术的普及,对于驾驶辅助技术的连续性在不断提高。
其中一个重要的概念是汽车电子电气架构(Electronic and ElectricalArchitecture,文中简称EEA)是由车企所定义的一套整合方式,EEA把汽车中的各类传感器、ECU(电子控制单元)、线束拓扑和电子电气分配系统完美地整合在一起,完成运算、动力和能量的分配,实现整车的各项智能化功能。
因此在智能驾驶技术发展的各个阶段,不可避免地应运而生了车辆域控制器的概念,域控制器就是将汽车电子系统根据功能划分为若干个功能块,每个功能块内部的系统架构由域控制器为主导搭建。域控制器内部的各个系统使用通信总线相互联通,不同域之间由以太网为主干网络承担信息交换,从而取代传统的分布式架构,实现集中化管理。
但是申请人在具体研发过程中,目前多数的车辆域控制器结构基本都是单一整体,即目前的汽车电气/电子架构在每个单独的控制单元中都集成了一个或几个功能特性。这不仅增加了控制单元和分布式软件功能的数量,而且还分别增加了连接的复杂性;也就是说现有的电子架构存在两个致命缺点:1)各个子系统互相独立,无法做多传感器之间的深度融合。2)各子系统独占所配置的传感器,因此无法实现跨多个不同子系统传感器的复杂功能。
更进一步的,不同域控制器之间的识别结果通常是仅仅通过CAN总线进行传输,而CAN总线带宽有限,内存占用较大的动态对象识别结果通过CAN总线进行传输,无法满足系统的大数据传输需求。
综上可知,目前的汽车电气/电子架构方式已经无法支持客运车辆在驾驶控制过程所需要的高速的数据交换和复杂的软件算法设计需求,其内部域控制器也没有足够的计算能力来满足驶控制过程内容和复杂性方面不断增长的要求。
发明内容
本发明提供一种客运车辆的双域电子电气架构、工作方法以及客运车辆,以克服上述技术问题。
为了实现上述目的,本发明的技术方案是:
一种客运车辆的双域电子电气架构,包括车辆智能座舱控制域、车辆行车驾驶控制域、中央控制器和云平台;其中,所述车辆智能座舱控制域用于接收多个车辆信息采集设备上传的信息,所述多个采集设备之间具备网关的协议转换功能,所述信息为车辆智能座舱控制域多维数据;
所述车辆行车驾驶控制域接收车辆行驶执行结构的参数,所述车辆行驶执行结构的参数为车辆行驶多维数据,所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果获取车辆行驶的控制实施流程以及车辆行驶的控制或操作指示。
进一步的,还包括:
车载应用平台,包括:车辆调度系统、设备运维系统、车辆信息发布系统、客户终端;
所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果向所述车辆调度系统发送车辆的调度指令;
所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果向所述设备运维系统发送车辆运维指令;
所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果向所述车辆信息发布系统发送显示指令;
所述车辆智能座舱控制域根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述客户终端发送车辆相关的实时信息。
进一步的,车辆调度系统包括:车辆信息管理单元、调度管理单元以及监控管理单元,所述车辆信息管理单元能够实时获取车辆管理网络中的各个车辆信息,所述调度管理单元能够根据车辆的调度指令对各个车辆进行调度管理,所述监控管理单元能够对各个车辆进行里程/油耗监控管理。
进一步的,设备运维系统包括设备感知单元、数据诊断单元以及运维决策单元;所述设备感知单元通过传感器网络获取设备运行信号,所述数据诊断单元通过对设备运行信号进行特征提取获取设备运行特征并进行预警诊断,运维决策单元能够对基于预警诊断确定设备运行状态信息并在异常时进行故障预警。
进一步的,车辆信息发布系统,包括:
所述电子路牌、车辆头牌、车辆腰牌、车辆尾牌,所述电子路牌设置于车辆停靠区域,所述车辆头牌设置于车辆的前端、所述车辆腰牌设置于车辆的中部、所述尾牌设置于车辆的后端。
进一步的,客户终端包括车载POS机、客流仪以及语音报站设备。
进一步的,所述车辆行车驾驶控制域包括:车辆自动驾驶域、车辆动力域、车身域、车辆底盘域。
所述车辆自动驾驶域包括车载环境感知单元,所述车载环境感知单元能够实时采集行车环境感知数据,并通过所述中央控制器将当前时刻的所述行车环境感知数据发送至路端中转控制系统,所述路端中转控制系统的数量为多个,各路端中转控制系统均匀设置在城市道路的道路边缘。
进一步的,所述路端中转控制系统包括路端通信单元、认证单元、第一路端感知单元、第二路端感知单元以及路端控制单元;所述路端通信单元能够实时接收车载环境感知单元发送的行车环境感知数据并在身份认证通过时,将所述行车环境感知数据发送至第一路端感知单元;所述认证单元能够自动提取所述路端通信单元接收到的所述行车环境感知数据并获取对应的合法用户编码以确定是否是合法用户,是则分别向路端通信单元以及路端控制单元发送合法用户通知即身份认证通过;所述第一路端感知单元能够接收行车环境感知数据,并判断当前的客运车辆是否属于第一感知限制状态,是则基于路端行车策略获取第一行车控制数据并发送至路端控制单元;所述第二路端感知单元能够获取第二行车控制数据并发送至路端控制单元;所述路端控制单元能够在身份认证通过时,提取所述合法用户编码,并为所述合法用户编码配置独立的数据处理运行环境,同时在所述数据处理运行环境下,基于第一行车控制数据、第二行车控制数据形成所述合法用户编码对应的行车控制数据,并通过路端通信单元分别向所述中央控制器、云平台发送。
进一步的,所述第一感知限制状态是指行车安全隐患状态,包括但不限于相邻车道存在障碍物和或客运车辆前进方向存在障碍物,使得在客运车辆的行车视域范围内不能获得完整的客运车辆行车安全数据包;所述路端行车策略包括若处于第一感知限制状态时,获取路侧监测设备内的检测数据并形成第一行车控制数据;若出于非第一感知限制状态时,直接获取行车环境感知数据并形成第一行车控制数据。
进一步的,所述第二路端感知单元能够与路侧监测设备通信,获取客运车辆前进方向一定范围内的道路信息,并形成第二行车控制数据发送至路端控制单元;所述道路信息至少包括道路拥堵数据。
进一步的,所述道路信息还包括路面本体状态数据以及路面气象信息。
进一步的,所述路端中转控制系统还包括路端运维监测单元,所述路端运维监测单元能够在路端控制单元处于闲时状态时,与中央控制器进行通信,用于获取车端传感器网络所获取的设备运行信号,并对设备运行信号进行特征提取,获取设备运行特征并进行预警诊断,同时能够对基于预警诊断结果确定设备运行状态是否异常并进行故障预警。
进一步的,所述路端运维监测单元包括数据处理模块、数据分析模块以及运维决策模块;所述数据处理模块用于对设备运行信号中的运行日志数据进行清洗和标准化处理;所述数据分析模块用于基于处理后的运行日志数据并进行特征提取以获取对应的设备运行特征数据;所述运维决策模块用于根据所述设备运行特征进行预警诊断即确定设备运行特征的异常度,同时能够对基于预警诊断结果确定设备运行状态是否异常并进行故障预警。
进一步的,所述中央控制器通过CAN总线和以太网向车辆自动驾驶控制域发送控制指令,所述控制指令同步备份至云平台/数据存储器;
所述车辆行车驾驶控制域接收所述车辆智能座舱控制域发送的控制指令,对所属控制指令进行解析(安全等级预测,安全限值)后,根据所述控制指令控制车辆的行驶中的驱动、制动、转向功能。
进一步的,基于车辆智能座舱控制域接收多个车辆信息采集设备(所述采集设备之间具备网关的协议转换功能)上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果通过CAN总线和以太网向车辆行车驾驶控制域发送控制指令,所述控制指令同步备份至数据存储器;
通过车辆行车驾驶控制域接收所述车辆智能座舱控制域发送的控制指令,对所属控制指令进行解析(安全等级预测,安全限值)后,根据所述控制指令控制车辆的行驶中的驱动、制动、转向功能。
进一步的,根据运算结果向所述车辆调度系统发送车辆的调度指令包括:
获取目标区域的客流信息;所述客流信息包括乘客数量、每一乘客对应的目的地和预乘车时间;
根据所述客流信息确定出预计调度信息,所述预计调度信息包括每一目的地对应的可调度公交类型和数量;
根据所述预计调度信息,确定出调度方案;所述调度方案用于形成调度指令。
进一步的,根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述设备运维系统发送车辆运维指令包括:
获取车辆信息采集设备上报的信息中的故障事件信息,故障事件信息包括:故障区域的标识及故障区域的定位位置;
根据故障区域的定位位置获取标识对应的故障区域的车辆运维指令;
所述设备运维系统接收车辆运维指令并根据车辆运维指令发出告警响应(能够使运维人员快速定位出故障区域)。
进一步的,车辆信息管理单元基于通讯定位技术获取并实时记录车辆行车状态以实现公交系统的智能化运营管理,最大限度地优化公交系统的运行,所述车辆行车状态至少包括车况数据、定位信息、到站信息、视频监控、营运记录、行驶记录数据。
进一步的,所述通讯定位技术至少包括GPS/北斗定位技术、网络通信技术、物联网技术。
进一步的,根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述车辆信息发布系统发送显示指令包括:
车辆运行到指定位置(距离电子路牌一定距离)车辆信息采集设备向中央控制器自身标识信号(识别该辆车的线路号、车序号)、车辆位置以及速度,
中央控制器根据收到的自身标识信号、车辆位置以及速度确定出相应的到达站点和到站时间形成显示指令并向到达站点的车辆信息发布系统发送,以使其显示相应公交车的线路号、车序号、当前的到达站点、到站时间。
本发明提供了一种包括所述客运车辆的双域电子架构的客运车辆,其特征在于,包括:整车车身以及能够对整车车身进行集中控制的双域电子结构。
有益效果:本发明提供了一种新型的车辆智能化的电子架构形式以满足自动驾驶控制需求,其通过形成自动驾驶场景下和云平台深度协同的车载集控系统,加强了客运车辆的行车安全、提高了服务质量、降低了系统成本;并通过双域结构的域控制器架构实现了各个域控制器的密切协同,同时满足车辆有效实现环境感知、运动规划、任务决策、车辆控制等自动驾驶功能的融合,进而能够和平台进行业务的深度融合和全场景联动。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图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是本发明所述路端中转控制系统框架图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
如图30所示,本实施例提供了一种客运车辆的双域电子电气架构,包括:
车辆智能座舱控制域、车辆行驶控制域、中央控制器和云平台;其中,所述车辆智能座舱控制域用于接收多个车辆信息采集设备上传的信息,所述多个采集设备之间具备网关的协议转换功能,所述信息为车辆智能座舱控制域多维数据;
所述车辆行驶参数域接收车辆行驶执行结构的参数,所述车辆行驶执行结构的参数为车辆行驶多维数据,所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果获取车辆行驶的控制实施流程以及车辆行驶的控制或操作指示。
优选的,所述车辆智能座舱控制域的多维数据包括但不限于以下数据:车载视频监控数据、手咪数据、语音播放数据、高精度定位数据、按键输入数据、客流监视数据、车载OBU数据、车载POS数据、路牌数据、以太网数据、CAN总线通信数据以及无线网络通信数据等;
优选的,所述车辆行驶多维数据包括但不限于以下数据:
动力域数据(电机总成数据、电池总成数据以及电控总成数据)、车身域数据(灯光、雨刷、门窗、视镜、座椅等控制数据)、底盘域数据(传动系统控制数据、制动系统控制数据以及转向系统控制数据)以及自动驾驶域数据(环境感知数据(如雷达、摄像头)、数据处理数据、通信数据的等)。
优选的,所述车辆行驶执行结构包括但不限于车辆发动机、变速箱、安全气囊等各底层执行结构。
优选的,所述智能座舱构成主要包括全液晶仪表、大屏中控系统、车载信息娱乐系统、抬头显示系统、流媒体后视镜等设备。
同时通过智能座舱域控制器,整合座舱电子部件以及智能驾驶ADAS系统和车联网V2X系统等系统,实现自主的“独立感知”和“交互方式升级”能力。例如,可以智能座舱域控制器通过以太网/MOST/CAN,实现抬头显示、仪表盘、导航等部件的融合控制。
进一步的实施例:
本实施例客运车辆的双域电子电气架构的核心设计点是包括两个域,车辆智能座舱控制域和车辆自动驾驶控制域,其中,车辆智能座舱控制域包括车辆智能座舱域控制器,所述车辆智能座舱域控制器具有超高算力的系统级SoC芯片单元、通信单元(4G/5G)、高精度定位单元、车辆CAN总线单元、图像识别单元等并结合人工智能算法等先进技术形成高集成、高处理性能、高智能等性能的域控制器。优选的所述高集成性能是指集数据采集、智能计算、集中控制、多屏显示等多功能于一体;所述高处理性能是指人、车、路立体式信息交互下高速数据处理;所述高智能性能是指智能调度、智能监控、智能告警等全场景人工智能服务等设计特点。
优选的,智能座舱域控制器还可以将仪表和智能中控设备进行融合。由于仪表和智能中控设备是基于不同操作系统开发的,不同的操作系统和功能需求对算力、功能安全等级、信息安全等级和实施性要求不尽相同。为提升仪表的可靠性,采用Hypervisor等虚拟化技术,实现当智能中控操作系统出现故障时仪表仍能正常显示,保障驾驶的安全性。
进一步优选的,所述智能中控设备可以为智能座舱域提供具备丰富的娱乐和辅助功能,如可以导航、多媒体、天气、蓝牙电话、车辆控制、车况查询、设置、用户管理等多种类型的功能。还能够提供个性化服务,如语音控制,实现可见即可说。上电后,智能中控设备主动将天气、油量、电量、气量等车辆相关信息主动播报给驾驶员,提升驾驶的舒适性。同时用户可以通过语音交互,实现空调的开关、导航、灯光的开关等功能,减少用户的手动操作。同时也可以考虑定制节日推送服务,如在智能座舱系统的软件设计中,考设计中国传统节假日如春节皮肤,并通过后台对用户进行推送。用户可以自行选择喜欢的皮肤并进行更新,提升用户的满意度。
同时所述车辆行车驾驶控制域包括与车辆行驶密切协同的自动驾驶域、动力域、车身域、底盘域等,用于所述车辆行车驾驶控制域和中央控制器进行公交业务的深度融合和全场景联动。
具体的,如图1所示,在本案所述的实施例中车辆智能座舱控制域优选包含智能座舱域控制器和数据存储器两个部分。
其中,作为智能座舱域控制器部分具有以下功能区:
1、通过内置的智能AI算法形成若干功能区域,具体包含ADAS功能、DMS功能、360环视及BSD功能等。
2、架构视频监控功能,所述视频监控功能最多可支持14路视频监控,其中包括DMS和ADAS摄像头,例如可设置4路车外摄像头,8路车内监控摄像头。
3、架构喇叭功能区域,所述功能区域可以形成几个分区,如车内喇叭,车外喇叭,司机喇叭以及显示屏喇叭功能区域等。
4、架构手咪功能区域:
5、架构高精度定位功能区域,同时可以通过RS232连接外部定位设备,实现普通定位或高精度定位功能。
6、架构按键功能区域,通过RS232连接外部物理按键,实现按键操作功能。
7、架构客流监视功能区域,通过以太网实现外接客流仪实现客流监测功能。
8、架构多屏显示功能区域,如在本实施例中可以形成支持2+4智慧LCD多屏显示功能,其中“2”为两块12.3寸屏,一个为仪表屏,一个为调度屏;“4”为4块AHD方式LCD屏,进而实现LCD电子路牌相关功能。
9、架构车载OBU设备功能区域,通过RS232连接外部车载OBU设备,实现近距离通信功能。
10、架构车载POS设备功能区域,通过RS485连接车载POS设备,实现车载收费等相关功能。
11、架构电子LED路牌功能区域,通过RS485连接电子LED路牌,实现LED路牌显示功能。
12、架构千兆以太网功能区域,具有2路千兆以太网,其中一路千兆以太网连接自动驾驶域控制器实现与自动驾驶域连接,一路千兆以太网连接数据存储器实现数据的存储。
13、架构CAN总线通信功能区域,具有6路CAN总线通信能力。一路为仪表内网CAN总线,支持与前电控模块和后电控模块进行组网实现电控模块相关功能,并支持连接倒车雷达实现倒车雷达功能;剩余五路CAN总线分别接入车辆动力CAN,车身CAN,底盘CAN,能量管理CAN和车载终端CAN,用于实现仪表功能、车身管理功能和CAN网关转发等功能等。
14、架构支持4G/5G无线网络通信区域,如可支持eSIM卡贴装和SIM卡外部插装方式,实现与中央控制器等数据中心的数据交互。
其中,作为数据存储器部分具有以下功能区:
1、如通过以太网(千兆以太网)实现与智能座舱域控制器的连接,实现智能座舱域控制器部分相关数据的存储,即完成基本存储功能。
2、具有存储容量扩展功能,如可支持3.5寸大硬盘,其存储容量可根据实际情况选配。
3、通过以太网(百兆以太网)实现与行车记录仪的对接,完成行车记录数据的存储。
4、通过以太网(百兆以太网)实现与C-V2X设备对接,完成智能网联相关数据的存储。
5、通过以太网(百兆以太网)实现与LCD电子路牌屏对接,实现LCD电子路牌OTA远程升级存储等功能。
6、具有USB外接端口,可支持通过USB接口,实现灾备存储器功能,如行车记录仪已兼容灾备存储器功能,则无需单独外接灾备存储器。
7、同时也具有支持4G/5G无线网络通信的无线网络通信模块,且该模块支持eSIM卡贴装和SIM卡外部插装方式,实现与中央控制器的数据交互。
在具体实施例中,本实施例所述智能座舱域控制器(CDC1000)形成上述功能区域所对应的嵌入式软件设计构思对应的技术方案为:
如图2所示,本实施例的智能座舱域控制器内部的嵌入式软件主要分为MCU嵌入式软件和SOC嵌入式软件两个部分。
在MCU嵌入式软件部分:
通过MCU嵌入式软件形成嵌入式实时操作系统,该系统用于负责ms级快速响应并处理数据,处理结果能够在规定的时间之内控制生产过程或对处理系统做出快速响应,调度一切可利用的资源,完成实时任务的同时控制所有实时任务协调一致运行。
在上述设计思路基础上,本系统所述MCU软件具体包含Boot程序和App程序;其中MCU Boot程序为启动引导程序,MCU App主要有电源管理程序、状态管理程序、通信管理程序、升级管理程序、看门狗业务程序、参数存储程序、输出任务程序、输入任务程序、CAN总线程序等功能。同时还需具备App固件OTA升级功能。
在SOC嵌入式软件部分:
在本实施例中优选采用RK3588平台进行SOC嵌入式软件功能设计,同时采用XenHypervisor技术需要虚拟化出Domain0,Domain1和Domain2等3个操作系统,在本实施例的功能区域设计中,Domain0负责仪表系统功能,Domain1负责智能应用服务系统功能,Domain2负责IVI中控屏功能。
具体的,Domain0仪表功能的嵌入式软件由仪表中间件层软件和仪表应用层软件组成;所述仪表中间件层软件主要可提供GUI组件,投屏组件,信号组件等基础能力。仪表应用软件主要负责仪表界面的绘制,诊断界面的绘制以及仪表设置等功能。
具体的,Domain1所述的智能应用系统软件实现360环视功能,行车记录采集功能,音视频解码功能,四周全盲区BSD监测功能,ADAS功能和DMS功能等。
具体的,Domain2中所述的IVI中控屏可包括固件层,SDK层,中间件层与应用层组成,其中固件层提供设备固件驱动功能,SDK层负责驱动的适配和封装,并对Android系统电话,状态栏等进行定制,为中间件层提供基础能力;中间件层是核心层,为应用层提供统一的整体接入能力,各应用可通过标准的API接口,快速的集成升级,通信,参数管理,AI报警监听等各类功能;应用层作为人机交互的入口,根据应用一定的业务逻辑,借助中间件层,做到业务与功能的融合,同时基于上述设计构架说明,目前实施例所述的智达车载应用对应的APP包括但不限于:公交调度APP、公交运维APP、车身管理APP、电子路牌APP、媒体屏APP、TBOX APP,并且也支持其他第三方APP快速接入。
在其中一个更具体实施例中,360环视功能的逻辑设计思路为:
首先、使得设备支持360环视功能,设备上电后,通过共用车身4个BSD摄像头,完成图像采集,之后通过对拍摄图像进行畸变矫正和无缝拼接处理后,形成车辆360环视视图。
其次、用户可通过视频直通功能查看任意视角360环视视图。
再次、当设备识别到倒车信号,将全屏显示360环视倒车视图。同时当设备识别到转向或者行人碰撞预警信号时,触发报警联动,显示对应的360环视视图。
在其中一个具体实施例中,所述的客运车辆的双域电子电气架构,还包括:前述各个域控制器还能通过中央控制器与车载应用平台实现协调联动运行;所述车载应用平台,其包括车辆调度系统、设备运维系统、车辆信息发布系统、客户终端等;
其中,所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果向所述车辆调度系统发送车辆的调度指令;
具体而言,本实施例的车载应用平台的车辆调度系统的调度管理单元包括:登录登出功能模块(登录后开启车辆的例检功能)、线路选择模块(切换线路、上下行切换、站点切换)、行车调度模块(发车通知、准点考核、调度申请、异常申请、紧急呼叫、任务查看、信息查看、运行可视化、报站、业务警告)。
其中,登录登出功能模块,该模块所能实现的功能包括登录支持刷卡,账号密码,刷码,人脸等多种方式。
由于登录作为司机上班的一项重要操作,有两重目的,一是实现准确的人车绑定,以便调度平台实现按车找人、人车对应,从而更准确地下发任务给对的车并且是对的人;二是为了给一些没有酒精测试一体设备的场站或者项目的提供车上考勤打卡的通道方式,从而可以在车机上实现考勤操作。登出作为司机下班的一项必须要完成的操作,对人机实施了解绑,同时起到考勤下班的作用。
因此如图3-4所示,登录登出功能模块对应的登录流程具体如下。
触发条件:司机按键或刷卡触发登录操作。输入方式:刷卡,输入账号密码,刷码,人脸等任意一种方式。输出方式:跳转到登录成功或失败的界面或提示。
在后台处理过程中:登录后开启车辆的例检功能。如图5-6,车辆例检分为“发车例检”和“收车例检”。司机在登录后依据本地运维配置决定是否要在车机上进行发车例检,由司机现场提交的例检异常选项,经app对比关键项列表判断是否可以参与运营,并上报云平台。
在具体实施过程中,是否需要例检、例检项及例检关键项第一阶段由本地代码固定一版规则,后续由云平台以文件或协议的形式下发配置参数,设备根据配置参数进行对应功能实现,当设备没有收到平台的配置参数时,以默认配置参数执行,平台下发配置参数均会同步更新默认配置参数,保证按上次配置执行例检。
如图4所示的登出流程图,司机在登出app之前要提交如图6所示的“收车例检”例检异常选项,app对比关键项列表作出判断,并将结果上报平台作为调度排班参考,收车例检不通过,司机可正常登出,只需将收车例检结果上报即可。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:登录后依据例检配置项判断,判断结果要求对该车进行例检。对应的性能要求:例检结果判定毫秒级完成。
则相应的输入信息为:例检项文件提供的所有例检项及关键项数据;司机根据现场车辆实际情况勾选的异常例检项数据。输出信息为:车辆能否正常参与运营,例检结果及例检数据上传中央控制器;例检结论UI展示与提醒。
所述线路选择模块的线路选择功能逻辑思路为:线路选择工作流程:
调度App启动时向报站模块(如图19)注册线路改变监听,线路改变时报站模块通过该监听回调给调度App,调度App收到回调后更新线路。
调度App启动时向报站模块注册上下行改变监听,上下行改变时报站模块通过该监听回调给调度App,调度App收到回调后更新上下行。
调度App启动时向报站模块注册站点改变监听,站点改变时报站模块通过该监听回调给调度App,调度App收到回调后更新站点。
调度App注册发车通知回调,收到发车通知后会触发。
调度App先检查是否有发车通知,如果有,显示发车通知线路,如果没有,检查是否有运营线路记录,如果有,显示运营线路记录线路,如果没有,向报站模块请求线路列表,取列表首线路,显示线路。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:调度App报站启动。输入信息:线路号和方向。输出信息:线路信息。
所述线路选择对应的功能包括切换线路、上下行切换以及站点切换,如图16-17,具体内容如下:
其中,切换线路功能对应的逻辑思路为:
调度App启动时向报站模块注册线路改变监听,线路改变时报站模块通过该监听回调给调度App,调度App收到回调后更新线路。
切换线路分为自动切换线路和手动切换线路:自动切换线路:自动切换线路由中央控制器下发的发车通知自动触发。手动切换线路:手动切换线路为调度App相关页面元素点击手动触发。
同时切换线路时,综合考虑当前运营状态,具体的包括:
如果运营状态是异常状态,提示是否退出异常状态,退出后可执行切换线路。
如果运营状态是运行状态,提示是否结束运行任务,结束后可执行切换线路。
如果运营状态是就绪状态,可直接执行切换线路。
执行切换线路的具体步骤包括:向报站模块请求切换线路,报站模块切换线路后通过线路改变回调给调度App,并且同步线路信息给外设模块,调度App收到回调后更新线路。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:发车通知自动触发、手动触发切换线路;输入信息:线路号和方向;输出信息:线路信息。
同时执行切换线路还包括切换方向步骤:
具体的逻辑步骤为:向报站模块请求切换方向,报站模块切换后通过方向改变回调给调度App,并且同步线路信息给外设模块,调度App收到回调后更新方向。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:报站模块自动触发、发车通知自动切换触发、手动触发切换上下行。输入信息:方向。输出信息:线路列表。
其中,切换上下行功能对应的逻辑思路为:如图17所示;调度App启动时向报站模块注册方向改变监听,方向改变时报站模块通过该监听回调给调度App,调度App收到回调后更新线路方向。
同时考虑切换方向的模式不同,所述切换模式分为自动切换和手动切换:
若采用自动切换:自动切换方向由平台下发的发车通知自动触发或由报站算法自动换向触发。
若采用手动切换:手动切换为调度App相关页面元素点击方向手动触发。
在更具体的实施例中,考虑切换方向的模式不同的同时还考虑切换上下行运营方向,具体包括:
在支持手动切换上下行模式下;如果手动切换完上下行后,不自动切换上下行;如果未手动切换完上下行后,可以自动切换上下行;
同时需要注意的是:
行驶过程中,发现运营方向不对,要自动切换到正确的上下行,但是需要经过2个连续反向站点才切换;
为了解决上述问题,可以通过设置智能化的报站算法解决以上问题:
具体实施案例:
假定按照线路行驶,报站顺序错误问题,如:专80路,问题报站顺序是4、12、5,智能化的报站算法报站顺序为4、5。
智能化的报站算法解决方案的核心思路为:优先报预期站点进站;非预期站点报站条件严苛,使用报站半径的一半来判断。
其中,站点切换功能对应的逻辑思路为:
调度App启动时注册站点改变监听,站点改变时报站模块通过该监听回调给调度App,调度App收到回调后更新站点。
同时针对变站的不同形式,设置不同的逻辑,具体的变站分为自动变站和手动变站(加减站、跳站):
若为自动变站:自动变站由报站模块自动触发。
若为手动变站:手动变站为调度App相关页面元素点击手动触发或通过小键盘按键手动触发。
同时针对变站时当前运营状态的不同形式,设置不同的逻辑,
如果运营状态是异常状态,提示是否退出异常状态,退出后可执行变站。
如果运营状态是就绪/运行状态,可直接执行变站。
所述执行变站的具体过程为:
自动变站:报站模块自动变站后通过站点改变回调给调度App,并且同步站点信息给外设模块,调度App收到回调后更新站点。
手动变站:向报站模块请求变站,报站模块变站后通过站点改变回调给调度App,并且同步站点信息给外设模块,调度App收到回调后更新站点。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:报站模块自动触发、手动触发变站。输入信息:站号。输出信息:站点列表。
所述行车调度模块能够实现如下功能,具体包括发车通知、准点考核、调度申请、异常申请、紧急呼叫、任务查看、信息查看、运行可视化、报站以及业务警告等,具体内容如下。
其中,发车通知功能对应的逻辑思路为:
由于车辆和司机参与运营的核心依据,决定着车辆和司机执行的任务类型以及具体的任务内容,则发车通知功能主要为了实现依调度安排从调度平台下发到车机的行车任务,其具体包含运营任务和非运营任务。
其中运营任务发车通知包含线路信息,始发时间终到时间,以及对应司机等运营信息;非运营任务发车通知主要指加油加汽等非运营任务或临时任务。
基于上述设计思路,则本案发车通知的逻辑架构过程为:
发车通知由中央控制器下发,收到发车通知及时进行播报以便提醒司机,结合车机当前的运行状态(就绪、异常申请、执行中)决定是否要立即使用收到的发车通知,原则上车机处于任务执行中暂存收到的新发车通知,待执行中的任务完成之后再使用收到的发车通知。
本案发车通知的应用层架构为就发车通知而言,app主要与中间件的808模块进行数据交互,808模块及其他中间件库负责发车通知的接收解析并转发给app进行业务使用。
具体的:发车通知指定的线路在本地存在两种情况:本地线路文件不存在;线路文件版本不正常。App判断确认以上两种情况后向升级模块同步线路升级下载需求,同时提示相关缺失信息,展示文件升级下载动画状态。App收到升级下载完成回调后再次向报站模块发起线路列表信息请求获取到最新的线路列表,并再次尝试匹配使用发车通知。
发车通知本地进行重复提醒播报机制,通常情况下,发车前5分钟,1分钟,发车时间点均需进行对应的文字和声音提醒,同时超过发车时间3分钟,5分钟还未发车的也需要进行文字和声音提醒。收到新的发车通知或超时后司机主动关闭提醒弹窗,则停止提醒。同时基于图7所示,对于非常规线路的发车通知,APP应能接受对应任务,并根据任务内容进行信息展示。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:云平台主动下发发车通知指令及内容到终端,终端被动接收。输入信息:将要执行的运营任务或非运营任务,及对应任务的执行开始、结束时间、执行人信息。输出信息:任务数据决定运营线路、方向;任务执行人与App登录人是否匹配;播报任务内容;在本地存储发车通知记录。同时设置特殊要求:当发车通知车辆号与当前车辆号不一致时,应引导客户进行使用本车或换车申请。
其中,如图8,准点考核对应的逻辑思路为:
一般随发车通知之后下发准点考核信息,主要包含考核点及对应的考核时间标准列表数据。车辆运营到考核站点时由app根据考核时间标准来计算到达该点的相对快慢成绩,将成绩记录、提交并展示给司机,供司机和调度平台作为运营参考、调整车速、调整调度排班信息等。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:报站模块通知报站事件。输入信息:云平台下发准点考核标准;报站模块通知报站事件;输出信息:UI展示准点考核成绩;向平台上报该考核点考核成绩。
其中,调度申请功能对应的逻辑思路为:
如图9所示,车端参与调度运营的一种手段,主动反馈车辆或司机运营现场的大致信息给调度平台,从而影响现有的排班调整或未来新的排班任务安排,使调度工作更灵活准确,及时反馈和处理调度问题。
其一般由车端司机主动发起,主要分为:1、普通调度申请;2、异常申请;3、紧急呼叫;
具体的逻辑架构为调度申请以车机使用者主动触发开始,经中间件808模块以文本信息--短信的方式上报平台相应申请内容,调度平台依据上报信息采取直接沟通或者调整调度安排等方式予以响应,发出的申请可在信息查看,已发消息中查看。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:司机根据现场情况手动选取触发各项调度申请选项。输入信息:调度平台提供运营过程中各种与调度有关的调度申请项;司机结合现场情况选择触发调度申请项;输出信息:经中间层808模块向平台发起相应调度申请短信;UI展示调度申请是否成功的结果。
其中,异常申请功能对应的逻辑思路为:
由于车端参与调度运营的一种手段,主动反馈车辆或司机运营现场的大致信息给调度平台,从而影响现有的排班调整或未来新的排班任务安排,使调度工作更灵活准确,及时反馈和处理调度问题。
因此,其由车端司机主动发起,主要分:1、普通调度申请;2、异常申请;3、紧急呼叫;
具体的逻辑架构为所述异常申请以车机使用者主动触发开始,经中间件808模块以文本信息--短信的方式上报平台相应申请内容,调度平台依据上报信息采取直接沟通或者调整调度安排等方式予以响应。
需要说明的是,如图10所示,不同于普通调度申请,异常申请一般指无法继续运营的情况才会使用,具体场景如事故、故障、纠纷等,提交异常申请时app状态即进入异常申请状态,状态不改变的情况下无法进行运营,此状态有针对性app界面和展示信息。如何继续运营?只有手动退出了异常申请状态,app认为车机可能经过维修等处理恢复了正常,之后提供就绪状态响应新的发车通知任务。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:司机根据现场异常情况手动选取触发相对应的各项异常申请选项。
输入信息:调度平台提供运营过程中各种与调度有关的异常申请项;司机结合现场情况选择触发异常申请;
输出信息:经中间层808模块向平台发起相应异常申请短信;UI展示调度申请是否成功;将当前运营状态改变为异常状态,显示车辆异常界面,司机与调度沟通后,可恢复或中止任务。
其中,紧急呼叫功能对应的逻辑思路为:
如图11所示,车端参与调度运营的一种手段,主动反馈车辆或司机运营现场的大致信息给调度平台,从而影响现有的排班调整或未来新的排班任务安排,使调度工作更灵活准确,及时反馈和处理调度问题。
具体的逻辑架构为紧急呼叫,提供网络IP对讲功能,作为一个相对独立的子功能提供给运营过程中众多可能的节点,供司机主动触发建立与调度平台的及时沟通渠道。IP对讲需要由中间件808模块参与建立与指定IP+PORT建立网络双向通讯,再结合手咪和喇叭等外设建立起对讲环境。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:司机主动触发,经调度平台同意建立通话;调度平台主动发起,司机被动加入通话。
输入信息:中间层808模块回调通知紧急呼叫链路已建立;
输出信息:UI展示通话状态;司机可以与调度平台进行语音通话。
其中,如图12、任务查看功能对应的逻辑思路为:
供司机随时查询查看最新的调度平台排班计划,所谓排班即是未来一天的运营任务列表,对应发车通知,每项排班都会有预计始发终到时间、线路信息、司机信息等,以便司机了解自己的任务进度和具体任务信息。
排班信息随时可能有变化,每次查询都会重新获取最新的调度平台数据。
具体的逻辑架构为发车计划列表显示按运营时间排序并显示运营时间和任务类型,当司机查看当日排班计划时,如果已完成的任务会进行特殊标识。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:司机主动触发查看。可以筛选日期。输入信息:司机选择对应日期后,通过808模块请求对应日期排班数据。输出信息:向司机展示各排班信息。
其中,如图13、信息查看功能对应的逻辑思路为:
根据实际运营需要,调度平台会下发各类文本消息给车机,主要目的是向司机发布运营提醒或者组织内部公告,车机负责接收并播报短信以便将信息传达给司机。
具体的逻辑架构为根据重要程度划分为两种:1、需要司机确认;2、不需要确认。结合相关项目地配置信息决定是否提供app交互确认的功能。但不论哪种短信,收到后App通常会进行UI显示和语音播报,具体由消息协议而定,短信可由平台控制是否需要确认,是否需要报读,显示时长,是否联动电子路牌。
对于已接收的消息,如是需要确认,但未确认的消息,当司机点击确定后,需补传消息已读。基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:中央控制器下发文本消息。输入信息:中间层808模块回调通知收到新的文本消息;输出信息:UI展示文本消息内容及语音播报;文本消息记录保存至本地。
其中,运行可视化功能对应的逻辑思路为:
具体地,如图14所示,运行可视化的逻辑架构形式为:
1、采用离线地图,调度平台配置检测地图更新的开关,中央控制器打开开关后,设备端先检查离线地图数据是否存在更新,若有更新,则由高德定位相关API获取到定位城市名,拿到城市名称去下载最新的城市离线地图,下载离线地图过程中使用地图需要消耗流量,下载完成优先加载离线地图的数据。
2、设备应支持通过配置可实现多三方地图切换。以高德地图为例,先集成高德官方地图SDK,按照官方集成文档说明配置,根据我们的实际业务需求,先在地图中调API显示基础地图,根据车载定位模块实时获取到最新位置信息,调用绘制API将位置绘制到基础地图上,从报站模块里获取公交线路轨迹和站点,拐点等等信息的数据,从808协议模块里获取前后车距、实时路况信息、预计到达时间,调用绘制API将各项数据绘制到基础地图上。
3、切换线路,切换上下行需要重新加载地图。
4、地图作为选配功能,默认显示模拟图,对于支持地图的设备,司机可手动切换到地图显示模式,设备每次开机均已上次选中的模式启动。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:开机,根据上次选择的模式决定是否显示地图。输入信息:线路信息,发车通知内的考核点,停靠站点等信息。输出信息:基础地图,线路轨迹,定位,起点,终点,停靠点,安全点,拐点,前后车位置等等信息。
其中,报站功能对应的逻辑思路为:
如图18所示,报站模块的主要功能包括:解析报站文件,处理调度APP的各种业务请求,通知其他模块自动报站的到离站信息等。
报站模块的逻辑架构形式:接收升级模块的升级结束通知,或在开机后解析报站文件,缓存报站相关的各种数据,接收调度APP的各种业务请求并提供相关的报站数据,向自动报站模块提供必要的数据信息,获取车辆到离站等信息提供给调度APP。
基于上述设计思路,对应的实施例为:设置触发条件,上述过程中的触发条件为:
1、来自同级升级模块:升级结束通知;
2、来自同级自动报站模块:到离站、进出站、方向切换等信息;
3、来自应用层调度APP:获取线路列表、切换方向线路、手动加减站/跳站等;
输入信息包括:
1、同级升级模块:报站文件;
2、同级自动报站模块:运行方向、线路编号、到离站状态等;
3、应用层调度APP:当前线路、运行方向、站序号、服务语快捷键等;
输出信息包括:
1、同级升级模块:报站文件解析结果;
2、应用层调度APP:线路站点信息,车辆到离站信息,车辆运行方向;
同时在考虑应用场景具体情况,结合站点与站点、站点与轨迹应用场景分析结果,形成一定的最小颗粒度组合,共分为六大类,具体包括:
①连续两个站点;②非连续两个站点;③多段轨迹接近同方向站点;
④多段轨迹接近反方向站点;⑤轨迹经过反方向站点;⑥正常情况6条;
每类再进行细分形成智能化的报站算法,对应的逻辑思路为:
第一类的逻辑思路为:
(1)自动报站规则的输入和输出:
设定报站文件:1)指定线路;2)站点列表;3)站点序号;4)站点上下行方向;5)站点经度;6)站点纬度;7)报站半径;8)站点方向角;
设定GPS数据:1)经度;2)纬度;3)方向角;4)速度;5)时间戳;
(2)对线路维度进行处理:
(3)设定站点和站点,站点轨迹维度:
①线路文件所有站点限定范围:
·限定线路所有站点在指定的“矩形”范围内(RectA);
·不在限定范围内的GPS数据,不参与报站逻辑的判断;
·右上GPS1坐标确定,所有站点最右侧和最上面的最大值,在此基础上加上3倍报站半径对应距离的经纬度偏差值。
·左下GPS2坐标确定,所有站点最左侧和最下面的最小值,在此基础上减去3倍报站半径对应距离的经纬度偏差值。
②线路按站点划分若干小范围:
·站序相邻站点划为指定的“矩形”范围内(RectBx)。
·右上GPS坐标确定,两个站点最右侧和最上面的最大值,在此基础上加上3倍报站半径对应距离的经纬度偏差值。
·左下GPS坐标确定,两个站点最左侧和最下面的最小值,在此基础上减去3倍报站半径对应距离的经纬度偏差值。
③自动报站:分为如下几个情况:
常规情况:没有站点重叠的情况,GPS轨迹满足进站报站半径且方向角在站点方向角的正负45度范围内,则报进站;在已报进站的情况下,GPS满足在报站半径范围外,则报离站;
连读站点重叠:两个站点有重叠情况,且两个站点的方向角接近,即满足阈值,A站进站后,还未离开A站即检测到B站进站,先报A离站,再报B进站;
非连续站点重叠:两个不连续的重叠站点,且两个站点的的方向角接近,即满足阈值;目前在F80及F2等线路发现,两个站点分别在上行和下行方向中,该线路属于环线对发线路,逻辑只处理单向站点即可解决;
非连续站点重合:两个不连续的重合站点,且两个站点的的方向角接近,即满足阈值;其中A站、B站有一个是预期站点,通过预期站点优先原则以及非预期站点的报站半径减半原则正常报站。
④自动换向:
·非起点终点站的运营方向切换,在运营中途连续经过两个反向站点切换运营方向。
·起点终点站运营方向切换:
⑤设定如图20的自动报站逻辑流程;
上述自动报站算法的特点:
其一引入RectA,实现GPS数据过滤的基础功能,识别GPS数据是否为逻辑依赖的有效数据。
其二引入RectBx,实现快速识别GPS数据是否在预期站点范围内;快速识别在其他某个临时预期站点范围内;GPS在某个RectBx内,这个RectBx内的站点比其他RectBx内的站点权重更高。
引入预期站点的方式,即正常行驶应当驶入的站点。
同时车辆驶入非预期站点,判断条件比到达预期站点要严苛。若为非预期站点,运营方向相同且方向角符合,GPS数据与站点坐标的距离与报站半径的一半对比,符合则报进站;运营方向相反且方向角符合,GPS数据与站点坐标的距离与报站半径的一半对比,符合则记录一次反向站点,下次还是反向站点则报进站且切换运营方向。
最近已报站的那个站点不会再报站。
离站时,满足其关联站点进站条件,则提前报当前站离站。
同时考虑异常情况的处理流程,具体参见下表:
/>
/>
其中,还可以考虑设置业务告警,该功能对应的逻辑思路为:
首先在【IVI应用层】实现报警事件声光提示功能:
调度app初始化完成以后,在主activity里注册报警配置信息改变监听,同时从参数模块里读取最新的报警配置信息,注册报警回调监听,调报警初始化接口和报警事件接口后通过callback回调返回报警事件的完整信息,报警会产生联动,一部分联动内容由对应报警模块内部处理,如OSD叠加,录像存储,视频抓拍,日志存储,报警IO输出,同时需通过808模块完成平台的上报;另一部分联动内容如视频,语音播报,文言提示由上层应用处理,具体报警事件对应的声光提示情况如下,其中视频联动,除了常规视频外,还支持360环视视频:
/>
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:超速报警:行车速度超过某一个临界值就触发;
信号报警:行车时左转,右转,倒车,车门开关,进离站即触发;
ADAS/DMS/BSD/SC:智能摄像头捕捉实际场景,通过AI算法推算达到报警条件即触发;
性能要求:报警事件要实时响应,联动延迟在1s之内。
输入信息:报警回调。
输出信息:报警联动内容如视频,语音播报,文言提示。具体的处理过程,如图21。
其次、在【仪表应用层】实现报警事件声光提示功能,如图22:
仪表的声光报警数据来源包括两部分,分别是CAN数据和AI报警数据。经过CAN原始数据解析和AI算法报警数据转换,数据计算和逻辑运算,分别向喇叭和仪表屏输出声音报警和画面报警信息。
AI报警信息如下:
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:CAN报警信号满足上述表格条件或AI报警信号满足上述表格条件。性能要求:
报警事件要实时响应,联动延迟在10ms之内。
输入信息:CAN数据和AI报警信号。
输出信息:按照上述表格规则进行声光报警。具体的过程处理如图23;
再次、如图24,设置报警机能模块:该模块为车机端全部的报警集合模块,对应的逻辑思路为包括:AI类报警,速度及各类开关量信号报警,视频遮挡报警。还包括集成引入更多报警能力,如:滞站,甩站,偏航预警等。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:来自同级CAN模块:左右转、刹车;
1、来自同级报站业务模块:进出站信息;
2、来自中央控制器能力层:视频信号、AI信号、速度值、IO信号(倒车、车门开关,一键报警开关信号);
性能要求:
报警事件要实时响应,联动延迟在1s之内。
一键报警信号触发3S后,向后台上报报警信息,并上传相关视频。
特殊要求:
速度报警包括超速和低速报警,超速持续时间可配置,范围0~255秒,默认为0。
输入信息:
1、同级参数管理模块:报警条件参数配置(超速持续时间、滞站、甩站规则参数等)、报警联动项参数配置;
2、同级报站业务模块:限速值;
3、应用层调度APP:运营状态;
输出信息:
1、同级网络模块:报警事件、附件上送;
2、应用层调度APP:画面及语音报警事件联动;
3、平台能力层:IO输出、录像存储、图片抓拍、日志存储、OSD叠加报警联动;
具体的处理过程:
根据输入各项做报警稽查前置条件准备,当触发条件各项任意发生时,报警稽查捕捉到报警信息,进行报警上送及报警联动输出。
基于上述思路,通过对系统运行状态可视化实现系统异常智能告警以通过智能告警让异常的发现和通知更加准确及时。
同时本发明公开的客运车辆的双域电子电气架构工作方法,还包括根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述设备运维系统发送车辆运维指令;具体包括:
获取车辆信息采集设备上报的信息中的故障事件信息,故障事件信息包括:故障区域的标识及故障区域的定位位置;根据故障区域的定位位置(所述位置为系统为每个故障区域预先配置的位置编码)在预设的故障维修数据库内查找并获取标识对应的故障区域的车辆运维指令;所述设备运维系统接收车辆运维指令并根据车辆运维指令发出告警响应(能够使运维人员快速定位出故障区域)。
同时客运车辆的双域电子电气架构的设备运维系统,包括设备感知单元、数据诊断单元以及运维决策单元;所述设备感知单元通过传感器网络获取设备运行信号;优选的,传感器网络内各个传感器监测位置按照以车辆故障维修的区域或者区域的关键位置设定,如发动机区域,由于发动机的故障特征需要重点监测仪表车速、加速踏板行程值、瞬时发动机转速、冷却液温度、机油压力和机油温度等,因此其关键位置可以细分为加速踏板、冷却管路等,以实际使用监测需求为准即可;所述数据诊断单元基于故障预测算法通过对设备运行信号进行特征提取并进行故障预警诊断,所述故障预测算法包括但不限于小波变换算法、Hilbert-Huang变换算法、故障树分析算法、神经网络算法等;运维决策单元能够对基于预警诊断确定设备运行状态信息并在异常时进行故障预警。
客户终端包括车载POS机、客流仪以及语音报站设备。
另,所述智能座舱域控制器还集成有乘客信息服务功能:
该功能对应的逻辑思路为:调度app在接收平台的服务用语等信息后或司机触发服务用语播报快捷按键,需根据参数进行语音播报,同时同步信息到各电子路牌显示。
另,司机也可通过手咪实现车内外喊话,手咪的喊话方式,开启和关闭调度app均在页面有提醒。喊话时其他同通道音频输出优先级靠后,喊话优先级最高。提供整机网络通讯服务,同平台侧进行双向通讯。
进一步地,所述中央控制器通过CAN总线和以太网向车辆自动驾驶控制域发送控制指令,所述控制指令同步备份至云平台以及数据存储器;
所述车辆自动驾驶控制域接收所述车辆智能座舱控制域发送的控制指令,对所属控制指令进行解析(安全等级预测,安全限值)后,根据所述控制指令控制车辆的行驶中的驱动、制动、转向功能。
形成控制指令的具体逻辑思路架构过程包括:
其中,【网络通讯模块】的中间层的网络业务,
具体的网络业务包括:信令链路的维护功能、信令数据项的解析、封装功能、上送信令帧头组装功能、下行信令的数据段提取功能、注册鉴权功能、信令链路心跳保持功能、定位数据周期上报功能、上行通用应答功能、上送信令重传功能、上送信令补传功能、媒体链路维护功能、上行多媒体数据帧头组装功能、下行多媒体数据段提取功能、下行多媒体信令业务处理功能等。
其中,信令链路的维护功能对应的逻辑思路为:
使得其具备对808信令链路的创建、销毁、重连功能。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:
1、系统启动后创建808信令链路。
2、运维配置中的服务器参数发生改变时。
3、808信令链路连接中断时。
输出信息:808信令链路的连接状态。
性能要求:
实时监测链路状态,对链路的异常进行重连处理。
具体的处理过程:
系统启动后,依据运维配置中的主备服务器参数,轮询创建808信令链路。当主备服务器的参数发生变化时,销毁当前链路,重新创建链路。808信令链路中断时,进行链路的重连。
其中,信令数据项的解析、封装功能对应的逻辑思路为:
解析808各个信令的数据项中字段值;将信令结构体中的字段值封装成网络字节流。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:
1、收到平台下发的808信令。2、调用信令结构体的封装方法。
性能要求:
数据解析、封装准确。
输入信息:
1、经过校验、解转义、去除包头后的数据段。
2、信令的各个字段值。
输出信息:
1、对应各个信令的数据段的结构体。
2、信令数据段网络字节流。
具体的处理过程:
1、依据不同的消息ID,创建对应的信令对象,将字节流解析成对象属性值。
2、构造信令对象,装填属性值,调用封装方法生成网络字节流。
其中,上送信令帧头组装功能对应的逻辑思路为:
将数据段封装成可以上送808平台的数据帧。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:收到各个模块发来的信令数据段网络字节流。性能要求:数据封装准确。
输入信息:信令数据段网络字节流。
输出信息:上送808平台的数据帧。
具体的处理过程:
如果数据段为长包则进行分包处理,为每一包数据分配流水号,生成帧头,连接数据段,生成校验位,转义,封装标识位生成上送平台的数据帧。
其中,下行信令的数据段提取功能对应的逻辑思路为:
提取中央控制器下发的信令的数据段。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:收到中央控制器下发的数据帧。性能要求:数据准确。
输入信息:中央控制器下发的信令帧。
输出信息:数据段字节流。
具体的处理过程:
收到平台下发的数据帧后,校验、解转义数据,去除帧头,如果数据段为分包数据,则要接收各分包数据拼接数据段。
其中,注册鉴权功能对应的逻辑思路为:
完成与中央控制器的注册鉴权业务。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:信令链路连接成功。性能要求:数据准确。
输入信息:链路状态。
输出信息:注册鉴权信令。
具体的处理过程:与中央控制器的信令链路建立后,发送注册、鉴权信令。
其中,信令链路心跳保持功能对应的逻辑思路为:
周期发送心跳数据。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:信令链路连接成功。性能要求:数据准确。
输入信息:链路状态。
输出信息:心跳信令帧。
具体的处理过程:
当链路连接成功后,依据运维配置中的心跳周期参数,周期发送心跳帧。
其中,定位数据周期上报功能对应的逻辑思路为:
周期发送定位数据,通过运维APP可设置定位上传周期。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:信令链路连接成功。性能要求:数据准确。
输入信息:链路状态。
输出信息:定位数据信令帧。
具体的处理过程:
当链路连接成功后,依据运维配置中的定位数据上报周期参数,周期发送定位数据。
其中,上行通用应答功能对应的逻辑思路为:
为收到的每一条下行信令组织通用应答。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:收到下行信令。性能要求:数据准确。
输入信息:下行信令。
输出信息:通用应答数据帧。
具体的处理过程:
收到下行信令帧,进行数据校验,记录信令流水号,组织通用应答。
其中,上送信令重传功能对应的逻辑思路为:
对于未收到中央控制器通用回复的上送的信令按照重传机制进行重传。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:上送信令未收到回复超时。性能要求:数据准确。
输入信息:上送信令时间戳,系统时间。
输出信息:重传的信令。
具体的处理过程:
当信令上送后标记时间戳,如果超时未收到平台的回复,则进行一次重传,共重传3次,3次后放弃掉该条信令。
其中,上送信令补传功能对应的逻辑思路为:
对因为链路问题未上送的信令进行补传。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:
1、信令链路中断。
2、信令链路建立。
性能要求:数据准确。
输入信息:
1、链路状态。
2、要补传的信令
输出信息:磁盘文件。
具体的处理过程:
信令链路中断时要将上送的信令保存到磁盘,当链路恢复时读取保存的信令对其进行补传。
其中,媒体链路维护功能对应的逻辑思路为:
媒体联路的创建、销毁及数据IO。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:
1、平台下发的多媒体链路创建信令
2、其他模块调用多媒体链路创建接口。
性能要求:数据准确。
输入信息:
1、服务器参数。
2、IO数据源。
具体的处理过程:
依据服务器参数,创建媒体链路,记录链路状态,执行回调函数反馈链路状态,进行数据IO处理,完成后销毁链路。
其中,上行多媒体数据帧头组装功能对应的逻辑思路为:
将多媒体数据段封装成可以上送平台的数据帧。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:收到多媒体数据流。
性能要求:数据准确。
输入信息:多媒体数据流。
输出信息:上送平台的多媒体数据帧。
具体的处理过程:
将获取到的多媒体数据流按照1078协议封装成数据帧。
其中,下行多媒体数据段提取功能对应的逻辑思路为:
提取平台下发的多媒体数据帧的数据段。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:收到多媒体数据帧。
性能要求:数据准确。
输入信息:多媒体数据帧。
输出信息:多媒体数据段的字节流。
具体的处理过程:将中央控制器下发的多媒体数据帧去掉帧头,提取数据段字节流。
其中,下行多媒体信令业务处理功能对应的逻辑思路为:
808协议中多媒体部分的业务处理。
基于上述设计思路,对应的实施例为:设置触发条件,所述触发条件:收到中央控制器下发的808多媒体信令。
性能要求:数据准确。
输入信息:中央控制器下发的808多媒体信令。
输出信息:
1、上送的应答信令。
2、多媒体链路创建,数据IO。
具体的处理过程:
解析多媒体信令,组织应答信令,相应业务处理。
进一步地,车辆信息发布系统,包括:
所述电子路牌、车辆头牌、车辆腰牌、车辆尾牌,所述电子路牌设置于车辆停靠区域,所述车辆头牌设置于车辆的前端、所述车辆腰牌设置于车辆的中部、所述尾牌设置于车辆的后端。
车辆信息发布系统对应的信息发布功能模块对应的逻辑思路为:
车辆信息发布系统终端支持为车内外乘客发布线路服务信息功能,能够兼容原有的LCD和LED电子站牌,同时设备支持通过电子路牌APP AHD直驱显示各类路牌信息。
其中,路牌显示信息应包含线路信息、起始站信息、终点站信息、行驶方向信息、前方到站信息、首末班车时间信息和服务用语信息等功能。
具体的:
对于动态公交,结合实际业务数据进行信息提示,比如:提示车辆非运营状态,关闭头腰围牌,或者起点站-动态公交-终点站。
对于大站快,区间车或临时取消停靠等运行线路,路牌也应有对应提示,对于不停靠的站点进行特殊标识,友好的提醒乘客。
其中,关于车辆头牌的头牌业务对应的逻辑思路为:
车辆信息发布系统的头牌主要负责显示车辆的基础线路信息,可以通过头牌参数配置控制是否联动报站,信息滚动显示,滚动方式、方向、速率可配。
具体的:滚动方式:不滚动、横向和纵向。默认为横向。
滚动方向:左到右、右到左、上到下和下到上;默认为从右到左滚动,
滚动速率:支持快、常规和慢三种选择。默认为常规,
同时如图24初步暂定:始发站区域和终点站区域中文字符大于5个字符滚动显示,线路号大于4个字符滚动,报站联动时,在线路下方显示报站信息,报站信息如果超过线路区域则进行滚动显示。具体实现视UI大小情况调整。
其中,关于车辆腰牌的腰牌业务对应的逻辑思路为:
车辆信息发布系统的腰牌主要负责显示车辆的首发站,终点站,线路名称,运营时间等信息,可以通过参数腰牌配置控制是否联动报站,对于信息的显示均是常显。
如图25,显示样式暂定参照北京。
其中,关于车辆尾牌的尾牌业务对应的逻辑思路为:
车辆信息发布系统的尾牌主要负责显示车辆的基础线路信息,可以通过尾牌参数配置控制是否联动报站,是否联动车路协同信息,是否练功信息滚动显示,滚动方式、方向、速率可配。
具体的设置条件为:
滚动方式:不滚动、横向和纵向。默认为横向。
滚动方向:左到右、右到左、上到下和下到上。默认为从右到左滚动。
滚动速率:支持快、常规和慢三种选择。默认为常规。刹车转向信号灯等联动,均按转向灯信息一样,显示在线路底部,详细设计参见图26、图27。
进一步地,基于上述设计思路,衍生出本申请的客运车辆的双域电子电气架构工作方法,还包括根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行处理并运算,根据运算结果向所述车辆信息发布系统发送显示指令包括:车辆运行到指定位置(距离电子路牌一定距离)车辆信息采集设备向中央控制器自身标识信号(识别该辆车的线路号、车序号)、车辆位置以及速度,
同时中央控制器根据收到的自身标识信号、车辆位置以及速度确定出相应的到达站点和到站时间形成显示指令并向到达站点的车辆信息发布系统发送,以使其显示相应公交车的线路号、车序号、当前的到达站点、到站时间。
具体地,如图28,车内信息屏业务对应的逻辑思路为:
车载信息屏主要负责显示车辆的基础线路信息,正常状态下,常显线路信息,超长滚动显示,可以通过头牌参数配置控制是否联动报站,信息滚动显示,滚动方式、方向、速率可配。
具体的设置条件为:
滚动方式:不滚动、横向和纵向。默认为横向。
滚动方向:左到右、右到左、上到下和下到上。默认为从右到左滚动。
滚动速率:支持快、常规和慢三种选择。默认为常规。
当配置报站联动后,会将滚动内容切换到报站内容,首末站会上移到顶部,当站点进站时,提示xxxx站到了,当站点离站时,提示前方到站+下一站站点名称。
当接收到短消息或服务用语的显示通知后,会将报站内容位置切换到对应显示内容,将信息滚动显示一次。确保服务用语和短消息显示完整一轮之后恢复正常状态下的线路信息。
其中,关于车内站节牌业务对应的逻辑思路为:
车内站节牌主要实现的功能有线路信息模拟图、梯形票价表、宣传用语、公交守则、禁止信息、爱心专座及临时宣传用语等信息轮播显示。可以通过车内站节牌参数配置控制页面切换间隔,报站信息显示时间,服务用语或临时短消息显示时间,是否显示票价表,是否显示其他文字信息。各个页面默认情况下进行15s间隔轮播。
同时设置当有报站信息时,需中断轮播,返回线路显示界面,突出显示当前站点的信息,默认显示5s后恢复到正常轮播。
当有服务用语或者临时短消息显示时,需中断轮播,直接显示对应信息内容,默认显示5s后恢复到正常的轮播。
具体页面设计参照北京,
·抬头需显示公交公司、公司标语、实时显示公交线路名、行驶方向首末站中文及英文名;
·线路信息显示各个站点中英文名;首末站用红蓝标志做特殊处理,中间站使用箭头进行标识;站点有换乘站时,在站点上方进行显示;
·站点到离站显示,站点到站时,站名及图标标红并进行闪烁提示;
站点离站后,站名及图标进行置灰显示。
·底部显示两个方向的首末班时间、基础票价、公交相关信息等。
关于业务流程内容参见图29。
在进一步的实施例中,所述双域电子结构中的车辆智能座舱域能够采集智能座舱域内外部信息,实时更新智能座舱内各工作模块工作状态,并根据驾驶员的操作指令结合当前车辆状态,对驾驶员驾驶意图识别,经预置的控制策略处理后,输出相应的控制指令。其中,所述的智能座舱域内部信息包括但不限于座舱压力信号、温度信号、环境光信号、域内通信信号、域内设备如面板开关信号等各类信号;所述的智能座舱域外部信息包括但不限于中央处理器的通信信号、车身域通信信号、动力域通信信号、底盘域通信信号以及自动驾驶域通信信号;车辆智能座舱域对应的智能座舱域控制器通过输入层采集智能座舱域输入的各种内外信号,包括数字信号,模拟量信号和来自域内外的通讯总线信号并将采集到的各类型信号传入智能座舱域控制器预处理软件层中,智能座舱域控制器预处理软件层对输入信号进行预处理来保证信号的正确性和稳定性,同时智能座舱域控制器的软件应用层进行处理分析计算后将输出信号通过预处理软件层和输入层实现对执行器控制或通过通讯总线发送到整车网络中。
在进一步的实施例中,所述中央处理器的主要作用是完成整个双域电子架构内部的各个域的控制、管理及“域”间网络连接功能,如网络数据转发存储、网络安全监控功能、诊断功能以及云端密钥处理等功能,各个域控制器内对应的传感网络的数据处理融合与执行器动作处理由各个域控制器进行管控,即各个域控制器用于完成本域内的各个电控单元的控制、管理功能,同时向中央处理器传输网络信号,同时通过中央处理器与云平台完成相应的数据处理交互过程即各个控制器,可分别基于自身功能划分来实现双域架构的功能架构模型中的定位通信业务、娱乐业务等业务需求,并把通信数据传给中央控制器;同时各个域控制器网络连接可以采用不同的总线协议,如LIN、CAN、CAN-FD、FlexRay、MOST、APIX、Ethernet等多种类型来满足自身域内的通信需求。同时所述中央处理器的总线协议优选采用Ethernet总线协议。
优选的,由于客运车辆的双域网络结构是按照对应的功能划分为若干功能域,且每个功能域都配置一个域控制器,域控制器同时也作为域内部网关使用负责向域外进行信息传递,而各个域控制器之间的跨域通信过程则由中央控制为各个域控制器提供整车主干网络,以实现各个域控制器之间的连接,此结构更好地进行总线隔离和功能封装。
进一步优选的,整车主干网络的电气网络拓扑形式可以是总线拓扑、星型拓扑和总线拓扑集成的混合拓扑结构任意一种或者兼容组合形式,整车主干网络同时兼具采用CAN/CANFD/LIN/Ethernet/LVDS多种总线形式,以降低线束成本。
优选的,所述中央处理器的硬件架构形式可采用采用SOPC的技术在单个平台上通过数据总线将客运车辆总线控制器IP核与嵌入式处理器软核相连接而构成的可编程通用平台的形式。
基于上述需求,则所述的中央处理器包括用于为其内部各个器件提供电能的电源单元,通信控制单元、总线驱动单元、总线监测单元和中央控制单元等;其中,所述中央控制单元主要用于完成通信网络(包括各个域控制器间以及与云平台间的)内的信息计算、信息处理、信号封装转发等过程;通信控制单元负责LIN、CAN和FlexRay等网络连接的相关协议的物理层实现。
进一步的实施例,由于在自动驾驶或者辅助驾驶相关技术内,客运车辆的感知系统感知能力是有限的,因此可以考虑充分利用路端的监测设备延伸车端的感知距离以及能力,充分利用道路环境信息,优化车端的智能设备配置;有效形成车端与路端的优化配置从而做出更准确的自动驾驶判断。
但是申请人在具体研发过程中发现:目前的在自动驾驶或者辅助驾驶相关在利用路端信息辅助完成自动驾驶策略时,多考虑调用其检测的数据占用自身算力完成控制数据的核算过程;但是此种方式无疑影响车辆自身的计算效率;因此申请人欲利用路基或者路端的监测设备的算力配合车端完成部分运算过程,释放车端算力,形成车端与路端智能协同融合的方式。
在具体实施过程中:自动驾驶域与车辆智能座舱域交互密切,并和智能座舱域一样需要处理大量数据,对算力要求较高,且涉及到车辆具备多传感器融合感知、路径规划、决策控制、图像识别、高速通讯、数据处理等多类型的能力;即由于自动驾驶域的主要作用是基于各项传感器的数据,执行涵盖了感知、决策、控制三个层面运算过程,最终将输出命令传送至执行机构,进行车辆的横纵向控制;因此在结合数据传输安全性以及整体控制综合考虑将车端的算力下放到路端时,首选将车端多传感器融合感知分析、图像识别等识别过程分配到路端进行初步分析。
所述自动驾驶域包括车载环境感知单元,所述车载环境感知单元能够实时采集行车环境感知数据,并通过所述中央控制器将当前时刻的所述行车环境感知数据发送至路端中转控制系统。
所述车载环境感知单元包括但不限于多种类型的环境感知传感器以及摄像头模块;所述环境感知传感器至少包括毫米波雷达、激光雷达、超声波雷达。其中,毫米波雷达是工作在毫米波波段探测的雷达,它通过电磁波反射原理,实现对车辆周围障碍物的精准探测,输出目标的相对距离和相对速度;优选布置在客运车辆的前方、后方和侧面,所述毫米波雷达可选用24GHz雷达或者77GHz雷达。其中,激光雷达通过激光雷达发射器发射出一束或多束激光,激光光束遇到障碍物时,产生漫反射,返回至激光接收器,雷达可根据发送与接收信号的时间差乘以光速,除以2,即可算出物体与发射器之间距离。优选布置在客运车辆前方的两侧,主要利用激光反射原理对车辆前向的路沿高度进行扫描,从而获取道路路沿特征,实现对前向路沿的识别。其中,超声波雷达通过利用超声波反射原理,实现对公交车周边近距离障碍物的精准探测,输出目标的相对距离和相对速度,可用于倒车环节等精度要求不高的区域。其中,摄像头模块采用数字摄像头,其可将道路地面标识线等图像信息,并将其转化为数字信号,如可使用深度学习算法来确定与车道线的距离偏差、角度偏差等信息。
优选的,在自动驾驶避障中,障碍物的感知技术是实现自动避障的基础,因此其整车的障碍物感知传感器网络布局的合理性就显得尤为重要,为了提高自动驾驶域的稳定性和可靠性优势,
自动驾驶的障碍物感知方法,在车身区域四周部署相应的环境感知传感器时,可以按照各个类型雷达的属性布局,如在对激光雷达进行部署时,可以自多个激光雷达中选定出主激光雷达和从激光雷达同时完成安装定位,其次,获取主/从激光雷达的初始位姿偏移量,同时通过坐标变换方法对从激光雷达的从激光点云进行预处理,进而完成激光定位系统的坐标的粗标定工作;再次,同时在车身区域中部署多个激光反射柱,分别采用主/从激光雷达扫描激光反射柱的点云数据,采用ICP算法对所获得的两组点云数据进行匹配,进而获取主/从激光雷达的精确位姿偏移量,完成激光定位系统的坐标精标定;最后,利用主激光雷达扫描其对应的复合标定器中的激光反射柱,获得激光点云的坐标数据,采用ICP算法与来自UWB基站的坐标数据进行匹配,通过坐标变换布局成坐标联合标定。
优选的,在自动驾驶域完成自动避障控制时,对于雷达传感信号检测和特征分析处理也是建立能够完成精准避障的自动驾驶障碍物避障控制模型重要改进技术,具体的,如通过构建激光雷达信号融合自动驾驶障碍物感知的参数融合和信号特征分析模型,通过激光雷达信号参数采集和信号融合,实现对激光雷达信号目标检测和回波探测根据回波探测接收结果,进行避障控制来提高域控制器的故障规避和信号检测能力。具体的,首先进行各个传感器原始数据进行信号采集即采集自动驾驶装置与障碍物之间的激光雷达回波信号,然后对采集的雷达信号进行优化处理,分析自动驾驶激光雷达毫米波传感信号回波特征,根据波束形成和信号融合结果实现对障碍物感知和自适应定位。
同时,对于毫米波传感器与激光雷达的信号融合处理的基础方法包括:
将直达波作为信号的主分量,基于目标信号源的分布特性分析方法,建立基于信号参量估计和分布源模型;同时在自动驾驶障碍物感知控制过程,采用双目视觉跟踪检测方法,实现对激光雷达信号融合自动驾驶障碍物感知的回波成像处理并构建自动驾驶域对应的激光雷达毫米波传感信号回波检测模型,其采用单脉冲雷达跟踪和信号检测方法,随后构建毫米波雷达主动信号采集的回波分析模型,其采用点目标DOA估计的方法,结合传感数据采集和视觉特征分析结果,采集自动驾驶激光雷达毫米波传感信号参数和监控摄像信息,以此作为设备层,在网络层中实现信号融合和集成控制,在交换机中实现对自动驾驶激光雷达毫米波传感信号融合和数据。优选的,对于车身与障碍物之间的激光雷达回波信号采用匹配滤波器进行干扰滤波处理,即采用匹配滤波检测的方法,进行信号与噪声的分离处理,分离出的相应的噪声分量,并根据回波相位角分布情况获得激光雷达与毫米波传感信号的互相关特征量并结合自适应的噪声抵消和目标回波探测的方法,建立激光雷达信号融合模型,提取自动驾驶激光雷达毫米波传感信号的功率谱密度特征量,采用信号子空间和噪声子空间分离和自适应加权方法进行信号融合和障碍检测。
优选的,所述车载环境感知单元还包括信号接口电路,所述信号接口电路至少包括Ethernet接口、串口接口、CAN接口;其中所述Ethernet接口用于连接相机摄像头、激光雷达等设备;所述串口接口用于连接组合导航设备等(所述组合导航设备优选采用CGI-320模块,CGI-320模块是华测公司推出的一款采用多传感器数据融合技术的全新高精度板卡,支持全系统多频点RTK定位和定向,CGI-320板卡具备自动基座对准、IMU/GPS组合导航、自主零速修正、自主标定等功能,可与里程计数据组合,进一步提高车载导航下精度);所述CAN接口设备可连接包括毫米波雷达等设备。
优选的,为了解决集成布线遇到的信号线束和电源线束的数量大等问题,采用Ethernet的方式给各相机摄像头、激光雷达等设备供电。
在更进一步的实施例中,由于环境感知能力是客运车辆的车端通过采集周边环境数据和自身数据,经过数据处理后形成的感知模型,因此一般来说,该模型分为3个主要感知内容:道路情况、行驶过程中的静态物体情况和动态物体情况,其中,道路情况可通过获取道路边缘线、道路基本方向等信息,并对这些信息采用机器学习法等进行道路边缘提取。同时在行驶环境中动、静态目标检测过程中,对于动态物体如行人和车辆检测,可通过雷达测量得到检测区域,然后根据图像数据选择检测算法,最后通过自动驾驶域控制器内置算法对检测区域进行检测并完成碰撞避免过程,此类控制过程由于对于实时性要求比较高,也可直接由自动驾驶域控制器自行完成;但是对于交通信号灯情况、前进方向则可以直接利用路端获取,具体依照客户需求设置,也可以设置一定的授权优先级,根据优先级进行设定,如可以设定在一定范围内无障碍物时可进行道路情况、行驶过程中的静态物体情况和动态物体情况的控制,在进入设定的范围内则可以由车端完成行人和周围车辆检测,道路情况则由路端辅助完成。
所述路端中转控制系统的数量为多个,各路端中转控制系统均匀设置在城市道路的道路边缘,具体位置设定要求并无具体规则,直接按照路网规划或者客户需求而定,但是一般建议要覆盖十字/T形/Y形路口、行人过街路口、环岛路口、隧道、桥涵等处。更进一步的实施例,在位于隧道、桥涵等处的所述路端中转控制系统还能够为车端提供高精度地图支持服务,即由于自动驾驶域控制器在进行无人驾驶情景下,需要对道路场景进行更精细的感知(厘米级),仅通过车载设备实现成本太高,在信号不稳定条件下难以实时获得可靠的地图支持且难以做到全程覆盖特殊区域(如隧道、桥涵等),需要借助路端中转控制系统内预存的区域地图进行补充修正,该地图支持服务进程预存在所述路端控制单元内,车端接入成功时即默认启动进程以便于其实时调用。
同时路侧监测设备包括但不限于交通感知设备(宽窄角摄像头、高点高清摄像头、激光LIDAR/LRR/SRR等)、通信设备(RSU/RFED)等。
优选的,所述路端中转控制系统包括路端通信单元、认证单元、第一路端感知单元、第二路端感知单元以及路端控制单元;
所述路端通信单元能够实时接收车载环境感知单元发送的行车环境感知数据并在身份认证通过时,将所述行车环境感知数据发送至第一路端感知单元;优选的,所述路端通信单元可以通过专用短程通信技术-V2X通信技术完成车端与路端之间的实时信息交互,其协议使用IEEE 802.11p;同时也可以兼容接入LTE-V、5G等符合标准的通信设备,在具体实践过程中,本例所述的通信设备为Cohda公司的MK5。
所述认证单元能够自动提取所述路端通信单元接收到的所述行车环境感知数据并获取对应的合法用户编码以确定是否是合法用户,是则分别向路端通信单元以及路端控制单元发送合法用户通知即身份认证通过;优选的,所述认证单元的主要作用是完成尝试接入用户的身份认证,确认是否该用户具有能够开启路端的预留算力的授权,具体可以通过预存在认证单元内部的用户列表与所获取的合法用户编码进行比对,若存在于列表内则认证为合法用户;若不存在则登出并下发拒绝登录通知;所述用户列表的更新则通过5G等通信网络直接由云平台通过相互间的通信加密技术下发。同时为了满足数据加密的需求,可采用信大捷安的XDSM3276的信息安全加密芯片进行硬件搭建。
所述第一路端感知单元能够接收行车环境感知数据,并判断当前的客运车辆是否属于第一感知限制状态,是则基于路端行车策略获取第一行车控制数据并发送至路端控制单元;所述第一路端感知单元的重要功能就是确定当前行车状态是否存在行车安全隐患状态---即所述第一感知限制状态,具体是指确定是否已经超出车端感知设备所能识别出的行车环境能力,由于车端设备受限于车载感知传感器的自身参数性能以及安装位置等局限性,其难以避免能够在相邻车道、行车方向等视角范围内不出现高于自身感知能力外的障碍物进而遮挡车端感知系统的“探测视线”(如不能识别前方或者转向路口等环境时的障碍物信息或者的交通信号灯状态),因此在处于第一感知限制状态时,应借助路端的感知设备的感知能力增加车端的自身“视角范围”,也因此第一感知限制状态包括但不限于相邻车道存在障碍物和或客运车辆前进方向存在障碍物,使得在客运车辆的行车视域范围内不能获得完整的客运车辆行车安全数据包,此时完整的客运车辆行车安全数据包依据实际情况包括前进方向无障碍物(此时的障碍物为行驶的车辆)时的前车车距/车速/转向数据,前进方向存在障碍物(此时的障碍物为行驶的车辆)时的前车车距/车速/转向数据,相邻车道存在障碍物(此时的障碍物为行驶的车辆)时的转向数据(与本车转向方向一致),前进方向无障碍物(此时的障碍物为行驶的车辆)时的交通信号灯状态,前进方向存在障碍物(此时的障碍物为行驶的车辆)时的交通信号灯状态,相邻车道存在障碍物(此时的障碍物为行驶的车辆)时的交通信号灯状态等多种类型的状态。所述第一路端感知单元能够辅助车端在出现相邻车道遮挡时,难以识别障碍物、路口交通信号灯状态等信息,存在安全隐患时完成环境感知操作。
基于上述内容,所述路端行车策略基于两种状态设置不同的执行条件,具体包括:若处于第一感知限制状态时,获取路侧监测设备内的检测数据并形成第一行车控制数据;若出于非第一感知限制状态时,直接获取行车环境感知数据并形成第一行车控制数据,此时的第一行车控制数据实质上是指行车环境参考数据,并不能直接对进行车辆的横纵向控制起到最终的控制作用,最终仍需要由自动驾驶域控制器进行数据分析融合进而形成实际的横纵向控制指令。
优选的,所述第二路端感知单元能够获取第二行车控制数据并发送至路端控制单元;具体的,所述第二路端感知单元能够与路侧监测设备通信,获取客运车辆前进方向一定范围内的道路信息,并形成第二行车控制数据发送至路端控制单元;所述道路信息至少包括道路拥堵数据。由于在客运车辆行车过程中,除了要考虑自身周围的环境信息,还需要考虑行车方向上的道路畅通情况,以便于域控制器能够及时调整行车控制参数,形成安全驾驶数据,提高自动驾驶控制精度,在获取道路拥堵数据(在一定行车范围,前进方向的全部车道拥堵情况)时,在道路拥堵时,减慢车辆行车速度或者调整车道或进行行车路径变更优化等。
在更具体的实施例中,所述道路信息还包括路面本体状态数据以及路面气象信息。其中,考虑路面本体状态数据(考虑行车路面是否存在坑洼缺陷等路基实体缺陷),以便于自动驾驶域控制完成车辆变道或者减速等控制操作;其中,考虑路面气象信息是极端气象环境下的行车安全也是重要的行车控制环节,如在积雪结冰路面行车时,应及时获取车道的积雪结冰范围以便于通知车端及时换道或者不能换道时降速缓慢行驶并增加安全车距阈值;又如,在积水车道时,也应及时获取车道的积水范围以便于通知车端及时换道或者不能换道时降速缓慢行驶;又如,在隧道或者桥洞附近-桥涵的积水车道,应及时对积水深度进行预估,并提醒车端进行行车路径变更优化。通过上述技术方案,延伸车辆车端感知能力,降低车端自身对于感知范围有限、遮挡盲区等制约。
优选的,对路面本体状态数据进行数据分类处理的过程包括:
首先,通过摄像头模块对路面本体状态数据进行图像数据采集,形成图像样本;
其次,对所述图像样本进行数据预处理,所述预处理过程包括对图像进行降噪处理以及图像增强处理等;
再次,基于卷积神经网络,对预处理后的图像样本进行特征提取和分类,即创建路面本体状态数据处理子网络,基于所述路面本体状态数据处理子网络对预处理后的图像样本进行特征提取和分类以识别路面本体状态数据,如坑洼缺陷等路基实体缺陷;
所述路面本体状态数据处理子网络对应的模型函数为:
其中,
-(L):表示路面本体状态的输出变量
-(σ):Sigmoid函数,用于将输出范围控制在0到1之间
-(N):卷积核的数量
-(M):卷积核的大小
-(Iij):表示路面本体状态数据图像中的第(i)个卷积核的第(j)个像素值
-(Wij):表示路面本体状态数据处理子网络中的第(i)个卷积核的第(j)个权重值
-(bij):表示路面本体状态数据处理子网络中的第(i)个卷积核的第(j)个偏置值
-(Vi):表示路面本体状态数据处理子网络中的第(i)个全连接层的权重向量
-(ci):表示路面本体状态数据处理子网络中的第(i)个全连接层的偏置值。
优选的,对路面气象信息进行数据分类处理的过程包括:
首先,通过摄像头模块对路面气象信息进行图像数据采集,形成图像样本;
其次,对所述图像样本进行数据预处理,所述预处理过程包括对图像进行降噪处理以及图像增强处理等;
再次,基于卷积神经网络,对预处理后的图像样本进行特征提取和分类,即创建路面气象信息处理子网络,基于所述路面气象信息处理子网络对预处理后的图像样本进行特征提取和分类以识别路面气象信息状态数据,以识别极端气象环境下的行车安全信息,如积雪结冰、积水信息等;
所述路面气象信息处理子网络对应的模型函数为:
其中,
-(M):表示气象信息的输出变量,取值范围在0到1之间
-(N′):卷积核的数量
-(M′):卷积核的大小
-(Jij):表示路面气象信息图像中的第(i)个卷积核的第(j)个像素值
-(W′ij):表示路面气象信息处理子网络中的第(i)个卷积核的第(j)个权重值
-(b′ij):表示路面气象信息处理子网络中的第(i)个卷积核的第(j)个偏置值
-(Vi′):表示路面气象信息处理子网络中的第(i)个全连接层的权重向量
-(c′i):表示路面气象信息处理子网络中的第(i)个全连接层的偏置值。
同时优选的,同时两种类型的路面特征也存在同时存在的可能性,因此,可以通过图像特征分类技术,将两个子网络的输出特征合并,作为输入送入后续的分类器,用分类器输出最终的控制操作,如形成变道和或减速行车控制命令。
优选的,所述路端控制单元能够在身份认证通过时,提取所述合法用户编码,并为所述合法用户编码配置独立的数据处理运行环境,同时在所述数据处理运行环境下,基于第一行车控制数据、第二行车控制数据形成所述合法用户编码对应的行车控制数据,并通过路端通信单元分别向所述中央控制器、云平台(存储)发送。所述路端控制单元应匹配核心运算力强的芯片,来满足一定算力需求,如一般采用GPU或是人工智能芯片TPU处理承担大规模浮点数并行计算;也可以采用S32G274A芯片,S32G274A有4个MAC接口,分别为PFEO、PFE1、PFE2和GMAC,采用3个独立千兆PHY和一个SWITCH来扩展以太网接口,电源芯片是NXP与S32G平台匹配的VR5510,板上还放置一个RTC芯片用以实现定时唤醒检测功能,除此之外还预留了部分ADC采样和I/O控制接口。
在更具体的实施例中,为所述合法用户编码配置独立的数据处理运行环境的过程包括:在虚拟镜像运行环境下,所述路端控制单元内预置多个相互独立运行的用户数据分析进程;即为每一待接入的用户即客运车辆按照各自的用户编码配置一个独立运行的数据处理进程。
进一步的,所述虚拟镜像运行环境的创建过程包括:设备开机后,所述路端控制单元内本地镜像服务进程收到调用指令后,对调用指令进行解析,以获取解析镜像运行环境信息;其包括:进程类别、版本控制类别等管理信息;将解析好的管理信息封装整理成不同类别的数据包,通过内部管道通信方式发送给路端控制单元的适配服务进程;此处提及的数据包,包括:运行信息数据包、软件版本控制信息数据包等;本地镜像服务进程与适配服务进程确定网络通信连接存在后;本地镜像服务进程将“基础信息数据包”、“软件版本控制信息数据包”等信息,解析并拼接成一个指定的目录结构,并通过上一步的目录路径,依据“软件版本控制信息数据包”中的操作指令,对指定目录下的可执行程序进行指定操作;完成后,将所获取的数据以数据包的形式,通过适配服务进程返回获取的数据包内容。在更具体的实施例中,如采用git技术进行本地镜像运行环境创建,本地Git服务进程收到调用指令后,对调用指令进行解析,以获取解析镜像运行环境信息;其包括:软件管理类别、应用软件名称、版本控制类别等信息;将解析好的软件管理信息封装整理成不同类别的数据包,通过内部管道通信方式发送给控制单元的适配服务进程;此处提及的数据包,包括:运行信息数据包、软件版本控制信息数据包等;本地Git服务进程与适配服务进程确定网络通信连接存在后;本地Git服务进程将“基础信息数据包”、“软件版本控制信息数据包”等信息,解析并拼接成一个指定的目录结构,;并通过上一步的目录路径,依据“软件版本控制信息数据包”中的操作指令,对指定目录下的可执行程序进行指定操作;完成后,将所获取的数据以数据包的形式,通过适配服务进程返回获取的数据包内容。以为任何应用创建一个轻量级的、可移植的、自给自足的镜像容器,批量地在运行环境中部署,多个用户接入无需等待,进而充分利用镜像分布式运行带来的速度和敏捷性,为用户提供与用户身份相匹配的镜像运行环境;所进而能够在所述镜像运行环境下,按照不同的用户需求为身份验证合法的提供独立的镜像运行环境,以便于各个用户在不影响路端主控运行的同时,保证多个数据处理进程各自独立运行。
同时云平台系统预先为每一注册的用户提供唯一对应的身份标识码并以列表形式下发到每个路端设备,以便于路端设备在响应接入请求时,为每一个身份标识码配置各自对应的镜像运行数据包,以使得用户在其提供独立的镜像运行环境下自主运行,并将待处理数据存储在各自对应的地址下,所述身份标识码的可以按照用户类型进行分类标识,如身份识别码的原始数据为X00123456789,X为用户类型区别位,如1为28路车第123号车,2为28路车第124号车,3为28路车第125号车。
进一步的,本地镜像服务进程能够在确定宿主进程的宿主访问空间地址以及寄生进程的数量并基于预设的空间映射关系表,为每一寄生进程分配寄生访问空间地址;再次,分配宿主进程与寄生进程的数据运行存储数据链关系并进行数据存储。进一步的分配宿主进程与寄生进程的数据运行存储数据链关系并进行数据存储的过程包括:将宿主进程内待运行的镜像数据数据,迁移至寄生进程内运行并将运行过程中的运行数据按照给定的空间映射关系拷贝至宿主进程内进行存储。例如,确定出宿主访问空间地址以及至少一个寄生访问空间地址,所述宿主访问空间地址与寄生访问空间地址具有唯一对应的空间映射关系,优选的关系模型为:设定宿主访问空间地址m,m共有32个字节,且寄生访问空间地址n,n共有32个字节,则空间映射关系函数为
其中,ni表示寄生访问空间地址n的第i个字节,mi表示宿主访问空间地址m的第m个字节,m2表示宿主访问空间地址m的第2个字节,m13表示宿主访问空间地址m的第13个字节,m22表示宿主访问空间地址m的第22个字节,m6表示宿主访问空间地址m的第6个字节,m11表示宿主访问空间地址m的第11个字节,m25表示宿主访问空间地址m的第25个字节,m7表示宿主访问空间地址m的第7个字节,m18表示宿主访问空间地址m的第18个字节,m3表示宿主访问空间地址m的第3个字节。
在具体的实施例中,由于车端的域控制器中的硬件架构与路端的控制单元不能保证完全一致的架构形式(铺设成本有限),即两者可能存在两种控制器所需处理的数据、消息类型与业务种类不同的技术问题,在解决此种技术问题时,需要首选考虑如何保证每一个时间切片能高效处理各种业务消息并将数据及时分发到指定应用。为了解决该问题,在路端中转控制系统内架构数据中转应用单元,该数据中转应用单元主要包括以下几个核心组件,数据解析组件、消息队列组件、数据分发组件、数据订阅组件、应用处理组件。数据解析组件按照预定编码格式对接收的数据进行解码,并将解码的数据组装成消息,按照预设消息优先级缓存到对应消息队列组件;所述消息队列组件用于缓存V2X消息,并根据数据优先级优先处理实时性高、安全类应用消息,消息队列形式可采用ActiveMQ;数据分发组件根据各应用订阅要求,按照消息类型、订阅周期将数据发送到指定应用组件进行处理。应用处理组件是V2X应用的最终实现层,应用组件接收到所需消息作为算法输入,并给出应用响应实现V2X应用效果。基于上述设计的方案,一个经典的实施例为:数据处理流程包括:首先,通过V2X网络循环接收消息,由消息解析组件进行解析;然后,如果接收到PCM消息则向订阅该消息的应用组件发送该数据;最后,高精定位应用组件将设备单点定位信息与PCM消息进行解算。同时如果遇到多路侧发送差分数据,路端同时接收多个RSU差分数据,则根据PCM发送时间进行过滤,选取时间最新的差分数据使用,从而提高多个RSU数据提高数据冗余性。
在具体实施方式中,所述动力域包括动力域控制器、整车控制系统VCU、电池管理系统BMS、VBU;其中,所述动力域控制器的主要设计功能为基于助CAN/FLEXRAY实现变速器管理、引擎管理、电池监控、交流发电机调节进而实现对动力总成的优化与控制过程;其在硬件架构上可采用英飞凌多核CPU/GPU芯片,该类型芯片能够提供了更大的代码存储空间和更强更安全的运算能力,且具备丰富的输入输出通信端口,可支持多种形态的组合应用和OTA升级能力。同时在软件架构上可使用现有的AUTOSAR架构+MBD建模应用,以有效提高域控制器软件可靠性和可移植性,从而实现智能化的动力总成管理单元的效果。优选的,所述动力总成包括但不限于内燃机、电动机、发电机、电池、变速箱等动力设备。
优选的,所述动力域控制器用于为所述动力总成计算和分配扭矩、提供电气智能故障诊断、智能节电、总线通信等功能;具体的,所述动力域控制器负责三合一系统、BMS和整车控制器的控制过程。BMS包括电池控制器单元(BatteryControlUnit,BCU)和电池管理单元(BatteryManagementUnit,BMU)组成。电池管理单元BMU主要任务包括:负责采样模组中的电芯的电压,执行电芯的电压平衡,采样和管理电芯的温度,通过CAN总线跟外部其余相关单元进行通讯等。
而BCU的主要任务则是:测量电池包的总电压、总电流和绝缘状态等,管理充电和放电,评估电池荷电状态SOC/SOH/SOP值,此外它也是VCU与电池组之间的通讯中介桥梁。优选的,BMS采用BMS芯片,所述BMS芯片可采用SoC方案进行架构。优选的,其总线通讯形式包括CAN/CAN-FD,Gigabit Ethernet并对通讯提供SHA-256加密算法支持。
在具体实施方式中,由于车身域集成了车身电子的所有基础驱动即车身相关功能的实时工作,属于综合统一管理器,能够合理有效的分配系统资源,如能够集成BCM、PEPS、TPMS、Gateway等功能,也可拓展增加座椅调节、后视镜控制、空调控制等功能,各执行器,也能够整合钥匙、灯、车门、车窗等电控系统、胎压监测、网关的功能。
优选的,所述车身域包括车身域控制器、智能钥匙单元、射频接收单元、胎压传感器单元、信号发送单元等单元;其中,信号发送单元受控于车身域控制器并由其进行驱动,用于发送低频信号给智能钥匙单元,智能钥匙单元发送高频信号给射频接收单元;同时射频接收单元主要接收智能钥匙单元或胎压传感器单元的高频信号,其与车身域控制器之间通过车身域控制器的局域网的CAN总线进行通信。
所述车身域控制器主要功能是:作为车身域的中央控制模块,主要负责车门智能开启、车门智能关闭、智能门锁控制、智能胎压监测、灯光智能控制(包括内部灯光、外部灯光的控制过程)、电源智能管理、自动雨刮喷水管理、后风窗加热管理、加油/充电口盖管理、远程控制管理等功能。
基于上述设计需求,本例所述车身域控制器分为安全功能域以及程序功能域,所述安全功能域搭载FreeRTOS实时操作系统,主要用于对CAN、LIN等实时性要求较高的信息进行处理;所述程序功能域搭载Linux富操作系统,主要用于对DOIP、OTA等网络相关信息进行处理,具体架构形式包括车身应用层、车身实时运行层以及车身底层;应用层中为具体的应用功能。实时运行层为应用层和底层驱动的中间层,其实现与应用层和驱动层的接口和逻辑转换等,驱动层则实现硬件设备的访问控制。其主要工作任务包括:运行RF、RKE任务,获取钥匙当前状态;运行TPMS任务,获取胎压传感器数据;根据胎压传感器和其他车身数据,判断胎压警告状态;通过MSDI驱动获取底层输入开关信号状态;获取开关状态后,将数据传送给相应的灯控模型并获取灯控模型的输出结果,获取座椅姿态数据并调整座椅相关姿态状态等。
优选的,所述车身域对应的接口单元包括CAN/CANFD接口、LIN接口、车载以太网接口、信号输入出接口等;其中,LIN接口选用NXP公司的TJA1021芯片,实现LIN主从协议控制器到物理总线之间的接口转换。车载以太网接口选用YT8010A芯片。
优选的,所述车身域对应的电源单元包括RTC电源单元、安全域电源单元和程序功能电源单元;各个电源单元采用分立DC/DC实现;RTC电源单元用于为车身上电并负责域内各个芯片的整体电源的控制;安全域电源单元用于为安全域功能域的MCU提供工作电源;程序功能电源单元用于为程序功能域MPU提供工作电源。
在具体实施方式中,由于客运车辆的底盘是保证汽车正常行驶、承载发动机、车身的核心部件的关键性集成平台,其主要由传动系、行驶系、转向系、制动系和悬架系统组成。因此客运车辆的底盘域架构也是重要的域控制技术研究方向,进而提升车辆在轻量化、响应速度等性能。
在车辆底盘控制过程中一个重要的内容则是实现转向盘和车辆转向机构的完全解耦过程,以避免车辆在ECU控制下自动实现紧急转向时对驾驶员转向动作的干扰和引起可能的碰撞;其基本思路是通过相应的传感器网路,如多个扭矩传感器接收,获取转向盘转向和扭矩信号,通过ECU转化为电信号并传输给助力电机,实现转向控制。具体的实现步骤则是根据扭矩传感器接收驾驶员操作转向盘产生的扭矩和转向角数据,通过ECU与数据线将指令传输至转向拉杆的助力电机上,并设置另一路感反馈电机,实现转向控制。
优选的,所述底盘域控制器的架构形式为第一层为状态输入层、第二层为底盘决策层、第三层则是底层--控制执行层;其中,状态输入层用于获取驾驶人或自动驾驶命令,根据驾驶人操作获取驾驶人操作意图,计算全局控制输入并对当前的驾驶情况进行定义分类。底盘决策层根据状态输入层控制器定义的工作模式选择不同的协调控制策略,并将不同控制输入分配到各个底盘子系统。控制执行层则包括多个底盘子系统控制器,以根据底盘决策层的控制命令,将子系统控制信号传递到执行器硬件电路中。
在进一步的实施例中,鉴于车辆底盘集成协调控制过程一般包括制动控制(踏板信号监测、线控制动的控制与反馈)、油门控制(电机驱动的控制与反馈)、转向控制(方向盘信号监测、线控转向的控制与反馈)、档位控制(档位控制与反馈)等,则本例所述的车辆底盘域控制器可采用埃孚公司开发的车辆底盘集成协调控制器-中央协调器VMC CubiX。VMCCubiX作为车辆运动,其能够基于感知状态输入层的输入,通过底盘决策层计算出的期望车辆运动目标并进行分解,通过预置车辆运动控制算法输出各底盘执行器的控制指令(如目标后轮转角、目标制动/驱动力等)。
则具体的,所述状态输入层执行底盘感知数据获取操作,参与执行的仪器包括车速传感器、轮速传感器、陀螺仪、方向盘扭矩传感器、制动压力传感器、制动踏板位移传感器、加速踏板位移传感器、悬架线位移传感器、悬架加速度传感器、质心侧偏角估计仪器、车重估计仪器等;所述底盘决策层主要中央协调器实现,同时对应的控制执行层的底盘子系统控制器则分别为转向控制器、制动控制器、驱动控制器、悬架控制器;其中,转向控制器用于控制主动前轮转向系统、主动后轮转向系统以及主动四轮转向系统;所述制动控制器用于控制差动制动系统、横摆力矩系统、紧急制动系统、制动防抱死系统、复合制动系统;所述驱动控制器主要用于控制驱动力控制系统以及牵引力控制系统;所述悬架控制器用于控制主动悬架系统以及半主动悬架系统。
在进一步的实施例中,在所述电气双域架构形式下,由于动力域和底盘域的功能安全和信息安全级别要求相似,通过域融合思想可以将通过域控制器的协调控制技术以及在硬件虚拟化技术的支持下实现两个域的协同,合并为一个新的域控制器,其具备中央核心控制能力。
在进一步的实施例中,客运车辆对于关键部件的智能化运维监测也是自动驾驶技术的重要研究方向,但是由于客运车辆整车组成结构复杂及系统集成度较高,长时间超负荷运行及行驶环境的变化性易导致关键零部件发生报警或故障。因此在此种需求下,可以考虑:由于车辆的运维数据分析属于即时性要求不高的分析处理进程,则此进程可以由路端配合完成相应的数据运维数据分析过程以寻找出相应的异常特征数据,但是现有的运维监测技术不能满足智能车辆运维指标体系对于复杂的非结构化高维数据进行异常检测的车辆运维数据分析需求,因此如何通过路端对故障问题及时作出响应,准确判断故障部位,给出故障原因是关键。
基于上述设计思路,所述路端中转控制系统还包括路端运维监测单元,所述路端运维监测单元能够在路端控制单元处于闲时状态时,与中央控制器进行通信,用于获取车端传感器网络所获取的设备运行信号,并对设备运行信号进行特征提取,获取设备运行特征并进行预警诊断,同时能够对基于预警诊断结果确定设备运行状态是否异常并进行故障预警。
优选的,所述路端控制单元处于闲时状态是指,某个车端已经通过本路端中转控制系统的认证单元的合法身份验证时,路端控制单元的运算能力占用率未超限,为了有效保证路端控制单元有足够的算力完成前述行车控制数据的分析过程以及后续待接入的车端能够满足其接入后算力需求,因此需要进行闲时状态判断,只有当前的路端控制单元处于闲时状态才允许进行运维监测预警操作,如果处于非闲时状态则车端要求在接入到下一路端中转控制系统时再发起运维监测预警操作。
优选的,所述路端控制单元同时能够为路端运维监测单元分配独立的分析运行环境进行预警诊断诊断操作。
优选的,所述路端运维监测单元包括数据处理模块、数据分析模块以及运维决策模块;所述数据处理模块用于对设备运行信号中的运行日志数据进行清洗和标准化处理;所述数据分析模块用于基于处理后的运行日志数据并进行特征提取以获取对应的设备运行特征;所述运维决策模块用于根据所述设备运行特征进行预警诊断即确定设备运行特征的异常度,同时能够对基于预警诊断结果确定设备运行状态是否异常并进行故障预警。
如,所述标准化处理可采用获取设备运行信号中的运行日志数据,并对其采用下述公式进行标准化处理,处理后的数据定义D;
上式中,xij为样本集;xj是xij的均值;Sj为样本集xij的标准方差;为标准化处理后的数据集样本标准差;i=1,2,···,n;j=1,2,···,n,n为采样次数。
上式中,为标准化处理后的样本集均值;
形成标准化处理后的数据矩阵,所述数据矩阵为
m为样本数据的测试数量,如将信号分割为120个样本,每个样本由960个数据点组成;
所述数据分析模块用于基于处理后的运行日志数据并进行特征提取以获取对应的设备运行特征;具体的处理过程为:
首先,基于数据矩阵,确定对应的主成分空间,具体包括,通过协方差分解公式确定主成分空间,所述协方差分解公式即协方差矩阵s为:
其次,获取数据矩阵的简化形式表达,对应的公式为
再次,获取数据矩阵的主成分评价函数,对应计算公式为
式中,amj为相关系数;
最后,对数据矩阵进行主元分解处理,对应的处理过程为
T=[t1,t2,…,tm]
P=[P1,P2,…,pm]
上述式中,T为主元的分矩阵,t1,t2,···,tm为主元的分向量,P为主元负荷矩阵;
则,主元分解处理后的数据矩阵为:
式中,E为残差向量;TPT为主元子间。
所述运维决策模块用于根据所述设备运行特征进行预警诊断即确定设备运行特征的异常度,对应的处理过程为:
对主元分解处理后的数据矩阵计算,对应的计算公式为
上式中,C即CONT贡献率
则,第i个主元的贡献率的计算公式为:
式中,cL为主贡献率,其值范围为0≤cL≤1。
将各个贡献率按照降序排列,以寻找出符合设备运行特征的异常度阈值的特征作为敏感特征。
在进一步的实施例中,由于车辆零部件智能化水平不断提高,域控制器技术的不断发展,车辆内部搭载的ECU越来越多也越来越复杂。因此,车辆复杂度的提高必将带来维护上的困难,不可避免的会出现对ECU软件、固件进行升级的需求也越强列。因此在架构云平台时应当考虑云平台具有远程空中升级技木(Update On The Air)。
基于上述技术需求,在架构双域电子的客运车辆所需的云平台时,可采用现有的OTA技术,形成一定的OTA系统,所述OTA系统应在云端架构有软件升级服务器,软件升级服务器上存储有各个ECU的最新软件版本,车载升级代理端即车端检测到有需要升级的软件包后会通过HTTPS协议将升级包下载到中央控制器内再传递到各个域控制器中,执行完整性验证,解密和签名验证。此后再通过UDS对各ECU进行升级。升级完成后向软件升级升级服务器反馈升级的结果。
优选的,所述云平台的OTA系统分为云端OTA管理服务器,车载端升级代理(UpdateAgent)和各个域控制器内部的被升级的车载控制器(ECUs):
其中,OTA管理服务器:其承担了车型/车辆基础数据的管理,供应商各个ECU升级包的存储与分析,OTA升级策略的创建与管理,升级进度的统计与分析等工作。
优选的,所述OTA管理服务器为各个用户提供独立的数据库服务,其能够将通过中央控制器传递的数据按照数据库所建的数据表结构存入数据库中,同时为用户提供数据下载支持;所述的数据库基于Docker技术创建,主要通过管理节点对各个Docker所消费的资源进行管理以形成一群数据库构成的数据库集群。
同时云端OTA管理服务器也设置相应的安全与防护系统:主要包括密钥管理系统、证书发放系统与安全传输协议。
其中,车载端升级代理(Update Agent)是车载端执行升级包的下载、签名验证与车内数据发放工作的软硬件集合;车载端升级代理(Update Agent)是具有移动通讯模块的T-Box或车机(Head Unit)。
其中,被升级的车载控制器(ECUs)用于对于信息域的各个控制器遵循网络升级规范,对于车身域和动力域控制器要遵循ISO15765协议和UDS中相应的刷写规范。
基于上述方案相同的设计思路,本申请还提供了一种客运车辆的双域电子电气架构工作方法,其主要步骤包括:
基于车辆智能座舱控制域接收多个车辆信息采集设备(所述采集设备之间具备网关的协议转换功能)上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果通过CAN总线和以太网向车辆行车驾驶控制域发送控制指令,所述控制指令同步备份至云平台以及数据存储器;
通过车辆行车驾驶控制域接收所述车辆智能座舱控制域发送的控制指令,对所属控制指令进行解析(如可获取安全等级预测,安全限值)后,根据所述控制指令控制车辆的行驶中的驱动、制动、转向功能。
其中,采集设备之间通过协议转换网关(内置协议转换功能)进行通信,如modbus设备与网关连接后,通过该协议转换网关,将协议转换为IEC101或者IEC104协议,将数据采集后上传到上位机系统或者云平台。
上述一种客运车辆的双域电子电气架构工作方法,可通过双域电子电气架构形式将客运车辆各大功能区域通过域控制器组合形式进行控制,同时通过中央控制器提高各部分域控制器的信息交互效率,降低制造成本,以完成客运车辆的智能网联化技术的运用。
其中,根据运算结果向所述车辆调度系统发送车辆的调度指令包括:
获取目标区域的客流信息;所述客流信息包括乘客数量、每一乘客对应的目的地和预乘车时间;根据所述客流信息确定出预计调度信息,所述预计调度信息包括每一目的地对应的可调度公交类型和数量;根据所述预计调度信息,确定出调度方案;所述调度方案用于形成调度指令。
其中,根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述设备运维系统发送车辆运维指令包括:获取车辆信息采集设备上报的信息中的故障事件信息,故障事件信息包括:故障区域的标识及故障区域的定位位置;根据故障区域的定位位置获取标识对应的故障区域的车辆运维指令;所述设备运维系统接收车辆运维指令并根据车辆运维指令发出告警响应(能够使运维人员快速定位出故障区域)。
其中,根据运算结果向所述车辆管理单元发送车辆管理指令包括:基于通讯定位技术获取并实时记录车辆行车状态以实现公交系统的智能化运营管理,最大限度地优化公交系统的运行,所述车辆行车状态至少包括车况数据、定位信息、到站信息、视频监控、营运记录、行驶记录数据。
其中,所述通讯定位技术至少包括GPS/北斗定位技术、网络通信技术、物联网技术。
其中,根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述车辆信息发布系统发送显示指令包括:车辆运行到指定位置(距离电子路牌一定距离)车辆信息采集设备向中央控制器自身标识信号(识别该辆车的线路号、车序号)、车辆位置以及速度,中央控制器根据收到的自身标识信号、车辆位置以及速度确定出相应的到达站点和到站时间形成显示指令并向到达站点的车辆信息发布系统发送,以使其显示相应公交车的线路号、车序号、当前的到达站点、到站时间。
基于上述方案相同的设计思路,本申请还提供了包括配置有双域电子电气架构的客运车辆,其特征在于,包括:整车车身以及能够对整车车身进行集中控制的双域电子结构。
明显的,采用上述双域电子电气架构的客运车辆能够有效克服传统车辆电气系统结构复杂、维护升级困难、电子部件冗余等问题。在完成电子系统布局精简化(中央控制器与各个域控制器技术的运用,使电子系统布局大为精简,且大幅减少电子控制单元的数量、缩短通信总线长度、降低电子系统重量)的设计目的之外,更是有效提高了安全防护性能,由于客运车辆受车辆用途的影响,其存在行驶频率高、距离长,尤其是发动机、底盘、轴承等关键部分,磨损面积大、功能失效快、保养难度高,但是采用本申请所述客运车辆的设计方案可以有效提高其安全性,如可以通过车端与路端中转系统在第一时间采集诸如发动机运行状态、机械部件磨损情况、电子系统软硬件错误报告等信息,并同步读取以便于监控中心制定排故方案,尽快对车辆进行针对性维修,有效降低交通事故发生率。
同时也可以基于上述双域电子电气架构的客运车辆,设计一种客运车辆监控平台,其主要包括:监控中心以及若干与所述监控中心实时通信的客运车辆,每一所述客运车辆采用所述双域电子结构或者能够以前述客运车辆的双域电子电气架构工作方法进行工作。
上述基于双域电子电气架构的客运车辆架构的客运车辆能够有效辅助客运车辆公司或者联合交管部门形成智慧型公交运行监测平台,以在现有的数据与资源的基础上,提供智慧型交管数据分析和处理技术,进而建立自动化、规范化的数据处理和分析系统,实现对数据的深层次、多方面的挖掘分析和处理,为交通结构优化、路网结构优化、公交线网规划和优化、交通系统运行状况评价提供新思路,最终达到提高公共交通运行效率和服务水平,在提高行车安全的同时提高路网通行效率的设计目的。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (23)

1.一种客运车辆的双域电子电气架构,其特征在于,包括:
车辆智能座舱控制域、车辆行车驾驶控制域、中央控制器和云平台;其中,所述车辆智能座舱控制域用于接收多个车辆信息采集设备上传的信息,所述多个采集设备之间具备网关的协议转换功能,所述信息为车辆智能座舱控制域多维数据;
所述车辆行车驾驶控制域接收车辆行驶执行结构的参数,所述车辆行驶执行结构的参数为车辆行驶多维数据,所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果获取车辆行驶的控制实施流程以及车辆行驶的控制或操作指示。
2.根据权利要求1所述的客运车辆的双域电子电气架构,其特征在于,还包括:
车载应用平台,其包括:车辆调度系统、设备运维系统、车辆信息发布系统、客户终端;
所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果向所述车辆调度系统发送车辆的调度指令;
所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果向所述设备运维系统发送车辆运维指令;
所述中央控制器将所述车辆智能座舱控制域多维数据和所述车辆行驶多维数据进行融合后运算,根据运算结果向所述车辆信息发布系统发送显示指令;
所述车辆智能座舱控制域根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述客户终端发送车辆相关的实时信息。
3.根据权利要求2所述的客运车辆的双域电子电气架构,其特征在于,
车辆调度系统包括:车辆信息管理单元、调度管理单元以及监控管理单元,所述车辆信息管理单元能够实时获取车辆管理网络中的各个车辆信息,所述调度管理单元能够根据车辆的调度指令对各个车辆进行调度管理,所述监控管理单元能够对各个车辆进行里程/油耗监控管理。
4.根据权利要求2所述的客运车辆的双域电子电气架构,其特征在于,
设备运维系统包括:设备感知单元、数据诊断单元以及运维决策单元;所述设备感知单元通过传感器网络获取设备运行信号,所述数据诊断单元通过对设备运行信号进行特征提取,获取设备运行特征并进行预警诊断,运维决策单元能够对基于预警诊断结果确定设备运行状态信息并在异常时进行故障预警。
5.根据权利要求2所述的客运车辆的双域电子电气架构,其特征在于,
车辆信息发布系统,包括:所述电子路牌、车辆头牌、车辆腰牌、车辆尾牌,所述电子路牌设置于车辆停靠区域,所述车辆头牌设置于车辆的前端、所述车辆腰牌设置于车辆的中部、所述尾牌设置于车辆的后端。
6.根据权利要求2所述的客运车辆的双域电子电气架构,其特征在于,
客户终端,包括:车载POS机、客流仪以及语音报站设备。
7.根据权利要求1所述的客运车辆的双域电子电气架构,其特征在于,
所述车辆行车驾驶控制域,包括:车辆自动驾驶域、车辆动力域、车身域、车辆底盘域。
8.根据权利要求1所述的客运车辆的双域电子电气架构,其特征在于,
所述中央控制器通过CAN总线和以太网向车辆行车驾驶控制域发送控制指令,所述控制指令同步备份至云平台/数据存储器;
所述车辆行车驾驶控制域接收所述车辆智能座舱控制域发送的控制指令,对所属控制指令进行解析后,根据所述控制指令控制车辆的行驶中的驱动、制动、转向功能。
9.根据权利要求7所述的客运车辆的双域电子电气架构,其特征在于,
所述自动驾驶域包括车载环境感知单元,所述车载环境感知单元能够实时采集行车环境感知数据,并通过所述中央控制器将当前时刻的所述行车环境感知数据发送至路端中转控制系统,所述路端中转控制系统的数量为多个,各路端中转控制系统均匀设置在城市道路的道路边缘。
10.根据权利要求9所述的客运车辆的双域电子电气架构,其特征在于,
所述路端中转控制系统包括路端通信单元、认证单元、第一路端感知单元、第二路端感知单元以及路端控制单元;所述路端通信单元能够实时接收车载环境感知单元发送的行车环境感知数据并在身份认证通过时,将所述行车环境感知数据发送至第一路端感知单元;所述认证单元能够自动提取所述路端通信单元接收到的所述行车环境感知数据并获取对应的合法用户编码以确定是否是合法用户,是则分别向路端通信单元以及路端控制单元发送合法用户通知即身份认证通过;所述第一路端感知单元能够接收行车环境感知数据,并判断当前的客运车辆是否属于第一感知限制状态,是则基于路端行车策略获取第一行车控制数据并发送至路端控制单元;所述第二路端感知单元能够获取第二行车控制数据并发送至路端控制单元;所述路端控制单元能够在身份认证通过时,提取所述合法用户编码,并为所述合法用户编码配置独立的数据处理运行环境,同时在所述数据处理运行环境下,基于第一行车控制数据、第二行车控制数据形成所述合法用户编码对应的行车控制数据,并通过路端通信单元分别向所述中央控制器、云平台发送。
11.根据权利要求10所述的客运车辆的双域电子电气架构,其特征在于,
所述第一感知限制状态是指行车安全隐患状态,包括但不限于相邻车道存在障碍物和或客运车辆前进方向存在障碍物,使得在客运车辆的行车视域范围内不能获得完整的客运车辆行车安全数据包;所述路端行车策略包括若处于第一感知限制状态时,获取路侧监测设备内的检测数据并形成第一行车控制数据;若出于非第一感知限制状态时,直接获取行车环境感知数据并形成第一行车控制数据。
12.根据权利要求10所述的客运车辆的双域电子电气架构,其特征在于,
所述第二路端感知单元能够与路侧监测设备通信,获取客运车辆前进方向一定范围内的道路信息,并形成第二行车控制数据发送至路端控制单元;所述道路信息至少包括道路拥堵数据。
13.根据权利要求12所述的客运车辆的双域电子电气架构,其特征在于,
所述道路信息还包括路面本体状态数据以及路面气象信息。
14.根据权利要求9所述的客运车辆的双域电子电气架构,其特征在于,
所述车载环境感知单元包括但不限于多种类型的环境感知传感器以及摄像头模块;所述环境感知传感器至少包括毫米波雷达、激光雷达、超声波雷达。
15.根据权利要求10所述的客运车辆的双域电子电气架构,其特征在于,
所述路端中转控制系统还包括路端运维监测单元,所述路端运维监测单元能够在路端控制单元处于闲时状态时,与中央控制器进行通信,用于获取车端传感器网络所获取的设备运行信号,并对设备运行信号进行特征提取,获取设备运行特征并进行预警诊断,同时能够对基于预警诊断结果确定设备运行状态是否异常并进行故障预警。
16.根据权利要求15所述的客运车辆的双域电子电气架构,其特征在于,
所述路端运维监测单元包括数据处理模块、数据分析模块以及运维决策模块;所述数据处理模块用于对设备运行信号中的运行日志数据进行清洗和标准化处理;所述数据分析模块用于基于处理后的运行日志数据并进行特征提取以获取对应的设备运行特征数据;所述运维决策模块用于根据所述设备运行特征进行预警诊断即确定设备运行特征的异常度,同时能够对基于预警诊断结果确定设备运行状态是否异常并进行故障预警。
17.一种客运车辆的双域电子电气架构工作方法,其特征在于,包括:
基于车辆智能座舱控制域接收多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果通过CAN总线和以太网向车辆行车驾驶控制域发送控制指令,所述控制指令同步备份至数据存储器;
通过车辆行车驾驶控制域接收所述车辆智能座舱控制域发送的控制指令,对所属控制指令进行解析后,根据所述控制指令控制车辆的行驶中的驱动、制动、转向功能。
18.根据权利要求9所述的客运车辆的双域电子电气架构工作方法,其特征在于,
根据运算结果向所述车辆调度系统发送车辆的调度指令包括:
获取目标区域的客流信息;所述客流信息包括乘客数量、每一乘客对应的目的地和预乘车时间;
根据所述客流信息确定出预计调度信息,所述预计调度信息包括每一目的地对应的可调度公交类型和数量;
根据所述预计调度信息,确定出调度方案;所述调度方案用于形成调度指令。
19.根据权利要求9所述的客运车辆的双域电子电气架构工作方法,其特征在于,
根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述设备运维系统发送车辆运维指令包括:
获取车辆信息采集设备上报的信息中的故障事件信息,故障事件信息包括:故障区域的标识及故障区域的定位位置;
根据故障区域的定位位置获取标识对应的故障区域的车辆运维指令;
所述设备运维系统接收车辆运维指令并根据车辆运维指令发出告警响应。
20.根据权利要求9所述的客运车辆的双域电子电气架构工作方法,其特征在于,
车辆信息管理单元基于通讯定位技术获取并实时记录车辆行车状态以实现公交系统的智能化运营管理,最大限度地优化公交系统的运行,所述车辆行车状态至少包括车况数据、定位信息、到站信息、视频监控、营运记录、行驶记录数据。
21.根据权利要求9所述的客运车辆的双域电子电气架构工作方法,其特征在于,
所述通讯定位技术至少包括GPS/北斗定位技术、网络通信技术、物联网技术。
22.根据权利要求9所述的客运车辆的双域电子电气架构工作方法,其特征在于,
根据多个车辆信息采集设备上传的信息,并将所述多个采集设备的信息进行融合后运算,根据运算结果向所述车辆信息发布系统发送显示指令包括:
车辆运行到指定位置车辆信息采集设备向中央控制器自身标识信号、车辆位置以及速度,
中央控制器根据收到的自身标识信号、车辆位置以及速度确定出相应的到达站点和到站时间形成显示指令并向到达站点的车辆信息发布系统发送,以使其显示相应公交车的线路号、车序号、当前的到达站点、到站时间。
23.一种基于权利要求1-16任意一项所述客运车辆的双域电子架构的客运车辆,其特征在于,包括:整车车身以及能够对整车车身进行集中控制的双域电子结构。
CN202310895409.3A 2023-06-16 2023-07-20 一种客运车辆的双域电子电气架构、工作方法及客运车辆 Active CN117022146B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2023107188928 2023-06-16
CN202310718892 2023-06-16

Publications (2)

Publication Number Publication Date
CN117022146A true CN117022146A (zh) 2023-11-10
CN117022146B CN117022146B (zh) 2024-06-11

Family

ID=88623571

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310895409.3A Active CN117022146B (zh) 2023-06-16 2023-07-20 一种客运车辆的双域电子电气架构、工作方法及客运车辆

Country Status (1)

Country Link
CN (1) CN117022146B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118093640A (zh) * 2024-04-19 2024-05-28 南京牧镭激光科技股份有限公司 一种基于民航激光测风雷达的集成软件系统

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190156668A1 (en) * 2016-08-11 2019-05-23 Jiangsu University Driving service active sensing system and method in internet of vehicles environment
CN111210618A (zh) * 2018-11-22 2020-05-29 南京锦和佳鑫信息科技有限公司 自动网联公交道路系统
CN112289059A (zh) * 2020-10-22 2021-01-29 中电智能技术南京有限公司 一种车路协同道路交通系统
CN112429012A (zh) * 2020-10-30 2021-03-02 北京新能源汽车技术创新中心有限公司 汽车电控系统、自动驾驶控制方法及汽车
CN113066299A (zh) * 2021-03-25 2021-07-02 上海智能新能源汽车科创功能平台有限公司 一种基于车路云一体的客运数字交通系统
WO2022063331A1 (zh) * 2020-09-25 2022-03-31 金龙联合汽车工业(苏州)有限公司 一种基于v2x的编队行驶智能网联客车
US20220319333A1 (en) * 2020-04-29 2022-10-06 Casco Signal Ltd. Cloud simulation apparatus and method for verifying rail transit-oriented full-automatic unmanned driving scene
CN115320621A (zh) * 2022-08-18 2022-11-11 科大国创极星(芜湖)科技有限公司 支撑软件定义汽车的车辆电子架构及其工作方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190156668A1 (en) * 2016-08-11 2019-05-23 Jiangsu University Driving service active sensing system and method in internet of vehicles environment
CN111210618A (zh) * 2018-11-22 2020-05-29 南京锦和佳鑫信息科技有限公司 自动网联公交道路系统
US20220319333A1 (en) * 2020-04-29 2022-10-06 Casco Signal Ltd. Cloud simulation apparatus and method for verifying rail transit-oriented full-automatic unmanned driving scene
WO2022063331A1 (zh) * 2020-09-25 2022-03-31 金龙联合汽车工业(苏州)有限公司 一种基于v2x的编队行驶智能网联客车
CN112289059A (zh) * 2020-10-22 2021-01-29 中电智能技术南京有限公司 一种车路协同道路交通系统
CN112429012A (zh) * 2020-10-30 2021-03-02 北京新能源汽车技术创新中心有限公司 汽车电控系统、自动驾驶控制方法及汽车
CN113066299A (zh) * 2021-03-25 2021-07-02 上海智能新能源汽车科创功能平台有限公司 一种基于车路云一体的客运数字交通系统
CN115320621A (zh) * 2022-08-18 2022-11-11 科大国创极星(芜湖)科技有限公司 支撑软件定义汽车的车辆电子架构及其工作方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118093640A (zh) * 2024-04-19 2024-05-28 南京牧镭激光科技股份有限公司 一种基于民航激光测风雷达的集成软件系统

Also Published As

Publication number Publication date
CN117022146B (zh) 2024-06-11

Similar Documents

Publication Publication Date Title
CN111524357B (zh) 用于车辆安全行驶所需的多数据融合的方法
KR102366795B1 (ko) 차량 플랫폼을 위한 장치 및 방법
CN111524362B (zh) 基于多数据融合的车辆安全行驶保障系统与方法
US20200026289A1 (en) Distributed traffic safety consensus
US20190205115A1 (en) Systems and methods for secure and safety software updates in the context of moving things, in particular a network of autonomous vehicles
US20180090009A1 (en) Dynamic traffic guide based on v2v sensor sharing method
CN117173884A (zh) 针对混合式集体感知和地图众包的方法和系统
CN111179617B (zh) 一种智能网联车的车载单元
CN109017757A (zh) 汽车远程代驾方法及系统
CN103890730A (zh) 用于传感器驱动的车辆遥测应用和服务的开发和部署的计算平台
EP3895950B1 (en) Methods and systems for automated driving system monitoring and management
JPWO2019077999A1 (ja) 撮像装置、画像処理装置、及び、画像処理方法
CN110576808B (zh) 车辆、车机设备及其基于人工智能的场景信息推送方法
CN117022146B (zh) 一种客运车辆的双域电子电气架构、工作方法及客运车辆
CN112073936A (zh) 用于网络节点通信的系统和方法
US20210354722A1 (en) Autonomous vehicle and driving control system and method using the same
CN118104211A (zh) 用于测试云和车载自主车辆系统的系统、方法和计算机程序产品
WO2021241189A1 (ja) 情報処理装置、情報処理方法、およびプログラム
CN110793537A (zh) 一种导航路径推荐方法、车机及车辆
Vermesan et al. IoT technologies for connected and automated driving applications
CN115348657A (zh) 用于车辆时间同步的系统架构、方法及车辆
CN115179879A (zh) 车辆自唤醒方法、装置、车辆及存储介质
CN113359724B (zh) 基于无人机的车辆智能驾驶系统、方法及存储介质
CN112017459A (zh) 车辆、车机设备及其信号灯识别的驾驶辅助方法
WO2020248136A1 (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
GR01 Patent grant
GR01 Patent grant