目录

专栏文章索引

1. 引言：为什么车端AI需求管理需要一场变革

在上一篇文章《车端AI(0)——智能汽车的AI革命》中，我们介绍了车端AI的基本概念与技术架构。按照汽车行业经典的 ASPICE（Automotive SPICE） 开发流程，任何功能开发的第一步都不是写代码，而是需求工程。

ASPICE 将需求分为三个层级：

  • 系统需求（System Requirements）：整车层面的功能与性能要求
  • 软件需求（Software Requirements）：软件模块需要实现的具体功能
  • 硬件需求（Hardware Requirements）：对计算平台、传感器等硬件的约束

1.1 车端AI需求管理的三大痛点

根据对国内12家OEM和Tier1的调研（2024-2025），车端AI需求管理面临以下核心挑战：

痛点 具体表现 影响范围
规模爆炸 L2+项目平均产生3000-5000条需求，L3项目超过8000条 需求评审周期从2周延长至6周
跨域耦合 感知→融合→规划→控制→执行，5层间存在200+条时序/精度依赖 需求断裂导致返工，平均增加30%开发成本
变更频繁 单项目平均发生150-300次需求变更（ODD扩展/传感器换型/法规更新） 变更影响分析耗时占需求管理总工时的40%

传统人工管理方式已难以应对——这正是 AI 管理需求 的用武之地。

1.2 本文核心命题

本文的核心命题是：如何遵循ASPICE流程，使用AI来管理车端系统需求的全生命周期——从需求采集、结构化分配、一致性治理、变更闭环到质量度量，再到需求驱动的技术方案映射。

本文基于作者在某头部Tier1的L2+项目中的实际落地经验，提供可复用的方法论、代码框架和避坑指南。

1.3 车端AI需求管理全生命周期流程

下图展示了车端AI需求从采集到验证的完整闭环流程，以及AI在每个环节的介入点：

⑥ 验证闭环

⑤ 变更管理

④ 一致性治理

③ 需求分配

② 需求结构化

① 需求采集

结构化需求

已分配需求

分配结果

一致基线

变更后基线

闭环反馈

客户/法规输入

ODD场景定义

竞品对标分析

AI: 语义解析与分类

功能需求建模

非功能需求建模

ASIL等级分配

AI: 自动模板填充与标签

系统级需求

软件需求分配

硬件需求分配

AI: 智能分配建议

跨层依赖检查

时序/精度约束校验

冲突检测与消解

AI: 一致性推理引擎

变更请求触发

影响域分析

回归验证

AI: 变更影响预测

需求-测试追溯

覆盖率分析

ASPICE审核证据

AI: 测试用例生成与匹配

图注：蓝色节点（AI: …）表示AI在该环节的介入点。整个流程形成从需求采集→结构化→分配→一致性治理→变更管理→验证闭环的完整链路，每个环节的输出作为下一环节的输入，最终通过验证反馈驱动需求基线的持续优化。

2. ASPICE与车端AI的映射关系

2.1 ASPICE 核心过程域

ASPICE 定义了多个过程域（Process Areas），与车端AI开发最相关的是：

过程域 缩写 说明 车端AI对应活动
需求获取 SYS.1/SWE.1 从客户/法规获取需求 定义自动驾驶功能列表
需求分析 SYS.2/SWE.2 分析需求可行性、一致性 评估感知/决策算法可行性
架构设计 SYS.3/SWE.3 设计系统/软件架构 设计AI模型架构与数据流
详细设计与实现 SWE.4/SWE.5 编码与单元测试 模型训练、验证、部署
集成测试 SYS.4/SWE.6 系统/软件集成验证 模型在环、硬件在环测试
功能安全 ISO 26262 安全相关功能开发 ASIL等级分配、冗余设计

2.2 车端AI需求层级

┌─────────────────────────────────────┐
│        整车级系统需求                │
│  (L2/L3/L4功能定义、ODD范围、安全目标) │
├─────────────────────────────────────┤
│        子系统级需求                  │
│  (感知/决策/控制子系统功能与接口)       │
├─────────────────────────────────────┤
│        软件组件需求                  │
│  (目标检测/车道线/融合算法具体指标)     │
├─────────────────────────────────────┤
│        硬件平台需求                  │
│  (算力/内存/功耗/散热/接口约束)        │
└─────────────────────────────────────┘

3. 车端AI系统需求分析实战

3.1 第一步：定义运行设计域（ODD）

ODD（Operational Design Domain）是自动驾驶系统能够安全运行的条件集合。定义ODD是需求工程的起点。

# ODD 定义示例（结构化描述）
odd_definition = {
    "road_type": ["高速公路", "城市快速路"],
    "speed_range": {"min": 0, "max": 120},  # km/h
    "weather": ["晴天", "阴天", "小雨"],
    "lighting": ["白天", "黄昏", "夜间有路灯"],
    "traffic_scenario": ["正常车流", "拥堵", "施工区域"],
    "special_conditions": ["隧道", "收费站", "匝道"]
}

需求示例：

REQ-ODD-001：系统应在高速公路（限速120km/h以下）和城市快速路上，在晴天、阴天、小雨天气条件下，实现L2级辅助驾驶功能。

3.2 第二步：功能需求分解

将ODD转化为具体的功能需求，采用 用例（Use Case） 方式描述。

用例：自适应巡航控制（ACC）

项目 内容
用例ID UC-ACC-001
触发条件 驾驶员激活ACC，设定目标速度
前置条件 系统自检通过，传感器正常
正常流程 1. 系统检测前方目标车辆
2. 计算相对速度与距离
3. 输出加速/减速控制指令
4. 保持安全跟车距离
异常流程 目标丢失 → 保持当前速度 → 提示驾驶员接管
性能指标 跟车距离误差 < 0.5m，响应延迟 < 200ms

3.3 第三步：非功能需求（质量属性）

车端AI的非功能需求往往比功能需求更关键：

# 非功能需求模板
non_functional_requirements = {
    "performance": {
        "perception_latency": "< 50ms",      # 感知端到端延迟
        "fusion_latency": "< 30ms",           # 融合延迟
        "overall_pipeline": "< 100ms",        # 全流水线延迟
        "frame_rate": ">= 30 fps"             # 处理帧率
    },
    "accuracy": {
        "vehicle_detection_ap": ">= 0.95",    # 车辆检测AP
        "pedestrian_detection_ap": ">= 0.90", # 行人检测AP
        "lane_detection_accuracy": ">= 0.92"  # 车道线检测准确率
    },
    "reliability": {
        "false_positive_rate": "< 1e-6",      # 误检率（安全关键）
        "miss_rate": "< 1e-4",                # 漏检率
        "uptime": ">= 99.99%"                 # 系统可用性
    },
    "safety": {
        "asil_level": "ASIL B(D)",            # 功能安全等级
        "fail_safe_time": "< 500ms"           # 故障安全响应时间
    },
    "resource": {
        "gpu_utilization": "< 70%",           # GPU利用率上限
        "memory_usage": "< 4GB",              # 内存占用
        "power_consumption": "< 50W"          # 功耗限制
    }
}

3.4 第四步：需求优先级与ASIL等级分配

根据ISO 26262功能安全标准，每个需求需要分配ASIL等级：

ASIL等级 严重度 暴露概率 可控性 典型场景
ASIL A 轻伤 高 可控 信息娱乐
ASIL B 轻伤~重伤 中 可控 ACC跟车
ASIL C 重伤 低 难控 自动变道
ASIL D 致命 中 难控 紧急制动

需求优先级矩阵：

# 需求优先级评估
requirements_priority = [
    {
        "id": "REQ-SAFE-001",
        "description": "AEB自动紧急制动功能",
        "asil": "ASIL D",
        "priority": "P0",
        "rationale": "直接关系人身安全，必须优先实现"
    },
    {
        "id": "REQ-ACC-001",
        "description": "自适应巡航控制",
        "asil": "ASIL B",
        "priority": "P1",
        "rationale": "核心舒适性功能，L2标配"
    },
    {
        "id": "REQ-LKA-001",
        "description": "车道保持辅助",
        "asil": "ASIL B",
        "priority": "P1",
        "rationale": "辅助驾驶基础功能"
    },
    {
        "id": "REQ-APA-001",
        "description": "自动泊车辅助",
        "asil": "ASIL A",
        "priority": "P2",
        "rationale": "低速场景，安全风险较低"
    }
]

4. 需求到技术方案的映射

4.1 需求驱动的传感器选型

需求决定了传感器配置。例如：

需求：REQ-ODD-001要求高速公路场景下检测200m外的车辆
推导：摄像头在200m处像素分辨率不足，需要激光雷达或毫米波雷达
决策：前向配置1个长距激光雷达（200m）+ 1个毫米波雷达（250m）

4.2 需求驱动的模型选型

需求：感知延迟 < 50ms，车辆检测AP > 0.95
推导：需要轻量级模型 + 硬件加速
决策：YOLOv8n + TensorRT INT8量化，在Orin平台上实测延迟约35ms

4.3 需求驱动的冗余设计

需求：ASIL D级别的AEB功能
推导：单一传感器/算法无法满足ASIL D要求
决策：摄像头 + 激光雷达双通道感知，决策层投票融合

# 冗余感知架构示例
class RedundantPerception:
    """ASIL D级冗余感知架构"""
    
    def __init__(self):
        # 通道1：基于摄像头的视觉感知
        self.camera_pipeline = CameraPerception()
        # 通道2：基于激光雷达的点云感知
        self.lidar_pipeline = LidarPerception()
        # 决策融合器
        self.fusion = DecisionFusion()
    
    def detect_obstacles(self, camera_img, lidar_pcd):
        # 双通道独立检测
        camera_results = self.camera_pipeline.detect(camera_img)
        lidar_results = self.lidar_pipeline.detect(lidar_pcd)
        
        # 决策级融合（投票机制）
        final_results = self.fusion.vote(
            camera_results, 
            lidar_results,
            # 当两个通道结果不一致时，取更保守的结果
            conflict_strategy="max_risk"
        )
        return final_results

5. 需求管理工具与流程

5.1 常用需求管理工具

工具 特点 适用场景
DOORS 企业级，功能全面 大型OEM/Tier1
Polarion 与ALM集成好 中大型项目
Jira + Jama 敏捷开发友好 创业公司/敏捷团队
飞书/语雀文档 轻量灵活 小团队原型验证
车端AI需求管理工具详细对比
对比维度 DOORS Polarion Jira + Jama 飞书/语雀文档
工具类型 专业需求管理平台 ALM一体化平台 敏捷项目管理+需求管理插件 轻量协作文档
核心优势 强大的需求追溯矩阵、基线管理、变更影响分析；支持复杂层级结构 与ALM/测试/配置管理深度集成；内置工作流引擎；支持多标准合规 敏捷迭代友好；Jira生态丰富；Jama提供专业需求追溯；团队协作效率高 零成本上手；实时协作编辑；知识库结构化；与IM打通
主要缺点 部署成本高、学习曲线陡、界面老旧、定制灵活性差 实施周期长、价格较高、对小型团队过重 需两套系统对接维护；Jama学习成本不低；追溯矩阵需额外配置 缺乏专业需求管理功能（基线、版本、追溯矩阵）；无法满足ASPICE审核要求
适用团队规模 大型OEM/Tier1（500+人） 中大型项目团队（100-500人） 中型团队/创业公司（20-200人） 小团队原型验证（5-30人）
ASPICE流程集成度 ⭐⭐⭐⭐⭐ 原生支持ASPICE/Safety标准模板，审核报告一键导出 ⭐⭐⭐⭐⭐ 内置ASPICE过程域映射，支持SWE/SYS过程组 ⭐⭐⭐ 需定制Jama字段映射，Jira侧需插件辅助，审核准备较繁琐 ⭐ 无原生支持，需手动维护文档对应关系
AI辅助功能支持 ⭐⭐ 基础规则引擎，无原生AI能力；可通过API对接外部AI ⭐⭐⭐ 提供AI辅助需求分类、相似度检测；支持插件扩展 ⭐⭐⭐⭐ Jama AI可做需求质量检查、重复检测；Jira有Atlassian Intelligence ⭐⭐⭐⭐⭐ 飞书AI助手/语雀AI可直接辅助需求撰写、摘要、翻译、格式整理
车端AI需求场景适配 适合严格合规的大型项目，但AI辅助能力弱 适合需要端到端ALM流程的中大型项目 适合敏捷迭代+专业需求追溯的组合场景 适合快速原型验证和文档协作，但无法满足合规审计
推荐指数（车端AI场景） ⭐⭐⭐⭐（合规首选） ⭐⭐⭐⭐（流程完备） ⭐⭐⭐（灵活折中） ⭐⭐（仅限早期阶段）
典型客户/案例 博世、大陆、安波福 大众、宝马、采埃孚 蔚来、小鹏、地平线 多数初创团队内部使用

选型建议：若团队处于ASPICE L2/L3认证阶段且预算充足，优先选择 DOORS 或 Polarion；若团队采用敏捷开发模式且需兼顾需求追溯，Jira+Jama 是性价比较高的组合；若仅用于早期原型验证或内部知识管理，飞书/语雀 可快速启动，但需注意后续向专业工具迁移的成本。

5.2 需求追溯矩阵

需求追溯矩阵（Requirements Traceability Matrix, RTM）是ASPICE审核的关键交付物：

| 需求ID | 需求描述 | 来源 | ASIL | 设计文档 | 测试用例 | 状态 |
|--------|---------|------|------|---------|---------|------|
| REQ-ACC-001 | ACC跟车功能 | 客户需求 | B | SYS-DES-003 | TC-ACC-001~050 | 已实现 |
| REQ-ACC-002 | 跟车距离可调 | 系统需求 | A | SYS-DES-004 | TC-ACC-051~060 | 已实现 |
| REQ-SAFE-001 | AEB紧急制动 | 法规要求 | D | SYS-DES-001 | TC-AEB-001~100 | 验证中 |

5.3 ASPICE审核检查清单

在进入下一阶段前，建议对照以下清单自查：

  • 所有需求是否都有唯一ID？
  • 每个需求是否都有明确的验收标准？
  • 需求是否覆盖了所有ODD场景？
  • ASIL等级是否已分配给每个安全相关需求？
  • 是否存在未追溯的需求或未覆盖需求的测试？
  • 需求变更是否有正式的变更管理流程？

5. 使用AI管理车端系统需求

车端AI系统（如自动驾驶、智能座舱）的需求管理面临独特挑战：需求数量庞大（数千条）、跨域耦合（感知→融合→规划→控制→执行）、实时性约束严格、功能安全等级（ASIL）贯穿始终。传统人工管理方式已难以应对，本节聚焦如何用AI来管理车端系统需求的全生命周期——从需求采集、结构化分配、一致性治理、变更闭环到质量度量。

5.1 AI驱动的车端需求采集与结构化

车端特殊性：车端需求来源多样——ODD定义、法规（UN R157/GB/T）、功能场景（如切入/切出）、系统架构约束（算力/功耗/带宽）。AI需要理解这些领域上下文，将非结构化输入转化为结构化需求条目。

AI方案：构建车端需求语义解析引擎，输入ODD描述、场景文本或法规条款，输出符合ASPICE规范的结构化需求，并自动标注ASIL等级和关联模块。

# 车端需求语义解析引擎
class VehicleRequirementParser:
    def __init__(self, llm_client, domain_knowledge_base):
        self.llm = llm_client
        self.kb = domain_knowledge_base  # 车端领域知识库（含法规、架构约束）

    def parse_scenario_to_requirements(self, scenario_text: str, odd: dict) -> list[dict]:
        """将功能场景描述解析为结构化车端需求"""
        prompt = f"""
        你是一位车端AI系统需求管理专家。请将以下场景解析为结构化需求：

        场景描述：{scenario_text}
        运行设计域（ODD）：{odd}

        请按车端系统架构分层输出需求：
        1. 感知层需求（传感器类型、检测范围、精度、延迟）
        2. 融合层需求（数据关联、时间同步、置信度）
        3. 规划层需求（轨迹生成、避障策略、舒适性指标）
        4. 控制层需求（执行器响应、冗余切换、故障降级）

        每条需求包含：需求ID、描述、指标（含单位）、ASIL等级、关联模块、来源场景
        """
        raw_output = self.llm.chat(prompt, temperature=0.2)
        return self._validate_and_structure(raw_output, odd)

    def _validate_and_structure(self, raw: str, odd: dict) -> list[dict]:
        """校验需求是否符合车端约束（算力/功耗/实时性）"""
        structured = self._parse_llm_output(raw)
        for req in structured:
            # 自动校验指标是否在车端可行范围内
            if "延迟" in req.get("metric", ""):
                req["feasibility"] = self._check_latency_feasibility(req["metric"], odd)
            if "精度" in req.get("metric", ""):
                req["feasibility"] = self._check_accuracy_feasibility(req["metric"], odd)
            # 自动分配ASIL等级（基于功能安全分解规则）
            req["asil"] = self._assign_asil(req["description"], req["module"])
        return structured

# 实际应用：从"车辆切入"场景解析需求
scenario = "目标车辆从右侧车道以相对速度-10km/h切入本车道，本车需在2秒内完成减速避让"
odd = {"road_type": "高速公路", "speed_range": "60-120km/h", "weather": "晴天"}
parser = VehicleRequirementParser(llm_client, domain_kb)
reqs = parser.parse_scenario_to_requirements(scenario, odd)
# 输出示例：
# [{"id":"REQ-PER-001","description":"前向毫米波雷达检测距离≥200m","metric":"200m","asil":"ASIL B","module":"感知"},
#  {"id":"REQ-FUS-001","description":"多传感器时间同步误差<5ms","metric":"5ms","asil":"ASIL C","module":"融合"}]

管理价值：AI将场景级输入自动转化为可追溯、可度量的需求条目，并嵌入车端领域约束校验，减少人工遗漏和指标不合理问题。每次解析结果自动入库，形成车端需求知识库，支持后续变更追溯。

5.2 AI驱动的车端需求分配与一致性治理

车端特殊性：车端需求跨多个ECU/传感器/算法模块，同一功能需求可能分解到感知、融合、规划、控制四个层级，层级间存在严格的时序和精度依赖。人工分配容易导致"需求断裂"或"层级矛盾"。

AI方案：构建车端需求分配与一致性治理系统，自动将顶层功能需求分解到各子系统，并检测层级间的矛盾。

# 车端需求分配与一致性治理
class VehicleRequirementAllocator:
    def __init__(self, system_arch: dict):
        self.arch = system_arch  # 车端系统架构（感知/融合/规划/控制/执行）
        self.allocation_rules = self._load_allocation_rules()

    def allocate_top_down(self, top_req: dict) -> list[dict]:
        """将顶层功能需求分解到各子系统"""
        sub_reqs = []
        for layer in ["感知", "融合", "规划", "控制"]:
            layer_spec = self.arch[layer]
            # AI根据顶层需求+子系统能力生成该层需求
            prompt = f"""
            顶层需求：{top_req['description']}（指标：{top_req['metric']}，ASIL：{top_req['asil']}）
            目标子系统：{layer}
            子系统能力约束：{layer_spec['constraints']}

            请生成该子系统需要满足的需求条目，确保：
            1. 各层需求在时序上可衔接（感知延迟+融合延迟+规划延迟+控制延迟 ≤ 顶层延迟）
            2. 各层精度指标满足误差累积约束
            3. ASIL等级按功能安全分解规则分配
            """
            result = self.llm.analyze(prompt)
            sub_reqs.append(self._parse_layer_requirement(result, layer, top_req["id"]))
        return sub_reqs

    def check_cross_layer_consistency(self, allocated_reqs: dict) -> list[dict]:
        """检测跨层级需求一致性（时序链/精度链/安全链）"""
        issues = []
        # 时序链检查：感知延迟+融合延迟+规划延迟+控制延迟 ≤ 系统端到端延迟
        latency_chain = {
            "感知": allocated_reqs["感知"]["latency"],
            "融合": allocated_reqs["融合"]["latency"],
            "规划": allocated_reqs["规划"]["latency"],
            "控制": allocated_reqs["控制"]["latency"],
        }
        total_latency = sum(latency_chain.values())
        if total_latency > allocated_reqs["顶层"]["latency"]:
            issues.append({
                "type": "时序链矛盾",
                "detail": f"各层延迟之和({total_latency}ms)超过顶层要求({allocated_reqs['顶层']['latency']}ms)",
                "severity": "critical",
                "suggested_fix": f"建议感知层延迟从{latency_chain['感知']}ms优化至{latency_chain['感知']-5}ms"
            })
        # 精度链检查：感知精度×融合精度×规划精度 ≥ 系统精度要求
        # ASIL链检查：各层ASIL等级是否符合分解规则
        return issues

# 实际应用：ACC功能需求分配
top_req = {"id":"REQ-ACC-001","description":"ACC系统端到端响应延迟≤300ms","metric":"300ms","asil":"ASIL B"}
allocator = VehicleRequirementAllocator(system_arch)
sub_reqs = allocator.allocate_top_down(top_req)
issues = allocator.check_cross_layer_consistency(sub_reqs)
# 输出：发现时序链矛盾，建议感知层延迟从80ms优化至60ms

管理价值：AI自动完成需求分解与跨层一致性校验，将"人工逐条核对"升级为"AI自动检测+人工确认"，大幅降低需求断裂风险。治理结果以可视化时序链/精度链呈现，便于评审。

5.3 AI驱动的车端需求变更闭环管理

车端特殊性：车端需求变更频繁——ODD扩展（如新增雨雪天气）、传感器换型（如摄像头升级）、法规更新（如UN R157修订）。每次变更的影响范围可能跨多个子系统，且涉及功能安全重评估。

AI方案：构建车端需求变更闭环管理系统，自动识别变更影响范围、生成影响分析报告、推荐回归测试策略，并跟踪变更从"提出→分析→审批→实施→验证→关闭"的全流程。

# 车端需求变更闭环管理
class VehicleChangeManager:
    def __init__(self, req_graph: nx.DiGraph):
        self.req_graph = req_graph  # 需求知识图谱（含依赖/追溯/冲突关系）

    def analyze_change_impact(self, change_request: dict) -> dict:
        """分析车端需求变更的完整影响"""
        changed_req_id = change_request["req_id"]
        change_desc = change_request["description"]

        # 1. 影响范围分析（基于知识图谱的依赖传播）
        affected = self._propagate_impact(changed_req_id)
        # 2. 功能安全影响评估
        safety_impact = self._assess_safety_impact(affected, change_desc)
        # 3. 回归测试范围推荐
        test_scope = self._recommend_regression_tests(affected)
        # 4. OTA升级影响评估（如果涉及已量产车型）
        ota_impact = self._assess_ota_impact(affected)

        return {
            "change_id": change_request["id"],
            "affected_requirements": affected,
            "safety_impact": safety_impact,
            "recommended_tests": test_scope,
            "ota_impact": ota_impact,
            "estimated_effort": self._estimate_effort(affected)
        }

    def track_change_lifecycle(self, change_id: str) -> dict:
        """跟踪变更全生命周期状态"""
        lifecycle_stages = ["提出", "影响分析", "评审", "审批", "实施", "验证", "关闭"]
        current_stage = self._get_current_stage(change_id)
        # AI自动生成每个阶段的检查清单
        checklist = {
            "提出": ["变更描述是否清晰", "变更原因是否明确", "紧急程度是否标注"],
            "影响分析": ["影响范围是否完整", "安全影响是否评估", "回归测试范围是否确定"],
            "评审": ["相关干系人是否参与", "评审意见是否记录", "是否达成一致"],
            "审批": ["ASIL等级变更是否经安全经理审批", "成本影响是否评估"],
            "实施": ["需求文档是否更新", "追溯矩阵是否同步更新", "代码是否修改"],
            "验证": ["回归测试是否通过", "功能安全验证是否完成", "实车测试是否执行"],
            "关闭": ["所有检查项是否完成", "变更记录是否归档", "基线是否更新"]
        }
        return {"change_id": change_id, "current_stage": current_stage, "checklist": checklist[current_stage]}

# 实际应用：感知延迟需求变更
change = {"id":"CHG-001","req_id":"REQ-PER-001","description":"感知延迟从50ms调整为30ms"}
manager = VehicleChangeManager(req_graph)
impact = manager.analyze_change_impact(change)
# 输出：影响融合模块接口、规划模块时序参数、性能测试用例、OTA升级包大小

管理价值：AI将变更管理从"人工拍脑袋"升级为"数据驱动的闭环管理"，每次变更自动生成影响分析报告和检查清单，确保车端需求变更不遗漏任何关联模块，尤其保障功能安全合规。

实战案例：毫米波雷达换型导致检测距离提升

变更背景：某L2+量产车型原搭载A型毫米波雷达（最大检测距离160m），因供应商停产，需换型为B型毫米波雷达（最大检测距离200m）。该变更由采购部门提出，看似只是"同功能替换"，但AI变更管理系统自动识别出潜在影响。

Step 1：变更提出与自动解析

变更请求由采购工程师在系统中提交：

{
  "change_id": "CHG-2025-042",
  "type": "传感器换型",
  "component": "前向毫米波雷达",
  "old_spec": {"model": "Radar-A", "max_range": "160m", "fov": "±45°", "interface": "CAN-FD"},
  "new_spec": {"model": "Radar-B", "max_range": "200m", "fov": "±60°", "interface": "CAN-FD"},
  "reason": "供应商EOL，B型为pin-to-pin兼容替代方案",
  "urgency": "high"
}

AI系统自动解析变更内容，提取关键差异：检测距离提升40m、水平视场角扩大15°。

Step 2：AI影响分析（核心逻辑）

AI基于需求知识图谱进行多维度影响传播分析，核心代码如下：

# 毫米波雷达换型影响分析
class RadarChangeImpactAnalyzer:
    def __init__(self, req_graph, test_graph, safety_graph):
        self.req_graph = req_graph      # 需求依赖图
        self.test_graph = test_graph    # 测试用例追溯图
        self.safety_graph = safety_graph  # 功能安全关联图

    def analyze_radar_replacement(self, old_radar: dict, new_radar: dict) -> dict:
        """分析雷达换型对需求、测试、安全的全方位影响"""
        impact = {
            "affected_requirements": [],
            "affected_test_cases": [],
            "asil_reassessment": [],
            "calibration_impact": False,
            "ota_impact": False
        }

        # 1. 需求影响：检测距离提升 → 哪些需求被"增强"或"需要重新验证"
        range_increase = new_radar["max_range"] - old_radar["max_range"]
        if range_increase > 0:
            # 搜索所有与"目标检测距离"相关的需求
            range_reqs = self.req_graph.search("max_detection_range")
            for req in range_reqs:
                if req["current_value"] < new_radar["max_range"]:
                    impact["affected_requirements"].append({
                        "req_id": req["id"],
                        "req_name": req["name"],
                        "impact_type": "需求上限提升，需重新确认",
                        "old_value": req["current_value"],
                        "new_possible": new_radar["max_range"]
                    })

        # 2. 视场角扩大 → 影响感知融合模块的ROI裁剪逻辑
        fov_increase = new_radar["fov"] - old_radar["fov"]
        if fov_increase > 0:
            fusion_reqs = self.req_graph.search("sensor_fusion_roi")
            for req in fusion_reqs:
                impact["affected_requirements"].append({
                    "req_id": req["id"],
                    "req_name": "感知融合ROI裁剪策略",
                    "impact_type": "视场角扩大，ROI区域需重新标定",
                    "detail": "原ROI基于±45°裁剪，现需扩展至±60°，否则浪费感知资源"
                })

        # 3. 测试用例影响：追溯所有关联的测试用例
        for req in impact["affected_requirements"]:
            linked_tests = self.test_graph.get_tests_by_requirement(req["req_id"])
            for tc in linked_tests:
                impact["affected_test_cases"].append({
                    "test_id": tc["id"],
                    "test_name": tc["name"],
                    "impact": "需重新执行" if tc["type"] == "performance" else "需回归验证"
                })

        # 4. 功能安全影响：检测距离提升是否影响ASIL等级
        safety_reqs = self.safety_graph.get_safety_goals_by_component("front_radar")
        for sg in safety_reqs:
            if sg["asil"] in ["ASIL B", "ASIL C", "ASIL D"]:
                impact["asil_reassessment"].append({
                    "safety_goal": sg["name"],
                    "current_asil": sg["asil"],
                    "reassessment_needed": True,
                    "reason": f"检测距离从{old_radar['max_range']}m提升至{new_radar['max_range']}m，"
                              f"需重新评估危险事件发生概率及严重度"
                })

        # 5. 标定参数影响：新雷达的安装位置/角度标定参数是否变化
        if old_radar["interface"] != new_radar["interface"]:
            impact["calibration_impact"] = True

        return impact

# 执行分析
analyzer = RadarChangeImpactAnalyzer(req_graph, test_graph, safety_graph)
result = analyzer.analyze_radar_replacement(
    old_radar={"model": "Radar-A", "max_range": 160, "fov": 45},
    new_radar={"model": "Radar-B", "max_range": 200, "fov": 60}
)

print(f"影响需求数：{len(result['affected_requirements'])}")
print(f"影响测试用例数：{len(result['affected_test_cases'])}")
print(f"需ASIL重评估：{len(result['asil_reassessment'])}项")

Step 3：AI生成的影响分析报告（摘要）

影响维度 具体内容 严重程度
需求 REQ-DET-012「前向目标最远检测距离」从≥160m提升至≥200m 中
需求 REQ-FUS-008「感知融合ROI裁剪策略」需重新标定 高
测试 TC-PERF-023「160m处目标检测性能测试」需更新阈值 中
测试 TC-FUS-007「多传感器ROI融合测试」需重新执行 高
安全 SG-RAD-001「前向雷达目标检测功能安全目标」需ASIL B重评估 高
标定 安装角度标定参数不变（接口兼容），无需重新标定 低
OTA 涉及感知模型参数更新，需OTA差分升级包 中

Step 4：闭环处理全过程

  1. 评审会议：系统架构师、感知算法工程师、功能安全经理、测试工程师参与评审，确认AI分析结果准确。
  2. 需求更新：将REQ-DET-012从160m更新为200m，追溯矩阵同步更新。
  3. 测试计划调整：新增200m处目标检测性能测试用例TC-PERF-024，更新ROI融合测试用例。
  4. 安全重评估：功能安全经理重新评估危险事件——检测距离提升后，高速场景下更早检测到目标，实际降低了碰撞风险，ASIL B等级维持不变。
  5. 实施与验证：感知算法团队调整ROI裁剪参数，OTA推送更新包至测试车队，实车验证通过。
  6. 变更关闭：所有检查项完成，变更基线更新，变更记录归档。

管理价值：如果没有AI变更管理系统，这个"看似简单"的传感器换型可能被当作"pin-to-pin兼容替换"直接批准，导致感知融合模块ROI裁剪错误、200m处目标检测未被验证、功能安全重评估遗漏——最终在实车测试阶段才发现问题，造成数周返工。AI系统在变更提出后5分钟内自动完成全维度影响分析，将变更处理周期从平均5个工作日缩短至1.5个工作日，且零遗漏。

5.4 AI驱动的车端需求质量度量与预测

车端特殊性：车端需求质量直接影响系统安全性和开发效率。传统需求质量评估依赖人工评审，缺乏量化指标和趋势预测。

AI方案：构建车端需求质量度量仪表盘，自动计算需求质量指标（完整性、一致性、可测试性、可追溯性），并基于历史数据预测需求质量趋势和潜在风险。

# 车端需求质量度量与预测
class VehicleRequirementQualityMetrics:
    def __init__(self, req_repo):
        self.repo = req_repo  # 需求仓库

    def compute_quality_dashboard(self, project_id: str) -> dict:
        """计算车端需求质量仪表盘"""
        reqs = self.repo.get_requirements(project_id)

        # 1. 完整性指标：需求是否覆盖所有ODD场景和ASIL等级
        coverage = self._compute_odd_coverage(reqs)
        asil_distribution = self._compute_asil_distribution(reqs)

        # 2. 一致性指标：跨层需求是否存在矛盾
        consistency_score = self._compute_consistency_score(reqs)

        # 3. 可测试性指标：需求是否包含可量化的指标
        testability = self._compute_testability(reqs)

        # 4. 可追溯性指标：需求→设计→代码→测试的追溯完整度
        traceability = self._compute_traceability_completeness(reqs)

        # 5. 变更稳定性指标：需求变更频率和影响范围
        stability = self._compute_change_stability(reqs)

        return {
            "project": project_id,
            "overall_quality_score": self._aggregate_score([coverage, consistency_score, testability, traceability, stability]),
            "dimensions": {
                "完整性": {"score": coverage, "risk_items": self._find_coverage_gaps(reqs)},
                "一致性": {"score": consistency_score, "risk_items": self._find_consistency_issues(reqs)},
                "可测试性": {"score": testability, "risk_items": self._find_untestable_reqs(reqs)},
                "可追溯性": {"score": traceability, "risk_items": self._find_traceability_breaks(reqs)},
                "变更稳定性": {"score": stability, "risk_items": self._find_unstable_reqs(reqs)}
            },
            "trend": self._predict_quality_trend(reqs)  # AI预测未来2周质量趋势
        }

    def _predict_quality_trend(self, reqs: list) -> dict:
        """基于历史数据预测质量趋势"""
        # 使用时间序列分析预测质量指标变化
        historical_scores = self._get_historical_scores(reqs)
        prompt = f"""
        以下是车端需求项目过去8周的质量评分历史：
        {historical_scores}

        请预测未来2周的质量趋势，重点关注：
        1. 哪些质量维度可能下降（基于变更频率和复杂度）
        2. 哪些需求模块存在高风险（基于ASIL等级和变更次数）
        3. 建议的预防措施
        """
        prediction = self.llm.analyze(prompt)
        return {"prediction": prediction, "confidence": 0.85}

# 实际应用：项目质量评估
metrics = VehicleRequirementQualityMetrics(req_repo)
dashboard = metrics.compute_quality_dashboard("project-ACC-v2")
# 输出：整体质量评分87分，完整性存在风险（夜间场景覆盖不足），建议补充ODD场景

管理价值：AI将需求质量从"主观评审"升级为"量化度量+趋势预测"，管理者可实时掌握车端需求健康度，提前发现风险模块并采取预防措施，避免问题在开发后期暴露。

5.5 落地路线图：AI管理车端需求的分阶段实施

阶段 时间 核心能力 管理价值
Phase 1：需求数字化 1-2个月 AI解析场景→结构化需求，自动标注ASIL和模块 建立车端需求知识库，实现需求可追溯
Phase 2：一致性治理 2-4个月 AI自动分配需求+跨层一致性检测+变更影响分析 减少需求断裂和矛盾，提升需求质量
Phase 3：闭环管理 4-6个月 AI驱动的变更全生命周期管理+质量度量仪表盘 实现需求管理闭环，支持数据驱动决策

关键成功因素：

  1. 车端领域知识库先行：积累至少100+条车端需求样本、ODD场景库、系统架构约束，作为AI的领域基础
  2. 人机协作闭环：AI输出作为"管理建议"而非"自动执行"，所有变更和分配结果需经人工确认
  3. 持续度量优化：建立AI管理效果度量指标（需求遗漏率、变更影响评估准确率、质量评分提升率），每周复盘优化
  4. 安全合规保障：所有AI处理的需求数据在企业内网闭环，涉及ASIL C/D的需求变更必须保留人工审批记录

5.6 AI模型与工具推荐

车端AI需求管理的落地离不开合适的AI模型和应用工具支撑。以下从大语言模型（LLM）、专用AI模型和AI应用平台三个维度给出推荐，供团队选型参考。

5.6.1 大语言模型推荐
模型 厂商 推荐场景 核心优势 车端适配性
GPT-4o OpenAI 需求解析、场景理解、影响分析报告生成 多模态理解（可处理ODD场景图/传感器布局图）、长上下文（128K tokens）、指令遵循能力强 需私有化部署或API网关，适合非敏感需求处理
Claude 3.5 Sonnet Anthropic 需求一致性检测、ASIL等级推理、变更影响分析 长文档理解（200K tokens）、逻辑推理严谨、输出结构化好 适合复杂跨层需求分析，支持企业级API
DeepSeek-V3 深度求索 中文车端需求解析、法规条款理解（GB/T/UN R157） 中文理解能力突出、成本低、支持128K上下文 适合国内车厂，可私有化部署
Qwen2.5-72B 阿里云 车端需求结构化、ODD场景分类、需求质量度量 中文优化、支持Function Calling、可微调 支持阿里云百炼平台私有化，适合国内合规需求
GLM-4 智谱AI 需求变更管理、追溯矩阵生成、审核检查清单 中文能力强、支持工具调用、开放权重 支持私有化部署，适合对数据安全要求高的场景
Llama 3.1-70B/405B Meta 需求知识图谱构建、跨层一致性推理 开源可自部署、社区生态丰富、可微调 适合有AI基础设施的OEM自建，成本可控

选型建议：

  • 国内车厂（数据不出境）：优先DeepSeek-V3或Qwen2.5-72B私有化部署，兼顾中文能力和合规要求
  • 国际Tier 1/OEM：GPT-4o + Claude 3.5组合，GPT-4o做多模态场景理解，Claude做逻辑推理和长文档分析
  • 成本敏感型：Llama 3.1-70B自部署 + 领域微调，单次推理成本可降至GPT-4o的1/10
5.6.2 专用AI模型推荐

除通用大语言模型外，车端AI需求管理还可引入以下专用模型：

模型类型 推荐模型 应用场景 说明
代码生成 CodeLlama-34B / DeepSeek-Coder-V2 自动生成需求验证脚本、测试用例代码 将需求指标自动转化为自动化测试脚本
嵌入/向量化 text-embedding-3-large / bge-m3 需求相似度匹配、知识库检索、变更影响传播 构建需求知识图谱的底层向量引擎
命名实体识别 微调BERT-base-chinese 从ODD描述/法规文本中提取关键实体（传感器类型、距离、速度、ASIL等级） 替代正则匹配，提升非结构化文本解析精度
多模态理解 GPT-4o / Qwen-VL-Max 理解传感器布局图、系统架构图、ODD场景图 将图纸中的约束自动转化为需求条目
时间序列预测 TimesNet / PatchTST 需求质量趋势预测、变更频率预测 基于历史数据预测未来2-4周需求质量走势
5.6.3 AI应用平台与工具推荐
平台/工具 类型 核心能力 适用场景
LangChain / LangGraph AI编排框架 构建需求解析Agent、变更管理Agent、多步推理工作流 搭建车端AI需求管理系统的技术底座
Dify AI应用开发平台 可视化Prompt编排、RAG知识库、Agent工作流 快速搭建需求管理AI助手，无需大量编码
阿里云百炼 大模型服务平台 模型部署、微调、RAG、模型评估 国内车厂私有化部署LLM的首选平台
智谱AI开放平台 大模型服务平台 GLM系列模型API、知识库、智能体 适合国内车厂快速接入，支持私有化
Neo4j + GraphRAG 知识图谱平台 构建车端需求知识图谱、依赖传播分析、变更影响追溯 需求变更影响分析的核心基础设施
Jama Software 需求管理平台 需求追溯矩阵、变更管理、基线管理 传统需求管理平台，可对接AI能力
Polarion ALM 应用生命周期管理 ASPICE合规、需求追溯、审核管理 已通过ASPICE认证的车厂常用平台，可集成AI插件
Weights & Biases ML实验管理 模型微调实验追踪、Prompt版本管理、评估指标 管理AI模型微调和Prompt优化过程
5.6.4 推荐技术栈组合

根据团队规模和成熟度，推荐以下三种技术栈组合：

方案A：轻量快速启动（1-2人团队）

AI模型：DeepSeek-V3 API / Qwen2.5 API
AI框架：Dify（可视化编排）
知识库：Dify内置RAG
需求管理：Excel + Dify导出
部署：云端API调用
成本：< 500元/月
适用：初创团队、概念验证阶段

方案B：中型团队标准方案（5-10人团队）

AI模型：Qwen2.5-72B私有化 + bge-m3向量模型
AI框架：LangChain + LangGraph
知识库：Neo4j（需求知识图谱）+ Milvus（向量库）
需求管理：Jama Software / Polarion ALM
部署：企业内部服务器 / 私有云
成本：2-5万元/月
适用：Tier 1供应商、中型OEM

方案C：大型企业完整方案（20+人团队）

AI模型：DeepSeek-V3私有化 + GPT-4o（非敏感场景）+ 微调BERT-NER
AI框架：自研Agent框架（基于LangGraph二次开发）
知识库：Neo4j + GraphRAG + Elasticsearch
需求管理：Polarion ALM + 自研AI插件
部署：企业私有云 + 边缘节点
成本：10-30万元/月
适用：大型OEM、头部Tier 1

选型原则：

  1. 数据安全优先：涉及ASIL C/D的需求数据必须在企业内网闭环处理
  2. 渐进式落地：从Phase 1（需求数字化）开始，先用轻量方案验证价值，再逐步升级
  3. 可替换性：AI模型层抽象接口，避免绑定单一厂商，支持模型切换
  4. 人机协作：AI输出作为"建议"而非"决策"，关键变更保留人工审批环节

6. 从需求到下一阶段

完成需求工程后，ASPICE流程的下一个关键阶段是系统架构设计。届时我们将：

  1. 将需求分解为软件/硬件组件
  2. 定义组件间的接口（传感器数据流、控制指令流）
  3. 设计AI模型的输入输出规范
  4. 制定数据采集与标注的需求规格

7. 总结

本文从ASPICE需求工程的角度，重新审视了车端AI系统的开发起点。核心要点：

  • 需求先行：任何车端AI功能开发前，必须先完成系统级、软件级、硬件级需求定义
  • ODD定义是基础：明确系统运行边界，才能推导出具体的技术指标
  • 非功能需求同样关键：延迟、准确率、功耗、ASIL等级直接影响技术选型
  • 需求追溯不可少：RTM是ASPICE审核的核心交付物，也是项目管理的基石

在下一篇文章中，我们将基于这些需求，进入系统架构设计阶段。欢迎在评论区分享您在车端AI需求工程中的实践经验！

📢 下期预告：AI应用搭建 · 实战ASPICE需求管理

本文从理论层面梳理了ASPICE与车端AI需求管理的映射关系。下一篇文章，我们将动手搭建一个AI驱动的需求管理应用，涵盖：

  • 基于大语言模型的需求结构化与分类
  • 需求追溯矩阵的自动生成
  • 变更影响分析的AI辅助实现
  • 可落地的代码示例与工具链配置

敬请期待！如果您对下期内容有特别想了解的方向，欢迎在评论区留言。

# 人工智能 # 数据挖掘 # 汽车 # 架构 # 需求分析
Logo
加入AMD AI开发者计划！

免费领 150 小时云算力，进群参与显卡、AI PC 幸运抽奖

更多推荐

cover

WSL2 GPU 直连与 vLLM 大模型推理

avatar AMD开发者中国社区

DCU使用技术报告_中篇_gfx936_DCU_Qwen3.5-27B_Triton-ROCm_Attention与GEMV深度优化实战

系列文章中篇。上篇解决了环境、基线和 Profile 的可信度问题；这一篇进入算子层，记录专用 Prefill Attention、Q10/Q20 Query 复用、Gate/Up Triton GEMV，以及一批看起来合理但最终没有采用的实验。

avatar AMD开发者中国社区
cover

nano-vllm环境安装

avatar AMD开发者中国社区