基于模型的系统工程

基于模型的系统工程（MBSE）的案例研究第1部分:IBMRationalHarmony的集中式系统模型建模自出现以来，一直是系统工程的重要组成部分。在过去十年中，工程师们已经大幅增加基于模型的技术的使用，并发展出一门新的学科，基于模型的系统工程（Model-BasedSystemsEngineering,MBSE）。这门学科与传统的系统工程不同，它强调中央系统模型，该模型同时捕捉系统需求和满足这些需求的设计决策。除了作为系统工程的工作构件的知识库之外，还可以通过模拟系统模型来验证成本、性能研究和设计选择。IBMRationalHarmonyforSystemsEngineers等广泛应用的MBSE流程重点关注的是系统功能分析，也就是说，关注如何将功能要求转换为一致的系统操作描述。然后，使用系统操作获得所分配系统架构块之间的端口和接口。这些接口形成了各子系统之间的正式切换的基础。MohitChoudhary,系统工程师,RealTimeTechSolutions2012年3月23日内容本系列的这一部分旨在通过一个案例研究来探讨标准MBSE流程。首先，我们根据UAV（无人驾驶飞机）地面站控制器的设计来拟定这个案例研究的范围。然后，我们会介绍RationalHarmony系统工程流程的基本概念、工作流和工作产品。最后，我们通过定义任务流来实现UAV地面站控制器的设计，同时构造每个阶段所需的构件。案例研究本案例研究基于对少部分UAV地面站控制器的设计分析，这些控制器的功能必须符合表1中的要求。表1.UAV地面站控制器需求需求引用需求01实时飞行中的UAV的信息。（身份和传感器负载）02允许操作员将搜寻区域分配给选定的飞行中的UAV。需求引用需求03以1次更新/秒的频率接收来自UAV的传感器追踪信息。04在系统中保持30分钟的追踪历史。05允许操作员维护包含所采用的系统追踪信息的资料库。06最多维护100条SystemTracks（系统追踪信息）。07允许操作员对系统追踪信息执行生命周期操作（创建/删除）。08每秒更新一次系统追踪信息，如果主传感器追踪信息更新可用，则使用该值进行更新，否则，使用DR的值进行更新。09使系统追踪信息可在显示屏上显示，并绘制其更新。10允许操作员将操作员辅助系统追踪信息与另一台UAV的传感器追踪信息相关联。11允许操作员将两条独立的系统追踪信息合并成一条。12将系统中的重要事件（比如创建和删除系统追踪信息）通知操作员。13允许操作员随时中止UAV搜索。RationalHarmony系统工程中基于模型的系统工程RationalHarmonyforSystemsEngineering使您能够识别并推导出所需的系统功能，还能够确定相关的系统模式和状态。此外，您还可以将已确定的系统功能和状态分配给子系统结构，并确定跨子系统的端口和接口。图1显示了您在每个工程阶段为了完成系统设计而必须执行的基本输入和输出。图1.工程阶段的生命周期在功能分析阶段，通过一个活动图定义用例的功能流。然后，从活动图推导出用例场景。各场景通过一组序列图表示，创建用例块的端口和接口时需要用到它们。最后，用例基于状态的行为被捕获为一个状态图。在架构设计阶段，选定的系统块被分解成几部分。最终的系统结构被捕获在SysML块定义图(BDD)和SysML内部块图(IBD)中。每个用例分配都可以通过一个关联的白盒活动图以图形的形式表示。下图是用例的黑盒活动图的副本，但它被划分为泳道(swimlane)。每条泳道代表分解层次的一个块。然后，根据选定的设计理念，将操作“移动”到各自的块泳道。这种分配的一个基本要求是要求维护操作之间的初始链接（功能流）。最后，详细架构设计阶段的重点是端口和接口的定义，以及在架构分解的最低层，系统块基于状态的行为的定义。设计流程/大纲UAV地面站的系统要求被划分成两个用例，如图2所示。为了实现可追溯性，需要将已确定的系统要求与相关的用例相关联。在本文中，假设已经完成需求分析。对于本案例研究，我们将重点关注Uc1PerformAreaSearch用例。图2.UAV管理系统用例图功能分析用例的功能流涵盖的方面包括：将搜索分配给选定的UAV、接收来自UAV传感器的追踪信息、保持系统追踪信息与传感器追踪信息一致、维护所需要的传感器追踪信息更新历史、允许操作员中止搜索。您可以使用该工具在黑盒活动图中详细说明每个功能流，如图3所示。图3.黑盒活动图用例场景您可以看到，活动图中的每个流都表示一个不同的用例场景。这些流不仅能帮助我们详细了解功能流中的操作，还能形成在各个开发阶段验证用例行为的基础。在图4所示的五个场景中，您可以通过其中三个场景获得我们的用例。图4.黑盒用例场景用例状态图在下一步中，您可以使用序列图获得端口和接口。获得端口和接口之后，必须在状态图中捕捉用例的状态行为。最后，为了设定用例的黑盒行为的基线，需要执行状态机，并且将生成的序列图与刚才创建为场景的序列图进行对比。本用例的状态机如图5所示。图5.黑盒状态图状态“SearchExecuted”有两个‘and'子状态：“PerformSensorTrackManagement执行传感器追踪信息管理”和“PerformHistoryCheck”。第一个子状态支持追踪信息的建立或更新，第二个子状态清除大于30分钟的传感器追踪信息历史，如果传感器追踪信息没有历史记录，则清除传感器追踪信息本身。架构设计在架构设计阶段，您需要重点关注结构分解，以及如何将操作和行为分配给子系统组件。首先，我们描述了将系统结构性分解成子系统的系统BDD（参见图6），然后我们将获得UseCaseWhite-BoxActivityDiagram，并通过它将用例的操作分配给分解后的子系统（参见图7）。当将系统分解成子块后，它会以关键系统功能的定义为基础。这一阶段的目标是对系统功能进行分组，每个组可以通过一个子系统组件实现。第一步是将相关的系统功能划分为关键系统功能。对于本用例，我们通过用例黑盒活动图的分析，确定了以下三个关键系统功能：管理传感器追踪信息控制人机界面执行历史管理图6.UAV管理系统BDD考虑到要使用一些关键系统功能，我们获得了如图6所示的BDD。因为我们有子系统块，所以接下来的任务是在各个泳道中执行分配操作，以描绘每个独立的子系统块。以下是重要的分配规则：如果您无法将操作分配到单个块，那么必须将操作分解。在这种情况下，已分解的相关业务必须通过各自的依赖关系链接到父操作。您可以将一个系统级的操作分配到多个块。在这种情况下，需要将相关的操作复制到相应的块泳道，并将它们集成到功能流中。图7.白盒活动图图7.白盒活动图图7.白盒活动图在图7中，与操作员交互相关的操作已包含在人机界面(MMI)控制器组件中。同样，与创建、更新和处理传感器追踪信息相关的操作被分配到TrackManager泳道。而与历史数据管理有关的操作都推送到HistoryManager泳道。在将连续流拆分成两个块的地方，可以利用消息操作来表示从一个块到另一个块的转发请求。这种模式的一个示例是，从HistoryManager组件到TrackManager组件的消息操作purgeSensorTrack()，该操作请求后一个组件执行disposeSensorTrack()。现在，已将操作分配给泳道，下一步就是执行具体的架构设计。具体的架构设计在进行具体的架构设计阶段，需要重点关注端口和接口的定义，以及实现子系统块基于状态的行为。为了做到这一点，必须使用白盒序列图确定所子系统块的端口和接口。黑盒活动图的重点是确定不同的系统功能（操作）流，而白盒活动图的重点则是不同子系统之间的协作，同时还要考虑到操作的分配。接收到服务请求定义一个块的接口。在定义了端口和接口后，必须将所产生的每个叶块基于状态的行为捕获到某个状态图中。代理白盒序列图如图8所示。序列图显示一个子系统块为了满足场景而向另一个子系统块请求的服务。图8.白盒序列图图8.白盒序列图图8.白盒序列图我们继续使用白盒序列图来获得子系统之间的端口和接口，并获得代理子系统组件基于状态的行为，如图9、图10和图11所示。图9.MMI控制器状态图10.追踪信息管理器的状态图图11.白盒端口和接口结束语我们描述了如何通过案例研究来应用RationalHarmony系统工程流程。从系统工程切换到后续系统开发的关键构件是一个可执行基线模型。该模型是生成规范文档和操作ICD的资料库。切换包中包含下列项目：可执行子系统模型的基线子系统已分配的操作的定义子系统端口和逻辑接口的定义子系统行为的定义，捕获在状态图中测试场景，从系统级用例场景中获得参考资料学习查看本系列的第2部分：为分布式系统的分析和设计开发以数据为中心的流程SystemsEngineeringBestPracticeswiththeRationalSolutionforSystemsandSoftwareEngineering，作者：HansPeterHoffman；工具书版本访问developerWorks的Rational软件专区，获得RationalSoftwareDeliveryPlatform产品的技术资源和最佳实践。随时关注developerWorks技术活动和网络广播，包括各种IBM产品和IT行业主题。o参加developerWorksLive!技术讲座，快速了解IBM产品和工具，以及IT行业趋势。o观看developerWorks演示中心，其中包括面向初学者的产品安装和设置演示，以及为经验丰富的开发人员准备的高级功能。提高您的技能。查看Rational培训和认证目录，其中包含了许多广泛议题的课程类型。您可以随时随地学习它们，许多“入门”课程是免费的。获得产品和技术下载IBMWebSphereUDDI注册中心预览版FAQs的Rational软件。以最适合您的方式IBM产品评估试用版软件：下载产品试用版，在线试用产品，在云环境下试用产品，或者在IBMSOA人员沙箱中花费几个小时来学习如何高效实现面向服务架构。第2部分:为分布式系统的分析和设计开发以数据为中心的流程分布式系统本身是面向数据的，它通过数据实体规定子系统边界，并通过特定数据交互来定义系统的动态特性。数据实体及其在分布式环境中的行为是不容忽视的。因此，通过对IBM®Rational®Harmony系统工程流程等典型MBSE工作流中进行功能分析，可以推导出端口和接口（数据交互和属性）的来源，在这种情况下，这种结果似乎比较奇怪。在本文中，我们将探索如何开发适用于分布式系统的分析和设计的MBSE流程。MohitChoudhary,系统工程师,RealTimeTechSolutions2012年3月23日内容在本系列的第1部分中，我们获得了UAV地面控制器的系统设计，我们使用IBMRationalHarmony系统工程作为一个流程，指引我们了解子系统和逻辑接口。不过，分布式系统的设计往往以数据为中心，而数据实体在系统设计中又占据最重要的位置。因此，很显然，我们只好稍微调整一下RationalHarmony系统工程流程，让设计流程把重点放在数据实体上，同时继续将RationalHarmony系统工程等成熟的MBSE流程的优势融入设计中。在分布式系统设计中，使用一个先进的接口语言来定义这些数据交互是有必要的，这样做不仅可以在整个交互过程中确保各子系统的一致性，还可以捕获设置在语言本身中的数据的交互目的和行为。在不断变化的接口规范语言中，类似的步骤是通过OMG数据分发服务(DataDistributionService,DDS)规范（参阅参考资料）实现。在派生的逻辑接口中的子系统之间弹出操作性ICD（界面控制文件）时，标准的RationalHarmony系统工程流程结束时的切换（参阅参考资料）已经足够用，但是，在利用数据分发服务(DDS)将这些逻辑接口映射到信息交换结构时，可能并不简单。在本文中，我们将尝试调整标准的RationalHarmony系统