译者注：

对象过程方法（OPM）将事物抽象描述为对象、状态和过程，并以此为基础新建了一种工程语言。如此彻底的抽象，其优点是显而易见的:不仅能对任何领域（除了亚原子尺度的微观领域）的任何系统作概念建模，而且语言简单，使用灵活。

不过，语言的灵活性是柄双刃剑。灵活性能避免束缚思维和表达，但同时会让模型过分个性化，信马由缰构建的模型难以描述复杂系统，不仅建模者自己会迷失方向，也不利于他人阅读理解和协作，让模型难以维护。

为了驾驭这种灵活性，让OPM更好地用于复杂系统建模，就必须合理制定并恰当运用建模规范。

在运用OPM对系统建模的实践探索过程中，我被OPM的灵活性负面影响所困扰。受到军事科学院杨峰教授的指点，向我介绍Yaniv Mordecai 先生和Dov Dori先生的论文《Model-BasedOperational-Functional Unified Specification for Mission Systems》)，读后感觉受益匪浅。全嘉钰将这篇极具价值的论文翻译成中文，和我一起反复讨论，最终成稿，在此分享给关注MBSE的读者。如有需要，可以与我们的团队联系，作进一步沟通及合作。

正如论文“讨论与总结”所述，关于OPM语言和建模规范，还有值得探讨的问题。在研读这篇论文时，论文的内容也引起了我们的很多思考。例如图6中“功能”与“机能”之间使用包含关系描述，没有体现关于涌现的认识。如何用模型描述涌现，还需要探索。图7中“运行”与“SRS”之间的关系，似乎使用实例链接更合适，但是当前的OPM语言并不支持这样的描述……诸多问题值得大家继续研究。

要恰当地翻译涉及方法论和语言的论文是个很大的挑战。文中有一些抽象语义，要逐字逐句翻译是做不到的，因为英语和汉语中描述抽象语义的词汇不能精确的一一对应。在翻译过程中，不得不在尊重原文的直译和揣摩内容的意译之间权衡取舍，同时承担理解错误的风险。上面的网址链接可以帮助读者方便地下载英文原文，这让我们误导读者的顾虑有所释怀。系统工程某些术语的译法目前还没有形成广泛共识。另外，为了尽量准确地体现本论文的思想，不得不在翻译中引入一些新的中文术语，仅限于理解本篇论文，欢迎读者指正。相关术语翻译如下：

Enveloping System（ES）：包络系统

Functionality：功能

Function：机能

Interoperability：互操作性

Operational-Function：运行功能

Requirement：需求

Stakeholder：利益相关方

System-Contained Scenario（SCS）：包含系统（指SoI，译者注）的场景

System-Reliant Scenario（SRS）：系统（指SoI，译者注）依赖的场景

System-of-Interest（SoI）：所关注系统

Systems of Systems（SoS）：体系

Validation：确认

Verification：验证

要理解本论文所阐述的内容，有必要对OPM有一定了解，建议阅读Dov Dori先生的著作《基于模型的系统工程-综合运用OPM与SysML》（杨峰等译）。

摘要

在系统工程所考虑的问题中，运行功能需求及场景是一个方面，系统功能及技术需求是另一个方面，如何针对这两个方面联合开展架构定义、设计定义和仿真是系统工程常见的挑战。我们提出了一种基于模型的系统工程方法来应对这一挑战。混淆运行和功能源于系统工程师的固有倾向，即采用以系统为中心的观点，并且所采用的建模技术不足以解决这个问题。功能模型是对总体运行环境的片面认识，而面向业务过程的模型则是对系统架构的部分覆盖，因为架构是结构和行为的组合体。当运行场景依赖系统响应，但运行场景不确定；或运行场景运用多个系统功能时，问题会更严重。不同领域的运行任务管理需要系统中多个规划功能、执行功能和控制功能，并管理运行功能之间的差别。

关键词：

基于模型的系统工程（Model-Based Systems Engineering，MBSE），对象过程方法（Object-Process Methodology，OPM），功能分析（Functional Analysis），运行分析（ OperationalAnalysis），基于场景的设计（Scenario Based Design，SBD）

1. 引言

区分系统的运行视角和功能视角是系统工程常见问题。基于问题域的运行视角与业务或运行相关，而基于解决方案域的功能视角则与系统和目的相关。区分运行需求、系统功能需求、系统需求规范和系统设计都非常困难，这对系统工程师来说是个挑战，在新的和正在开展的系统工程和运行程序中，该挑战反复出现。

系统模型本质上是以系统为中心的，并因此偏向于系统功能架构视角：它们从系统视角描述系统周围环境和系统行为方式。系统工程师经常倾向并致力于引入现有系统或子系统，以使他们的利益相关方和利益集团受益。例如，参与开发计划的公司都围绕各自拥有的资产（技术、服务、系统组件等）介绍系统，希望依靠这些资产提供功能和价值。最后，传统的系统工程标准很难结合系统功能设计来表达运行需求[1]。

尽管以功能系统为中心的模型偏向于以解决方案为导向的基本视角，但是面向业务的过程规范（使用如业务过程建模BPM、基于场景的设计SBD或架构框架AF中的运行视角等方法）未映射到实际资产、解决方案和促进这些场景的系统功能，从而缺乏它们的支撑。以功能系统为中心的模型有助于弄清端到端、运行环境、业务依据及理由或问题域的范围和说明，但是它们几乎不能用于描述系统架构。

对于结合场景和功能的模型需求已得到充分理解[2]。基于UML或SysML等语言的建模方法为面向业务或客户的可视化描述提供了单独的视图[3、4]，包括用例图和活动图，以及SysML所独有的需求图。SysML还为功能规范提出了单独的视图，包括块定义图、状态图和顺序图。这种分解是经过深思熟虑的，并且是UML分解方法的一部分。用例主要用于描述与客户相关的运行场景，但常常被误用于描述系统功能，而不是用于描述外部参与者运用这些功能的场景[5]。另外，用例之间是松散的，非结构化的，与UML的其他模型没有很好地衔接[6]。

在本文中，我们提出了运行功能统一规范（Operational-Functional Unified Specification：OFUS），这是一种基于模型的方法，可以在一个连贯、统一和协同的模型中结合对功能的考虑并描述运行。

该框架基于对象过程方法（Object-Process Methodology：OPM，符合国际标准ISO-19450），这是一种基于整体模型的系统工程（MBSE）范例[7]，[8]，用于描述复杂系统和过程。使用OPM可以将建模模式无缝地集成到任何基于OPM的系统模型中，并使其具有OFUS的优点。

OFUS方法是对任务系统进行概念建模研究的成果。任务是一种运行场景，其中所关注系统（System-of-Interest：SoI）扮演着一定的角色。在详细描述和设计SoI时，很难区分与任务相关的运行和系统功能这两种行为。为了解决此问题，我们开发了基于OPM的建模模式，该模式可捕获运行场景和系统功能。我们在具有挑战性的搜索和救援行动中演示了这种模式。这种情况特别有意义，它首先是任务规划场景，然后是任务执行场景。这两种场景均需要系统的任务规划功能和执行功能支持。

本文的其余部分安排如下：第二节是文献综述，讨论了相关的主题，包括基于场景的设计（Scenario-Based Design：SBD）和OPM；第三部分介绍OFUS即运行功能统一规范；第四部分讨论了OFUS在搜索和救援任务系统中的运用；第五部分包括问题讨论、研究结论以及未来的研究方向。

2. 文献综述

A． 基于场景的设计

基于场景的设计（SBD）[9、10]是面向应用的非正式软件设计技术，它专注于用户体验和使用场景，需要软件系统支持。这与面向解决方案设计的功能规范方法不同[11]。在纸上用二维铅笔草图描述用户交互场景，旨在生动地捕捉交互设计的本质，就像用机械图纸作物理设计一样。

SBD是在20世纪90年代中期到2000年代中期由卡洛尔、罗森等人带头发展起来的。这种方法被批判的原因在于既无法真正捕获用户目标，又无法满足功能设计的需求，而功能设计最终是用来完善SoI的[2]。SBD的集成主要用于嵌入式、并行和实时系统建模，主要与状态图集成[12-15]。

B． 架构框架中的运行视角

美国国防部架构框架（DoDAF）包括运行视角（OperationalViewpoint：OV，译者注：在军事领域常被翻译为“作战视角”）和能力视角（CapabilityViewpoint：CV），OV识别并描述支持任务和活动的运行分析、运行要素和资源交换[16]。与CV模型相关的OV模型将系统能力映射到所支持的运行活动。它们的主要缺点是各种OV模型数量多且冗余，这些OV模型之间边界模糊，虽然模型的名称不同，却会重复描述同样的内容，描述往往不一致。

基于UML的UPDM（Unified Profile for DoDAF and theUK Ministry of Defense Architecture Framework，美国国防部架构框架DoDAF和英国国防部架构框架MoDAF的统一配置文件）试图围绕系统能力和服务展开，并导出专用视图，这些视图用于将业务活动映射到能力(STV-6)，以及将服务映射到能力[17]，以解决DoDAF和MODAF中的挑战。这种方法允许在系统功能的背景下构建运行场景，从而通过功能来限制更广泛的运行背景。统一架构框架（Unified Architecture Framework：UAF）旨在调解北约（NATO）成员间的各种框架和开发计划，以使他们能够在相互了解能力、功能和接口的基础上，确保联盟的互操作性以及联合行动计划并执行[18]。

C． 对象过程方法（OPM）

随着现代系统和问题的复杂性不断增长，绝大多数建模和架构框架的复杂性也随之不断增长。复杂系统需要用简单模型描述，OPM一直在辩论和证明这一点，为此坚持了大约二十年。OPM致力于简单，这体现在以下几个关键特征上：

（a）符号数量最少，只有20个符号。与之对比，UML有120个符号；

（b）唯一一种图，即对象过程图（Object-ProcessDiagram：OPD），它捕捉结构、行为和功能方面。与之对比，UML有14种图，SysML有9种图；

（c）通过定义明确的抽象提炼机制，基于本质（而非基于外表）分解，降低复杂性并管理复杂性，对于相互关联的不同层级OPD，其抽象结构自相似；

（d）事物的通用本体（具有状态的对象，以及转换状态的过程）以及事物之间的关系，它证明在量子、亚微粒子级以外任何领域中是描述系统的一组必要和充分的概念集；

（e）图形文本双模表示法，可以在对象过程语言（Object-Process Language：OPL）中自动生成形式化的、连贯的OPD规范，OPL是基于上下文无关的语法，即自然语言[19、20]的子集。

通过其统一的结构、行为、功能建模方法[21]，OPM已被证明能够满足多种领域中复杂系统和流程的统一过程功能架构定义和设计，包括企业互操作性、决策自动化、计算机和通信协议以及弹道导弹防御系统[22-26]。而且，OPM已用于复杂生物过程的形式化描述[27、28]和项目产品生命周期管理[29、30]。

以功能为种子的OPM原理[21]指出，每个模型重要的基本过程是系统的种子功能。这可能让人担心OPM侧重于功能性。一旦我们意识到该模型描述的是基于环境的SoI集合而不是SoI本身，则无需担心这一问题，因为该功能既考虑了系统又考虑了环境，并且考虑了两者之间的相互影响。

OPM包含一组紧凑的图形元素（即事物和链接）集合。事物是过程（椭圆）和对象（矩形），对象具有状态（圆角矩形）。图1显示了过程、对象、状态，按照物理特征和环境特征对它们的分类，以及状态与对象的从属关系。过程和对象可以由较低层次的过程和对象组成。链接表示这些元素之间的各种关系。如图2所示的结构链接支持描述系统的静态特征。图3所示的过程链接描述与过程相关的关系、控制和因果。

图1 OPM事物符号：对象、过程、状态、物理类事物（阴影）、状态从属于对象（轮廓线）

图2 OPM结构链接关系

图3 OPM过程链接关系

UML和SysML所包含的多种图分别描述结构、行为、状态转换、活动和时间流。与此相比，OPM通过分层细化分解方式应对复杂性。分层组织的OPD是使用几种精简抽象机制相互关联的：

i）展开和折叠事物的结构层次。

ii）放大或缩小事物的内部细节（如图4）。

iii）显示和隐藏状态。

iv）创建新视图，即通过专门视图描述关键元素及其附加信息。

每个事物都要在某些OPD中至少被定义一次，以使其在整体模型中都是正确的。所定义的事物可以出现在指定模型OPD集任意一个OPD中。每一个事物都可以在任意OPD中被复制，即使没在某些OPD中出现，它也适用于所有OPD。

可以使用免费软件OPCAT V4.01 [31]构建OPM模型。OPCAT提供了一个图形用户界面（GUI），供分析人员创建、管理和共享他们的模型。它支持大多数OPM概念，并根据OPM语法和规则立即验证模型。OPCAT还可根据图形模型OPD自动生成OPL语句，并提供整个模型的OPL文本规范，或提供针对特定OPD的OPL文本。OPCAT提供了一个内置的定性仿真引擎，该引擎支持模型验证、确认和测试，在对复杂系统建模过程中，可视化交互特别有用。OPCAT软件的GUI屏幕截图如图5所示。

图4 在OPM中放大对象和过程

图5 OPCAT V4.0屏幕截图

（译者注：杨峰教授团队在OPCAT软件基础上开发了全中文软件GreatArch，GreatArch能将OPL文本以全中文形式呈现，并优化了OPCAT软件的某些功能）

OPM符号的轮廓颜色和填充颜色与模型语义无关。OPCAT软件对OPD符号轮廓和OPL文本默认定义的颜色是：对象为绿色，过程为蓝色，状态为卡其色。这些颜色可以更改，并非形式化语义。颜色用于提高可视化模型的可读性。OPCAT还将放大后的事物轮廓涂成加粗的灰色，并将折叠后的事物涂成加粗的红色。OPCAT允许建模者更改对象和过程的轮廓颜色和填充颜色，以提高视觉可读性，或利用颜色自定义语义类别。例如，我们可以将灰色填充默认为“当前状态”，而将另一种颜色（例如白色）默认为“未来状态”。

3. OFUS：运行功能统一规范

在本节中，我们一方面指定OFUS（即：一种建模模式，可以同时考虑到运行和业务）相关的场景，另一方面描述系统功能。我们首先对运行过程和功能过程之间的关系提出几点看法。我们定义了基线（仅仅是建模样板），其中的系统功能就是场景。然后，我们扩展此样板，使其成为可运行的功能，即它同时描述了运行场景和系统行为。

A． 指导性模型样板

我们首先在图6中定义一个指导性的OPM模型和相应的指导性建模样板。该指导性建模样板是基础，即区分功能-场景的起点。我们定义的系统由多个子系统组成。系统具有一些高层级功能。功能是机能的集合，集合中的机能共同提供某些系统能力。机能可以是多个功能的成员。例如，管理机能可以被视为管理功能的成员，而与某个能力相关的每个管理机能都可以被视为该能力的组成部分。

图6 指导性模型OPM图：OPD（上部分）和OPL（下部分）

功能是抽象的，是涌现出来的。而机能作为功能的构成要素，是由子系统实际运行的。指导性模型按其自身形式捕获系统的运行方式和系统功能。

B． 功能与场景区分

现在，我们扩展了建模模式，以在“功能”旁边添加“场景”概念。场景是与系统相关活动的可能序列。对于每个所关注系统（SoI），都有一个更高层级的包络系统（Enveloping System：ES即SoI及其环境），它完全包含构成场景的所有过程（活动）和涉及的对象。因此，场景始终是某些ES的种子功能。同一功能可以通过所含机能的不同子集支持多种场景。

从场景中区分功能很重要。尽管这两个过程集合看起来很相似，有时可以互换，并且可以在所有情况下定义为UML用例，但它们在建模、架构定义和设计定义中的目的不同。功能是机能的概念性容器，可为SoI受益人提供协同价值。因此，功能通过展开进行优化：详细说明其组成组件和属性。场景通过有序执行活动来创造价值。这样，场景通过缩放进行完善描述：过程{/对象}的执行{/部署}，内部时间{/空间}顺序的详细说明。在不同情况下，不同场景可能依赖同一功能。一个常见的例子是验证用户身份，它是用户管理功能的一部分，也是几个运行场景（如银行服务系统中的电汇或贷款请求）的一部分。

我们区分包含SoI的场景（System-ContainedScenario：SCS）和SoI依赖的场景（System-Reliant Scenario：SRS）。SCS是仅包含SoI功能的程序或过程，SoI或其某个子系统可以执行此过程。系统的每个功能都是一个SCS，但并非每个SCS都是一个功能。SRS涉及至少一项与SoI功能（或其结果）有关的活动，以及至少一项与SoI功能无关的活动。因此，任何SRS（较高层级的场景）都是ES（包含SoI并比SoI层级更高）的SCS（较低层级的场景）。通常情况下，隐含地假设系统所涉及的场景就是系统的功能，即它是SCS而不是SRS。

OFUS模式如图7所示。包络系统（ES）由系统和环境组成。ES展示了运行过程，该运行过程由一个或多个系统相关场景组成，他们包括系统活动和外部活动。系统活动调用构成系统功能的子系统机能。如前所述，环境事物的浅青色可提高图表的可读性，但没有形式化语义。

图7 功能场景OPM图

与涉及功能系统方面的功能不同，场景与行为有关：场景是一组旨在实现某些目标的机能。一个场景可以包含多个系统和用户。场景与功能的不同之处在于场景可以用一个模型对两个系统（功能和过程）同时进行建模。这样，我们可以将涌现系统特征或行为作为其功能（机能的特定组合）进行建模，这些功能对某些受益人的价值大于每个单独子系统提供的功能价值之和。功能与场景区分允许在一个统一模型中对系统功能分解，并对提供附加价值的程序进行建模。

可以说，这种方法扩展了严格功能和严格程序的方法。初步的建模和设计可以通过以下方式利用此方法：定义功能和机能，而不将其执行过程分配给特定的子系统或组件，并基于机能定义场景，而不必将它们统称为功能。这样就可以建立一个早期统一需求的OPM模型，该模型主要基于过程需求，这些需求主要是可运行的、用户定义的和面向问题的，其次是功能性需求，其中大多数是面向解决方案的。因此，OFUS模式对于早期的系统定义和概念化有用，还对高层级和详细的功能规范和设计非常有用，这是对开发项目影响最大的系统工程阶段。

4. OFUS在搜救任务系统中的应用

在本节中，我们将描述OFUS在任务系统中的一般应用。任务系统是在执行任务时被分派执行的活动，或支持组织、团队或其他系统的一组旨在实现明确目标的特殊活动。任务系统是体系（Systems of Systems：SoS）。任务体系至少包含两个过程：规划任务和执行任务。可以设想两个独立的体系功能（可以由独立系统或集成系统实现），即：（i）任务规划功能和（ii）任务功能。这种通用任务OFUS模式如图8所示。

图8 通用任务的OFUS图：包括一个任务规划场景和两个任务场景：已规划和未规划

例如，考虑失踪登山者的搜寻与救援（Search and Rescue：S＆R）任务。第一阶段是S＆R规划。第二阶段是S＆R行动本身，这可能包括搜索、营救或两者兼而有之，这取决于登山者的最后已知位置。一旦确定了登山者的位置，便会决定是进行救援行动还是让登山者继续登山。S＆R可以是通过飞机、车辆、步行或它们的某种手段的组合，并且通常受搜索区域天气和其他条件的影响。这些参数的每种组合都是潜在的场景或子场景。在某些情况下，我们可以将多个选项组合到一个场景中。

S＆R场景依赖S＆R系统功能的不同子集：

（i） S＆R规划（绘制地图，路线规划，部署规划）。

（ii） 指挥与控制（监视，通信，记录，决策）。

（iii）搜索（成像、无线电扫描）。

（iv）救援（飞机，徒步，医疗）

（v） 管理（团队管理，设备管理）。这些场景还可能依赖外部功能，例如卫星通信、视觉搜索和气象信息支持。

图9说明了这三种情况、五种系统功能及其非确定性关系。我们注意到此概念模型中的几个要素。首先，S＆RES场景（不是系统功能）的目标是拯救登山者。这些功能在某种意义上是具有激励-响应性的，因为它们是在运行相关场景时被调用和激活的。其次，根据网络信息与物理现实差异建模模式，场景执行配置是由登山团队的已知位置而不是其物理现实位置确定的[25、32]。第三，某些功能是通用的，且适用于多个场景，但另外一些功能则适用于特定场景。

图９基于OFUS的搜索&救援（S&R）任务模型：S&R规划场景和两个任务场景：搜索和救援

为了演示在一个场景中如何利用几种功能，在图10中，我们放大了“搜索场景”。这种情况显然依赖“搜索功能”，包括“成像功能”和“无线电扫描功能”，以及常见的“管理和命令与控制功能”。“搜索场景”沿着一组搜索路段（即相当于一条搜索路径）展开，相当于在搜索时分段重复实施“搜索”过程。如果在搜索过程中找到了登山者，或者已完全覆盖了搜索路线，则将触发新的“S＆R规划”周期。如果找到了登山者，并且需要救援，那么就会转入“触发救援”场景。搜索场景还依赖外部功能，例如“视觉搜索”和“卫星通信”。

图10基于OFUS的S&R任务模型：搜索场景利用搜索、管理、和指挥&控制功能

由OPCAT自动生成形式化OPL文本规范的子集，附加到基于OFUS的S＆R图上。OPL语句的子集侧重于系统功能结构、搜索场景活动的概述，最重要的是，场景活动的功能利用率以及场景执行、重复执行和完成的条件。结构和状态设置规范被省略了。由于本文研究范围有限，我们无法提供S＆R系统的完整规范或完整模型。

5. 讨论与总结

我们已经提出并讨论了以统一方式捕获和分析运行场景以及系统功能的挑战。我们提出了一个概念、框架和建模模式，它们为解决此问题奠定了基础。常用的分解方法（将运行和功能方面分别划分为两个或多个视图）是有问题的，因为它们之间会产生矛盾、不一致及概念设计不匹配。我们的方法（即运行功能统一规范，OFUS）将这两个方面统一起来，抓住了它们的密切关系并相互利用。OFUS的功能在于它能够顺利地从问题域过渡到解决方案域，以及将运行概念到架构功能设计作详尽阐述。

OFUS利用对象过程方法OPM。OPM的缩放机制可用于指定子过程同步性和探索运行场景。OPM的展开机制可用于指定异步过程或过程集群，描述系统功能，组成功能及其对子系统的分配。OFUS鼓励使用包络系统（ES）的概念，即所关注系统及其环境的集合。这种方法在广泛的背景下促进了系统整体分析。

我们已经在搜索和救援案例等任务系统上演示了OFUS。本案例是真实应用程序的简化版本，由于本文的范围，无法完全阐述。我们还在弹道导弹防御系统的演化设计中证明了这一概念的价值[23]，这启发了将概念扩展到建模和设计框架的层次。

进一步的研究旨在将OFUS正式化为一个框架，并建议与其他方法进行比较分析，同时研究一种建设性方法，该方法依靠OFUS来检测潜在的运行功能差异，并提出修正式建模和设计步骤以减少这些差异。我们还打算改善图形和语义表示方式，并减少可视化负担，并提高关键OFUS的OPM概念清晰度和表达能力，例如定义调用链接和其他专用语法和语义元素。

后记

希望您读了此文后有所受益。

如果您有经验乐于分享，欢迎投稿给我们。

如果您对我们的培训、咨询和工具感兴趣：