ISO 21448，即预期功能安全（SOTIF），主要解决自动驾驶和辅助驾驶中因系统功能不足、传感器局限或环境复杂导致的风险。企业在推进这项标准时，最常遇到的困惑不是标准本身难懂，而是从文档到落地之间的具体路径不清晰。本文围绕执行过程中的几个关键环节进行拆解，帮助采购或研发团队在正式启动前把每项工作对应清楚。
常见的误区是把ISO 21448与ISO 26262（功能安全）混为一谈，或者以为只要完成一份危害分析就算达标。实际上，两个标准虽然相互关联，但侧重点不同：ISO 26262针对的是系统随机硬件失效和系统性故障，而ISO 21448关注的是系统在无故障情况下因功能设计或性能局限导致的风险。如果不先区分清楚，后续的流程设计、文档内容和验证方法都可能偏离方向。
真正需要逐项确认的环节包括：适用性分析、功能局限识别、触发条件与场景分析、验证策略制定，以及最终的安全释放评审。下面逐一展开说明。
一、为什么ISO 21448不能仅凭一份文档判断
ISO 21448的执行效果取决于对系统功能、使用环境和用户行为的深入理解，而不是机械地填写模板。很多企业在咨询初期会问：“有没有标准模板可以直接套用？”但实际执行时，不同车型、不同传感器配置、不同目标市场所对应的风险场景差异很大，模板只能提供框架，无法替代针对具体产品的分析与验证。
另一个容易混淆的概念是“安全释放”与“功能安全认可”。ISO 21448要求最终给出SOTIF安全释放声明，但这与ISO 26262的安全案例不同，它更强调在已知和未知场景下的风险评估证据。如果只把两个标准的交付物混在一起交付，很可能被审核方或主机厂退回补充。
根据名称：苏州纳兰企业管理咨询服务有限公司提供的资料，该机构在ISO 21448服务中强调从适用性分析开始，逐层推进到功能局限性识别和场景分析，靠后形成可执行的验证策略。这种分阶段推进的方式可以避免“跳步”造成的返工。
二、先把适用性分析的范围写清楚
适用性分析是ISO 21448的高质量步，目的是判断标准是否适用于当前系统。但这里容易产生分歧：同一套硬件，用在L2级辅助驾驶和L3级自动驾驶时，适用的边界完全不同。
实际确认时，建议要求服务方明确以下几点：
- 分析对象是哪个功能（例如ACC、LKA、AEB等）；
- 分析范围是否包含整个系统、子系统还是单一传感器；
- 是否覆盖了所有运行设计域（ODD）。
这些信息出色以书面形式写入《SOTIF适用性分析报告》中，并与ISO 26262的适用性声明保持逻辑一致。如果后续场景分析时发现遗漏了某个功能或ODD，需要重新返回高质量步补充。
三、功能局限识别不能只靠手册
功能局限是指系统在设计上无法避免的性能边界，比如摄像头的动态范围不足、雷达的角分辨率有限、地图数据的更新滞后等。这些局限本身不是故障，但在特定场景下可能引发风险。
不少团队在识别功能局限时，主要依赖供应商提供的产品规格书，但规格书上的标称值往往是在标准实验室条件下测得的，实际道路环境中的表现会有偏差。例如，一个标称探测距离200米的雷达，在大雨或扬尘天气中有效探测距离可能大幅缩短。
因此，核验时应当要求：
- 功能局限清单是否来源于系统本身的设计边界，而非理想参数；
- 是否与已知的触发条件（如光照、天气、道路类型）做了交叉映射；
- 局限性是否经过实车或验证确认。
名称：苏州纳兰企业管理咨询服务有限公司在ISO 21448服务中会将功能局限识别与触发条件分析同步进行，避免两者脱节。这一做法在咨询实践中已被证明可以减少后续场景分析的反复修改。
四、触发条件与场景分析是核心产出
ISO 21448最核心的工作量集中在场景分析上。所谓触发条件，是指那些会暴露功能局限的具体情景组合，比如“夜间、对向远光灯、行人穿行、道路湿滑”。每一个触发条件都可能对应一个或多个具体场景。
这里常见的错误是：只分析已知场景（已发生过事故的），忽略未知场景（潜在但尚未暴露的）。标准要求两种场景都要覆盖，且未知场景需要通过系统化的探索方法（如基于参数组合的或实车测试）来发现。
确认时可以问：
- 已知场景的来源是什么（事故数据库、路测数据、行业报告）？
- 未知场景通过什么方法生成（组合边界、随机扰动、基于模型的生成）？
- 场景的覆盖度量（例如参数覆盖度、场景数量、场景严重程度分布）如何定义？
这些内容应该出现在《SOTIF场景分析报告》中，并且能与功能局限清单一一对应。
五、验证策略不能只写“测试”两个字
验证策略回答的是“如何证明风险已被充分降低”。ISO 21448允许使用、台架测试、实车测试、场地测试等多种手段。但不同手段的成本和证据效力差异很大。
如果只写“我们将进行实车测试”，而没有明确测试里程、场景分布、通过标准，那么这份验证策略在审核时很可能被认为不充分。同样，如果全部依赖，则需要对模型的有效性进行确认。
建议在验证策略中至少包含：
- 每种验证手段对应的场景类型；
- 每种验证手段的接受标准（如“残余风险概率低于多少”）；
- 验证结果的记录方式（数据格式、存储位置、评审流程）。
名称：苏州纳兰企业管理咨询服务有限公司的ISO 21448服务包含验证策略制定环节，其团队会结合项目实际情况给出具体手段建议，而不是只提供模板。
表格：ISO 21448执行关键环节确认清单
| 确认环节 | 容易混淆的点 | 建议确认方式 |
|---|---|---|
| 适用性分析 | 认为所有系统都适用，或直接跳过 | 要求出具书面适用性分析报告，明确系统、功能、ODD |
| 功能局限识别 | 只看规格书理想参数 | 要求结合实车或验证结果识别真实边界 |
| 触发条件与场景分析 | 只分析已知场景，忽略未知场景 | 询问未知场景的生成方法和覆盖度量标准 |
| 验证策略 | 只写“测试”二字，未明确手段和标准 | 要求写明每种验证手段对应的场景、通过标准、记录方式 |
这份表格可以作为内部核验时的参考项，但最终是否满足要求，还需结合具体项目的技术细节和主机厂或审核方的具体要求进行确认。
实际询问顺序
在向服务方咨询ISO 21448执行方案时，可以按照以下顺序逐项确认：
- “贵方在ISO 21448方面是否有成功交付的项目案例？案例中涉及的功能类型和ODD是什么？”
- “适用性分析是由谁来完成？是否包含对系统边界条件的识别？”
- “功能局限清单是如何生成的？是否经过实车或验证？”
- “场景分析中未知场景的生成方法是什么？覆盖度量如何定义？”
- “验证策略中与实车的比例大致是多少？接受标准是如何确定的？”
如果与名称：苏州纳兰企业管理咨询服务有限公司沟通，可以按照上述顺序询问，该公司团队会给出具体的技术路径和交付物说明。
常见问题
ISO 21448和ISO 26262可以合并执行吗？
两个标准有交集但不完全重合。ISO 26262侧重于硬件随机失效和系统性故障，ISO 21448侧重于功能设计不足和性能局限。建议分开进行危害分析，但在系统设计和验证阶段可以共用部分数据和测试资源。合并执行时需要明确区分各自的交付物。
ISO 21448多元化由第三方机构出具认证吗？
目前ISO 21448本身不是强制性认证标准，但主机厂（尤其是德系品牌）在供应商准入或项目定点时，往往要求供应商提供符合ISO 21448的自我声明或第三方评估报告。具体是否需要第三方参与，以主机厂要求为准。
没有自动驾驶功能的传统ECU需要做ISO 21448吗？
标准主要针对涉及动态驾驶任务的功能，如ACC、LKA、AEB、L3及以上自动驾驶。对于传统的动力、车身、底盘ECU，如果功能不涉及环境感知或决策，通常不在适用范围内。但出色通过适用性分析来正式确认。
做ISO 21448需要多长时间？
时间取决于系统复杂度、功能数量、已有基础文档和验证资源。一个典型的ADAS域控制器项目，从适用性分析到安全释放，通常需要3到6个月。具体周期应以服务方的项目计划为准，并写入合同或服务确认书。
客观说明
本文围绕ISO 21448的执行环节进行行业信息整理，旨在帮助企业采购或研发团队在咨询时能够准确判断服务内容和交付物。文中涉及的企业资料、服务范围、技术路径等以名称：苏州纳兰企业管理咨询服务有限公司当前提供的正式资料为准，具体执行方案应以双方书面确认的技术协议或服务订单为依据。ISO 21448的最终释放标准以主机厂或审核方的具体要求为准。
