基于模型的系统工程（mbse)案例研究

《基于模型的系统工程（mbse)案例研究》由会员分享，可在线阅读，更多相关《基于模型的系统工程（mbse)案例研究（22页珍藏版）》请在装配图网上搜索。

1、 .wd.基于模型的系统工程MBSE的案例研究第 1 局部: IBM Rational Harmony 的集中式系统模型建模自出现以来，一直是系统工程的重要组成局部。在过去十年中，工程师们已经大幅增加基于模型的技术的使用，并开展出一门新的学科，基于模型的 系统工程Model-Based Systems Engineering, MBSE。这门学科与传统的系统工程不同，它强调中央系统模型，该模型同时捕捉系统需求和满足这些需求的设计决策。除了作为系统工程的工作构件的知识库 之外，还可以通过模拟系统模型来验证成本、性能研究和设计选择。IBM Rational Harmony for Systems

2、Engineers 等广泛应用的 MBSE 流程重点关注的是系统功能分析，也就是说，关注如何将功能要求转换为一致的系统操作描述。然后，使用系统操作获得所分配系统架构块之间的端口和接口。这些 接口形成了各子系统之间的正式切换的根基。Mohit Choudhary, 系统工程师, RealTime TechSolutions2012 年 3 月 23 日 内容本系列的这一局部旨在通过一个案例研究来探讨标准 MBSE 流程。首先，我们根据 UAV无人驾驶飞机地面站控制器的设计来拟定这个案例研究的范围。然后，我们会介绍 Rational Harmony 系统工程流程的 基本概念、工作流和工作产品。最后

3、，我们通过定义任务流来实现 UAV 地面站控制器的设计，同时构造每个阶段所需的构件。案例研究本案例研究基于对少局部 UAV 地面站控制器的设计分析，这些控制器的功能必须符合表 1 中的要求。表 1. UAV 地面站控制器需求需求引用 需求01 实时飞行中的 UAV 的信息。身份和传感器负载 02 允许操作员将搜寻区域分配给选定的飞行中的 UAV。 03 以 1 次更新/秒的频率接收来自 UAV 的传感器追踪信息。 04 在系统中保持 30 分钟的追踪历史。 05 允许操作员维护包含所采用的系统追踪信息的资料库。 06 最多维护 100 条 System Tracks系统追踪信息。 07 允许操

4、作员对系统追踪信息执行生命周期操作创立/删除。 08 每秒更新一次系统追踪信息，如果主传感器追踪信息更新可用，那么使用该值进展更新，否那么，使用 DR 的值进展更新。09 使系统追踪信息可在显示屏上显示，并绘制其更新。 10 允许操作员将操作员辅助系统追踪信息与另一台 UAV 的传感器追踪信息相关联。 11 允许操作员将两条独立的系统追踪信息合并成一条。 12 将系统中的重要事件比方创立和删除系统追踪信息通知操作员。 13 允许操作员随时中止 UAV 搜索。 Rational Harmony 系统工程中基于模型的系统工程Rational Harmony for Systems Engineer

5、ing 使您能够识别并推导出所需的系统功能，还能够确定相关的系统模式和状态。此外，您还可以将已确定的系统功能和状态分配给子系统构造，并确定跨子系统的端口和接口。图1显示了您在每个工程阶段为了完成系统设计而必须执行的 基本输入和输出。图 1. 工程阶段的生命周期在功能分析阶段，通过一个活动图定义用例的功能流。然后，从活动图推导出用例场景。各场景通过一组序列图表示，创立用例块的端口和接口时需要用到它们。最后，用例基于状态的行为被捕获为一个状态图。在 架构设计阶段，选定的系统块被分解成几局部。最终的系统构造被捕获在 SysML 块定义图 (BDD) 和 SysML 内部块图 (IBD) 中。每个用例

6、分配都可以通过一个关联的白盒活动图以图形的形式表示。以以下列图是用例的黑盒活动图的副本，但它被划分为泳道 (swim lane)。每条泳道代表分解层次的一个块。然后，根据选定的设计理念，将操作 “移动 到各自的块泳道。这种分配的一个 基本要求是要求维护操作之间的初始链接功能流。最后，详细架构设计阶段的重点是端口和接口的定义，以及在架构分解的最 低层，系统块基于状态的行为的定义。设计流程/大纲UAV 地面站的系统要求被划分成两个用例，如图2所示。为了实现可追溯性，需要将已确定的系统要求与相关的用例相关联。在本文中，假设已经完成需求分析。对于本案例研究，我们将重点关注 Uc1 PerformAre

7、aSearch 用例。 图 2. UAV 管理系统用例图功能分析用例的功能流涵盖的方面包括：将搜索分配给选定的UAV、接收来自UAV传感器的追踪信息、保持系统追踪信息与传感器追踪信息一致、维护所需要的传感器追踪信息更新历史、允许操作员中止搜索。您可以使用该工具在黑盒活动图中详细说明每个功能流，如图 3 所示。图 3. 黑盒活动图用例场景您可以看到，活动图中的每个流都表示一个不同的用例场景。这些流不仅能帮助我们详细了解功能流中的操作，还能形成在各个开发阶段验证用例行为的根基。在图 4 所示的五个场景中，您可以通过其中三个场景获得我们的用例。图 4. 黑盒用例场景用例状态图在下一步中，您可以使用序

8、列图获得端口和接口。获得端口和接口之后，必须在状态图中捕捉用例的状态行为。最后，为了设定用例的黑盒行为的基线，需要执行状态机，并且将生成的序列图与刚刚创立为场景的序列图进展比照。本用例的状态机如图 5 所示。图 5. 黑盒状态图状 态 “Search Executed 有两个 and 子状态：“Perform Sensor Track Management 执行传感器追踪信息管理 和 “Perform History Check。第一个子状态支持追踪信息的建设或更新，第二个子状态去除大于 30 分钟的传感器追踪信息历史，如果传感器追踪信息没有历史记录，那么去除传感器追踪信息本身。架构设计在架构

9、设计阶段，您需要重点关注构造分解，以及如何将操作和行为分配给子系统组件。首先，我们描述了将系统构造性分解成子系统的系统 BDD参见图 6，然后我们将获得 Use Case White-Box Activity Diagram，并通过它将用例的操作分配给分解后的子系统参见图 7。当将系统分解成子块后，它会以关键系统功能的定义为根基。这一阶段的目标是对系统功能进展分组，每个组可以通过一个子系统组件实现。第一步是将相关的系统功能划分为关键系统功能。对于本用例，我们通过用例黑盒活动图的分析，确定了以下三个关键系统功能： 管理传感器追踪信息 控制人机界面 执行历史管理图 6. UAV 管理系统 BDD考

10、虑到要使用一些关键系统功能，我们获得了如图 6 所示的 BDD。因为我们有子系统块，所以接下来的任务是在各个泳道中执行分配操作，以描绘每个独立的子系统块。以下是重要的分配规那么： 如果您无法将操作分配到单个块，那么必须将操作分解。在这种情况下，已分解的相关业务必须通过各自的依赖关系链接到父操作。 您可以将一个系统级的操作分配到多个块。在这种情况下，需要将相关的操作复制到相应的块泳道，并将它们集成到功能流中。图 7. 白盒活动图图 7. 白盒活动图图 7. 白盒活动图在图 7 中，与操作员交互相关的操作已包含在人机界面 (MMI) 控制器组件中。同样，与创立、更新和处理传感器追踪信息相关的操作被

11、分配到 Track Manager 泳道。而与历史数据管理有关的操作都推送到 History Manager 泳道。在将连续流拆分成两个块的地方，可以利用消息操作来表示从一个块到另一个块的转发请求。这种模式的一个例如是，从 History Manager 组件到 Track Manager 组件的消息操作 purgeSensorTrack()，该操作请求后一个组件执行 disposeSensorTrack()。现在，已将操作分配给泳道，下一步就是执行具体的架构设计。 具体的架构设计在进展具体的架构设计阶段，需要重点关注端口和接口的定义，以及实现子系统块基于状态的行为。为了做到这一点，必须使用白

12、盒序列图确定所子系统块的端口和接口。黑盒活动图的重点是确定不同的系统功能操作流，而白盒活动图的重点那么是不同子系统之间的协作，同时还要考虑到操作的分配。接收到服务请求定义一个块的接口。在定义了端口和接口后，必须将所产生的每个叶块基于状态的行为捕获到某个状态图中。代理白盒序列图如图 8 所示。序列图显示一个子系统块为了满足场景而向另一个子系统块请求的服务。图 8. 白盒序列图图 8. 白盒序列图图 8. 白盒序列图我们继续使用白盒序列图来获得子系统之间的端口和接口，并获得代理子系统组件基于状态的行为，如图 9、图 10 和图 11 所示。图 9. MMI 控制器状态图 10. 追踪信息管理器的状

13、态图图 11. 白盒端口和接口完毕语我们描述了如何通过案例研究来应用 Rational Harmony 系统工程流程。从系统工程切换到后续系统开发的关键构件是一个可执行基线模型。该模型是生成标准文档和操作 ICD 的资料库。切换包中包含以下工程： 可执行子系统模型的基线 子系统已分配的操作的定义 子系统端口和逻辑 接口的定义 子系统行为的定义，捕获在状态图中 测试场景，从系统级用例场景中获得参考资料 学习 查看本系列的第 2 局部：为分布式系统的分析和设计开发以数据为中心的流程 Systems Engineering Best Practices with the Rational Solut

14、ion for Systems and Software Engineering， Hans Peter Hoffman；工具书版本 访问 developerWorks 的 Rational 软件专区，获得 Rational Software Delivery Platform 产品的技术资源和最正确实践。 随时关注 developerWorks 技术活动和网络播送，包括各种 IBM 产品和 IT 行业主题。o 参加 developerWorksLive! 技术讲座，快速了解 IBM 产品和工具，以及 IT 行业趋势。o 观看 developerWorks 演示中心，其中包括面向初学者的产品安

15、装和设置演示，以及为经历丰富的开发人员准备的高级功能。 提高您的技能。查看 Rational 培训和认证 目录，其中包含了许多广泛议题的课程类型。您可以随时随地学习它们，许多 “入门 课程是免费的。获得产品和技术 下载 IBM WebSphere UDDI 注册中心预览版 FAQs 的 Rational 软件。 以最适合您的方式IBM 产品评估试用版软件：下载产品试用版，在线试用产品，在云环境下试用产品，或者在 IBM SOA 人员沙箱 中花费几个小时来学习如何高效实现面向服务架构。第 2 局部: 为分布式系统的分析和设计开发以数据为中心的流程分布式系统本身是面向数据的，它通过数据实体规定子系

16、统边界，并通过特定数据交互来定义系统的动态特性。数据实体及其在分布式环境中的行为是不 容无视的。因此，通过对 IBM Rational Harmony 系统工程流程等典型 MBSE 工作流中进展功能分析，可以推导出端口和接口数据交互和属性的来源，在这种情况下，这种结果似乎比较奇怪。在本文中，我们将探索如何开发适用于分布式 系统的分析和设计的 MBSE 流程。Mohit Choudhary, 系统工程师, RealTime TechSolutions2012 年 3 月 23 日 内容在本系列的第 1 局部中， 我们获得了 UAV 地面控制器的系统设计，我们使用 IBM Rational Har

17、mony 系统工程作为一个流程，指引我们了解子系统和逻辑接口。不过，分布式系统的设计往往以数据为中心，而数据实体在系统设计中又占据最重要的位置。因此，很显 然，我们只好稍微调整一下 Rational Harmony 系统工程流程，让设计流程把重点放在数据实体上，同时继续将 Rational Harmony 系统工程等成熟的 MBSE 流程的优势融入设计中。在分布式系统设计中，使用一个先进的接口语言来定义这些数据交互是有 必要的，这样做不仅可以在整个交互过程中确保各子系统的一致性，还可以捕获设置在语言本身中的数据的交互目的和行为。在不断变化的接口标准语言中，类似的 步骤是通过 OMG 数据分发服

18、务 (Data Distribution Service, DDS) 标准参阅参考资料实现。在派生的逻辑接口中的子系统之间弹出操作性 ICD界面控制文件时，标准的 Rational Harmony 系统工程流程完毕时的切换参阅参考资料已经足够用，但是，在利用数据分发服务 (DDS) 将这些逻辑接口映射到信息交换构造时，可能并不简单。在 本文中，我们将尝试调整标准的 Rational Harmony 系统工程流程的工作流，让它支持分布式不协调性，而不是支持 Rational Harmony。首先，我们将介绍 DDS 标准和 Problem-frame Analysis 的构造请参阅参考资料。然后

19、，我们遵循修改正的 MBSE 流程中所涉及的步骤，这些步骤及时采用了 DDS，并在整个分布式系统的分析和设计过程中表达它。最后，您应该能够通过使用与本文第 1 局部中一样的案例研究来运行这些步骤。了解 DDS 和问题框架分析OMG 数据分布服务 (Data Distribution Service, DDS) 标准被划分为两个架构层次。下层是以数据为中心的发布和订阅 (Data Centric Publish and Subscribe, DCPS) 层，其中包含了发布和订阅通信机制的类型安全的接口。上层是数据本地重构层 (Data Local Reconstruction Layer, DL

20、RL)，它使应用程序开发人员能够在 DCPS 层上构建本地对象模型，以屏蔽应用程序对 DCPS 的感知。本文的内容仅限于 DCPS 的一些特定构造。以数据为中心的发布和订阅DCPS 层将数据从发布者传播到感兴趣的订阅者。它的实现所使用的概念是，发布者 和数据编写器 和在发送端，而订阅者 和数据读取器 在接收端。DCPS 层由一个或多个数据域组成，其中每个域都包含通过 DDS 进展通信的发布者和订阅者。每对发布者和订阅者都附属于一个域。在所有数据域中，都是根据主题 来识别数据，主题是一个类型特定的域段，使发布者和订阅者能够明确地指定数据。在一个域中，每个主题都将惟一的主题名称、数据类型 和一组服

21、务质量 (QoS) 策略与数据相关联。每个主题都与一个数据类型相关联，但多个不同主题可以发布一样的数据类型。发布者的行为由与发布者、数据创立者和特定数据源的主题元素 关联的 QoS 策略决定。同样，订阅者的行为由与订阅者、数据读取器和特定数据接收器的主题元素关联的 QoS 策略决定。可以在语言中指定并在案例研究中使用的一些 QoS 策略和操作，如表 1 和表 2 所示。QoS 策略和操作如下所示。表 1. 记录相关的 DDS QoS 策略QoS描述Liveliness验证，确保系统中的预期实体仍然活着Reliability确定样本交付所需的可靠性水平。History如果实例的值在与订阅者通信之

22、前发生变化，那么控制对该实例的处理Lifespan防止将 “过时 的数据提供给应用程序。Deadline确定主题预计在期限内定期更新每个实例。表 2. 记录相关的 DDS 操作操作描述Read数据读取器对数据值集合的访问。Take从数据读取器删除一个样本，这样就不能对其执行读或获取操作。Wait set &Listener使应用程序了解 DCPS 通信状态的变化。Content filter基于属性筛选传入的主题样本。Data_Available状态变化标志，指示在读取器中的数据可用性。Read withcondition对符合在条件中所指定标准的样本具有 “读 访问权限。条件可以是只读条件或

23、查询条件。问题框架分析Problem Frames Approach问题框架方法是需求分析的方法。它使您能够将系统需求归类为一组预定义的问题，类似于解决方案范畴的设计模式。在将问题归类后，就可 以通过解答与每个问题框架相关的一套标准题目来轻松地解释这些问题。图 1 显示了本文如何使用该技术来记录案例研究的构件。图 1. 通过问题框架进展记录建议的工作流建议的处理工作流如图 2 所示。图 2. MBSE 流程的工作流在需求分析阶段已定义了系统级用例，该流程旨在通过问题框架分析如何为每个系统用例定义数据实体、属性和操作。您可以使用这些信息问题框架来开发模型实体及其属性、连接和转换问题框架，然后定义

24、这些实体的行为和工件问题框架，从而在已定义的实体上进展开发操作。接 下来，我们需要根据在问题框架分析阶段确定的实体来定义系统信息模型。通过分析所产生的构件是一个主题模型，它定义了已确定的 DDS 主题的名称、类型和 QoS。因为我们已有了主题模型，所以在下一阶段的实体功能分析中，将重点介绍如何围绕已确定主题模型实体的生命周期操作来执行功能分析。您可以使用黑盒 活动图来捕获每个已确定实体的生命周期并行流。此外，您必须通过组合一个或多个流来建设与序列图一致的真正功能流，从而生成黑盒用例场景。可以使用序列生 成用例块的端口和接口。然后捕获用例的基于状态的行为，验证所生成的序列图，并将它们与黑盒场景序

25、列图进展比较。设计合成从执行系统构造分解开场，其依据不仅是关键功能，还有模型实体本身。在下一步中，在描述白盒活动图的同时，还需要将 DDS-Data-space 作为其中一个子系统组件包含在内，以修补独立的功能流。先将 DDS-Data-space 定义为一个子系统组件，然后使白盒状态机作为一个可执行模型来运行，同时保存在使用 DDS 过程中所要求的时间和空间的别离。现在，通过比较我们在这里生成的序列图与白盒场景所产生的序列图，可以验证这个可执行模型。最后，您需要生成系统内部结 构框图 (IBD)，它将产生白盒端口和接口。毫不奇怪，在本例中的接口与信息模型中的主题是一一对应的，这些主题已经充分

26、定义了属性及其行为。问题框架分析该分析的范围由 Perform Area Search 用例定义，它检测飞行中的 UAV，将搜索区域分配给 UAV，从传感器获取追踪信息数据，并将该信息存储在信息模型中。所执行的分析如表 3 和表 4 所示。表 3. 信息和连接问题框架分析实体属性和描述UAVInfo：无人驾驶飞机。1. 真实世界：对飞行中的无人机的特点进展建模 a. 对象 i. UAVb. 在信息模型中，对象的事件和反响 i. 无法联系 UAV A. 在限期内没有提供 UAV 位置更新。B. 丧失的更新都将丧失。2. 属性 a. Identification i. Vehicle id飞机 i

27、d，由 UAV 发送ii. 没有其他身份属性，没有系统生成的 IDb. Time information时间信息 i. Update time更新时间 是时间和位置更新的信息ii. Available flight time可用飞行时间 是在飞行中剩余时间的信息c. UAVstateUAV 状态 i. Search assigned已分配的搜索ii. Search unassigned未分配的搜索d. Sensor information传感器信息 i. 可用传感器及其属性的清单e. Own vehicle data自己的飞机数据 i. Position data位置数据ii. Motion

28、data移动数据3. 数据 a. 没有更新历史。只有瞬时值。Sensor传感器：由 UAV 用于检测追踪信息。1. 传感器类型 a. SARb. FLIRc. OPTICAL2. 传感器属性 a. Sensor start time传感器启动时间 用于确定传感器是否活动。b. State状态 i. Active活动ii. Inactive不活动Sensor tracks传感器追踪信息：一组来自特定目标的测量值，可以使用它们来计算目标的位置和运动。追踪信息作为独立信息构造存在，除非在针对该追踪信息而给出的样本中没有提供追踪信息级别所需的其他数据。1. 真实世界：对传感器发出的传感器追踪信息进展建

29、模。 a. 对象 i. 由传感器检测到发射器/触点ii. 由传感器发送的测量值。有一个与测量值相关的周期。b. 在信息模型中，对象的事件和反响 i. 无法联系传感器 A. 在限期内无法提供追踪信息测量值。B. 丧失的追踪信息测量值都将丧失，从我们再次获得连接开场，传感器追踪信息继续发送测量值。ii. 传感器无法再获得追踪信息 - 在限期内无法提供追踪信息测量值。iii. 传感器重新获得追踪信息 - 追踪信息测量值再次可用。iv. 传感器无法获得追踪信息与无法联系传感器之间的区别 A. 传感器活动状态的可用性2. 属性 a. Identification身份 i. ID，由外部传感器发送 由以下

30、属性组成ii. Sensor ID传感器 IDiii. Track-ID追踪信息 ID，数字 1 至 50。iv. 没有其他身份属性，没有系统生成的 IDb. Time information时间信息- i. Created time创立时间 是来自传感器测量时间的信息，指追踪信息的第一次测量时间。ii. Track age追踪时间长度 - 是自上次测量值更新所经过的时间。c. Track state追踪状态- 取决于相关测量值的期限标志 i. Active活动ii. Lost丧失d. Source sensor源传感器 来自任何测量值的传感器 ID，通常根据第一个样本进展设置3. 数据 a.

31、 由一个或多个追踪信息测量值组成b. 存储超过 30 分钟窗口的测量值历史c. 去除早于该时间段的测量值4. 传感器特定的属性 a. 这些属性的 基本信息：几乎所有这些数据都直接从传入的传感器数据中取出，并用于向用户显示。4. Sensor Track Measures传感器追踪信息测量值1. 真实世界：对传感器发送的单一数据样本进展建模2. 属性 a. Identification身份 由传感器发送 i. Sensor ID传感器 IDii. Track ID追踪信息 ID 由传感器发送b. Measure ID测量值 ID- 序列号c. Time of the sample采样的时间 由传

32、感器发送，必须保存d. 有效或无效的数据好/坏/延迟 - 需要根据数据范围验证来转换，即基于传感器进展转换。系统会拒绝无效的测量值。e. Data数据 一个样本可以包含一个或多个以下属性： i. Position位置 Latitude纬度和 Longitude经度ii. Projection used使用的投影iii. Speed速度3. 特征 a. 传感器以 1 Hz 的频率发送 Track Measures追踪信息测量值表 4. 工件问题框架分析实体 分析 Static information静态信息1. 有否任何静态信息与传感器追踪信息相关 a. 传感器的特性 i. 来自传感器的表示错误

33、等信息的 RMS 值，一般是一个表，在系统中用于计算工件出问题时的 Sensor Tracks传感器追踪信息 1. 操作员驱动的操作 a. 创立 i. 从传感器测量值直接创立 A. 从上次测量值更新计算的 Track Age追踪时间长度B. 用于获取追踪信息 ID 的 First Measure首次测量b. 选择一个要转换为系统追踪信息的传感器追踪信息2. 生命周期相关的操作 a. 根据追踪信息新的可用更新测量值更新传感器追踪信息b. 自动去除在 30 分钟历史记录内没有任何测量值的传感器追踪信息。c. 归档 i. 无需求工件出问题时的 Sensor Track Measures传感器追踪信息

34、测量值 1. 操作员驱动的操作 a. 无 由传感器拥有2. 生命周期相关的操作 a. 显示错过期限的更新b. 自动去除超过 30 分钟历史的测量值。c. 归档 i. 无需求信息模型分析在这一步中，您需要使用前一阶段的信息和连接问题框架分析来执行信息模型分析。这一阶段的目标是，确定代表数据实体及其行为的 DDS 主题。所有这些主题共同构成 DDS 环境中的交互单元，其行为的正确表示可以大大减轻子系统在维护和通用管理方面的责任。案例研究的一个有代表性的信息模型子集如图 2 所示。在 为主题 “SensorTrackMeasure 定义的行为中，可以看到这种责任减少的例如。在这个主题上定义的键描述其

35、值构成键的数据字段列表是一种复合构造，由 SensorID 和 TrackID 组成。具有一样键值的不同数据值代表一样实例的连续值，而具有不同键值的不同数据值那么代表不同的实例。此外，主题的 HistoryQosPolicy 被定义为 KEEP_ALL，其深度为 1800，这表示在数据空间中为每个这样的实例最多保存 1800 个样本按照 1Hz 的频率更新 30 分钟时间。最后，持续时间对应为 30 分钟的 LifespanQosPolicy 指定数据样本在 DDS 空间的最长有效时间，这段时间过去后，系统会自动处理该样本。有关 SensorTrackMeasure 实体这种行为的定义，明确地

36、定义了 DDS 服务接收实体的历史管理责任。现在，在用例中对该功能进展建模会是重复操作。图 3. 主题模型表示主题名称描述主题定义QoS 策略QoS 理论值本主题将发布传感器追踪信息测量值信息struct idendityunsigned long ulsensorID ;unsigned long ultrackID;typedef unsigned long measure_ID;struct SensorTrackMeasureIdentity ulSourceID; / owner of meassagemeasure_ID ulSeq_no;unsigned long ullSyst

37、emTimemilliSecs; / current time in millisecondsfloat fLatitudeDeg; / latitudefloat fLongitude Deg; / Longitudedouble dXSpeedMtrs; / X coordinatedouble dYSpeedMtrs; / Y coordinate;#pragma keylist SensorTrackMeasure ulSourseIDDeadline 1 sec Destination order BY_SOURCE_TIMESTAMP Durability Volatile His

38、tory KEEP_ALL History depth 30 Lifespan 1800000ms Liveliness AUTOMATIC Latency budget 30ms Ownership SHARED ReliabilityBEST_EFFORT Resource limit Defaultmax_samples,max_instances,max_samples_per_instance (all set to LENGTH_UNLIMITED) Transport priority 1 Durability service Default 备注：图 2 中有代表性的主题模型描

39、述了与主题 “SensorTrackMeasure 相关的名称、类型和 QoS 策略。我们使用一个类似的练习在用例的其余局部中描述以下主题： UAVInfo SensorTrack SensorTrackMeasure Command这里需要重点注意的是，并非所有在问题框架分析阶段中确定的模型实体都与主题模型存在一一对应关系。实体功能分析实体功能分析阶段的输入是主题模型和工件问题框架分析模型。这个阶段的重点是围绕已确定主题的生命周期操作来执行功能分析。在此步骤中产生的构件是用例的黑盒活动图、场景和状态图。用例的黑盒活动图如图 4 所示，而有代表性的场景和状态图分别如图 5 和图 6 所示。黑

40、盒活动图表示基于 read、write、content_filter 或 read_with_query_condition 等 DDS 构造的操作。这些构造是简化功能流的一种途径。可以将这样的绑定带入活动流程，这被认为是通过使用 DDS 实现功能效率的必要条件。另一方面，可以创立黑盒场景，用它们代表现实世界的场景，将所产生的流的不同序列引入到代表该场景的主序列中。为了确保能够满足 需求分析阶段所了解的需求，这一步非常重要。反过来，这将有助于我们对详细主题及围绕这些主题的操作进展效能分析。如果出现不匹配的情况， 那么有必要回头修改信息模型，直到实现所需的现实世界功能序列。此外，获得用例的状态机

41、也很简单。用例的状态机由多个 AND 状态组成，每个 AND 状态分别代表活动图中的独立功能流的状态行为。虽然每个流都由一个 AND 状态表示，并因此可以独立执行，但这些流都通过从一个 AND 状态到其他等待子状态的事件流被捆绑在一起，以便支持作为一个整体状态机来执行。通过模型执行，参照之前生成的黑盒场景来验证自动生成的序列，这样做是有 必要的。图 4. 黑盒活动图面向数据图 5. 黑盒场景面向数据图 6. 黑盒状态图面向数据设计合成在这种方法中的系统构造分解不仅基于关键系统功能的识别，还基于已获得的主题模型。此外，白盒活动图的功能分配的执行通过将黑盒活动图的完整流独立分配到一个泳道来完成。这

42、种分配是可以实现的，因为通过 DDS 全球数据空间可以跨子系统边界访问所获得的主题实例和样本。为用例所生成的白盒活动图如图 7 所示。分配给代表 DDS 数据空间的泳道的功能，是通过发布/订阅模式将其余组件拼接在一起的功能。为了使子系统在模型级别共同参与现实世界的场景，并且使可执行白盒状态机生效， 这种表示方式被认为是必要的。该流程的下一步是开展用例的白盒场景，代表黑盒子场景的白盒视图。有代表性的白盒场景如图 8 所示。最后，我们从白盒场景推导出端口和接口，并实现子系统组件的白盒状态行为，以准备切换。有代表性的子系统的状态行为以及白盒端口和接口分别如图 9 和图 10 所示。本例中的子系统状态

43、图使用与相应黑盒状态图完全一样的模式。两者之间仅有的区别是从子系统等待状态过渡的触发事件，这些事件由组件 DDS-Data-space 产生。DDS-Data-space 的状态机是一种模拟表示形式，用于支持不同别离组件的执行。立即执行白盒状态机，以便比较生成的序列图与白盒场景，从而针对切换确定模型的基线。最后，明确映射到主题模型的子系统接口是根据确定基线的模型生成的，如表 5 所示。图 7. 白盒活动图面向数据图 8. 白盒序列图面向数据图 9. 白盒状态行为面向数据图 10. 白盒端口和接口面向数据表 5. 白盒接口列表块端口名称I/F 类型接口事件主题名称 / 描述MMIControll

44、erpOperatorProvidedreqSelectUAVOperator selection through h/w interruptreqAbortSearchOperator selection through h/w interruptreqSelectSearchAreaOperator selection through h/w interruptreqExecuteSearchOperator selection through h/w interruptpDDSDataSpace RequiredreqPublishCommandCommandTopicSensorTra

45、ckManager pDDSDataSpace ProvidedreqOnDataAvailableSensorTrackMeasureTopicRequiredreqPublishSensorTrackSensorTrackTopicUAVBridgepDDSDataSpaceProvidedreqOnDataAvailableCommandTopicRequiredreqPublishUAVInfoUAVInfoTopicreqPublishSensorTrackMeasureSensorTrackMeasureTopicpUAVProvidedreqRecieveUAVInfoUAVIn

46、fo message on UAV linkreqRecieveSensorTrackMeasureSensorTrack Measure msg on UAV linkRequiredevSendCommandCommand message on UAV linkDisplayControllerpDDSDataSpaceProvidedreqOnDataAvailableSensorTrackTopicreqOnDataAvailableUAVInfoTopicpDisplayRequiredevUpdateDisplayInterface on display linkDDSDataSp

47、acepMMIControllerProvidedreqPublishCommandCommandTopicpUAVBridgeProvidedreqPublishUAVInfoUAVInfoTopicreqPublishSensorTrackMeasureSensorTrackMeasureTopicRequiredreqOnDataAvailableCommandTopicpDisplayControllerRequiredreqOnDataAvailableSensorTrackTopicreqOnDataAvailableUAVInfoTopicpSensorTrackManagerP

48、rovidedreqPublishSensorTrackSensorTrackTopicRequiredreqOnDataAvailableSensorTrackMeasureTopic完毕语在把基于分布式组件的系统架构放在一起时，主要需要考虑的事项是，能够明确界定业务功能及其跨子系统的接口。如果系统遵循下面这些面向服务的架构的 Open Architecture 原那么请参阅参考资料，那么我们完全可以解决上述这些问题： 模块化：这意味着，架构已仔细划分业务和技术功能，使用户能够单独访问它们，并在状态之间保持最少量的交互需求。在分布式系统的设计中使用发布和订阅模式， 这从本质上促进了子系统设计

49、的无状态性质的使用。从本文的案例研究中，显然可以得出以下结论：每个独立的活动流应当代表组件的一个 AND 状态，而每个 AND 状态中惟一的主导状态是每个流的等待状态。行为主要是无状态的，因此，已定义实体的创立或更新本身就是通过写操作暴露给系统的其余局部，并且从不保存。这 样的设计自然地呈现模块化系统的属性，即在状态之间保持最少交互。 开放式标准：使用开放式标准对分布式系统的设计造成的最大影响最大是，这些标准必须在何处完成服务描述、发现和功能访问。SysML 是基于开放式标准的建模语言，所以也是 DDS 标准。SysML 是用于明确定义系统或子系统功能的语言。而 DDS 是用于明确定义子系统接

50、口的语言，它也在其自身中封装了发现和访问机制。 互操作性：在分布式系统中，互操作性依赖于定义良好的接口语法和语义。作为接口语言的 DDS 不仅清楚地暴露了接口功能，还明确暴露了数据模型的相关语义和行为。这防止了因为对解析采用了错误的上下文而造成数据的误解。因 此，我们考虑在 MBSE 流程中将两个驱动因素即 DDS 和 SysML结合在一起，这看起来似乎是成功的分布式系统分析和设计，该分析和设计严格采用了 Rational Harmony 系统工程等成熟流程定义的路径，而这些流程本身就以系统工程的最正确实践为根基。参考资料 学习 查看本系列的第 1 局部：IBM Rational Harmon

51、y 的集中式系统模型 访问 developerWorks 的 Rational 软件专区 获得 Rational Software Delivery Platform 产品的技术资源和最正确实践。 随时关注 developerWorks 技术活动和网络播送，包括各种 IBM 产品和 IT 行业主题。 o 参加 developerWorksLive! 技术讲座 ，快速了解IBM 产品和工具，以及 IT 行业趋势。o 观看 developerWorks 演示中心，包括面向初学者的产品安装和设置演示，以及为经历丰富的开发人员提供的高级功能。 提高您的技能。查看 Rational 培训和认证 目录，其

52、中包含了许多广泛议题的课程类型。您可以随时随地学习它们，许多 “入门 课程是免费的。 阅读 Data Distribution Service for Real-time Systems Version 1.2OMG Available Specification formal/07-01-01。 Systems Engineering Best Practices with the Rational Solution for Systems and Software Engineering， Hans Peter Hoffman；工具书版本 阅读 Michael Jackson 的 Prob

53、lem Frames: Analyzing & Structuring Software Development Problems 阅读 Open Architecture Technical Principals and Guidelines 1.5.8 Eric M. Nelson。获得产品和技术 下载 IBM WebSphere UDDI 注册中心预览版 FAQs 的 Rational 软件。 以最适合您的方式 IBM 产品评估试用版软件：下载产品试用版，在线试用产品，在云环境下试用产品，或者在 IBM SOA 人员沙箱 中花费几个小时来学习如何高效实现面向服务架构。讨论 参加 Rati

54、onal 软件论坛，提出问题并参与讨论。 评分或评论 Rational 软件。以这种方式进展评分和评估很快、很简单，真的。 通过 撰写一篇 developerWorks 文章，分享您的知识并帮助其他使用 Rational 软件的人。了解 好的 developerWorks 文章有何特点，以及如何写出好文章。 在 Facebook、Twitter (ibmrational) 和 YouTube 上关注 Rational 软件，并发表您的评论和请求。 参加 Rational 论坛、Rational cafs 和 wikis，提出问题并答复以下问题，提高您的专业知识。 获得思想领袖的社交网络。参加 Rational 社区，分享您的 Rational 软件专业知识，并获得与同行的联系。