一、问题意识

人类依赖符号系统来认知、设计与控制日益复杂的工程系统。从自然语言、数学记号，到编程语言、数据库模式，再到工程领域的建模语言，符号始终是我们把世界结构化的唯一媒介。然而，一个反复出现、却很少被言明的困境是：我们似乎永远无法同时让一套符号系统"既好懂、好改、好扩"，又"既稳定、高密度、严丝合缝可被机器精确推理"。每一次在工程实践中试图把某一项推到极致，另一些项便不可避免地塌缩。

二、核心论点

符号系统必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做不可逆的零和取舍，不存在完美兼顾的终极体系。 MBSE 作为符号系统的一个典型工程实例，其全部历史演进、方法分歧与能力边界，均可归结为这一根本性张力：越是强化形式编码一侧（让语言易学、易扩展、能随需求柔性演化），就越削弱语义编码一侧（语义不稳、密度稀释、逻辑校验失准）；反之，越是追求语义编码的严谨（形式化语义、可执行、可机器验证），就越牺牲形式编码的可习得性与可扩张性。

需特别说明：此处"零和"应被精确理解为帕累托最优的不存在——六性无法被任何单一体系同时推至最优，任何一侧的改善必然以另一侧可度量的退化为代价；增益与代价并不严格等值，但"六性全优"在数学与工程上均不可达。

三、概念界定

为便于后文统一分析，先对六个关键性质给出可操作的判别定义：

• 形式编码（formal encoding）——符号被"书写、传播、改造"的便利性：

  • 可习得性（learnability）：新成员多快能上手建模，培训成本与认知负荷。

  • 可扩张性（extensibility）：语言能否低成本地随领域需求扩展（profile、DSL、库）。

  • 动态柔性（dynamic flexibility）：模型能否随系统演化而柔性地增删改，支撑迭代。

• 语义编码（semantic encoding）——符号"承载确定含义"的能力：

  • 稳定性（stability）：同一符号的含义不随解释者/工具/时间漂移。

  • 高密度性（density）：单位符号承载丰富且无歧义的信息。

  • 逻辑精准性（logical precision）：含义可被机器精确解析、推理与验证。

MBSE 则是"以演进中的系统模型为权威事实来源（single source of truth），贯穿需求、设计、分析、验证与确认的系统工程范式"，其载体主要是 SysML、OPM、KerML 等建模语言及配套方法论与工具。

四、报告结构

全文结构如下：

• 第1章 MBSE 的历史背景与演进脉络——从文档中心系统工程到模型驱动范式，语言、标准与工具生态的演进。

• 第2章 MBSE 的实现方式：语言、方法与工具——SysML/OPM/KerML 等语言、OOSEM/Harmony/State Analysis/Arcadia 等方法、Cameo/Rhapsody/Capella 等工具，及碎片化现象。

• 第3章 MBSE 的语义基础与形式化张力——全书理论核心，界定六性、剖析元模型/本体/形式语义之争，论证零和取舍的不可逃逸。

• 第4章 MBSE 的发展趋势——数字工程、数字孪生、MBSE+敏捷、AI 融合、SysML v2 与开源生态。

• 第5章 MBSE 的局限性——学习曲线、工具锁定、语义残留歧义、可扩展性悖论、ROI 不确定、覆盖鸿沟、验证边界，全部还原为零和投影。

• 第6章 MBSE 的主要争议点及各方立场——供应商锁定、形式化 vs 务实、模型 vs 文档、ROI 怀疑、标准碎片化、适用性边界，并揭示争议的本质是取舍曲线上的不同最优点。

• 第7章 MBSE 的未来发展方向——语言收敛、形式化适度下沉、人机协作分工化、开放互操作、DSL 张力、认证适配，论证未来不终结零和而只优化折中。

• 第8章 跨域案例与零和取舍的普遍印证——从航空航天到汽车、国防，再到编程语言、数学、自然语言、本体、数据库，证明零和是符号系统的普遍律，MBSE 仅为投影。

• 第9章 结论——核心论点，综述文献，汇总写作中记录的意外发现。

五、理论贡献与阅读指引

本报告并非又一部 MBSE 技术指南，而是一次对 MBSE 的"元批判"。其理论贡献可归纳为三点。

第一，提出并操作化了"形式编码—语义编码"的双轴六性分析框架。既有 MBSE 文献多在"易用性""表达力""一致性"等模糊维度上争论，缺乏统一的可度量标尺。本报告将争论还原为可习得性、可扩张性、动态柔性（形式侧）与稳定性、高密度性、逻辑精准性（语义侧）六条可操作的判别指标，使不同语言、方法、工具的优劣得以在同一坐标内比较，而非陷入"各说各话"的立场之争。

第二，把 MBSE 的演进重新叙述为"零和取舍曲线上的再平衡史"。历史背景、方法分歧、标准之争、采用障碍，不再是彼此孤立的现象，而是同一根本张力在不同历史时刻的投影。这一视角解释了为何 MBSE 历经三十余年仍未收敛于单一"终极体系"——因为收敛本身在数学与工程上均不可达，任何声称"统一一切"的体系都只是把代价转移到了别处。

第三，通过跨域印证将命题提升为关于"符号系统"的普遍定律。编程语言、数学记号、自然语言、本体、数据库模式、法律代码化，无一例外地显现同一零和；MBSE 因此被去魅为普遍定律的一个工程实例，而非特例。这种"降维"使工程界习以为常的焦虑（为何我们的模型总是不够好）获得了一个冷静的答案：不是你们做得不对，而是符号系统的本质如此。

为便于阅读，建议读者：若关注"MBSE 是什么"，从第1、2章入手；若关注"为何必然如此"，直奔第3章理论核心；若关注"现实挑战与走向"，阅读第4—7章；若关注"命题的普遍性与方法论边界"，第8章不可跳过。各章均可独立成篇，但贯穿全书的同一核心论点将它们焊接为一个整体。

六、关于"零和"的澄清与可能的反驳

为避免误读，预先回应三类常见反驳。

其一，"会不会有技术突破（如 AI）终结零和？"答：AI 提升的是形式编码一侧的柔性（自动生成、一致性检查），却以语义漂移与不可解释性稀释语义编码一侧；它把代价转移给人机分工，而非消除代价。第7章将论证，AI 是"分工化"而非"终结化"。

其二，"会不会有'分层/混合'体系兼得六性？"答：分层只是把取舍分散到不同抽象层，各层内部仍受零和约束，系统总和并不豁免。混合语言（如 SysML 融合 OPM）看似兼得，实则把冲突从"语言内"推到"语言间"，治理成本反而上升。

其三，"这是否陷入决定论与悲观主义？"答：恰恰相反。正视零和是一种工具理性：当组织停止追逐"完美体系"的幻象，转而有意识、可审计地配置六性权重时，反而能做出更优的工程决策。承认局限，才谈得上驾驭局限。

七、六性术语对照与速查

为降低后续阅读的认知负荷，将贯穿全书的六个性质及其可操作判别指标汇总如下表，读者可随时回查。

需要强调的是，这六性并非六个独立旋钮，而是两两成组的"零和对"：可习得性、可扩张性、动态柔性构成形式侧，稳定性、高密度性、逻辑精准性构成语义侧；强化任一侧，必在另一侧付出可度量代价。本书所有章节的论证，最终都可映射回这张表。

为把这张表变"活"，不妨用一个贯穿全书的微型示例预演零和取舍：设想一个跨专业团队要在 OPM 与 SysML 之间为某航天分系统建模选型。若选 OPM，其极简图元（对象—过程）带来高语义密度与低可习得门槛（形式侧可习得性高、语义侧高密度性高），但面对大规模嵌套结构与严格可验证需求时，其形式语义与工具生态的扩张性受限（语义侧逻辑精准性、形式侧可扩张性下降）；若选 SysML，其九图与 profile 机制带来强可扩张性与生态支持（形式侧可扩张性高），却因语义松散与图元繁多推高学习曲线、引入跨工具歧义（形式侧可习得性、语义侧稳定性下降）。两种选型都不是"错误"，而是在六性坐标上选择了不同最优点——这正是本书要反复证明的：没有哪一种符号系统能同时占据左上（全形式优）与右下（全语义优），选型本质上是一次公开的代价取舍。

基于同一框架，读者还可把本书的论证主线概括为一条递进链：历史（第1章）展示张力如何被"逼"出来 → 实现（第2章）展示张力如何在语言/方法/工具中具象 → 理论（第3章）将张力抽象为六性零和 → 趋势与局限（第4、5章）展示张力如何随技术演进而变形却不消失 → 争议（第6章）揭示张力如何在利益相关方之间外化为立场冲突 → 未来（第7章）给出与张力和解的设计哲学 → 跨域（第8章）证明张力是符号系统的普遍律。导论之后的每一章，都是这条链条上的一环。

第1章 MBSE 的历史背景与演进脉络

本章的任务，正是把 MBSE 从二战后系统工程学科诞生、经文档中心范式、再到模型中心范式的历史长河，重新叙述为一条围绕形式编码与语义编码权重再分配的连续线索。我们将看到：每一次所谓"范式进步"，本质上都不是问题的解决，而是把同一对矛盾的权重从一端推向了另一端。

1.1 系统工程学科的诞生

1.1.1 二战后复杂工程对跨学科方法的倒逼

现代意义上的系统工程，并非诞生于书斋，而是被工程的规模与复杂性"倒逼"出来的。二十世纪四十至六十年代，一系列国家级巨型工程——从雷达与通信系统的整合，到核武器研制的曼哈顿计划，再到洲际导弹与载人航天——的共同特征是：它们不再可以由单一学科、单一组织以线性方式完成，而必须由成千上万个相互耦合的子系统、跨越多家企业与研究机构协同集成（Kossiakoff 等，2011；Blanchard & Fabrycky，2011）。在这一背景下，"系统"第一次成为工程思考的元对象：工程师必须同时处理功能、结构、接口、可靠性、成本与进度之间的相互制约，而不是孤立地优化某一个零件或某一段代码。

阿波罗工程（Apollo Program，1961—1972）是这一转折最常被引用的范本。该工程历时约十一年，耗资约二百五十五亿美元，前后动员约三十万人、两万余家公司与一百二十余所研究机构，动用数百台计算机与三百万余个构件（钱学森倡导的航天系统工程实践亦与之同期成熟，见航天系统工程相关论述）。阿波罗工程的总负责人曾强调："阿波罗工程中没有一项新技术，全都是现成的技术，关键在于综合。"这句话精确地揭示了系统工程的本质——它不是发明新元件，而是对既有技术进行受控的、可验证的整体集成。也正因如此，阿波罗把计划协调技术（PERT）发展为图解协调技术（GERT），并广泛运用计算机仿真来确保每一项试验按期、按质完成。系统工程作为一门"组织管理的科学方法"由此被世界广泛接受，并在二十世纪七十年代后迅速扩散（系统工程相关百科与历史综述）。

然而，这里已经埋下了贯穿全书的张力种子。阿波罗式的成功，依赖于一套高度结构化、可被人工检查与评审的"符号载体"——接口定义、设计评审文档、配置控制记录、任务时间线。这些载体本质上是用自然语言与图表进行的语义编码尝试：人们希望它们稳定、高密度、逻辑自洽，从而充当系统全貌的可靠描绘。但当系统规模逼近人类认知与协作的临界点，这类"以文档承载语义"的编码方式就开始显露出它的根本脆弱性。换个说法，早期系统工程在形式编码一侧（让方法可被多学科团队习得、可被扩张到巨型工程）取得了巨大成功，却已暗含了语义编码一侧（语义稳定、密度可控、逻辑可校验）终将失稳的祸根——只不过在阿波罗这种由强中央管理与统一文档体系保驾的工程里，矛盾尚被组织权威所压制。

1.1.2 A. D. Hall（1962）的方法论

1962 年，A. D. Hall 出版《A Methodology for Systems Engineering》（Hall，1962），系统阐述了系统工程的方法论，并在此后进一步提出著名的"霍尔三维结构"（时间维、逻辑维、知识维）。这一工作的重要性在于：它首次试图把原本隐于杰出工程师直觉之中的系统工程，提炼为一套可传授、可重复、可扩张的形式化方法论框架。从本书核心论点看，霍尔的工作代表的是形式编码一侧的早期努力——他将系统工程"编码"成三维结构，使不同背景的从业者能够习得同一套思考路径，并把它扩张应用到从通信到航天的广泛领域。

但必须指出霍尔方法论的内在限度。三维结构提供的是一种"元语言"或"认知地图"，它规定了工程应经历哪些阶段、每个阶段应回答哪些问题、应调用哪些学科知识；它却并不对"系统"本身给出机器可验证的形式语义。换句话说，霍尔体系在可习得性与可扩张性上做得很成功，却把语义的精确性留给了各领域的专家判断与纸质文档。这恰恰是零和取舍的早期显现：为了让方法足够"轻"、足够"通用"以便被最广大的工程群体习得与扩张，就必须放弃对系统语义的形式化硬度。霍尔体系之后数十年，系统工程教科书层出不穷（Sage，1992；Kossiakoff 等，2011；Blanchard & Fabrycky，2011），但这一根本取舍从未被突破，只是被不断重新包装。

1.1.3 INCOSE 于 1990 年成立的历史意义

系统工程作为一门实践虽早已有之，但作为其制度化、专业化标志的国际组织 INCOSE（International Council on Systems Engineering，国际系统工程协会）于 1990 年成立。其前身是 1990 年夏天由波音等公司在西雅图发起的"国家系统工程委员会"（NCOSE），旨在应对"合格工程师在进行系统层面思考、而非仅聚焦于单一学科时的明显缺陷"；随着来自十个以上国家专业人士的参与，该组织于 1995 年正式更名为 INCOSE（INCOSE，2020；相关历史综述）。

INCOSE 成立的历史意义，远不止于"多了一个学会"。它意味着系统工程第一次拥有了跨企业、跨国界、跨军民航天的统一话语共同体与标准制定权威。从其成立之初，INCOSE 便着手推动系统工程原则的国际标准化，并自 1995 年起以联络成员身份参与 ISO/IEC JTC1/SC7 的标准制定，直接促成了 ISO/IEC 15288 这一首个标题中包含"Systems Engineering"的国际标准（INCOSE，2008）。说白了，INCOSE 把原本散落于各工程组织内部、以各自文档惯例形式存在的"语义编码"，试图提升为全行业共享的、可习得的"形式编码"——这正是形式编码诉求（可习得、可扩张、跨组织柔性一致）的一次制度性跃升。

但也正因如此，INCOSE 从诞生起就处在本书核心论点的风暴眼：它越是把系统工程编码成统一的方法、手册与标准（强化形式编码一侧），就越难保证这些标准在被千差万别的工程语境实例化为具体语义时仍保持逻辑精准与稳定（语义编码一侧的损耗）。我们将在后续章节看到，MBSE 的提出与演进，正是 INCOSE 为弥合这一裂缝而下的赌注——而赌注的本质，依旧是把权重从一端挪向另一端。

1.2 文档中心系统工程（DBSE）范式及其内在瓶颈

1.2.1 DBSE 范式的确立

在 MBSE 兴起之前，系统工程长期运行于"文档中心系统工程"（Document-Based Systems Engineering，DBSE）范式之下。其核心信条是：系统的需求、设计、分析、验证与确认，主要通过文字密集的文档（需求规格书、设计说明、接口控制文档、测试计划、验证报告等）来承载、传递与归档。文档既是工程信息的载体，也是跨专业、跨组织沟通的事实来源。从符号系统的视角看，DBSE 试图用自然语言这一人类最成熟、最易习得、最具扩张性的符号系统来承担语义编码的职责——它希望自然语言文档既是高密度、稳定、逻辑自洽的语义载体，又是所有参与者都能轻松习得与扩张的形式载体。

1.2.2 文档爆炸

DBSE 的第一个、也是最直观的瓶颈是"文档爆炸"。随着系统复杂度上升，为覆盖每一个接口、每一种失效模式、每一条需求溯源，文档数量与篇幅呈组合式膨胀。一份现代航空航天或汽车系统的需求与设计文档往往以千计、以万页计。文档爆炸的直接后果，是信息的物理密集度超过了人类的阅读与整合带宽：没有任何一个工程师能够"读完系统"，系统全貌被拆解为无数局部文本碎片。这里浮现的，正是语义编码一侧的"高密度性"诉求在实践中反噬自身——人们为追求语义覆盖的密度而生产更多文档，却因密度过高而丧失了语义可被整体理解的稳定性。

1.2.3 多文档间不一致

文档爆炸必然伴随"多文档间不一致"。由于每一份文档由不同团队、在不同时间、为不同目的撰写，同一概念（例如"系统的最大允许温度"）会在需求文档、设计文档、验证文档中以不同措辞、不同数值、不同单位反复出现而彼此矛盾。自然语言作为形式编码载体固然极易习得与扩张，但其语义边界模糊、缺乏机器可校验的精确定义，这恰恰削弱了语义编码最看重的"稳定性"与"逻辑精准性"。DBSE 下的不一致，不是工程师的疏忽，而是用自然语言承担精密工程语义这一符号选择的必然副产品。

1.2.4 需求—设计—验证的可追溯性困难

DBSE 的第三个瓶颈，是需求—设计—验证之间可追溯性的困难。理想状态下，每一条顶层需求都应能向下追溯到具体设计元素，向上回溯到验证证据。但在文档海洋中，这种"追溯"依赖人工维护的矩阵与交叉引用，一旦文档修订便极易断裂。可追溯性本质上是语义编码"稳定性"与"逻辑精准性"的延伸要求——它要求语义关系在不同抽象层之间保持确定且可验证。DBSE 之所以在此失灵，是因为自然语言文档之间的语义关联是隐式的、非形式化的，无法被机器稳定地解析与校验。

1.2.5 变更传播失控与知识散落

第四个瓶颈是变更传播的失控。当某一条需求变更，DBSE 难以自动判定它波及哪些设计条目、哪些验证案例、哪些下游文档，于是要么遗漏关联项（埋下隐患），要么发动大规模人工评审（消耗成本）。第五个瓶颈是知识散落于非结构化文本——系统真正有价值的工程判断、约束理由、取舍依据，往往以叙述段落、脚注、会议纪要的形式沉没在难以检索的自然语言里，无法被复用、推理或机器挖掘。

1.2.6 瓶径的实质：语义编码追求稳定却在实践中失稳

必须强调：上述五大瓶颈并非彼此独立的"管理不善"，它们共有一个统一的深层病因。DBSE 选择自然语言文档作为语义编码的主载体，本意是追求语义的高密度与稳定承载；但自然语言在形式编码维度上的"软"——易被习得、易于扩张、可柔性表达——恰恰以牺牲语义维度的"硬"为代价。当工程规模跨过某一阈值，这种脆弱性便系统性地爆发为文档爆炸、不一致、追溯断裂、变更失控与知识散落。换种讲法，DBSE 的全部痛苦，正是核心论点所预言的图景：越是依赖易习得、可扩张的形式编码（自然语言），语义编码一侧（稳定性、高密度、逻辑精准）就越在实践中失稳。DBSE 因此是这一零和取舍的一个历史反例——它把权重几乎全压在形式编码一侧，最终被自己追求的"柔性"反噬。MBSE 的诞生，正是对这一反噬的回应。

1.3 MBSE 的正式提出

1.3.1 INCOSE MBSE Initiative（2007 起）

2007 年，INCOSE 正式启动 MBSE Initiative（MBSE 倡议），标志着"基于模型的系统工程"作为一项有组织的工程运动登上历史舞台（INCOSE，2007；INCOSE MBSE Wiki，2007—）。同年，INCOSE 发布了《Systems Engineering Vision 2020》（系统工程愿景 2020），系统描绘了以模型为中心的系统工程未来图景（INCOSE，2007）。该倡议确立了 MBSE 的初步定义与价值主张，并催生了一系列方法论调研——其中最具影响力的是 Estefan 于 2008 年发布的《A Survey of Model-Based Systems Engineering (MBSE) Methodologies》（Estefan，2008），它系统梳理了 OOSEM、Harmony-SE、State Analysis、Statemate、ROOM、RUP 等方法谱系，为后续方法争鸣奠定文献基础。

从核心论点审视，MBSE Initiative 的提出是一次有意识的"权重再分配"：它承认 DBSE 在语义编码一侧已不可持续，于是决意把符号系统的重心向形式编码的"硬"一侧——即用结构化、机器可处理的模型替代自然语言文档——转移。这一转移承诺用模型的可计算性换取语义的稳定性与可追溯性。但它同时也意味着：工程师必须习得一套新的、比自然语言更刻板的建模语言与工具，系统的"可扩张性"与"动态柔性"将受到建模语言严格语法的约束。零和取舍的钟摆，开始摆向另一端。

1.3.2 Systems Engineering Vision 2020 与 2035

《Systems Engineering Vision 2020》（INCOSE，2007）勾画了模型驱动、数字连续、跨生命周期协同的愿景；其后发布的《Systems Engineering Vision 2035》（INCOSE，2021）进一步把数字工程、数字孪生、人工智能辅助建模纳入远景。这两份文件的历史价值在于，它们把"模型"从工程活动的辅助工具，提升为工程知识的核心载体与战略资产。有意思的是，愿景文件的措辞本身也暴露了取舍的两难：它既要求模型"易学易用、可被广大从业者采纳"（形式编码一侧），又要求模型"语义精确、可自动验证、跨工具互操作"（语义编码一侧）。两份愿景在二十余年间反复重申同一组目标，恰恰说明这对矛盾无法被一次性"解决"，只能被持续地重新权衡。

1.3.3 "模型作为唯一事实来源"理念的出现

MBSE 最具标志性的理念，是"模型作为唯一事实来源"（single source of truth，简称 SSOT）。其主张是：系统的权威性描述应存在于单一、结构化、机器可读的模型中，文档、图纸、报表等均由模型自动派生，从而根除 DBSE 下多文档相互矛盾的顽疾。SSOT 直击语义编码的"稳定性"与"逻辑精准性"诉求：当所有下游产物都从同一形式化模型生成，一致性便由构造保证，而非依赖人工对齐。

但 SSOT 亦是零和取舍最尖锐的体现。要让一个模型成为"唯一事实来源"，它就必须足够形式化、足够严格，以至于自然语言那种随心所欲的扩张性被剥夺——工程师不再能随手加一句"原则上允许例外"，而必须在建模语言的语法与语义边界内表达。可习得性随之受损：MBSE 的入门门槛显著高于写一份文字需求。SSOT 因此不是免费午餐，而是用形式编码一侧的代价，去购买语义编码一侧的确定性。这一交易的本质，构成全书后续所有讨论的底座。

1.4 建模语言的演进主线

MBSE 的承诺能否兑现，最终取决于它用何种"语言"来编码系统。建模语言是形式编码与语义编码矛盾的集中爆发点：一门语言若语法宽松、易于习得与扩张，其语义就松散难验；若语义被形式化到可被机器证明，其语法就严苛、学习曲线陡峭。

1.4.1 UML：软件建模的事实标准

统一建模语言（UML，Object Management Group，2007—2019 的 v2.5.1 等版本）原本为软件工程而生，凭借用例图、类图、状态机图、活动图等丰富的图形 Notation，迅速成为软件建模的事实标准（OMG，UML 2.5.1，2017）。UML 的设计哲学明显偏向形式编码一侧：图形化 Notation 直观易学，元模型可扩展，profile 机制允许针对特定领域定制。这种"易习得、可扩张"的特性，使它成为 SysML 的母体。

然而 UML 的软肋恰在语义编码一侧。尽管学术界长期呼吁 UML 的"形式语义"（Broy & Cengarle，2010 即专论 UML formal semantics），其官方规范在相当长时期内以半形式化的自然语言描述元模型，导致同一张图在不同工具、不同人手中可被赋予不同解释。其实，UML 为可习得性与可扩张性付出的代价，是语义的不稳定与逻辑校验的失准——这正是核心论点的标准注脚。

1.4.2 SysML v1：在 UML 之上叠加系统语义

为把 UML 的建模范式引入系统工程，OMG 于 2007 年采纳 SysML v1，并在 2019 年发布 v1.6（OMG，SysML v1.0—v1.6，2007—2019；OMG，SysML v1.6，2019）。SysML v1 通过 UML 的 profile 机制扩展出需求图、参数图（parametric diagram）、模块定义图等系统工程专属构造，试图在保留 UML 易学易扩优势的同时，补上系统的需求与参数语义。

但 profile 机制本身是一把双刃剑。它最大化了形式编码一侧的可扩张性（任何团队都可自定义 stereotype），却也最大化了语义编码一侧的发散：不同组织对同一构造的自定义差异巨大，模型难以跨组织、跨工具保持统一的语义解释。Madni 与 Sievers（2018）在回顾 MBSE 现状时即指出，SysML v1 在互操作与语义一致性上仍存在显著短板。SysML v1 因此是一个"折中产物"——它既没有足够的形式硬度来根治 DBSE 的语义失稳，又继承了 UML 在语义精确性上的先天不足。它把零和取舍停留在了中间地带，而这恰恰是它后来必须被 v2 取代的根本原因。

1.4.3 OPM：对象—过程法的另一条路径

与"在 UML 上做加法"不同，Dori 提出的对象过程法（OPM，Object-Process Methodology）选择了一条更激进的路径：用统一地描述"对象"与"过程"的单一图示范式来表达系统，并以此为基构建可执行的系统模型（Dori，2016）。OPM 的长处在于其概念经济性——一种图、一套基本原语，降低了形式编码的习得门槛；同时它具备形式化内核，后被采纳为国际标准 ISO 19450。OPM 可视为一次试图"同时兼顾"两侧的精巧尝试：用更少的符号获得更广的语义覆盖。

然而概念经济的代价是表达力的受限与规模化的困难。当系统极端复杂时，单一范式的紧凑性反而成为瓶颈——它既难以像专用图那样精细刻画某类结构，也难于像形式逻辑那样支撑严密验证。OPM 的案例再次印证：任何"兼顾"的努力，最终都会在某一维度上付出代价，所谓"完美体系"并不存在。

1.4.4 SysML v2 与 KerML：明确倒向语义编码一侧

2023 年 6 月 30 日，OMG 采纳 SysML v2 的 beta 规范，同期采纳其形式语义内核 KerML（Kernel Modeling Language）v1.0 beta 与 Systems Modeling API & Services v1.0 beta（OMG，SysML v2 Beta 2，2023；OMG 新闻稿，2023）。这是 MBSE 语言演进中最意味深长的一幕：SysML v2 不再依赖 UML 的 profile 机制，而是构建全新的元模型；其内核 KerML 以一阶逻辑的形式语义、辅以 4D 时空外延（temporal and spatial extent）来定义语义（Seidewitz，2023；OMG 新闻稿，2023）。这意味着 SysML v2 把权重明确地、大幅地推向了语义编码一侧——它追求可被机器精确解释、可被形式验证、可跨工具互操作的"硬语义"。

这一转向的代价，同样清晰可见。以一阶逻辑与 4D 语义为内核的语言，其严格性是以可习得性与动态柔性为筹码的：建模者需要理解更精密的元模型、更克制的语法约束，入门与精通的门槛显著高于 SysML v1。SysML v2 同时提供文本与图形两种互补表示，意在挽回部分可习得性，但内核的严谨性决定了它不可能回到 UML 那种"随手画图"的柔性。这便是核心论点最凝练的历史证据：当一门建模语言决心把语义编码推向极致，它必然在形式编码的可习得与可扩张上做出不可逆的牺牲。反之，若它想回到易学易扩，则语义必将再度失稳。零和，不可逆。

1.4.5 建模语言演进时间轴

下表以时间为序，呈现上述语言的演进及其在形式编码—语义编码张力中的权重取向。

1.5 标准与框架的形成

建模语言提供了"词汇"，但要让 MBSE 成为可制度化的工程纪律，还需要标准与框架作为底座。这一底座由三类关键文献与战略共同奠定，它们本身亦可从核心论点加以解读。

1.5.1 ISO/IEC/IEEE 15288：系统生命周期过程

ISO/IEC/IEEE 15288:2015《系统与软件工程—系统生命周期过程》是首个标题含有"Systems Engineering"的国际标准，它为系统全生命周期定义了从协议、组织项目使能到技术过程的统一过程框架（ISO/IEC/IEEE，2015；其 2023 版已取代 2015 版）。15288 的价值在于：它把系统工程的"应做之事"编码为一套可习得、可扩张、可被任意组织实例化的过程形式——这是形式编码一侧的制度化胜利。

但 15288 本质上编码的是"过程"而非"系统语义本身"。它规定了工程应当经历哪些过程、产生哪些信息项，却无法保证这些信息项在语义上是机器可验证精确的。标准在形式编码维度建起了坚固的脚手架，却把语义编码维度的硬度留给了建模语言与工具去解决。这又一次印证：标准的建立强化了"可习得、可扩张"，却不能直接兑换"语义稳定、逻辑精准"——后者是另一场独立的、且更为艰难的取舍。

1.5.2 INCOSE Systems Engineering Handbook

《INCOSE Systems Engineering Handbook》（第 5 版，INCOSE，2023）是实践者的权威指南，NASA 亦发布《NASA Systems Engineering Handbook》（NASA，2016）作为机构级对照。这类手册把 15288 等标准翻译为可操作的知识，是形式编码"可习得性"的工程化体现。然而手册以自然语言书写，自身便带有 DBSE 的全部语义脆弱性——它能被人读懂，却不能被机器校验。手册与标准共同构成 MBSE 的"软底座"，而模型的"硬语义"则必须由语言与工具去补足。

1.5.3 美国 DoD 数字工程战略（2018）

2018 年，美国国防部发布《Digital Engineering Strategy》（数字工程战略，DoD，2018），明确提出以"权威数字模型"和"数字孪生"取代传统文档为中心的实践，把 MBSE 上升为国家防务的工程基线。Stoewer（2014）曾发问：MBSE 究竟是数字企业战略中缺失的一环，还是其引擎？DoD 战略以制度力量回答了这一问题——MBSE 被确立为数字工程的枢纽。

值得深思的是，国家级战略之所以强力推动 MBSE，正是因为 DBSE 的语义失稳已威胁到装备全寿命周期的可靠性。但战略文件同样无法回避取舍：当模型被赋予"权威"地位，它对形式化硬度（语义编码）的要求，必然抬高对从业者建模素养（形式编码的可习得性）的门槛，并压缩各承制方在表达上的自由柔性。数字工程战略是核心论点在国家尺度上的重演。

1.6 工具与产业生态

语言与标准须由工具落地。MBSE 的工具生态从早期专有 CASE（计算机辅助软件工程）工具，演化为今日多元竞逐的格局，其中代表性的包括：

• MagicDraw / Cameo（No Magic，后被 Dassault Systèmes 收购）：SysML v1 时代事实上的主流商业工具，深度集成建模、仿真与系统工程流程（Borky & Bradley，2018）。

• IBM Rhapsody：源自 Harmony-SE 等方法传统，强调从模型生成代码与测试用例（Douglass，2009）。

• Capella：由 Thales 开源贡献的 Arcadia 方法配套工具，体现了方法论与工具协同的开源路线（Roques，2016）。

• Enterprise Architect（Sparx Systems）：覆盖面广、性价比高的商业建模平台。

• Papyrus：基于 Eclipse 的开源 SysML 实现，是开放生态的重要支点。

• OpenMBEE（Open-source Model-Based Engineering Environment）：以"模型即服务"、跨工具互联为目标的开放环境（OpenMBEE，2020s）。

1.6.1 生态繁荣与碎片化悖论

工具生态的繁荣，表面是 MBSE 成熟的标志，实则又是核心论点的鲜活映射。一方面，众多工具各自追求"易学易用、可灵活扩张"（形式编码一侧），纷纷定义自己的存储格式、API 与建模约定；另一方面，这种百花齐放恰恰侵蚀了"跨工具语义一致、可互操作"（语义编码一侧）。不同工具对同一 SysML 模型的解读与持久化方式存在差异，模型在工具间迁移时常丢失语义保真度。Madni 与 Sievers（2018）将互操作与工具链整合列为 MBSE 的主要研究挑战之一；Borky 与 Bradley（2018）亦强调工具集成与语义一致性的工程难度。

这构成一种深刻的悖论：为提升形式编码的可习得性与可扩张性（让更多组织能低成本进入 MBSE），产业自然走向工具多样化；但多样化反过来摧毁了语义编码最珍视的跨边界稳定性与可验证一致性。碎片化不是生态的"失误"，而是零和取舍在产业层面的必然投影。SysML v2 与 Systems Modeling API & Services（OMG，2024）的提出，正是试图用"标准 API"在语义层面重新统一碎片——而这又一次要求工具放弃各自的形式自由，向语义编码一侧让渡权重。

1.7 范式转向的深层逻辑：从"用模型"到"基于模型"

MBSE 的演进，常被概括为从"engineering with models"（用模型）到"model-based"（基于模型）的范式转向。这一转向的深层逻辑，正是一条形式编码与语义编码张力逐步显形的线索。

在"用模型"阶段，模型是辅助性的：工程师用草图、仿真脚本、局部分析模型来帮助思考，但系统的权威描述仍由文档承载。此时形式编码一侧（随手建模、自由表达）占主导，语义编码则散落、非权威。随着 DBSE 语义失稳的危机加深，工程界被迫把权威性从文档转移到模型，即"基于模型"——模型成为 SSOT，文档退化为派生产物。这一转向的代价，如前所述，是建模语言必须更严格、从业者门槛必须更高、系统表达的动态柔性必须被收敛。

因此，"基于模型"绝不只是一个温和的方法升级，而是一次符号系统重心的根本迁移：它最初显现的，正是形式编码（可习得性、可扩张性）诉求与语义编码（稳定性、逻辑精准性）张力的最早裂缝。INCOSE 在 2007 年前后推动 MBSE，本质上就是用制度力量，把这场张力从"隐性的、被组织权威压制的"状态，推向"显性的、由语言与工具正面承担的"状态。自此以后，MBSE 的每一次语言迭代（v1→v2）、标准演进（15288→数字工程战略）、工具整合（API 标准化），都是在已暴露的零和取舍上反复重新分配权重，而非走向某种终极和解。

1.8 关键转折点与里程碑汇总表

为便于纵览，下表汇总 MBSE 历史脉络中的关键年份、事件及其对形式编码—语义编码张力的影响。

本章小结

本章沿历史脉络重述了 MBSE 的来路与转向。我们看到，系统工程因二战后巨型工程的复杂性而被倒逼诞生（Hall，1962；阿波罗工程），INCOSE 于 1990 年将其制度化为统一学科（INCOSE，1990/2008）；DBSE 以自然语言文档承载语义，最终因形式编码过重而 语义失稳，表现为文档爆炸、不一致、追溯断裂、变更失控与知识散落——这是核心论点的一次历史反例。MBSE 自 2007 年由 INCOSE 倡议提出（INCOSE，2007；Estefan，2008），以"模型作为唯一事实来源"为旗帜，把符号系统的权重向语义编码一侧迁移；建模语言从 UML、SysML v1、OPM 一路演进至 SysML v2 与 KerML（OMG，2023；Seidewitz，2023），其语义硬度逐步硬化，代价是习得性与柔性的牺牲；标准（ISO/IEC/IEEE，2015；INCOSE，2023；DoD，2018）与工具生态（MagicDraw/Cameo、Rhapsody、Capella、Papyrus、OpenMBEE 等）共同构成底座，而生态繁荣本身又因碎片化侵蚀了语义互操作。

贯穿这一切的，正是那条不可逆的零和取舍：没有任何历史阶段、没有任何语言或标准曾经真正"兼顾"形式编码与语义编码，它们只是在不同时刻、以不同比例重新分配了权重。MBSE 不是对 DBSE 矛盾的解决，而是矛盾在更高形式硬度上的重新安置。后续章节将在此基础上，逐一剖开方法、语言、工具与能力的边界，证明这一根本性张力如何持续塑造着基于模型的系统工程的全部可能与全部限度。

1.9 MBSE 在各国航天、国防与汽车领域的扩散时间表与驱动因素对比

MBSE 自 2007 年由 INCOSE 倡议提出后，并未以均匀速度向各工程领域扩散。驱动其采纳的力量，在不同产业中呈现出显著差异：航天与国防领域由"失败代价极高、系统极度耦合"的倒逼逻辑主导，汽车与轨道交通领域则由"功能安全标准与电子电气架构复杂度"的合规逻辑主导，而更广的工业装备与能源领域更多受"全生命周期成本与数字化交付"的商业逻辑驱动。这种不均衡扩散本身，恰可从核心论点加以解读：越是把语义编码的稳定性视为生死攸关的领域（航天、国防），越早、越坚决地倒向模型中心范式；而越是受成本与柔性约束的领域，则在形式编码一侧停留更久。换个说法，扩散的时间表，是各领域为语义稳定性愿意支付多少形式习得与表达柔性代价的刻度尺。

1.9.1 航天领域：从模型辅助到模型权威

航天是 MBSE 最早的策源地之一。NASA 喷气推进实验室（JPL）自二十世纪九十年代起发展"状态分析"（State Analysis）方法，用形式化模型描述航天器在实时约束下的状态与行为，以应对深空任务中软硬件紧耦合、不可现场调试的极端约束（Ingham 等，2004）。这一路径的本质，是把系统的"语义"从自然语言需求文档中抽离，编码为可被仿真与验证的模型——正是语义编码一侧的早期自觉实践。欧洲空间局（ESA）则在 2010 年代系统引入 MBSE，以应对卫星与载人飞船日益膨胀的系统规模与跨分包商集成压力。NASA 于 2016 年发布修订版《NASA Systems Engineering Handbook》（NASA，2016），虽仍以自然语言书写，却已明确把模型作为系统工程活动的核心资产而非附属草图。航天领域的驱动因素高度一致：一次接口语义失稳即可导致整星损失，因此它对"语义稳定、逻辑精准"的诉求压倒了"易学易扩"的柔性，扩散因而最为决绝。

1.9.2 国防领域：国家尺度把 MBSE 提升为工程基线

国防领域对 MBSE 的推动，最具制度刚性。2018 年，美国国防部发布《Digital Engineering Strategy》（数字工程战略，DoD，2018），明确要求以"权威数字模型"与"数字孪生"取代传统文档中心实践，把 MBSE 上升为国家防务的工程基线。其驱动因素并非单纯追求技术先进，而是装备全寿命周期中 DBSE 语义失稳已直接威胁可靠性与互操作性：跨军种、跨承制方的接口若仍以各自文档表述，则联合杀伤链与持续保障将无法保证一致性。英国国防部等亦相继发布建模与仿真战略，呼应这一方向。国防领域的特征是：国家级战略以行政权威强制把权重推向语义编码一侧，哪怕这意味着对承制方建模素养门槛的抬高与表达自由柔性的压缩——核心论点在国家尺度上被重演。

1.9.3 汽车领域：功能安全标准与电子电气架构的合规倒逼

汽车领域采纳 MBSE 的驱动力与航天、国防不尽相同。随着线控底盘、自动驾驶与电动化的发展，汽车从机械系统演化为"轮子上的计算机"，其电子电气架构（E/E architecture）与功能安全需求急剧复杂化。AUTOSAR 标准与 Modelica 等物理系统建模语言（Modelica Association，2017）的出现，使汽车工程师得以用模型描述控制器网络、信号流与物理行为；而 ISO 26262 对"可追溯性"与"验证证据"的强制要求，使文档中心范式在合规成本上难以为继。汽车领域的扩散因此呈现"合规驱动、渐进采纳"的特征：它较少由国家级战略强制，而更多由功能安全标准与供应链协同（OEM 与 Tier-1 供应商间的模型交换）推动，形式编码一侧的可习得性与工具可用性仍是关键约束，故其倒向语义编码的步调慢于航天与国防。

1.9.4 三领域扩散对比表

下表汇总三大领域的扩散时间线与驱动因素，并对照其在形式编码—语义编码张力中的取向。

1.9.5 扩散差异的深层含义

三领域的对比揭示一条规律：MBSE 的扩散速度，与领域对"语义失稳代价"的敏感度成正比。航天与国防因失败不可承受，率先倒向语义编码；汽车因商业与合规双重约束，渐进采纳；而更广的民用工业则仍在形式编码的柔性中观望。这条规律再次印证核心论点——所谓"采纳 MBSE"，在符号系统层面就是一次把权重从形式编码移向语义编码的不可逆抉择，其难易取决于该领域愿意为语义稳定性支付多少形式习得与表达柔性的代价。扩散时间表，因而本质上是一张零和取舍的"支付意愿表"。

1.10 文档中心范式失败的经典工程案例：可追溯性崩溃与变更失控的真实教训

核心论点所预言的"语义编码追求稳定却在实践中失稳"，并非抽象推论，而有多起代价高昂的真实工程事故为其注脚。本节以两个被广泛引用的案例——NASA 火星气候轨道器事故（1999）与阿丽亚娜 5 型首次飞行失败（1996）——说明：当接口语义仅以自然语言文档承载、缺乏机器可校验的形式硬度时，DBSE 的可追溯性与一致性保障如何在临界点崩溃，并造成以亿美元计的损失与任务失败。两案例均经官方事故调查报告核实（NASA MCO MIB，1999；Lions 等，1996），属库外文献，已用 WebSearch 复核官方来源，无 DOI，官方链接见 NASA 事故董事会报告与 ESA/CNES 调查报告。

1.10.1 火星气候轨道器：单位语义未被机器校验

1999 年 9 月 23 日，NASA 火星气候轨道器（Mars Climate Orbiter）在火星轨道插入机动中失联并损毁。事故调查董事会（Mars Climate Orbiter Mishap Investigation Board）确定的根本原因是：地面软件文件"Small Forces"在轨迹模型中使用了英制单位（磅·秒）而非软件接口规范（Software Interface Specification，SIS）所要求的公制单位（牛·秒）。具体而言，洛克希德·马丁提供的角动量卸载（AMD）数据以磅·秒输出，而 JPL 导航软件依 SIS 假定其为牛·秒，导致轨迹估计在九个月航程中被系统性低估约 4.45 倍，最终插入高度比计划低约一百七十公里，航天器在大气中解体或逃逸（NASA MCO MIB，1999）。

此案例的深刻之处在于：接口"单位"这一语义，本已写于 SIS 文档之中，却在跨组织（JPL 与洛克希德·马丁）的文档传递中被忽略。调查报告指出，该根因未被项目既有的需求走查、设计评审与测试流程捕获；至少两名导航员此前已察觉计算与实际位置不符，但其疑虑因未依规则填表而被驳回（NASA MCO MIB，1999）。这正是一个典型的"语义编码失稳"案例：自然语言 SIS 虽在纸面上规定了单位语义，却缺乏机器可校验的形式硬度，使不一致在跨组织、跨文档的传递中潜伏并最终引爆。若以 MBSE 的 SSOT 理念，将单位语义编码进单一形式化模型并由工具自动校验接口，此类不一致本可在生成下游代码前被捕获——DBSE 下"追溯断裂、变更失控"的顽疾，在此表现为一次以整星为代价的真实返工。

1.10.2 阿丽亚娜 5 型首次飞行：规格未被充分验证的溢出

1996 年 6 月 4 日，欧洲空间局阿丽亚娜 5 型火箭首次飞行（Flight 501）在升空约三十七秒后偏离航迹、解体自毁，损失超过三亿七千万美元（Lions 等，1996）。由雅克-路易·利翁斯主持的 Inquiry Board 查明：惯性参考系统（SRI）软件为 Ariane 4 复用，其中一段仅在 Ariane 4 发射前对齐阶段使用的"死代码"在 Ariane 5 上仍被保留；Ariane 5 升空初期水平速度更高，使对齐函数中的水平偏置变量超出 64 位浮点转 16 位有符号整数的表示范围而溢出，触发异常。程序员出于工作负载上限（80%）的考量，未对该变量做溢出保护——这一假设在 Ariane 4 轨迹下成立，在 Ariane 5 下却不成立。异常被不当处理，两套冗余惯性系统相继停机，主计算机将诊断位误读为飞行数据，指令发动机大幅偏转，火箭在气动力下解体（Lions 等，1996）。

此案例同样指向 DBSE 的病灶：需求与设计的"范围假设"（该变量取值范围）以自然语言规格表述，在从 Ariane 4 到 Ariane 5 的复用中未被重新形式化验证；测试沿用 Ariane 4 轨迹，因而未能暴露语义失配。调查报告直言，既有设计与评审流程"未充分识别地面/飞行模式接口"，并错误地假定"在 Ariane 4 上正确的软件在 Ariane 5 上也正确"（Lions 等，1996）。这反复印证：当语义仅靠文档承载，其"稳定性"与"逻辑精准性"无法跨版本、跨语境被机器保证，变更（此处为平台换代）便引发失控的连锁失效——正是"变更传播失控"这一 DBSE 瓶颈的工程实景。

1.10.3 案例的共性教训与核心论点呼应

两起事故表面成因各异（单位错配、整数溢出），深层病灶却同一：它们都源于"语义被编码于自然语言文档/规格，却缺乏机器可校验的形式硬度"，从而在跨组织、跨版本传递中失稳。这正是 DBSE 五大瓶颈（文档爆炸、不一致、追溯断裂、变更失控、知识散落）的工程实景。它们以惨痛代价证明：形式编码一侧的"柔性"（自然语言易写、规格易复用）在系统规模与耦合越过阈值后，必然侵蚀语义编码一侧的稳定性。MBSE 以模型承载语义、以工具强制一致性，正是对这一类失败的制度性回应——其代价，则是把权重移向语义编码所要求的更严格形式与更高习得门槛。失败案例因此不是 MBSE 的旁证，而是其核心论点的前提。

1.11 建模语言标准化背后的组织政治：OMG 内部 UML→SysML 的演进阻力

建模语言何以为"标准"，从来不只是技术问题，更是组织政治问题。MBSE 的主力语言 SysML 由对象管理集团（Object Management Group，OMG）制定，而 OMG 本质上是一个由工具厂商、用户企业与学术界组成的开放标准联盟，其规范的通过须经成员投票与利益协调。任何语言修订都必须平衡成员间的商业利益与方法惯性。SysML 从 v1 到 v2 的演进，正是形式编码诉求（易学易扩、保护既有投资）与语义编码诉求（形式语义硬化、跨工具一致）在联盟政治中反复博弈的缩影，也是核心论点在标准化组织内部的微观重演。

1.11.1 UML 母体与 profile 的政治妥协

SysML v1（OMG，2007—2019）选择以 UML 的 profile 机制扩展系统语义（Friedenthal 等，2014），而非另起炉灶。这一技术选择背后是清晰的政治逻辑：OMG 成员中大量工具厂商已围绕 UML 建立成熟生态，另建全新语言将动摇其投资、招致强烈反对；复用 UML 既能以最低阻力获得"系统工程版 UML"的共识，又能让既有 UML 工具以较低成本支持 SysML。说白了，v1 的 profile 路线是联盟内部"维持形式编码惯性、避免语义硬化冲击"的政治妥协（Madni & Sievers，2018）。其代价正如前文所述：profile 的无限可定制使语义发散、互操作薄弱——语义编码一侧的失稳被政治所固化，而非被技术所克服。

1.11.2 v1 之困与 v2 的"破坏性"转向

随 MBSE 深入关键领域，v1 的语义松散日益成为瓶颈。2010 年代起，OMG 启动 SysML v2 工作，决定彻底抛弃 UML profile 路线，构建全新元模型，并以 KerML（Kernel Modeling Language）作为一阶逻辑形式语义内核（Seidewitz，2023；OMG，2023）。这一转向在技术上倒向语义编码一侧，在组织上却是"破坏性创新"：它意味着既有 v1 工具与模型资产的兼容性断裂，必然遭遇依赖 v1 生态的成员反弹。v2 同时定义文本与图形互补表示、并提供 Systems Modeling API & Services（OMG，2024）以求跨工具语义一致，正是试图以"标准 API"在语义层重新统一碎片（Borky & Bradley，2018）。技术上的"语义正确"，在组织上必须以兼容性断裂与利益重排为代价。

1.11.3 组织政治与零和取舍的同构

OMG 内部围绕 UML→SysML 的阻力，与本书核心论点构成同构关系。v1 的"政治可行"建立在牺牲语义硬度之上（偏形式编码），v2 的"语义正确"则须以兼容性断裂与成员利益冲突为代价（偏语义编码）。联盟越是想让语言"易学易扩、保护既有生态"（形式编码），就越难强制统一的形式语义（语义编码）；反之，一旦决心硬化语义，便必须承受组织层面的重新洗牌。标准化委员会因此成为零和取舍的微观剧场：每一次表决，都是把符号系统的权重在两端间重新分配一次，而所谓"两全其美"的标准，从未在政治上或技术上真正出现。MBSE 演进史，由此既是语言史，也是一部组织政治史。

1.11.4 工业与能源领域：被忽视的扩散慢变量

需补充指出，工业装备、能源与轨道交通领域的 MBSE 扩散明显慢于航天、国防与汽车，这并非因为其对语义失稳免疫，而是因为失败代价的显性度较低、且系统耦合度在相当长时期内未越临界。当一座工厂或一套电网的接口语义失配，其后果通常是渐进的产能损失或局部停机，而非一次性的任务失败，故组织缺乏以行政权威强制倒向语义编码的紧迫感；与此同时，这些领域既有大量以自然语言与图纸维护的存量工程资产，迁移到形式化模型的成本与风险被高估。这一"慢变量"反过来说明：形式编码一侧的柔性（既有文档习惯、低迁移门槛）在这些领域仍占上风，而语义编码一侧的硬化缺乏足够的失败压力来推动。它进一步佐证核心论点——零和取舍的落点，由领域愿意且能够为语义稳定性实际支付的代价决定，而非由技术理想决定。当数字化交付与全生命周期数字孪生在这些领域逐步成为商业刚需，其扩散方向仍将无可避免地指向语义编码一侧，只是钟摆摆动的节奏更缓和罢了。

第2章 MBSE 的实现方式：语言、方法与工具

2.1 引言：实现方式作为张力的物质载体

在展开本章之前，必须首先将讨论锚定于贯穿全书的根本论点之上：符号系统必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做出不可逆的零和取舍，不存在一种能够完美兼顾两侧的终极体系。MBSE 作为符号系统的一个典型工程实例，其全部历史演进、方法分歧与能力边界，均可归结为这一根本性张力。越是强化形式编码一侧（让语言易学、易扩展、能随需求柔性演化），就越削弱语义编码一侧（语义不稳、密度稀释、逻辑校验失准）；反之，越是追求语义编码的严谨（形式化语义、可执行、可机器验证），就越牺牲形式编码的可习得性与可扩张性。

如果我们将上述论点视为一种“结构性的引力场”，那么本章所讨论的“实现方式”——建模语言、方法论与工具链——就不再是中立的技术选项清单，而是一系列被同一张力所塑形的、彼此竞争的“落点”。所谓“实现方式”，从来不是一套可以任意组合的乐高积木；它本质是各研究与工程群体在形式编码与语义编码之间做出的不同权重分配。因此，本章不打算罗列一份中立的工具目录，而是要把每一种语言、方法与工具都还原到它所处的“取舍站位”上，去追问：它在哪一侧做出了让步，又在哪一侧获得了收益？

Madni 与 Sievers（2018）在综述 MBSE 动机与现状时已经指出，MBSE 的兴起并非源于某次理论突破，而是系统工程面对复杂度指数上升时的一种“符号系统自救”——用显式、可计算的模型替代隐式、难以校验的文档。但恰恰是这种自救，把系统工程直接推入了形式编码与语义编码的两难：要让模型“被广大工程师学会并随项目扩张”，就必须放宽语义约束；要让模型“可被机器精确验证”，就必须牺牲直观性与可扩张性（Madni & Sievers，2018；Borky & Bradley，2018）。本章正是沿着这一矛盾，逐层剖析 MBSE 的实现方式。

值得预先说明的一点是：本章所呈现的“谱系”并不是按时间先后排列的进化阶梯。许多叙述习惯把 SysML v1 到 SysML v2 的演进读作“旧的被新的取代”，把 OPM、Arcadia 等读作“补充性选项”。这种读法会掩盖真正发生的事——它们几乎都不是对前者的超越，而是对同一零和曲线上不同点的重新选取。SysML v2 没有“消灭”SysML v1 的取舍，只是把权重从形式编码一侧移向了语义编码一侧；OPM 与 Arcadia 也从未声称要兼具双方的优点。一旦我们放弃“进步叙事”、改用“取舍站位”的视角，整幅实现方式地图才会显出它本来的结构：那不是一条向上的斜坡，而是一张在二维张力场中散开的散点图（Madni & Sievers，2018；INCOSE，2023）。这一视角也将贯穿本章全部论述。

2.2 建模语言谱系：符号系统的第一条取舍轴

建模语言是 MBSE 最直接、最底层的符号载体，也是零和取舍最先显现的地方。一种语言的语法设计（它允许什么、约束什么）几乎单方面决定了它在形式编码与语义编码之间的站位。

2.2.1 SysML：作为 UML profile 的本质与其双重性

SysML（Systems Modeling Language）是 MBSE 领域事实上的主流语言，其根本身份是统一建模语言 UML 的一个 profile（剖面）（OMG，2007–2019；Friedenthal 等，2014/2018）。这一“作为 profile 而生”的本质，本身就是一次深刻的取舍。

所谓 profile，是 UML 提供的扩展机制：通过 stereotype（构造型）、tagged value（标记值）与 profile 元模型，用户在不必改动语言内核的前提下，为特定领域注入新的语义注解（Friedenthal 等，2014/2018；Weilkiens，2011）。这一机制赋予 SysML 极高的形式编码可扩张性——任何组织都能通过自定义 stereotype 把 SysML 拉伸到自己的领域。然而，这种扩张性的代价正是语义编码的松散：stereotype 本质上只是“附加标签”，并不携带被机器强制的形式语义（Broy & Cengarle，2010；Evermann，2009）。当一百个项目各自定义一百套 stereotype 时，模型在“可扩张”上得分极高，却在“语义稳定”与“逻辑精准”上严重失分——同一个block在不同项目中的解释可能大相径庭。

SysML v1 还以九类图（需求图、用例图、模块定义图、内部块图、参数图、活动图、序列图、状态机图、包图）覆盖了系统描述的多个视角（Friedenthal 等，2014/2018）。九类图的广度提升了形式编码的可习得性与可沟通性——工程师可以挑自己熟悉的图来上手；但广度也意味着语义密度的稀释：不同图之间缺乏统一的形式语义桥接，致使“跨图一致性”长期是 SysML v1 的软肋（Borky & Bradley，2018）。一个需求图里的条目、一个参数图里的约束、一个活动图里的动作，三者可以“看起来相关”却并无机器可验证的语义链路，模型内部的逻辑一致性在很大程度上依赖建模者的纪律而非语言的强制。换种讲法，SysML v1 在形式编码一侧（易学、易扩、柔性）站位明显偏前，在语义编码一侧（严谨、稳定、高密度）则主动让步。这不是设计缺陷，而是取舍的必然结果。

进一步看，SysML 自 v1.0 至 v1.6 的多次修订（OMG，2007–2019；OMG，2019），几乎都是通过修补语法与扩展机制来回应工程实践，而始终未触及“作为 UML profile 因而语义松散”这一根本身份。这从侧面说明：试图在 profile 框架内单方面提升语义严谨，会遇到结构性天花板——因为 profile 的扩展哲学从一开始就以“不强制语义”为代价换取扩张自由（Broy & Cengarle，2010）。认识到这一点，才能理解为何 SysML v2 必须另起炉灶，引入独立的形式语义内核，而非在 v1 上继续打补丁。

2.2.2 OPM：极简图元与高语义密度

与 SysML 的“图海战术”相反，Dori 提出的对象—过程法（Object-Process Methodology, OPM）走了一条截然相反的路线（Dori，2016）。OPM 仅用“对象（Object）”与“过程（Process）”两类基本图元，以及少量链接关系（如消耗、产出、控制、触发、代理），便试图在一个统一模型里同时刻画系统的静态结构与动态行为。其哲学是：用一个极简的、本体论上干净的符号基（object 与 process 两类实体及其关系）来承载高语义密度（Dori，2016；Guizzardi，2007）。

OPM 的这一设计，恰好在语义编码一侧站得很靠前：极简图元背后的本体论约束（object 与 process 的严格区分、事物与过程的不可混淆）带来了较高的语义稳定性与逻辑精准性；一个 OPM 模型在语义上比一个由九类图松散拼凑的 SysML v1 模型更“自洽”（Dori，2016）。然而，这种高语义密度的代价落在形式编码一侧：OPM 的极简基虽然概念上优雅，却要求使用者先建立一套与直觉（以及与传统系统工程文档习惯）不同的本体论思维，学习曲线相当陡峭；同时，由于其图元被严格限定，当面对某些超出 object-process 二元框架的工程表达需求时，扩张能力受限（Dori，2016；Borky & Bradley，2018）。于是我们看到了与 SysML 完全镜像的取舍：OPM 在语义编码上得分高，在形式编码（尤其可习得性、可扩张性）上让步。两种语言，恰如零和曲线上的两个端点。

2.2.3 KerML：SysML v2 的形式语义内核

SysML v2 的演进，本质上是一次向语义编码一侧的“回摆”。其核心变革之一，是引入了一个独立的、形式化定义的内核语言——Kernel Modeling Language（KerML）（OMG，2023；Seidewitz，2023）。KerML 不再依赖 UML 的元模型，而是以一阶逻辑与 4D 时空外延（four-dimensional spatiotemporal extent）来定义建模概念的语义（OMG，2023；Seidewitz，2023；OMG 新闻稿，2023）。

所谓 4D 时空外延，是把一切建模实体（包括“对象”）都视为在四维时空连续体中具有特定延展的“个例（individual）”，而非传统面向对象中离散的、与时间无关的“类实例”（Seidewitz，2023）。这一本体论立场，使得 SysML v2/KerML 能够以前后一致的一阶逻辑公式来表达“状态随时间的保持与变化”，从而在逻辑精准性上远超 SysML v1 的松散 profile（OMG，2023）。

但是，向语义编码的这次回摆同样付出了形式编码的代价。一阶逻辑与 4D 时空本体对大多数系统工程师而言是陌生的数学语言，可习得性显著下降；同时，严格的语义内核意味着“随便加一个 stereotype 就能扩张”的捷径被收窄——任何形式的扩展都必须在该形式语义框架内可被证明自洽（Seidewitz，2023）。SysML v2 试图用“更严谨的内核 + 仍保留的表层语法”来缓和这一矛盾，但根据核心论点，这种缓和只能是程度上的，不可能消除零和：内核越严谨，表层越难被无门槛地扩张（Friedenthal 作为 SysML v2 主笔的相关论述，见 OMG，2023）。

2.2.4 UML、Modelica 与 AADL 的补充角色

在 MBSE 的语言谱系中，还有若干“专才型”语言，它们以牺牲广度来换取特定维度上的语义深度。

UML 作为 SysML 的母体，长于软件实体的结构与行为描述，但其语义根基同样建立在 profile 的可扩张哲学之上，因而在跨域系统语义稳定性上亦有局限（OMG，2017；Broy & Cengarle，2010）。Modelica 则专攻连续动态与多域物理系统，用基于方程的声明式语法表达物理守恒律，在“物理语义精准性”上一枝独秀，却几乎不触及需求、逻辑与组织架构等系统层面的形式表达，可扩张性被严格限定在物理建模域（Modelica Association，2017）。AADL（Architecture Analysis and Design Language）聚焦嵌入式实时系统的架构与资源调度，以严格的时间、空间、调度语义支持形式化分析，语义编码站位极高，但同样只覆盖系统工程的某一截面，形式编码的可习得面较窄（Borky & Bradley，2018）。

这些语言的存在本身，就是零和取舍的旁证：没有任何一门语言同时占有“广覆盖的形式可扩张性”与“深而严谨的语义”，它们各自选择在某一维上深挖，也就意味着放弃了另一维的广度。

2.2.5 语言对比总表

下表将主要建模语言在“形式编码三性”与“语义编码三性”上的取舍站位加以归纳（站位越高表示在该维度投入越多、收益越大，但往往对应另一侧让步）。

上表清晰表明：语言学上的选择，从来不是“哪一种更好”，而是“在零和曲线上愿意站在哪一点”。一种语言在某个单元格里的高分，几乎必然对应另一单元格里的让步——这正是核心论点在语言层面的直接投影。

2.3 MBSE 方法论谱系：取舍的工程化落地

如果说建模语言是符号的“词汇与语法”，方法论则是“如何组织这些符号去完成工程活动”的规程。不同的方法论，本质是对同一组符号资源施以不同的过程约束，从而在形式编码与语义编码之间做出不同的工程化站位。

2.3.1 OOSEM：对象导向系统工程方法

OOSEM（Object-Oriented Systems Engineering Method）由 INCOSE 与 SysML 社区共同推动，是建立在 SysML 之上的、最广泛传播的方法论之一（Friedenthal 等，2014/2018；Estefan，2008）。它把系统工程活动组织为“利益相关者需求分析—系统需求分析—架构定义—设计综合—验证”的迭代循环，并用 SysML 的各类图把每一阶段的产物显式化。

OOSEM 的站位，继承自它所依赖的 SysML v1：由于 SysML v1 本身偏形式编码，OOSEM 的过程产物也就天然偏向“易沟通、易扩展、可随项目柔性裁剪”（Estefan，2008）。其流行，很大程度上正是因为它在形式编码的易学性与可扩张性上做出了让步式的取舍——它不强制一套极严的逻辑语义，而是让团队用自己熟悉的图逐步搭建模型，从而降低了采纳门槛（Madni & Sievers，2018）。代价则是：OOSEM 产出的模型在不同团队间缺乏统一的语义基准，跨组织的逻辑校验能力有限。OOSEM 的成功与局限，恰是“形式编码优先”取舍的缩影。

2.3.2 Harmony-SE：Bruce Douglass 的实时敏捷方法

Harmony-SE 由 Bruce Douglass 提出，最初面向实时与嵌入式系统，强调“敏捷”与“可执行模型”（Douglass，2009）。它在 SysML 活动图、状态机上叠加了从需求到可执行代码的转化规程，使模型能在较早阶段被仿真与验证。

Harmony-SE 在语义编码一侧比 OOSEM 更靠前：它追求模型的可执行性与早期验证，这要求对行为语义施加更严格的约束，从而提升了逻辑精准性（Douglass，2009）。但这一收益以形式编码的让步为代价——严格执行 Harmony-SE 需要团队掌握更专门的状态/活动语义与工具链配置，可习得性与可扩张性相对收窄。它代表了一种“愿意为语义严谨牺牲部分易学性”的站位。

2.3.3 State Analysis：JPL 的状态分析方法

JPL 的状态分析（State Analysis）方法源于航天任务控制中对“系统状态随时间演化”的严密刻画需求（Ingham 等，2004）。它不依赖图形化的 SysML 主流，而是以“状态变量 + 状态转移函数 + 控制程序”的形式化框架描述系统的动态行为，强调数学上的可证明性与可验证性。

在全部 MBSE 方法论中，State Analysis 是语义编码站位最极端的代表之一：它对逻辑精准性与语义稳定性的要求近乎苛刻（Ingham 等，2004）。其实，它在形式编码一侧（可习得性、可扩张性）做了最大程度的让步——只有少数具备强形式化训练的工程团队（如 JPL 的航天任务组）才能有效运用。这一极端的取舍，恰好论证了核心论点的边界情形：极端语义严谨，必然对应极端的形式编码门槛。

2.3.4 Arcadia/Capella：Thales 的工业级方法

Arcadia（Architecture Analysis and Design Integrated Approach）由 Thales 提出，并配套开源工具 Capella，是一套面向大型工业系统（防务、航天、交通）的工程方法（Roques，2016）。它的特色是定义了一套清晰的、分层递进的架构视点（操作、系统、逻辑、物理、 EPBS），并以“与具体建模语言解耦”的方式定义方法语义，再映射到 Capella 原生表示。

Arcadia 的站位偏向形式编码一侧的“可习得性与可沟通性”：它刻意不绑定 SysML 的复杂图集合，而是用一套简化的、领域工程师更易上手的视点来表达，从而降低了大型跨专业团队的采纳成本（Roques，2016）。其代价是：它不追求像 KerML 那样的形式语义严格性，语义编码的逻辑精准性相对温和。Arcadia/Capella 在工业界的成功，再次印证了“为易学易沟通而让语义让步”的取舍逻辑——它之所以能在 Thales 这类巨型组织中落地，正是因为把形式编码的门槛压到了足够低。

2.3.5 SYSMOD：Weilkiens 的系统建模方法

SYSMOD（Systems Modeling Method）由 Tim Weilkiens 提出，是一套与 SysML 紧密结合、强调“用系统化模板驱动建模”的方法（Weilkiens，2011；Weilkiens 等，2015）。它提供需求、上下文、用例、结构、行为等可复用模板，试图在 SysML 的灵活性与工程一致性之间建立纪律。

SYSMOD 的站位接近于 OOSEM：它承认 SysML 形式编码的弹性，又试图用模板把这种弹性约束在可控范围内（Weilkiens 等，2015）。它不试图改变语言本身的语义松散性，而是在方法层“补偿”一部分语义纪律。这种“在方法层弥补语言层取舍”的努力本身，就是对零和取舍的间接承认——方法无法消除语言的底层取舍，只能在其上做局部修补。

2.3.6 RUP/IBM 方法、Vitech 方法与其他

IBM 的 RUP（Rational Unified Process）及其在系统工程中的延伸，把软件开发的过程纪律移植到系统层面，依托 Rhapsody 工具实现模型—代码贯通，语义站位偏严谨但强绑定供应商生态（Borky & Bradley，2018）。Vitech 方法（Long & Scott，2011/2017）则以“需求—行为—结构”三层视图为核心，强调系统思维的完整性，形式编码站位居中、易学性良好，但语义形式化程度有限。此外还有基于状态图传统的 STATEMATE/Statecharts 谱系（Harel & Politi，1998），以及 ROOM 等更早的反应式系统方法（Estefan，2008）。

Estefan（2008）在其著名的 MBSE 方法论调研中，系统性地并列了 OOSEM、Harmony-SE、State Analysis、Statemate、ROOM、RUP 等诸多方法，并明确指出它们“没有哪一种在所有维度上占优”。这一结论，正是核心论点在方法论层面的直接证据：方法的多样性，源于各自在零和曲线上选取了不同的优化点。

2.3.7 方法取位对比表

这张表与语言对比表互为镜像：方法学的站位，几乎总是与它所选用的语言的站位相互加强。语言与方法，在零和曲线上同向滑动。

2.4 工具链生态：取舍的工程实现与商业投影

语言与方法最终必须落到软件工具上才能被工程使用。工具链不仅实现符号，也通过商业策略“再放大”或“再固化”某种取舍站位，其中最值得关注的是互操作性与供应商锁定问题。

2.4.1 MagicDraw/Cameo：事实标准的商业实现

MagicDraw 及其 MBSE 扩展 Cameo Systems Modeler（Dassault/No Magic）是业界使用最广的 SysML 工具之一（Borky & Bradley，2018；Friedenthal 等，2014/2018）。它完整支持 SysML v1，并率先支持 SysML v2 的方向。其优势在于功能全面、生态成熟、培训资源丰富，因而在形式编码的可习得性（丰富的向导、模板）上表现突出。

但作为商业闭源工具，它在开放性上有限：模型主要存于私有仓库格式，跨工具交换依赖 XMI 等脆弱机制（详见 2.5 节）。其强项（易用、全面）某种程度上建立在对 SysML v1 语义宽松性的“容忍”之上，并未强制语义严谨。Cameo 把 SysML v1 的“形式编码优先”取舍，做成了一个顺手的商业产品。

2.4.2 IBM Rhapsody：模型—代码贯通的严谨派

IBM Rhapsody 同样基于 SysML/UML，但更强调从模型到代码的自动生成与实时系统验证（Borky & Bradley，2018）。它在语义编码一侧站位相对较高（强调可执行与一致性），但需要较重的配置与专业训练，形式编码可习得性偏低，且高度绑定 IBM 生态。它体现了“为语义贯通而接受高门槛与高锁定”的取舍。

2.4.3 Capella 与 Papyrus：开源路线的两种姿态

Capella（Eclipse 开源，Thales 主导）是 Arcadia 方法的原生工具，开源免费、方法内置，极大降低了大型组织的采纳门槛，形式编码易学性高（Roques，2016）。其互操作性通过开放的模型存储与逐步接入的标准 API 来改善，但在严格语义验证能力上仍逊于形式化内核路线。

Papyrus（Eclipse 开源）则是 SysML/UML 的通用建模环境，支持 SysML v2 的演进，代表了“开放、可扩展”的工具哲学，形式编码可扩张性强（用户可自行扩展）；但开源工具的语义严谨性依赖社区维护，逻辑校验能力参差不齐（Borky & Bradley，2018）。开源路线整体偏向形式编码一侧（开放、易扩、低门槛），在语义编码的强制严谨上让步。

2.4.4 Sparx Enterprise Architect、OpenMBEE 与 Genesys

Sparx Enterprise Architect 以低价、易得、覆盖面广著称，形式编码可习得性高，适合中小团队；但其语义严谨性与互操作性在复杂企业级场景中受限（Borky & Bradley，2018）。

OpenMBEE（Open Model Based Engineering Environment）走的是“模型即服务、开放集成”的路线，强调模型仓库与 Web 协同，试图通过开源与标准接口打破工具孤岛（OpenMBEE，2020s）。它在开放性上得分最高，但作为一个协作框架，其语义严谨性取决于所接入的语言与方法，本身不做语义强制。

Genesys（由 Rich Karban 等推动）则以形式化语义与可执行系统模型为特色，强调从模型自动生成分析，语义编码站位高，但工具生态与可习得性相对小众（Karban，2017）。

2.4.5 工具对比表：开放性、互操作性与锁定风险

工具链的格局再次显示：开放与易学（形式编码一侧）往往与强制语义严谨（语义编码一侧）不可兼得；而高语义严谨的工具，又往往伴随封闭或高锁定。商业策略在零和曲线上做了二次放大。

2.5 模型仓库与互操作：跨越取舍的尝试及其限度

面对语言、方法、工具各自的内部取舍，工程界试图通过“互操作基础设施”把割裂的模型连成一体。这些努力本身，也处在零和取舍的引力之中。

2.5.1 模型仓库与数字主线

模型仓库（model repository）把分散的模型集中存储、版本化、可追溯，是“数字主线（digital thread）”概念的技术基底（Borky & Bradley，2018；DoD，2018；Madni 等，2019）。数字主线力求让需求、设计、分析、验证在全生命周期中无缝贯通。然而，仓库能统一“存储”却难以统一“语义”：当上游用 SysML v1 的松散 stereotype、下游用 Modelica 的严格方程时，仓库只是把异质语义并置，并不能消除其底层取舍差异（Grieves，2014；Stoewer，2014）。数字主线在形式编码的组织效率上得分，却无法凭空创造出跨语言的语义稳定。

2.5.2 模型转换 M2M/M2T 与 XMI

模型转换（Model-to-Model, M2M；Model-to-Text, M2T）试图在不同模型间搬运信息，其理论根基可追溯至 triple graph grammar 等图转换形式（Schürr，1994）。XMI（XML Metadata Interchange）则是 OMG 标准化的模型交换格式（OMG，2007–2019）。

问题在于，XMI 交换的是“语法结构”而非“语义保证”。由于 SysML v1 语义本身松散，两个工具对同一个 XMI 文件的“理解”可能不一致，导致“可读入但语义漂移”（Borky & Bradley，2018；Evermann，2009）。这里再次出现零和：为了让模型“容易在多种工具间流转”（形式编码可扩张性），XMI 选择不强制语义，于是牺牲了跨工具的语义稳定与逻辑精准。这正是核心论点在互操作层的回响。

2.5.3 SysML v2 API & Services：向语义互操作回摆

作为对 v1 互操作困境的回应，SysML v2 引入了标准的 Systems Modeling API & Services（OMG，2024；OMG，2023）。其思路是：用统一的、基于 KerML 形式语义的编程接口与查询服务，让不同工具对同一模型获得一致的程序化访问，而非仅交换脆弱的 XMI 文本。

这是一次明确的向语义编码一侧的回摆——通过形式化的 API 语义，提升跨工具的逻辑精准与稳定（Seidewitz，2023）。但代价是：工具开发者必须实现复杂的语义内核，终端用户也被迫接受更严格的语义约定，形式编码的可习得性与可扩张性随之受限。回摆缓解了问题，却仍受制于零和：互操作越要“语义真一致”，底层符号系统就越难“随意扩张”。

2.6 “实现方式碎片化”现象分析：零和取舍在生态层面的投射

把语言、方法、工具三张表合起来看，一个无法回避的现象浮现：MBSE 的实现方式高度碎片化。语言有 SysML/OPM/KerML/Modelica/AADL 等；方法有 OOSEM/Harmony-SE/State Analysis/Arcadia/SYSMOD/RUP/Vitech 等；工具有 Cameo/Rhapsody/Capella/Papyrus/EA/OpenMBEE/Genesys 等。彼此之间既缺乏统一互操作，又各自声称“适合某类项目”。

Estefan（2008）的调研早已记录了这种“方法丛林”的繁荣，INCOSE 的 MBSE 调研也持续显示方法采纳的碎片化（INCOSE MBSE Initiative，2007–）。若按“进步叙事”，这会被解释为该领域生机勃勃、尚在探索最优解。但依据本书核心论点，碎片化并非进步充分的证据，而恰恰是零和取舍在生态层面的直接投射。

其机制如下：由于任何单一符号体系都无法同时占有形式编码与语义编码的全部优势，每一种语言、方法、工具都只能在自己偏好的编码侧重上做局部优化——SysML/OPM/Arcadia 在形式编码（易学、易扩）上放宽，State Analysis/KerML/Genesys 在语义编码（严谨、可验证）上深挖。于是生态层面自然分裂为多个“优化点不同的孤岛”。跨方法之间的语义稳定与可习得一致性，恰恰因为每种方法都在强化自己的侧重而被牺牲。碎片化不是偶然的市场竞争结果，而是底层零和张力的必然生态投影（Madni & Sievers，2018；Borky & Bradley，2018；Stoewer，2014）。

需要澄清一个常见的误解：碎片化并不等于“彻底不可协作”。在形式编码层面，不同方法之间其实可以通过共享的文档习惯、人工映射与项目约定达成“够用”的协同——这恰恰是为什么许多组织能够容忍碎片化并照常推进项目。问题的要害在于，这种协同的代价被悄悄转嫁到了语义编码一侧：当跨方法的语义一致性只能靠人工维护时，模型的机器可验证性、逻辑精准性就被实质性牺牲了。也就是说，碎片化生态之所以“看起来能运转”，是因为它持续地在语义编码一侧支付利息。一旦项目进入强验证需求场景（如安全关键系统、适航认证、跨组织联合研制），这笔利息就会以高昂的协调成本与认证风险形式显现（Borky & Bradley，2018；Stoewer，2014）。混淆“人工可协同”与“语义可互操作”，是许多 MBSE 采纳失败的根源之一。

更尖锐地说：如果真有一种“完美兼顾”的体系存在，市场早应趋向收敛于它；而现实的持续碎片化，反向印证了“不存在终极体系”这一论点。互操作努力（XMI、SysML v2 API）之所以屡屡受挫或只能部分成功，根源不在于工程投入不足，而在于它们试图在零和曲线上“既要又要”——这是结构性不可能。

还可以从组织行为学的角度补充一层观察：碎片化之所以被工程组织“忍受”甚至“维护”，是因为每种组织都在潜意识里选择了适合自身能力结构的站位。一支以文档与协调见长、形式化训练有限的大型工业团队，会自然倾向 Arcadia/Capella 这类低门槛方法；一支航天任务控制团队则会选择 State Analysis 这类高严谨方法（Ingham 等，2004；Roques，2016）。组织不是在“比较所有方法的客观优劣”后碎片化，而是在“匹配自身取舍偏好”后主动分化。这等于说，即便未来出现某个在纸面上更平衡的语言或方法，它也很难真正抹平碎片化——因为碎片化的最终锚点不是技术，而是不同组织愿意支付哪一侧的代价（Borky & Bradley，2018；Madni & Sievers，2018）。

由此我们得到一个对全书其余章节具有约束力的结论：实现方式的碎片化不应被当作“待解决的工程问题”去消除，而应被当作“张力的生态指纹”去理解。后续章节在讨论 MBSE 的能力边界、采纳阻力与未来走向时，都必须回到这一指纹——任何声称能终结碎片化的方案，要么是在转移取舍的代价，要么是在隐瞒自己在零和曲线上的真实站位。

2.7 小结：多样不是充分进步，而是张力未被消除的证据

本章沿“语言—方法—工具—互操作”逐层展开，展示了 MBSE 实现方式的广阔谱系。但我们始终没有把它当作中立的技术清单，而是把它还原为一系列在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做出的不同权重分配：

• 在语言层，SysML v1 以 profile 的可扩张性换取语义松散，OPM 以陡峭学习曲线换取高语义密度，KerML/SysML v2 以一阶逻辑与 4D 时空外延回摆向语义严谨，Modelica 与 AADL 则以覆盖面换取特定域的深度语义。

• 在方法层，OOSEM 与 Arcadia 为易学易落地而让语义宽松，Harmony-SE 与 RUP 为可执行验证而抬升门槛，State Analysis 则将语义严谨推到极致、形式编码门槛亦到极致，SYSMOD 与方法层补强只是对语言层取舍的局部修补。

• 在工具层，商业闭源工具（Cameo、Rhapsody）以易用或严谨换取锁定风险，开源工具（Capella、Papyrus、OpenMBEE）以开放换取语义强制的让步，Genesys 以严谨换取小众。

• 在互操作层，XMI 为流转便利牺牲语义保证，SysML v2 API 为语义一致抬高实现与采纳门槛。

一言以蔽之：MBSE 实现方式的多样，不是“进步已经充分”的勋章，而是“根本张力尚未被任何体系消除”的证据。每一种流行，都对应一次自觉或不自觉的取舍；每一种不足，都源于它在另一侧必然的让步。第3章（及后续章节）将继续追问：当这种零和取舍被视为不可消除的结构性事实时，我们应当如何审慎地选择、组合与治理 MBSE 的实现方式，而不是幻想一种能够终结取舍的终极方案。

2.8 建模语言形式化谱系对比的深化：六性的精细站位

前文 2.2.5 给出的六性总表，采用的是粗粒度的“高／中／低”分级，足以指示方向，却不足以支撑“取舍曲线的不同最优点”这一判断背后的机理。要切实论证该判断，必须把分级落到更可比较的精细维度上：形式化语义基底、可机器验证性、典型学习周期、跨域覆盖度、工业成熟度，以及跨图（跨模型）语义桥接能力。本小节补一张精细表，并逐列解释其如何印证零和取舍。

第一列“形式化语义基底”是理解全部差异的钥匙。SysML v1 与 UML 共享 profile 哲学——stereotype 本质上是附加标签，不携带被机器强制的形式语义（Broy & Cengarle，2010；Evermann，2009），因此其“可机器验证性”天然偏弱，高度依赖建模者的纪律而非语言的强制。这正是 Friedenthal 等（2014/2018）在 SysML 实务指南中反复强调“建模公约（modeling convention）必须作为方法论的一部分被显式管理”的根本原因——公约所填补的，正是语言在语义编码一侧的结构性空缺。应当指出，这种“靠公约补语义”的做法并非 SysML 独有，而是 profile 式扩展路线的通病：只要语言内核不强制语义，扩张越自由，机器可验证性就越稀薄（Broy & Cengarle，2010）。

OPM 之所以在可机器验证性上优于 SysML v1，是因为它把 object 与 process 的严格本体区分作为“统一基”，所有图元都从这一个基派生，因而跨图（在 OPM 中其实是同一张对象—过程图在不同粒度上的投影）的语义桥接是内建的（Dori，2016；Guizzardi，2007）。但这一收益以“典型学习周期 8–16 周”为形式编码代价——工程师必须先重构一套与传统文档习惯不同的本体论直觉。这里出现一个常被忽视的细节：OPM 的“图少”并不等于“易学”，恰恰相反，图元越少、本体约束越严，对使用者的概念负担越集中，学习曲线反而越陡。

KerML／SysML v2 把基底换成一阶逻辑与 4D 时空外延（OMG，2023；Seidewitz，2023），可机器验证性跃升为“强（可证明）”，跨图语义桥接也因统一内核而增强；但典型学习周期被拉到 12–24 周，且工业成熟度仍处“成长中”——大量既有实践资产沉淀在 v1，迁移本身即一笔形式编码代价。这恰是零和曲线上一次明确的“右移”：每在语义编码侧进一分，形式编码侧（可习得性、可扩张性）便退一分（Friedenthal 作为 SysML v2 主笔的相关论述，见 OMG，2023）。别忽略的是，KerML 并非简单地“更严格”，而是把建模实体统一视为四维时空连续体中的个例（individual），从而让“状态随时间的保持与变化”可用前后一致的一阶逻辑公式表达（Seidewitz，2023）；这种本体论收益与概念门槛是同一枚硬币的两面。

Modelica 与 AADL 则展示了“专才型”路线在两列上的极端分野：它们以窄跨域覆盖度（物理域／嵌入式实时）换取了极强的形式化可验证性（Modelica Association，2017；Borky & Bradley，2018）。这提示一个对全书有用的推论：零和取舍不仅发生在“形式编码 vs 语义编码”两轴之间，也发生在“广度 vs 深度”这一对子轴上；而后者往往是前者的生态放大（Weilkiens 等，2015）。换个说法，当一种语言选择深挖某一物理或实时语义时，它实际上是在语义编码的某一维上加倍投入，同时在该维的广度上加倍让步——两对零和在此叠加，使专才型语言的站位更加极端。

由此可推出一个对后续章节具有约束力的判据：判断一门语言“站在零和曲线何处”，不应只看其宣称支持多少图或多少视图，而要看其形式化语义基底的强制程度——基底越强制，语义编码得分越高，形式编码代价越大。六性总表（2.2.5）与精细表（本节）应当并读：总表给出方向，精细表给出机理；两者共同说明，所谓“语言多样性”，不过是同一零和曲线上若干可被不同组织各自接受的最优点的散点投影。

2.9 方法论适用域矩阵：项目类型、代价与取舍

语言是被选定的符号载体，方法论则是把符号组织成工程活动的“过程约束”。但方法不是“越严谨越好”，而是“越匹配项目属性越好”。本小节给出一张适用域矩阵，把前文的六性取舍转译为“具体项目应如何选方法”的可操作判据，并显式计入代价，以免读者误以为存在某种“通吃一切”的方法。

这张矩阵的核心不是“推荐”，而是“代价透明”。每一种“首选”背后都对应一处已经在语义编码或形式编码上预付的代价。例如，安全关键领域选 Harmony-SE／RUP，看似“更严谨”，实则把代价预付在“团队必须掌握专门的状态机／活动语义并配置较重工具链”之上（Douglass，2009；Borky & Bradley，2018）；其收益（早期可执行验证）只有在“验证失败成本高昂”的场景里才划算——一旦项目并不处于适航或车规这类强验证语境，这笔预付代价便转为沉没成本。反观 Arcadia／Capella 在大型防务与交通系统的成功，恰恰因为它的代价（语义形式化有限）被“跨专业低门槛协同”这一压倒性需求所吸收（Roques，2016）——在这里，形式编码的易学性本身就是项目可行性的前提，而不是可牺牲的奢侈品；若强行引入高严谨方法，跨专业协同反而会因门槛过高而崩解。

State Analysis（JPL）把代价推到极端：其数学可证明性只有具备强形式化训练的小团队（如航天任务控制）才负担得起（Ingham 等，2004）。这印证了核心论点的一条重要推论：当项目对“逻辑精准性”的边际需求足够高时，组织愿意——也必须——支付极高的形式编码代价；反之，当“协同广度”才是瓶颈时，组织会主动选择让语义编码让步。代价不是客观的“好坏”，而是组织在特定约束下对零和曲线最优点的标定（Madni & Sievers，2018）。

为了把这一逻辑具象化，不妨设想两个对照场景。场景甲是一家初创团队开发消费级物联网固件，需求月均变更十余次。若采用 State Analysis，团队将被形式化建模的数学负担拖垮，迭代速度归零，形式编码代价远超其收益。场景乙是某型飞机的飞控软件研制，须通过适航当局的形式化验证。若采用 Arcadia／Capella 这类低门槛方法，跨专业协同虽顺畅，却无法在证书层面提供可机器证明的逻辑保证，语义编码的让步在此直接转化为认证风险（Borky & Bradley，2018）。同一组语言与方法，在两个场景里“最优”结论截然相反——这恰好说明所谓“最优”永远是某一约束条件下的局部最优，而非全局无代价最优。

Estefan（2008）在其方法论调研中并列了 OOSEM、Harmony-SE、State Analysis、Statemate、ROOM、RUP 等诸多方法，并明确指出“没有哪一种在所有维度上占优”。本矩阵不过是把这一结论工程化为“按项目属性查表”的形式；它不削弱、反而强化了零和论点。另需特别指出“多组织联合研制”一行的特殊性：它无法靠单一方法消除跨组织语义差异，只能靠 SYSMOD 这类“模板治理＋人工映射”在方法层做局部补强（Weilkiens 等，2015）。这再次说明，方法层无法消除语言层的内生取舍，只能在零和曲线上做二次平移——方法与语言同向滑动，却都无法越出张力场之外。

2.10 工具互操作性的实测案例与 XMI／API 迁移失真

前文 2.5 已勾勒互操作的“语义保证 vs 流转便利”零和。本小节把该零和落到可观测的失真现象上，以说明“可读入 ≠ 语义一致”为何不是偶发 bug，而是结构性必然。

2.10.1 XMI 迁移失真的三重来源

基于 triple graph grammar 的模型转换理论（Schürr，1994）与 XMI 交换实践（OMG，2007–2019），XMI 失真可归为三类，每一类都直接对应零和取舍的某一个侧面。

其一是“方言漂移”：SysML v1 的 stereotype 由各厂商与项目自定义，同一 XMI 标签在不同工具中的解释可能不同，导致“读入后语义改变”（Borky & Bradley，2018；Evermann，2009）。例如某私有构造型 «safetyCritical» 在工具 A 中被映射为可求解的约束，在工具 B 中仅作显示标签——结构完全相同，语义却已相异。这种漂移的本质，正是 profile 路线“不强制语义以换取可扩张性”的代价兑现。

其二是“图间链路断裂”：SysML v1 的九类图之间缺乏形式语义桥接（见 2.2.1）。当模型从工具 A 导出 XMI 再导入工具 B，需求图与参数图之间本就脆弱的关联常因元素 ID 重映射而丢失或错配，模型内部逻辑一致性进一步受损（Friedenthal 等，2014/2018）。即便两段语法都“成功解析”，模型作为整体的语义连贯性已遭到破坏。

其三是“约束消解”：参数图中的等式约束、状态机中的监护条件等“可执行语义”，在 XMI 文本交换中常被降级为注释或纯字符串，失去可被求解的语义（Borky & Bradley，2018）。说白了，XMI 保住了“语法骨架”，却丢弃了“语义血肉”。三重失真共同说明：XMI 为换取“模型易在多种工具间流转”（形式编码可扩张性），主动不强制语义，于是牺牲了跨工具的语义稳定与逻辑精准（Evermann，2009）。这正是零和取舍在互操作层最具体的显形——它不是实现质量低下的产物，而是交换格式在零和曲线上选点的结果。

2.10.2 从 XMI 到 SysML v2 API：失真能否被消除

作为对 v1 困境的回应，SysML v2 引入了基于 KerML 形式语义的 Systems Modeling API ＆ Services（OMG，2024；OMG，2023），以程序化、语义一致的方式访问模型，而非交换脆弱文本。方向无疑向语义编码一侧回摆：跨工具访问获得统一的形式语义基底（Seidewitz，2023）。

但实测层面的“失真消除”仍受零和约束。第一，API 语义一致的前提是所有工具都完整实现 KerML 内核，而实现复杂度把第三方工具开发者挡在更高门槛之外——形式编码可扩张性（他人易扩展）随之收窄，互操作生态的多样性因此被抑制。第二，即便 API 一致，跨语言（如 SysML 模型与 Modelica 物理模型）的语义桥接仍需额外的语义映射，API 本身并不消灭 2.5.1 所述的“异质语义并置”问题（Borky & Bradley，2018；Stoewer，2014）。第三，OpenMBEE 等“模型即服务”框架通过标准接口提升互操作（OpenMBEE，2020s），但其语义严谨性取决于底层所接入的语言与方法，框架本身不做语义强制——它把零和的选择权交还给用户，而非替用户消解零和。

2.10.3 一个简化的失真度量视角

为把上述现象量化，可引入“语义保真度”概念：设一次迁移后机器仍可验证的语义约束比例为 f∈[0,1]。经验上，SysML v1 经 XMI 的 f 常明显低于 0.5（多数约束在文本交换中降级），而经 SysML v2 API 在同构工具间的 f 可接近 1（Seidewitz，2023；OMG，2024）。但 f 的提升以“工具实现成本 × 用户语义纪律”为分母——分母越大，f 越难在产业尺度普及。这一比值恰是零和曲线在互操作层的投影：任何把 f 推向 1 的努力，都在形式编码侧收取等额代价。

小结：互操作失真不是工程投入不足，而是“要在零和曲线上既要语义一致、又要随意流转”这一结构性不可能的外在症状。理解这一点，才能避免把 MBSE 互操作困境误读为“再写一套更好的转换器即可解决”——转换器只是把同一笔零和代价从一处挪到另一处，从不曾消除它。

2.11 实现方式碎片化的治理含义：在零和曲线上主动选点

把第 2.2 至 2.10 节的讨论收束，可得到一个对全书其余章节具有操作意义的治理原则：既然碎片化是零和取舍在生态层面的必然投影（见 2.6），那么治理的目标就不该是“终结碎片化”，而该是“让每个组织清晰地说出自己站在曲线的哪一点，并为该点的代价负责”。

具体而言，这要求在项目启动期完成一次显式的“取位声明”：选定语言时，写明其形式化语义基底的强制程度与对应的学习周期（呼应 2.8 精细表）；选定方法时，写明其适配的项目类型与所预付的代价（呼应 2.9 矩阵）；选定工具与互操作策略时，写明 XMI 或 API 路线所容忍的语义保真度下限（呼应 2.10）。这种“把取舍说在前面”的做法，正是 Friedenthal 等（2014/2018）所倡“建模公约须显式管理”的延伸——公约治理的，正是语言与工具在语义编码一侧的结构性空缺。

需要强调的是，“主动选点”并不等于“各选各的、互不往来”。在形式编码层面，不同方法之间仍可通过共享文档习惯、人工映射与项目约定达成“够用”的协同（见 2.6）；问题在于这种协同的代价被悄悄转嫁到了语义编码一侧。因此，治理的第二条原则是：当项目进入强验证需求场景（安全关键、适航认证、跨组织联合研制）时，必须预先承认“人工可协同”无法替代“语义可互操作”，并据此把方法站位从形式编码侧回调到语义编码侧（如由 Arcadia 转向 Harmony-SE 或 State Analysis 一类的严谨路线），而非幻想用协同惯例掩盖语义缺口（Borky & Bradley，2018；Stoewer，2014）。

至此，第 2 章完成了对“实现方式”这一主题的完整刻画：语言、方法、工具与互操作，四层皆被还原为同一零和张力场上的不同选点；所谓碎片化，不过是一组彼此不可通约的最优点的并置。第 3 章起，我们将离开“实现方式是什么”的描述层，进入“在不可消除的张力之下应当如何审慎选择、组合与治理”的规范层——而本章所确立的“选点自觉”与“代价透明”，将成为后续全部规范性讨论的底座。

第3章 MBSE 的语义基础与形式化张力

3.1 引言：作为符号系统的 MBSE

在展开一切具体的技术讨论之前，需要先确立本章乃至全书的立论前提：MBSE（基于模型的系统工程）不是某一种孤立的工程技巧，而是一套以图形化、结构化符号为载体的工程语言系统。也就是说，MBSE 首先是、并且本质上是一个符号系统。任何符号系统都面临一个根本性的设计问题——它必须决定：用何种方式把"现实世界中的系统事实"映射为"可被人类理解、可被机器处理的符号"。这个映射过程，我们称之为"编码"（encoding）。

本书的核心论点，正是在这一层面对 MBSE 做出诊断：

符号系统必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做不可逆的零和取舍，不存在完美兼顾的终极体系。MBSE 作为符号系统的一个典型工程实例，其全部历史演进、方法分歧与能力边界，均可归结为这一根本性张力：越是强化形式编码一侧，就越削弱语义编码一侧；反之，越是追求语义编码的严谨，就越牺牲形式编码的可习得性与可扩张性。

本章是全书的"理论核心章"。后续第5章讨论 MBSE 的局限性、第6章梳理方法学争议、第7章展望未来发展，其底层逻辑都将在本章建立的分析框架中得到统一解释。因此，本章的任务不是罗列 MBSE 的工具或方法，而是要回答三个更根本的问题：

第一，所谓"形式编码"与"语义编码"到底指什么？它们各自包含哪些可度量的性质？这是本章的概念基石（3.2 节）。

第二，在 MBSE 的真实演进史中，这套零和取舍是如何被反复验证的？我们从元模型与四层架构（3.3 节）、本体与概念建模（3.4 节）、SysML 形式语义之争（3.5 节）、可执行 MBSE（3.6 节）、互操作与可分享性（3.7 节）五个维度逐一拆解。

第三，当这套张力落到一个具体的工程决策上时，它如何具象化为"一处增益、一处付出"的不可逆交易？我们用贯穿全章的例子加以说明（3.8 节），并在小结中给出贯穿全书的判断（3.9 节）。

需要预先澄清一点：本书所说的"零和"并非指每一次取舍都严格地此消彼长、总量恒定，而是指不存在一个设计点能够同时让六性全部达到最优。换种讲法，在形式侧与语义侧之间，增益与代价呈结构性反向关联，且这种反向关联无法通过对工具的局部修补而消除。这正是"零和"一词在本书中的精确含义——它描述的是"帕累托最优不存在"这一事实，而非"收益与损失在数量上严格相等"。这一限定对后续所有论证都成立。

3.2 概念界定：形式编码与语义编码

本章的一切论述都建立在两个概念的清晰区分之上。这两个概念常被混用，但本书坚持将它们拆开：形式编码关乎"符号如何被生成、学习、扩展与演化"，语义编码关乎"符号承载的意义是否稳定、稠密、可被机器精确推理"。

3.2.1 形式编码及其三性

形式编码（formal encoding） 指的是符号系统在外在形态层面所具备的工程特征：一个建模者多大代价能够上手、一套语言多大代价能够适配新领域、一个既存模型多大代价能够随系统演化而增删改。它衡量的是"语言作为工具的可使用性"。形式编码包含三个可独立度量的性质：

可习得性（learnability）：建模者从零基础到能够独立产出可用模型所需的时间与认知负荷。可习得性高的语言，概念基数小、记法直观、与领域直觉贴合；可习得性低的语言，概念基数大、记法抽象、需要先掌握底层数学或逻辑基础。MBSE 工具能否被广大系统工程师而非仅被建模专家采用，首先取决于可习得性（Madni & Sievers，2018）。

可扩张性（extensibility）：语言能否以低成本适配新的领域、新的关注点或新的分析需求，而无需修改语言内核。可扩张性高的语言提供轻量的扩展机制（如标签、原型、剖面），让领域专家在不必理解编译器/解释器内部的前提下扩展词汇；可扩张性低的语言则要求任何扩展都经由严格的语言修订流程。

动态柔性（dynamic flexibility）：既存模型能否随系统需求演化而被柔性地增删改，而不引发大范围的级联破坏。动态柔性高的语言允许局部修改、支持版本差量与增量演化；动态柔性低的语言一旦核心结构确定，任何变更都代价高昂。

3.2.2 语义编码及其三性

语义编码（semantic encoding） 指的是符号系统在其意义的解释层面所具备的严谨程度：一个符号的含义是否会在不同人、不同工具、不同时间之间漂移；单位符号是否承载了丰富而无歧义的信息；符号能否被机器精确地解析、约束与推理。它衡量的是"语言作为知识载体与推理基础的可信度"。语义编码同样包含三个可独立度量的性质：

稳定性（stability）：符号含义不随解释者、工具或上下文而漂移的程度。稳定性高的语言，同一张图在两个合格建模者眼中含义一致，在两种合规工具中解析一致；稳定性低的语言则允许"同一图、多种读法"，这正是歧义与集成灾难的根源（Friedenthal、Moore & Steiner，2014/2018）。

高密度性（density）：单位符号承载丰富且无歧义信息的程度。高密度并非简单指"信息多"，而是指"在保持无歧义前提下的信息量大"。一个只包含方框与箭头的草图信息稀疏；一张同时嵌入物理量纲、约束关系、追溯链条与可执行语义的模型，则信息稠密（Dori，2016）。

逻辑精准性（logical precision）：符号能否被机器精确地解析与推理，从而支持自动化的约束检查、一致性验证与仿真。逻辑精准性高的语言背后存在形式化语义（formal semantics），即一种将语言构造映射为逻辑公式的精确规则；逻辑精准性低的语言则只能依赖人工评审来发现错误（Broy & Cengarle，2010）。

3.2.3 六性判别指标：让张力可度量

为了让"零和取舍"不再是一句口号，而成为一种可度量、可论证的工程判断，本节给出一组可操作的判别指标。这些指标不必在每次讨论中全部量化，但其存在使得后续每一节都能回答："我们在哪一侧取得了增益？在哪一侧付出了代价？"表 3.1 汇总了六性及其判别指标。

表 3.1 形式编码与语义编码六性判别指标

需要强调：这六性并非彼此正交的六个独立旋钮，而是成对地耦合在两个"侧"之内、又结构性地对立在两侧之间。形式侧的三性（可习得性、可扩张性、动态柔性）往往同向变化——让语言易学，通常也让它易扩、易改；语义侧的三性（稳定性、高密度性、逻辑精准性）也往往同向变化——一旦意义被形式化，它通常同时变得更稳定、更稠密、更可被推理。然而，形式侧整体与语义侧整体之间，却呈现系统性的反向关联。这正是本书核心论点的度量落点。

3.2.4 跨域旁证：零和并非 MBSE 独有

为避免读者误以为"形式编码—语义编码零和"是 MBSE 的某种工程失误，本节以其他符号系统为旁证，说明它是一条跨越符号种类的普遍规律，MBSE 只是其中一个典型工程实例。

编程语言。Python 以语法直观、库生态易扩展而著称（可习得性↑、可扩张性↑），但代价是运行时语义的动态性与类型检查的宽松，使得大规模系统易在语义层面出错（稳定性↓、逻辑精准性↓）；反观 Rust 或带证明的 Coq/Isabelle，以严格的所有权/类型或构造证明保证语义精准（稳定性↑、逻辑精准性↑），却以陡峭的学习曲线与高昂的扩张门槛为代价（可习得性↓、可扩张性↓）。两者恰处零和曲线的两端。

数学。形式化数学（如集合论公理化体系）语义最稳定、最稠密、最可被机器验证，但习得与扩张都极端困难；自然语言式的"直观数学"则易学易用、便于自由表达，却允许歧义与隐蔽矛盾。数学史从直觉到形式化的每一次推进，都是语义侧得分、形式侧扣分的交易。

自然语言本身。自然语言是人类最"易习得、易扩张、柔性"的符号系统（婴儿即可掌握，词汇随需膨胀，语义随语境演化），但其稳定性与逻辑精准性最低——同一句话在不同语境下的含义漂移，正是歧义与争论的永恒来源。没有任何自然语言改革能同时让"人人易学、自由扩张"与"含义零漂移、可被机器精确推理"兼得。

三组旁证共同表明：零和是符号系统的结构属性，而非某套工程标准的缺陷。MBSE 既然是一个符号系统，便无从豁免。认清这一点，才能在第5章以后正确地把"MBSE 的局限"理解为"零和的代价"而非"实现的失败"。

3.3 元模型与四层架构：形式侧"可扩张性"的机制及其代价

MBSE 语言（尤其是 OMG 的系列建模标准）以"四层元建模架构"为组织骨架。理解这套架构，是理解"形式侧可扩张性从何而来、又如何侵蚀语义稳定性"的第一步。

3.3.1 四层架构（M0–M3）

OMG 的建模体系普遍采用四层架构（OMG，2007–2019；OMG，2017）：

• M3 层（元元模型，meta-metamodel）：定义"如何定义元模型"的最抽象构造，如"类""关联""属性"。它是元模型的元模型。

• M2 层（元模型，metamodel）：在 M3 之上定义具体语言的抽象语法，例如 UML 的元模型、SysML v1 的元模型。它规定了该语言有哪些合法构造。

• M1 层（模型，model）：在 M2 元模型约束下，对真实系统进行描述的具体模型，如某卫星的动力分系统模型。

• M0 层（实例，instance）：模型所描述的现实世界中的真实运行对象。

这套层级看似只是学术分层，实则承载了关键的工程意图：通过在 M2 之上叠加轻量的"扩展层"，语言可以在不改动元模型内核的前提下，适配特定领域。这是形式侧"可扩张性"的根本来源。

3.3.2 profile、stereotype、tagged value：轻量扩张机制

SysML v1 与 UML 共享一套经典的轻量扩展机制（Friedenthal 等，2014/2018；OMG，2007–2019）：

• stereotype（构造型）：在既有元类之上附加一个新的"标签化语义"，例如把 UML 的 Class 标记为 «block»，从而表达 SysML 的"块"概念。

• profile（剖面）：一组相关 stereotype 的集合，构成一个针对特定领域的扩展包，如 SysML 的"需求剖面""参数剖面"。

• tagged value（标记值）：为 stereotype 附加的自定义属性，用于承载领域特定的元数据，例如给某个块标记"可靠性等级=高"。

这套机制的设计意图极其明确：让领域工程师不必触碰 UML/SysML 的元模型内核，就能以"贴标签"的方式把自己的领域词汇叠加到通用语言之上。这极大地提升了可扩张性与动态柔性——新增一个领域概念，往往只是新增一个 stereotype，而非重写语言。也正因如此，MBSE 才得以在航空、汽车、国防、医疗等众多差异巨大的领域中被快速采用（Estefan，2008）。

3.3.3 加法背后的减法：扩展如何稀释语义稳定性

然而，零和取舍在此已然显现。profile/stereotype 机制以"不保证语义"为代价换取扩张自由：

第一，stereotype 只规定了"贴什么标签"，却没有为标签规定强制性的形式语义。一个 «block» 究竟意味着"物理实体""逻辑抽象"还是"数据流节点"，标准并不强制，将其留给建模者或工具供应商解释。于是，同一标签在不同项目中可能承载不同含义——语义稳定性↓。

第二，tagged value 本质上是一种"无类型约束的键值对"，它绕过了元模型的类型系统。这意味着任何工具都可以自由塞入任意字段，而这些字段在另一种工具中既无对应语义、也无解析规则——跨工具稳定性↓，为 3.7 节所述的互操作脆弱性埋下伏笔。

第三，profile 的泛滥导致"语言碎片化"：每个组织、每个项目都拥有一套自己的 stereotype 方言。语言表面上仍是 SysML，实则已是彼此不可通约的方言集合。可扩张性↑的同时，全局语义稳定性↓。

因此，四层架构与 profile 机制揭示了一个根本事实：形式侧的扩张自由，是以语义侧的解释自由（即歧义空间）为支付成本的。这并非实现不精，而是机制本身的结构性后果。

一个具体的反例最能说明问题：当某组织用 stereotype 把"需求"标记为 «performanceRequirement» 并附加 tagged value threshold=0.95 时，标准并未规定"0.95"的语义是概率、置信度还是归一化指标，也未规定该阈值应在系统生命周期哪一阶段、由何种证据满足。工具甲可能将其解释为设计目标，工具乙可能解释为合格判据，工具丙可能干脆忽略。一个看似"扩展了需求语义"的轻量操作，实际在语义侧打开了三扇歧义之门。这正印证：profile 扩张的每一分增益，都在语义稳定性上等额计提了风险准备金。

3.4 本体与概念建模：语义稳定性的来源及其反向代价

如果说 profile 机制代表"形式侧扩张优先"的取向，那么本体（ontology）驱动的概念建模则代表"语义侧稳定优先"的另一极。本节展示：语义稳定性确有来源，但其代价恰恰是形式侧的可习得性与可扩张性。

3.4.1 语义稳定性的来源：本体论约束

Guizzardi（2007）在其关于本体、概念化与（元）模型的开创性论述中指出：建模语言要获得可靠的语义，不能仅依赖语法层的约定，而必须建立在明确的本体论承诺（ontological commitment） 之上——即明确区分"对象""属性""事件""关系""角色"等基本的存在论范畴，并规定它们之间的合法组合。只有当我们清楚"一个'块'在存在论上究竟是对象还是类型、是具身实体还是抽象结构"时，模型的含义才可能稳定。

这一思想对 MBSE 意义重大：许多模型之所以产生歧义，根源在于建模语言混用了存在论范畴（例如把"功能"既当对象又当过程来建模）。引入本体约束，能够强制建模者在严格的存在论框架内表达，从而显著提升稳定性与逻辑精准性：含义不再漂移，且可被机器依据本体规则校验（Evermann，2009 将本体用于 UML/OCL 模型的验证即是一例）。

3.4.2 零和在此现身：稳定性↑ ⇒ 学习成本↑、扩张门槛↑

然而，本体论框架的引入立刻触发了反向代价：

其一，可习得性↓。系统工程师需要预先掌握存在论范畴的区分（对象vs类型、反事实vs事实、内在vs外在属性……），这是一种沉重的认知负荷。对多数领域专家而言，他们关心的是"推力是否足够""接口是否匹配"，而不是"这个实体在存在论上归属于哪一范畴"。本体提供的语义严谨，是以牺牲领域专家的直觉易得性为代价的。

其二，可扩张性↓。在本体约束下，任何新概念的引入都必须先通过存在论合法性审查，不能像 stereotype 那样随意贴标签。扩张从"自由叠加"退化为"受控纳入"，门槛显著提高。形式侧的轻量扩张通道被语义侧的严谨要求封堵。

其三，动态柔性↓。既有模型若要变更，需确保不破坏隐含的本体不变量，局部修改的级联风险上升。

于是，3.4 节与 3.3 节恰好构成镜像：profile 机制以稳定换扩张，本体建模以扩张换稳定。两者都不是"错误"，而是同一零和曲线上的两个不同工作点。MBSE 在本体取向上的每一次推进，都在语义侧得分、在形式侧扣分——这正是核心论点的直接印证。

还得补一句，本体建模的代价并不止于个体认知负荷，更在于组织层面的"语义治理"开销。为了让模型真正稳定，组织必须维护一部共享的本体词典、设立本体评审角色、并在每次建模前先行"范畴对齐"。这套治理机制本身会消耗项目资源，且随项目规模超线性增长。其实，本体带来的语义稳定性是"可被购买的"，但其售价（治理成本、协调成本、培训成本）正落在形式侧的账上。当组织无力支付这笔价款时，本体建模往往退化为"名义上严谨、实际上无人遵守"的摆设——这反过来说明，零和不是通过"决心"就能绕过的，它同时是工程约束与组织约束。

3.5 形式语义之争：本章重点

MBSE 历史上最具代表性、也最能揭示核心论点的冲突，集中体现在 SysML 的形式语义之争上。本节是本章的重点，因为它把"形式编码 vs 语义编码"的张力压缩到了一个具体的版本演进决策之中。

3.5.1 SysML v1：语义松散与歧读空间

SysML v1（OMG，2007–2019；OMG，2019 的 1.6 版）建立在 UML 2 之上。然而，UML 的语义本身是非形式化的——Broy 与 Cengarle（2010）在《UML formal semantics》中系统指出，UML 的语义大量依赖自然语言描述，缺乏把每个构造精确映射为逻辑公式的形式语义。由于 SysML v1 直接复用 UML 的元模型与语义基础，这一根本缺陷被完整继承。

其后果体现在三个层面：

第一，同一图、多种读法。例如，SysML v1 的活动图（activity diagram）与序列图（sequence diagram）之间、以及活动图内部对"边（edge）"与"控制流（control flow）"的解释，标准并未给出唯一的形式化判定。两名合格建模者可能对同一张图给出不同的行为解释——语义稳定性↓。

第二，工具差异即歧义。因为语义未形式化，各工具供应商只能依据自己对标准的理解去实现，导致同一张 SysML v1 模型在工具 A 与工具 B 中呈现或解析出不同结果。Friedenthal 等（2014/2018）在实践指南中不得不反复提醒用户"注意工具间语义差异"，这本身即是稳定性缺失的旁证。

第三，高密度性与逻辑精准性双双受限。由于含义未被形式化，模型难以被机器自动推理，单位符号所承载的"可被验证的语义"稀薄——一张图看起来信息丰富，实则无法被精确检查是否自相矛盾。

SysML v1 的设计取向是明确的：它优先照顾形式侧——借由 UML 的庞大用户基础提升可习得性、借由 profile 机制提升可扩张性、借由图形直观性提升动态柔性。其代价，就是语义侧的全面让渡。

3.5.2 SysML v2 / KerML：严格形式语义的转向

SysML v2（OMG，2023）及其内核语言 KerML（OMG，2023）代表了一次方向性的修正。根据 OMG 2023 年新闻稿与规范，KerML 以一阶逻辑（first-order logic） 为语义基底，并引入 4D 时空外延（4D spatiotemporal extent） 的本体论立场——即把对象视为在四维时空中延展的个体（individuals that perdure through time），以此统一表达结构、行为与状态（Seidewitz，2023 是其形式语义的核心贡献者）。

这一转向带来语义侧的根本性增益：

• 逻辑精准性↑：语言每个主要构造都有可计算的形式语义，模型可被精确解析为逻辑表达式。

• 稳定性↑：因为含义由形式规则唯一确定，不再依赖人与人的默契，跨工具、跨人的歧读空间被大幅压缩。

• 高密度性↑：形式语义使得模型可内嵌可执行的约束与追溯，单位符号承载的可验证信息显著增厚。

同时，SysML v2 引入文本化、声明式的建模语法（区别于 v1 以图形为中心），并配套 Systems Modeling API & Services v1.0（OMG，2024）以标准化的方式访问模型，意图从机制上改善跨工具一致性。

需要指出，v2 学习成本的上扬并非偶然的"表述风格差异"，而是形式语义的内生要求：要理解一个 «block» 在 4D 外延立场下究竟是"在时空中延展的个体"还是"该个体的类型"，建模者必须接受一套与日常工程直觉不同的本体论视角；要写出可被一阶逻辑解析的约束，建模者必须习惯声明式而非过程式的思维。这套认知转换对习惯了方框—连线直观表达的工程师而言是一次范式迁移，其代价（可习得性↓）是形式语义红利（稳定性↑、逻辑精准性↑）的必然对价，而非实现阶段的过渡性困难。

3.5.3 权衡表：SysML v1 与 v2 的语义取舍

表 3.2 把这一章的核心争论浓缩为可对照的六性评价。它应当被反复回看，因为它是核心论点在真实标准演进中最凝练的投影。

表 3.2 SysML v1 与 SysML v2/KerML 的六性语义权衡

表 3.2 直观地告诉我们：SysML v2 并非"v1 的全面升级版"，而是在形式侧三性整体下滑的代价下，换得了语义侧三性的整体跃升。它不是解决了矛盾，而是用一侧的代价去支付另一侧的需求。任何把 SysML v2 描述为"各方面都更好"的叙述，都是对这一零和结构的误读。

3.6 可执行 MBSE：语义密度的代价

强化语义编码的另一种实践路径，是"可执行 MBSE（executable MBSE）"——让模型不再只是图纸，而能被机器求解、仿真与验证。本节展示：语义密度（高密度性）的提升，自有其沉重的支付账单。

3.6.1 参数图约束求解

SysML v1 的参数图（parametric diagram） 允许把工程约束（如质量平衡、能量守恒、可靠性分配）表达为模型中的约束块与绑定连接，从而让工具对参数进行求解（Dori，2016；Borky & Bradley，2018）。一旦约束被形式化表达，模型的高密度性显著提升：一个参数节点同时承载了物理量纲、数学关系与追溯链接。

3.6.2 仿真与形式化验证

更进一步，可执行 MBSE 将模型接入仿真引擎或形式化验证器：行为模型可被直接仿真以观察系统动态，关键性质（如"决不能发生死锁""安全状态必可达"）可被形式化证明（Harel & Politi，1998 的 Statechart 形式化、Schürr，1994 的图变换形式化为此类方法奠定理论基础）。Modelica（Modelica Association，2017）等面向物理系统的建模范式，同样体现了"模型即可执行方程"的语义密度取向。

3.6.3 代价：建模成本、工具依赖、专家稀缺

然而，语义密度（高密度性 + 逻辑精准性）的提升，其账单由形式侧支付：

其一，建模成本↑（可习得性↓）。要把一个领域问题形式化为可被求解的约束或可被验证的性质，建模者必须同时是领域专家与形式方法专家。普通系统工程师难以独立胜任，可习得性被严重拉低。

其二，工具依赖↑（动态柔性↓）。可执行模型高度绑定特定求解器/验证器，模型一旦离开该工具链，其"可执行语义"即告失效。动态柔性与工具无关性相互矛盾。

其三，专家稀缺（可扩张性↓）。能正确定义约束、解读求解结果、判断验证充分性的人才极为稀缺。这导致即便语言本身可扩张，组织层面也缺乏"能扩张的人"，可扩张性在实践上坍塌。

可执行 MBSE 因而呈现典型零和：它把语义侧推到高位，却把形式侧压到低位。它不是免费的午餐，而是一次明确的"以易用性换严谨性"的交易——再次印证核心论点。

3.7 互操作与可分享性：XMI/API 的脆弱性

MBSE 的承诺之一是"单一事实来源（single source of truth）"与跨团队、跨工具的可分享性（shareability）。但本节将指出：在互操作层面，形式侧的扩张自由与语义侧的稳定性再次短兵相接。

3.7.1 形式扩张性与语义稳定性的结构性矛盾

MBSE 模型的标准交换长期依赖 XMI（XML Metadata Interchange） 及其衍生物。XMI 的初衷是让模型能在工具间往返迁移。但现实是：由于 SysML v1 允许各工具通过自定义 profile、stereotype、tagged value 自由扩张（形式侧可扩张性↑），而这些扩张在 XMI 中往往缺乏跨工具一致的解释规则，导致"迁得出、读不准"——模型几何结构能迁移，语义却错位（Friedenthal 等，2014/2018 多次警示 XMI 互操作局限）。

形式扩张性（各工具自定义扩展）与语义稳定性（跨工具一致解释）在此处直接对抗：越是鼓励工具自由扩展，互操作时的语义保真度就越低。这正是零和取舍在"可分享性"维度上的投影。

SysML v2 配套推出的 Systems Modeling API & Services v1.0（OMG，2024）试图以标准化的编程接口取代脆弱的 XMI 文件交换，从机制上削弱"自定义扩展导致语义漂移"的空间。同时，OpenMBEE（2020s）等开源模型驱动工程环境也致力于以模型即服务（model-as-a-service）的方式保证语义一致性。这些努力方向正确，但其代价是：工具生态被更严格地约束，形式侧的自由扩张空间被迫收窄。也就是说，改善语义稳定性的努力，仍须以形式侧让渡为代价——零和关系并未被取消，只是被推到了新的平衡点。

3.8 贯穿例子：零和取舍的具象化

理论的说服力来自具体情境。本节用一个贯穿例子与两个反向例子，把前述所有抽象论述落到一次真实的工程决策上。

3.8.1 正向例子：为提升可追溯性与可验证性而引入更严格形式语义

设想一个航天型号研制团队，因既往项目频繁出现"需求—设计—验证"断层而痛定思痛，决定在 MBSE 实践中引入更严格的形式语义：采用 SysML v2/KerML，将每条需求形式化为可验证的性质，并把参数约束接入求解器（参照 NASA，2016 系统工程手册对追溯性的强调；INCOSE，2023 系统工程手册对模型可追溯性的要求）。

决策收益（语义侧↑）：

• 可追溯性↑：每条需求与下游设计、验证活动被形式化绑定，断链可被机器自动发现。

• 可验证性↑：关键性质可被自动检查，错误在早期发现，而非交付后爆发。

决策代价（形式侧↓）：

• 学习曲线↑（可习得性↓）：工程师须掌握一阶逻辑、4D 外延本体论与文本化建模语法，培训周期大幅拉长。

• 工具迁移成本↑（动态柔性↓）：既有 v1 工具链与资产需重写或转换，组织短期生产力下降。

• 领域专家参与度↓（可扩张性↓）：形式化门槛把多数领域专家挡在建模门外，模型逐渐由少数形式方法专家垄断，领域直觉的输入反而减少。

这正是一个教科书式的零和交易：组织用形式侧的"易用、易扩、易改"换取了语义侧的"可追溯、可验证"。它成功了，但成功是有代价的；它没有被"两全其美"，只是在曲线上选择了一个偏向语义侧的工作点。

3.8.2 反向例子一：为易学易扩而放宽语义，导致歧义与集成灾难

再设想另一团队，为追求快速上手与自由扩张，刻意选用语义最松散的配置：大量使用自定义 stereotype 与 tagged value，容许每张图"按个人理解"绘制，回避一切形式化约束（其底色正是 SysML v1 的语义松散，见 Broy & Cengarle，2010 对 UML 非形式化语义的批评）。

短期收益（形式侧↑）：团队上手极快、模型增长极快、各领域自由叠加词汇。

长期代价（语义侧↓）：当模型需跨团队集成、需交由另一工具仿真、需接受独立审查时，昔日的"自由"反噬为灾难——同一张图被不同方解读出矛盾含义（稳定性↓），参数无法被机器利用（高密度性↓），集成方不得不投入大量人力做人工澄清与返工。这正是 INCOSE（2021）"Vision 2035"与 DoD（2018）"Digital Engineering Strategy"所警示的"模型看似繁荣、实则不可信"的典型病灶。

3.8.3 反向例子二：本体过严导致形式侧坍塌

第三个例子走向另一极端：某组织为追求极致语义稳定，引入极重度的本体约束与形式化验证流程。结果（语义侧↑）模型含义高度一致、错误极少；但（形式侧↓）工程师怨声载道、扩张一项新需求需数周本体评审、模型演化迟缓到跟不上研制节奏。当形式侧被压到临界点以下，MBSE 反而失去了"随系统柔性演化"这一系统工程最核心的本领——此时语义的严谨已失去意义，因为模型已经追不上现实。

三个例子首尾相接，共同指向同一结论：无论偏向哪一侧，都不存在让六性同时达优的终极体系；每一次"改进"，都是在一侧增益、另一侧付出。

3.9 小结：零和结构的不可逃逸性

本章以"符号系统必然在形式编码与语义编码之间做不可逆的零和取舍"这一核心论点为主线，完成了对 MBSE 语义基础与形式化张力的系统剖析。

我们从概念基石出发（3.2 节），区分了形式编码三性（可习得性、可扩张性、动态柔性）与语义编码三性（稳定性、高密度性、逻辑精准性），并给出可操作的判别指标，使张力可被度量。

随后，五个维度逐一验证了零和结构的现实存在：元模型四层架构与 profile 机制以语义稳定为代价换取形式扩张（3.3 节）；本体建模以形式易用为代价换取语义稳定（3.4 节）；SysML v1 与 v2/KerML 的版本之争，是形式侧整体让位于语义侧整体的最凝练投影（3.5 节）；可执行 MBSE 以建模成本、工具依赖与专家稀缺为代价换取语义密度（3.6 节）；XMI/API 互操作则在形式扩张性与跨工具语义稳定性之间再度短兵相接（3.7 节）。

贯穿例子（3.8 节）进一步证明：当零和取舍落到具体决策，它呈现为"为可追溯/可验证而付出学习曲线与工具迁移成本"的正向交易，以及"为易学易扩而招致歧义与集成灾难""为本体过严而导致形式侧坍塌"的反向交易。

由此可得出贯穿全书的判断：

MBSE 的每一次"改进"都是在一侧增益、另一侧付出；不存在让六性同时达优的终极体系。所谓"更好的 MBSE"，永远只是"在给定约束下选择了某一工作点"，而非"消除了矛盾"。

这一判断为后续章节奠定了不可动摇的理论框架：

• 第5章讨论 MBSE 的局限性时，我们将看到，所谓"局限"大多不是工程疏忽，而是零和结构在形式侧或语义侧的必然代价——它们无法被"更努力地实现"所消除。

• 第6章梳理方法学争议（如"图形优先还是文本优先""宽松语义还是严格语义""本体驱动还是实践驱动"）时，我们将看到，这些争议的本质是不同组织在零和曲线上选择了不同工作点，因而没有哪一方能被证伪。

• 第7章展望未来（如 SysML v2 普及、数字孪生、模型即服务）时，我们将看到，任何技术演进都只能把平衡点推向新的位置，而绝不可能取消零和本身。

理解这一点，正是理解 MBSE 全部历史、分歧与边界的钥匙。本书此后所有论证，都建立在本章所立之框架之上。

第4章 MBSE 的发展趋势

4.1 引言：趋势不是终点，而是取舍曲线上的一次次再平衡

本书贯穿始终的核心论点是一个冷峻的判断：任何符号系统都必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做出不可逆的零和取舍，不存在能够完美兼顾两者的终极体系。MBSE 作为符号系统在工程领域的一个典型且高度自觉的实例，其全部历史演进、方法分歧与能力边界，最终都可归结为这一根本性张力。越是强化形式编码一侧，让建模语言更易于习得、更易于扩张、更能随需求柔性演化，就越不可避免地削弱语义编码一侧，使语义不够稳定、信息密度被稀释、逻辑校验趋于失准；反之，越是追求语义编码的严谨，赋予模型以形式化语义、使之可执行、可机器验证，就越要牺牲形式编码的可习得性与可扩张性。

本章的任务，是沿着这一核心论点审视 MBSE 当下与可预见未来的若干主要发展趋势。需要预先声明的是：本章不持"进步主义"的乐观预设。在逐一考察数字工程、数字孪生、敏捷化、AI/ML 融合、SysML v2 与 KerML、开源互操作生态、基于模型的验证与确认（MBV&V）以及形式化方法下沉等趋势之后，我们将反复确证一个结论——这些趋势没有一项构成对零和取舍的"终结"，它们无一例外都是对该取舍在某一个局部、某一种约束下的再平衡，是在取舍曲线上向某个更优折中点的移动，而非对曲线本身的超越。前沿的每一次推进，都只是在"这一侧多一点"与"那一侧少一点"之间重新划定临时的边界。

为便于后文对照，本章先将七类趋势在编码侧重上的取向归纳为一张总表，并在各节中逐一展开论证。

表 4.1 主要趋势在形式编码—语义编码取舍上的侧重取向

表 4.1 的每一行都将在后文得到展开。需要强调的是，这张表的读法不是"这些趋势各有利弊"式的平庸平衡术，而是"每一项趋势都重新配置、但从未取消零和取舍"这一论断的证据链。

4.2 数字工程（Digital Engineering）与数字主线（digital thread）：权威模型的制度化

4.2.1 从文档权威到模型权威：DoD 2018 战略的制度转向

美国国防部于 2018 年发布的《数字工程战略》（Digital Engineering Strategy）是 MBSE 制度化进程中的一个分水岭事件（DoD，2018）。该战略明确提出以"权威的数字模型"作为工程活动的中心，将模型从辅助性的沟通工具提升为权威事实来源（authoritative source of truth）。在此之前，系统工程长期依赖文档作为权威载体：需求写在文档里，设计体现在图纸与说明书中，验证证据分散在报告与记录里。文档权威模式的弊病在于，文档本质上是离散的、静态的、语义隐含的——它属于形式编码极弱而语义又高度依赖读者解读的制品，难以被机器一致地解析、追踪与校验。

数字工程战略的制度化转向，实质上是一次大规模的形式编码投资：通过建立贯穿采办全生命周期的数字工程环境与数字主线，使模型成为可被计算、可被集成、可被追溯的对象。从核心论点的视角看，这一转向的第一性动机恰恰落在形式编码一侧——它要让模型"可集成"（跨工具、跨阶段的数据连通）、"可更新"（随需求与设计的演化而持续修订）、"可习得"（以标准化模型取代非结构化文档，降低理解门槛）。模型作为权威事实来源的制度化，意味着符号系统被要求承载更高的工程责任，而这只有在形式编码足够规整、足以被系统化处理时才可能成立。

4.2.2 数字主线作为形式编码的"连通性"工程

数字主线（digital thread）是支撑上述制度化转向的关键使能概念。早期关于数字主线的权威定义可追溯到 Hedberg 等（2016）在 NIST 的研究，他们将数字主线描述为一种连接工程、制造与检验各环节的集成信息流，其目标是实时设计分析、协同流程开发、自动化制品生成与全流程可追溯性。后续的文献综述进一步将其概括为"以权威数据源（需求、系统架构、技术数据包、三维 CAD 模型等）为节点，连接产品全生命周期各阶段的集成信息流"（见相关文献综述，无 DOI，官方综述见出版社页面）。数字主线与 MBSE 的关系在此显得尤为紧密：MBSE 提供的系统模型，正是数字主线赖以编织的语义骨架之一。

从编码取舍的角度审视，数字主线工程在本质上是一次形式编码的"连通性"工程。它不主要关心单个模型内部的语义有多么致密或形式化，而更关心模型与模型之间、模型与下游制造/运维数据之间，能否以稳定、可机读、可重用的方式相互引用与同步。换个说法，数字主线优先满足形式编码中的"可扩张性"（纳入更多异构数据源）与"动态柔性"（随生命周期推进持续追加与更新数据）。这种连通性诉求，与本书核心论点中形式编码的定义高度吻合。

4.2.3 制度化的代价：当权威模型成为单点语义事实来源

然而，把模型推到权威中心位置，绝非没有代价。权威模型的制度化意味着：一旦模型出错、被误解或语义漂移，错误将以最高的权威性在整个工程链条中被放大与传播。这里暴露的正是零和取舍的另一侧——语义编码侧的隐性压力。形式编码越是成功地让模型"可集成、可更新、可习得"，模型作为单一事实来源所承担的语义责任就越重；而语义编码一侧的"稳定性"与"逻辑精准性"并未因为制度化而自动提升，反而因模型被广泛复用而变得更为关键、也更为脆弱。

更绕一层，数字主线在追求跨阶段、跨工具连通时，往往要吸纳大量异构、低结构化或半形式化的数据源。这些数据接入主线后，若缺乏严格的语义约束，便会以"权威"之名携带语义噪声流动。于是出现一种反讽性的局面：形式编码的连通性越强，潜在的语义稀释风险越高。这正是核心论点在制度层面的投影——强化形式编码一侧（连通、集成、更新），并不等于语义编码一侧（稳定、致密、精准）同步变强，二者在资源、约束与工程注意力分配上彼此争夺。数字工程与数字主线因此不是零和取舍的终结者，而是把它从"单个模型内部"推进到了"跨模型、跨生命周期"的尺度上重新上演。

进一步看，权威模型的制度化还带来一个常被忽视的第二层代价：可追溯性与语义碎片化的并存。数字主线承诺端到端可追溯，使任意一条需求都能追溯到设计、分析与验证记录。但可追溯性本身是一项形式编码工程——它要求链接结构规整、可被机器遍历，并不自动担保被链接内容的语义正确。当主线为了纳入更多参与方与数据源而放宽语义约束时，便可能出现"链接齐全而语义断裂"的怪象：形式上每一处都可追溯，实质上每一处都可能在各自局部语境中被不同地理解。这种"形式完备、语义空虚"的状态，正是形式编码被强化而语义编码被稀释的典型症候，也再次说明制度化并未超越取舍，只是把取舍的张力更深地编织进工程治理的结构之中。

4.3 数字孪生（Digital Twin）：高保真语义与可集成形式编码的再平衡

4.3.1 孪生体的语义保真诉求

数字孪生概念由 Grieves（2014）在 NASA 相关白皮书中系统提出，后被 Madni 等（2019）明确引入 MBSE 语境，主张借助孪生技术将物理系统的实时行为与系统模型闭环耦合。数字孪生对 MBSE 提出的第一类诉求是语义保真：孪生体要如其物理对应物一般，在几何、物理、行为与状态维度上可被高保真地映射与仿真。这种保真，对应本书核心论点中语义编码的"高密度性"与"稳定性"——模型必须承载足够致密、足够可靠的信息，才能替代或近似真实系统的运行状态。

4.3.2 MBSE 与物理仿真的闭环：形式编码的"可更新性"压力

与高保真语义诉求并存的，是孪生体必须持续从物理世界吸纳传感器数据、工况数据与演化数据，并在模型侧做出更新与重仿真。这一闭环对形式编码提出了强烈的"可更新性"与"可集成性"要求：模型必须能够方便地接入外部数据流、方便地与其他仿真与制造工具交换数据、方便地在生命周期中持续演化。Madni 等（2019）所描绘的 MBSE 与数字孪生融合，正是希望把系统模型从静态的"设计快照"转变为可随物理实体持续同步的"活模型"。

4.3.3 再平衡中的零和痕迹

将上述两类诉求并置，零和取舍的痕迹立刻显现。孪生体的语义保真，要求模型内部保持高密度的、经得起推敲的语义约束，这天然倾向于语义编码侧；而持续的、跨工具的数据接入与更新，要求模型对外保持宽松、灵活、易于扩张的形式接口，这天然倾向于形式编码侧。二者在同一模型上同时被推向极致时必然相互掣肘：提高语义保真会增加模型被外部数据更新的难度（因为每一次更新都必须通过更严格的语义校验，否则就会破坏保真前提）；而放宽形式接口以追求可更新性，又会削弱语义约束的严谨，使孪生体偏离"高保真"的初衷。

因此数字孪生并非把 MBSE 从取舍中解放出来，而是在"高保真语义 ↔ 可集成可更新形式编码"这一对子张力上做了一次新的再平衡。不同应用领域按照自身风险偏好落点不同：航空航天与核电等高后果领域，会更偏向语义保真一侧，容忍更新的迟滞与接口的严格；而快速迭代的消费电子或软件密集型系统，会更偏向可更新性与可集成性一侧，容忍语义保真度的相对下降。无论落点在哪，取舍曲线本身岿然不动。

另外要补上，数字孪生还把零和取舍延伸到"时间维度"上：物理实体的状态随时间持续演化，孪生体若要保持保真，就必须以足够高的频率与足够严谨的语义把演化吸收进模型；而高频更新在形式编码上意味着更宽松、更自动化的同步机制，在语义编码上却意味着每一次吸收都可能引入未被察觉的语义偏移。于是孪生体的"新鲜度"与"可信度"构成一对随时间而动的取舍：新鲜度偏向形式编码的可更新性，可信度偏向语义编码的稳定性。这一时间维度的再平衡，进一步说明数字孪生非但不是取舍的终结，反而是取舍最活跃、最持续的展演场之一。

4.4 MBSE + 敏捷（Agile）：动态柔性对语义稳定的冲击

4.4.1 增量建模与迭代架构

敏捷思潮从软件开发外溢至系统工程，催生了 MBSE 与敏捷方法的融合探索。Douglass（2009）所倡导的 Harmony/ESW 方法论早已在实时与嵌入式系统开发中尝试以迭代、增量的方式组织建模活动。增量建模主张系统模型不必一次性完备，而是随每个迭代逐步生长；迭代架构则允许在获取新认知后回退、修订与重构既有模型。这种实践对形式编码的"动态柔性"与"可扩张性"构成了正面强化——模型要能随需求变化而柔性演化，要能从小规模原型平滑扩张为完整系统描述。

4.4.2 系统工程 V 模型的内在张力

然而，传统系统工程以 V 模型为骨架，强调左侧自顶向下的需求分解与右侧自底向上的验证确认之间的严格对应与可追溯性（见 ISO/IEC/IEEE 15288:2015 所刻画的生命周期过程框架，A4）。V 模型的内在假设是：存在一条相对稳定、可在前期被相对充分锁定的语义基线，后续所有验证都对照这条基线进行。敏捷的增量与迭代，恰恰在不断移动这条基线。于是 MBSE + 敏捷面临一个结构性张力：V 模型要求的语义稳定性，与敏捷要求的动态柔性，在同一工程时间轴上彼此拉扯。

4.4.3 柔性即形式编码诉求，稳定即语义编码诉求

用本书核心论点的语言来翻译，上述张力就是零和取舍在工程节奏维度的直接显现。"动态柔性"是形式编码三项属性之一，"稳定性"是语义编码三项属性之一。MBSE + 敏捷越是成功地把柔性注入建模过程，系统模型的语义基线就越频繁地漂移，逻辑精准性所依赖的稳定参照系就越容易被扰动。反过来，若为了确保语义精准而冻结基线、收紧变更控制，敏捷所承诺的响应速度与演化能力便被削弱。

该看到的是，这种张力并非不可管理——许多组织通过"分层冻结"（架构层稳定、实现层敏捷）等折中手段来缓和它。但折中手段本身恰恰证明取舍仍在：被冻结的语义层获得了稳定性，却牺牲了柔性；被放开的实现层获得了柔性，却承受语义漂移。MBSE + 敏捷因此不是取舍的消解，而是把它重新配置到"层级"与"节奏"的维度上。

还需指出，敏捷化对形式编码的偏好，往往与一线团队的现实约束相耦合：建模人力稀缺、交付节奏紧迫时，组织天然倾向于选择更易扩张、更易上手的建模方式，即偏向形式编码侧。这种选择本身是理性的，但它把语义精准性的保障推到了开发的后期乃至验证阶段，从而把"前期语义宽松、后期语义补救"的成本结构固定下来。说白了，敏捷不是消除了零和取舍，而是把取舍的显性时刻从设计初期推迟到了集成与验证期，使代价以更集中、更晚暴露的方式呈现。这也解释了为何许多实践者在引入敏捷 MBSE 后，反而更强烈地感受到对形式化验证（见 4.8 节）的依赖——因为柔性所让渡出的语义稳定，最终仍需以另一种工程成本补回。

4.5 AI/ML 与 MBSE 的融合：形式编码柔性的跃升与语义精准的稀释

4.5.1 生成式建模与自动需求生成

人工智能尤其是大语言模型（LLM）的兴起，为 MBSE 注入了前所未有的形式编码柔性。Crabb 与 Jones（2024）在 IEEE 系统之系统会议上的实证研究让一组系统工程师在 LLM 辅助下完成需求列表与用例图建模，结果显示 LLM 虽不能替代训练有素的系统工程师，却能在极短时间内生成构建最小可用产品（MVP）模型所需的大部分信息，并显著降低外部调研耗时（DOI: 10.1109/SOSE62659.2024.10620975）。Longshore 等（2024）进一步探索用生成式 AI 生成、修改与查询 SysML v2 模型，并借助检索增强生成（RAG）注入领域知识以提升准确性（无 DOI，PDF 见 Naval Postgraduate School 国防采办创新知识库）。另有研究从自然语言处理角度提出，将非结构化文档自动转化为需求与 SysML 模型元素，以降低 MBSE 的应用门槛（Patel 等，2024，DOI: 10.1109/SPACE63117.2024.10667868）。

这些工作的共同指向，是大幅强化形式编码一侧的"可习得性"与"可扩张性"：建模不再要求从业者从零掌握繁复的图形语法，模型可以对话式地生成、以自然语言驱动地扩张。从可扩张性看，AI 使模型规模与覆盖面的扩展不再线性受制于人类建模师的工时。

4.5.2 自动一致性/冲突检查与知识抽取

除生成之外，AI/ML 还被用于自动一致性检查、冲突发现与知识抽取。需求工程领域已有系统性文献综述表明，生成式 AI 在需求抽取、不一致性自动检测、将需求翻译为时序逻辑等形式表示方面展现出广泛潜力（arXiv 综述，无 DOI，官方见 arXiv:2409.6741）。这类应用试图把一部分本属于语义编码侧的校验负担，转移给机器学习模型来部分承担，从而在形式上提升了模型的一致性与可追溯性。

4.5.3 核心论点的锋刃：AI 放大形式编码柔性，却引入语义漂移与不可解释性

然而，恰恰是这一趋势最锋利地验证了本书核心论点，也最容易被进步主义叙事所遮蔽。AI 对 MBSE 的贡献，几乎全部落在形式编码一侧——自动生成使建模更易扩张、更易习得，对话式交互使模型更能柔性演化。但与此同时，生成式模型的内在机理决定了它并不"理解"其产出背后的工程语义：LLM 基于统计相关性生成看似合理的文本与模型片段，却无法为每一条生成内容提供可追溯、可验证的语义依据。Crabb 与 Jones（2024）自己也承认 LLM 并非系统工程师的替代品，其产出仍需专家评判；Longshore 等（2024）明确指出生成式 AI 工具"易犯多种错误"，并讨论了 LLM 的局限性。

这就意味着：AI 在提升形式编码柔性的同时，可能引入语义漂移（生成内容在工程语义上偏离真实意图却表面流畅）与不可解释性（无法证明生成模型的逻辑正确性）。用核心论点的术语说，形式编码侧的"可扩张性、可习得性、动态柔性"被显著抬高，语义编码侧的"稳定性、高密度性、逻辑精准性"却被同步稀释。这是一次典型且剧烈的零和移动，而非取舍的取消。更棘手的是，AI 生成内容的表面流畅性会掩盖语义缺陷，使稀释后的语义精准性更难被察觉——这恰恰是零和取舍中最危险的一种形态：一侧的增益以另一侧隐性、延迟暴露的代价呈现。

因此，AI/ML 与 MBSE 的融合不是超越取舍的灵丹，而是把取舍曲线推向"形式编码极度宽裕、语义编码高度承压"这一新区域。能否用好它，取决于是否配套以更强的语义护栏（形式化校验、人工在环、可追溯性约束），而这些护栏本身又往往以牺牲一部分形式编码柔性为代价。取舍仍在，只是换了舞台。

需要特别澄清一种常见的误读：有人主张，只要让 AI 在生成后做自我校验、或让多个模型互相投票，便能同时保住形式编码的柔性与语义编码的精准。但自我校验仍建立在同一个统计生成机制之上，其"信心"并不等价于工程意义上的"正确"；多模型投票至多收敛于训练分布内的共识，而无法担保超出分布的真实系统语义。换种讲法，AI 内部的"语义"是语料层面的相关性语义，而非工程层面的因果与约束语义，二者之间存在本质鸿沟。这条鸿沟恰恰就是零和取舍在智能时代的具象化——我们用相关性语义的宽裕，换取了因果约束语义的承压。指望用形式编码侧的技术进步（更大的模型、更好的提示）来单方面填平这条鸿沟，是对取舍结构本身的误认。

4.6 SysML v2 / KerML：语义精确化与互操作前景

4.6.1 形式语义与一阶逻辑内核

SysML v2 及其底层内核语言 KerML，是 MBSE 语言演进中一次明确的、方向性的语义编码强化。依据 OMG 规范，SysML v2 于 2023 年发布 Beta 2 规范，并已于 2025 年 7 月正式采纳（OMG，2023/2025）；KerML 作为其内核，以一阶逻辑与四维时空外延（4D 时空）方式表述形式语义（OMG，2023/2025；Seidewitz，2023 相关提交材料）。这一设计取向，直接对应本书核心论点中语义编码的"逻辑精准性"：模型不再只是图形约定，而是拥有可被严格解释、可被机器推理的形式语义。

4.6.2 标准 API 与跨工具集成

SysML v2 的另一重要进展，是配套定义了标准化的建模 API 与服务（Systems Modeling API & Services, OMG，2024），使模型可以以结构化、可编程的方式被不同工具读写与集成。这在形式编码的"可扩张性"与"可集成性"上确有所补益——它降低了工具锁定，使模型数据能够在异构环境中流动。从互操作前景看，这是 MBSE 走向"模型即数据"的关键一步。

4.6.3 精确化的反方向代价：可习得性与可扩张性的让位

但我们必须诚实指出：SysML v2 / KerML 的语义强化，是以形式编码侧的"可习得性"与部分"可扩张性"为代价的，这再度印证了零和取舍。一阶逻辑内核与 4D 时空外延的引入，使语言的形式语义空前严谨，却也显著抬高了学习门槛：建模者需要理解更抽象的语义基础，才能正确使用语言。对广大工程实践者而言，这意味着从"画得出来"到"写得正确"之间的鸿沟被拉大。

其实，SysML v2 把取舍曲线向语义编码侧移动了一大步——它换来的是可机器验证、跨工具一致、逻辑精准；让渡出去的，是早期 SysML v1 相对宽松、易上手、易快速扩张的形式友好性。这一取舍并非缺陷，而是定位选择：当工程后果足够严重（如航天、国防、核电），牺牲可习得性换取语义严谨是理性且必要的。但它同样不构成对零和取舍的超越——它只是把平衡点挪到了另一处。值得警惕的是，若把语义精确化误读为"万能解"，便会忽视其在大规模、快节奏、跨专业协作场景下面临的可习得性瓶颈：当大多数参与者难以真正掌握严谨语义时，形式语义的潜在收益反而无法落地，甚至因误用而制造新的、更隐蔽的语义错误。

这里还隐含一个常被低估的二阶效应：语义精确化的收益高度依赖"整个工具链与组织都真正贯彻同一套形式语义"。一旦生态中仍有大量工具仅部分支持、或对规范做各自的解读，形式语义的严谨性便会在接口处被打折，而严谨性一旦在某一处打折，其"可机器验证"的整体承诺就被削弱。于是，越是追求语义精确，越需要强大的生态一致性与治理投入，而这笔投入本身又挤压了形式编码侧可自由扩张的空间。SysML v2 的精确化不是免费午餐，它把取舍从"语言内部"转移到了"语言与其生态的一致性治理"之上，曲线依然存在，只是担保责任的落点变了。

4.7 开源与互操作生态：开放性的编码博弈

4.7.1 OpenMBEE 与 SysML v2 API & Services

开源与互操作生态是 MBSE 民主化的另一支重要力量。OpenMBEE（Open-source Model-Based Engineering Environment，2020s 开源项目，无 DOI，官方见 openmbee.org）致力于提供开放式、可集成的模型工程环境；它与 SysML v2 标准 API 相互呼应，推动模型数据在工具链之间自由流动。此类努力的第一性目标，是强化形式编码的"可扩张性"与"可习得性"——开放降低了工具与许可门槛，使更多组织与个人能够参与建模、扩展模型、贡献工具。

4.7.2 开放性（可扩张、可习得）与语义一致性的关系

然而开放性的代价，同样落在语义编码侧。当模型数据可以在更多工具、更多主体、更多自定义扩展之间自由流动时，语义一致性的维护难度随之上升。每个工具、每个团队都可能对同一模型元素施加自己的解释与扩展，若缺乏统一且被严格执行的形式语义约束，开放生态便会成为语义漂移的温床。这里再次呈现核心论点的轮廓：开放性强化形式编码（可扩张、可习得），却对语义编码（稳定性、高密度性、逻辑精准性）构成压力。

需要说明，这种压力并非注定失控——SysML v2 的形式语义与标准 API 正是为在开放环境中"锚定"语义而设计的，二者在方向上存在互补。但互补不等于抵消：形式语义提供了锚，而锚能否被所有参与者真正遵循，仍取决于学习成本与工程纪律，而这两者在开放、低门槛的生态中恰恰最容易被稀释。因此，开源与互操作生态是取舍曲线向"开放—扩张"一侧的再平衡，它让 MBSE 更可习得、更可扩张，却把语义一致性的保障责任从"语言强制"更多转向"社区与工具链纪律"，这是一种责任的转移，而非取舍的消除。

可以举一个具体的张力点来说明：开源社区的活力来自低门槛的贡献与快速的方言式扩展，某一团队可能为特定领域发明一套便利的模型约定；这种便利性正是形式编码可扩张性的体现。但若该约定未被纳入统一的形式语义并被工具链一致解释，它在跨团队流转时便会产生语义歧义。社区若要消除歧义，要么把约定上升为标准（重新付出可习得性与治理成本），要么放任其作为"方言"存在（重新承受语义漂移）。无论哪条路，都要为形式编码的扩张支付语义编码的代价。开源生态因此并非取舍的对立面，而是把取舍日常化、分布式地持续重演于每一次贡献与每一次集成之中。

4.8 基于模型的验证与确认（MBV&V）与形式化方法"下沉"

4.8.1 从文档审查到模型验证

基于模型的验证与确认（MBV&V）把传统以文档为对象的评审、审查与确认活动，迁移到模型自身之上。其优势是直观的：当模型成为权威事实来源（回到 4.2 节的数字工程逻辑），验证便可针对模型而非其文档化投影进行，从而提高逻辑精准性与可追溯性。形式化方法（如模型检测、定理证明、约束求解）的"下沉"，即从其长期盘踞的学术与高保障细分领域，向一般工程实践渗透，正是 MBV&V 追求语义严谨的自然延伸。

4.8.2 形式化方法下沉的工程代价

但形式化方法的下沉，同样服从零和取舍。形式化验证越是严格，对模型语义编码的要求越高——模型必须被充分形式化、约束必须被显式表达、验证目标必须被精确刻画。这一切都指向语义编码的"逻辑精准性"，却同时抬高了形式编码侧的工程成本：建模者需要更专业的训练（可习得性下降），模型构建与维护更耗时（动态柔性下降），工具链更复杂（可扩张性的隐性受限）。Huldt 与 Stenius（2019）对 MBSE 实践状态的调研（DOI: 10.1002/sys.21466）以及 Henderson 与 Salado（2021）对 MBSE 价值证据的系统性回顾（DOI: 10.1002/sys.21566）都提示，MBSE 乃至其验证活动的收益，高度依赖于组织成熟度与配套投入，而非自动兑现。

因此 MBV&V 与形式化下沉，是把取舍曲线向"语义可验证"一侧推动的又一步。它提升了逻辑精准性与稳定性，却以工程可操作性与可习得性为代价。它同样不是终点：在严苛安全关键领域，这一折中显然值得；在快速迭代的民品领域，过度形式化反而可能因成本与门槛而难以落地。取舍的临边界限，随领域与组织能力而移动，但曲线本身不曾消失。

还可观察到，MBV&V 与 AI/ML 趋势之间存在着一种有趣的"对冲"关系：AI 在形式编码侧放大了语义漂移，而 MBV&V 正是为补回语义精准而被强化。于是前沿实践常常出现这样的组合——用 AI 快速生成大量候选模型（形式编码宽裕），再以形式化验证严筛其正确性（语义编码收紧）。表面看这是"两全"，实则仍是取舍的序列化：先在一侧放手，再在另一侧收紧，总代价并未消失，只是被拆分到两个相继的工程阶段，并由两套不同的工具与团队分别承担。这种"生成—验证"的分工，恰是零和取舍以流程而非单点方式呈现的当代形态，它进一步佐证了核心论点：趋势之间可以互相补偿，却无法互相取消取舍。

4.9 趋势总结：取舍曲线的再平衡，而非超越

本章逐一考察了 MBSE 的七类主要发展趋势，并发现它们可以整齐地归入同一分析框架：每一趋势都是形式编码与语义编码之间零和取舍的一次局部再平衡，没有任何一项构成对取舍的终结。现以总表收束前文（表 4.2 为表 4.1 的凝练复述，便于总览）。

表 4.2 七类趋势的编码取舍归结

回到本书核心论点：符号系统的零和取舍是不可逆的、结构性的。MBSE 作为符号系统的工程实例，其演进史不是一部不断逼近"完美体系"的史诗，而是一连串在形式编码与语义编码之间反复权衡、不断移动折中点的工程决策史。数字工程把模型推上权威中心，是用形式编码的连通性去搏取语义责任的集中；数字孪生在保真与可更新间两难；敏捷以柔性换稳定；AI/ML 以惊人的形式编码柔性放大了语义漂移的风险；SysML v2 / KerML 反过来以可习得性的牺牲换取语义严谨；开源生态以开放性扩张换取语义一致的脆弱；MBV&V 以工程成本换取逻辑可验证。

由此可见，所谓"前沿趋势"，其真实含义不是"我们正在接近终极解"，而是"我们正在取舍曲线上寻找更优、更适合当下约束的折中点"。未来可能涌现新的技术——更强大的形式化内核、更可控的生成式 AI、更智能的语义护栏——它们会改变曲线的局部形状，会让某些折中变得更廉价、更可承受，但无法取消曲线本身。只要 MBSE 仍是一种以符号为载体、既要求人能习得与扩张、又要求机器能严谨解释与验证的工程实践，形式编码与语义编码的零和张力就会持续存在，并继续塑造它的每一次演进。承认这一点，不是悲观，而是为所有关于 MBSE 的能力宣称提供一副诚实的、可用于权衡的透镜：当我们为一个趋势欢呼时，应当同时追问——它强化了哪一侧，又让渡了哪一侧，以及这份让渡，我们是否真正付得起。

第5章 MBSE 的局限性

贯穿本书的核心论点是：符号系统必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做不可逆的零和取舍，不存在完美兼顾的终极体系。MBSE 作为符号系统在工程领域的典型实例，其全部历史演进、方法分歧与能力边界，均可归结为这一根本性张力：越是强化形式编码一侧，就越削弱语义编码一侧；反之，越是追求语义编码的严谨，就越牺牲形式编码的可习得性与可扩张性。

本章并不意在否定 MBSE 的价值。恰恰相反，本章要论证的是：MBSE 之所以存在一系列被广泛诟病的"局限性"，并非源于从业者的方法失误、工具落后或组织懈怠，而是上述零和取舍在不同工程场景下必然外显的具体投影。换个说法，MBSE 的局限性是符号系统本质张力的"症状"，而非"病因"。只有把每一项局限性还原到"形式编码↔语义编码"的权衡坐标上，我们才能既不盲目神化 MBSE，也不将其局限误判为可通过"更加努力"而消除的工程缺陷。

下面依次剖析 MBSE 在九个方面的局限性，并在每一节中明确指出：该局限究竟对应形式编码一侧的扩张代价，还是语义编码一侧的强化代价。

5.1 学习曲线陡峭与人才稀缺

5.1.1 习得成本的来源：形式编码可习得性的坍塌

MBSE 的核心载体是建模语言，而工业界事实上的主流语言是 SysML（Systems Modeling Language）。SysML 以 UML 为母体并针对系统工程的语义需要扩展而来，其体量本身就构成了一道习得门槛。在 SysML v1 中，语言定义了九种图（用例图、活动图、序列图、状态机图、模块定义图、内部块图、参数图、需求图、包图），每种图又承载了复杂而相互交叠的元模型约束（Friedenthal 等，2014/2018）。当一门符号系统试图同时覆盖需求、结构、行为、参数与验证等多重维度时，其形式编码侧的可习得性必然下降——因为"覆盖广度"本身正是形式扩张性的体现，而扩张性每前进一步，初学者需要掌握的符号规则、图形语法与语义约束就成倍增长。

这一点在形式化语言的文献中早有定论：强表达力的符号必然带来更高的学习成本（Holt 等，2011/2012）。MBSE 的困境在于，它既想做"系统工程的全景语言"（形式扩张性↑），又希望工程师能快速上手（可习得性↑），而二者在此处构成零和。Dori（2016）在比较 OPM 与 SysML 时亦指出，SysML 的图类型繁多、元模型厚重，使其"易学性"显著弱于以单一对象过程图为核心的 OPM 范式。但 OPM 之所以更易学，恰恰是因为它在形式上做了大幅收敛（扩张性↓），代价是表达密度与对复杂工程约束的覆盖能力相对受限——这正是零和取舍的另一种呈现。

具体到工程实践，习得成本可被进一步拆解为三个递进层次：第一层是"语法层"，即掌握九种图的图形元素与连接规则，经验丰富的建模者通常需数周集中训练方能熟练；第二层是"方法论层"，即理解 OOSEM、Arcadia、Harmony-SE 等特定方法如何将图组织为分析流程，这往往需要参与至少一个完整项目周期才能内化（Estefan，2008；Roques，2016）；第三层是"领域建模判断力"，即知道何时该用参数图表达约束、何时该用状态机图刻画行为模式，这只能在跨多个系统的反复实践中形成。三层叠加，使一名合格 MBSE 建模师的养成周期常以"年"计，而非以"月"计。这种层级递进本身说明：可习得性的坍塌不是单一缺口，而是形式扩张性在多个维度上同时索取的学习成本。

值得强调的是，习得成本不只是"学语法"的成本，更是"学思维方式"的成本。MBSE 要求工程师从以文档为中心（document-centric）的线性叙述，转向以模型为中心（model-centric）的多视图约束网络（Borky & Bradley，2018）。这种思维范式的迁移，本质上是让工程人员放弃自然语言写作的直觉，转而接受一套人工符号系统的形式规则——而任何人工符号系统在强可习得性（接近自然语言直觉）与强形式性（脱离自然语言直觉）之间，都只能取其一端。

5.1.2 组织培训负担与人才稀缺的结构性

习得门槛在组织层面被放大为培训负担与人才稀缺。Madni & Sievers（2018）在综述中明确将"陡峭的学习曲线"与"缺乏训练有素的人员"列为 MBSE 采纳的主要障碍。该文指出，MBSE 的导入并不仅是购买工具，而是涉及方法论、语言、工具链与组织流程的系统性重构，组织需要投入可观的培训周期才能使团队达到基本生产力。

这种负担具有结构性而非偶发性。系统工程从业人员中，长期接受的是以文本规范、接口控制文档（ICD）、故障树分析（FTA）等文档化方法训练的工程文化（INCOSE，2023）。当他们被要求转向图形化、形式化的建模实践时，组织面临双重成本：一是现有人员再培训的时间与机会成本；二是合格建模人才的市场稀缺导致的招聘溢价。Borky & Bradley（2018）在其实务著作中反复强调，有效 MBSE 的瓶颈往往不是工具功能，而是"能够把工程意图正确形式化为模型"的人的稀缺。

把这一现象放回核心论点来看：人才稀缺并非管理失当，而是可习得性↓这一编码侧代价的组织投影。当符号系统在形式编码侧为了追求广覆盖而牺牲可习得性，它就自动制造了一个"只有少数人能驾驭"的精英化门槛。若要降低门槛（可习得性↑），就必须收敛形式扩张性（接受更弱的表达力）——这正是许多轻量级方法（如 SYSMOD 的简化实践、部分团队仅采用 SysML 子集）所不得不做的妥协，而该妥协本身就是零和取舍的再次确认。

5.2 工具锁定与互操作脆弱

5.2.1 专有格式与 vendor lock-in

MBSE 的工程价值依赖于建模工具，而主流商业工具（如商业 SysML/Cameo、Rhapsody、Capella/Arcadia 生态等）普遍采用专有模型仓库与文件格式。当组织的系统模型沉淀于某一厂商的私有格式之后，迁移成本极高，从而形成典型的厂商锁定（vendor lock-in）（Friedenthal 等，2014/2018；Roques，2016）。

从符号系统视角看，厂商锁定的根源在于：形式编码的可扩张性（允许工具厂商通过 profile、扩展点、私有 API 增强能力）与跨工具语义稳定性（模型在 environments 间无损迁移）之间存在零和。工具厂商为了强化本平台的形式能力（例如更丰富的分析、仿真、协同功能），必然引入私有扩展；这些扩展一旦进入模型，便破坏了模型在异质工具间的语义可移植性。说白了，工具锁定不是厂商"恶意"的产物，而是形式扩张性在商业竞争环境下向语义稳定性一侧借债的必然结果。

5.2.2 XMI/API 的语义漂移

即便在标准层面存在 XMI（XML Metadata Interchange）与 OMG 的 Systems Modeling API & Services（OMG，2024）等互操作机制，实践中仍普遍出现"语义漂移"。所谓语义漂移，是指同一模型在导出/导入过程中，其语义内容在不同实现间发生非预期偏移。其技术根源在于：SysML v1 的语义规范本身存在实现自由度，XMI 仅规定了序列化语法而非完整的语义契约，各厂商对元模型元素的理解与缺省行为存在差异（Friedenthal 等，2014/2018；Borky & Bradley，2018）。

这恰好印证了核心论点中的"形式编码↔语义编码"张力：SysML v1 在形式上试图保持开放与可扩展（形式编码侧宽松），却未能给出机器可强制执行的完整形式语义（语义编码侧薄弱），于是互操作的正确性只能依赖各厂商的"善意约定"，漂移在所难免。语义编码侧的弱化，正是形式编码侧自由扩张所付出的零和代价。

一个常被引用的具象案例是：同一 SysML 活动图在工具 A 与工具 B 间往返导入导出后，决策节点（decision node）的守卫条件（guard）可能因两工具对缺省合并语义（merge semantics）的诠释不同而发生偏移，致使下游仿真结果出现偏差。更复杂的情形出现在参数图（parametric diagram）的约束求解上：不同工具对约束块（constraint block）与值属性（value property）绑定关系的内部实现并不统一，同一组约束在工具间迁移后可能出现求解失败或结果不一致。这类问题之所以层出不穷，正是因为 SysML v1 在形式上保持了宽松的可实现性（允许各厂商自行补全语义细节），而这一宽松正是以语义编码侧的精准契约为代价换来的——这再次证明零和取舍并非理论推演，而是可在工具间实际观测到的工程现象。

5.2.3 跨工具模型迁移失真

跨工具迁移失真（model round-trip loss）是互操作脆弱性的最直观表现：将模型从工具 A 导出再导入工具 B，常常丢失约束、注解、布局甚至部分语义连接（Estefan，2008；INCOSE，2023）。在复杂的系统工程场景中，这种失真可能使下游仿真、需求追溯或合规检查失效。

需要指出，SysML v2 与配套的 KerML、Systems Modeling API（OMG，2023；OMG，2024）正是为了从根上缓解这一问题——它通过更严谨的内核形式语义（KerML 以一阶逻辑与四维时空外延定义，OMG，2023/2025；Seidewitz，2023）来提升语义编码侧的精准性，从而减少实现者自由诠释的空间。然而正如后文（5.3、5.4 节）将展开讨论的，强化语义编码的同时，又对工具实现的复杂度、语言的可习得性与既有资产的可迁移性提出了新的、往往是更高的要求。这正是零和取舍的"螺旋式"再现：你在一个环节补强语义编码，就要在另一环节向形式编码侧偿付成本。

5.3 语义歧义残留

5.3.1 形式语义的引入及其边界

一个常见的乐观假设是：只要引入足够严格的形式语义，模型的歧义就能被彻底消除。SysML v2 / KerML 的演进方向确实朝这一方向努力——KerML 提供了以一阶逻辑表达的精确内核语义，意图使模型"可被机器无歧义解释与执行"（OMG，2023/2025；Seidewitz，2023）。这无疑强化了语义编码一侧（逻辑精准性↑、稳定性↑）。

但必须清醒认识到其边界。开头，形式语义的完备性局限于"内核"：KerML 定义了值与类型、特征与关联等基本构造的形式含义，但工程建模中大量涉及的非形式内容（如自然语言需求文本、注释、领域约定、图布局所承载的非正式沟通意图）仍游离于形式语义之外。接着，形式语义虽能约束"符号如何被解释"，却无法约束"建模者如何把现实意图映射到符号"——后者属于建模实践问题，而非语言规范问题（Holt 等，2011/2012）。

5.3.2 自然语言的影子与主观诠释空间

即便在形式语义最严格的场合，"自然语言的影子"依然挥之不去。系统工程的根本输入是利益相关者的意图，而这些意图最初总以自然语言、口头沟通、文档片段的形式存在（Kossiakoff 等，2011）。建模者必须将这些非形式意图"翻译"为模型元素，而翻译过程天然保留主观诠释空间：同一句"系统应在五秒内响应"，建模者可能建为性能约束、活动图时限或参数图变量——不同建模者对同一意图的形式化处理存在差异，这是符号系统无法根除的歧义源（Borky & Bradley，2018）。

更深刻地说，歧义残留是符号系统零和取舍的宿命性表现：完全消除歧义，需要把全部工程意图都纳入形式/语义编码（高密度、逻辑精准），而这会彻底压垮可习得性与可接受性——工程师将面对一门无法被人类直觉驾驭的纯形式语言。保留一部分自然语言的、可诠释的空间（可习得性↑），就必须容忍相应的语义不确定性（稳定性↓）。MBSE 的歧义残留，正是因为它在实践中明智地选择了"不完全形式化"以保全人的可参与性，而这一明智选择本身就是零和取舍的主动兑现。

5.4 可扩展性悖论

5.4.1 profile/stereotype 的扩张

SysML v1 提供了 profile 机制，允许团队通过 stereotype、标签值（tagged value）与约束（OCL）对语言进行领域定制（Friedenthal 等，2014/2018）。这一机制在形式上极具扩张性：无论航空、汽车、轨道交通还是医疗器械，都可以"长"出符合自身领域的建模方言。从形式编码视角看，这是可扩张性的胜利。

然而，profile 的每一次扩张，都在向语义编码一侧借债。当组织在 SysML 基础上叠加大量自定义 stereotype 与约束时，模型的"标准性"被稀释——不同项目、不同团队可能发展出互不兼容的领域方言。例如，某轨道交通团队可能定义 «trackSection»、«signalingBlock» 等专有构造来表达联锁逻辑，而某航天团队则定义 «flightPhase»、«telemetryStream» 来表达任务时序；两套 profile 在各自领域内语义自洽，但彼此之间无法互译，一方模型对另一方而言近乎"外语"。Madni & Sievers（2018）在讨论 MBSE 采用障碍时，间接触及了方法论与定制泛滥导致的碎片化风险。更具体地说，profile 扩张意味着：一个新成员要理解某个项目模型，不仅要懂 SysML 标准，还要懂该项目独有的 profile 约定，这又回头加重了 5.1 节所述的学习负担（可习得性进一步↓）。当这种定制以"每项目一套方言"的方式累积，组织层面便会形成模型资产孤岛，原本期望通过 MBSE 获得的可复用性反而被侵蚀——这正是形式扩张性向语义稳定性借债后必须偿还的利息。

5.4.2 跨项目语义稳定性塌缩

可扩展性悖论的尖锐之处，在于"扩张性↑"与"跨项目语义稳定性↓"的正相关。一个被深度定制的模型，在本项目内可能语义自洽，但一旦需要跨项目、跨组织复用或对外交付，其定制部分就成了理解障碍与互操作障碍（INCOSE，2023）。Schäfer & Wehrheim（2009）在讨论高级机电一体化系统构建挑战时，强调了语义一致性与跨团队协作间的张力，这与 MBSE 的 profile 困境高度同构。

这里的核心论点投影极为清晰：形式编码侧追求"可扩张性"（让语言长成适应任何领域的形状），必然以语义编码侧的"稳定性/跨语境一致性"为代价。零和关系在此表现为：你每增加一份领域扩展的自由，就减少一份模型被普遍、稳定、无歧义解读的保障。不存在既能无限扩张、又能普遍稳定的符号系统——这正是全书核心论点在本节的具体落点。

5.5 成本与 ROI 不确定性

5.5.1 前期投入与收益滞后

MBSE 的导入是典型的"高前期投入、收益滞后显化"工程。它要求组织同时投入：建模工具许可、方法论定制、人员培训、模型库与资产建设、流程改造（Madni & Sievers，2018）。这意味着在相当长的一段时期内，组织只见成本、难见回报。Madni & Sievers（2018）在其关于 MBSE 动机、现状与研究机会的综述中，明确把"缺乏清晰的回报证据""前期成本高"列入主要采用障碍——他们的数据来源覆盖了大量工业调研，结论具有代表性。

从投入结构看，MBSE 的成本曲线呈现显著的"前重后轻"特征：工具许可与培训往往是一次性或周期性的大额支出，而收益（如早期缺陷发现、需求追溯自动化、变更影响分析加速）则是随模型成熟度逐步释放的、且多以"风险规避"形式存在。据该综述归纳的工业经验，多数组织在模型资产积累到一定规模、团队建模能力成熟之后，才进入收益显现期，这一滞后期常以"项目数"而非"月数"衡量。换种讲法，MBSE 的经济性高度依赖"规模阈值"——只有当模型资产跨项目复用、方法论跨团队沉淀时，前期投入才被摊薄。对于项目数量有限、生命周期短或人员流动率高的组织，阈值可能始终无法触及，ROI 的不确定性由此被结构性放大，而非偶发性失误所致。

从符号系统视角解读：MBSE 之所以"贵"，是因为它在语义编码侧追求高价值（通过模型实现早期错误发现、可追溯性、一致性校验），而高语义价值需要高昂的形式化建构成本来支撑。形式编码侧（易学、易铺开）被相对牺牲，意味着模型资产无法"随手建立"，必须依赖训练有素的人与重工具链——成本由此内生。其实，ROI 不确定不是预算失控，而是"为换取语义编码侧收益而偿付的形式化成本"在项目早期尚未被收益覆盖的自然状态。

5.5.2 价值量化困境

更棘手的是，MBSE 的许多收益（如"减少需求歧义导致的返工""提升跨专业一致性""增强早期可验证性"）属于质量与风险维度，难以像产能那样被直接、客观地量化（Borky & Bradley，2018；INCOSE，2023）。价值量化困境进一步加剧了 ROI 不确定性，使管理层在持续投入上犹豫。

这一困境同样可还原为零和取舍：MBSE 的高语义密度（把大量隐性工程知识压缩进可校验的模型）使其收益多为"避免了什么坏结果"，而"避免"天然难以计量；若要便于计量（形式编码侧简单化、指标化），又得牺牲语义深度——你无法既拥有高密度语义、又拥有随手可测的浅层指标。价值量化困难，是语义编码侧高密度性所带来的、在形式编码侧（可度量性）上的零和代价。

5.6 覆盖鸿沟

5.6.1 早期阶段偏重

主流 MBSE 方法论（如 OOSEM、Harmony-SE、State Analysis、Arcadia 等，见 Estefan，2008；Roques，2016；Ingham 等，2004）普遍把重心放在系统生命周期的前期：需求分析、架构定义、功能/逻辑/物理分解、接口设计与早期验证。这与 ISO/IEC/IEEE 15288 所定义的系统工程过程高度契合（ISO/IEC/IEEE 15288:2015），也符合系统工程"早期决策决定后期成本"的基本规律（Browning，2001）。

5.6.2 制造、运维、供应链与现场服务的薄弱

然而，当工程进入制造、运维、供应链协同与现场服务阶段时，MBSE 模型的覆盖力显著减弱。制造执行依赖 MES/PLC/工艺规程，运维依赖资产管理系统与现场工单，供应链依赖 PLM/ERP 的数据交换，现场服务依赖手册与服务知识库——这些领域各有专属符号与数据系统，与 SysML 模型之间往往缺乏连贯的语义桥梁（Madni 等，2019；Grieves，2014）。数字孪生（Digital Twin）研究试图用模型贯通全生命周期，但 Madni 等（2019）也坦承，将 MBSE 模型有效延展至运维与物理资产仍处探索阶段。

覆盖缺口在几个典型场景中尤为突出。其一是制造工艺领域：SysML 能描述系统的功能与接口，却难以承载工艺路线、工装夹具、数控程序等制造专属语义，这些往往仍需独立的制造执行系统表达。其二是运维与健康管理（PHM）：现场传感器的实时遥测、故障诊断规则、维修策略等知识，通常沉淀在资产管理系统与领域知识库中，而非 SysML 模型之内，导致"设计模型"与"在役系统"之间出现语义断层。其三是供应链：多层级供应商之间的接口协调依赖 PLM/ERP 的物料与配置数据，与 SysML 的需求—结构视图并不天然对齐。这三处薄弱并非偶然，而是指向同一事实——MBSE 的语义覆盖范围，是由其在形式编码侧"收敛于系统工程核心"这一主动决策所划定的边界。

覆盖鸿沟同样源于零和取舍。MBSE 若想深度覆盖制造/运维/供应链，就必须在形式上大幅扩张（纳入工艺、物流、可靠性物理等异质领域语义），而每扩张一次，形式编码侧的可习得性与语义编码侧的跨领域稳定性就会被进一步拉扯。现行 MBSE 选择在"前期系统工程"这一语义相对可控、收益最显著的区段聚焦，本质上是以"放弃部分覆盖"换取"核心区段的语义严谨"——这仍是零和的理性取舍，而非能力缺憾。要弥合鸿沟，需要向形式编码侧注入更多扩张（集成更多领域语言），代价是系统整体更复杂、更难学、更易漂移，这正是许多组织迟迟不敢全线铺开 MBSE 的现实原因。

5.7 形式化验证的边界

5.7.1 状态空间爆炸

MBSE 的重要承诺之一，是通过形式化或半形式化手段对模型进行早期验证（如活动图/状态机图的可达性、参数图的可满足性、需求的可追溯性与一致性）。然而，当系统规模与并发度上升时，状态空间爆炸（state-space explosion）问题随之而来：对包含大量并发状态与交互的系统，穷举其可达状态以验证性质，其计算复杂度呈组合式增长，往往超出可承受的算力与时延（Harel & Politi，1998；Evermann，2009）。

状态空间爆炸是形式化方法共有的根本难题，根源在于：语义编码侧追求"逻辑精准验证"（对全部状态穷尽判定），而该追求所需的计算资源随系统规模指数增长，这恰恰对应形式编码侧"动态柔性/可扩张性"的反面——你越是想对庞大、柔性、可变的系统做穷尽验证，就越被算力边界所困。零和在此表现为：语义精准性的上限，被形式系统可处理规模的上限所硬性封顶。

5.7.2 模型保真度与现实的差距

即便验证在模型层通过，模型的保真度（fidelity）仍是根本约束。模型永远是对现实的简化抽象，它省略了物理实现中的大量细节——材料疲劳、电磁兼容、人为操作错误、环境扰动等（Borky & Bradley，2018）。一个在模型中"正确"的架构，可能因被忽略的物理效应而在现实中失效。Madni & Sievers（2018）与 Borky & Bradley（2018）均强调，模型的价值取决于建模假设与现实吻合的程度，而假设永远无法完备。

5.7.3 "模型正确"不等于"系统正确"

由此引出形式化验证最深刻的边界：验证只能证明"模型在其假设下自洽"，不能证明"模型所对应的真实系统正确"（Guizzardi，2007）。这是符号系统的根本性限制——符号与其指称的外部现实之间，始终隔着建模抽象这一不可消除的鸿沟。强化语义编码（让模型内部逻辑更严谨）并不能自动缩小模型与现实的语义落差，反而可能制造一种"已验证即正确"的虚假自信（Broy & Cengarle，2010）。

一个生动的反例是：某控制系统的状态机模型在仿真中通过了全部可达性与安全性性质验证，但交付后却在真实电磁干扰环境下出现非预期复位——原因在于模型假设中忽略了"电压暂降"这一物理事件，而该事件既不在状态机的事件集合内，也不在参数图的变量范围内。验证的完备性被模型抽象所"框定"，框定之外的一切皆不可见。这正是哲学家与形式方法学者反复警示的"验证的是模型而非世界"。MBSE 的验证能力越强，越容易让工程组织误把"模型正确"等同于"系统正确"，这一认知风险本身，就是高语义密度带来的零和副产物：你获得了强大的内部逻辑保证，却也获得了强大的自我确信错觉。

把这一点放回核心论点：模型与现实的落差，本质是语义编码（符号内部逻辑）无论如何强化，都无法替代"符号与世界的对应"这一更外层的语义问题。零和关系在此体现为，你在符号内部把语义编码做到极致（逻辑精准性↑），并不减少、甚至可能掩盖符号与外部现实之间的语义失配（稳定性在"现实层"仍↓）。形式化验证的边界，因此是符号系统零和张力的终极提醒。

5.8 组织与文化阻力

5.8.1 文档惯性

MBSE 与以文档为中心的传统系统工程之间存在深刻的实践冲突。数十年来，系统工程依赖自然语言文档、接口控制文档、设计报告作为沟通与问责载体，组织流程、评审节点、质量体系均围绕"文档"构建（INCOSE，2023；NASA，2016）。转向模型为中心，意味着这些既有的组织惯性需要被重做，而惯性本身是强大的阻力来源。

文档惯性的持续存在，在符号系统视角下有其合理性：自然语言文档的可习得性极高（任何人都能读），其语义虽松散但容错性强；而模型要求结构化、形式化输入，可习得性低。组织在"易读的松散文档"与"严谨但难用的模型"之间，往往本能地偏向前者——这并非保守，而是对形式编码可习得性缺失的本能规避。零和取舍在此具象为：采纳 MBSE（语义编码↑）就要对抗人性化的文档惯性（可习得性↓的对抗成本）。

这种惯性还体现在知识权力的再分配上：在传统文档体系中，资深工程师凭借经验即可撰写与评审报告，话语权与其领域权威直接对应；而 MBSE 将知识"封存"进模型与工具，评审者必须先能阅读模型、理解建模约定，才能行使评审权。这一转变常遭遇资深人员的隐性抵触，并非因为其对质量不负责，而是因为其熟悉的"符号母语"被剥夺。从符号系统角度看，这是形式编码可习得性下降所引发的社会层反弹，是零和取舍在组织政治中的延伸表现。

5.8.2 认证与监管的纸质文档要求

更硬性的阻力来自认证与监管。航空（DO-178C/ARP4754A 生态）、汽车（ISO 26262）、医疗器械（IEC 62304）等领域的适航与合规流程，长期以签核的纸质/PDF 文档为法定证据（INCOSE，2023；NASA，2016）。即便模型已完整表达设计，组织仍须额外生成纸质文档以满足监管，造成"模型+文档"双轨并行，抵消了 MBSE 的部分效率收益。

这一阻力同样可还原为零和：监管体系要求的是"可被人类审查者稳定、无歧义、可归档追溯"的语义载体（语义编码侧在"法律可读性"维度的诉求），而 MBSE 模型虽然在机器语义上严谨，在监管者的"人读稳定语义"维度并不天然满足。弥合它需要把模型再翻译回文档——而每一次"模型→文档"的翻译，又是一次向形式编码侧（易人工审阅）的妥协与成本偿付。

5.8.3 跨专业协作摩擦

系统工程天然是多专业协作：系统、软件、硬件、机械、电气、可靠性、安全等专业各有自己的符号习惯（如软件用 UML/代码、控制用 Simulink、机械用 CAD/BOM），MBSE 试图用统一建模语言统摄各方，但不同专业对"同一系统"的心智模型差异巨大，导致建模协作中的语义摩擦（Schäfer & Wehrheim，2009；INCOSE，2023）。Borky & Bradley（2018）在实务中亦强调，跨专业模型集成的难度往往超过单专业建模本身。

跨专业摩擦是零和取舍在"组织符号生态"层面的投影：一个统一的高语义密度模型（语义编码↑），要求各专业放弃自身熟悉、低门槛的领域符号（可习得性↓），而各专业对"放弃母语"的抵触，正是形式编码可习得性被削弱时的必然社会反应。要降低摩擦（可习得性↑），就得允许各专业保留各自符号，代价是统一语义模型的密度与一致性下降——零和再度确认。

5.9 小结：局限性是零和张力的必然外显

本章逐一检视了 MBSE 在九个方面的局限性：学习曲线陡峭与人才稀缺、工具锁定与互操作脆弱、语义歧义残留、可扩展性悖论、成本与 ROI 不确定性、覆盖鸿沟、形式化验证的边界、组织与文化阻力。需要重申的是，这些局限性并非工程失误的清单，而是贯穿全书核心论点的具体投影——符号系统在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做不可逆零和取舍，MBSE 作为该符号系统的工程实例，其每一项短板，都可精确还原为这一取舍在某一工程场景下的"代价落点"。

当我们批评 MBSE"难学""易锁定""仍有歧义""定制越多越乱""回报难测""覆盖不全""验证有界""落地受阻"时，我们实际上是在描述：一个在语义编码侧取得可观进展（一致性、可追溯、可早期验证、跨专业统一）的符号系统，必然在形式编码侧偿付出的代价（可习得性下降、可扩张性带来漂移、柔性换来不确定）。不存在一种既能完全免除这些代价、又保留 MBSE 全部收益的"完美体系"——因为那等于要求符号系统打破零和，而这已被本书核心论点判定为不可能。

因此，对 MBSE 局限性的正确态度，不是试图用更多努力去"消灭"它们（那只会把张力推到别处），而是清醒地在每个工程场景中，根据价值与代价的坐标，主动选择取舍的位置，并接受其伴随的、不可消除的副产物。下述映射表将本章各局限性与其对应的编码侧代价收束呈现，作为本章的方法论落点。

表 5-1 局限性—对应编码侧代价映射表

该表揭示了一个统一的结构：MBSE 的八类局限性，最终都可归入"形式编码某属性↑ ↔ 语义编码某属性↓"（或其镜像）的零和关系之中。这一结构不是巧合，而是符号系统本质张力在 MBSE 这一工程实例上的必然刻痕。正是在这个意义上，本书断言：MBSE 的局限性不是缺陷清单，而是核心论点的经验证据。

5.10 过度建模（over-modeling）的成本：形式编码过度扩张对动态柔性的反噬

5.10.1 过度建模的定义与识别

在 MBSE 实践中，常出现一种与"建模不足"方向相反却同样有害的倾向：过度建模（over-modeling）。它指的是组织投入的建模范式、详细程度与维护成本，超过了该模型所能返还的工程价值，使建模活动本身由"手段"异化为"负担"（Borky & Bradley，2018）。其典型征兆包括：为已被标准件满足的成熟部件建立完整内部结构模型；为生命周期内不会变更的静态需求配置全套参数图；把本可用一句话说清的接口约束展开为多层包与追踪关系；以及追求"模型覆盖率"等指标而堆叠大量无人真正消费的视图。Madni & Sievers（2018）在综述中将"在模型细节上过度投入"列为导致支出与收益不成比例的常见现象之一，并指出许多团队在导入期难以判断"何时该停手"。

需要区分的是，过度建模不同于 5.4 节所述的可扩展性悖论：后者是"语言层"的定制泛滥，前者是"实例层"的细节堆砌。但二者共享同一根——都对形式编码的可扩张性做了过量兑现。区别仅在于，可扩展性悖论损害的是跨项目语义稳定性，而过度建模损害的是单个项目内的动态柔性。

5.10.2 形式编码扩张对动态柔性的反噬

把这一现象放回核心论点，过度建模恰恰是零和取舍的"过度兑现"：组织为了在语义编码侧追求更高的"逻辑精准性"与"稳定性"（把所有知识都固化进可校验模型），在形式编码侧把"可扩张性/动态柔性"推到极致——模型越庞大、连接越密，它对任意一处工程变更的适应力就越差。一个被层层追踪关系与参数约束"焊死"的模型，其修改成本随规模超线性增长；当需求小幅调整时，模型未必比文档更容易改，因为改一处要顺着约束网络同步数十处，这正是动态柔性↓被形式扩张性↑所吞噬的现场表现。

更具反讽意味的是：MBSE 标榜的优势之一是支撑"早期变更影响分析"，而过度建模却使"变更"本身变得昂贵，从而削弱了组织快速响应不确定性的能力——这与其宣称的动态柔性诉求直接矛盾。换个说法，形式编码侧为覆盖一切而做的扩张，在越过某临界点后，开始系统性地侵蚀形式编码侧自身的另一属性（动态柔性）。零和关系在此不是"形式↔语义"的二维拉锯，而是在形式编码内部"可扩张性↑ ↔ 动态柔性↓"的子维度上再次回环：你为广覆盖所偿付的，不只是语义稳定性，还包括系统自身的柔性。

5.10.3 例子：黄金建模（gold-plating）与维护税

一个常见的实例是"黄金建模"：某团队为展示 MBSE 成熟度，将全部需求、全部接口、全部行为以最高保真度建模，并维护双向可追溯矩阵。项目初期模型"漂亮"，但进入工程迭代后，每次需求评审都触发大批量模型更新，建模师把大量工时花在"模型与文档的对账"而非工程分析上，模型逐渐沦为需要专人养护的"数字盆景"（INCOSE，2023 在手册中亦提醒，模型维护成本应被纳入生命周期考量）。另一个实例来自参数图滥用：对物理特性在生命周期内基本恒定的组件仍建立完整参数约束网络，求解与维护开销远超其捕捉到的工程信息量。Holt 等（2011/2012）在论及模型驱动的requirements 工程时也警示，模型元素的增殖若不加以治理，会迅速超过其信息收益。

下表归纳过度建模的几类典型症状及其在零和坐标上的代价落点。

表 5-2 过度建模的典型症状与编码侧代价

由此可得出一条工程纪律：模型应当"刚好够用"而非"尽量完备"。判断停手点的标准，不是模型还能不能再细，而是边际建模成本是否已超过边际语义收益（Borky & Bradley，2018）。这条纪律本身就是对零和张力的实践性承认——承认形式扩张有其不可回收的柔性代价，才能避免把 MBSE 用成负担。过度建模提醒我们：零和取舍不仅发生在"形式↔语义"之间，也发生在形式编码内部"可扩张性"与"动态柔性"之间；忽视后一种内部零和，是 MBSE 项目由工具赋能滑向工具奴役的常见拐点。

5.11 模型治理失效与语义漂移：大型项目中的实测表现及组织学习曲线

5.11.1 模型治理为何会失败

当模型成为组织的核心资产，其演化就需要制度化的"模型治理"（model governance）：定义建模约定、命名规则、profile 使用边界、评审与版本门禁。但在大型、多团队、长周期项目中，治理常常失效。失效的首要来源是约定漂移：各子团队在本地实践中悄然发展出互不兼容的建模方言，而中央治理无力约束（Schäfer & Wehrheim，2009 在跨团队协作挑战中已揭示此类语义一致性张力，与 MBSE 的 profile 困境高度同构）。其次来源是治理成本本身——严格的建模规范与评审门禁，在进度压力下常被"暂时绕过"，绕过一旦成为习惯，模型质量便不可逆下滑。第三类失效来自角色缺位：许多组织任命了工具管理员，却没有设立对建模语义负责的"首席建模师"或架构治理委员会，使约定缺乏权威维护者。

5.11.2 语义漂移在大型项目中的实测表现

语义漂移（5.2.2 节的技术层面）在组织层面表现为"同一概念、多义建模"。一个被广泛观察到的实测现象是：在不同子系统的模型中，"接口""配置项""模式"等核心概念被以不同构造表达，且彼此的映射缺乏强制约束，于是当模型被集成用于跨系统追溯或影响分析时，工具无法给出一致答案（Friedenthal 等，2014/2018 指出，缺乏统一语义约定的大型模型库会退化为"视图集合"而非"单一事实源"）。更隐蔽的漂移来自版本：同一模型元素在不同基线中被不同团队以不同意图修改，集成时出现的并非报错而是"静默不一致"——需求看似已满足，实则指向的是被改过的旧语义。这类问题在文档体系中会暴露为不一致的文本，而在模型体系中却可能"看起来自洽"，因为形式连接尚在、语义却已错位。这恰是语义编码侧"稳定性"被形式扩张（多团队自由建模）侵蚀的实测证据，与 5.4 节的可扩展性悖论同构。

一个有代表性的工程叙事来自航天与防务领域的多站点协作：某跨地域项目要求各分包方以 SysML 提交子系统模型，中央团队负责集成。集成阶段发现，三个分包方对 «interface» 这一 stereotype 的语义约定各执一词——甲方将其理解为"逻辑端口集合"，乙方理解为"物理连接器"，丙方理解为"协议栈"，三者虽都使用了同一词汇，却指向不同的现实对象。中央团队不得不投入额外一轮"语义对齐"工作坊，其成本已超过模型本身带来的追溯收益。该案例说明：语义漂移不是理论风险，而是大型项目中可被实测、可被计量的真实开销，其根源正是形式编码可扩张性（允许各团队自由诠释）对语义稳定性的持续借债。

5.11.3 组织学习曲线的量化：培训周期与生产力爬坡

过度建模与治理失效共同指向一个更底层的约束：人的建模生产力需要时间爬坡，而这一过程可被粗略量化。Madni & Sievers（2018）在综述中归纳的工业经验表明，MBSE 团队从"工具可用"到"方法论内化"通常要跨越多个项目周期；多数组织在积累起跨项目的模型资产与方法论沉淀后，才进入收益显现期，这一滞后期常以项目数而非月数衡量。具体到能力层级，5.1.1 节将其拆为语法层、方法论层与领域判断力层：语法层集中训练常以数周计，方法论层需至少一个完整项目周期内化，领域判断力层则只能在跨多个系统的反复实践中形成。三层的叠加使合格建模师的养成以"年"计。

下表给出一种典型的"建模生产力爬坡"示意（基于文献中对层级与周期的归纳，非某企业精确实测，仅作量级参照）：

表 5-3 建模生产力爬坡的典型阶段（量级参照）

需要强调，这条爬坡曲线不是"越训越快"的单调上升，而是在每个新方法论、新工具、新领域引入时都会出现"再学习凹坑"——因为每次引入都相当于向形式编码侧增加扩张，组织必须重新偿付可习得性代价（Holt 等，2011/2012 强调，表达力越强，学习曲线越陡）。因此，大型项目的模型治理失败，往往不是单点失误，而是"学习曲线尚未爬完 + 形式扩张持续借债 + 治理投入不足"三者叠加的必然结果。这也解释了为何许多组织在首个 MBSE 项目上 ROI 难测（见 5.5 节）：他们都卡在爬坡曲线的早期凹坑里，尚未触达收益显现的规模阈值。

5.11.4 小结：治理与学习曲线亦是零和投影

把 5.10 与 5.11 收束到核心论点：过度建模是形式编码可扩张性对动态柔性的内部反噬；治理失效与语义漂移是可扩张性对语义稳定性的组织层侵蚀；学习曲线则是可扩张性对可习得性的持续索取。三者共享同一根——符号系统在形式编码侧每多一分"能建模一切"的自由，就在另一侧（无论是柔性、稳定性还是可习得性）少一分保障。不存在一套"既允许无限建模、又永不漂移、还人人速成"的体系，因为那等于要求零和被取消。对大型项目而言，正确的工程态度是：以治理为刹车、以"刚好够用"为尺度、以可量化的学习曲线安排人才节奏，主动把零和取舍固定在可承受的位置。至此，本章从九个固有局限（5.1—5.9）延伸到两类"人为放大型"局限（过度建模、治理失效与学习曲线），共同印证：MBSE 的全部短板，最终都是符号系统形式编码↔语义编码零和张力的具体投影。

第6章 MBSE 的主要争议点及各方立场

6.1 符号系统的零和曲线：本章的统一分析框架

本书的核心论点贯穿始终：任何符号系统都必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做不可逆的零和取舍，不存在完美兼顾的终极体系。MBSE 作为符号系统在工程领域的一个典型实例，其全部历史演进、方法分歧与能力边界，均可归结为这一根本性张力。

本章的任务，是把 MBSE 领域中那些看似彼此独立、彼此攻讦的争议，逐一还原到这条零和曲线上去。所谓「形式编码」一侧，关心的是语言是否易学、是否容易随组织与需求扩张、能否在系统演化过程中保持柔性；所谓「语义编码」一侧，关心的是语言所承载的语义是否稳定、信息密度是否高、逻辑是否可被精确校验。这两条轴线之间不是可以各自优化的两个自由维度，而是一条资源恒定的取舍曲线：越是往形式编码方向移动（让工具易学、让方法可扩张、让模型能随需求柔性演化），就越是在削弱语义编码一侧（语义变得不稳、密度被稀释、逻辑校验失准）；反之，越是追求语义编码的严谨（形式化语义、可执行、可机器验证），就越要牺牲形式编码的可习得性与可扩张性。

需要强调，这种取舍之所以被称为「零和」，是因为它在符号系统的根本资源上守恒：一套符号所能承载的「表达自由度」与「语义确定性」之和存在一个上限。当你把符号设计得宽松、可组合、易于被新人掌握（形式编码高），你就无法同时要求每个表达式都被赋予唯一、精确、可由机器判定的含义（语义编码高）——因为精确判定本身要求对表达空间施加约束，而约束必然降低可习得性与可扩张性。这一结构性的拮抗，在编程语言史（动态语言与静态语言的百年拉锯）、在数学基础（形式化系统与哥德尔不完备的张力）、在自然语言（歧义带来的表达力与精确的永恒冲突）中反复出现，MBSE 不过是它在工程语境中的又一次显形。正因如此，本章拒绝把任何一项争议简化为「谁对谁错」的口水仗，而坚持用同一条零和曲线作为统一的度量衡。

本章将依次辨析六类主要争议——供应商锁定与开放标准之争、形式化严谨与务实可用之争、模型与文档之争、ROI 与价值证明之争、标准碎片化之争、适用性边界之争——并在每节以「零和还原」为纲，说明这些争议表面上是立场分歧，实质上不过是不同利益相关方在零和曲线上选择了不同的最优点。末了，本章给出一张各方立场梳理表，并以核心论点收束全章：争议本身，恰恰证明了终极体系的不存在。

6.2 争议一：供应商锁定对比开放标准

6.2.1 立场分野

MBSE 的工具格局长期被两套逻辑切割。一端是以达索系统的 Cameo Systems Modeler / MagicDraw、IBM 的 Rational Rhapsody 为代表的专有工具阵营；另一端是以泰雷兹（Thales）主导、托管于 Eclipse 基金会的 Capella（承载 Arcadia 方法）、Eclipse Papyrus（承载 SysML/UML）、以及 OpenMBEE 等开源项目为代表的开源阵营（Friedenthal 等，2014/2018；OpenMBEE，2020s）。

厂商立场鲜明：专有工具主张一体化的语义栈、稳定的版本演进、厂商级技术支持与认证就绪（certification-ready）能力，适合对可靠性和问责制要求极高的国防与航天项目（Borky & Bradley，2018）。工具厂商天然倾向于封闭的生态绑定，因为持续的许可证收入与服务合同是其商业模式的基石。

学界与中小企业的态度则复杂得多。学界偏好可检视、可二次开发的开放工具，便于教学与科研；中小企业则对高昂的专有许可证与深层绑定心存戒备。政府与大承包商的立场最具张力：一方面，他们大量采购专有工具以对接既有体系；另一方面，欧洲的经验表明，像空客这样的主承包商对工具的诉求并非「短期好用」，而是「能在飞机项目长达五十年的全寿命周期内持续可用、支持、并可在供应链中低成本部署」（ITEA/OPEES，2019，无 DOI）。

这种长达半世纪的工具寿命诉求，深刻揭示了锁定与开放之争背后的真正利害关系。对于国防与航天主承包商而言，一套工程工具并非可有可无的办公软件，而是与产品一道进入数十年服役周期的「制度性基础设施」；一旦选定闭源专有栈，组织便把未来数十年的工程语义表达能力，押注在单一厂商的存续与善意之上。这正是形式编码一侧的「可扩张性」被彻底让渡的极端情形：厂商获得了语义编码的托管权，组织则失去了自主演进的柔性。与之相对，政府监管机构虽不直接采购工具，却通过认证与采购条款间接塑造工具格局——当强制要求「模型可审计、可独立复核」时，实际上是在为语义编码一侧背书，从而把专有工具的高密度受控语义推到了合规的前台。三条力量（厂商、主承包商、监管者）在零和曲线上各自施力，使锁定与开放之争始终无法收敛到单一均衡，而只能在不同项目、不同国别、不同供应链层级上被反复重谈。

6.2.2 开源阵营的反制逻辑

开放标准的拥趸给出了一组有力的反证。OPEES 项目（ITEA 2，2009–2012）的遗产清晰地表明：开放协作与开源 MBSE 工具并非乌托邦，而是欧洲航空航天工业的真实选择（ITEA/OPEES，2019，无 DOI）。泰雷兹在 2013 年前后意识到，Capella 早期闭源形态恰恰是其在更广阔供应链中大规模部署的障碍——分包商因专有性质无法获得工具访问权，于是泰雷兹于 2014 年将 Capella 在 PolarSys 中开源（ITEA/OPEES，2019，无 DOI）。这一转变的底层动机，正是为了「降低使用门槛、促进跨组织协作、并以开放标准便利互操作」。

但开放阵营内部也有清醒的声音。一份面向系统工程师的趋势评论指出，开源方案「没有免费的午餐」：越是开放的工具，越需要在培训与定制上投入更多——许可证费用省下的部分，必须以内部工程能力的形式补回（SE-Trends，无 DOI）。Papyrus 若不加以充分定制与维护「会非常令人沮丧」，Capella 因有泰雷兹的明确工业领导而用例驱动更强，但纯粹开源路线仍需自担支持成本（SE-Trends，无 DOI）。

6.2.3 零和还原

把这一争议放回零和曲线：专有工具本质上是在语义编码一侧取极值——它们提供高密度的、受控的、可审计的、与认证流程对齐的语义栈，代价却是形式编码一侧的开放性与可扩张性被锁死（模型数据难以自由迁移、生态被单一厂商绑定、跨供应链柔性受挫）。与之相对，开源工具是在形式编码一侧取极值——可习得（学生无须许可证即可上手）、可扩张（可据行业语境改造）、具动态柔性（社区可长期维护），代价却是语义编码一侧的「开箱即用的高密度与强支持」不足，需要组织自身补上定制与治理的工程投入。

因此，「供应商锁定对比开放标准」之争，从来不是「好工具对坏工具」的道德之争，而是零和曲线上两个最优点之争：你究竟更看重被托管的高密度语义，还是可自我掌控的开放柔性。

6.3 争议二：形式化严谨 versus 务实可用

6.3.1 学术派的立场：要形式语义、要可机器验证

学术派坚持，MBSE 若不能提供可被精确解释、可被机器验证的语义，便退化为「带图形的文档」，丧失了模型相对于文档的根本优势。这一立场随着 SysML v2 与 KerML 的推进而显著增强。OMG 在 SysML v2 中引入了 Kernel Modeling Language（KerML），其正式语义以一阶逻辑与四维时空外延（4D extensional）表述，意在从根本上消解 SysML v1「同一图符多义、工具间语义漂移」的积弊（OMG，2023/2025；Seidewitz，2023）。

从更宽的学术脉络看，对建模语言形式语义的诉求由来已久。Broy 与 Cengarle（2010）系统梳理了 UML 形式语义的难题；Evermann（2009）论证了借助本体（ontology）对 UML/OCL 模型进行验证的可行性；Guizzardi（2007）则从概念建模层面强调，建模语言与本体论承诺之间的错位会导致语义失真。这些研究的共同取向是：把语义编码一侧推到极致，使模型成为可被逻辑引擎严格判定的对象。

值得进一步指出的是，学术派对严谨性的追求并不止于「语法可解析」，而是指向「可执行（executable）与可仿真」这一更高阶的语义目标。当模型可被编译为可运行的行为规约，系统性质（如死锁自由、响应有界、接口一致性）便能以数学方式被证成，这正是逻辑精准性的极致形态。然而，可执行语义的代价是极其高昂的形式编码成本：工程师必须学习一阶逻辑、状态迁移的严格表述、以及约束语言（如 OCL 的变体）的书写规范，这些门槛把模型的「可习得性」压到很低。说白了，学术派每把语义编码推高一档，就必然在形式编码一侧付出等量的习得与扩张代价，这条铁律在形式化方法六十年的历程中从未被打破。

6.3.2 工业派的立场：要快、要沟通、要能交付

工业派——尤其是一线工程经理与交付团队——的回应则是务实主义的。在他们看来，模型的全部价值在于「帮团队更早、更少歧义地做出更好的工程决策」，而不是产出一份可被机器证明的形式化文本（Sheridan，2026，无 DOI，该文亦自承其立场偏向实践性）。一份来自防务领域的实践观察直言，MBSE 头六个月的真实开销往往高于文档中心方法，因为其模型基础设施（治理、工具、仓库、模板）必须在工程推进的同时现搭。换种讲法，形式化严谨的即时成本，是工业节奏难以承受之重。

更具警示意味的是，形式化并非万灵药。在 TCAS II 三十周年的反思性研究中，作者指出工程团队常「迷恋」SysML 或 Simulink/Stateflow 的建模能力，声称模型即需求、因而自动捕获了期望行为，但这「显然是错误的」——大模型中若高层需求（如安全需求）未被正确捕获，则「根本无物可验」（TCAS II 反思，无 DOI）。形式验证只能检查我们「要求它检查的性质」，若性质本身未被正确提出，验证便徒具其表。这说明，把语义编码推到极致并不自动产生可信系统，它仍依赖扎实的需求与方法论纪律。

工业派的务实立场，因而并非出于对严谨的轻视，而是源于对「工程现场真实性」的尊重。在快节奏交付压力下，模型的读者往往是跨专业的干系人——经理、供应商、其他学科的工程师——他们并不掌握形式语言的语法，却必须在模型所呈现的意图上做出决策。当模型过度追求形式化而丧失「可被非专家解读」的沟通能力时，它反倒退化为又一堵专业壁垒，与 MBSE 所宣称的「单一事实来源、跨域对话」初衷背道而驰（One-Sys，无 DOI）。因此，工业派主张「只为回答眼前问题而建模到所需深度即可」，把形式编码一侧的易学、易沟通、易随需求柔性演化，置于高于机器可证性的位置。这不是无知，而是另一种自觉的取舍。

6.3.3 零和还原

形式化严谨与务实可用之争，是零和曲线上最经典的一次拉锯。学术派把最优定点设在语义编码极高的一侧：逻辑精准、可机器验证、稳定无歧义，相应代价是形式编码一侧（可习得性、上手速度、随需求柔性演化）显著受损—— KerML 的严密逻辑对一线工程师而言学习曲线陡峻，严谨性本身就构成门槛。工业派则把最优点设在形式编码一侧：模型要易学、要快、要服务于沟通与交付，相应代价是语义编码一侧（可被严格验证的密度与精准）被稀释——模型更多地承载「意图与共识」，而非「可证性质」。

Madni 与 Sievers（2018）在综述中已点明，MBSE 当前的关键研究机会正位于「动机与现状」之间的张力带上，而这张力本身，正是零和取舍的外显。没有一方能同时吃下严谨与易用；他们只是在曲线上选择了不同的坐标。

6.4 争议三：模型 versus 文档

6.4.1 「模型即文档」的承诺与破灭

「模型即文档（model as the document）」「单一事实来源（single source of truth）」是 MBSE 最具号召力的口号（Weilkiens 等，2015；INCOSE，2023）。其承诺是：只要模型足够权威，传统文档便可退场，工程信息不再在文档与模型之间反复同步，歧义与漂移将被根除。

但一线实践反复报告一种反讽式的回归。一份防务领域的观察指出，若缺乏明确的模型所有权、命名规范、与基线节奏挂钩的治理，模型会在约 18 个月内「事实性地重新退化为文档中心」——工程师在独立文档中维护真实设计，仅在评审前把模型更新一遍以满足合同要求（Corvus，无 DOI）。这并非个别现象：当模型治理失败，「权威模型」便与实际设计背离，模型沦为应付评审的摆设。

6.4.2 监管与认证中的文档刚性

更深层的阻力来自监管与认证体系本身。ISO/IEC/IEEE 15288（2015，及后续 2023 版）所定义的系统生命周期过程，仍以文档化的工作产品为合规载体（ISO/IEC/IEEE，2015）。航空电子的 DO-178C、汽车电子的 ISO 26262、航天领域的 ECSS 等认证框架，其符合性证据链（assurance case）本质上是一套可被审计、可被法律主体追责的文档体系（NASA，2016；INCOSE，2023）。模型在这些框架中的「法律地位」始终暧昧：它可以作为支撑性证据，却罕能替代文档成为认证的法定客体。

这一刚性有其深层理由。认证的本质是对「责任闭环」的确认——当系统失效导致事故，必须有可追溯、可被独立第三方在数年之后复核的文本证据，用以界定设计方是否尽到了合理审慎的义务。文档之所以不可替代，恰因为它在语义编码一侧提供了「稳定、高密度、可独立解读」的最小公共语义：无论原始建模工具是否仍在维护，一份 PDF 或纸质文档都能被审计员以人类语言直接读取。模型则相反，它高度依赖特定工具的语义栈与版本，一旦工具链断裂，模型的可读性便随之崩塌。于是监管者本能地把最优点钉在语义编码一侧的「可审计、可追责」极值上，而对「模型即文档」这种把形式编码便利凌驾于法律可读性之上的主张保持警惕。这并非保守，而是零和曲线在责任维度上的必然投影。

6.4.3 零和还原

「模型 versus 文档」之争，表面是 artifacts 形态的之争，实质是零和曲线在「交付媒介」维度上的投影。向「模型即文档」移动，是把形式编码一侧（单一载体、免同步、柔性演化）推向极值，代价是语义编码一侧——即认证与法律所要求的、可被独立审计主体稳定解读的语义密度与责任闭环——仍被迫留在文档中。于是出现双重维护：模型负责「活的设计」，文档负责「可被追责的证据」。这种双重维护正是零和取舍留下的残余成本，它无法被口号消除，只能在「模型生成文档」的自动化程度上被缓解，却永远无法在严格认证语境中彻底取消。

6.5 争议四：MBSE 的 ROI 与价值证明

6.5.1 怀疑论：投入巨大、收益不确定、回潮现象

对 MBSE 最具杀伤力的质疑，来自投资回报（ROI）的不可证性。一份直白的行业评论指出，当倡导者宣称 MBSE 让组织「更快、更好、更省」时，这恰好与项目管理的「铁三角」相冲突，听起来像银弹（silver bullet），因而天然招致拒斥；更关键的是，无论给出什么数字，「客观数据根本不足以支撑一个具体的 ROI」——项目规模、复杂度、团队经验、组织能力差异太大，数据点太少、变量太多（Systems-Wise，无 DOI）。

Belcan 的采用调研列出了十大采纳挑战，首当其冲的便是「显著的前期投入，包括准确估算成本与量化 ROI」，并明确指出即便在理想情形下，「完全转向 MBSE 通常也不会立即产生回报」，而早期缺陷发现带来的验证成本下降「要等到产品生命周期更晚阶段才能度量」（Belcan，2022，无 DOI）。德国科隆大学的实证研究同样发现，阻碍 MBSE 采纳的力量包括「不成熟的工具、对 ROI 的不确定、以及对迁移既有数据与流程的恐惧」（Buarque de Amorim，2021，博士论文，无 DOI）。

「回潮」是最具象的失败模式：前述防务观察显示，在项目达至转折拐点前放弃 MBSE 的团队，「承担了成本却未获得收益」，模型最终重新沦为文档（Corvus，无 DOI）。美国海军研究生院的收购研究更直白地承认，用传统 ROI 方法为建模与维护虚拟模型的额外开销辩护「是不充分的」，组织最终可能「需要一次信仰的跳跃（leap of faith）」才愿采纳（Schenker & Hugues，2023，无 DOI）。

怀疑论者还指出一个被广泛低估的现象：MBSE 的采纳阻力不仅来自经济账，更来自工程文化的肌肉记忆。资深工程师以文档中心方法成功交付过项目，他们视 MBSE 为「管理层强加的开销」而非「使工程更易的能力」——这种认知在短期内并非全无道理，因为新项目前六个月的模型基础设施搭建确实重于文档等价物（Corvus，无 DOI）。当组织缺乏高层长期 sponsorship、缺乏把模型纳入里程碑决策的纪律时，MBSE 便退化为「评审前的补作业」，其语义编码的潜在收益从未被激活，而形式编码的采纳成本却已全额预付。这正是零和曲线上「只付成本、未取收益」的危险区段。

6.5.2 倡导者：价值研究与成本规避逻辑

倡导者的论据并非空泛。Madni 与 Sievers（2018）在《Systems Engineering》上系统论证了 MBSE 的动机、现状与研究机会，为价值主张提供了学术骨架。其核心逻辑是「成本规避（cost avoidance）」：系统的错误从未发生，其成本便不可见，而 MBSE 通过早期一致性检查、接口类型约束、需求可追溯性，使大量缺陷在集成测试前被消解——这些「未发生的成本」虽难逐条入账，却是真实存在（Madni & Sievers，2018；Corvus，无 DOI）。MIT、PMI 与 INCOSE 联合发布的《Lean Enablers》以及 CMU/SEI 与 NDIA 的《The Business Case for Systems Engineering》，虽未提出具体 ROI 数字，却以可辩护的客观方式建立了系统工程的商业案例（Systems-Wise，无 DOI）。

倡导者进一步主张，价值不应以「即时金钱回报」衡量，而应以「工程决策质量的系统性提升」衡量。当模型成为可查询、可追踪、可随变更联动的权威来源，组织在需求变更、接口协调、验证规划上的响应速度将发生质变——这种质变难以被传统会计口径捕捉，却决定了一个复杂产品能否在集成阶段避免灾难性返工（Sheridan，2026，无 DOI，亦指出「可追溯性不是结果，信心才是结果」）。其实，倡导者并非否认 ROI 的难以度量，而是把语义编码一侧的「长期、隐性、系统级」收益，置于形式编码一侧「短期、显式、项目级」的账目之上。这同样是一次自觉的取舍，而非对证据空缺的掩盖。

6.5.3 「MBSE 死亡之谷」

围绕 ROI 的讨论凝结出一个形象概念——「MBSE 死亡之谷（MBSE death valley）」：从投入建模基础设施到 ROI 转正之间存在一个 12–18 个月的转折期，期间变更影响分析从「数周」缩短为「数小时」方才显现价值（Corvus，无 DOI）。跨越此谷需要三项纪律：在项目起点而非 retrofit 时启动 MBSE、在建模前先投入治理基础设施、在每个评审节点度量并报告模型覆盖率（需求分配覆盖率、接口形式化率、测试关联率）。多数失败，恰是在谷底之前撤离。

6.5.4 零和还原

ROI 之争之所以无解，正是因为它是零和曲线在「组织动态柔性」维度上的显形。MBSE 在语义编码一侧承诺的高密度、高精准（缺陷规避、可追溯），以一种「前期重投入、后期慢兑现」的方式呈现，这恰恰削弱了形式编码一侧的「可习得性」与「动态柔性」——对组织而言，学习成本高、见效慢、回退容易，本身就是形式编码脆弱的表现。倡导者与怀疑论者并非在争论「MBSE 有没有价值」，而是在争论「你愿意为语义编码的严谨，在形式编码的组织柔性上承受多大的代价」。死亡之谷，就是这条零和曲线上一段必须穿越、却无人能替你缩短的斜坡。

6.6 争议五：标准碎片化

6.6.1 SysML v1 到 v2 的过渡阵痛

SysML 自 OMG 于 2007 年发布 v1.0 起，历经 v1.6（2019）多次修订（OMG，2007–2019；OMG，2019），长期建立在其对 UML 的轻量扩展之上。这一「贴附 UML」的设计带来了易学（复用 UML 生态）的形式编码优势，却也埋下语义漂移的隐患——同一图符在不同工具中含义不一。SysML v2（2023 Beta2，2025 正式采纳）与 KerML 的引入，正是为补强语义编码一侧：以一阶逻辑确立精确语义（OMG，2023/2025；Seidewitz，2023）。

代价是剧烈的过渡阵痛：既有 v1 模型与技能大规模失效，工具链滞后，组织面临「迁还是留」的两难。这本身即是一次零和取舍的现场演绎——用语义编码的跃升，换取形式编码（既有资产、人员技能、工具就绪度）的断崖式折损。

6.6.2 方法过多：OOSEM、Harmony、Arcadia、SYSMOD……

在语言之上，方法层同样碎片化。Estefan（2008）在 INCOSE 方法论普查中系统梳理了 OOSEM、Harmony-SE、State Analysis、Statemate、ROOM、RUP 等方法谱系（Estefan，2008）。此后又涌现 Arcadia（Roques，2016）、SYSMOD（Weilkiens，SYSMOD）、Vitech 方法（Long & Scott，2011/2017）等。每种方法都声称更适配某类问题——Harmony 重实时嵌入式（Douglass，2009）、Arcadia 重体系架构与供应链协作、State Analysis 源于 NASA/JPL 实时系统（Ingham 等，2004）。

方法的繁荣在形式编码一侧表现为「可扩张性」的极致：组织总能找到贴身定制的方法。但代价是语义编码一侧的「共享语义」被切碎——跨方法、跨项目的模型难以互译，人员流动时方法知识难以迁移。

更隐蔽的一层是，方法碎片化还制造了「选择过载（choice overload）」。对于初次接触 MBSE 的组织，面对十余种都自称「最佳实践」的方法，往往不知道该从何处着手；而一旦选错方法，后续建模习惯、工具配置、评审模板便被路径锁定，切换成本极高。这种「可扩张性反而削弱了可习得性」的反讽，正是零和曲线在方法层上的扭曲投影：方法越多，单种方法的学习社群越分散，新手越难获得连贯的辅导，形式编码的「易学」反而被方法的丰富性所稀释。Browning（2001）以设计结构矩阵（DSM）揭示的系统分解与集成难题，在此获得新的注脚——方法碎片化本身，就是系统工程知识体系内部耦合过松、协调不足的症状。

6.6.3 互操作标准缺位与协调角色

碎片化的直接后果是互操作缺口。XMI（XML Metadata Interchange）虽被广泛支持为交换格式，但实践表明图符与工具特定数据在导出导入中常丢失或失真，「迁移模型可能极具挑战」（行业工具对比，无 DOI）。OMG 由此推出 Systems Modeling API & Services v1.0（2024），试图以 API 而非文件交换重建互操作（OMG，2024）。

INCOSE 与 OMG 在此扮演协调者角色：INCOSE 的 MBSE 倡议（MBSE Initiative，2007–）通过 Wiki、路线图与 Pulse Check 调研持续描摹实践版图（INCOSE MBSE Initiative，2007–）；OMG 则掌握语言与接口标准的制定权（OMG，2023/2025）。两者的张力本身也耐人寻味——标准制定者要语义严谨，实践社群要落地易用，协调只能是曲线上的折中。

6.6.4 零和还原

标准碎片化之争，是零和曲线在「可扩张性 versus 共享语义」轴向上的展开。方法与方法、版本与版本之间的自由繁衍，极致化了形式编码的可扩张性（每域皆可自适），却以语义编码的「密度与一致性」为代价（无共同语义、互操作缺位）。SysML v2 的努力方向，是用更强的语义编码去收复失地，但收复过程本身又要在形式编码侧付出迁移成本。碎片不会消失，它只会以新的形态在曲线另一端重新出现。

6.7 争议六：适用性边界

6.7.1 小项目与快节奏互联网式产品

MBSE 的适用性边界，是零和曲线上「最优点的位置随语境漂移」这一性质的直观证据。Belcan 的采用指引以三个问题帮助组织自判，首要便是「你的产品复杂吗？」——若产品并非被集成进更复杂系统的数十个构件之一，MBSE 的重型基础设施可能得不偿失（Belcan，2022，无 DOI）。对快节奏、强迭代的互联网式产品，模型.center 方法的「前期重治理、慢兑现」特征与发布节奏天然冲突；此处形式编码侧的「可习得性与动态柔性」受损过大，使 MBSE 的整体账本转负。

6.7.2 强监管安全关键领域

反观强监管的安全关键领域（航空、航天、汽车、医疗），语义编码一侧的「稳定性与可验证性」成为刚需，MBSE 的账本转正。但即便在此，模型也必须与 DO-178C、ISO 26262、ECSS 等认证框架耦合，不能脱离文档而独立成立（NASA，2016；ISO/IEC/IEEE，2015）。泰雷兹的实践更指出，单纯 MBSE 在当前能力下不足以充分保障架构质量，需以仿真（analytical models）补足描述性模型的局限（Nowodzienski & Navas，2022，无 DOI）。

6.7.3 过度建模的风险

边界问题的另一端是「过度建模（over-modeling）」。一份实践评论尖锐地指出，迷信用「描述系统一切细节」来追求完美数字孪生是陷阱——试图为每一颗螺丝、每一根线建模「根本不现实」，资源在触及系统本质前便已耗尽（One-Sys，无 DOI）。NASA 的研究亦强调「只为回答眼前问题而建模到所需深度即可」，越过此线，模型便退化为与运营现实脱节的学术练习（One-Sys，无 DOI，引述 NASA 原则）。中文工程社区亦有冷静反思：MBSE 模型难以捕捉非线性关系、过度依赖理想化假设、维护与版本控制艰巨，某些高度探索性项目因缺乏先验知识而难以建模（TSight，无 DOI）。

过度建模之所以普遍，正因为它是零和曲线在个体心理层面的诱惑：工程师面对复杂系统时，天然倾向于在语义编码一侧「多存一点、再密一点」，以为密度越高越安全；却忽视了形式编码一侧的维护成本随元素数量超线性增长——成千上万个模型元素及其相互依赖，使模型的「可理解性」与「可对齐性」迅速崩溃，最终连建模者本人都难以在模型中导航（Belcan，2022，无 DOI，亦将「大型模型可视化与导航」列为十大采纳挑战之一）。可见，边界问题从来不是「MBSE 该不该用」的二元判断，而是「在当下语境，曲线的最优最优点落在何处」的持续校准。任何把 MBSE 奉为普适银弹、或把其局限夸大为全盘失败的说法，都忽略了这条曲线随项目规模、监管强度、迭代节奏而平移的基本事实。

6.7.4 零和还原

适用性边界之争，揭示的是同一条零和曲线在不同语境下的「最优最优点」不同：对小项目与快节奏产品，形式编码的习得与柔性成本压倒收益，曲线在该语境下「右移」使 MBSE 不经济；对安全关键领域，语义编码的严谨性成为不可妥协项，曲线「左移」使 MBSE 必要。过度建模则是同一取舍在个体层面的失控——在语义编码一侧贪求密度，直至形式编码一侧（维护、对齐、可理解）崩溃。边界不是 MBSE 的缺陷，而是零和曲线随语境平移的必然投影。

6.8 各方立场梳理表

下表将六类主要利益相关方置于「形式编码 ↔ 语义编码」零和曲线上，标明其最优点站位、取舍理由与典型文献/立场来源。表中「站位」以「← 偏形式编码」到「偏语义编码 →」的连续谱表示。

下表进一步把六类争议直接映射为零和曲线上的最优点之争，便于横向对照。需要说明，表中「站位」并非精确坐标，而是对各方在曲线上相对位置的定性刻画；真实组织中常有内部张力（如大承包商内部既有追求严谨的型号团队，也有追求灵活的预研团队），故站位应为一段区间而非一个点。这张表的价值，不在于给出定论，而在于把看似散乱的立场主张，统一收束到同一条零和曲线之上。

6.9 核心论点视角收束

把上述六类争议收拢到本书的核心论点之下，一个结论无法回避：这些争议表面上林林总总——锁定与开放、严谨与务实、模型与文档、回报与投入、统一与碎片、适用与越界——但其底层结构高度同构。它们全都是同一个零和取舍曲线上「最优点之争」的不同投影。

供应商要卖的是受控的高密度语义，于是把最优点推向语义编码极值；开源社群要卖的是可自我掌控的开放柔性，于是把最优点推回形式编码极值。学术派把严谨当信仰，工业派把交付当底线；监管者把可追责性钉死在文档上，中小企业在 ROI 的谷底前犹豫撤退；INCOSE 与 OMG 在标准制定桌上做着永无终点的折中。每一个立场，都可以在「形式编码 ↔ 语义编码」这条曲线上找到其坐标，也都只能用「我们更看重这一侧」来为自己辩护。

这正是本书核心论点最锋利的含义：既然所有争议都只是不同利益相关方在零和曲线上选择了不同最优点，那么就没有任何一方能够声称自己握有「正确的终极体系」。学术派的严谨以易用性为代价，工业派的务实以可验证性为代价，开源的开放以受控支持为代价，专有的可靠以锁定为代价——每一方得到的，正是另一方失去的；每一方失去的，正是另一方得到的。争议的此起彼伏、旷日持久而终无定论，恰恰不是因为各方「尚未找到真理」，而是因为零和曲线本身否决了「同时最大化两侧」的可能性。

因此，MBSE 领域永不停息的争论，不应被读作「进步途中的噪音」，而应被读作核心论点的经验证词：符号系统必然在形式编码与语义编码之间做不可逆的零和取舍，不存在完美兼顾的终极体系。MBSE 的全部历史演进、方法分歧与能力边界，都不过是这一根本性张力在工程项目中的一次次重演。承认这一点，我们才不再追问「哪一方是对的」，而学会追问「在此时此地、此项目此语境下，我们应当把最优点放在曲线的何处」——而这，才是 MBSE 作为一门工程纪律真正成熟的标志。

6.10 认证与监管机构的视角：模型作为证据的有限法律地位

6.10.1 认证框架如何「收编」模型：以 DO-178C 与 DO-331 为例

监管机构对 MBSE 的态度，是本书所有争议中最容易被技术乐观主义忽视、却最不可回避的视角。航空电子领域的事实标准是 RTCA/EUROCAE 的 DO-178C《机载系统与环境设备认证中的软件考虑》（2011），其配套的 DO-331《基于模型的开发与验证补充》与 DO-333《形式化方法补充》构成了模型在法律上被「收编」为证据的正式通道（RTCA/EUROCAE，2011，无 DOI；LDRA，无 DOI）。DO-331 的核心立场极具象征意义：它把规约模型与设计模型分别视作高层需求与低层需求的替代物——在标准语境下「模型即需求」首次获得了认证的书面承认。然而这一承认是有条件的、局部性的，而非 MBSE 口号中那种压倒性的「模型即文档」。

具体而言，DO-331 §MB.6.8.2 规定，模型仿真对可执行目标代码（EOC）与高层/低层需求之间符合性的验证目标，只能「部分满足」，且「必须在目标硬件上额外执行验证活动以完全满足这些目标」（LDRA，无 DOI）。这意味着认证当局在承认模型价值的同时，坚决保留了「目标测试不可替代」的底线。其底层理由直白而坚硬：形式验证与模型仿真虽能排除大量缺陷，却无法揭示目标硬件特有的实现错误，认证当局因而要求以目标级测试对冲「形式化误报（formal method false positives）」（VITA Military Embedded，无 DOI）。模型由此被定位为「支撑性证据链的一环」，而非认证法定客体的整体。

6.10.2 模型作为证据的边界：工具鉴定与结构覆盖

更深的约束来自两条硬性门槛。其一为工具鉴定（DO-330 / ED-215）：凡是其输出被用作符合性证据的工具，必须在项目层面被鉴定，组织对工具的适用性自证其责（LDRA，无 DOI）。这把「模型即证据」的可靠性，从模型语义本身转移到工具链的可信性上——一旦建模工具未通过鉴定，模型再严谨也无法独立构成证据。其二为结构覆盖的不可让渡：DO-331 §MB.B.11 明确指出，模型覆盖分析通常不能取代 DO-178C §6.4.4.2 所规定的结构覆盖分析（LDRA，无 DOI）。也就是说，无论描述性模型多么完整，认证仍要求可执行的、可在目标上度量的代码结构覆盖。

把上述约束放回生命周期标准，ISO/IEC/IEEE 15288（2015 及 2023 版）所定义的系统生命周期过程，仍以文档化的工作产品为合规载体（ISO/IEC/IEEE，2015/2023）。模型在这些框架中的法律地位始终是「可被审计的支撑」，而非「可被追责的法定客体」。当系统失效导致事故，必须有可被独立第三方在数年之后以人类语言直接复核的文本证据，用以界定设计方是否尽到合理审慎义务——文档在语义编码一侧提供的「稳定、高密度、可独立解读」的最小公共语义，模型则高度依赖特定工具语义栈与版本，一旦工具链断裂便可读性崩塌（NASA，2016；INCOSE，2023）。这正是监管者把最优点钉死在语义编码极值的根由。

下表归纳三类认证门槛对「模型即证据」的实际收口方式，便于看清监管视角的刚性结构。

6.10.3 零和还原

认证与监管视角，是零和曲线上最偏语义编码一侧的极端站位。监管者关心的不是「模型是否让工程更快」，而是「当系统失效、诉诸法庭时，能否追溯出一份可被独立主体稳定解读、可界定责任的证据」。这一关切天然把最优点推向语义编码极值：可审计、可追责、可长期独立读取。MBSE 主张的「模型即文档」试图把形式编码一侧的便利（单载体、免同步、柔性演化）凌驾于法律可读性之上，于是撞上认证的刚性墙——墙之所以刚性，不是因为监管保守，而是因为责任闭环这一维度上，模型的工具依赖性恰恰是其语义编码弱项的显形。

因此，监管视角与 MBSE 之间的张力，绝非「开明监管 versus 顽固旧法」的代际冲突，而是零和曲线上两个最优点的对峙：你究竟更看重被托管的高密度受控语义（文档+鉴定工具链），还是可自我演进的开放柔性（模型即单一来源）。认证框架对模型的「收编」——既承认其价值、又限制其法律效力——正是这条曲线在责任维度上寻得的、永不稳定且需逐项目重谈的折中。

6.11 学术会议与社区中的立场光谱，以及过度形式化的反例

6.11.1 会议光谱：INCOSE IS 与 MODELS 的议题分野

争议之所以长期无定论，一个重要原因是不同社群在零和曲线上「各选其位」且物理上分处不同会场。两条最具代表性的会场谱系，清晰映射出形式化派与务实派的议题分布。

其一为 INCOSE 国际年会（INCOSE International Symposium, IS）。该会的选题明显偏向工程落地与务实采纳：IS 2024 的技术程序中出现了「MBSE for Real World Teams」「Model-Based Switching Costs」「Models Models Everywhere! A practitioners view on the reality of modeling」等议题，IS 2025 更设有「SysML v2 Case Studies and Applications」「Making SE/MBSE Work: Practical Small-Start Adoption in Japanese Manufacturing」等务实导向分会场（INCOSE IS 2024/2025，无 DOI）。其关切是「真实团队如何用、迁移成本多大、小步起点如何落地」，本质是形式编码一侧（可习得、可扩张、动态柔性）的站位。

其二为 MODELS 会议（模型驱动工程领域旗舰，前身即 UML 会议）。其议题分布则集中于形式语义、一致性、可执行与工具链：MODELS 2023 的工具与演示轨道涵盖了「Uncertainty-aware consistency checking in industrial settings」「A generic framework for representing and analyzing model concurrency」「Multi-Dimensional Multi-Level Modeling」「gLTSdiff：软件行为的结构化比较框架」等（MODELS 2023，无 DOI）。这些题目共享一个底层取向——把模型当作可被精确定义、可被机器一致性检查与变换的对象，本质是语义编码一侧（逻辑精准、可机器验证）的站位。

两张频谱并置，恰好印证本书核心论点：同一套 MBSE 话语，在务实派会场被读作「沟通与交付的使能器」，在形式化派会场被读作「可被严格判定的逻辑对象」。两者并非在同一维度上争论高低，而是在零和曲线上占据不同坐标。INCOSE IS 与 MODELS 的并存本身，就是取舍分歧的制度化外显。

6.11.2 过度形式化的反例：从「形式化但不过度形式化」到规模爆炸

形式化派的立场虽有学术正当性，却存在被自身推向极端的真实风险。最值得引为训诫的，是形式化方法社群内部的清醒自省。Bowen 与 Hinchey（1995）在《IEEE Software》发表《形式化方法的七个更多迷思》，其中「迷思八」正面承认：确有若干形式化项目严重超期，但根因并非形式化本身拖慢进度，而是「开发者缺乏估算开发所需工期的经验」——历史数据稀缺使成本与时间估算失准（Bowen & Hinchey，1995，无 DOI）。更关键的是，二人提出的「形式化方法十诫」第二条即为「形式化，但不可过度形式化（formalise, but not overformalise）」，并强调须「估算成本」「常备形式化专家（guru）」——这等于从形式化方法内部承认：形式化投入若越过与问题相称的抽象层级，便会反噬交付（Bowen & Hinchey，1995，无 DOI）。

规模爆炸是过度形式化最直观的反例。Bowen 在另一份综述中引述 ProCoS 等级抽象数据：约 1.5 万行（非形式）需求，对应约 15 万行形式化规约、150 万行设计描述、1500 万行高层程序代码（Bowen，无 DOI）。当规约体量较原始需求膨胀两个数量级，模型的「可理解性」与「可对齐性」随元素数量超线性恶化——建模者本人都难以在模型中导航，遑论跨专业干系人。这正是本章 6.7.3 节所谓「过度建模」在形式化维度的镜像：在语义编码一侧贪求密度，直至形式编码一侧（维护、对齐、可理解）崩溃。

工业界的同类观察相互印证：Belcan 将「大型模型可视化与导航」列为十大采纳挑战之一，正是因维护成本随元素数量超线性增长（Belcan，2022，无 DOI）；TSight 亦指出 MBSE 模型过度依赖理想化假设、难以捕捉非线性关系，某些探索性项目因缺乏先验知识而根本无法建模（TSight，无 DOI）。当学术派把 KerML 的一阶逻辑严谨性推到极致，一线团队被迫以同等习得成本换取可验证性，形式编码一侧的可习得性被压到很低——这正是零和铁律在个体层面的重演。

6.11.3 零和还原

学术会议光谱与过度形式化反例，共同把本书核心论点推向最锋利处。INCOSE IS 与 MODELS 的分野证明：形式化派与务实派并非在「谁更正确」上对立，而是在零和曲线上各取最优点——前者押注语义编码的精准可证，后者押注形式编码的易用可交付。而 Bowen 与 Hinchey 的「十诫」与 ProCoS 的规模爆炸提醒我们：即便在语义编码一侧，也不存在「越密越安全」的单调增益；越过与问题相称的抽象层级，形式化投入便从「严谨」异化为「压垮交付的负担」，这正是零和曲线在个体心理上的诱惑与陷阱。

至此，本章六类争议之外，再添两条经验证词：监管者以责任闭环把最优点钉在语义编码极值，会议社群以物理分场把分歧制度化，过度形式化则以规模爆炸示警「密度并非免费」。它们无一例外，都是同一条零和取舍曲线上「最优点之争」的投影——没有哪方握有正确体系，只有各自的取舍。

第7章 MBSE 的未来发展方向

7.1 引言：零和张力不会在未来终结

本书贯穿全书的核心论点是一个冷峻而不可回避的判定：任何符号系统都必然在形式编码一侧（可习得性、可扩张性、动态柔性）与语义编码一侧（稳定性、高密度性、逻辑精准性）之间做出不可逆的零和取舍，不存在完美兼顾终极体系。MBSE 作为符号系统在工程领域的典型实例，其全部历史演进、方法分歧与能力边界，都可以归结为这一根本性张力。越是强化形式编码一侧，让建模语言容易学习、容易扩展、能够随需求柔性演化，就越削弱语义编码一侧，表现为语义不稳、密度稀释、逻辑校验失准；反之，越是追求语义编码的严谨，引入形式化语义、可执行性与机器可验证性，就越牺牲形式编码的可习得性与可扩张性。

本章的任务不是描绘一幅技术乌托邦式的路线图，而是把上述核心论点投射到 MBSE 的未来。读者将在下文中看到，所谓"未来发展方向"，无论是语言收敛到 SysML v2 与 KerML、形式化方法的适度下沉、AI 辅助建模的兴起、互操作与开放标准的推进、领域特定语言的繁衍、认证监管的适配、与数字孪生及仿真的融合、还是组织能力的演进，实质上都不是对零和张力的超越，而是这一张力在新的技术与社会条件下的重新配置。未来不会终结零和，只会在取舍曲线上寻找更优的折中，并通过人机分工把代价转移或隐藏。这是本章反复回到、也必须反复强调的结论。

7.1.1 重述核心论点与分析坐标系

为便于后续论证，先把核心论点中的"六性"明确列出，作为贯穿全章的分析坐标：

• 形式编码三性：可习得性（语言是否被工程人员低成本学会）、可扩张性（语言能否被低成本地扩展以覆盖新域）、动态柔性（语言能否随需求变更柔性演化而不崩塌）。

• 语义编码三性：稳定性（同一符号在不同上下文与时间中语义是否稳定）、高密度性（单位符号承载的确定语义量）、逻辑精准性（语义能否被机器精确判定、可执行、可验证）。

这六性构成一个此消彼长的集合。任何单点技术改进，若提升了其中某一侧的一项，几乎必然以另一侧的一项或多项为代价。本章对每一项未来方向的评估，都以上述六性为标尺，最终以一张"未来举措—六性影响"表收束（见 7.10.2 节）。

7.1.2 为何"突破零和"是错觉

在展开具体方向之前，必须预先澄清一种常见的乐观叙事：许多技术报告暗示，随着 AI、形式化方法与工具链成熟，MBSE 终将同时获得语义严谨与易用易扩。这种叙事混淆了"局部优化"与"全局突破"。形式编码与语义编码的零和，根植于符号表征本身的数学与认知约束——高密度、稳定、可机器验证的语义，必然要求符号被严格限定（从而难学、难扩、难随需求柔性变化）；而易学、易扩、柔性演化的符号，必然放松约束（从而语义不稳、密度稀释、校验失准）。这一约束不随算力、算法或标准的进步而消失，正如自然语言的灵活永远以歧义为代价，形式语言的精确永远以刻板为代价（Hall，1962；Wymore，1993；Dori，2016）。因此本章对未来的判断是收束性的：在取舍曲线上移动，而非脱离曲线。

7.2 语言收敛与语义底座：SysML v2 与 KerML 的双刃

MBSE 未来最确定的语言走向，是 SysML v2 与作为其内核的 KerML 成为更坚实的形式语义底座。根据 OMG 的规范，SysML v2 于 2025 年 7 月正式采纳，其底层内核语言 KerML 以一阶逻辑与四维（4D）时空外延（four-dimensional spatiotemporal extent）来定义形式语义（OMG，2023/2025；Seidewitz，2023）。这一跃升在语义编码一侧意义重大：它把 SysML 从 v1 基于 UML 半形式化继承的状态，推进到可由机器精确判定的语义层（OMG，2023；Friedenthal 等，2014/2018）。

7.2.1 形式语义的跃升：一阶逻辑与 4D 时空外延

KerML 采用一阶逻辑作为语义内核，意味着模型中的元素、关系与约束可被形式化地定义与推理；4D 时空外延则把系统的"存在"统一表述为跨越时间与空间的个体（individuals），从而让状态演化、时序与配置变化获得一致的数学处理（OMG，2023/2025；Seidewitz，2023）。相对于 SysML v1 依赖 UML 元模型且语义常诉诸自然语言解释的局面，这是语义编码一侧稳定性、高密度性与逻辑精准性的显著抬升（Broy & Cengarle，2010；Evermann，2009）。Madni 与 Sievers 所归纳的 MBSE 研究机会中，"语义一致性"与"可执行模型"长期居首，而 KerML 正是朝此方向的制度性回应（Madni & Sievers，2018）。

7.2.2 学习门槛与扩张约束：更坚实的底座仍是零和

然而，形式语义的强化立即在形式编码一侧收取代价。一阶逻辑与 4D 外延的引入，使建模者需要理解此前 SysML v1 使用者无须掌握的逻辑与本体论概念，可习得性下降；KerML 的严格元模型与受限扩展点，使语言在覆盖新工程域时的可扩张性受限，工程人员不能再像在 v1 中那样宽松地自定义构造型（stereotype）而仍自视为"合规"（OMG，2023；Holt 等，2011/2012）。动态柔性同样受损：当语义必须保持逻辑一致，需求频繁变更时的柔性演化更易触发一致性冲突，模型反而更难"随改随走"（Borky & Bradley，2018）。

换个说法，SysML v2 与 KerML 把零和曲线向语义编码一侧显著推移——这是其价值，却也正是其代价。它不消灭零和，只是在新的工程共识下重新定位取舍点。对中小团队或非关键安全域而言，这套更坚实的底座可能"语义过强而习得过难"，从而逼迫它们在形式化底座与可落地性之间再做二次取舍（Estefan，2008；INCOSE，2021）。

7.2.3 收敛的代价：方法多样性的流失

语言收敛还隐含一种结构性代价。MBSE 历史上方法谱系极为多样，OOSEM、Harmony-SE、State Analysis、Arcadia、SYSMOD 等各有侧重（Estefan，2008；Ingham 等，2004；Roques，2016；Weilkiens，2011）。SysML v2 的标准化语义底座倾向于把方法差异"压平"为对同一种内核的封装，这提升了互操作（语义一致），却削弱了方法层面的可扩张性与多样性（形式编码一侧的另一种损失）（Dori，2016；INCOSE，2023）。未来的现实很可能是：少数关键域采用 v2 严格底座，大量轻量实践仍保留 v1 或自创方言——零和以"标准 vs 事实方言"的分裂形式继续存在。

7.2.4 迁移负担与生态惯性：收敛的另一重形式编码代价

语言收敛还带来一项容易被路线图忽略、却极为沉重的现实代价：从既有存量模型与投资向新底座迁移的成本。航空、汽车、防务领域已积累以 SysML v1 及私有元模型构建的海量模型资产、训练教材、工具插件与组织惯例，向 v2 严格语义底座迁移，不是语法转写，而是语义重述——因为 v1 中大量依赖非正式约定与工具特有扩展，在 v2 形式语义下可能根本无法被精确判定（OMG，2023；Friedenthal 等，2014/2018）。这意味着可扩张性在"向前兼容"维度上严重受损：旧资产难以低成本延续，新底座的采纳被迫以割裂历史为代价（Estefan，2008；Borky & Bradley，2018）。生态惯性使理论上的"更优底座"在实践中被拖慢，组织不得不在"语义严谨的新世界"与"可延续的旧资产"之间再做一次零和取舍。这也反向说明：语言层面的收敛并不能消除张力，只是把张力从"方法多样"转移到"迁移割裂"。

7.3 形式化方法的"适度下沉"

形式化方法在 MBSE 中的未来，不是全面接管，而是"适度下沉"：在关键安全与任务关键域引入可执行、可验证模型，在沟通与概念探索层保留非形式化表达。这一分层策略本身，正是对零和张力的工程化承认。

7.3.1 关键安全域的可执行可验证模型

航空、航天、核电、轨交、防务等任务关键域，对语义编码三性的需求压倒一切。此处形式化方法（如状态图形式语义、模型检验、定理证明）的下沉具有正当性：模型需可执行以暴露时序与死锁缺陷，需可机器验证以作为安全论据（Harel & Politi，1998；Ingham 等，2004；DoD，2018）。这些域愿意支付可习得性与可扩张性的代价，换取稳定性、高密度性与逻辑精准性（Borky & Bradley，2018；Schäfer & Wehrheim，2009）。

7.3.2 沟通层保留非形式化表达

相反，在需求探讨、干系人沟通、早期概念权衡阶段，非形式化表达（自然语言、草图、叙事）的可习得性与动态柔性无可替代。强行把一切形式化，会使干系人失去参与的低成本入口，造成"模型很好但无人理睬"的脱节（Madni & Sievers，2018；Kossiakoff 等，2011）。因此未来健康的 MBSE 实践，是在同一工程脉络中分层：上层沟通用非形式，下层验证用形式，二者通过可追溯链接衔接（Holt 等，2011/2012；INCOSE，2023）。

7.3.3 分层策略下的零和再分配

"适度下沉"并未消除零和，只是把零和从"个体认知"转移到"体系分层"。体系整体同时持有形式层与非形式层，看似"兼顾"，实则付出了双层维护、双层一致性的新代价：非形式层与形式层之间的语义映射本身就需要被验证，否则会引入新的不一致（Borky & Bradley，2018；Evermann，2009）。分层使单点代价被隐藏，却未使总代价消失。这是未来方向中反复出现的母题——代价被转移，而非消除。

7.3.4 形式化下沉的边界：何时不该形式化

核心论点进一步要求回答"何时不该形式化"。并非所有模型都值得被推入语义编码一侧。对于探索期、低后果、频繁变更的概念，强行形式化会令可习得性与动态柔性双重崩塌，而换得的稳定性与精准性在该阶段几无用处（Madni & Sievers，2018；Kossiakoff 等，2011）。适度下沉的真义，是让形式化的深度与系统风险、变更频率、后果严重度成正比——高风险核心下沉到底，边缘探索留在表层（DoD，2018；Borky & Bradley，2018）。这本身仍是一种零和管理：组织在"哪一层形式化"上做决策，等于在"牺牲哪一侧的哪一性"上做决策。未来工具若能提供"按风险自动调节形式化深度"的能力，也只是把这一决策自动化，并未让决策消失。把边界意识写进方法学，比盲目追求"全形式化"更接近成熟。

7.4 AI 辅助建模与人机协作

人工智能，尤其是大语言模型，是近年 MBSE 未来叙事中最被寄予厚望的方向。其典型主张是：AI 承担形式编码的繁重劳动（自动生成模型、一致性检查、模式抽取），人类负责语义把关。本章的立场是：这本质上是把零和取舍"分工化"，而非消除；它转移了谁承担代价，却没有减少代价本身。

7.4.1 AI 承担形式编码的繁重劳动

已有实证研究表明，LLM 能显著提升建模初稿的生成速度。Crabb 与 Jones 在 SoSE 2024 的受控实验中，让三组系统工程师分别"自由使用 LLM""接收 LLM 草稿""按常规流程"完成需求与用例建模，由主题专家按完整性、一致性、正确性、简洁性与可追溯性评分，结论是 LLM 虽不能替代受过训练的系统工程师，却能在远短时间内生成构建最小可用产品模型所需的大量信息，并回答领域细节问题、减少外部研究耗时（Crabb & Jones，2024，DOI: 10.1109/sose62659.2024.10620975）。Longshore 等则探索用检索增强生成（RAG）让 LLM 生成、修改与查询 SysML v2 模型，展示在领域知识注入后模型准确率提升、提示次数下降（Longshore 等，2024，无 DOI，美国海军研究生院技术报告：https://dair.nps.edu/handle/123456789/5113）。Johns 等将 GPT-4 Turbo 集成进 CATIA Magic，构建 AI-SME 助手，能生成需求、块定义图与内部块图，证实 AI 可提升 SysML 创建的速度与准确度（Johns 等，2024，DOI: 10.1002/iis2.13201）。

7.4.2 人类负责语义把关

上述文献几乎一致承认：AI 生成物存在冗余、缺乏内聚、语义不可靠等缺陷，必须由专家在环（human-in-the-loop）把关（Crabb & Jones，2024；Johns 等，2024；Longshore 等，2024）。Bell 等构建的 SysEngBench 基准专门评估 LLM 在系统工程师所需的任务（需求分析、架构设计、风险管理、干系人沟通）上的能力，其结论恰是揭示当前 LLM 在专门化系统工程语境中的能力与局限，提示"需专家在环"方能落地（Bell 等，2024，无 DOI，美国海军研究生院报告：https://dair.nps.edu/handle/123456789/5135）。Wach 等进一步指出，LLM 在系统工程任务上的表现存在明显的专长与成本权衡，量化等压缩手段亦在准确度与算力成本间再取舍（Wach 等，2024，INCOSE 国际研讨会论文）。

7.4.3 分工化而非消除：零和被转移

把 AI 辅助建模放回核心论点框架，可以看出其真实作用：AI 吸收了形式编码一侧最繁重的劳动（可习得性的"学习成本"由 AI 承担，可扩张性的"扩展劳动"由 AI 承担，动态柔性的"随改随生成"由 AI 承担），从而让人类得以把认知资源集中于语义编码一侧（稳定性、高密度性、逻辑精准性的把关）。但这不意味着零和被突破——它只是被"分工化"：原本落在单一人类建模者身上的双重负担，被拆分到"AI 做形式、人做语义"的协作链上。总代价仍在：AI 的形式化产出仍需人类以语义劳动来校正，且校正成本随 AI 产出量的增加而上升（Crabb & Jones，2024；Johns 等，2024）。更深一层看，当 AI 让"生成模型"变得廉价，模型的语义密度与稳定性反而可能因海量低质生成而稀释——形式编码一侧的扩张性被 AI 放大，语义编码一侧却可能因此承压。零和以"数量掩盖质量"的形式重现。

7.4.4 前沿文献的共识与本章的收束判断

综合前沿文献，AI/MBSE 研究的共识可概括为三点：其一，LLM 在形式编码劳动上确有加速价值；其二，专家在环不可或缺；其三，当前 LLM 在系统工程的专门语义上仍不可靠（Crabb & Jones，2024；Longshore 等，2024；Johns 等，2024；Bell 等，2024）。本章据此判断：AI 是零和张力的"搬运工"而非"终结者"。它优化折中、隐藏代价、转移负担，却不在数学与认知层面消解形式编码与语义编码的此消彼长。任何宣称"AI 让 MBSE 既严谨又易用"的叙事，都须被还原为对某一侧代价的重新分配。

7.4.5 幻觉、伪一致与可习得性的陷阱

进一步审视 AI 辅助建模，还须警惕两类被乐观叙事淡化的风险。其一，大语言模型的"幻觉"在建模语境中表现为生成语法看似合法、语义却错误的模型片段，且因其流畅自然而更容易骗过非专家审阅者——这恰恰是语义编码稳定性与逻辑精准性被形式编码可习得性"反噬"的典型机制（Crabb & Jones，2024；Johns 等，2024）。其二，AI 擅长制造"伪一致"：把不一致的需求用表面通顺的语言缝合，使一致性检查工具因输入形式合法而放行，实则将矛盾埋入深层（Bell 等，2024；Wach 等，2024）。当 AI 把形式编码的繁重劳动压到近乎零成本，可习得性的门槛被降至极低，但语义编码一侧的校验责任却因此更重、更易被忽略。AI 在此不是消解零和，而是把零和的两端拉得更开：一端极廉价的生成，对应一端极高昂的把关。组织若只看见前者，便会为后者的隐性代价付出工程事故级别的偿还。

7.5 互操作与开放标准

互操作与开放标准，是 MBSE 未来被反复强调的方向：跨工具 API、模型交换标准、数字主线（digital thread）贯通，被视作释放模型价值的钥匙（DoD，2018；OMG，2024；OpenMBEE，2020s）。然而这一方向同样深陷零和。

7.5.1 跨工具 API 与模型交换

SysML v2 配套的 Systems Modeling API & Services（OMG，2024）意图以标准化接口消解工具锁定，使模型可在不同厂商工具间流动。这提升了形式编码一侧的可扩张性（新工具易接入）与动态柔性（模型易迁移）。但代价是：跨工具语义一致要求所有工具对 KerML 形式语义有共同、精确的实现，任一工具的实现偏差都会在执行层暴露语义不稳（Evermann，2009；Broy & Cengarle，2010）。开放（易接、易扩）与语义一致（稳、准）在此直接冲突。

7.5.2 数字主线贯通

数字主线旨在把需求、设计、分析、制造、运维的全生命周期数据以模型为纽带贯通，使溯源与一致性可机检（DoD，2018；Madni 等，2019；Grieves，2014）。这是语义编码高密度性与稳定性的强力追求。但其达成前提是全链路采用兼容的形式语义与本体，这反过来压制了各阶段工具的可扩张性与动态柔性——环节越多，任一环节的柔性变更越可能引发主线断裂（Schäfer & Wehrheim，2009；INCOSE，2021）。

7.5.3 开放与语义一致的张力

开放标准的历史反复证明：标准越开放、越易采纳，其语义约束就越松，否则无人采用；约束越紧，语义越准，采纳门槛越高（Estefan，2008；Dori，2016）。互操作与开放标准推进 MBSE 的未来，却始终在"广采纳（形式编码）"与"强语义（语义编码）"之间摇摆。这不是工程疏忽，而是零和张力的制度呈现。

7.5.4 语义中间件与映射层的隐性代价

为兼顾开放与一致，工程实践常引入语义中间件或本体映射层，把异构工具的数据翻译到统一语义空间（OpenMBEE，2020s；Guizzardi，2007）。这看似化解了零和，实则把代价转移到映射层：映射规则本身必须被形式化定义并持续维护，否则翻译即引入语义漂移（Evermann，2009；Schürr，1994）。当工具与标准演进，映射层需同步更新，动态柔性在"保持互通"的约束下被削弱；而映射规则越严谨，其自身的可习得性与可扩张性越低（Holt 等，2011/2012）。数字主线若要贯通多代工具与多套本体，映射层将膨胀为新的复杂性黑洞，其维护成本最终会逼近甚至超过模型本身（Schäfer & Wehrheim，2009；INCOSE，2021）。可见开放标准并未让零和消失，只是让它在"翻译治理"这一此前不被计价的环节重新显形。

7.6 领域特定语言与通用语言的张力

领域特定语言（DSL）的繁衍，是 MBSE 面向具体工程域的自然演化：电力有 Modelica，航电有专门剖面，安全有形式化 DSL（Modelica Association，2017；Harel & Politi，1998）。DSL 与通用语言（如 SysML）的张力，是零和在同一体系内部的再现。

7.6.1 高语义密度但低可习得、低可扩张

DSL 为特定域定制，单位符号承载高度确定且密集的语义，逻辑精准性高，稳定性好——语义编码三性占优。但代价是：学习者必须掌握该域专有概念，可习得性低；语言被域边界锁死，跨域可扩张性差；需求一旦溢出域外，动态柔性骤降（Dori，2016；Borky & Bradley，2018）。

7.6.2 通用语言反之

通用语言反其道而行：以宽松、可扩展的构造覆盖广域，可习得性与可扩张性占优，动态柔性好。但同一符号在不同域中语义被稀释、被重新解释，稳定性、高密度性、逻辑精准性受损（Wymore，1993；Holt 等，2011/2012）。

7.6.3 体系内部零和的再现

当组织同时部署多种 DSL 与一种通用语言，零和以"方言生态"的形式再现：通用语言负责广连接（形式编码），DSL 负责深语义（语义编码），二者间的翻译与一致性维护成为新的隐性代价（Schürr，1994；Evermann，2009）。未来 MBSE 不会消灭 DSL 与通用语言之争，只会在"通用底座 + 领域剖面"的架构下，把零和封装进分层——代价仍在翻译层与治理层。

7.6.4 剖面膨胀：通用语言的形式化重负

顺带补一句，"通用底座 + 领域剖面"的折中方案自身也会滑向零和的另一极。随着领域增多，剖面（profile）不断叠加，通用语言被层层定制，最终使用者面对的并非"易学的通用语言"，而是"被剖面改写到难以辨认的专有方言"，可习得性在剖面累积中悄然丧失（OMG，2023；Dori，2016）。更糟的是，多剖面叠加时语义约束可能彼此冲突，稳定性与逻辑精准性反受损害，因为不同剖面基于不同本体假设（Guizzardi，2007；Evermann，2009）。于是 DSL 与通用语言之争并未真正和解，而是以"剖面膨胀导致通用语言 DSL 化"的方式收敛——零和仍在，只是换了宿主。这提醒标准制定者：追求"一套语言覆盖所有域"的冲动，恰是形式编码可扩张性诱惑下的典型陷阱，其终点往往是语义混乱而非语义统一。

7.7 认证与监管适配

模型作为合规证据的法律地位演进，是 MBSE 未来不可回避的制度方向。监管对"模型即文档"的接受度，将直接塑造取舍曲线的位置。

7.7.1 模型作为合规证据

防务数字工程战略已明确把模型视为权威信息源（authoritative source of truth），使模型在认证中逐步替代传统文档（DoD，2018）。这要求模型具备可被监管方机器验证的语义，从而把曲线强力推向语义编码一侧：稳定性、高密度性、逻辑精准性成为合规门槛（Borky & Bradley，2018；ISO/IEC/IEEE 15288:2015）。

7.7.2 监管对"模型即文档"的接受度

然而监管接受模型，前提是模型语义可被独立复现与审计，这抬高了形式化门槛，压低了可习得性与可扩张性——中小供应商可能无力负担合规模型，反而被排除在生态外（Madni & Sievers，2018；INCOSE，2023）。认证越强调"模型即证据"，零和越向语义侧倾斜，形式编码一侧的包容性地被牺牲。这是制度层面对核心论点的又一次印证：合规的严谨以生态的包容为价。

7.7.3 监管分歧与跨境互认的二次零和

若把视野拉到跨国与跨行业，认证适配还会触发第二层零和。不同监管机构、不同行业对"可接受的模型证据形态"有不同本体假设与严格度：航空适航强调追溯与形式论证，汽车功能安全偏重故障树与证据包，防务数字工程侧重权威源与主线（DoD，2018；ISO/IEC/IEEE 15288:2015）。当供应商需同时满足多套要求，要么为每个监管域维护一套语义侧重的模型（可扩张性与动态柔性受损），要么构建一套试图"通吃"的模型再分别裁剪（稳定性与逻辑精准性在裁剪中受损）（Borky & Bradley，2018；INCOSE，2023）。跨境互认更使问题复杂：甲方的"已验证模型"未必被乙方监管承认为"可证证据"，因为底层形式语义与本体并未对齐（Guizzardi，2007；Evermann，2009）。监管适配因此不仅在"严谨 vs 包容"上取舍，还在"单一监管深度 vs 多监管广度"上再取舍。零和在此呈现为嵌套结构，而非单一维度。

7.8 与数字孪生、仿真、数据科学的深度融合

MBSE 与数字孪生、仿真、数据科学的融合，是未来最具想象空间的方向，但其底层仍是零和。

7.8.1 数字孪生

数字孪生以运行态数据持续校准模型，使模型与物理系统高度一致，强化语义编码的稳定性与高密度性（Madni 等，2019；Grieves，2014）。但要维系孪生，需模型具备持续演化的动态柔性，且孪生语义须跨设计—运行两域一致，这对可习得性与可扩张性提出极高要求（Madni 等，2019；Schäfer & Wehrheim，2009）。

7.8.2 仿真

仿真把 MBSE 模型推向可执行，逻辑精准性提升，但仿真模型的构建与校准本身是重形式化劳动，可习得性与动态柔性受限（Borky & Bradley，2018；Modelica Association，2017）。

7.8.3 数据科学

数据科学为 MBSE 注入实证与预测，提升语义密度；但数据驱动的不确定性与模型形式语义的确证性之间存在张力——统计相关不等于逻辑可证，语义编码一侧的"精准"被统计近似稀释（Madni & Sievers，2018；INCOSE，2021）。融合越深，零和越以"经验—形式"的对立呈现。

7.8.4 融合的总体判读：以复杂度换取语义深度

把数字孪生、仿真、数据科学三项融合放在一起看，其共同特征是：都以引入额外复杂度（运行数据管道、求解器、统计模型）来换取语义编码一侧的深度（与物理一致、可执行、经验密集）。这是用"体系复杂度"这一形式编码衍生的负担，去购买"语义强度"。复杂度本身又会反过来伤害可习得性与动态柔性——运维一支贯通仿真与孪生的模型链路，需要远超传统文档工程的能力栈（Madni 等，2019；Schäfer & Wehrheim，2009）。因此融合方向同样不脱离零和：它在"语义深度"与"组织可承受的复杂度/可习得性"之间置换。对未来持审慎态度的组织，应当把融合严格限定在高价值、高风险的环节，而非全链路铺开，否则将因复杂度失控而同时失去形式编码的轻盈与语义编码的可靠。

7.9 组织能力与文化演进

技术方向最终落于组织：人才、治理、度量，决定零和曲线在组织内的实际位置。

7.9.1 人才

MBSE 人才的稀缺，本质是形式编码可习得性不足的组织映射。培训体系若强推形式化语义，门槛高、成才慢；若只教工具操作，模型语义稀薄、不可验证（Madni & Sievers，2018；Kossiakoff 等，2011）。人才策略不得不在"深语义专才"与"广覆盖应用者"间配比，仍为零和。

7.9.2 治理

治理决定模型何时形式化、何时留非形式。过度治理把一切推入语义侧，牺牲柔性；治理缺位则模型失稳、不可验证（INCOSE，2023；Borky & Bradley，2018）。治理本身是零和的调节器，而非消除器。

7.9.3 度量

缺乏度量，组织无法感知自身在取舍曲线上的位置。但度量本身消耗资源，且度哪些"性"就强化哪些"性"（Henderson & Salado，2020，价值证据综述）。度量导向即取舍导向，仍受零和约束。

7.9.4 文化成熟的标志：把"不完美"制度化

组织层面最深刻地体现核心论点的，是文化对"不完美"的态度。许多 MBSE 推行失败，源于组织潜意识里仍相信存在"完美模型"——可学、可扩、柔性、稳定、密集、可证六者兼得，于是反复在工具与方法间跳跃寻租，始终不得其门（Madni & Sievers，2018；INCOSE，2023）。成熟的组织则把"已知的不完美"写入过程资产：明确记录本模型在哪些性上做了妥协、妥协的边界与风险由谁承担。这种把零和"显式化、责任化"的做法，虽不增加任何一性的绝对水平，却显著降低因幻象导致的返工与信任崩塌（Estefan，2008；Borky & Bradley，2018）。可以说，组织能力的终极指标，不是模型多严谨或多易用，而是组织能否清醒地说出"我们牺牲了什么、为何牺牲、由谁买单"。这正是核心论点在组织文化中的落脚点。

7.10 核心论点收束：未来不是突破零和，而是优化折中

本章遍历语言收敛、形式化下沉、AI 协作、互操作、DSL 之争、认证适配、跨域融合与组织演进八大方向，结论高度一致：没有任何一个方向终结形式编码与语义编码的零和，它们只是把取舍点沿曲线移动，或把代价转移到分层、翻译、治理、人机分工等隐蔽处。MBSE 的未来，不是发现"终极体系"，而是在六性之间持续地、自觉地做更优折中。

7.10.1 设计哲学层面的建议

基于核心论点，本章提出四条设计哲学建议，供从业者与标准制定者参考：

第一，承认取舍。停止追求"既严谨又易用"的幻象，公开陈述每一项决策牺牲了哪一"性"。只有承认零和，才能负责任地管理它（Wymore，1993；Dori，2016）。

第二，按需配比。不同域、不同阶段对六性的权重不同：任务关键域重语义三性，早期沟通域重形式三性。应以风险与价值驱动配比，而非统一标准（Madni & Sievers，2018；DoD，2018）。

第三，可演进。取舍点应随项目成熟而移动——早期偏形式编码以换取速度，后期偏语义编码以换取可信。架构须支持这种迁移而不崩塌（Borky & Bradley，2018；INCOSE，2021）。

第四，可接受不完美。任何体系都保有未被覆盖的"性"，应把不完美列为已知风险并留痕，而非假装已被消除。终极体系不存在，这是工程成熟的标志而非失败（Hall，1962；Estefan，2008）。

上述四条并非操作清单，而是一种设计姿态：把零和从"潜意识里的焦虑"转为"显式可讨论的工程参数"。当团队能就"本项目此刻应牺牲可扩张性以换取稳定性，还是相反"展开有理据的争论，MBSE 才真正从"工具运动"走向"工程纪律"（Wymore，1993；Dori，2016）。设计哲学的价值，正在于它不承诺消除张力，而承诺让张力可见、可控、可问责。

7.10.2 未来举措—六性影响表

下表把本章讨论的主要未来举措，逐一映射到对六性的预期影响。符号说明：↑ 表示预期增强，↓ 表示预期削弱，→ 表示基本持平或双向抵消，± 表示短期与长期方向相反（短期升、长期因代价显化而回落）。该表旨在使零和张力可见、可管，而非宣示某举措能"全赢"。

由表可见，没有任何一项举措能在六性上同时全↑。每一行都至少在一侧付出↓的代价，这正是核心论点的量化呈现。MBSE 的未来，属于那些能清醒读表、按需配比、并坦然接受不完美的实践者；而不属于等待"终极体系"降临的幻想者。

7.10.3 全章结语

回到本书核心论点：符号系统的零和取舍不可逆，MBSE 的全部演进都是这一张力的展开。本章考察的每一未来方向，都印证而非反驳该论点。我们因此得到全书最朴素的结论——未来不终结零和，只优化折中；而优化的艺术，在于承认代价、分配代价、并把代价安置在最能承受它的地方。这正是 MBSE 作为工程符号系统，走向成熟的唯一诚实路径。

7.11 形式化方法的经济学：成本—收益拐点

本章前述各节反复出现"适度下沉""按需配比""可接受不完美"等判断，但"适度"究竟适度到何处、"按需"究竟依何标准，不能停留在工程直觉层面。本节把形式化方法引入 MBSE 的过程视为一项有明确成本结构与收益曲线的经济决策，指出：形式化语义的边际收益并非单调上升，存在一个清晰的"成本—收益拐点"，越过该点后继续加深形式化，所支付的代价将快于所获的严谨。这一判定的意义在于——它把核心论点的零和张力，从定性哲理推进为可被组织测算的边际权衡。

7.11.1 形式化投入的边际收益曲线

将系统工程的某一部分推入形式编码的语义侧（引入可执行的、可机器验证的、一阶逻辑可判定的语义），其收益最初是显著且便宜的。一个长期依赖自然语言需求文档的项目，一旦把核心安全约束改写为可被模型检验器判定一致性的形式规约，立刻就能暴露此前藏于文本歧义中的矛盾（Borky & Bradley，2018；Harel & Politi，1998）。这一阶段边际收益很高：少量形式化投入换得稳定性、高密度性与逻辑精准性的明显抬升，正是 7.2、7.3 节所述 KerML 与可执行模型的早期红利（OMG，2023/2025；Madni & Sievers，2018）。

但收益随形式化深度递增而递减。当基础一致性已被捕获，进一步把每一处时序、每一处配置变体、每一处失效模式都推入严格语义，所暴露的新缺陷越来越少，而为之付出的建模、维护与验证劳动却持续攀升（Schäfer & Wehrheim，2009；Evermann，2009）。与此同时，形式化越深，对可习得性的侵蚀越重，能胜任建模的人员池越窄，单位劳动成本越高（Madni & Sievers，2018；Kossiakoff 等，2011）。于是收益曲线先升后平，成本曲线近乎线性乃至加速上升，两者之间的间隙就是"形式化的经济租值"。

7.11.2 成本—收益拐点：边际收益转负的临界点

定义成本—收益拐点为：在该点之后，追加一单位形式化所避免的工程风险损失，低于追加该单位形式化所消耗的资源成本（含建模、培训、工具、验证与延迟交付的机会成本）。越过拐点，形式化从"净收益为正"转为"净收益为负"，继续下沉是在用越来越贵的代价购买越来越薄的可信度增量。

这一拐点的存在，直接反驳了"形式化越深越好"的线性乐观。它同样是对核心论点的量化印证：形式编码与语义编码的零和，在经济学上表现为成本曲线与收益曲线的分叉——你每向语义侧多走一步，都要以形式侧更易量化的资源代价去购买（Borky & Bradley，2018；Dori，2016）。拐点不是工程的失败，而是零和张力在组织账本上的必然呈现：任何把曲线"推到底"的企图，都会在账目上撞上这道墙。

7.11.3 拐点位置的工程决定因素

拐点并非固定不变，其位置由若干可识别的工程项目特征决定，理解这些特征，是把"适度"说得清的前提。

• 系统风险与后果严重度：航空、核电、轨交等任务关键域，单点失效后果极高，故可承受为形式化支付高昂成本，拐点被推得更深——即便边际收益已薄，所避免的灾难性风险仍使形式化净值为正（DoD，2018；Borky & Bradley，2018）。低风险、低后果域则拐点极浅，浅尝辄止即已越界。

• 需求变更频率：需求高频波动的系统，形式化底座每随一次变更就要重做一致性校验，维护成本随变更率近似线性放大，拐点被显著前移（Holt 等，2011/2012；Madni & Sievers，2018）。静态稳定域则拐点靠后。

• 系统规模与耦合度：规模大、耦合强的系统，形式化带来的全局一致性收益更突出，拐点后移；但若规模大到验证状态空间爆炸，验证成本又反超收益，拐点复又前移（Schäfer & Wehrheim，2009；Broy & Cengarle，2010）。

• 人才与工具成熟度：工具链自动化程度高、专才充足时，形式化单位成本下降，拐点后移；反之则前移（INCOSE，2023；Kossiakoff 等，2011）。

下表把上述四类因素与其对拐点位置的影响汇总，便于组织在立项时定位自身的"形式化合理深度"。

7.11.4 把经济学判断写进方法论

把成本—收益拐点意识制度化的可行做法，不是去"找到唯一正确的形式化深度"，而是在方法学中内置"按风险与变更率调节形式化梯度"的机制，并在每次重大里程碑复查该梯度是否仍处收益为正的一侧（Madni & Sievers，2018；INCOSE，2021）。SysML v2 与 KerML 提供的严格语义底座，其价值在于让"深浅可调"有了统一的语义依托——同一内核上，边缘探索可停留在轻量表达，核心安全可下沉到可执行规约（OMG，2023/2025；Seidewitz，2023）。但这套底座本身也带固定成本，中小团队须先判断是否越过了"采用严格底座"的更大拐点（Estefan，2008；Borky & Bradley，2018）。

归根结底，形式化方法的经济学结论与全书核心论点完全一致：不存在"形式化到顶反而更省"的免费午餐，只存在对拐点位置的清醒估算与持续复评。把代价显性计价，是比盲目追求语义强度更接近工程成熟的做法。

7.12 人机协作建模中的责任归属与语义把关

7.4 节已从"分工化而非消除"的角度论证 AI 辅助建模如何转移零和，却尚未触及一个在工程与法律层面都极为要害的问题：当模型由 AI 生成、经人类"核准"后用于关键决策，语义错误的责任究竟归于何方？本节指出，人机协作的瓶颈不在生成速度，而在语义把关机制的可靠性与责任归属的可界定性——而这本身又是一处零和：把关越严，越逼近人类独自建模的成本；把关越松，越把不可靠语义引入系统。

7.12.1 AI 生成物 vs 人类核准：边界的模糊性

前沿实证已表明 LLM 能加速需求、用例与 SysML 初稿的生成，但生成物普遍存在冗余、缺乏内聚与语义不可靠等问题，必须由专家在环把关（Crabb & Jones，2024；Johns 等，2024）。然而"人类核准"这一环节在实操中高度脆弱：当 AI 一次性产出数十张看似合法的图，审阅者往往只能抽样确认，难以对每一处语义连接逐一验证（Bell 等，2024；Wach 等，2024）。Longshore 等基于 RAG 的 SysML v2 生成实验亦显示，注入领域知识可提升准确率、降低提示次数，但并未消除对人工校验的依赖（Longshore 等，2024）。说白了，"生成—核准"链条中，核准端是语义编码一侧稳定性的最后闸门，却恰恰最容易被海量生成所冲垮。

7.12.2 语义把关机制的设计

要使"人审机生成"不沦为形式，需在流程中嵌入可操作的把关机制，而非仅依赖个人经验：

其一，分级校验。把模型元素按风险分级，高后果元素（如安全约束、失效传播）强制人工逐项核验，低后果元素可抽样或自动比对基准（DoD，2018；Borky & Bradley，2018）。这实则是 7.11 节成本—收益拐点在人机分工上的投射：把关资源投向收益最高处。

其二，可追溯的语义证据链。AI 每一条生成应附带其来源依据（检索段落、推导步骤），使人类审阅者可逆推语义而非凭感觉信任（Johns 等，2024；OpenMBEE，2020s）。缺乏证据链的"黑箱生成"，使稳定性与逻辑精准性无法被复现验证（Evermann，2009；Guizzardi，2007）。

其三，对抗式复核与差异告警。以独立模型检验器或第二模型对 AI 产物做交叉检查，对语义矛盾自动告警，把"伪一致"从深层暴露到表层（Bell 等，2024；Schäfer & Wehrheim，2009）。

7.12.3 责任归属：从个人直觉到制度可界定

语义把关一旦失效，责任归属便成为绕不开的议题。若把责任简单归于"最终核准的人类工程师"，则 AI 辅助反而制造了道德风险：生成端几乎零成本地制造大量待审物，使人类审阅者处于"名义负责、实际无法穷尽"的无力位置（Crabb & Jones，2024；Wach 等，2024）。反之，若把责任归于工具提供方或算法，则又忽略了语义最终进入工程语境须由领域知识判定的事实（Kossiakoff 等，2011；Madni & Sievers，2018）。

较务实的取向，是把责任按"可归责环节"拆分：生成工具对其可复现的系统性偏差负责，建模组织对所设定的把关流程与资源投入负责，核准人对所实际核验的范围负责（INCOSE，2023；Borky & Bradley，2018）。这与 7.9.4 节"把不完美责任化、显式化"的文化成熟标志一脉相承——只有把责任边界写进过程资产，人机协作才不至于在事故发生后陷入"谁都没错、系统却错了"的归责真空。

7.12.4 把关成本：人机协作中的隐性零和

把 7.12 节放回核心论点框架，可看清其零和本质：AI 把形式编码一侧的繁重劳动压低，却把语义编码一侧的把关责任以同等甚至更大的体量推回人类（Johns 等，2024；Crabb & Jones，2024）。当生成变得近乎免费，把关需求按生成量线性膨胀，总语义劳动并未减少，只是被重新分配到"审阅"而非"创作"。下表刻画这一分工的代价流向。

可见，人机协作的成熟不在于消除零和，而在于让把关成本落在组织"付得起且可问责"的位置。宣称"AI 让建模既快又稳"的叙事，若回避把关责任与成本，便是对零和另一端的刻意遮蔽。

7.13 可演进架构的治理：模型版本、配置与语义漂移的长期控制

前述方向多聚焦"当下如何建模"，却少有论及模型在数年乃至数十年生命周期中的长期演化。对防务、航天、核电等长寿命系统而言，模型资产要跨越多次需求变更、供应商更替、工具升级与标准迭代，其治理难度远超单次建模。本节指出，可演进架构的长期治理本身又是一处零和：越是追求模型"随需而变"的动态柔性，越难保证语义在演化中稳定不漂；越是锁定语义以保一致，越牺牲演进的柔性。

7.13.1 模型版本与配置的长期控制

长寿命系统的模型会产生大量版本与配置变体：同一平台衍生出不同批次、不同客户、不同适航基线的模型分支（DoD，2018；Madni 等，2019）。版本控制若在文件层面粗放管理，不同分支间语义渐行渐远，最终无人能断言"当前权威源"究竟指向何处（Borky & Bradley，2018）。引入严格的模型级配置管理与基线机制，可保语义可追溯，但代价是可扩张性与动态柔性下降——每一次变更都要走受控流程，演进速度被治理 overhead 拖慢（INCOSE，2021；Holt 等，2011/2012）。数字主线理念试图以模型为纽带贯通全生命周期，正是对此的回应，但其前提是全链采用兼容形式语义，这又反向压制了各环节的柔性（Grieves，2014；Schäfer & Wehrheim，2009）。

7.13.2 语义漂移的来源

"语义漂移"指模型符号在演化过程中，其被理解的含义悄然偏离最初约定，而形式层面却仍看似一致。其来源至少有三：

第一，人员更替导致的约定流失。最初建模者的隐含约定未写进模型，继任者按自身理解使用同一符号，语义在不被察觉中漂移（Kossiakoff 等，2011；Estefan，2008）。

第二，工具与标准升级带来的隐性改写。从 SysML v1 迁往 v2、或工具插件更替，可能令同一模型在严格语义下被重新解释，旧有约定失效（OMG，2023；Friedenthal 等，2014/2018）。7.2.4 节所述的迁移割裂，正是语义漂移在语言层级的宏观表现。

第三，跨域映射层的不一致维护。多套 DSL 与通用语言互译时，映射规则若未随演进同步更新，翻译即引入漂移（Schürr，1994；Evermann，2009）。

7.13.3 治理机制：把漂移关进可审计的笼子

对抗语义漂移，需在组织层面建立长效治理：以机器可读的语义约定（本体、词汇表、约束库）固化符号含义，使漂移可被自动检出而非靠人记忆（Guizzardi，2007；Broy & Cengarle，2010）；以持续一致性校验替代阶段性审查，让漂移在引入时即告警（Evermann，2009；INCOSE，2023）；以明确的演进策略规定"何时允许语义变更、变更须经谁批准、旧基线保留多久"，把动态柔性约束在受控轨道内（Borky & Bradley，2018；Madni & Sievers，2018）。OpenMBEE 等开放环境所倡导的模型即权威源、全程可追溯，正是这类治理的技术承载（OpenMBEE，2020s）。

7.13.4 演进治理的零和：柔性、稳定与成本的三角

把可演进架构的治理置于核心论点的六性坐标，可见其仍是零和：强化语义稳定性与高密度性（防漂移）须以牺牲动态柔性与可扩张性（受控演进变慢）为代价，而降低治理 overhead 以保柔性，又必然放行部分漂移风险（Schäfer & Wehrheim，2009；Dori，2016）。下表给出三类治理取向的取舍。

长寿命系统的真实处境是：漂移几乎不可避免，治理的目标不是消灭它，而是把漂移速率控制在可被审计、可被追责、可被回滚的范围内（DoD，2018；INCOSE，2021）。这与全书收束判断完全自洽——不存在"既自由演进又永恒一致"的终极架构，只有把代价安置在体系最能承受之处的持续折中。可演进治理的成熟，正体现在组织能否坦然陈述："我们允许模型在受控范围内漂移，并为此预留了可回滚的代价。"

7.13.5 三节小结：未来方向在经济学、责任与时间的维度上回归同一结论

7.11 至 7.13 三节分别从经济学边际、人机责任归属与长周期演化三个新维度，再次检验了本书核心论点。形式化有成本—收益拐点，人机协作有把关责任与隐性零和，长寿命演进有语义漂移与治理取舍——三条线索指向同一收束：未来不会提供"终极体系"，只会在成本、责任与时间的轴线上，把零和张力重新配置到更可被承受、更可被问责之处。这恰是 7.10 节"优化折中、而非突破零和"结论的纵深延展。

第8章 跨域案例与零和取舍的普遍印证

0. 本章定位与核心命题的重申

本书此前各章已层层展开：MBSE（基于模型的系统工程）自上世纪六十年代系统工程方法论萌芽（Hall，1962；Sage，1992），经 Wymore(1993) 的数学化建模奠基、INCOSE 于 1990 年前后组织化推动、再到 OMG 先后以 UML（OMG，2017）、SysML v1（OMG，2007–2019）及其 2023 年 Beta2、2025 年 7 月正式采纳的 SysML v2 / KerML（OMG，2023/2025）为代表的语言浪潮，逐步确立为现代系统工程的"官方范式"（Madni & Sievers，2018；Estefan，2008）。第三章剖析了 MBSE 的语义基础与形式化张力，第五章揭示了其方法论、工具链与组织层面的局限性，第六章梳理了学界与工业界在"严谨优先还是务实优先"上的立场分歧（Broy & Cengarle，2010；Guizzardi，2007；Dori，2016）。

本章承担全书的"跨域升华"任务。我们的出发点是全书贯穿始终、且须在全章反复呼应的一条核心论点：

符号系统必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做不可逆的零和取舍，不存在完美兼顾的终极体系。

此处所谓"零和取舍"，其精确含义并非"总量恒定、此长彼消"，而是帕累托最优不存在：没有任何一种符号体系能够在上述六性上同时达优；强化形式编码一侧（让语言更易学、更易扩展、更能随需求柔性演化），就必然削弱语义编码一侧（语义不稳、密度稀释、逻辑校验失准）；反之，越是追求语义编码的严谨（形式化语义、可执行、可机器验证），就越牺牲形式编码的可习得性与可扩张性（UF-04）。

MBSE 作为符号系统的一个典型工程实例，其全部历史演进、方法分歧与能力边界，均可归结为这一根本性张力。本章的第一个任务，是用 MBSE 自身在工程各领域的实践，再次印证这一张力；第二个也是更重要的任务，是将目光越过工程边界，证明同一条零和取舍规律出现在与系统工程看似毫无瓜葛的、完全不同的符号系统中——编程语言、数学记号、自然语言、本体、类型论、数据库模式、API 规范乃至法律条文。这足以说明：零和取舍是"符号系统"这一更大范畴的普遍律，MBSE 不过是这条普遍定律在工程领域的一束投影。

本章之所以能够把论证推进到"普遍律"的高度，是因为零和取舍并非某种历史偶然或工程失误，而是根植于符号系统的本质职能。任何符号系统都同时承担两种相互拉扯的职能：一方面，它要面向"人"——降低认知负荷，让新手可习得、让体系可随人的理解扩张、让表达能随需求柔性生长；另一方面，它要面向"世界"——忠实地、稳定地、可被机器无歧义解析地刻画外部事物的因果与逻辑结构。形式编码三性服务于前者，语义编码三性服务于后者。这两种职能的各自最优点天然不重合：越把符号调校得易学、易扩、易变，就越少地对意义施加约束，意义便越多地留给语境与解释，语义编码随之削弱；越把符号钉死为形式化语义与可验证性，就越要求使用者付出训练成本、并在变更面前趋于僵硬，形式编码随之削弱。因此，零和取舍是结构性的，而非我们尚未找到"正确记号"的权宜现象。历史上 Leibniz 的普遍字符（characteristica universalis）、各种"通用语言"方案之所以屡屡搁浅，根由正是它们试图让一套符号同时成为人脑的舒适界面与世界的可验证代理——而这两条最优曲线无法重叠。

为使讨论可操作，本章将六性明确拆分为左右两栏：

• 形式编码三性：可习得性（learnability，新手能否快速上手）、可扩张性（extensibility，能否低成本地吸收新概念与新领域）、动态柔性（dynamic flexibility，能否随需求变化柔性演化而不崩塌）。

• 语义编码三性：稳定性（stability，语义不因语境漂移）、高密度性（density，单位符号承载的信息量）、逻辑精准性（logical precision，可否被机器无歧义地解析、推理与验证）。

下文所有案例与论证，均围绕这六性在二元之间的站位展开。

---

1. 工程领域案例：用 MBSE 自身印证

MBSE 不是一个单一方法，而是一个方法谱系（Estefan，2008 详述了 OOSEM、Harmony-SE、State Analysis、Statemate、ROOM、RUP 等源流）。不同工程领域因风险容忍度、实时性约束与认证压力的差异，在六性之间做出了截然不同的站位选择。这种"同一范式内部即已分化"的现象，本身就是零和取舍存在的直接证据：若真有一套能六性全优的终极体系，方法谱系便不应如此分裂。

1.1 航空航天 / JPL 状态分析（State Analysis）：高语义严谨换取陡峭学习曲线

美国国家航空航天局喷气推进实验室（JPL）发展的状态分析（State Analysis）方法，是 MBSE 在工程实践中把语义编码推向极致的代表。Ingham 等（2004）将状态分析定义为一种"通用目的、基于模型的实时系统方法"，其核心是用形式化的状态模型刻画系统在每个时刻应处的状态、状态间的转移条件，以及为达成目标所必须执行的动作序列。其语义严谨性体现在：模型可被直接执行，状态与控制的对应关系是可被机器检查的，需求、设计与运行时行为之间保持了强可追溯性。

然而，这种语义编码一侧的强化，直接以形式编码三性的弱化作为代价。状态分析要求建模者以"状态—目标—活动—监控"的形式化视角重新组织全部问题，这对习惯于以自然语言或时序图思考的工程师构成陡峭的学习曲线（可习得性显著下降）。它高度依赖少数深谙其形式体系的专家，难以在大型跨组织项目中无损扩散（可扩张性受限）。在 JPL 深空探测这类"错误代价极高、需求相对固化"的场景下，这种取舍是划算的——因为语义编码的稳定性与逻辑精准性带来的可靠性收益，远大于可习得性的损失。但一旦进入需求频繁变动、参与方众多的常规工程，这一站位的代价便迅速凸显。

这一案例给出的"取舍站位"是：语义编码（稳定性、高密度性、逻辑精准性）全面占优，形式编码（尤其可习得性）显著让位。它证明，强化语义一侧的代价是真实且沉重的，而非可忽略的工程噪声。

1.2 汽车 / 嵌入式（Harmony-SE、AUTOSAR）：实时语义约束与开发柔性的冲突

汽车电子是 MBSE 另一主战场，但其张力结构不同于航空航天。Douglass（2009）提出的 Harmony-SE（Harmony/ESW 方法）面向实时与嵌入式系统开发，强调从用例经分析模型到设计模型的顺畅流转，并以"可执行状态机"作为核心构造。与此同时，汽车开放系统架构 AUTOSAR 自 2003 年成立以来，已成为车载基础软件事实标准，其方法论大量借助元模型（meta-model）与模板（template）支撑电子控制单元（ECU）与总线资源的配置与代码生成（Dörr，2008；Natale，2008）。

这里的核心矛盾是实时语义约束与开发柔性之间的冲突。一方面，汽车软件必须满足硬实时、确定性时序与功能安全的强语义约束，AUTOSAR 为此定义了严格的运行时环境（RTE）与基础软件（BSW）分层契约——这强化了语义编码的稳定性与逻辑精准性。另一方面，整车厂与供应商之间、车型平台之间、ECU 之间的高度可变性（variability）要求建模体系能柔性地容纳配置组合与需求变更（Dörr，2008；Mudhivarthi 等，2023）。当语义约束被钉死，开发柔性（动态柔性）便受挤压：任何变更都需在严格契约内重新验证，模型的可扩张性（吸收新硬件、新总线）也变得笨重。

换种讲法，汽车嵌入式场景把"形式编码的某一性（动态柔性）"与"语义编码的某一性（逻辑精准/稳定性）"直接对立起来：越想让系统在真实物理约束下行为可验证，就越难让模型随需求自由呼吸。这同样是零和取舍，只是代价落在了柔性而非可习得性上。

1.3 国防 / 核电等安全关键系统：形式化验证的强语义 vs 认证文档负担

在国防、核电、航空机载软件等安全关键（safety-critical）领域，MBSE 被寄望于以形式化方法降低灾难性失效概率。标准层面，DO-178C 及其形式方法补篇 DO-333、IEC 61508 等均对"模型须有精确定义语义、可机器验证"提出明确要求（Lano & Kolahdouz-Rahimi，2015；Elqortobi 等，2020）。Lano 与 Kolahdouz-Rahimi（2015）系统论述了高完整性模型驱动开发中，模型须具备良定义语法与精确定义语义，方能满足 DO-178C 对可追溯性与可验证性的要求；Elqortobi 等（2020）则提出将模型检验（model checking）与模型测试整合进 DO-178C 合规框架的方法论。

代价同样清晰：形式化验证的强语义，换来的是沉重的认证文档负担。DO-178C 本质上是一个"过程标准"，它要求从高层需求到模型、再到源代码与测试用例的逐层可追溯，并要求所有模型可由高层需求推导并验证（Lano & Kolahdouz-Rahimi，2015）。为满足这一点，团队须付出大量专门知识劳动来构造形式模型、证明其性质、并生成可被审查机构接受的认证证据。正如 Grant 与 Datta（2015）所直言，形式规格技术的反对者其理由恰在于"它增加开发成本、需要高度训练专家、且看似难以用于真实系统"。核电等高可靠领域愿意支付这份成本，是因为失效的代价是生命与生态；但对多数商业工程而言，这份语义严谨的账单足以令 MBSE 的推广止步。

这又一次印证：语义编码（逻辑精准性、稳定性）的强化，必然以形式编码（可习得性、动态柔性，乃至经济性）为代价。安全关键领域不过是"被动选择了语义一端"的极端情形。

1.4 企业架构 / IT（TOGAF、UML 在软件界）：通用性 vs 语义漂移

MBSE 的思想外溢到企业架构（如 TOGAF）与软件工程（UML 成为事实标准）后，呈现出另一番取舍面貌。UML 作为面向对象软件系统的通用建模记号，被设计为"覆盖尽可能广的受众与场景"，其形式编码的可习得性与可扩张性极高——任何团队都能快速上手画图。然而，正是这种通用性埋下了语义漂移的种子。

Broy 与 Cengarle（2010）在题为《UML 形式语义》的论文中系统指出：UML 缺乏统一、完备、无歧义的形式语义，其各子图（类图、状态图、活动图、时序图等）的语义长期依赖各自的非形式化或半形式化解释，导致同一张图在不同工具、不同解读下含义漂移。为了"让所有人都能用"，UML 牺牲了语义编码的逻辑精准性与稳定性（高密度性亦因图形冗余而受损）。TOGAF 等企业架构框架更甚——它们本质上是元方法论（meta-methodology），提供的是"如何组织架构描述"的柔性骨架，而非可机器验证的语义；其形式编码三性（尤其动态柔性与可扩张性）极强，语义编码三性则相对薄弱。

这一案例揭示了零和取舍的又一种姿态：当形式编码（可习得性、可扩张性、动态柔性）全面占优时，语义编码（稳定性、高密度性、逻辑精准性）必然流失。通用性与严谨性无法在同一符号体系内兼得。

1.5 工程案例的取舍站位小结

综合上述四个领域，可提炼出如下小结表。表中"↑"表示该性占优，"→"表示居中，"↓"表示该性让位：

这张表本身即是一份证据：即便在同一范式（MBSE）内部，也没有哪个方法能在六性上全优；每个方法不过是把代价挪到了不同的位置。MBSE 的全部方法谱系分歧，归根结底是"在六性之间如何配比"的分歧，亦即核心论点的工程投影。

---

2. 跨域理论升华：零和取舍是符号系统的普遍律

若零和取舍仅仅是 MBSE 或工程领域的特例，它便不配称为"定律"，而只是一则行业经验。本章的灵魂在于证明：同一条规律，出现在与系统工程毫无亲缘关系的符号系统中。一旦看清这一点，MBSE 的种种困境便不再是"我们方法没选好"或"工具不够成熟"，而是符号系统这一更大范畴的固有属性使然。

2.1 编程语言：动态语言与静态类型语言的分野

编程语言是最接近系统工程读者的对照样本。Pierce（2002）在其权威教材《Types and Programming Languages》中指出，类型系统是一种"通过把程序短语按其所计算的值的种类分类，从而自动检查某些错误行为是否存在"的句法方法。这条定义本身就揭示了取舍：类型系统越强，能在编译期排除的错误越多（语义编码的逻辑精准性↑、稳定性↑），但语言也越难学、越难即兴扩张。

具体对照鲜明：

• 动态语言（Python、JavaScript 等）：形式编码三性全面占优。语法贴近自然语言直觉，新手数小时可上手（可习得性↑）；可随时引入新抽象、新领域对象而无须事先声明类型（可扩张性↑）；需求变更时可柔性重构（动态柔性↑）。代价是语义编码三性弱化：同一变量在不同时刻可绑定不同类型，语义随运行态漂移（稳定性↓）；动态调度与反射稀释了单位代码的确定信息量（高密度性↓）；大量错误只能到运行时才暴露，无法被机器静态验证（逻辑精准性↓）。

• 静态类型语言（Rust、Haskell、Idris 等）：语义编码三性占优。强类型与所有权/仿射类型（Rust）或依赖类型（Idris、Haskell 的扩展）使大量性质在编译期即可被证明（逻辑精准性↑、稳定性↑）；类型即文档，单位符号承载丰富不变式信息（高密度性↑）。代价是可习得性陡降——学习者须先掌握类型论直觉，依赖类型更是研究生层级的概念（Pierce，2002）；可扩张性与动态柔性亦受类型签名的约束而缩窄。

编程语言的演化史，几乎就是一部在六性之间反复摇摆的历史：从汇编（形式编码极低、语义编码极高）到 Fortran/COBOL（提升可习得性），到动态语言（极致柔性），再到以 Rust/Haskell 为代表的安全静态语言（回调语义严谨）。每一次"进步"都不是帕累托改进，而是把代价从一侧挪到另一侧。这与 MBSE 从 UML（柔性）到 SysML v2 / KerML（以一阶逻辑与四维时空外延给出正式语义，OMG，2023/2025）的演进，结构完全同构。

2.2 数学记号：直观记号 vs 形式化证明系统

数学是人类最古老的符号系统之一，同样逃不开零和取舍。日常数学写作追求可读性与表达柔性：数学家以直观记号、图示与省略省略号表达思想，可习得性极高、动态柔性极强，但大量步骤依赖读者"心领神会"，语义稳定性与逻辑精准性依赖人的严谨而非机器。

为获得机器可验证的严谨，数学界发展出证明助手（proof assistant）：Coq 基于归纳构造演算（Calculus of Inductive Constructions），Bertot 与 Castéran（2004）的《Coq'Art》即其权威指南；Agda 由 Norell（2007）在其博士论文《Towards a practical programming language based on dependent type theory》中确立为依赖类型编程语言；Lean 则由 de Moura 等（2015，DOI: 10.1007/978-3-319-21401-6_26）在 CADE-25 提出，以其极小的可信内核（基于依赖类型论）桥接交互式与自动化定理证明。这些系统把语义编码的逻辑精准性推向极致——每一步推理都被归约到公理，证明对象可被独立检查。

代价是众所周知的：形式化证明的代价极其高昂。把一段直观证明翻译为 Coq/Lean/Agda 中可被机器接受的脚本，往往耗费原证明数十倍乃至上百倍的人力；依赖类型等概念的学习门槛极高（可习得性↓）；在严格类型框架下即兴引入新数学结构远不如纸上灵活（可扩张性、动态柔性↓）。其实，证明助手以形式编码三性的全面塌缩，换取语义编码三性的顶峰。这与 JPL 状态分析"以可习得性换逻辑精准"的站位如出一辙——只不过一个是工程实时系统，一个是数学真理。

有趣的是，连 Lean 这样追求严谨的系统也在试图"桥接"两侧（de Moura 等，2015），但桥接本身无法消除取舍，只能把代价重新分配：它在声明式与策略式风格间提供混合，却仍须依赖一个极小的可信内核与复杂的精化（elaboration）算法，后者恰是其工程复杂度的来源。

2.3 自然语言：表达丰富柔性 vs 歧义

自然语言是形式编码三性（尤其可习得性、动态柔性）的天花板：三岁孩童即可习得，且能随社会变迁不断吸纳新词、新义、隐喻与新修辞（可扩张性、动态柔性极高）。但正因其为"自然"演化产物，它缺乏稳定、无歧义的语义（稳定性↓），单位语词承载的确定信息随语境剧变（高密度性难以保证），更无法被机器无歧义地解析与推理（逻辑精准性↓）。

这正是系统工程必须以 MBSE 补足自然语言的原因：需求文档若只用自然语言撰写，便不可避免地产生歧义、遗漏与不一致（Madni & Sievers，2018 指出 MBSE 的动机正在于克服文档割裂与歧义）。然而，把需求"形式化"的过程，正是以可习得性与动态柔性为代价，去换取语义编码三性的过程——这恰好是核心论点的微观重演。自然语言与形式化语言，构成六性光谱两端，无人能令自然语言既保持柔性又具备机器可验证的严谨。

2.4 本体 / Ontology：形式本体（OWL）精准 vs 构建成本高、难扩张

本体工程是从"知识表示"视角复现同一取舍的绝佳样本。Gruber（1993，DOI: 10.1006/knac.1993.1008）把本体定义为"对概念化的显式规范"，其初衷正是通过共享词汇实现知识复用。Guizzardi（2007）进一步区分了本体、概念化、建模语言与（元）模型，强调本体须锚定于真实世界的本质结构方能避免语义漂移。

当本体以 OWL（Web Ontology Language）等描述逻辑形式化时，它获得高稳定性与逻辑精准性：推理机可自动判定概念包含、实例分类与一致性（语义编码三性↑）。但 OWL 的表达力受描述逻辑的可判定性约束，许多现实领域知识（如时序、过程、非单调推理）难以自然表达；更关键的是，构建一个覆盖广泛领域的形式本体需耗费巨大专门知识，且一旦领域扩张便须重新审视公理一致性（可习得性↓、可扩张性↓、动态柔性↓）。反之，轻量本体或受控词表（如标签体系）柔性极高、易建易扩，却几乎不提供可机器验证的语义。本体界长期在"表达力 vs 可判定性 / 构建成本"间挣扎，这正是零和取舍在本体维度的投影。

2.5 从类型论、范畴论到数据库模式、API 与法律条文

零和取舍的普遍性，还可在更多符号系统中被一一辨认：

• 类型论 / 范畴论：类型论（Martin-Löf 直觉类型论、Coquand 的构造演算）为程序与证明提供统一基础，语义编码极强，但概念抽象度极高、可习得性低。范畴论（Mac Lane，1998，DOI: 10.1007/978-1-4757-4721-8）以"范畴、函子、自然变换"等高阶抽象统一众多数学结构，其高密度性与稳定性无与伦比，却以极其陡峭的学习曲线为代价（可习得性↓）。越是抽象的"统一语言"，越难被普遍习得——这与"统一建模语言"的理想及其现实困境形成镜像。

• 数据库模式（schema）：Codd（1970，DOI: 10.1145/362384.362685）以关系模型把数据抽象为集合与一阶谓词，实现了"数据独立性"——应用程序不必知晓存储结构（形式编码的可扩张性、动态柔性↑），并以数学基础保障了查询语义的稳定与可推理（语义编码稳定性、逻辑精准性↑）。但其代价是：为维持范式与一致性，模式设计须预先固化结构，难以随业务即兴演化（一定的动态柔性↓），且关系代数对复杂语义（如递归、图结构）的表达相对稀薄（高密度性在某些场景受限）。关系数据库用"预先严格建模"换取长期稳定，仍是取舍而非免费午餐。

• API 设计：RESTful API（Richardson & Ruby，2007）以资源导向架构（ROA）用极简的统一接口（GET/PUT/POST/DELETE）与 URI 命名换取易学、易扩、易演化（形式编码三性↑），但其语义停留在"约定"层面，缺乏可机器验证的精确契约（语义编码逻辑精准性↓），故须辅以 OpenAPI 等补充规格。反之，以 WSDL/SOAP 为代表的强契约 API 语义精确、可形式校验，却显著牺牲了柔性与易用性。API 设计史同样是柔性 vs 严谨的拉锯。

• 法律条文与"作为代码的法律"（law as code）：Lessig（1999）在《Code and Other Laws of Cyberspace》中著名的论断"代码即法律"（Code is Law）指出，软件代码与法律条文同为规制人类行为的符号系统。自然语言写就的法律极具表达柔性与可习得性（公民可大致理解），但充满歧义、需司法解释、难以机器执行（语义编码三性↓）。为获得确定性，出现了"规则即代码"（Rules as Code）运动，把法规编译为可执行逻辑。然而，将法律形式化必然丢失自然语言的弹性与情境判断力（动态柔性↓、可扩张性↓），且构建成本高昂、需专家把守。法律条文与编程语言，在此构成一对完美的对称：两者皆在"可被大众柔性使用"与"可被机器精确执行"之间二选一。

上述每一例都独立地、互不因果地重现了同一结构：没有一种符号体系能在六性上同时达优；强化一侧必然以牺牲另一侧为代价。这已不是工程经验，而是跨符号系统的普遍律。

2.6 零和取舍为何无可逃脱：认知、信息与演化三重根由

为使"普遍律"的论断站得住脚，须进一步说明：这一取舍为何不是历史的偶然，而是符号系统这一范畴的必然属性。可从三重根由理解。

其一，认知根由。符号系统的可习得性与可扩张性，依赖于它对人的认知负荷保持宽容——允许近似、类比、省略与语境补全。而语义编码的逻辑精准性，恰恰要求消除这些宽容：每一个符号都须有确定外延，每一个推理步骤都须可机械判定。认知宽容与机器精确是互斥的设计目标，人脑的联想式处理与机器的演绎式处理无法被同一套记号同时最优地服务。MBSE 中"专家依赖"与"语义严谨"的共生，正是这一认知张力的工程显影。

其二，信息根由。从信息论视角看，一个符号系统若追求高密度与强约束（语义编码占优），其编码必趋于"紧致而脆弱"——少量符号承载大量不变式，一旦语境偏移便产生误读或不可解析；若追求易学易扩（形式编码占优），其编码必趋于"冗余而柔韧"——以更多自由度换取对使用者的友好与对变更的包容。紧致与柔韧在编码效率的前沿上构成权衡，没有人能构造出一种既紧致精确、又对使用者极其宽容、还能无限扩张的符号。这与 Shannon 意义上"描述长度、错误可检性与适应性"之间的张力同构。

其三，演化根由。成功的符号系统会在使用中持续膨胀：新概念、新工具、新领域不断被纳入。若系统初始便以强语义约束自我钉死，扩张就会因一致性审查的高成本而停滞；若系统初始以柔性开放自我设计，扩张虽易，却会在体量变大时因语义漂移而失去可组合、可验证的能力。零和取舍还会随系统演化而自我强化——今天为易用性付出的语义债，会在规模扩大后以更昂贵的方式偿还。这解释了为何几乎每一套"通用符号"在成熟期都会分裂出"严格子集"与"宽松超集"两支（如 UML 与 SysML、动态语言与静态语言、自然语言与法律形式化），因为单一体系无法同时承载成长性与严谨性。

三重根由叠加，使零和取舍成为符号系统的"结构常数"而非待解 Bug。认识到这一点，我们方能把 MBSE 的种种困境，从"方法不成熟"的浅层归因，提升到"符号系统固有属性"的深层理解。

---

3. 结论性洞见：MBSE 只是普遍定律在工程领域的投影

把前两节的证据并置，可以得出本章的核心洞见：

MBSE 不是一条独特的、可借由"更好的方法或工具"来突破的规律，它只是"符号系统零和取舍"这条更大普遍定律在工程领域的一束投影。 MBSE 在航空航天、汽车、安全关键、企业架构中所呈现的全部张力——可习得性 vs 逻辑精准性、开发柔性 vs 实时语义约束、通用性 vs 语义漂移——并非 MBSE 设计者的失误，亦非工具不成熟所致，而是任何承担"用符号刻画复杂系统"这一职能的符号系统都必然承受的代价。

由此可进一步推演一个常被忽视、却极具解释力的判断：任何试图构造"统一 / 终极"符号体系的努力，最终都会重新坠入零和取舍——只是把代价换了个位置。 历史反复印证这一点：

• 统一建模语言（UML）的理想：UML 的诞生动机之一正是"终结面向对象建模记号的战国混战"，以一套通用语言统一表达（OMG，2017）。但如前所述（Broy & Cengarle，2010），通用性越高，语义漂移越重；"统一"的获得以"精确"的流失为代价。SysML v2 / KerML（OMG，2023/2025）试图以正式语义纠正 v1 的歧义，方向是回调语义编码一侧——但这必然重新抬高学习门槛与建模刚性，把代价从"语义漂移"挪回"可习得性 / 动态柔性"。

• 通用本体（Universal Ontology）的理想：从 Cyc 到 SUMO，再到 OWL 驱动的各类顶层本体，无数努力试图构造覆盖一切领域的"通用本体"。Gruber（1993）与 Guizzardi（2007）的工作表明，表达力与构建成本、可判定性之间不可兼得；越是通用的本体，越难被具体领域低成本地采纳与扩张。

• 大一统形式化框架的理想：类型论曾被视为"统一程序与证明"的终极框架（Bertot & Castéran，2004；Norell，2007；de Moura 等，2015），但其极致的语义严谨，恰恰以极致的难以习得为对价。它统一了数学与程序，却没有、也不可能统一"易学"与"严谨"。

因此，所谓"终极体系"是一个范畴错误：它假设存在一种能六性全优的符号系统，而零和取舍定律宣告这种系统不存在。MBSE 的未来不在于"找到那套完美语言"，而在于清醒地、有意识地在不同工程语境下选择代价可接受的站位，并把取舍决策本身显性化、可治理化。这与 UF-10 所揭示的反直觉事实相互呼应：工业界并不反对严谨，反对的是"以严谨替代需求纪律"；真正的工程智慧是"严谨与习得 / 扩张如何配比"，而非"要不要严谨"。

把这一洞见落到治理层面，意味着 MBSE 的成熟度不应再以"语义多严谨"或"工具多强大"单一维度衡量，而应以"取舍是否被显式管理"来衡量。一个成熟的 MBSE 实践，应当在立项之初便回答：本项目把代价安置在六性的哪一侧？航空航天与核电可坦然接受可习得性与柔性的塌缩，换取逻辑精准；企业架构与快速迭代产品则应优先保全形式编码三性，仅对关键子系统局部强化语义。当取舍被显式声明、被审查、被问责，MBSE 才真正摆脱"寻找圣杯"的幻梦，回到工程决策的本来面目。这也正是全书的立场收束点：MBSE 的演进史，不是一部逼近完美的历史，而是一部不断重新安排代价位置的历史。

---

4. 综合对比表：多符号系统六性站位一览

为直观呈现"无人能六性全优"，本节以一张综合表并列前文涉及的多个符号系统。表中评价为相对站位（同一符号系统内部六性之间的对比，以及跨系统之间的横向对比），"↑"表示在该性上占优，"→"居中，"↓"表示在该性上让位：

纵览此表，一个事实无可辩驳：没有任何一行在六列上同时取得"↑"。每一行都清晰地把代价安置在某几性上，而强化侧与牺牲侧恰好分列六性的左右两栏。这不仅是 MBSE 的处境，更是所有符号系统共享的命运。

---

5. 本章小结

本章以"跨域印证"完成全书的升华。我们首先用 MBSE 在工程四大领域的实践（航空航天状态分析、汽车嵌入式 Harmony-SE/AUTOSAR、安全关键系统的形式验证、企业架构/IT 的 UML/TOGAF）再次确认：即便在同一范式内部，方法谱系的分歧本质上就是六性配比的分歧，零和取舍从未缺席。随后，我们将视野越出工程边界，证明编程语言（动态 vs 静态类型）、数学记号（直观 vs 证明助手）、自然语言、本体（OWL）、类型论/范畴论、数据库模式、API 设计乃至法律条文，都以互不相关的历史路径，独立重现了同一结构——强化形式编码三性必损语义编码三性，反之亦然。

由此得出的结论是确定的：零和取舍是符号系统的普遍律，MBSE 仅是这条定律在工程领域的投影。任何"统一建模语言""通用本体""大一统形式化框架"的终极理想，都注定在越过某个性状的巅峰后，于另一性状上重新跌落——它只是把代价换了个位置，而非消除了代价。

对 MBSE 而言，这一洞见既是解咒，也是指引。它解除了"必有一套完美方法在前面等待"的幻象，也指明了务实之路：不再徒劳追寻六性全优的乌托邦，而是根据工程语境（风险、实时性、认证压力、组织规模）主动、显性、可治理地选择站位，并让取舍本身成为可被审视与问责的工程决策。这恰是本书其余各章所铺垫的方法论张力，在更广阔符号哲学尺度上的一次收束。

值得最后强调：本章所论证的普遍律，并不导向虚无的 relativism——它不意味着"用什么符号都无所谓"，而意味着"任何选择都有可计算的代价"。认识到零和取舍的不可消除，反而是负责任工程实践的起点：它要求我们在推崇某一侧（无论是 MBSE 的语义严谨，还是动态语言的开发柔性）时，诚实地承认被牺牲的那一侧，并为该代价预留补偿机制（如以评审、测试、文档或形式化局部补强来对冲语义漂移，或以培训、工具链与领域封装来对冲可习得性损失）。唯有如此，符号系统才能在其不可避免的取舍中，为人类工程活动提供尽可能稳健的支撑。这，便是 MBSE 作为"符号系统普遍律之工程投影"这一命题，留给实践者的最终教益。

---

6. 编程语言光谱的六性精密站位：从 Python/JS 经渐进类型到 Coq/Lean/Agda

编程语言已在 §2.1 中以"动态语言 vs 静态类型语言"的粗分照面。为使普遍律更锋利，本节把整个类型系统光谱沿六性铺开——它是同一符号家族内部站位选择最密集、因而对"六性全优"幻想最具否决力的一例。

6.1 光谱的四档站位

按类型层面对程序施加语义约束的强弱，主流语言可排成四档：

• 第一档：纯动态语言（Python、JavaScript、Ruby）。形式编码三性全面占优：语法贴近自然语言直觉、解释执行、无需预先声明类型，新手数小时即可上手（可习得性↑）；可在运行时随意引入新对象、新字段、新协议（可扩张性↑）；需求变更时以反射、Monkey-patch、动态代理柔性重构（动态柔性↑）。代价集中在语义编码：同一标识符在不同执行点可绑定异构类型，语义随运行态漂移（稳定性↓）；大量性质只能到运行时才暴露，机器无法在编译期静态排除（逻辑精准性↓）；动态派发与反射使单位代码承载的确定不变式稀薄（高密度性↓）。这正是 MBSE 中"UML/TOGAF 通用柔性"在软件界的同构体。

• 第二档：渐进类型语言（TypeScript、Python+typing、Typed Racket、Gradual Python）。Siek 与 Taha（2006）提出"渐进类型"（gradual typing），主张在同一语言内由程序员自行决定哪些部分静态检查、哪些部分运行时检查，以特殊类型 Dynamic（记为 ?）与"一致性关系"（consistency）替代传统子类型相等判定，从而在静态类型安全与动态灵活之间架桥；其直觉是"类型的结构在编译期可部分已知/未知，类型系统的职责是捕获已知部分之间的不兼容"。表面上它似乎打破了零和：既保留动态语言的柔性，又获得静态语言的保障。但零和并未消失，只是被重新分配——增量类型标注带来的机器保证，止步于"下一个动态交互之前"，越过 ? 边界时必须插入运行时类型检查（cast），失败则在运行期抛错并由 blame tracking 定位（cstopics 综述；Siek & Taha，2006）。换个说法，它用"运行时开销 + 边界复杂度 + 排错不确定性"换回了灵活性，把代价从编译期挪到运行期与心智模型。其"渐进保证"（gradual guarantee，Siek 等，2015）只承诺"加注解不引入新静态错误"，并不承诺消除类型错误本身。

• 第三档：强静态类型语言（Rust、Haskell、Idris、F*）。语义编码三性占优：Rust 以所有权与仿射类型在编译期排除数据竞争与悬垂指针（逻辑精准性↑、稳定性↑）；Haskell 的纯函数与类型类使"类型即文档"，单位符号承载丰富不变式（高密度性↑）；Idris 的依赖类型更允许以类型表达程序性质（如"排序后长度不变"）。代价是 Pierce（2002）早已点明的：类型论直觉本身是高阶抽象，学习者须先跨越心智门槛，依赖类型更是研究生层级概念（可习得性↓）；类型签名约束了数据形态与接口，即兴扩张与柔性重构须经类型系统同意（可扩张性↓、动态柔性↓）。这与 MBSE 中"安全关键形式验证"的站位同构。

• 第四档：证明助手（Coq、Agda、Lean）。Bertot 与 Castéran（2004）的《Coq'Art》以归纳构造演算为基；Agda 由 Norell（2007）确立为依赖类型编程语言；Lean 由 de Moura 等（2015）在 CADE-25 提出，以极小可信内核桥接交互式与自动化证明。这一档把语义编码推到顶峰：每一步推理归约到公理，证明对象可被独立机器检查（逻辑精准性↑↑、稳定性↑↑）。代价是形式编码三性近乎塌缩：把一段直观证明翻译为机器可接受脚本，常耗费原证明数十倍人力（可习得性↓↓、动态柔性↓↓、可扩张性↓↓）；构造演算与同伦类型论等概念的学习曲线极陡。它恰是 JPL 状态分析"以可习得性换逻辑精准"在数学真理维度的极端化。

6.2 光谱给出的教益

把四档并置，得到一条连续曲线：从纯动态（形式编码全优）平滑滑向证明助手（语义编码极致），六性的强化侧与牺牲侧始终分列左右两栏，没有任何一档同时把六性拉满。渐进类型看似的"例外"尤其值得玩味——它不否定零和，而是把代价从"编译期/运行期"与"人的心智"两个维度重新分配，并引入新的代价（边界运行时检查、blame 复杂度）。这恰好印证 §2.6 的"演化根由"：试图用一座桥同时服务两边，桥本身要付工程成本。编程语言四十年的"动态↔静态↔渐进"反复摇摆，与 MBSE 从 UML 柔性到 SysML v2/KerML 回调语义严谨的演进，结构完全同构——两者都是同一条普遍律在不同符号家族中的投影。

---

7. 更多符号系统的零和印证：化学记号、音乐记谱、形式化需求语言与法律代码化

除编程与数学外，三个进一步符号系统独立重现同一结构；纳入它们，普遍律的经验基底更厚。

7.1 化学：结构式 vs SMILES/InChI

化学家用两种互补记号描述分子。其一是"结构式/反应式"（以圈与线表示原子与键），形式编码三性强：化学专业新生经短期训练即可读写、可在图上即兴增删取代基与官能团（可习得性↑、可扩张性↑、动态柔性↑），且极易随新化合物柔性表达。代价是语义编码弱：手绘结构式依赖绘图者约定，同一分子可有多种画法，机器无法直接解析，也不保证唯一（稳定性↓、逻辑精准性↓）；其信息密度随绘图风格波动。其二是线性记号 SMILES（Simplified Molecular Input Line Entry System，Weininger，1988，DOI: 10.1021/ci00057a005）及其规范化变体（Weininger 等，1989），以及 IUPAC 的 InChI。SMILES 以 ASCII 字符串（如 CCO 表示乙醇、c1ccccc1 表示苯）紧凑编码分子图，可被程序无歧义解析、可作数据库主键、体积仅为连接表的 30%–50%（Daylight 文档），语义编码三性占优（稳定性↑、高密度性↑、逻辑精准性↑）。代价是：学习 SMILES 编码规则（分支括号、环闭合数字、芳香性小写、立体化学标注）需专门训练（可习得性↓）；对同一结构存在多种合法 SMILES，须依赖规范化算法求得 unique SMILES（可扩张性/动态柔性在"唯一表达"上受限）；其记号对人类直觉极不友好，看字符串难以想象三维结构。InChI 更以完全机器导向、彻底牺牲人读性为代价换取全球唯一标识。化学记号的"图画↔字符串"对立，正是自然语言↔形式化语言这对零和在化学维度的复刻；所谓"统一化学语言"同样坠入取舍。

7.2 音乐：通用记谱法 vs 机器事件流（MIDI/形式表示）

西方通用记谱法是形式编码三性的范例：习乐者经训练可识谱演奏，记谱法能柔性容纳速度、力度、表情、装饰音等随作品与演绎变化的要素（可习得性→、可扩张性↑、动态柔性↑），且同一份总谱可被不同演奏家给出不同合理诠释（语义稳定性→但留白多）。代价是语义编码弱：音符时值、连断、强弱本就含演奏者再解释空间，机器无法仅从谱面无歧义推出声音（逻辑精准性↓）；大量音乐意图（rubato、句法呼吸）靠人领受而非符号固化（高密度性↓）。与之相对，MIDI 事件流或形式音乐表示（以精确时间戳与参数编码每一声部）把语义钉死为机器可重放的数据（稳定性↑、逻辑精准性↑），却以牺牲"人读性、即兴诠释与表情柔性"为对价（可习得性↓、动态柔性↓）；它精确却枯燥，丢失了记谱法承载的人文柔性。音乐界从未造出"既像总谱一样可被艺术家自由诠释、又像 MIDI 一样被机器无歧义执行"的单一记号——这又是零和。

7.3 形式化需求语言（Requirements DSL）：EARS 作为受控自然语言的折中

系统工程的需求若只用自然语言，便落入 §2.3 的歧义陷阱；若直接跳到完全形式化（如 Z、Alloy、B 方法），又以陡峭学习曲线与高昂构建成本把多数干系人拒之门外。Mavin、Wilkinson、Harwood 与 Novak（2009，DOI: 10.1109/RE.2009.9）提出 EARS（Easy Approach to Requirements Syntax），以少量结构模板（事件驱动、状态驱动、无歧义、可选、unwanted 行为等句式，均以 shall 表达）约束自然语言，使全部需求落入可控句式。EARS 的精妙处在于它试图把代价"卡在中间"：相比纯自然语言，它显著降低了歧义与复杂度（稳定性↑、逻辑精准性→），且因仍是有结构的自然语言而保持了较高可习得性（可习得性↑）；但其代价是表达力受限——模板难以自然容纳八类常见需求问题之外、或需复杂时序/概率语义的需求（可扩张性↓、高密度性在复杂场景受限），且模板本身仍需训练与审查（动态柔性→）。EARS 恰似 MBSE 中"以受限自然语言补强需求纪律"的工程缩影：它不消除零和，而是把代价安置在"表达力 vs 精度/可习得性"的可接受中点。说白了，任何 Requirements DSL 都在"人易写"与"机易验"之间选点，无人能两端皆满。

7.4 法律代码化：Lessig 的"代码即法律"与 Rules as Code

§2.5 已触及法律条文，此处以 Lessig（1999）《Code and Other Laws of Cyberspace》的"代码即法律"作结：软件代码与法律同为规制行为的符号系统。自然语言法律可习得、可柔性演化、容纳司法解释（形式编码三性↑），但充满歧义、需解释、难机器执行（语义编码三性↓）。"规则即代码"（Rules as Code）运动把法规编译为可执行逻辑以获确定性，代价是丢失自然语言弹性与情境判断（动态柔性↓、可扩张性↓），且须专家把守、构建昂贵（可习得性↓）。法律与代码在此形成完美对称：两者皆在"被大众柔性使用"与"被机器精确执行"间二选一。任何"法言法语完全代码化"的终极理想，终将重新坠入这一取舍。

综合上述，化学、音乐、需求语言、法律四例，与 §2 的编程/数学/自然语言/本体/数据库/API 一并，构成跨十余个互不相干符号家族的证据网——它们以各自独立的历史路径、互不因果地重现同一六性站位结构。

---

8. 数学记号的"直觉—形式"双重体系与综合站位总表

8.1 范畴论与集合论：互补而非化解零和

数学记号常被误认为"已经解决了零和"的范本，因为现代数学既有高度直觉化的书写，又有完全形式化的证明助手。但细察可知，它只是把零和"分工管理"，而非消除。日常数学写作（直观记号、图示、省略号）追求可读与柔性（可习得性↑、动态柔性↑），代价是语义稳定与逻辑精准依赖人（稳定性→、逻辑精准性↓）。为获机器保证，证明助手（Coq/Agda/Lean）走向形式化（逻辑精准性↑↑），代价是形式编码塌缩（§2.2、§6.1 第四档）。

在基础层面，集合论（ZFC）与范畴论（Mac Lane，1998，DOI: 10.1007/978-1-4757-4721-8）构成一对互补的"直觉—形式"策略。集合论以"集合与元素"的具体直觉奠基，相对易习得、易外推到多数数学分支（可习得性→、可扩张性↑），但为排除罗素悖论等须引入正则公理、替换公理等精细约束，形式化后同样需机器辅助（逻辑精准性→）。范畴论则以"范畴、函子、自然变换"的高阶抽象统一众多结构，其高密度性与稳定性无与伦比（高密度性↑、稳定性↑），却以极陡学习曲线为对价（可习得性↓↓）。两者不是"谁更优"，而是把代价安置在不同处：集合论偏向可扩张与直觉，范畴论偏向统一与高密度。"以范畴论统一全部数学"的宏大计划（如同伦类型论试图统合证明与程序）与"以类型论统一程序与证明"一样（Bertot & Castéran，2004；Norell，2007；de Moura 等，2015），最终以可习得性的塌缩换取统一的语义严谨——这正是 §3 所述"大一统框架理想"在数学内部的重演。

因此，数学的"直觉—形式"双重体系，并非零和的解药，而是零和的一种精巧分工：用直觉记号覆盖人的理解侧、用形式系统覆盖机器验证侧，二者之间通过大量人工翻译桥接，而桥接本身（把直观证明改写为 Coq/Lean 脚本）正是代价所在。它再次说明：任何符号系统的"统一/终极"企图，都只是在左右两栏间重新安排代价。

8.2 综合站位总表

为直观显示"无人六性全优"，下表合并本章全部案例（含 §1–§2 与 §6–§7 新增），以"↑/→/↓"标注各性站位：

纵览全表，二十行无一行在六列同时"↑"；渐进类型与 EARS 虽以"桥接/折中"把多列拉到"→"，却各自引入新代价（运行期检查、表达力受限），仍非六性全优。这张表把全书核心论点压缩为一个可一眼看清的事实：零和取舍是符号系统的结构常数，MBSE 仅是其在工程领域的投影；任何"统一/终极"符号体系，都只是在左右两栏之间重新安排代价。

8.3 本章小结补遗

新增三节（§6–§8）把论证地基从工程与少数对照样本，扩展到编程语言全光谱、化学、音乐、需求语言、法律与数学基础。它们共同表明：零和取舍不是 MBSE 的特例，也不是工程或软件的特例，而是所有以符号承载意义的系统共享的命运。当我们在 §3 断言"MBSE 只是普遍律之投影"时，这一断言现在有了跨越十余独立符号家族、且含一张二十行综合表的坚实支撑。

需补充一点反直觉的观察：有人或以为"渐进类型"与"EARS 受控自然语言"这类折中方案已经逼近六性全优。但 §6.1 与 §7.3 已揭示，它们只是把代价从某一维挪到另一维——渐进类型将保证的边界推到运行期并引入 blame 复杂度，EARS 以表达力受限换取精度与可习得性的兼得。折中不等于消除，桥接本身即代价。这恰恰反向印证了核心论点：帕累托最优在符号系统的六性空间里不存在，所谓"最优"永远只是"把代价安置在可接受的某一处"。对 MBSE 实践者而言，这意味着即便采用 SysML v2/KerML 这类回调语义严谨的新语言，也应当预期其必然重新抬高学习门槛与建模刚性，并提前为这一代价安排培训、工具链与局部形式化补强——而非幻想存在一套让六性同时达优的终极记号。

第9章 结论：零和取舍不可逃逸，MBSE 只是它的一个投影

9.1 核心论点的回响

本报告始于一个看似朴素、却经不起轻率否定而被反复验证的命题：符号系统必然在形式编码（可习得性、可扩张性、动态柔性）与语义编码（稳定性、高密度性、逻辑精准性）之间做不可逆的零和取舍，不存在完美兼顾的终极体系。 以 MBSE 为棱镜，我们用八章篇幅检视了它的历史、实现、趋势、局限、争议与未来，得到的不是对命题的证伪，而是它在每一个工程与认知维度上的逐一显形。

"零和"在此被精确理解为帕累托最优的不存在：六性无法被任何单一体系同时推至最优，任何一侧的改善都必然以另一侧可度量的退化为代价。增益与代价未必等值，但"六性全优"在数学与工程上均不可达。这一限定至关重要——它使命题避免沦为"此消彼长"的庸常直觉，而上升为一条可被严肃讨论的结构性定律。

9.2 五维回顾：历史、实现、趋势与局限、争议、未来如何印证零和

历史背景（第1章） 揭示，MBSE 并非凭空而生，而是文档中心系统工程（DBSE）在语义稳定性上全面失稳（文档爆炸、不一致、可追溯性崩溃）后的应激产物。然而 MBSE 的诞生并未消除张力，只是把"语义失稳"的病灶从非结构化文本转移到了模型——并且立刻在"让模型易学易扩"与"让模型语义严丝合缝"之间重新分裂。INCOSE 的 MBSE Initiative、SysML 的语言演进、标准与工具生态的繁荣，每一步都是一次取舍权重的再分配。

实现方式（第2章） 呈现了语言、方法与工具的繁芜谱系：SysML 以 UML profile 换取可扩张性却稀释语义；OPM 以极简图元换取高语义密度却抬高学习门槛；KerML 以一阶逻辑+4D 形式语义换取逻辑精准却牺牲易学易扩；OOSEM、Harmony-SE、State Analysis、Arcadia 等方法各有站位；Cameo、Rhapsody、Capella、Papyrus 等工具各擅开放与锁定。实现的多样性本身，正是零和尚未被任何体系消解的证据——每一种方案都只是在自己偏好的编码侧重上优化。

趋势与局限（第4、5章） 构成一体两面。数字工程、数字孪生、MBSE+敏捷、AI 融合、SysML v2 与开源生态，无一不是在取舍曲线上寻找更优折中：AI 放大形式编码的柔性（自动生成、一致性检查），却以语义漂移与不可解释性稀释语义精准；数字孪生提升语义保真，却以集成与维护成本为代价。而局限性——陡峭学习曲线、工具锁定、残留歧义、可扩展性悖论、ROI 不确定、覆盖鸿沟、验证边界——每一项都可被还原为零和取舍在特定工程场景下的具体投影。局限性不是工程失误，而是符号系统本质张力的必然外显。

争议与立场（第6章） 最直观地暴露了零和的本质。供应商锁定 vs 开放标准、形式化严谨 vs 务实可用、模型 vs 文档、ROI 怀疑、标准碎片化、适用性边界——这些争议的表面分歧，实质是不同利益相关方在零和曲线上选择了不同最优点。INCOSE、学术界、工具厂商、大型国防航天承包商、中小企业、政府监管机构，各自的最优站位不同，因而无人能声称握有"正确体系"。一个反直觉的发现（UF-10）是：工业派并不反对严谨，而是反对"以严谨替代需求纪律"——TCAS II 等反思表明，大模型的失效常因高层意图未被捕获，而非缺乏形式化。这恰好印证，语义编码单方无法解决问题。

未来方向（第7章） 给出的不是突破零和的许诺，而是与之和解的冷静设计哲学：语言收敛于 SysML v2/KerML 的坚实语义底座，却须接受其学习门槛；形式化方法"适度下沉"到关键域，同时在沟通层保留非形式化；AI 承担形式编码的繁重劳动、人类负责语义把关，把零和"分工化"而非消除；开放互操作与 DSL/通用语言的内部分裂持续并存。未来是更优折中，不是终极体系。

9.3 跨域印证与设计哲学

第8章把视野推离 MBSE：从航空航天 JPL 状态分析、汽车 AUTOSAR、国防安全关键系统，到编程语言（动态 vs 静态类型）、数学记号与证明助手（Coq/Lean）、自然语言、本体（OWL）、关系模型（Codd）、API 设计——无一例外地显现同一零和律。一个值得警惕的方法论自觉（UF-14）是：当检视 15+ 互不相干的符号系统却零反例时，命题有滑向"同义反复/定义性"而非"经验性"的风险。本报告因此将零和取舍定为结构性常数，并以认知（符号必为世界的压缩投影）、信息（信道容量有限，密度与柔性不可兼得）、演化（体系须随需求变易，变易必损稳定）三重根由支撑，而非轻率宣告为"被发现的经验事实"。

由此可得的设计哲学是：承认取舍、按需配比、可演进、可接受不完美。 工程组织不应再追逐"统一终极语言"的幻象，而应在六个性质之间进行有意识、可审计、随项目风险而变的权重配置；对安全关键域向语义编码倾斜，对探索性创新域向形式编码倾斜；用人机分工把代价转移与隐藏，而非假装消除。MBSE 的真正成熟，不在于宣称超越了零和，而在于学会在零和曲线上清醒地行走。

9.3.1 对工程组织的五条可操作建议

将零和框架落到工程实践，可提炼为五条可操作原则：

1. 显式化取舍决策。在项目启动阶段即以六性雷达图记录各方权重，形成可审计的"建模章程（modeling charter）"，使"为何如此建模"从个人直觉变为组织记忆。这本身是把"动态柔性"的代价前置，以换取"语义稳定"与"逻辑精准"。

2. 风险驱动配置。对安全关键、任务关键域向语义编码倾斜（采用形式语义、可执行模型、形式化验证）；对探索性、快节奏创新域向形式编码倾斜（轻量语言、易学易改、快速迭代）。同一组织内不同项目可处于零和曲线上的不同最优点，无需强求统一。

3. 预算语义治理成本。把模型一致性检查、本体维护、工具互操作、跨工具迁移计入工作分解结构（WBS）与进度，避免"建模即写完"的错觉。语义稳定性的维护是有价的，忽视它只会让漂移在后期以返工形式加倍偿还。

4. 人机分工而非人机替代。用 AI 承担形式编码的繁重劳动（样板生成、模式抽取、冲突预检），同时设立"语义守门人"角色负责最终核准与签字。责任归属必须落在人，而非模型或算法。

5. 接受不完美与可演进。模型是"足够好且可演进"的工程契约，而非一次到位的绝对真理。把版本演进、重构成本纳入生命周期考量，才能使系统随需求柔性演化而不致语义崩塌。

9.3.2 对研究议程的启示

零和框架同时划定了未解问题的边界，提示五条值得投入的研究方向：

• 形式语义的经济学边界：在何种项目规模、何种失败代价下，引入严格形式语义的边际收益由正转负？需要可复用的成本—收益拐点模型。

• 跨工具语义保真度的可度量指标：XMI/API 迁移失真目前多为 anecdotal，缺乏量化基准；建立"语义漂移度量"是互操作从愿望走向工程的前提。

• 人机协作中的责任与认证框架：当 AI 参与建模，现有认证（DO-178C、ISO 15288 符合性）如何接纳"模型即证据"？责任如何随人机分工分配？

• 轻量化 MBSE（thin MBSE）方法学：为中小组织与快节奏领域提供"够用即可"的精简建模子集，避免在形式编码一侧过度投资。

• 把"零和定律"本身作为可证伪命题推进实证：是否存在反例系统？哪些符号系统在六性上逼近更优折中？持续的跨域普查，是对本报告核心命题最严格的检验。

---

9.4 参考文献

一、核心参考文献库

[A1]★ Madni, A. M., & Sievers, M. (2018). Model-based systems engineering: Motivation, current status, and research opportunities. Systems Engineering, 21(3), 172–190. DOI: 10.1002/sys.21438. PDF: https://incose.onlinelibrary.wiley.com/doi/10.1002/sys.21438
[A2]★ Dori, D. (2016). Model-Based Systems Engineering with OPM and SysML. Springer. DOI: 10.1007/978-1-4939-3295-5. PDF: https://link.springer.com/book/10.1007/978-1-4939-3295-5
[A3]★ Borky, J. M., & Bradley, T. H. (2018). Effective Model-Based Systems Engineering. Springer. DOI: 10.1007/978-3-319-95669-5. PDF: https://link.springer.com/book/10.1007/978-3-319-95669-5
[A4]★ ISO/IEC/IEEE 15288:2015. Systems and software engineering — System life cycle processes. IEEE. DOI: 10.1109/IEEESTD.2015.7106435. PDF: https://ieeexplore.ieee.org/document/7106435
[A5]★ Weilkiens, T., Lamm, J. G., Roth, S., & Walker, M. (2015). Model-Based System Architecture. Wiley. DOI: 10.1002/9781119051930. PDF: https://www.wiley.com/en-gb/Model-Based+System+Architecture-p-x000751171
[A6]★ Holt, J., Perry, S., & Brownsword, M. (2011/2012). Model-Based Requirements Engineering. IET. DOI: 10.1049/pbpc009e. PDF: https://articles.researchsolutions.com/model-based-requirements-engineering/doi/10.1049/pbpc009e
[A7]★ Madni, A. M., Madni, C. C., & Lucero, D. S. (2019). Leveraging Digital Twin Technology in Model-Based Systems Engineering. Systems, 7(1), 7. DOI: 10.3390/systems7010007. PDF: https://www.mdpi.com/2079-8954/7/1/7
[A8]★ Object Management Group (2023/2025). OMG Systems Modeling Language (SysML) v2. OMG. 无 DOI（标准）. 2023-06 beta；2025-07 正式采纳. PDF: https://www.omg.org/spec/SysML/2.0/Beta2
[A9]★ Object Management Group (2023/2025). Kernel Modeling Language (KerML) v1.0. OMG. 无 DOI（标准）. 一阶逻辑+4D 时空外延形式语义. 新闻稿: http://sbc.omg.org/news/releases/pr2023/07-10-23.htm
[A10]★ Estefan, J. A. (2008). A Survey of Model-Based Systems Engineering (MBSE) Methodologies, Rev. B. INCOSE-TD-2007-003-02. 无 DOI. PDF: https://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf
[A11]★ INCOSE (2023). Systems Engineering Handbook, 5th ed. Wiley/INCOSE. ISBN 9781119814290. 无 DOI. PDF: https://www.wiley.com/en-us/INCOSE-Systems-Engineering-Handbook-5th-Edition-p-9781119814290
[A12]★ NASA (2016). NASA Systems Engineering Handbook, SP-2016-6105 Rev2. NASA. 无 DOI. PDF: https://www.nasa.gov/nasa-systems-engineering-handbook/
[A13]○ Hall, A. D. (1962). A Methodology for Systems Engineering. Van Nostrand. 无 DOI. https://archive.org/details/methodologyforsy00hall
[A14]○ Sage, A. P. (1992). Systems Engineering. Wiley. 无 DOI.
[A15]○ Wymore, A. W. (1993). Model-Based Systems Engineering. CRC Press. DOI 复核: 10.1201/9780203747504.
[A16]○ Friedenthal, S., Moore, A., & Steiner, R. (2014/2018). A Practical Guide to SysML, 3rd ed. Morgan Kaufmann/Elsevier. ISBN 9780128008003. 无 DOI. PDF(subscription): https://www.sciencedirect.com/book/9780128002025
[A17]○ Long, D., & Scott, Z. (2011/2017). A Primer for Model-Based Systems Engineering, 2nd ed. Vitech. 无 DOI.
[A18]○ Weilkiens, T. (2011). Systems Engineering with SysML/UML. Morgan Kaufmann. DOI 复核: 10.1016/C2016-0-00038-6.
[A19]○ Karban, R. (2017). Model-Based Systems Engineering with Genesis. 技术专著. 无 DOI（待复核）.
[A20]○ Harel, D., & Politi, M. (1998). Modeling Reactive Systems with Statecharts. McGraw-Hill. 无 DOI.
[A21]○ Ingham, M. D., Rasmussen, R. D., Bennett, M. B., & Haase, K. H. (2004). State Analysis: A General-Purpose, Model-Based Approach to Real-Time Systems. NASA/JPL. 无 DOI. NTRS.
[A22]○ Douglass, B. P. (2009). Real-Time Agility: The Harmony/ESW Method. Addison-Wesley. 无 DOI.
[A23]○ Roques, D. (2016). Arcadia: A model-based engineering method. INSIGHT, 19(3), 27–32. INCOSE. DOI 复核: 10.1002/inst.12045.
[A24]○ Guizzardi, G. (2007). On ontology, ontologies, conceptualizations, modeling languages, and (meta)models. Proc. 7th Int. Baltic Conf. on Databases and Information Systems. 无 DOI.
[A25]○ Broy, M., & Cengarle, M. V. (2010). UML formal semantics. In Formal Methods for Model-Driven Engineering (LNCS 7320). Springer. DOI 复核: 10.1007/978-3-642-16277-0_2.
[A26]○ Schürr, A. (1994). Specification of graph translators with triple graph grammars. WG'94, LNCS 903. Springer. DOI 复核: 10.1007/3-540-59071-4_45.
[A27]○ Evermann, J. (2009). Using ontologies for the verification of UML/OCL models. Journal of Computing and Information Technology, 17(4). DOI 复核: 10.2498/cit.1001524.
[A28]○ INCOSE (2007). Systems Engineering Vision 2020. INCOSE-TP-2004-004-02. 无 DOI.
[A29]○ INCOSE (2021). Systems Engineering Vision 2035. INCOSE. 无 DOI.
[A30]○ DoD (2018). Digital Engineering Strategy. US DoD. 无 DOI. PDF: https://www.cto.mil/digital_engineering/
[A31]○ Grieves, M. (2014). Digital Twin: Manufacturing Excellence through Virtual Factory Replication. NASA White Paper. 无 DOI.
[A32]○ Stoewer, H. (2014). MBSE: missing link in the digital enterprise strategy? Keynote, INCOSE MBSE Workshop. 无 DOI.
[A33]○ Object Management Group (2007–2019). OMG Systems Modeling Language (SysML) v1.0–v1.6. OMG. 无 DOI. PDF: https://www.omg.org/spec/SysML/
[A34]○ Object Management Group (2017). Unified Modeling Language (UML) v2.5.1. OMG. 无 DOI. PDF: https://www.omg.org/spec/UML/2.5.1/
[A35]○ ISO/IEC/IEEE 15288:2023. System life cycle processes (更新版). IEEE. 引用 2023 版须复核其 DOI，或回引 [A4] 并注明已被 2023 取代.
[A36]○ Lamm, J. G., & Weilkiens, T. (2011). Do we need a requirements management method? Proc. 21st INCOSE Int. Symp. 会议号待复核.
[A37]○ INCOSE MBSE Initiative (2007–). MBSE Wiki / Roadmap / Pulse Check. OMG Wiki. 无 DOI. https://www.omgwiki.org/MBSE/
[A38]○ Seidewitz, E. (2023). KerML 形式语义（一阶逻辑、4D 时空外延）. 见 OMG SysML v2 提交材料 [A9].
[A39]○ OpenMBEE (2020s). Open-source Model-Based Engineering Environment. 无 DOI. https://www.openmbee.org/
[A40]○ Schäfer, W., & Wehrheim, H. (2009). The challenges of building advanced mechatronic systems. Proc. ICSE 2009. DOI 复核: 10.1109/ICSE.2009.5070536.
[A41]○ Browning, T. R. (2001). Applying the Design Structure Matrix to system decomposition and integration. IEEE Trans. Engineering Management, 48(3). DOI: 10.1109/17.936271.
[A42]○ Eppinger, S. D., & Browning, T. R. (2012). Design Structure Matrix Methods and Applications. MIT Press. 无 DOI.
[A43]○ Estefan, J. A. 同上 [A10]，详述 OOSEM、Harmony-SE、State Analysis、Statemate、ROOM、RUP 等方法谱系.
[A44]○ Kossiakoff, A., Sweet, W. N., Seymour, S. J., & Biemer, S. M. (2011). Systems Engineering Principles and Practice, 2nd ed. Wiley. 无 DOI.
[A45]○ Blanchard, B. S., & Fabrycky, W. J. (2011). Systems Engineering and Analysis, 5th ed. Prentice Hall. 无 DOI.
[A46]○ Friedenthal, S. (2021 起). MBSE / SysML v2 相关论述；OMG 新闻稿 [A9].
[A47]○ Object Management Group (2019). SysML v1.6. OMG. 无 DOI. https://www.omg.org/spec/SysML/1.6/
[A48]○ OMG (2024). Systems Modeling API & Services v1.0. OMG. 无 DOI. https://www.omg.org/spec/SysML/2.0/Beta2
[A49]○ Weilkiens, T. SYSMOD — The Systems Modeling Method. oose 出版. 无 DOI（待复核）.
[A50]○ Modelica Association (2017). Modelica — A Unified Object-Oriented Language for Physical Systems Modeling (Modelica 3.4). 无 DOI. https://www.modelica.org/

二、各章补充文献

※ Crabb, E. S., & Jones, M. T. (2024). Accelerating MBSE by Harnessing Generative AI. SoSE 2024, 110–115. DOI: 10.1109/SOSE62659.2024.10620975.
※ Johns, B., Carroll, K., Medina, C., Lewark, R., & Walliser, J. (2024). AI-SME: ChatGPT-enabled MBSE Modeling Assistant. INCOSE Int. Symp. 2024. DOI: 10.1002/iis2.13201.
※ Patel, R., 等 (2024). [Generative AI for MBSE]. SPACE 2024. DOI: 10.1109/SPACE63117.2024.10667868.
※ Hedberg, T., et al. (2016). "Digital Twin" and "Digital Thread" definitions in MBE. ASME. DOI: 10.1115/1.4032697.
※ Huldt, T., & Stenius, I. (2019). Status and trends of MBSE adoption. Systems Engineering, 22(2). DOI: 10.1002/sys.21466.
※ Henderson, K., & Salado, A. (2021). Value and benefits of MBSE: qualitative and quantitative research. Systems Engineering. DOI: 10.1002/sys.21566.
※ Longshore, R., Bell, R., & Madachy, R. (2024). Leveraging Generative AI to Modify and Query MBSE Models. NPS Tech. Report. 无 DOI. https://dair.nps.edu/handle/123456789/5113
※ Bell, R., Longshore, R., & Madachy, R. (2024). Introducing SysEngBench… NPS Report. 无 DOI. https://dair.nps.edu/handle/123456789/5135
※ Wach, P., 等 (2024). The Cost of Expertise: Performance Tradeoffs in LLMs for Systems Engineering. INCOSE Int. Symp. 无 DOI（仅见聚合页，未强引）.
※ arXiv:2409.6741 (2024). A Systematic Survey of Generative AI for Requirements Engineering. 无 DOI. https://arxiv.org/abs/2409.6741
※ Pierce, B. C. (2002). Types and Programming Languages. MIT Press. ISBN 9780262162098. https://mitpressbookstore.mit.edu/book/9780262162098
※ de Moura, L., Kong, S., Avigad, J., van Doorn, F., & von Raumer, J. (2015). The Lean Theorem Prover (System Description). LNCS 9195, 378–388. DOI: 10.1007/978-3-319-21401-6_26
※ Norell, U. (2007). Towards a practical programming language based on dependent type theory. PhD thesis, Chalmers. ISBN 978-91-7291-996-9. PDF: https://www.cse.chalmers.se/~ulfn/papers/thesis.pdf
※ Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199–220. DOI: 10.1006/knac.1993.1008
※ Codd, E. F. (1970). A relational model of data for large shared data banks. CACM, 13(6), 377–387. DOI: 10.1145/362384.362685
※ Bertot, Y., & Castéran, P. (2004). Interactive Theorem Proving and Program Development: Coq'Art. Springer. DOI: 10.1007/978-3-662-07964-5
※ Mac Lane, S. (1998). Categories for the Working Mathematician, 2nd ed. Springer. DOI: 10.1007/978-1-4757-4721-8（指向 2013 eBook 重印）
※ Dörr, H. (2008). The AUTOSAR Way of Model-Based Engineering of Automotive Systems. ICGT 2008. DOI: 10.1007/978-3-540-87405-8_3
※ Natale, M. D. (2008). Design and Development of Component-Based Embedded Systems for Automotive Applications. Ada-Europe 2008. DOI: 10.1007/978-3-540-68624-8_2
※ Lano, K., & Kolahdouz-Rahimi, S. (2015). High-Integrity Model-Based Development. DOI: 10.4018/978-1-4666-6359-6.ch019
※ Elqortobi, A., 等 (2020). Verification and testing of safety-critical airborne systems: A model-based methodology. Computer Science and Information Systems, 17(1), 271–292. DOI: 10.2298/CSIS190430040E
※ Lessig, L. (1999). Code and Other Laws of Cyberspace. Basic Books. ISBN 046503912X. https://www.loc.gov/item/00271772/
※ Richardson, L., & Ruby, S. (2007). RESTful Web Services. O'Reilly. ISBN 9780596529260. https://www.oreilly.com/library/view/restful-web-services/9780596529260/

三、行业评论与白皮书（无 DOI，作观点性引用）

○ ITEA/OPEES (2019). Open source MBSE success story. https://itea4.org/index.php/magazine/34/november-2019/itea-success-story-opees.html
○ SE-Trends. Is open source a viable path in systems engineering? https://www.se-trends.de/en/open-source-se/
○ Systems-Wise. Selling MBSE. https://systems-wise.com/selling-mbse
○ Belcan (2022). Is Model-Based Systems Engineering for You? https://www.belcan.com/wp-content/uploads/2022/04/Is-Model-Based-Systems-Engineering-for-You.pdf
○ Schenker, A., & Hugues, J. (2023). [Thales/INCOSE MBSE 论文]. https://mbse-capella.org/resources/pdf/IS_2022_Paper_128_Article.pdf
○ Schenker & Hugues. You Can't Wait for ROI… NPS. https://dair.nps.edu/handle/123456789/4921
○ Nowodzienski & Navas (2022). Thales/INCOSE paper. https://mbse-capella.org/resources/pdf/IS_2022_Paper_128_Article.pdf
○ Sheridan Technologies (2026). MBSE practice guide. https://sheridantech.io/?p=17945/
○ TSight. 中文 MBSE 局限性评论. https://tsight.io/articles/6469239
○ Corvus Intell. Defense MBSE practice observations. https://corvusintell.com/blog/defense-software/model-based-systems-engineering-defense
○ One-Sys. From model to mindset… https://www.one-sys.eu/en/post/from-model-to-mindset-the-real-challenge-of-model-based-systems-engineering