课程导入：学习目标、课程适用人群、SysML在汽车需求工程中的价值与整体学习路径
汽车电子系统的复杂度正在以指数级速度增长。从传统的分布式ECU架构到域集中式再到中央计算平台，从单纯的机械控制到软件定义汽车，需求工程面临的挑战早已超越了"写一份清晰的文档"这一层面。现代汽车产品开发中，需求不仅要覆盖功能逻辑，还要兼顾功能安全（ISO 26262）、网络安全（ISO/SAE 21434）、AUTOSAR架构约束、多供应商协同以及持续迭代的OTA升级需求。传统的基于自然语言的文档式需求规格书，在应对这种复杂度时暴露出歧义性高、追溯链断裂、变更影响分析困难等致命弱点。SysML（Systems Modeling Language，系统建模语言）作为OMG发布的系统建模标准，为汽车需求工程提供了一种基于图形化模型的表达、分析与验证手段。本课程将围绕"如何用SysML构建高质量、可追溯、可验证的汽车需求模型"这一核心命题，展开系统化的实战教学。
1.1 学习目标：从"会画图"到"会建模"
本课程的学习目标不是让学员机械地记住SysML中九种图元的画法，而是建立一套完整的"需求建模思维"。课程结束后，学员应当具备以下四项核心能力：
| 能力维度 | 具体表现 | 评估方式 |
|---|---|---|
| 建模表达能力 | 能够使用需求图、用例图、序列图、状态机图、活动图、模块定义图、内部块图、参数图等SysML视图，准确表达汽车电子系统需求 | 完成一个完整的ADAS需求建模案例 |
| 需求分析能力 | 能够从自然语言需求中提取关键信息，识别需求之间的逻辑关系、时序约束、状态转换和接口定义 | 给定一份真实的需求文档，输出对应的SysML模型 |
| 追溯管理能力 | 能够建立从干系人需求→系统需求→架构设计→详细设计→测试用例的完整追溯链，并执行变更影响分析 | 模拟一次需求变更，完成影响范围分析报告 |
| 工具实操能力 | 熟练使用主流SysML建模工具（如IBM Rhapsody、CATIA Magic、Papyrus等）完成模型创建、一致性检查和文档生成 | 工具实操考核 |
需要特别强调的是，SysML建模的核心价值在于"分析"而非"画图"。一个优秀的建模工程师，应当通过建模过程发现需求中的歧义、缺失和矛盾，而不是简单地将文字翻译成图形。例如，当我们在建模"自动紧急制动（AEB）系统"的需求时，如果仅仅画出一个用例图，标注"驾驶员激活AEB"和"系统执行制动"，这并没有增加任何信息量。真正的建模分析需要回答：AEB的激活条件是什么？在什么车速范围内生效？如何与ESP、VCU交互？误触发如何处理？功能降级策略是什么？这些问题的答案，需要通过状态机图、序列图、内部块图和参数图的组合来完整表达。
1.2 课程适用人群：谁需要这门课？
本课程面向汽车电子领域的技术人员和管理人员，具体包括以下四类人群：
- 系统工程师与需求工程师：负责整车级或系统级需求的定义、分析和分配。这类学员通常已经具备一定的需求工程经验，但缺乏图形化建模的方法论，导致需求文档冗长且难以维护。通过本课程，他们将学会用SysML需求图和用例图替代部分自然语言描述，提升需求的精确性和可读性。
- 软件与硬件架构师：需要将系统需求分解为软件需求和硬件需求，并定义软硬件接口。SysML的内部块图和参数图能够帮助他们清晰表达架构拓扑、接口协议和资源约束，避免因接口理解不一致导致的集成问题。
- 功能安全与网络安全工程师：ISO 26262和ISO/SAE 21434要求建立完整的需求追溯链，并进行危害分析与风险评估。SysML的追溯关系和约束建模能力，能够为功能安全活动提供结构化的模型支撑，减少安全案例编制的工作量。
- 项目经理与质量工程师：需要监控需求状态、跟踪变更、评估交付质量。通过SysML模型，他们可以直观地查看需求覆盖率、追溯完整性以及变更影响范围，从而更精准地管控项目风险。
对于学员的预备知识，建议具备基本的系统工程概念（如V模型开发流程）和一定的汽车电子背景知识。如果完全没有接触过SysML，也不必担心，本课程将从零开始讲解建模语言的核心语法和语义。但如果学员具备UML基础知识，学习进度会更快，因为SysML在图形语法上与UML有大量重叠。
1.3 SysML在汽车需求工程中的价值：为什么传统方法不够用了？
在传统汽车需求工程实践中，需求通常以Word文档或Excel表格的形式存在。这种方式在项目规模较小、系统复杂度较低时尚可应对，但随着智能网联汽车的发展，其局限性日益凸显。我们可以从以下四个维度对比传统方法与SysML建模方法的差异：
| 对比维度 | 传统文档式需求 | SysML建模方法 |
|---|---|---|
| 表达精确性 | 自然语言存在歧义，例如"在适当条件下触发制动"中的"适当条件"无法被计算机解析 | 通过状态机、活动图、参数约束精确表达触发条件、执行顺序和数值范围 |
| 可追溯性 | 需求编号靠人工维护，跨文档追溯极易断裂 | 通过SysML的«trace»、«refine»、«satisfy»等关系建立结构化追溯链，支持自动检查 |
| 一致性验证 | 需求之间的矛盾和冲突难以自动发现，依赖人工评审 | 通过模型的一致性检查规则，自动检测状态冲突、接口不匹配、约束违反等问题 |
| 变更管理 | 变更影响分析依赖个人经验，容易遗漏关联需求 | 通过追溯关系快速定位受影响的模型元素，生成影响分析报告 |
| 复用性 | 文档无法直接复用，新项目需要重新编写 | 模型可以模块化封装，通过模型库实现跨项目复用 |
以AEB系统为例，传统需求文档中可能包含这样一条描述："当车辆以10-80km/h的速度行驶，且与前车的相对距离小于安全距离时，系统应触发部分制动，减速度不超过3m/s²。"这条需求存在多个模糊点：安全距离如何计算？"部分制动"的具体含义是什么？如果传感器故障如何处理？在SysML中，我们可以通过参数图定义安全距离的计算公式，通过状态机图定义系统的不同工作状态（待机、激活、制动中、故障降级），通过活动图定义传感器数据采集、融合、决策、执行的具体流程。这样，每条需求都被转化为可验证的模型元素，测试工程师可以直接从模型中生成测试用例。
1.4 整体学习路径：从基础到实战的六阶段设计
本课程共30章，按照"基础认知→核心语法→专项建模→工具实操→综合实战→进阶提升"六个阶段组织，确保学员循序渐进地掌握SysML需求建模能力。
| 阶段 | 章节范围 | 核心内容 | 实战产出 |
|---|---|---|---|
| 第一阶段：基础认知 | 第1-3章 | SysML语言概述、需求工程基础、建模工具选型 | 搭建建模环境，创建第一个需求模型 |
| 第二阶段：核心语法 | 第4-10章 | 需求图、用例图、序列图、状态机图、活动图、模块定义图、内部块图、参数图 | 完成AEB系统需求建模（单项视图） |
| 第三阶段：专项建模 | 第11-16章 | 功能需求建模、接口需求建模、时序需求建模、安全需求建模（ISO 26262）、网络安全需求建模（ISO/SAE 21434） | 完成AEB系统完整需求模型（多视图集成） |
| 第四阶段：工具实操 | 第17-20章 | IBM Rhapsody实操、CATIA Magic实操、模型一致性检查、文档自动生成 | 使用工具完成模型校验和需求规格书生成 |
| 第五阶段：综合实战 | 第21-26章 | ADAS需求建模全流程、动力域需求建模、车身域需求建模、跨域协同建模 | 完成一个完整域控制器的需求建模项目 |
| 第六阶段：进阶提升 | 第27-30章 | 基于模型的测试用例生成、需求变更管理实战、SysML v2新特性、建模团队协作规范 | 完成需求变更演练和测试用例生成 |
在学习路径的设计上，我们遵循"每个阶段都有产出物"的原则。学员不是被动地听课，而是在每个阶段结束时都能交付一个可验证的模型成果。例如，在第二阶段结束时，学员应当能够独立完成AEB系统的用例图、序列图和状态机图；在第三阶段结束时，应当能够将多个视图整合为一个完整的系统需求模型，并通过工具的一致性检查。
1.5 案例拆解：从一条模糊需求到SysML模型的转化过程
为了帮助学员直观理解SysML建模的价值，我们用一个简化的案例来展示建模前后的对比。假设我们收到一条来自产品经理的原始需求：
"车辆在高速行驶时，如果驾驶员长时间不握方向盘，系统应发出警告，并最终使车辆安全停车。"
这条需求存在大量需要澄清的问题：
- "高速行驶"的具体车速范围是多少？
- "长时间"是多久？30秒？60秒？还是根据车速动态变化？
- "发出警告"是声音警告、视觉警告还是触觉警告？警告的强度是否分级？
- "最终使车辆安全停车"的降级策略是什么？是逐步减速还是立即停车？停车后如何保证安全？
- 系统在什么条件下允许驾驶员重新接管？
在SysML建模过程中，我们通过以下步骤逐步澄清这些模糊点：
- 创建用例图：定义"驾驶员监控"和"紧急停车"两个用例，明确系统边界和参与者（驾驶员、车辆、外部环境）。
- 创建状态机图：定义系统的状态（正常驾驶、警告状态、降级状态、停车状态），以及状态之间的转换条件。例如，从"正常驾驶"到"警告状态"的转换条件是"驾驶员双手脱离方向盘超过60秒且车速大于60km/h"。
- 创建序列图：描述系统与驾驶员、转向系统、制动系统之间的交互时序。例如，在警告状态下，系统先发出声音警告，同时通过方向盘震动提醒；如果驾驶员在10秒内未接管，系统进入降级状态，逐步降低车速。
- 创建参数图：定义关键参数的计算关系，例如"安全停车距离 = f(当前车速, 路面附着系数, 制动减速度)"。
- 创建模块定义图和内部块图：定义系统的物理组成（传感器、控制器、执行器）以及它们之间的接口关系。
通过上述建模过程，原本模糊的一句话被转化为一组精确的、可验证的模型元素。测试工程师可以直接从状态机图中提取测试用例，验证每个状态转换是否被正确实现；功能安全工程师可以从模型中识别出需要添加安全机制的关键路径。
1.6 总结与学习建议
本章作为课程的导入，为后续学习奠定了认知基础。核心要点可以归纳为以下四点：
- SysML不是UML的简单扩展，而是针对系统工程需求量身定制的建模语言，增加了需求图、参数图等专用视图，并强化了对连续系统、物理接口和约束的表达能力。
- 汽车需求建模的核心挑战在于多学科交叉（机械、电子、软件、网络）、功能安全与网络安全合规、以及供应链协同。SysML提供了一种统一的表达语言，让不同背景的工程师能够基于同一套模型进行沟通。
- 建模能力需要刻意练习。建议学员在课程学习期间，选择一个自己熟悉的汽车子系统（如车窗控制、雨刮控制、电池管理），从第4章开始同步进行建模练习，而不是等到课程结束再动手。
- 工具是手段，不是目的。本课程推荐使用主流商用工具（如IBM Rhapsody、CATIA Magic），但学员也可以使用开源工具（如Papyrus）完成练习。重要的是掌握建模方法论，而不是绑定特定工具。