鉴智推出的市场首个基于征程6E的7V鱼眼辅助驾驶方案即将量产，首款搭载车型将于8月正式面世。同时，该套面向智驾全面普惠的「标配最优解」于近期接连收获头部OEM的量产定点，成为业界的“明星方案”。
究其原因，该方案全面满足主机厂的“竞争”需求：
以业界最简洁的传感器配置（7V鱼眼）和国产芯片龙头最具性价比的走量芯片（地平线征程6E）保证了「极致性价比」的成本基础；
在J6E中等算力芯片内“超额”配置包括行泊一体、城区LCC+及记忆行车等功能实现了「主流功能全覆盖」的差异优势；
油电同智、量产可靠、快速上车，满足了主机厂“智驾下沉、全面渗透”的「高效快速量产」交付需要。
"多快好省"，让该方案成为“走量标品”。
【量产进行时】，本期文章从「安全工程落地」的角度，给大家分享鉴智是如何为用户安全保驾护航。
“智驾平权”时代，辅助驾驶逐渐渗透入每一位车主和乘客的日常生活。
「安全」是客户对于辅助驾驶系统信任度的基础。任何一点系统的“差池”，在实际行车过程中都可能会造成“事故”。所以，辅助驾驶系统的量产中，既要考虑软硬件的某些故障（功能安全维度），又要考虑由于系统局限性导致的性能边界模糊而间接引发的潜在危害问题（预期功能安全维度），这非常考验软硬件的系统安全工程经验。
针对智能驾驶系统安全，鉴智搭建了全生命周期的体系保障，贯穿硬件评估、算法设计、工具链支持、测试验证及量产数据闭环等多个环节，确保产品“极致安全，好用爱用”。
1
提出对硬件和底软的安全依赖
充分评估域控硬件供应商的安全设计和实现
针对智能驾驶系统安全，需重点建立对硬件平台及底层软件（底软）的安全依赖评估体系。当前，多数算法供应商因不主导硬件与底软的设计与开发，普遍存在对硬件与底软安全性认知不充分的问题，这一局限性构成了算法供应商的固有技术“盲点”。与之不同的是，鉴智在与客户合作过程中，于项目早期即联合客户与硬件供应商开展正向系统性安全分析，完整的识别硬件与底软的潜在失效模式（Potential Failure Mode），并针对性制定故障探测与上报需求（TSR，Technical Safety Requirement），以此保障底层基座的安全性。
该评估过程看似简单，但对工程设计能力要求极高。原因在于，硬件与底软并非理想化的“完美组件”，实际运行中可能存在故障误报现象。以故障去抖（Debounce）策略为例，需精确设定去抖时长以触发后续故障处理（如功能退出）：若去抖时间过短，可能导致驾驶体验受干扰；若过长，则可能延误安全响应。因此，需与客户Case by Case地开展联合分析，避免采用“一刀切”的不合理故障处理时间阈值（FHTI，Fault Handling Time Interval），平衡安全防护与驾驶体验的关系。
2
设立应用软件与算法的防御性设计体系
让真实驾驶“从容”且“安全”
智能驾驶系统中，软件与算法的失效具有概率性特征（无论概率高低），具体表现为通信异常、计算结果超阈值、模块崩溃（Core Dump）、算法输出目标位置/速度跳变等问题。墨菲定律在智能驾驶领域同样适用，且概率不低。
鉴智在软件与算法防御性设计中，重点构建“故障诊断”与“安全兜底”双重机制：
故障诊断：其核心理念相对明确，无论是采用E-GAS架构、AP Autosar中间件监控，还是CP Autosar降级管理，本质均是通过故障检测与处理使系统进入安全状态。技术难点在于如何“稳健有序”地执行降级操作——既需保障系统可用性，又需确保安全性，避免因过晚（如临近事故发生前1-2秒）触发智驾功能退出而引发事故。这要求规控决策策略在设计时需兼顾谨慎性与规划“从容性”，鉴智的Planning后决策方案在此方面已形成有效技术贡献。
安全兜底：该机制在传统L2级ADAS中已较为成熟，通常通过执行器阈值限制或域控阈值限制实现输出超限防护。但在中高阶智驾场景下，简单的“一刀切”限值策略可能影响功能可用性，因此需结合多维度条件（如车辆位姿、运动属性、道路环境等）进行综合判断后设计动态限值策略，鉴智的AI感知与规控技术在此方向已取得显著成果。
值得强调的是，安全工程的核心挑战在于“风险预防”而非“风险控制”。例如，需明确智驾系统的性能边界，在接近临界状态前实现风险预判，并通过合理的后处理降低风险。这一目标需要智驾系统对场景具备时间和空间的理解能力，端到端方案（如VLA（视觉-语言-动作）模型、世界模型等）的应用可以更好的实现该目标，鉴智高阶项目的量产中，将就此维度大幅升级。
3
通过工具链和数据闭环加速问题修复
形成敏捷迭代飞轮
安全需求在SOP前有效落地是系统安全的关键前提。这一目标的实现既不能单纯依赖开发团队，也无法完全依靠测试环节。鉴智的安全工程师通过将故障诊断功能【提前】接入可视化工具，实时跟踪daily版本冒烟测试及系统测试中的故障触发情况，实现问题的快速发现与闭环。
该机制对安全机制鲁棒性（Robustness）的验证具有重要价值——以岚图项目为例，通过PHI X故障可视化工具，团队在正式软件测试与系统测试前已过滤大量故障误报问题，有效避免了此类问题流入测试或用户侧（如NOA功能异常降级至ACC或主动退出的误触发事件）。从工程实践角度看，这一过程体现了安全工程的敏捷开发特性。
4
全维测试验证体系
将安全工程与大里程测试深度融合
系统安全需通过多层次测试验证保障，具体包括两方面：
基础测试验证：通过软件测试与系统测试对安全需求、安全策略进行验证，此为系统工程流程的既定要求，严格按照ISO 26262标准化流程作业。
实车验证确认：更关键的是将安全工程与大规模道路测试（大里程测试）深度融合。该策略的优势体现在：其一，可在SOP前修复软件测试无法覆盖的算法局限性问题，有效收集真实的危险场景和算法的不足，不断填充SOTIF场景库，其数据可作为回灌的“黄金数据”；其二，通过大里程测试对功能安全的方案设计进行压力测试，有效解决故障误报引起的功能可用性降低的情况。
5
量产阶段数据闭环与长尾问题管理
持续OTA升级
产品量产，安全工作仍不能停歇，辅助驾驶系统已部署故障诊断与数据闭环的触发器等机制，保障客户车辆在出现异常进行“优雅从容”的降级，同时、数据闭环触发将异常数据上传至云端，鉴智安全工程师与客户联合开展问题分析、分级与分发，确保安全问题以第一优先级反馈到“产品质量门”。
数据闭环与OTA协同，针对长尾问题（低概率、高危害场景）的收集与优化，从而使车辆“越开越好开”。量产仅是数据驱动安全优化的起点。
“安全第一”，是鉴智机器人自成立起始终坚持的准则。
我们深知，智驾安全没有“起点终点”，只有“全力以赴”。
我们发自内心地相信，每一次的功能激活，都是一段安全且舒心的旅程。
