1. 课程导入与SysML概览
汽车电子系统已经从“若干ECU通过CAN总线交换信号”演变为“多域控制器+区域控制器+车载以太网+OTA”的分布式计算平台。一辆中高端车型的软件代码量可达上亿行，涉及动力、底盘、车身、座舱、智驾、网联等多个域，且这些域之间存在大量跨域功能：例如自适应巡航需要同时读取动力扭矩、制动减速度、雷达/摄像头目标信息与驾驶员接管状态。传统以文档为中心、以信号为粒度的开发方式，在这种复杂度下会迅速暴露三个问题：需求散落在Word/Excel中难以追溯；接口定义与实现脱节，集成阶段才发现信号语义不一致；功能安全与信息安全分析无法与设计模型联动。SysML（Systems Modeling Language）正是为应对这类“系统级复杂度”而出现的建模语言，它把需求、结构、行为、参数与验证组织在同一套模型语义之下。
汽车电子系统建模面临的真实挑战
第一个挑战是跨学科语义不统一。机械工程师关心扭矩与惯量，电子工程师关心电压与采样率，软件工程师关心任务周期与优先级，功能安全工程师关心ASIL等级与失效模式。若没有统一的系统模型，各方只能通过文档“翻译”，信息在传递中衰减。第二个挑战是接口与信号爆炸。一个域控制器可能对外暴露数百个信号，每个信号都有方向、周期、精度、超时与默认值，仅靠DBC/ARXML难以表达“这个信号属于哪个功能、由哪条需求驱动、失效时如何降级”。第三个挑战是变体与配置管理。同一平台要覆盖不同车型、不同市场法规、不同选装包，模型必须能表达可选、替代与约束，而不是复制多份设计。第四个挑战是验证前移。物理样车昂贵且周期长，需要在模型阶段就通过参数仿真、状态机检查、需求覆盖分析提前暴露问题。
SysML在汽车开发中的价值定位
SysML由OMG在UML基础上扩展而来，包含九种图，但汽车电子开发中最常用的是五类：需求图用于建立需求与设计、测试之间的追溯；块定义图（BDD）用于定义系统层级、部件、接口与属性；内部块图（IBD）用于表达部件之间的连接、端口与数据流；状态机图用于描述模式切换、故障降级与上下电时序；活动图/序列图用于表达功能流程与交互顺序。参数图则用于把扭矩、电流、温度等工程参数与约束方程绑定，支持早期性能估算。
在汽车开发流程中，SysML通常与ASPICE、ISO 26262、ISO 21434协同使用：ASPICE要求需求—架构—测试双向追溯，SysML的需求图与分配关系可以直接支撑；ISO 26262要求安全机制可验证，SysML的状态机与序列图可以描述故障响应；ISO 21434要求威胁分析与风险评估，SysML的块与接口模型可以作为攻击面分析的输入。因此，SysML不是替代现有流程，而是为这些流程提供“单一模型源”。
课程目标与学习路径
本课程的目标不是让读者记住九种图的符号，而是能够用SysML完成一个汽车电子系统的“可追溯建模闭环”。具体包括四项能力：第一，能把一段自然语言需求转化为带ID、带验证准则的需求模型，并建立与设计元素的分配关系；第二，能用BDD/IBD定义系统层级、部件、端口与接口，并说明每个接口的信号方向、周期与失效默认值；第三，能用状态机与序列图描述模式管理、故障降级和上下电时序，并检查状态可达性与死锁；第四，能用参数图与测试用例把性能指标和验证结果关联起来，形成覆盖分析。
学习路径按“先结构、后行为、再验证”推进。前四章建立概念与工具链认知；第5至第10章聚焦需求建模与追溯；第11至第18章深入结构与接口建模，包括端口定义、流属性、变体管理；第19至第24章覆盖行为建模，重点讲状态机与序列图在模式管理、诊断与降级中的应用；第25至第28章讲参数图与性能预算；最后两章通过一个域控制器案例完成从需求到验证的端到端建模。每章都会给出可操作的建模片段、示例参数和判断依据，而不是停留在概念介绍。