基于模型的系统工程MBSE的案例研究.docVIP

在本系列的第 1 部分中，我们获得了 UAV 地面控制器的系统设计，我们使用 IBM Rational Harmony 系统工程作为一个流程，指引我们了解子系统和逻辑接口。不过，分布式系统的设计往往以数据为中心，而数据实体在系统设计中又占据最重要的位置。因此，很显然，我们只好稍微调整一下 Rational Harmony 系统工程流程，让设计流程把重点放在数据实体上，同时继续将 Rational Harmony 系统工程等成熟的 MBSE 流程的优势融入设计中。 在分布式系统设计中，使用一个先进的接口语言来定义这些数据交互是有必要的，这样做不仅可以在整个交互过程中确保各子系统的一致性，还可以捕获设置在语言本身中的数据的交互目的和行为。在不断变化的接口规范语言中，类似的步骤是通过 OMG 数据分发服务 (Data Distribution Service, DDS) 规范（参阅参考资料）实现。在派生的逻辑接口中的子系统之间弹出操作性 ICD（界面控制文件）时，标准的 Rational Harmony 系统工程流程结束时的切换（参阅参考资料）已经足够用，但是，在利用数据分发服务 (DDS) 将这些逻辑接口映射到信息交换结构时，可能并不简单。 在本文中，我们将尝试调整标准的 Rational Harmony 系统工程流程的工作流，让它支持分布式不协调性，而不是支持 Rational Harmony。首先，我们将介绍 DDS 规范和 Problem-frame Analysis 的结构（请参阅参考资料）。然后，我们遵循修改过的 MBSE 流程中所涉及的步骤，这些步骤及时采用了 DDS，并在整个分布式系统的分析和设计过程中体现它。最后，您应该能够通过使用与本文第 1 部分中相同的案例研究来运行这些步骤。 了解 DDS 和问题框架分析 OMG 数据分布服务 (Data Distribution Service, DDS) 规范被划分为两个架构层次。下层是以数据为中心的发布和订阅 (Data Centric Publish and Subscribe, DCPS) 层，其中包含了发布和订阅通信机制的类型安全的接口。上层是数据本地重构层 (Data Local Reconstruction Layer, DLRL)，它使应用程序开发人员能够在 DCPS 层上构建本地对象模型，以屏蔽应用程序对 DCPS 的感知。本文的内容仅限于 DCPS 的一些特定结构。 回页首 以数据为中心的发布和订阅 DCPS 层将数据从发布者传播到感兴趣的订阅者。它的实现所使用的概念是，发布者?和数据编写器?和在发送端，而订阅者?和数据读取器?在接收端。DCPS 层由一个或多个数据域组成，其中每个域都包含通过 DDS 进行通信的发布者和订阅者。每对发布者和订阅者都从属于一个域。在所有数据域中，都是根据主题?来识别数据，主题是一个类型特定的域段，使发布者和订阅者能够明确地指定数据。 在一个域中，每个主题都将惟一的主题名称、数据类型?和一组服务质量?(QoS) 策略与数据相关联。每个主题都与一个数据类型相关联，但多个不同主题可以发布相同的数据类型。发布者的行为由与发布者、数据创建者和特定数据源的主题元素关联的 QoS 策略决定。同样，订阅者的行为由与订阅者、数据读取器和特定数据接收器的主题元素关联的 QoS 策略决定。可以在语言中指定并在案例研究中使用的一些 QoS 策略和操作，如表 1 和表 2 所示。QoS 策略和操作如下所示。 表 1. 记录相关的 DDS QoS 策略 QoS 描述 Liveliness 验证，确保系统中的预期实体仍然活着 Reliability 确定样本交付所需的可靠性水平。 History 如果实例的值在与订阅者通信之前发生变化，则控制对该实例的处理 Lifespan 避免将 “过时” 的数据提供给应用程序。 Deadline 确定主题预计在期限内定期更新每个实例。 表 2. 记录相关的 DDS 操作 操作 描述 Read 数据读取器对数据值集合的访问。 Take 从数据读取器删除一个样本，这样就不能对其执行读或获取操作。 Wait set Listener 使应用程序了解 DCPS 通信状态的变化。 Content filter 基于属性筛选传入的主题样本。 Data_Available 状态变化标志，指示在读取器中的数据可用性。 Read withcondition 对符合在条件中所指定标准的样本具有 “读” 访问权限。条件可以是只读条件或查询条件。 回页首 问题框架分析 Problem Frames Approach（问题框架方法）是需求分析的方法。它使您能够将系统需求归类为一组预定义的问题，类似于解决方案范