数字花园

自动驾驶1000问：计算平台、功能安全与网络安全

10分钟阅读

自动驾驶1000问：计算平台、功能安全与网络安全

本篇迁移自动驾驶系列第三批 10 道问答（原题 22–31），覆盖 SoC 算力、SoC+MCU、Adaptive AUTOSAR、HARA/ASIL、冗余、SecOC、OTA、安全启动和仿真验证。

21. SoC 的 TOPS 越高越好吗？算力怎么和算法匹配？

答案： TOPS 通常是特定数据类型和条件下的峰值运算指标，不等于实际模型吞吐。实际表现还受内存带宽、算子支持、数据精度、编译器、并发负载、功耗和散热影响。

选型应使用目标算法、输入分辨率、帧率和精度，在真实软件栈上测量端到端延迟、吞吐、功耗和温度；不能只按 TOPS 排名，也不应把固定 2–3 倍冗余当作所有项目的标准答案。

22. 自动驾驶域控制器为什么常采用 SoC + MCU？

答案： SoC 提供大算力，运行感知、融合和规划；MCU 提供确定性控制、监控、上下电管理和故障处置。组合架构让复杂算法与安全关键控制职责分离。

flowchart LR
  A[摄像头 / 雷达 / 激光雷达] --> B[SoC：感知 / 融合 / 规划]
  B --> C[安全监控与命令接口]
  C --> D[MCU：实时控制 / 诊断 / 看门狗]
  D --> E[转向 / 制动 / 动力执行器]
  D --> F[故障检测 / 降级 / 安全停车]

但不能简单宣称所有 SoC 都无法达到某个 ASIL，或 MCU 天然就是 ASIL D；安全能力取决于芯片安全手册、系统架构、软件开发过程和安全论证。

23. Adaptive AUTOSAR 在自动驾驶域控中承担什么角色？

答案： Adaptive Platform 为高性能 ECU 提供基于 POSIX 的运行环境、服务化通信、执行管理、状态管理、诊断和持久化等基础能力，适合高算力、动态部署和频繁软件迭代的应用。

Classic Platform 通常承担 MCU 上的静态配置和硬实时控制；Adaptive 更适合 SoC 上的高性能应用。两者可通过车载网络和服务接口协同，具体通信绑定取决于项目架构。

24. HARA 如何确定 ASIL 等级？

答案： HARA（Hazard Analysis and Risk Assessment）针对危险事件评估严重度 S、暴露率 E 和可控性 C，再按 ISO 26262 对应风险分类表确定 ASIL 或 QM。它不是简单把三个数字相加，也不是按 ECU/模块名称直接分配等级。

ASIL 是安全目标的等级；一个部件可能支持多个安全目标。ASIL 分解需要满足标准规定的独立性和共因失效分析，不能只把一个目标拆成两份就视为完成。

flowchart TD
  A[功能定义与运行场景] --> B[识别危险事件]
  B --> C[评估 S：严重度]
  B --> D[评估 E：暴露率]
  B --> E[评估 C：可控性]
  C --> F[按 ISO 26262 风险分类表]
  D --> F
  E --> F
  F --> G[安全目标与 ASIL]
  G --> H[功能安全概念 / 技术安全概念]

25. 为什么感知融合与执行层的 ASIL 目标可能不同？

答案： ASIL 由具体危险事件和安全目标决定，而不是按“感知层一定 B/C、执行层一定 D”的固定层级表分配。执行器失效可能直接导致车辆运动失控；感知失效也可能引发严重后果，但系统可能通过多传感器冗余、合理性检查、保守策略和驾驶员接管降低风险。

必须针对 ODD、驾驶员角色、故障反应时间和系统架构做 HARA；不能仅凭“后面还有一层”就自动降低感知功能的 ASIL。

26. 同构冗余和异构冗余谁更安全？

答案： 同构冗余用相同或相近实现提高随机硬件故障容错；异构冗余通过不同硬件、软件或算法降低共同设计缺陷造成的共因失效风险。异构并非天然更安全：若两路共享电源、时钟、传感器、需求错误或环境条件，仍可能一起失效。

选择时应分析随机硬件失效、系统性故障、共因失效、独立性、诊断覆盖率、切换时间和验证成本。

27. CAN 报文注入怎么防？SecOC 的核心机制是什么？

答案： 经典 CAN 的 CRC 主要用于传输错误检测，不能证明报文发送者身份，也不能阻止攻击者重算 CRC 后伪造报文。AUTOSAR SecOC 通过认证信息与新鲜度机制保护关键通信：

  • MAC：验证报文数据的完整性和来源真实性。
  • Freshness：防止旧报文被重放。
  • 密钥管理：安全存储、分发和轮换密钥。
  • 纵深防御：配合网关隔离、IDS、网络分区和访问控制。
flowchart LR
  A[发送端 PDU + Freshness] --> B[MAC 计算]
  B --> C[发送认证报文]
  C --> D[接收端校验 MAC]
  D --> E[校验 Freshness]
  E --> F{认证通过？}
  F -->|是| G[交付上层]
  F -->|否| H[丢弃 / 记录安全事件]

SecOC 能力受报文长度、计算开销、密钥配置和新鲜度同步影响，不是物理隔离或入侵检测的替代品。

28. OTA 被劫持可能造成什么后果？怎样防护？

答案： OTA 若被攻击者控制，可能把恶意固件分发到大量车辆，因此必须端到端保护云端签名、传输、车端验签、写入和启动流程。

  • 固件包数字签名与车端验签。
  • TLS/HTTPS 保护传输通道，并对云车双方做身份认证。
  • 签名密钥在 HSM/安全设施中保护。
  • Secure Boot 确保启动时再次验证镜像。
  • Anti-rollback 防止降级到已知脆弱版本。
  • 灰度发布、健康监控、A/B 分区和恢复机制控制升级风险。
  • 供应链安全与 SBOM 提升组件可追溯性。

29. 安全启动的信任链如何工作？

答案： 安全启动从硬件信任根开始，逐级验证下一阶段镜像的签名和完整性，只有验证通过才把控制权交给下一阶段。典型链路为 BootROM → Bootloader → OS/Hypervisor → 应用。

flowchart TD
  A[不可变 BootROM / Root of Trust] --> B[验证 Bootloader 签名]
  B --> C[Bootloader 验证 OS / Hypervisor]
  C --> D[OS 验证关键应用]
  D --> E[正常运行]
  B -.失败.-> F[停止启动 / 恢复模式]
  C -.失败.-> F
  D -.失败.-> F

信任根通常由不可变 ROM、熔丝中的公钥摘要或安全硬件建立。具体公钥层级和验签策略取决于芯片启动架构；启动验证不能替代运行时保护。

30. 自动驾驶为什么必须依赖仿真？纯路测够不够？

答案： 纯路测难以经济地覆盖极低概率长尾场景，也难以安全复现高风险场景；仿真可参数化生成场景、批量运行、复现问题并开展故障注入。但仿真存在模型保真度和 sim-to-real gap，不能代替真实道路和目标硬件验证。

flowchart TD
  A[真实道路数据] --> B[场景提取与参数化]
  B --> C[软件 / 传感器 / 车辆仿真]
  C --> D[批量测试与回归]
  D --> E[问题定位与算法修正]
  E --> F[封闭场地 / 实车验证]
  F --> A

合理验证体系结合 MIL、SIL、HIL、VIL、封闭场地和开放道路测试，并建立数据回灌闭环。

Flomo 原始来源

关系图谱

反向链接