基于模型的系统工程(MBSE)的案例研究,第 1..
IBM 日本語登录 (或注册)
技术主题软件下载社区技术讲座
基于模型的系统工程（MBSE）的案例研究，第 1 部分: IBMRational Harmony 的集中式系统模型
Mohit Choudhary, 系统工程师, RealTime TechSolutions
简介： 建模自出现以来，一直是系统工程的重要组成部分。在过去十年中，工程师们已经大幅增加基于模型的技术的使用，并发展出一门新的学科，基于模型的系统工程（Model-Based Systems Engineering, MBSE）。这门学科与传统的系统工程不同，它强调中央系统模型，该模型同时捕捉系统需求和满足这些需求的设计决策。除了作为系统工程的工作构件的知识库之外，还可以通过模拟系统模型来验证成本、性能研究和设计选择。IBM Rational Harmony for Systems Engineers 等广泛应用的 MBSE 流程重点关注的是系统功能分析，也就是说，关注如何将功能要求转换为一致的系统操作描述。然后，使用系统操作获得所分配系统架构块之间的端口和接口。这些接口形成了各子系统之间的正式切换的基础。
发布日期： 2012 年 3 月 23 日
级别： 初级
原创语言： 英文
访问情况 ： 1823 次浏览
评论： (查看 | 添加评论 - 登录)
平均分 (0个评分)
为本文评分
本系列的这一部分旨在通过一个案例研究来探讨标准 MBSE 流程。首先，我们根据 UAV（无人驾驶飞机）地面站控制器的设计来拟定这个案例研究的范围。然后，我们会介绍 Rational Harmony 系统工程流程的基本概念、工作流和工作产品。最后，我们通过定义任务流来实现 UAV 地面站控制器的设计，同时构造每个阶段所需的构件。
案例研究
本案例研究基于对少部分 UAV 地面站控制器的设计分析，这些控制器的功能必须符合表 1 中的要求。
表 1. UAV 地面站控制器需求
需求引用需求
01实时飞行中的 UAV 的信息。（身份和传感器负载）
02允许操作员将搜寻区域分配给选定的飞行中的 UAV。
03以 1 次更新/秒的频率接收来自 UAV 的传感器追踪信息。
04在系统中保持 30 分钟的追踪历史。
05允许操作员维护包含所采用的系统追踪信息的资料库。
06最多维护 100 条 System Tracks（系统追踪信息）。
07允许操作员对系统追踪信息执行生命周期操作（创建/删除）。
08每秒更新一次系统追踪信息，如果主传感器追踪信息更新可用，则使用该值进行更新，否则，使用 DR 的值进行更新。09使系统追踪信息可在显示屏上显示，并绘制其更新。
10允许操作员将操作员辅助系统追踪信息与另一台 UAV 的传感器追踪信息相关联。
11允许操作员将两条独立的系统追踪信息合并成一条。
12将系统中的重要事件（比如创建和删除系统追踪信息）通知操作员。
13允许操作员随时中止 UAV 搜索。
Rational Harmony 系统工程中基于模型的系统工程
Rational Harmony for Systems Engineering 使您能够识别并推导出所需的系统功能，还能够确定相关的系统模式和状态。此外，您还可以将已确定的系统功能和状态分配给子系统结构，并确定跨子系统的端口和接口。图 1 显示了您在每个工程阶段为了完成系统设计而必须执行的基本输入和输出。
图 1. 工程阶段的生命周期
在功能分析阶段，通过一个活动图定义用例的功能流。然后，从活动图推导出用例场景。各场景通过一组序列图表示，创建用例块的端口和接口时需要用到它们。最后，用例基于状态的行为被捕获为一个状态图。
在架构设计阶段，选定的系统块被分解成几部分。最终的系统结构被捕获在 SysML 块定义图 (BDD) 和 SysML 内部块图 (IBD)中。每个用例分配都可以通过一个关联的白盒活动图以图形的形式表示。下图是用例的黑盒活动图的副本，但它被划分为泳道
(swim lane)。每条泳道代表分解层次的一个块。然后，根据选定的设计理念，将操作 “移动” 到各自的块泳道。这种分配的一个基本要求是要求维护操作之间的初始链接（功能流）。最后，详细架构设计阶段的重点是端口和接口的定义，以及在架构分解的最低层，系统块基于状态的行为的定义。
设计流程/大纲
UAV 地面站的系统要求被划分成两个用例，如图 2 所示。为了实现可追溯性，需要将已确定的系统要求与相关的用例相关联。在本文中，假设已经完成需求分析。对于本案例研究，我们将重点关注 Uc1 PerformAreaSearch 用例。
图 2. UAV 管理系统用例图
功能分析
用例的功能流涵盖的方面包括：将搜索分配给选定的 UAV、接收来自 UAV 传感器的追踪信息、保持系统追踪信息与传感器追踪信息一致、维护所需要的传感器追踪信息更新历史、允许操作员中止搜索。您可以使用该工具在黑盒活动图中详细说明每个功能流，如图 3 所示。
图 3. 黑盒活动图
图 3 的大图
用例场景
您可以看到，活动图中的每个流都表示一个不同的用例场景。这些流不仅能帮助我们详细了解功能流中的操作，还能形成在各个开发阶段验证用例行为的基础。在图 4 所示的五个场景中，您可以通过其中三个场景获得我们的用例。
图 4. 黑盒用例场景
图 4 的大图
用例状态图
在下一步中，您可以使用序列图获得端口和接口。获得端口和接口之后，必须在状态图中捕捉用例的状态行为。最后，为了设定用例的黑盒行为的基线，需要执行状态机，并且将生成的序列图与刚才创建为场景的序列图进行对比。本用例的状态机如图 5 所示。
图 5. 黑盒状态图
图 5 的大图
状态 “Search Executed” 有两个 ‘and' 子状态：“Perform Sensor Track Management 执行传感器追踪信息管理” 和
“Perform History Check”。第一个子状态支持追踪信息的建立或更新，第二个子状态清除大于 30 分钟的传感器追踪信息历史，如果传感器追踪信息没有历史记录，则清除传感器追踪信息本身。
架构设计
在架构设计阶段，您需要重点关注结构分解，以及如何将操作和行为分配给子系统组件。首先，我们描述了将系统结构性分解成子系统的系统 BDD（参见图 6），然后我们将获得 Use Case White-Box Activity Diagram，并通过它将用例的操作分配给分解后的子系统（参见图 7）。
当将系统分解成子块后，它会以关键系统功能的定义为基础。这一阶段的目标是对系统功能进行分组，每个组可以通过一个子系统组件实现。第一步是将相关的系统功能划分为关键系统功能。对于本用例，我们通过用例黑盒活动图的分析，确定了以下三个关键系统功能：
管理传感器追踪信息
控制人机界面
执行历史管理
图 6. UAV 管理系统 BDD
考虑到要使用一些关键系统功能，我们获得了如图 6 所示的 BDD。因为我们有子系统块，所以接下来的任务是在各个泳道中执行分配操作，以描绘每个独立的子系统块。以下是重要的分配规则：
如果您无法将操作分配到单个块，那么必须将操作分解。在这种情况下，已分解的相关业务必须通过各自的依赖关系链接到父操作。
您可以将一个系统级的操作分配到多个块。在这种情况下，需要将相关的操作复制到相应的块泳道，并将它们集成到功能流中。
图 7. 白盒活动图
在图 7 中，与操作员交互相关的操作已包含在人机界面 (MMI) 控制器组件中。同样，与创建、更新和处理传感器追踪信息相关的操作被分配到 Track Manager 泳道。而与历史数据管理有关的操作都推送到 History Manager 泳道。在将连续流拆分成两个块的地方，可以利用消息操作来表示从一个块到另一个块的转发请求。这种模式的一个示例是，从 History Manager 组件到 TrackManager 组件的消息操作 purgeSensorTrack()，该操作请求后一个组件执行 disposeSensorTrack()。
现在，已将操作分配给泳道，下一步就是执行具体的架构设计。
具体的架构设计
在进行具体的架构设计阶段，需要重点关注端口和接口的定义，以及实现子系统块基于状态的行为。为了做到这一点，必须使用白盒序列图确定所子系统块的端口和接口。
黑盒活动图的重点是确定不同的系统功能（操作）流，而白盒活动图的重点则是不同子系统之间的协作，同时还要考虑到操作的分配。接收到服务请求定义一个块的接口。在定义了端口和接口后，必须将所产生的每个叶块基于状态的行为捕获到某个状态图中。代理白盒序列图如图 8 所示。序列图显示一个子系统块为了满足场景而向另一个子系统块请求的服务。
图 8. 白盒序列图
图 8 的大图
我们继续使用白盒序列图来获得子系统之间的端口和接口，并获得代理子系统组件基于状态的行为，如图 9、图 10 和图 11 所示。
图 9. MMI 控制器状态
图 9 的大图
图 10. 追踪信息管理器的状态图
图 10 的大图
图 11. 白盒端口和接口
加入 Rational 软件论坛，提出问题并参与讨论。
评分或评论 Rational 软件。以这种方式进行评分或评论很简单。
通过 撰写一篇 developerWorks 文章，分享您的知识并帮助其他使用 Rational 软件的人。了解 好的 developerWorks 文章有何特点，以及如何写出好文章。
在 Facebook 、Twitter (@ibmrational) 和 YouTube 上关注 Rational 软件，并发表您的评论和请求。
加入 Rational 论坛、Rational cafés 和 wikis ，提出问题并回答问题，提高您的专业知识。
获得思想领袖的社交网络。加入 Rational 社区，分享您的 Rational 软件专业知识，并获得与同行的联系。
关于作者
Mohit Choudhary 是一位基于模型的解决方案的架构师，他在使用先进技术构建软件密集型系统方面具有丰富经验。在捕获、设计、开发和维护软件密集型海军作战系统的需求方面，他拥有超过 12 年的工作经验。
关闭 [x]
developerWorks：登录
IBM ID：
需要一个 IBM ID？
忘记 IBM ID？
密码：
忘记密码？
更改您的密码
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 使用条款
提交 取消
当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。
所有提交的信息确保安全。
关闭 [x]
请选择您的昵称：
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。
昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
昵称：（长度在 3 至 31 个字符之间）
单击提交则表示您同意developerWorks 的条款和条件。 使用条款.
提交 取消
所有提交的信息确保安全。
平均分 (0个评分)
1 星1 星
2 星
3 星
4 星
5 星
提交2 星3 星4 星5 星
添加评论:
请 登录 或 注册 后发表评论。
注意：评论中不支持 HTML 语法
有新评论时提醒我剩余 1000 字符
发布
快来添加第一条评论
打印此页面分享此页面关注 developerWorks帮助
联系编辑
提交内容
网站导航订阅源在线浏览每周时事通讯报告滥用使用条款第三方提示隐私条约
浏览辅助IBM 教育学院教育培养计划IBM 创业企业全球扶持计划ISV 资源 (英语)