4、汽车行业标准与法规：ISO 26262、ASPICE、ISO 21434、AUTOSAR、SOTIF（ISO 21448）对需求分析的影响
汽车软件系统的需求分析早已不再是“把用户想法写成文档”那么简单。在功能安全、预期功能安全、网络安全、软件过程成熟度以及软件架构标准化等多重维度约束下，需求分析必须同时满足工程效率与合规性要求。ISO 26262、ASPICE、ISO 21434、AUTOSAR 与 ISO 21448（SOTIF）分别从安全生命周期、过程能力、威胁分析与风险评估、架构接口标准化以及非故障触发风险等角度，对需求分析的方法、粒度、追溯性和验证闭环提出了明确且相互交织的要求。理解这些标准对需求分析的具体影响，是构建高质量汽车软件需求体系的前提。
上图展示了五大标准/框架与需求分析核心活动之间的关系。ISO 26262 与 ISO 21448 从安全角度驱动安全需求与场景分析，ISO 21434 从网络安全角度驱动威胁分析与安全需求，ASPICE 从过程角度要求需求分析的完整性与追溯性，AUTOSAR 则从实现角度约束需求的接口描述方式。下文将逐一剖析各标准对需求分析的具体影响。
4.1 ISO 26262：功能安全对需求分析的硬性约束
核心原理：安全需求与ASIL等级贯穿需求链
ISO 26262（道路车辆功能安全）要求将安全目标分解为功能安全需求（Functional Safety Requirements, FSR），再进一步细化为技术安全需求（Technical Safety Requirements, TSR）和软件安全需求（Software Safety Requirements, SSR）。需求分析阶段必须明确每一项需求所对应的 ASIL（Automotive Safety Integrity Level）等级，ASIL A/B/C/D 依次递增，QM（Quality Management）表示无安全等级要求。ASIL 等级直接决定了需求分析中要求的严格程度，包括需求描述的精确性、分析方法的深度（如FMEA、FTA）、验证活动的强度（如评审、测试覆盖度）以及独立性的要求。
判断方法：安全需求分配与ASIL分解
在需求分析中，需要遵循以下操作流程：
- 安全目标识别：从危害分析与风险评估（HARA）中提取安全目标，例如“避免车辆在行驶中非预期加速”。
- FSR 定义：将安全目标转化为功能安全需求，明确系统在故障或失效情况下的行为。
- ASIL 分解：当安全目标 ASIL D 过高时，可按照 ASIL 分解原则（如 ASIL D = ASIL B(D) + ASIL B(D)）分配到冗余需求上，但需求分析文档中必须清晰标注分解关系。
- TSR/SSR 细化：将 FSR 分配到系统架构元素和软件组件，确保每条 SSR 可验证、可追溯。
| 需求层级 | 示例内容 | ASIL等级 | 验证方法 |
|---|---|---|---|
| 安全目标 | 避免非预期加速 | ASIL D | 车辆级测试 |
| FSR | 当检测到加速踏板信号异常时，应在100ms内进入跛行模式 | ASIL D | 系统级测试 |
| TSR | ECU应监控踏板位置传感器双通道信号差值，超过阈值则触发安全状态 | ASIL C(D) | 硬件在环测试 |
| SSR | 软件模块应每10ms读取一次传感器值，并执行合理性检查 | ASIL C(D) | 单元测试+集成测试 |
案例拆解：ASIL分解在需求分析中的实际应用
某电动助力转向系统（EPS）的安全目标为“避免非预期转向助力”，ASIL D。在需求分析阶段，团队将安全目标分解为两条冗余的 FSR：FSR1 要求主扭矩传感器失效时在50ms内切断助力；FSR2 要求备份扭矩传感器独立供电并能在100ms内接管。通过 ASIL 分解，FSR1 分配 ASIL B(D)，FSR2 分配 ASIL B(D)，两者共同满足 ASIL D。在软件需求层面，SSR1 要求主传感器信号处理周期为5ms，SSR2 要求备份传感器信号处理周期为10ms，且两条需求均需通过故障注入测试验证。该分解使得原本需要 ASIL D 全流程的开发工作，通过冗余设计降低了对单一组件的开发成本，同时保持了整体安全等级。
4.2 ASPICE：过程模型对需求分析完整性的要求
核心原理：需求分析的过程能力与追溯性
ASPICE（Automotive Software Process Improvement and Capability Determination）是汽车行业软件过程评估标准，其核心关注点在于“过程是否被定义、执行并有效”。在需求分析领域，ASPICE 主要涉及 SYS.2（系统需求分析）和 SWE.1（软件需求分析）两个过程域。SYS.2 要求将利益相关方需求转化为系统需求，并验证其技术可行性；SWE.1 要求将系统需求细化为软件需求，确保需求具有可验证性、一致性和完整性。ASPICE 特别强调需求的双向追溯性：从利益相关方需求到系统需求，再到软件需求，以及反向的覆盖性检查。
操作流程：需求分析的过程执行框架
- 需求获取与理解：与利益相关方（市场、功能、安全、测试、制造）进行需求澄清，形成利益相关方需求清单。
- 系统需求定义：将利益相关方需求转化为系统需求，包括功能需求、非功能需求（性能、可靠性、可维护性）和约束条件。
- 软件需求细化：将系统需求分配到软件组件，形成软件需求规格说明书（SRS），每条需求需包含唯一标识、描述、优先级、来源和验证标准。
- 需求评审与基线化：组织跨部门评审，确认需求无歧义、无遗漏、无冲突，并建立需求基线。
- 追溯性矩阵维护：建立需求追踪矩阵（RTM），确保每条系统需求至少映射到一条软件需求，每条软件需求至少追溯到一条系统需求。
案例拆解：追溯性缺失导致的集成失败
某智能座舱域控制器项目，系统需求中定义了“支持语音唤醒功能”，但在软件需求分析时，团队仅编写了“语音识别模块应支持唤醒词检测”，未明确唤醒词列表、唤醒灵敏度、误唤醒率等具体指标。在集成测试阶段，测试团队发现语音唤醒在高速行驶（风噪大）场景下无法触发，追溯后发现系统需求中“在车速超过100km/h时仍能正常唤醒”的约束未被软件需求覆盖。该问题导致返工，增加了4周开发周期。复盘发现，根因在于需求分析阶段未建立严格的追溯性检查，且未将非功能需求（噪声环境下的性能）细化到软件需求中。
4.3 ISO 21434：网络安全对需求分析的新维度
核心原理：威胁分析与安全需求
ISO 21434（道路车辆网络安全工程）要求在产品开发全生命周期中考虑网络安全。在需求分析阶段，其核心影响在于引入了 TARA（Threat Analysis and Risk Assessment）方法。TARA 的输出——网络安全目标（Cybersecurity Goals）和网络安全需求（Cybersecurity Requirements）——必须与功能需求、安全需求并行分析，并纳入同一需求管理框架。网络安全需求通常包括：安全通信（如 TLS、SecOC）、安全存储（密钥管理）、安全更新（OTA签名验证）、访问控制（诊断接口保护）等。
判断方法：TARA驱动的需求识别流程
- 资产识别：识别系统中的关键资产（如车辆控制指令、用户隐私数据、软件更新包）。
- 威胁场景建模：基于 STRIDE 或攻击树方法，分析可能的攻击路径（如通过 OBD 接口注入恶意诊断指令）。
- 影响评级：评估威胁对安全（Safety）、财务（Financial）、隐私（Privacy）、操作（Operational）的影响等级。
- 攻击可行性分析：考虑攻击者的能力、资源、攻击面暴露程度，确定攻击可行性等级。
- 风险值计算与决策：结合影响与可行性，确定风险等级，并制定缓解措施，转化为网络安全需求。
案例拆解：OTA升级功能的网络安全需求分析
某车型计划支持 OTA 软件升级，需求分析阶段，安全团队对 OTA 功能进行了 TARA。资产定义为“OTA 升级包”和“ECU 刷写权限”。威胁场景包括：攻击者伪造升级包（影响：车辆控制被篡改，安全影响为 S3，财务影响为 S2）；攻击者通过中间人攻击拦截升级包（影响：隐私泄露，影响为 S2）；攻击者利用诊断接口直接刷写（影响：安全影响为 S3）。攻击可行性分析显示，伪造升级包需要破解签名密钥，可行性为低；中间人攻击需要物理接入车辆网络，可行性为中；诊断接口刷写需要专用工具，可行性为中。最终风险等级分别为：伪造升级包为高（因影响极大），中间人攻击为中，诊断接口刷写为中。据此，需求分析中新增了以下网络安全需求：升级包必须使用 ECC 256 位签名验证；OTA 通信必须使用 TLS 1.3 加密；诊断刷写必须通过安关的访问控制列表校验。这些需求被纳入软件需求规格，并分配了对应的验证测试用例。
4.4 AUTOSAR：标准化架构对需求接口描述的影响
核心原理：软件组件与接口需求
AUTOSAR（Automotive Open System Architecture）是汽车电子系统软件架构的标准化组织，其分层架构（应用层、RTE、基础软件层）对需求分析的影响主要体现在：需求必须按照软件组件（SWC）的粒度进行描述，并明确端口（Port）和接口（Interface）定义。在 AUTOSAR 体系下，需求分析需要额外输出：SWC 划分需求、端口类型（Sender-Receiver、Client-Server）、数据元素（Data Element）、操作（Operation）以及事件（Event）的触发条件。这些接口需求是后续 RTE 配置和代码生成的基础。
操作流程：从系统需求到AUTOSAR接口需求
- SWC 划分：根据功能内聚性和硬件映射关系，将系统需求分配到多个 SWC。例如，车身控制模块可划分为“车门控制 SWC”“灯光控制 SWC”“车窗控制 SWC”。
- 端口定义：为每个 SWC 定义所需/所供端口，明确端口类型（Pport/Rport）和接口类型。
- 数据映射：将需求中的数据项（如车速信号、车门状态）映射为数据元素，并定义数据类型、初始值、取值范围。
- 事件与操作定义：对于 Client-Server 接口，定义操作名称、参数、返回值；对于 Sender-Receiver 接口，定义发送周期或事件触发条件。
| 需求类型 | 非AUTOSAR描述 | AUTOSAR描述 |
|---|---|---|
| 功能需求 | 系统应控制车窗升降 | SWC_WindowControl 应提供操作 WindowUp()/WindowDown()，通过 C/S 接口被车身控制器调用 |
| 数据需求 | 系统应获取车速信号 | SWC_VehicleSpeed 应通过 S/R 接口周期（100ms）发送 VehicleSpeed 数据元素（类型：Float，范围：0-300km/h） |
| 事件需求 | 车门开启时应触发迎宾灯 | SWC_DoorStatus 应通过 S/R 接口发送 DoorOpenEvent（事件触发），SWC_AmbientLight 订阅该事件 |
案例拆解：AUTOSAR接口需求不明确导致的集成问题
某项目在需求分析阶段，仅描述了“空调系统应能调节温度”，未定义 SWC 划分和接口。开发团队自行设计了两个 SWC：SWC_ClimateControl 和 SWC_HVAC_Actuator。在集成阶段，发现 SWC_ClimateControl 发送的温度设定值数据类型为 uint8（0-255），而 SWC_HVAC_Actuator 期望的数据类型为 int8（-128-127），导致温度设定值超过 127 时出现数据溢出。此外，两个 SWC 的端口类型不匹配（一个使用 S/R，另一个使用 C/S），导致 RTE 无法生成有效连接。最终通过重新定义接口需求，统一数据类型为 uint8（0-100 表示温度百分比），并将端口统一为 S/R 接口，才解决了集成问题。该案例说明，AUTOSAR 需求分析必须在早期就明确接口细节，否则后期集成成本极高。
4.5 ISO 21448（SOTIF）：预期功能安全对需求分析的前瞻性要求
核心原理：非故障触发风险与场景分析
ISO 21448（SOTIF）关注的是“没有故障但功能表现不满足预期”的风险，即由于性能局限、环境干扰、驾驶员误用等因素导致的风险。在需求分析阶段，SOTIF 要求对系统的预期功能进行场景化分析，识别潜在的功能不足（Functional Insufficiency）和触发条件（Triggering Conditions）。例如，自适应巡航系统（ACC）在雨雾天气下传感器性能下降，可能导致无法识别前方静止车辆，这是典型的 SOTIF 风险。需求分析需要明确：系统在哪些场景下可能性能不足？这些场景下的最小性能要求是什么？系统应如何通过降级或提示来降低风险？
判断方法：场景驱动的需求补充流程
- 场景清单构建：基于操作设计域（ODD）定义，列出系统可能遇到的所有场景，包括天气、光照、道路类型、交通参与者、传感器遮挡等。
- 性能局限分析：针对每个场景，分析传感器、算法、执行器的性能边界。例如，摄像头在逆光下的动态范围不足，雷达在隧道内的多径反射。
- 触发条件识别：确定导致功能不足的具体触发条件，如“雨量大于 50mm/h”“对向车辆远光灯直射”等。
- 需求补充与验证标准定义：针对识别出的风险，补充需求，例如“在雨量大于 50mm/h 时，系统应降低最高车速至 80km/h 并提示驾驶员”。同时定义验证场景和通过标准。
案例拆解：自动紧急制动（AEB）系统的SOTIF需求分析
某 AEB 系统在需求分析阶段，团队仅基于 ISO 26262 定义了故障情况下的安全需求，未考虑 SOTIF。在实车测试中，发现系统在雨天夜间场景下，对横穿马路的行人识别率仅为 60%，远低于设计目标 95%。分析发现，摄像头在低照度+雨滴反光条件下性能下降，毫米波雷达对行人反射截面积小，融合算法置信度不足。团队通过场景分析，补充了以下需求：在雨天夜间（雨量>20mm/h，照度<10lux）场景下，AEB 系统应至少提前 1.2 秒发出预警，并保证 80% 以上的行人识别率；若置信度低于阈值，系统应自动降低车速至 40km/h 并提示驾驶员接管。同时，新增了 12 个 SOTIF 验证场景，包括不同雨量、不同照度、不同行人速度的组合。经过需求补充和算法优化，最终在目标场景下的识别率提升至 92%。
4.6 五大标准对需求分析的综合影响与协同策略
核心原理：多标准融合的需求分析框架
在实际项目中，五大标准并非孤立作用，而是相互交织。ISO 26262 和 ISO 21448 共同覆盖“安全”维度（故障安全+预期功能安全），ISO 21434 覆盖“网络安全”维度，ASPICE 覆盖“过程质量”维度，AUTOSAR 覆盖“实现架构”维度。需求分析必须建立统一的框架，将安全需求、网络安全需求、功能需求、非功能需求和接口需求整合到同一需求管理体系中，并确保它们之间的冲突被识别和解决。
协同策略：需求属性的多维标注
建议在需求管理工具中为每条需求增加以下属性标签：
- 安全属性：ASIL 等级（QM/A/B/C/D）、关联安全目标 ID。
- 网络安全属性：关联 TARA 项 ID、网络安全目标 ID。
- SOTIF属性：关联场景 ID、触发条件描述。
- 过程属性：需求来源（利益相关方/系统/软件）、创建者、评审状态、基线版本。
- 架构属性：关联 SWC 名称、端口名称、接口类型。
| 需求ID | 需求描述 | ASIL | 网络安全目标 | SOTIF场景 | SWC/接口 |
|---|---|---|---|---|---|
| REQ_SYS_001 | 车辆在行驶中应能检测前方障碍物并触发紧急制动 | ASIL D | CYB_003（防止制动指令被篡改） | SCN_012（雨天夜间行人横穿） | SWC_AEB / Pport_AEB_Trigger |
| REQ_SYS_002 | 系统应通过安关验证所有外部诊断请求 | QM | CYB_001（防止未授权诊断访问） | N/A | SWC_DiagGateway / Rport_DiagReq |
| REQ_SYS_003 | 在雨量大于50mm/h时，系统应限制最高车速至80km/h | ASIL B | N/A | SCN_008（暴雨场景） | SWC_VehicleSpeedLimit / S/R接口 |
案例拆解：多标准冲突的识别与解决
某智能驾驶域控制器项目中，ISO 26262 安全需求要求“紧急制动指令必须在 100ms 内执行”，而 ISO 21434 网络安全需求要求“所有制动指令必须通过 HSM 签名验证”，签名验证过程需要额外 30ms 时间。两者存在冲突。需求分析团队组织安全、网络安全和架构工程师联合评审，最终决定：在正常操作模式下，制动指令通过 SecOC 轻量级认证（增加 10ms）；在检测到潜在攻击时，切换至完整 HSM 签名验证（增加 30ms），但此时安全需求放宽至 150ms。该方案通过需求属性中的“模式”字段进行区分，并在验证阶段分别测试两种模式下的响应时间。此案例说明，多标准冲突需要需求分析阶段主动识别，并通过设计权衡解决，而非在测试阶段暴露。