一、安全合规概述：座舱HMI安全法规背景、功能安全与预期功能安全、SOTIF（ISO 21448）简介、责任与伦理

1.1 座舱HMI安全法规背景——为什么我们绕不开这些条条框框？

说实话，我刚入行那会儿，也觉得法规是束缚创意的枷锁。直到有一次，我参与的一个项目因为忽略了某个地区的触控响应时间标准，差点被要求召回整改。嗯，从那以后，我再也不敢小看这些「条条框框」了。

座舱HMI的安全法规，说白了就是给「人机交互」划了一条底线。你想想看，一个时速120公里的座舱里，驾驶员多看了屏幕0.5秒，车就跑了近17米。这17米，可能就是安全与事故的分界线。

目前全球主流的法规框架，我整理了一下：

法规/标准	核心要求	我的个人体会
ISO 26262（功能安全）	系统故障时不能造成危害	这是「兜底」的，硬件软件都不能乱来
ISO 21448（SOTIF）	没有故障，但场景超出预期也不行	这个更难，因为「未知场景」防不胜防
NHTSA 驾驶员分心指南	视线离开道路时间 ≤ 2秒	我习惯把这个作为HMI设计的「黄金法则」
UN R79 / R157	自动驾驶模式下HMI的接管逻辑	欧洲市场特别严格，踩过坑才懂

为什么会有这么多法规？因为座舱HMI已经不是「好看就行」的时代了。它直接关系到驾驶员的注意力分配、决策时间，甚至是生命。

1.2 功能安全与预期功能安全——两个「安全」到底有啥区别？

这个问题，我经常被刚入行的同事问到。其实很简单，我打个比方：

• 功能安全（FuSa）： 系统坏了怎么办？比如屏幕死机了，不能把车速显示成0。
• 预期功能安全（SOTIF）： 系统没坏，但场景太复杂了怎么办？比如大雾天，摄像头看不清车道线，HMI却还在显示「车道保持正常」。

我个人习惯把功能安全比作「硬件和软件的保险丝」，而预期功能安全则是「场景的边界管理」。两者缺一不可。

功能安全（ISO 26262）的核心逻辑

功能安全关注的是「系统性故障」和「随机硬件故障」。举个例子，我在项目中遇到过一个问题：某个触控芯片在高温下会误报触摸信号。这就是典型的硬件故障。按照ISO 26262，我们需要给这个功能分配一个ASIL等级（比如ASIL B），然后做相应的安全机制——比如加入信号滤波、冗余检测。

预期功能安全（SOTIF / ISO 21448）简介

SOTIF，全称是「Safety of the Intended Functionality」。说白了，就是「功能本身没问题，但用错了地方」。ISO 21448是专门针对这个问题的标准。

为什么会这样？因为现在的座舱越来越智能，传感器越来越多。但传感器有它的局限性：

• 摄像头在逆光下会「失明」
• 雷达在暴雨中会「衰减」
• 超声波在狭窄空间会「串扰」

这些都不是故障，但如果不处理，HMI就可能给出错误的信息。比如，倒车影像在雨天有水滴遮挡，系统没有提示「视野受限」，用户以为后面是空的，结果……

1.3 责任与伦理——屏幕背后的人命关天

这部分，我想多说几句。因为技术问题可以解决，但责任和伦理问题，往往是最难扯清的。

你想想看，如果一辆L3级自动驾驶的车，在行驶中突然要求驾驶员接管。但HMI的提示音太小，或者提示图标太隐蔽，驾驶员没注意到。结果出了事故。这个责任算谁的？

我个人认为，HMI设计师在这里有不可推卸的责任。因为「接管提示」是HMI的核心功能，它的设计必须满足：

1. 可感知性： 视觉、听觉、触觉，至少两种通道同时提示。
2. 可理解性： 用户一看就知道「现在需要我做什么」。
3. 可操作性： 接管动作必须在2秒内完成，且操作路径清晰。

我在项目中遇到过这样的案例：某款车的自动驾驶退出提示，用的是「方向盘震动+仪表盘小图标」。结果在高速上，驾驶员根本没感觉到震动（路面本身就在震），也没看到那个小图标。嗯，后来我们改成了「声音+大屏弹窗+语音播报」三重冗余。

最后，我想分享一个我个人的原则：HMI设计的第一性原理，不是「好用」，而是「安全」。好用是加分项，安全是及格线。及格线都过不了，其他都是空谈。