以下介绍系统启动类的常见问题解答。因版本差异，问题原因及解决方案可能有所不同。若下述方法不适用，请及时联系技术支持工程师协助处理。1、反复重启问题描述计算平台设备反复重启，重启间隔约5分钟一次，复位时系统状态正常。原因分析异常时查询主备区与版本号，发现主区版本号部分显示异常，可能与反复重启有关。解决方案1、强制切区，到备区重新升级设备。2、多次执行busybox reboot后切到备区sde5，并再次查询版本号，显示正常。3、在备区执行同版本升级操作，升级后验证设备未出现反复重启。2、OOM引起异常重启问题描述出现非预期的异常重启（已提供 /opt/log/aos_linux/ 目录下全量日志）原因分析分别查看kernel.log & SOC_A.log。/opt/log/aos_linux/os_log/kernel.log 中，提供绿框中的单调递增时间的回退，可以看到辅助驾驶计算平台在20260811-074045秒时有重启。/opt/log/aos_linux/os_log/start_info/SOC_A.log日志显示OS_PANIC，说明有异常复位。查看问题时间点前后的kernel.log日志逻辑，看到有oom打印。之后继续在该文件中看哪个进程占用内存比较多，看rss列，如下图 hmi* 进程占用资源最多。解决方案hmi开头的进程占用资源有异常，接近8GB。需要优先排查这个进程是否有内存泄漏。3、过温引起的异常重启问题描述出现非预期重启（已提供 /opt/log/aos_linux/ 目录下全量日志）原因分析1、分析kernel.log日志。查看/opt/log/aos_linux/os_log/kernel.log，在问题时间点有reboot_reason=DEVICE_COLDBOOT的打印，显示是冷启动。2、分析start_info.log日志。/opt/log/aos_linux/os_log/start_info/start_info.log日志中，也有reboot_reason=DEVICE_COLDBOOT的打印，显示是冷启动。3、分析MCU_RUN.log日志。找到问题时间点的MCU_RUN.log，先使用mdc-tool log-convert命令解析日志。在解析后的MCU_RUN.log中，过滤关键字Temps，可以看到设备的温度信息。日志显示问题时刻MDC已经过温，该次重启可以定位为过温重启。解决方案检查对端液冷设备是否正常接入。4、命令行误操作引起的重启问题描述出现非预期的重启（已提供 /opt/log/aos_linux/ 目录下全量日志）原因分析1、分析kernel.log 日志查看/opt/log/aos_linux/os_log/kernel.log，在问题时间点单调递增时间有回退，显示确实有重启。 2、分析SOC_A.log 日志/opt/log/aos_linux/os_log/start_info/SOC_A.log 日志中，有 reboot_reason=DEVICE_COLDBOOT的打印，显示是冷启动。 3、分析history.log日志查看/opt/log/aos_linux/os_log/history_cmd/history.log日志，在问题时刻，有执行过mdc-dbg  sm  reset hard 1。该命令会使辅助驾驶计算平台设备重启。解决方案检查有无其他工作人员执行过mdc-dbg sm reset hard 1命令。5、进程长时间处于D状态导致异常重启问题描述辅助驾驶计算平台设备重启，kernel日志显示OS_panic。已采集/opt/log/aos_linux/目录下全量日志。原因分析1、系统异常重启先看黑匣子日志history.log，黑匣子日志存放路径：/opt/log/aos_linux/hisi_log/hisi_logs/device-0/history.log，记录系统重启的原因以及时间。异常原因OS_PANIC：一般是软件问题导致的故障重启，需要进一步定位。2、确定重启原因，根据步骤1中所看到的复位原因记载的时间戳（如上图OS_PANIC后面的TimeStamp [20250212122719-475542119]），在具体路径下查看aos_linux_kbox.txt。进入hisi_logs/device-0/20250212163305-612333143/bbox/路径下查看，aos_linux_kbox.txt中可以搜索关键字Call trace具体定位发生故障重启的位置。日志显示进程eq_log_writer长时间处于D状态导致的异常重启。解决方案检查进程eq_log_writer 是否长时间处于D状态。建议专门起一个线程用于跟踪系统上进程状态。说明：hungtask是Linux内核的一个标准功能，用于检测进程长时间处在D状态（不可中断睡眠状态）的情况，为定位进程异常提供一个维测方法。通过hungtask可以检测 mutex、semaphore和rw_semaphore三种场景。6、输入电压低引起异常重启问题描述SoC有异常重启，MCU未重启（已提供/opt/log/aos_linux/目录下全量日志）原因分析1、查看kernel日志中有设备异常重启的记录。2、查看串口日志/opt/log/aos_linux/os_log/start_info/中有reboot_reason = DEVICE_COLDBOOT冷复位的日志打印。3、查看MCU_RUN日志，在SoC复位时刻，检测到MCU侧电压由12V降低到8V，这时SoC撑不住，发生掉电。解决方案检查电源有无波动。7、启动程序时报错问题描述使用pmupload启动程序或执行其他mdc-tool/mdc-dbg命令时，报[error]: connect process-manager Failed cannot upload app! errno:2错误。具体如下图所示：原因分析该问题需要采集操作日志/home/var/log/history与middleware日志/home/var/log/middleware。查看history.log日志，发现由于误操作，执行rm -r /dev/shm/* 命令，此命令会删除 /dev/shm/文件夹下的所有文件，包括负责和pm通信的管道。解决方案重新升级版本。

以下介绍以太网络类的常见问题解答。因版本差异，问题原因及解决方案可能有所不同。若下述方法不适用，请及时联系技术支持工程师协助处理。1、无法通过SSH登录问题描述修改/opt/cfg/conf/nrm/路径下lab_debug_net.yaml中调试网卡的IP，由192.168.30.42 改为了192.168.100.53后，无法SSH登录设备。原因分析拆板，加串口后，使用ifconfig命令查看，B4口IP是192.168.100.53，netmask是255.255.252.0上位机IP配置为192.168.100.100，netmask配置为255.255.255.0时ping不通设备，继续查看ifconfig命令回显。发现eth0.12的IP也是192.168.100.53，可能是IP冲突导致上位机使用192.168.100.100时ping不通。执行ifconfig eth0.12 down关闭网卡，再通过192.168.100.100来ping设备，可以ping通了。 解决方案修改eth0.12 或 ethg1口的IP，解决IP冲突问题。2、B4口设置两个IP问题描述如何在B4口设置两个IP，且这两个IP都可以ping通？解答在自定义的网络配置文件目录/opt/usr/app/1/gea/conf/net/usr/修改配置文件usr_eth_soc_nic_flow.json。[root@AOS usr]# cd /opt/usr/app/1/gea/conf/net/usr/; lltotal32K-r--r-----1rootroot2.8KJun2302:10usr_can.json-r--r-----1rootroot524Jun2302:10usr_eth_iptables.rules-r--r-----1rootroot1.2KJun2302:10usr_eth_lanswitch.json-r--r-----1rootroot2.5KJun2302:10usr_eth_lanswitch_port.json-r--r-----1rootroot1.5KJun2302:10usr_eth_panel.json-r--r-----1rootroot3.5KJun2302:18usr_eth_soc_nic_flow.json-r--r-----1rootroot2.4KJun2302:10usr_eth_tc.rules-r--r-----1rootroot201Jun2302:10usr_uart.json[root@AOSusr]#vimusr_eth_soc_nic_flow.json在B4节点做如下修改：130       {131"PortName":"B4",132"Label":[],133"NicList":[134{135"NicName":"ethg1",136"FlowList":[137{138"Label":[],139"IP":"192.168.30.42/24",140"SubIntf":[{ 141"ID":1, 142"IP":"192.168.33.42/24"143}]144}145]146}147]148},修改后执行命令pmupload nrm_init check_config，验证配置文件是否合法，之后断电重启计算平台使配置文件生效。修改后，新增ethg1:1，如下图所示：3、去掉所有网卡的VLAN标签问题描述如何去掉所有网卡的VLAN标签？解答将默认网络配置文件“/opt/platform/mdc_platform/conf/net/usr”默认路径拷贝至指定路径“/opt/usr/app/1/gea/conf/net/usr”下，再进行修改，系统会在启动时优先调用。主要修改usr_eth_soc_nic_flow.json 和 usr_eth_lanswitch_port.json 这两个配置文件。 修改usr_eth_soc_nic_flow.json（左边是原始文件，右边是修改后的文件）修改usr_eth_lanswitch_port.json（左边是原始文件，右边是修改后的文件）4、版本回退后，无法SSH登录问题描述由1.1.0xx回退到1.1.0xx版本后，执行mdc_cfg.sh脚本，上下电重启设备，发现SSH登录不上。原因分析1、串口登录设备。 若使用液冷设备（没有串口），需先把设备寄回，拆板加串口进行排查。设备寄回供应商侧，拆板，加串口。通过串口登录设备，ifconfig查看，系统网卡都没有正常初始化。                      2、网卡初始化失败排查。查看网络初始化日志/opt/log/aos_linux/platform_log/nrm/nrm_init.log，日志中有如下报错，显示自定义的网络配置文件有问题。截图如下：进到用户自定义的网络配置目录下，相关的网络配置文件除usr_network_port.json都是空文件。如下截图中红框所示：目前可以确认设备网络不通是由于用户自定义的网络配置目录下有很多空文件，导致网络初始化失败。3、网络配置文件为空问题排查。 关于网络配置相关的脚本是 mdc_cfg.sh。mdc_cfg.sh中关于修改网络的代码如下：cd /opt/usr/app/1/gea/; rm -fr confmkdir-p/opt/usr/app/1/gea/confcp-r/opt/platform/mdc_platform/conf/net/opt/usr/app/1/gea/conf/cd/opt/usr/app/1/gea/conf/net/;ll脚本执行完成后，没有执行sync操作就直接对设备进行下电操作，导致网络相关配置文件没及时写到磁盘上。解决方案在自定义的网络配置脚本中加sync命令。在Linux 环境中，sync命令的作用是将文件系统缓冲区（page cache）中的数据强制写入磁盘，确保内存中的未持久化数据被立即保存，避免因系统崩溃或断电导致数据丢失。 

以下介绍CAN网络类的常见问题解答。因版本差异，问题原因及解决方案可能有所不同。若下述方法不适用，请及时联系技术支持工程师协助处理。1、tcpdump抓CAN包，文件大小是0KB问题描述使用tcpdump抓取CAN9通路上的数据，并保存为文件。停止抓包后，文件大小是0KB 。但通过netstat和ifconfig查看通路状态，收发均有数据。原因分析用tcpdump在Linux上抓包完成后，抓包的大小为0。一般的原因为磁盘空间不足。使用df -h命令，查看磁盘的可用空间是0，确认是磁盘的原因。解决方案清理磁盘空间。2、MCU上CAN0问题问题描述对mcu_can数据做校验，存在很多时间戳为0或者异常的时间戳，进一步观测分析数据，发现存在部分不正常数据，can id为0，数据长度为0，crc值为0。进一步观测分析发现这种情况只出现在数据包较大的时候，比如数据包超过16帧，是计算平台的mcu_can上传的Can(Fd)报文个数有限制吗？原因分析1、 抓包使用candump工具进行抓包，抓包命令： ./candump can9 > can9.log。−    正常包−     异常包2、抓包分析，通过上述异常包的分析，显示candump抓到的包是完整的，问题可能是上层解析所引入，需排查上层业务逻辑。3、 继续排查上层业务逻辑，发现定义的接收端缓存BUF_LEN值是256，一个Can(Fd)Frame长度是16个字节，遇到Can(Fd)报文个数超过16的CANTP报文时，数据会溢出，导致问题发生。解决方案根据实际业务使用，将接收端缓存BUF_LEN值调大。   

以下介绍媒体数据处理类的常见问题解答。因版本差异，问题原因及解决方案可能有所不同。若下述方法不适用，请及时联系技术支持工程师协助处理。1、hi_mpi_venc编码出错问题描述参照产品文档中的API，使用VPC处理图像后，使用hi_mpi_venc系列函数编码出来的视频异常（左右重复+横向的黑色条）。摄像头输出的是YUV422的图像，先用接口hi_mpi_vpc_convert_color_to_yuv420转成YUV420后再送去编码。图像长宽分别是1920与1080，满足API要求。下图左侧是正常编码后的图像，右侧是使用hi_mpi_venc系列接口编码后的图像。原因分析YUV422格式的视频转为YUV420格式时出错。解决方案 1、保存编码前的视频数据。将通过 hi_mpi_venc_send_frame 接口编码前的原始数据保存为 input.yuv文件，使用 YUV 查看工具打开生成的文件，如下图所示。由此可知，送入编码前的 YUV 数据存在问题。使用YUV查看工具，看生成的文件input.yuv，如下图所示：图1 转码后异常图像2、 保存hi_mpi_vpc_convert_color_to_yuv420转码前的原始数据。如下图，显示转码前数据是正常的。图2 转码前正常图像3、转码过程排查。转码前数据正常，转码后数据异常，重点排查转码过程。重点排查转码配置。排查后发现width_stride未正确赋值，下图是出错时的width_stride值。参见《产品文档》“hi_mpi_vpc_convert_color_to_yuv420”章节中图片格式的宽高对齐约束，修改width_stride值，如下图所示：4、width_stride值修改后，验证编码后图像，显示正常。此次编码后视频出错的原因为在调用hi_mpi_vpc_convert_color_to_yuv420函数把YUV422格式的视频转为YUV420格式时出错，自行修改代码后解决。 2、hi_mpi_venc_get_stream接口报错问题描述把gop和dst_frame_rate两个参数值分别从60和30调整到50和25后，hi_mpi_venc_get_stream接口报a0088003错误。调整之前编码出来的图像是正常的。下图为参数调整和报错截图。原因分析 从日志打印来看，在调用函数hi_mpi_venc_get_stream时收到错误码0xA0088003。1、查询产品文档手册，错误码0xA0088003表示参数超出合法范围。2、使用dmesg命令查看DVPP库的日志报错如下图所示：3、 进一步定位，发现由于创建编码器时，输入码流的帧率与输出码流的帧率不一致。输入帧率是30，输出帧率是25。解决方案出现报错是由于创建编码器时，输入码流的帧率与输出码流的帧率不一致，统一输入输出帧率即可解决问题。3、hi_mpi_vpc_lut_remap接口报错问题描述使用函数hi_mpi_vpc_lut_remap，但一直报a0078003错误。原因分析再次复现问题，查看/opt/log/aos_linux/hisi_log/debug目录下DVPP开头的日志，在DVPP中已有日志，如下图所示：经分析，输入图片的格式不对。查看产品文档中“hi_mpi_vpc_lut_remap”章节，目前该接口只支持YUV格式数据，不支持RGB格式数据。解决方案修改输入图片的格式，由RGB格式数据修改为YUV格式数据。4、hi_mpi_venc_get_stream接口问题问题一问：通过接口hi_mpi_venc_get_stream获取编码后的H265码流，下图是编码的关键帧信息，红框开始是VPS/PPS头信息，前面64字节是什么信息？答：是否没有偏移offset去取码流，前面的是无效数据。问题二问：通过hi_mpi_venc_get_stream接口取到编码后数据，打印了一下输出参数hi_venc_stream结构体的offset，IDR的offset特别大，有515，这个正常吗？答：这是正常现象。由于采用单包模式，I 帧会将 VPS/SPS/PPS 紧凑拷贝到 I slice 之前，因此前部的 offset 值较大。正确的做法是从 offset 处开始读取码流。问题三问：打印通过hi_mpi_venc_get_stream接口获取的编码数据的data_type，发现只有P(1)帧和IDR(19)帧，没有I帧，是正常的吗？答：正常，I帧都是IDR帧。 5、hi_mpi_vpc_set_chn_workspace接口报错问题描述hi_mpi_vpc_set_chn_workspace接口报错，错误码为a0078003，代码片段与业务层日志截图如下：原因分析查询产品文档，错误码a0078003表示对应参数超出合法范围。查看/opt/log/aos_linux/hisi_log/debug目录下DVPP日志：[ERROR] DVPP(9055,camera_app):2022-03-26-01:47:30.038.229 [mpi_vpc_adapt.c:4638][HiDvpp][A631] param_count[2] should be 1[ERROR]DVPP(9055,camera_app):2022-03-26-01:47:30.038.241[mpi_vpc_adapt.c:4692][HiDvpp][A631]Error0xa0078003:deviceid0userchnid2workspaceparamfail.[ERROR]DVPP(9055,camera_app):2022-03-26-01:47:30.044.564[mpi_vpc_adapt.c:4638][HiDvpp][A631]param_count[2]shouldbe1[ERROR]DVPP(9055,camera_app):2022-03-26-01:47:30.044.576[mpi_vpc_adapt.c:4692][HiDvpp][A631]Error0xa0078003:deviceid0userchnid5workspaceparamfail.hi_mpi_vpc_set_chn_workspace接口的第三个参数需要填入1。解决方案按照DVPP日志中报错指示，把hi_mpi_vpc_set_chn_workspace接口的第三个参数由2改为1后问题解决。6、hi_mpi_vpc_lut_remap后相机不出流问题描述调用hi_mpi_vpc_lut_remap接口后，相机断流。原因分析1、代码逻辑a.     主函数逻辑：接收到相机数据后的总体逻辑b.      resize操作c.       remap操作d.         各操作间时间差值打印2、问题堆栈打印3、问题根因调用hi_mpi_vpc_lut_remap接口后，未接着调用hi_mpi_vpc_get_process_result接口获取remap的处理结果，导致数据堆积。解决方案调用hi_mpi_vpc_lut_remap接口后，接着调用hi_mpi_vpc_get_process_result接口获取remap的处理结果，防止数据堆积。 7、hi_mpi_venc_send_frame接口报错问题描述调用hi_mpi_venc_send_frame接口，出现failed, err code: -1610055677报错。原因分析使用计算器转换，发现err code: -1610055677对应 0xA0088003，HI_ERR_VENC_ILLEGAL_PARAM参数超出合法范围。启动相机采集及编码程序，使用命令dmesg查看内核日志，有如下打印：显示创建编码通道时使用的是3840*2160的分辨率，实际传入的是1920*1080的码流。继续排查，发现是代码问题，创建编码通道时使用的分辨率与实际码流的分辨率不一致。解决方案创建编码通道时传入正确的码流参数后问题解决。8、HafMemcpyToDvpp 接口报错误码107002问题描述使用HafMemcpyToDvpp接口时有报错，错误码是107002。原因分析查看/opt/log/aos_linux/hisi_log/debug/RTS*日志，有报错context pointer null，表示没有设置过上下文。产品文档“DVPP类接口”章节中有如下说明：在子线程中使用DVPP类接口，需要先创建context，或者set（调用HafSetCurrentContext）一个已创建好的context（比如HafInitialize接口使用的context）。解决方案未调用HafSetCurrentContext，在调用HafMemcpyToDvpp接口前先调用HafSetCurrentContext接口。

以下介绍时间同步类的常见问题解答。因版本差异，问题原因及解决方案可能有所不同。若下述方法不适用，请及时联系技术支持工程师协助处理。 1、上报1636故障 问题描述2026/5/24-11:50:22秒附近，出现安全域时间同步异常的告警，告警上报时间点同时打印了几帧时间跳变的日志。告警信息如下图绿框所示： 原因分析可能有其他进程在改时间。解决方案获取如下日志交由技术支持人员进一步分析。history日志路径：/opt/log/aos_linux/os_log/history_cmd/history.logaudit日志路径（可用于排查是否有人调用系统的clock接口）：/opt/log/aos_linux/os_log/audit/audit.log2、tsync_ap.json文件配置后没有CAN包问题描述使用平台提供的定制化配置时间同步功能，完成tsync_ap.json文件配置后，抓包并未发现CAN的时间同步报文。相关配置如下，左侧为修改后的配置，右侧为默认配置。原因分析把线束的CAN8外接CAN设备，模拟外接设备。再通过SSH方式登录辅助驾驶计算平台。执行命令 ./candump -t AH -dex "can6,0:0"，有如下数据，验证配置文件正常。16进制数2F6对应10进制数758，即配置文件里配置的canId，如上图所示；去除CRC校验就是10 18；有CRC校验是20 28。5F4C3182对应时间戳秒信息，转为10进制为1598828930使用命令date -d @1598828930继续转变为Sun Aug 30 11:08:50 PM UTC 2020，可与下图中左侧框中时间对应。13F2446A，转为10进制为334644330，对应整秒后的信息。图1 去除CRC校验示例 图2 有CRC校验示例 进一步排查环境，CAN对端未连接相应设备。解决方案CAN对端也要接上相应的设备。3、 配置tsync_ap.json后数据面时间同步失败问题描述替换文件tsync_ap.json后，使用命令mdc-tool tsync DPS -g查询数据面时间同步情况，报“DP is TimeOut status.”，时间同步失败。原因分析配置文件tsync_ap.json中配置项globalTimeMaster中关于TIME_BASE_DP的网卡名未正确配置。辅助驾驶计算平台上没有名为eth1的网卡，需按实际填写。解决方案修改配置文件tsync_ap.json中“globalTimeMaster”中关于“TIME_BASE_DP”的网卡名配置。4、激光雷达时间同步失败问题描述使用禾赛JT128型号的激光雷达，与计算平台之间的时间同步一直失败。（已知：JT128使用的是标准802.1as协议，需要计算平台发announce报文才可以同步。）原因分析目前辅助驾驶计算平台不支持开启BMCA发送announce报文。解决方案联系技术支持人员临时开启BMCA算法。须知：临时开启BMCA算法，仅用于调试环境，不能用于正式生产环境。 5、禾赛JT128（激光雷达）时间同步失败问题描述激光雷达接在辅助驾驶计算平台的视频A1口，辅助驾驶计算平台当前已可以收到激光雷达数据包。通过抓包命令tcpdump抓取数据包，分析数据包中雷达数据到达时间戳与雷达数据包内时间戳不一致。原因分析激光雷达发送的消息不符合要求。解决方案1、个时间同步正常的环境，与异常环境，同时抓包。2、分析抓包文件，发现异常环境激光雷达发送的是delay_req消息，不符合要求，需发送pdelay_req。 3、自行联系激光雷达厂商处理。6、如何通过gptp进行管理面的时间同步问题描述如何让惯导作为MASTER节点 ，辅助驾驶计算平台作为SLAVE节点 ，通过gptp进行管理面的时间同步。解答1、进入辅助驾驶计算平台的“/opt/platform/mdc_platform/conf/tsync_center/tsync_a/”目录。打开tsync_mp_gptp_config.json，修改totalPortNumber字段为1，修改nicName字段为对应连接车载网关的网卡名。2、打开tsync_mp_config.json，修改syncType字段为MP_SYNC_GPTP。3、执行mdc-dbg em restart ExtRegProcess，重启时间同步进程。4、执行如下命令，确认管理面时间是否同步成功。mdc-tool tsync MP -g：查看当前管理面时间。mdc-tool tsync MP -s 1600000000 0：手动修改管理面时间。mdc-tool tsync MP -g：再次查询管理面时间，判断修改是否成功。7、升级版本后，出现“MP is TimeOut status”问题问题描述执行命令mdc-tool tsync MPS -g，回显MP is TimeOut status。该回显表明可能时间同步进程ext_reg未收到GNSS或PPS消息，管理面时钟未同步。原因分析1、查看时间同步数据订阅情况。数据发布端CanNodeProcess[AOS]每秒钟发布一次消息，说明发端正常。数据订阅端ExtRegProcess[AOS]却没有收到数据。图1 订阅关系参考图2 时间同步消息发送2、发布端与订阅端进程号确认。执行ps aux | grep can_node 获取发端进程号为 8928。执行ps aux | grep ext_reg 获取订阅端进程号为 6378。3、进入“/home/var/log/”，取rcs.log*日志。4、确认问题，发布端创建的共享内存，订阅端无权限访问。查看共享内存文件属主。用于通信的共享内存文件的属主是root，而时间同步进程ext_reg的属主是mdc。解决方案 1、把共享内存文件属主改为mdc。2、再次执行mdc-tool tsync MPS -g验证，正常同步。 8、如何验证Lidar时间同步功能问题描述如何验证Lidar时间同步功能？解答Lidar点云数据自带时间戳，Lidar与MDC时间同步成功后，点云数据帧中携带的时间戳与MDC系统时间戳一致，利用此性质，可以验证Lidar时间是否与MDC同步。即tcpdump抓取Lidar点云数据，若Lidar数据帧中携带的时间戳与tcpdump记录的系统时间戳一致，表示Lidar时间与MDC同步成功。1、执行命令tcpdump -i eths0 -nn -w s0.pcap抓包几秒后退出，得到s0.pcap文件。（eths0仅用作举例说明，根据需要验证的Lidar，替换成对应的网卡名。）2、调整wireshark时间显示格式：使用 wireshark 打开上述文件，按照下图配置时间显示格式。3、对比时间戳找到任意 Lidar 数据帧，将抓包得到的系统时间（红色框）与 Lidar数据帧自带的时间戳（黄色框）进行对比，如果相同，则证明 Lidar 时间同步成功，如下图所示。说明：对于不同型号的Lidar，Lidar数据帧自带的时间戳在报文中的位置不一致，可通过查询Lidar手册确认。若没有 Lidar手册，可根据tcpdump的时间戳（如图中的 1657301206）将其转换为 HEX 62C868D6。若能在点云数据帧中找到 62C868D6，即可证明 Lidar 同步成功。通常时间戳在Lidar数据帧靠前三分之一的位置。9、管理面时间跳变 问题描述出现管理面时间跳变。 、原因分析查看/opt/log/aos_linux/platform_log/debug/目录下ECTM开头的日志，在ECTM日志中有如下打印：GNSS's UTC message not received for more than 1.5s表明时钟源有问题，同时GNSS消息也有丢失，不连续。解决方案自行排查时钟源问题。                                                                                         

各位伙伴：今年，我们对官网伙伴栏目进行了多轮优化。本次发帖，主要想邀请各位抽出约 1 分钟，参与页面的 笑脸评价，帮助我们发现问题、持续优化。以下是具体操作步骤，按顺序对照截图即可完成。第一步：进入合作伙伴页面从官网导航进入伙伴页面，页面加载后即可看到 [右侧] 的笑脸评价入口。第二步：选择对应分数在评价入口处选择对应分数。分数对应整体满意度，点选即可。第三步：勾选反馈模块并提交选择分数后，勾选您希望反馈的模块，具体陈述您的建议或遇到的问题。如在浏览过程中发现信息查找不便、展示异常，或有其他建议，也欢迎在本帖下方留言反馈。我们会统一整理，作为后续优化的参考。感谢各位的支持与配合。 👉 【官网视觉与内容】合作伙伴页面上新与页面优化-云社区-华为云，邀您探索华为云伙伴官网全新体验与惊喜！附 – 已上线合作伙伴栏目页面清单类别页面URL（中国站现网）首页伙伴首页cid:link_16政策类合作政策聚合页cid:link_8成为软件伙伴cid:link_0成为服务伙伴cid:link_5成为学习与赋能伙伴cid:link_4成为SI伙伴cid:link_2成为解决方案提供商cid:link_3成为总经销商cid:link_6成为云经销商cid:link_10伙伴资源类伙伴资源聚合页cid:link_7培训认证cid:link_14营销活动cid:link_13伙伴赋能资源cid:link_11客户类携手伙伴开展合作页cid:link_1伙伴案例cid:link_12查找合作伙伴cid:link_9 

近期，华为云计算有限公司（以下简称“我司”或“华为云”）发现有未经授权的组织及个人擅自使用“华为云计算技术有限公司”商标、标志、logo、公司名称等（以下简称“品牌”），对外开展各类会议营销、付费培训、付费咨询等活动，造成社会公众误解，严重损害华为云与客户的合法权益。为此，华为云郑重声明如下：一、华为云未授权任何主体使用华为云品牌，开展“华为云光合行动”“灵犀AI&华为云伙伴”“华为云灵界AI”“华为云灯塔计划”“华为云生态伙伴助力中国企业AI落地化”“中小企业AI落地分享会”等活动。所有未经华为云授权开展相关活动的行为，包括但不限于签订销售合同、于社交媒体发布广告、开展营销活动等，均属违法，与华为云无关。二、自本声明发布之日起，所有未经授权使用华为云品牌的行为应立即停止。对任何进行此类行为的组织及个人，华为云保留追究其法律责任的权利，包括但不限于向相关监管部门举报、提起民事诉讼或进行刑事报案，以维护华为云和客户的合法权益。三、请广大客户及合作伙伴在参与相关活动或开展合作、缴费前，通过华为云官网（www.huaweicloud.com）、华为云客服热线（950808）等途径核实相关主体的授权等情况，谨防损失。同时，欢迎社会各界向华为云提供相关线索或向相关部门进行举报，共同打击此类违法行为。特此声明！ 华为云计算技术有限公司2026 年 09 月 28 日

 尊敬的华为云合作伙伴：为持续助力合作伙伴团队打造云上技术核心竞争力，华为云推出系列伙伴赋能培训。课程由资深讲师团队授课，分享前沿行业技术与一线实战经验，帮助大家突破技术瓶颈。10 月培训具体计划详见下表，诚邀各位报名参与！课程名称报名截止培训时间开班地点课程摘要报名链接华为云AI智能体开发实战-深圳站2026/10/112026/10/15-2026/10/16深圳帮助学员掌握华为云上智能体构建核心工程方法论，熟练运用 AgentArts 平台实现智能体端到端开发搭建，并掌握智能体全生命周期的监控、评估与持续优化手段，形成从设计开发到运维迭代的完整落地能力。LinkFDE岗位的来龙去脉和业务实践分享/2026/10/15线上面向生态伙伴，围绕产品、解决方案、营销、热点话题等与伙伴分享交流，提升产品、解决方案的售卖能力。关注视频号看直播数据库工作级开发者认证培训HCCDP-GaussDB2026/10/82026/10/19-2026/10/23线上课程从数据库开发讲到日常运维等相关服务能力并应用实践。使您掌握数据库开发设计、高级SQL使用、性能调优以及日常运维的实践能力。LinkCloudRobo平台架构解析/2026/10/22线上面向生态伙伴，围绕产品、解决方案、营销、热点话题等与伙伴分享交流，提升产品、解决方案的售卖能力。关注视频号看直播人工智能工作级开发者认证培训HCCDP-AI2026/10/122026/10/26-2026/10/30线上课程涵盖人工智能基础、Transformer与大模型基础、大模型进阶与模型开发、大模型应用开发四大模块。使您掌握大模型核心算法原理，熟练使用ModelArts实现大模型微调与评测实践，具备基于Prompt/RAG的智能应用开发能力。Link华为云AgentArts智能体构建实战（初级）/2026/10/29线上面向生态伙伴，围绕产品、解决方案、营销、热点话题等与伙伴分享交流，提升产品、解决方案的售卖能力。关注视频号看直播 更多赋能活动，欢迎持续关注华为云伙伴赋能官网「培训活动日历」 Link

 尊敬的华为云合作伙伴：为持续助力合作伙伴团队打造云上技术核心竞争力，华为云推出系列伙伴赋能培训。课程由资深讲师团队授课，分享前沿行业技术与一线实战经验，帮助大家突破技术瓶颈。10 月培训具体计划详见下表，诚邀各位报名参与！课程名称报名截止培训时间开班地点课程摘要报名链接华为云AI智能体开发实战-深圳站2026/10/112026/10/15-2026/10/16深圳帮助学员掌握华为云上智能体构建核心工程方法论，熟练运用 AgentArts 平台实现智能体端到端开发搭建，并掌握智能体全生命周期的监控、评估与持续优化手段，形成从设计开发到运维迭代的完整落地能力。LinkFDE岗位的来龙去脉和业务实践分享/2026/10/15线上面向生态伙伴，围绕产品、解决方案、营销、热点话题等与伙伴分享交流，提升产品、解决方案的售卖能力。关注视频号看直播数据库工作级开发者认证培训HCCDP-GaussDB2026/10/82026/10/19-2026/10/23线上课程从数据库开发讲到日常运维等相关服务能力并应用实践。使您掌握数据库开发设计、高级SQL使用、性能调优以及日常运维的实践能力。LinkCloudRobo平台架构解析/2026/10/22线上面向生态伙伴，围绕产品、解决方案、营销、热点话题等与伙伴分享交流，提升产品、解决方案的售卖能力。关注视频号看直播人工智能工作级开发者认证培训HCCDP-AI2026/10/122026/10/26-2026/10/30线上课程涵盖人工智能基础、Transformer与大模型基础、大模型进阶与模型开发、大模型应用开发四大模块。使您掌握大模型核心算法原理，熟练使用ModelArts实现大模型微调与评测实践，具备基于Prompt/RAG的智能应用开发能力。Link华为云AgentArts智能体构建实战（初级）/2026/10/29线上面向生态伙伴，围绕产品、解决方案、营销、热点话题等与伙伴分享交流，提升产品、解决方案的售卖能力。关注视频号看直播 更多赋能活动，欢迎持续关注华为云伙伴赋能官网「培训活动日历」 Link

1月5日，华为云官网正式发布2026年生态政策，通过更精细化政策，更针对性的支持，赋能伙伴及开发者们不断成长、共创共赢，全方位构建更具活力与共赢价值的生态。2026年，华为云将以生态政策为支点，持续深化伙伴体系建设、加强开发者使能、优化云商店平台支撑以及持续投入初创生态，与广大合作伙伴、开发者们及初创企业紧密协同，开拓数智化未来。接下来，让我们一同了解新政策变化点。 以伙伴能力为核心的合作伙伴体系1.GoCloud：能力共长，注入发展动能华为云GoCloud合作框架将在2026年保持政策延续性，重点围绕能力共建与协同作战深化合作，聚焦拥抱AI浪潮的前沿技术与关键行业，携手伙伴共同实现高效增长与价值共赢。各路径升级方向具体如下：软件伙伴：围绕更具竞争力的重点云服务，通过更敏捷的技术认证、技术赋能，面向价值市场，共创数字化新蓝海。聚焦根技术的专项计划：通过优势权益激励，助力伙伴基于昇腾云、盘古大模型、高斯数据库、鲲鹏云持续创新，加速行业智能化方案落地。全面拥抱第三方大模型的专项计划：推出模型适配迁移激励计划，鼓励伙伴将开源与闭源模型适配迁移至昇腾云，加速其推广与应用。服务伙伴：持续加大在伙伴能力构建和offering构建相关的投入，强化协同，拓展伙伴发展空间。在Agent、昇腾云、盘古大模型、鲲鹏云等重点领域压强投入，高效增长。数字化转型咨询与系统集成伙伴：围绕重点行业联合作战，围绕客户需求构建可复制的场景化解决方案，推广Co-Sell合作模式，并基于华为全栈AI能力推进重点行业智能化创新。学习与赋能伙伴路径：优化海外认证要求，新增测试券加大权益投入，共建人才生态，围绕根技术深化生态培训合作，做强技术生态。   2. GrowCloud：利益共享，夯实共赢基石为了构建更信任、更赚钱、更简单、更成长的销售伙伴体系，华为云将做强做好三个内核：一是优化激励政策，牵引存量增长，同时促进增量提升；二是构建公开透明的伙伴秩序和规则，使得合作更加信任、更加透明；三是提供差异化的权益体系，通过优质资源向优质伙伴倾斜，激活整个伙伴体系，牵引伙伴能力的提升。具体来说，华为云将在认证、考核、权益和激励四大方面进行优化，全力支持伙伴的队伍能力和市场实现两级跃升。牵引专业深耕：总经销商加强二级拓展与运营，CSP强化拓客与存量经营，并逐步提升总经销商拓渠与CSP拓客认证标准。鼓励伙伴立足自身优势，聚焦主力销售渠道，期望伙伴在专注的赛道做深做透，实现持续盈利。差异化权益体系：提高考试券及MDF额度，加大对伙伴能力提升及营销支持的力度。优化激励政策：简化激励规则，优化新客激励，降低年返门槛、实施全量激励；从周期性大促转向常态化伙伴前折，提升商务竞争力，并在伙伴折扣基础上叠加返点激励。 云商店：价值共创，加速增长引擎华为云云商店KooGallery致力于打造业界领先的一站式应用分发和交易平台，让客户方便找方案，让方案方便找客户，在云商店可以快速便捷、安全无忧地完成交易交付，让云商店成为企业客户应用和方案采购的首选平台。为深化合作、共赢未来，华为云优化2026年云商店商家计划。在延续商家权益体系的同时，进一步优化申请路径，降低准入门槛，让更多有潜力的伙伴轻装上阵，快速融入华为云生态。将以更开放、更坚定的姿态，与伙伴共享发展机遇，携手伙伴用好华为根技术，打造高品质应用，实现商业共赢。 开发者：在华为云“黑土地”上，共同打造行业AI“梦工厂” 华为高级副总裁、华为云CEO周跃峰强调——华为云要携手开发者，在“黑土地”上共同打造行业 AI 的“梦工厂”，即通过构建开放的垂直领域社区，开放华为的技术能力、工具链与行业实践经验，让 AI 真正扎根产业、提升生产力。在这一生态中，每一位开发者的智慧皆可扎根生长，与华为云共同推开一扇扇行业AI的大门。华为云推出的沃土云创计划也持续吸引全球开发者参与华为根技术生态（鲲鹏云、昇腾云、鸿蒙应用上云）创新，覆盖企业、高校与个人，为全球开发者们提供全面支持。本计划旨在构建开放共赢的开发者生态，通过技术赋能、资源支持助力开发者技术创新与商业化落地，帮助开发者快速成长。此政策2026年将持续保持稳定，而最重要的政策变化在于新增“开发者案例共创权益”，具体包括：鼓励高质量的组织型与个人开发者，基于华为开发者空间产品与华为根生态（鲲鹏、昇腾、鸿蒙）完成应用开发与技术创新，总结技术实践案例并发布至华为云开发者案例中心；联合推广高质量技术案例，共同扩大技术影响力，服务更多开发者。 初创计划：预见创业者们的力量在初创生态方面，华为云通过“初创计划”、“加速器”和“AI创业赋能计划”等，全面布局全球，为初创企业提供创新云平台、创业赋能、商业资源等多维度的支持，目前已投入数亿元人民币，帮助超过7,000家初创企业在华为云生态中加速创新。2026年，初创生态将持续投入，继续秉持助力初创企业实现低成本上云、敏捷创新的宗旨，并协同华为内外部生态资源，从技术、营销、增长等多维度为初创企业提供支持，加速其商业成功。 独行快，众行远。2026年华为云生态政策，是华为云向伙伴发出的坚定承诺，也是面向未来的一份共同邀约。我们坚信，只有将伙伴的成功置于生态发展的核心，才能真正凝聚起穿越周期的力量。升级，是为了更好地聚力；聚力，是为了更远地前行。2026，让我们共筑生态，共见不凡。 2026年，合作伙伴新政策已上线，官网焕然一新！快来探索我们的发展路径和计划吧！类别页面URL（中国站现网）聚合页成为合作伙伴cid:link_15路径列表页cid:link_14计划列表页cid:link_12携手合作伙伴cid:link_3伙伴发展路径详情页软件伙伴cid:link_2服务cid:link_8LPcid:link_6数字化转型咨询与系统集成伙伴cid:link_4伙伴计划详情页服务伙伴能力提升专项计划cid:link_0合作伙伴共拓计划cid:link_7伙伴能力计划cid:link_11解决方案提供商计划cid:link_5分销计划（总经销商）cid:link_9分销计划（云经销商）cid:link_13云商店商家计划cid:link_10其他服务伙伴认证考试cid:link_1

亲爱的开发者，您好不知不觉，MDC论坛已陪伴各位开发者走过了5个年头在这5年里，我们持续运营论坛，不仅帮助开发者解决问题求助更发布了行业动态、技术博客和FAQ在内的上百条帖子帮助开发者快速上手那么作为开发者的你对论坛的使用体验如何，又有什么诉求呢现诚邀您填写问卷，参与调研您的使用体验和建议是我们运营的强大动力~戳下方问卷填写（耗时大约1-3分钟）cid:link_0活动时间：2025.12.9-2025.12.31

摘要：2019年11月1-2日，华为携手上汽大通、上汽通用五菱、福田汽车、广汽集团、中国重汽、比亚迪、奇瑞汽车、陕汽集团、武汉光庭等9家车企及合作伙伴，近50名辅助驾驶汽车相关的产品规划与技术开发人员，成功举办了华为MDC（辅助驾驶计算平台）培训交流研讨会。百年汽车工业正在走向“电动化、智能化、网联化、共享化”的新四化征程，其中“智能化”是核心，近年来，成为众多知名车企以及跨界加入的世界级大公司竞相看好的技术制高点，纷纷加大研发投入布局，加强技术积累。未来的辅助驾驶汽车涉及到三大子系统：传感器、计算平台与执行部件，华为MDC就是其中的计算平台——汽车大脑。此平台基于华为鲲鹏处理器与昇腾AI处理器，搭载车控OS，是一个开放的、标准化的、系列化的平台产品，具备“高性能、高安全&可靠、高能效、确定性低时延”的技术优势，结合配套的工具链，车企或合作伙伴可灵活快速开发出针对不用应用场景的辅助驾驶应用。参加此次研讨会的车企与合作伙伴的辅助驾驶解决方案，覆盖私人出行、长途运输、园区通勤、街道清洁、快递物流、港口货运等多种辅助驾驶场景，具有很强的行业普遍性与技术代表性。华为MDC产品部部长张孝铁对客户与合作伙伴们到美丽的溪村参加研讨会表示热烈欢迎，希望借研讨会的机会，增进大家对MDC产品知识与工具链开发流程的理解，基于MDC平台更高效地开发出辅助驾驶解决方案，共同推动辅助驾驶产业快速发展。并表示华为MDC培训交流研讨会将持续办下去，让研讨会成为一个技术学习与交流的平台，打造成辅助驾驶的“黄埔军校”！▲华为MDC产品部部长张孝铁致辞MDC产品知识与工具链开发流程等课程让与会者收获颇丰。与会者分享了自己在开发辅助驾驶过程中遇到的痛点与经验。同时，结合自己的研发现状，对华为MDC产品及工具链给出很多针对性强、卓有见地的优化意见与建议，成为MDC产品与工具链持续迭代优化的重要输入。▲研讨会现场精彩瞬间后记：“求木之长者，必固其根本；欲流之远者，必浚其泉源”。基于华为MDC辅助驾驶计算平台，客户与合作伙伴将能够更快速、更高效地研发出不同场景的领先辅助驾驶解决方案，共同推动辅助驾驶产业加速落地。

[中国，杭州，2020年2月13日] 近日，全球知名的检测、检验和认证公司德国莱茵TÜV集团（以下简称“TÜV莱茵”）向华为MDC辅助驾驶计算平台颁发了ISO 26262功能安全管理认证证书。ISO 26262汽车功能安全标准是国际标准化组织于2011年制定的一项全球性标准，并于2018年12月正式发布其最新版本。该标准涵盖功能性安全需求规划、设计、实施、集成、验证、确认和配置等方面，旨在通过完善的开发流程，将汽车电气或电子系统故障的风险降到最低，是全球电子零部件供应商进入汽车行业的准入门槛之一。   华为MDC获得ISO 26262功能安全管理证书TÜV 莱茵工业服务与信息安全事业群副总裁陈伟康博士向华为颁发认证证书，并表示：“TÜV莱茵以独立的检测，检验服务和专业严谨的认证流程，为华为确保质量和安全。我们很高兴向华为MDC辅助驾驶计算平台颁发ISO 26262功能安全管理认证证书，这将有助于提高辅助驾驶产业的功能安全性。”华为智能汽车解决方案BU从成立之初，一直将产品功能安全管理及认证工作放在首位，安全是辅助驾驶的基本要求，辅助驾驶计算平台，技术复杂度高，安全更受挑战。此次通过ISO 26262功能安全管理认证是华为MDC辅助驾驶计算平台研发历程中一个新的起点，它将提升并确保华为MDC辅助驾驶计算平台产品的功能安全性。在ISO 26262功能安全管理认证的护航下，华为MDC辅助驾驶计算平台将使能辅助驾驶产业更安全的进入快车道。华为MDC辅助驾驶计算平台，基于自研鲲鹏CPU与昇腾AI处理器，搭载自研辅助驾驶OS，是一个开放的、标准化的、系列化的平台产品。该平台支持L2+～L5级别辅助驾驶的平滑演进，统一的软硬件架构，助力车企与生态伙伴能力持续积累与保护历史投资，具备“高性能、高安全、高可靠、高能效、确定性低时延”的技术优势。基于华为MDC辅助驾驶计算平台及配套工具链，车企或生态伙伴可快速开发出针对不同场景的符合汽车行业安全要求的辅助驾驶应用。目前华为MDC辅助驾驶计算平台已携手合作伙伴，与18家主流车企及Tier1建立合作，覆盖乘用车、商用车、特种作业车等多种辅助驾驶应用场景。 

汽车产业是一个面对消费者的产业，满足消费者需求，成为产业发展、做大做强的核心因素。以往的汽车，由车辆基本结构和执行部件等 “躯干”等硬件部件所定义，而辅助驾驶汽车则将由软件定义，因为软件具有灵活易扩展、升级更新快的特点，才能不断满足消费者消费升级、快速迭代的个性化需求。辅助驾驶汽车产业，当前正面临来自消费者新需求、安全红线及新玩家进场等多方面的挑战，具体如下：        1.智能化、体验感成为新的关注点具备好的动力性、经济性和操稳性的车辆是基础，在此基础平台上，智能化水平将会成为辅助驾驶汽车之间主要差距点。FCW、AEB、LDW、LKA、TJA、DOW等逐渐成为强制法规，同时拥有TJP、HWP和城区L3功能的车辆将会被认为比只拥有TJP、HWP功能的车辆领先一代。在体验感上，随着数字座舱、人脸识别、语音识别等技术的兴起，空调自动提前开启、座椅自适应调节、口述目的地等功能对于成长于移动互联网时代的消费者而言将具有更佳的体验。2.安全问题仍然是汽车行业的红线汽车安全不仅仅是指传统的被动安全，还包括主动安全、信息安全、隐私安全。辅助驾驶汽车严重依赖传感器、地图和定位、云端系统，防范信息入侵、保障信息稳定也将成为重点。隐私安全方面，由于车和人的密切交互，消费者的移动轨迹、生活记录都有可能成为安全隐患的爆发点。在移动互联网时代，一次安全事故的发生将被无限放大，让消费者望而却步，安全问题仍然是汽车行业不可触碰的红线。3.新玩家进场加剧行业竞争汽车行业庞大的市场规模与智能网联汽车产业的升级机会，吸引了一大批跨界的有技术实力的非制造类企业的科技公司加入，它们通过新能源、辅助驾驶、智能互联、数字座舱等形式，充分发挥其在软件领域的技术积累，以及消费者需求洞察的优势，逐步侵蚀传统整车厂的市场。更关键的是，新玩家们通过OTA将汽车的功能迭代周期从以前的2~3年缩短到6个月左右，以满足消费者的智能化、个性化的消费需求，抢占智能网联汽车的新市场。可以预见，辅助驾驶汽车行业，极有可能出现手机行业类似的马太效应，出现能够快速满足消费者需求的汽车企业赢家通吃、几家独大的现象。 面对产业的消费者需求挑战，以及跨界玩家带来的竞争压力，传统汽车企业应该如何应对？笔者认为有以下几个思路，分享出来与大家一起探讨： 1.建立平台战略，聚焦差异化应用层平台开发德国汽车工业界认为，当前汽车的主要电子系统由车身电子、智能座舱和辅助驾驶等几大域组成，每个域为一套分层式的架构，如下图所示：这种结构的特点是层次结构清晰，硬件、操作系统、基础软件、应用软件，各层之间接口清晰，各自功能扩展不会造成交叉影响。汽车企业需要将在车身电子、智能座舱和辅助驾驶几大域上构建平台化战略，深入参与Tier1每一层的开发，并主导影响智能化、个性化、体验感特性、功能安全的应用层开发。以其中的辅助驾驶系统为例，汽车企业需要转变角色，从采购者、集成者转变为参与者、共同开发者。在产品定义阶段就与Tier1深入接触，共同定义产品特性、设计硬件层、操作系统层、基础软件层、应用层、适配层的架构和接口，设立一个旗下全系车型通用的产品架构平台，并在产品核心特性定义上，积累核心的决策规控能力。 2.快速迭代，优化当前产品开发流程汽车企业当前辅助驾驶车型是2~3年的产品开发周期，无法满足市场需求，产品开发流程是关键掣肘，如何优化此流程，笔者以辅助驾驶为例说明：（1）将辅助驾驶软硬件开发解耦车辆平台由于特有的测试、认证流程，开发周期天然很难缩减。比如某些执行部件的开发周期要经过高温、高原、高寒测试，时间周期要拉长到两夏一冬。辅助驾驶系统想要提升开发效率，需要将辅助驾驶的硬件部分与软件部分解耦，设定中间层，系统功能开发不再完全受车型特性的影响，并充分利用虚拟、仿真、在环测试等新兴技术缩短软硬件的适配周期。（2）变单车型定点流程为平台化定点流程当前汽车企业的一个车型的定点过程大致如下：如上整个定点流程走下来需要1~2.5年的时间产品才能量产，这种模式完全不能适应功能快速变化迭代的消费者需求个性化的产品。目前业界正在探索另外一种比较可行的方式：平台化定点。其将整个定点流程分为平台定点阶段和版本开发阶段，在平台定点阶段重点考察供应商能力、对齐战略目标，达成一致之后迅速开发辅助驾驶平台。一个新车型出现时，启动一个版本定点，此时只需要更改中间层，做适应性开发。如下图： 3.培养生态，构建战略合作伙伴关系当今世界产业内的竞争，本质上是技术与生态的竞争。通过设定平台战略、优化平台定点模式等方式，与有实力的Tier1构建长期战略合作伙伴关系，培养产业合作生态。比如在辅助驾驶领域，就需要寻找在芯片、算法、OS、硬件、软件领域，有战略决心、有技术实力、有资金实力的大供应商进行生态结盟，此举对汽车企业的好处也是显而易见的：（1）获得辅助驾驶平台的首发使用权与优先供货权；（2）获得辅助驾驶平台深度个性化定制的新特性；（3）获得更多的技术资源保障、更积极的服务支持、更高效的开发效率；（4）汽车产品的成本更具竞争力。 时代的发展，总以快速不断的满足消费者需求的企业获得胜利进而开启更伟大的时代。苹果的智能手机对于诺基亚的功能手机，尼康的数码相机对于柯达的胶卷，历史总在不断重复。今天，智能网联汽车产业，同样出现了特斯拉、蔚来汽车等新玩家，是静观其变还是主动求变，是当前传统汽车企业需要面对的现实问题。辅助驾驶汽车当前还处于起步阶段，只要抓住机遇、开阔思路、转变思想，通过深入产品的开发过程，构建平台战略，快速迭代、简化产品开发流程，培养生态，构建战略合作伙伴关系等手段适应多变的市场节奏，才能最终笑到最后并永立潮头。 

2020年9月24日，在北京国际车展前夕，华为MDC生态合作伙伴希迪智驾重磅发布了商用车辅助驾驶量产解决方案。 希迪智驾是一家以辅助驾驶科技创新及应用为导向，以全自主可控为优势，致力于为客户打造可落地、可量产、可运营的自动驾驶产品的创新型企业。经过两年多的研发迭代，打造出基于华为MDC的商用车自动驾驶量产解决方案，在商用车高级别自动驾驶应用领域，实现“高算力”、“高安全”、“高可靠”、“统一标准”的辩证统一，真正做到车规级、可量产所要求的软硬件实现。该方案是基于华为MDC辅助驾驶计算平台及开放的AUTOSAR标准架构，采用希迪智驾自研的多重异构融合感知、智能规划决策、自适应车辆控制、故障管理与响应、功能安全等子系统，适配多场景感知决策配置方案，整车系统软硬件具备极高的可靠性与可维护性，具备快速扩展和裁剪能力，满足多场景、多工况的自动驾驶需求，可实现L2至L4不同等级辅助驾驶方案的平滑演进。华为MDC辅助驾驶计算平台（MDC 300），算力强劲，可满足L2-L3级自动驾驶算力需求，并通过高可靠的工程设计，可满足防震、防水、防尘等车规要求，算力、电源、架构多重冗余，具备高算力、高安全、高能效、确定性低时延等特性。MDC平台对上层应用提供的功能软件平台框架及接口API，具备高度的开放性和互操作性，为感知、融合、定位、决策、规划、控制等功能模块提供组件化的灵活适配能力。希迪智驾的商用车辅助驾驶量产解决方案，包含摄像头、激光雷达、毫米波雷达、超声波雷达、GNSS/IMU等设备。通过多重融合感知与定位，实现360度视场冗余覆盖，常规工况下可提供侧向50米、后向150米、前向350米感知能力；能够适应无差分信号、GPS信号干扰、无标准化道路等各种复杂场景，实现厘米级定位。该方案集成多重冗余的主动安全系统，提供多重安全防护，有效降低事故发生几率。该方案还通过扩展MDC的HMI功能，在前端车载终端及移动终端、后端云平台之间实现自动驾驶系统的前后台友好操作，能够完成自动驾驶、远程监控与遥控系统的自主切换，实现端到端、点到点的全方面管理与监控，能够有效的实现故障监控与自主调整驾驶策略。另外，此方案还实现了与华为自动驾驶云服务平台（也称“八爪鱼”）的数据链路打通，八爪鱼与MDC车端数据无缝衔接，车云一体，前端测试，后端助力，越来越多的模型训练、算法仿真等功能实现云端部署。 ▲CiDi智能重卡解决方案硬件架构 ▲CiDi智能重卡解决方案软件架构基于华为MDC的希迪智驾商用车辅助驾驶量产解决方案，已成功实现智能重卡场景落地，通过开放道路测试规程的考核，去年10月开始在开放道路（长沙绕城高速）进行路测，实现园区、城区和高速场景下的精准停车装卸货、进出高速、高速公路100km/h以下速度行驶、高速编队、立交桥和隧道通行等功能，为高速物流、园区内/间仓到仓物流提供一站式方案支持。目前，希迪智驾已开始基于华为MDC，在智慧公交、无人矿卡及智慧清扫车等多种车型上进行辅助驾驶量产方案部署测试，以实现该方案在不同车型上的适配与应用落地。