标签: 智能驾驶

5 月中旬，一年一度的紫光同创技术研讨会系列活动正式拉开帷幕，相继在深圳、广州带来 FPGA 技术交流盛宴。 ALINX 作为紫光同创官方合作伙伴，长期助力推动 FPGA 国产化应用发展，此次携多款基于 Kosmo-2 系列产品开发的方案 demo 亮相活动现场，与行业专家、开发者及合作伙伴齐聚一堂，围绕 工业自动化、智能汽车、图像视频 等领域的 FPGA 技术革新展开交流，现场技术氛围热烈，为国产 FPGA 生态发展注入新动能。 ALINX 基于紫光同创国产化 FPGA 芯片，成功开发 Kosmo-2、Titan-2、Logos / Logos2 等多元化产品系列核心板与开发板。此次重点展示的 3 款demo，正是基于 Kosmo-2 PG2K400 设计的 AXK400、AXK401、AXK402 开发板产品，吸引了众多与会者参观交流。 现场展示的 AXK400 视频采集方案 ，通过AXK400 整合 HDMI/摄像头信号采集、帧缓存、图像缩放、字符叠加 等功能，单设备即可完成多模块协作流程，为 智能质检、医疗影像 设备商提供高性价比底层硬件。 针对 智能驾驶车载验证 场景，ALINX 基于 AXK401 开发板 的方案，能够实现车载摄像头数据采集与注入，助力 无人驾驶、特种车测试及车载仿真系统开发 ，推动智能汽车技术落地。 针对 通信、雷达等领域的射频系统设计 场景， AXK402 开发板搭载 FMC 子卡 FL6000 射频模块 ，实现 2.5G 射频信号采集-处理-显示全链路国产化。FPGA 内部模拟产生波形数据并通过 TX 发送，RX 接收波形数据并对波形数据进行处理之后通过 LVDS 屏输出显示。 ALINX 始终致力于为客户提供从原型开发到量产的完整支持，活动现场同步展示了配套的用户开发手册、工具链及技术服务体系，助力合作伙伴缩短研发周期，提升产品竞争力。 6 月，紫光同创技术研讨会将走进 上海与杭州 ， ALINX 将全程参与，期待与您再续技术盛宴！

随着自动驾驶（AD）/高级驾驶辅助系统（ADAS）在车辆中的应用日益广泛，其引发的各类事件分析成为关键问题。本文聚焦 特斯拉Autopilot 的紧急制动情况，借助IVEX打造的 数据采集平台（Carvex） 及 安全分析平台（Safety Analytics platform） 展开研究。 通过对超过 15000公里 行程、 40TB 数据中 紧急制动事件 的剖析，发现Autopilot在面对超出操作设计域的场景时会解除自动驾驶，导致驾驶员紧急制动；同时还存在将正常情况 误判为风险 而紧急制动的现象，这些分析为深入了解AD/ADAS系统行为提供了参考。 一、引言 在过去几年里，AD/ ADAS组件在商用车和零售车辆中越来越受欢迎。这也带来了一系列亟待解决的复杂问题。比如一个备受关注的问题 ：如何从数千小时的驾驶数据（包括开发阶段和实际路测）中识别并理解由 AD/ADAS 行为触发的各类事件，如紧急制动、急加速、低碰撞时间等。 数据采集平台Carvex 集成了一套尖端传感器阵列，搭载于特斯拉Model 3车型，主要用于采集驾驶数据以驱动产品开发。大部分数据是在Autopilot（特斯拉的L2 ADAS系统）被激活时收集的。由于 Autopilot 是先进的 ADAS 系统之一，我们特别关注其性能表现，尤其是 误触发紧急制动 （false positive braking）这一ADAS领域长期存在的技术痛点。 起初，我们在检查数据中的紧急制动事件时也遇到了困难。Carvex 已经收集了 15000 公里的驾驶数据。虽然与正常 ADAS 系统在部署前所需的测试里程相比，这个数字还很小， 但我们发现，如果没有良好的辅助工具，识别和检查紧急制动事件并非易事。 本文将解析特斯拉的紧急制动事件。 图1：Carvex数据收集平台 二、研究背景 Carvex 以Model 3为载体，集成包含RTK GNSS、激光雷达、毫米波雷达和多路相机的传感器套件（其中舱内相机用于监测Autopilot状态），所有数据由车载计算机实时记录。系统采用 全天候设计 ，确保恶劣天气下的数据采集完整性。 在数据收集过程中，Autopilot 大部分时间处于开启状态。Autopilot 主要由两个部分组成： 自适应巡航控制 和 车道保持辅助 。Autopilot 需要驾驶员主动监督，一旦遇到超出其操作设计域（ODD）的情况，系统会发出警报并解除自动驾驶。 目前Carvex累计行驶15,000公里，生成超过40TB数据，其中包含大量与Autopilot行为相关的关键事件。 通过IVEX安全分析平台 ，我们实现了： （1） 自动识别 驾驶日志中的 异常事件 （2） 关联事件潜在诱因 （3） 监测Autopilot行为模式变化 本次研究聚焦 减速度超过4.0 m/s² （13.12 ft/s²）的紧急制动事件，包括 Autopilot主动触发 或 系统退出后驾驶员介入 两种情况。这类事件的研究价值在于： （1）可能反映Autopilot超出ODD时的处置失效 （2）假阳性紧急制动可能导致追尾事故，存在安全隐患 三、Autopilot紧急制动解析 Carvex 的传感器数据会通过 开源自动驾驶软件阿波罗（Apollo） 的感知模块进行离线处理。处理后的图像等传感器数据以及 物体列表格式 的感知输出，随后会被导入到IVEX安全分析平台。 平台 能够展示 AD/ADAS 车辆的所有相机视频流。在这种情况下，我们选择重点关注 前置相机 和 舱内相机 的视频流，以便能够观察到其他车辆与Autopilot的行为。 平台支持 多驾驶日志联合检索 ，并按参数分类关键场景，可以通过"聚合视图"功能 筛选特定车速区间 内触发的紧急制动事件。 图2：安全分析平台紧紧急制动聚合视图 1、右侧车辆引发的紧急制动 图3：右侧车辆引发的紧急制动 图4：IVEX中的紧急制动 从图3和图4中可以看出，尽管 右侧卡车未实际侵入车道 ，自车仍以28 m/s（100.8 km/h）时速突发制动（右侧卡车时速75.6 km/h）。同时数据分析显示：当卡车 短暂压线1秒时 ，Autopilot判定其可能 低速切入 （此时车距仅1.59米），遂触发持续1秒的紧急制动，导致车速骤降7 m/s（根据RTK GNSS估算），这对两辆车来说都是一个危险的情况。 图5：仪表盘Autopilot行为记录 我们可以看到，车辆的 Autopilot 将卡车标记为 可能驶入本车车道 的潜在安全风险，这就是车辆决定紧急制动的原因。 2、交通信号灯前的紧急制动 图6：遇到交通信号时的紧急制动 图7：IVEX中的紧急制动 从图6和图7，分析可得车辆以20 m/s（72 km/h）接近路口时，驾驶员在黄灯亮起1.8秒后接管并急刹，3.7秒内完成静止（减速度5.4 m/s²）。值得注意的是，该版本的Autopilot虽能识别信号灯（如下图示），但无响应功能， 紧急制动纯属驾驶员行为 。 图8：仪表盘Autopilot行为记录 3、环岛入口的紧急制动 图9：在进入环形交叉路口之前进行的紧急制动 图10：IVEX中的紧急制动 在紧急制动发生前约 3 秒，车辆以18 m/s（64.8 km/h）接近环岛时突发制动。实测表明，Autopilot因环岛 超出其ODD 而 静默退出 ，驾驶员接管时剩余反应时间不足，导致 制动过急 。所幸后方无车，未造成风险。 4、技术结论 基于上述分析，我们对Autopilot 的行为得出一些结论： （1）ODD边界行为： 当场景超出Autopilot设计域时，系统会无预警退出，迫使驾驶员紧急干预； （2）风险预判机制： 对潜在切入障碍物存在过度敏感现象，可能触发非必要制动。 四、结语 在本篇文章中，我们介绍了如何使用 IVEX 安全分析平台分析特定场景类别 —— 意外紧急制动情况 。从案例中也可清晰了解到IVEX安全分析平台在AD/ADAS数据解析中的三大优势： （1）异常行为快速定位 （2）多维度场景重建 （3）系统决策溯因分析

数据隐私与安全 在当今数字化时代占据着举足轻重的地位。在应对数据保护法的复杂要求和网络攻击的威胁时，大多数企业都面临着 重重挑战 ，因此诸多企业对 可靠、可扩展且安全的数据管理解决方案 的需求愈发迫切。 正是在这一背景下，康谋精心打造了 本地匿名化一站式解决方案 ，该方案将 隐私和安全 作为其核心设计原则，旨在助力企业以信心和效率从容应对当今复杂多变的 隐私和安全需求 。 一、本地匿名化解决方案 该解决方案巧妙地利用 Terraform部署技术 ，能够在自有集群中实现灵活的 自动扩展 。无论数据处理需求是在 多个服务器的GPU和CPU上 运行，还是涉及到 复杂的数据架构， 系统都能确保在部署后的 第一时间 进行自动扩展。这一特性不仅确保了数据处理的 高吞吐量 ，而且提供了高效管理 跨多样基础设施 的复杂数据的途径。 二、方案优势 1、隐私与安全保护 本地部署 为处理敏感数据提供了最为 安全且合规 的环境。通过在用户自己的基础设施中 托管匿名化处理过程 ，用户可以全 面掌控数据 ，确保严格遵守最严格的数据保护法规。 无论是需要持续处理小批量数据，还是偶尔处理海量数据，该解决方案都能 迅速响应 ，根据需求 动态扩展 到 数百台GPU和CPU机器 ，或在不必要时 迅速缩减 ，以 有效控制成本 。此外，方案还支持许多平台上的Spot Instance，为灵活资源分配提供更多选择。 2、灵活性与控制力 本地匿名化解决方案与数据管理和处理流程 紧密集成 ，可以提供无与伦比的灵活性。用户可以 自由配置资源 ，并根据需要授予不同业务部门访问权限。 这种 高度独立且动态 的运营模式，助力更加 灵活多变 的数据处理能力，从而满足 不同场景下的需求。 3、离线解决方案 本方案还提供了一种 独特的离线解决方案 ， 无需与外部服务器持续通信 ，这一特性不仅提升了安全性，而且确保在最严格的隐私和合规要求下仍能稳定进行各种操作。比如，即使在网络受限或敏感信息不能外泄的场景下，也能顺利完成数据处理任务。 三、应用案例 本地匿名化解决方案具备 云无关性 ，以应对具备 多样性的客户基础设施 。无论用户的系统托管在亚马逊网络服务（AWS）、谷歌云、阿里云还是 其他任何云平台上 ，本平台都能 无缝集成 ，提供同样卓越的服务和可扩展性。 这种 广泛的兼容性 让用户的数据处理更加灵活便捷， 无需担心因平台限制而影响部署。 本地匿名化解决方案已被 欧洲多个行业领导者 广泛采用，如 CARIAD、大众（VW） 和 德国铁路（Deutsche Bahn） 等。客户们通过使用本地匿名化解决方案，成功地在 短时间内完成了数千小时视频的匿名化处理 ，验证了平台处理 庞大数据集 的卓越能力和高效性。 四、总结 综上所述， 本地匿名化解决方案 为企业的数据管理、安全保障和利用带来了革命性的变化。通过提供 可扩展、安全且高效 的平台，该方案能够确保企业能够全面 遵守数据保护法规 ，同时 提升运营灵活性 ，并优化 运营效率， 为您的业务发展奠定坚实的基础。

在过去十年中，自动驾驶和高级驾驶辅助系统（AD/ADAS）软件与硬件的快速发展对 多传感器数据采集的设计需求 提出了 更高的要求 。然而， 目前仍缺乏能够高质量集成多传感器数据采集的解决方案 。 康谋ADTF 正是应运而生，它提供了一个广受认可和广泛引用的软件框架，包含模块化的标准化应用程序和工具，旨在为ADAS功能的开发提供 一站式体验 。 一、ADTF的关键之处！ 无论 是奥迪、大众、宝马还是梅赛德斯-奔驰 ：他们都 依赖我们不断发展的ADTF 来开发智能驾驶辅助解决方案，直至实现自动驾驶的目标。从新功能的最初构思到批量生产的准备，为每一行代码编写奠定了基础。 ADTF软件框架 在汽车行业中扮演着至关重要的角色，主要体现在以下几个方面： 1.最大数据吞吐量： 确保在高负载情况下依然能够高效处理和传输数据，为自动驾驶系统提供实时反馈。 2.高性能实时数据分析： 支持复杂算法的实时运行，提升决策精度，增强自动驾驶的安全性。 3.提高算法测试效率： 简化测试流程，缩短开发周期，加速产品上市。 4.即插即用的通用接口和总线： 简化硬件集成过程，促进不同设备之间的兼容性，降低系统复杂性。 5.硬件组件之间的高效通信： 确保不同平台上的所有硬件组件能够无缝协作，提升系统整体性能。 6.集成开源软件： 通过开源解决方案，促进分布式系统的配置与管理，提升灵活性和可扩展性。 7.广泛的开源文件库： 支持在FEP、RTI-DDS和ROS2等平台上离线读取、写入和处理数据流，便于数据的共享和再利用。 8.多语言SDK支持： C++/JS/QML SDK为客户提供扩展功能的灵活性，使得软件组件可以在各种仿真集和测试设置中多样化应用。 9.云（后）处理工具的构建 ：使开发者能够创建高度可扩展的自动化解决方案，满足未来需求。 10.遵循汽车标准： 支持CAN、CAN FD、FlexRay、XCP、Some/IP、汽车以太网/Autosar等标准，确保产品的兼容性和行业适应性。 二、ADTF的魅力所在！ （1）用于解码AUTOSAR描述的车辆数据总线系统的工具 作为测量技术的强大合作伙伴，基于ADTF（高级驾驶技术框架）的 ARXML解释器 已经被 梅赛德斯－奔驰、奥迪、博世和大众 等汽车制造商广泛使用。在现代车辆中，所有电子控制单元（ECU）相互连接，形成一个称为数据总线系统的网络。 随着车辆技术的发展，数据总线系统越来越多地依赖于ARXML数据库。ARXML是一种用于描述ECU之间通信信息的格式，包括信号、帧（数据包）和时间顺序等信息。 ARXML解析器插件由Device Toolbox中的总线服务实例化，这意味着它作为一个工具，可以 扩展解析和加载信号数据库的功能 。它们充当不同数据库之间的 桥梁 ，并向Device Toolbox提供关键信息。 ARXML解析器引擎能够 快速解析 这些ARXML数据库，将所需信息传递给解析器插件。该插 件支持多个通信协议和标准，具体功能包括： 1.消息和信号的编码与解码： 能够处理CAN（控制区域网络）和CAN FD（灵活数据速率）消息和信号的格式。 2.多路复用信号处理： 可以在一个消息中同时传输多个信号，从而提高数据传输效率。 3.FlexRay通信的时间调度： 支持FlexRay协议中的时间管理，可以在不同的通道（A通道和B通道）中进行输入输出操作。 4.FlexRay帧和协议数据单元的处理： 能够解析和转换FlexRay帧（数据包），并支持大端序和小端序（不同的字节序列存储方式）。 5.信号处理策略： 支持单调计数和锯齿计数的方式，以及对信号位的递增、递减和排序操作，处理多路复用的协议数据单元。 通过这些功能， ARXML解释器 能够 有效地管理和处理 现代车辆中的复杂通信需求，确保 各个ECU之间能够顺畅地交流 ，从而提升车辆的整体性能和安全性。 （2）将功能工程平台（FEP）集成到ADTF中 功能工程平台（FEP） 是一个免费提供的开源中间件，旨在 简化分布式系统的开发和管理 。通过将FEP集成到ADTF（高级驾驶技术框架）中，ADAS（高级驾驶辅助系统）开发人员可以 克服许多设置和管理分布式系统的挑战 ，同时仍能享受到ADTF提供的高性能实时数据管理和验证功能，包括记录和回放测试数据。 使用ADTF配置编辑器， 开发人员可以 轻松配置 分布式系统。这使得以简单的方式体验复杂的仿真、测试和验证架构成为可能，无论是在个人电脑上运行，还是在可扩展的云环境中操作。 这样，开发人员可以更加高效地进行ADAS功能的测试和快速原型设计，从而加快技术的开发进程。 （3）自动可视化和评估测试用例的机载分析工具 Supertester 是一款用于 自动化可视化和评估ADAS（高级驾驶辅助系统）功能测试用例的机载分析工具。 它通过直观的用户界面，自动采集和控制测试过程，帮助测试管理人员避免因执行错误或未遵守规定参数而产生的挫败感。这样，Supertester能够提升ADAS功能测试的安全性， 同时显著节省时间和成本 。 在测试执行中，Supertester自动监控测试过程和系统状态，确保所有测试参数都符合规定。测量数据会被实时记录，并可以用于引导测试程序。Supertester提供的主要服务包括： 1.引导测试和实时分析： 为用户提供直观的操作指导，并实时分析测试结果。 2.IS029119一致性测试： 确保测试符合国际标准的要求。 3.整体测试文档： 生成全面的测试文档，便于后续查阅和管理。 4.通用接口： 与测试管理系统进行数据交换，方便信息共享和协作。 测试结果的特点包括： ·上传测试结果：用户可以方便地将测试结果上传至系统。 ·可视化评估：清晰展示驾驶操作和相关测试结果的可视化信息。 ·即时反馈：测试执行后，用户能够立即获得测试结果。 ·完整的环境数据：上传所有必要的测试环境数据，确保结果的可靠性和准确性。 通过这些功能，Supertester大幅提升了ADAS功能测试的效率和可靠性，使测试过程更加顺畅。 三、总结 综上可知，ADTF是一个模块化、标准化的软件框架，广泛应用于ADAS和自动驾驶功能的开发。 它通过高效的数据吞吐量、实时数据分析和多传感器集成能力，加速算法测试和产品开发。ADTF同时也支持多种汽车通信标准（如CAN、FlexRay、Autosar等），并提供即插即用的接口，简化硬件集成。 此外，其ARXML解析器支持复杂车辆通信数据的解码，确保ECU间高效通信；FEP中间件的集成则优化了分布式系统的开发与验证；Supertester工具进一步通过自动化标准测试和实时分析提升ADAS测试的安全性与效率。 总体而言，ADTF为智能驾驶开发提供了高性能、灵活性和可靠性的全方位支持，成为行业中不可或缺的解决方案。

随着软件定义汽车的发展，车辆生成的数据量也以前所未有的速度 不断增加 。这些数据包含广泛的信息，包括传感器数据、遥测数据、诊断数据等。在开发过程中， 有效处理这些数据并从中获得见解 至关重要。 对于原始设备制造商（OEM）和汽车一级供应商（Tier 1）来说，是否 自主构建 和 维护数据处理流程 是一个至关重要的考虑因素。 数据处理流程 是应对当下软件定义汽车所产生的海量数据的基础组件。 一、问题背景 在 AWS 等云平台 上为高级驾驶辅助系统 （ADAS） 和自动驾驶 （AD） 数据构建鲁棒的数据处理流程，通常需要全面了解各种服务及其集成。您可能使用的特定服务可能取决于 应用程序的要求、数据源和处理需求 。 为了解决这一问题， 康谋 通过使用 IVEX 提出了专门用于应对ADAS/AD海量数据的数据处理流程。 该流程的核心目的是自动 从原始传感器数据等输入中识别出值得关注的事件和场景。构建这样的数据处理流程需要仔细考虑 各种技术方面 ，例如：原始传感器数据的云端存储、基于原始数据的算法执行（包括需要例如GPU等特定资源的机器学习算法）、事件和场景等后处理数据的存储机制、算法版本控制、结果可视化以及确保数据仅对授权用户可见。 二、内部构建或获取预组装解决方案 IVEX 的数据处理流程基于多种AWS服务实现 无缝衔接 ，以下是经过 策略性部署的AWS服务 ： 1. 原始传感器的数据 （包括激光雷达点云、相机图像和GNSS信息）存储在S3存储服务中。S3用作采集数据的暂存地，为后期处理的数据提供扩展存储，并为处理提供经济高效的短期存储解决方案。此外，使用S3挂载点功能能让S3作为主要的“处理卷”，使其能够像文件系统一样使用。虽然它不完全符合POSIX标准，对某些工作负载存在限制，但可以通过整合EFS和可能添加的FSx来解决这个问题，以根据需要确保兼容性。 2. 处理后的数据 （重要事件和场景）存储在关系型数据库服务（Relational Database Service，RDS）和DocDB中。RDS是一个高效的存储库，用于组织对分析至关重要的标记数据。同时，DocDB作为文档存储运行，它是专为快速变化的数据和显示目的所需的二进制数据而设计的。 3. EKS和EC2处理算法执行和可视化任务。 EKS充当一系列服务的主机，包括后端、数据服务、前端和处理服务。EC2主要用于根据为EKS制定的规则配置机器。 4. 算法的版本控制通过 ECR 进行管理。 ECR用于存储Docker容器镜像。 5. 身份验证通过Cognito进行。 如果有必要，可以灵活地替换为任何OpenID Connect （OIDC）解决方案。 6. 数据传输和临时数据存储通过EFS进行管理。 EFS作为临时处理区域运行，供各种数据处理流水线存放中间数据并促进不同进程之间的数据共享。因为EFS完全符合POSIX标准，所以可以选择它作为S3的替代文件系统。 这个方案示例突出了 构建鲁棒的ADAS/AD数据处理流程 所涉及的 众多云服务 ，并强调了应对各种技术复杂性的必要性。此外，还必须解决诸如组织输入数据、确保数据格式兼容性以及管理和监控数据格式变化等挑战。 例如，随着ADAS/AD系统的发展，添加更多传感器以及管理不同车辆配置的需求成为数据处理流程中的关键考虑因素。如果不加以妥善处理，这些因素可能会导致 不正确的数据处理，最终得到错误的结果。 上图列出的是构建此数据处理流程的预计工作量和成本细目，该处理流程可标记 12种驾驶场景、提取驾驶参数，并支持可视化大型文件（≥ 10TB） 。 三、总结 总之，解决上述的这些问题需要付出大量的努力。显而易见的是，选择 预先搭建好的数据处理流程将拥有更低的开销 。此后，便可以将节省的时间和成本分配给开发OEM和Tier1产品的关键方面。