为什么需要新的系统工程方式
复杂产品研发涉及大量专业、系统和参与角色。需求通过文档向下传递，设计结果又分散在不同软件和文件中。一旦需求、参数或方案发生变化，团队需要人工判断影响范围，并反复更新相关成果。
这种工作方式高度依赖个人经验。信息虽然存在，但关系不清晰；模型虽然存在，却难以跨专业协同；历史成果虽然丰富，也很难被后续项目直接调用。
从 MBSE 到 KMBSE
模型化系统工程强调通过模型描述系统需求、功能、逻辑和物理架构。KMBSE 在此基础上进一步将专业知识嵌入模型，让模型不仅能够表达设计结果，也能够参与分析、计算、检查、比较和决策支持。
- 将设计规范转化为可执行的检查规则
- 将专业算法封装为可以重复调用的计算能力
- 将设备选型经验转化为明确的条件与约束
- 将历史项目成果组织成可复用的业务对象
- 将设计、仿真和验证工具连接到统一流程
连接完整的设计链路
KMBSE 以场景和任务为起点，将需求、功能、逻辑、物理、接口、软件、仿真、试验和运维信息建立关联。知识模型作为共同底座贯穿整个设计链路，使不同专业围绕统一对象和关系协同工作。
- 01场景与任务
- 02需求模型
- 03功能与逻辑架构
- 04物理、接口与软件设计
- 05仿真、试验与验证
- 06制造运维与工程反馈
让变化沿模型传递
当上游需求或参数发生变化时，系统可以沿模型关系分析其对功能、架构、设备、接口、软件、仿真和验证工作的影响。工程师不再完全依靠人工检索文档和逐项核对，而是能够查看受影响对象、关联依据和待确认事项。
影响分析用于帮助专业人员更完整地理解变化范围，最终判断仍由具备相应职责的工程师完成。经过确认的变更可以继续沿模型更新，减少上下游信息不一致。
形成持续积累的工程闭环
项目实施过程中形成的模型、规则、算法、验证结果和问题处理经验，可以经过审核后回存知识模型。后续项目可以直接调用已经验证的对象和知识，并根据新的工程条件进行调整。
新的设计活动又会继续补充和完善知识体系，形成“项目应用—工程验证—知识沉淀—再次复用”的循环，推动研发从依赖文档传递和个人经验，转向以统一模型协同、以企业知识驱动。
