电磁轨道炮设计-基于模型的系统工程（20190819更新）

作者 Dirk Zwemer

原文链接： http://intercax.com/2018/07/19/mbse-for-railgun-design-part-1/

本文的目的是展示如何组合一些工具来协作设计一款新的武器系统——电磁轨道炮（electromagnetic railgun）。 使用的技术和工具有： SysML架构建模(MagicDraw或Rhapsody)、基于物理的分析(Mathematica和Simulink)、机械CAD (NX)和需求管理(Jama)。 这些工具由两个Intercax工具连接起来——MBSE平台Syndeia和参数解决方案ParaMagic (用于MagicDraw) 和Melody (用于Rhapsody)。

图 1 电磁轨道炮的简单物理原理

图1展示了电磁轨道炮最基本的形式。直流电脉冲的环路上包括两根导电的轨道和一个跨接在轨道上的可移动电枢。通过轨道的电流产生的磁场B和通过电枢的同一电流I交互产生了一个作用在电枢上的横向力F。如果电枢允许沿着轨道滑动，它就可以带着炮弹，把炮弹从轨道的一端发射向目标。

炮弹获得的出口速度(千米/秒)和动能(兆焦，MJ)可以达到或超过传统的大炮，而且没有传统爆炸推进物的成本和处置风险。 已经有实验系统报告出口速度>3千米/秒，动能>30MJ。

轨道炮领域建模

图2 轨道炮领域，MagicDraw画的块定义图

图2展示了轨道炮领域的组成，包括：

• Platform（平台）,容纳轨道炮的SoS（系统的系统）。可以是车辆、陆地或舰船。通过特化BattleTank（战斗坦克）、LandMount和Ship表示，包含的部件类型为ControlStation（控制站）、ProjectileStorage（弹仓）和AC_PowerSource（交流电源）(轨道炮的一个前提是大功率电源，特别是开火间隔很短时)。

• Railgun，SOI（感兴趣的系统）。 后面我们会建模SOI的内部结构。
• Users（用户），至少有轨道炮的Operator（操作员）和指挥使用的Platform Commander（平台指挥官）。 注意，Operator的用例主要和对目标开火相关，Platform Commander的用例和维持和保护平台的存活相关。

图3 序列图

我们可以使用SysML的行为建模能力来捕获操作场景。图3是描述开火操作的序列图，通过控制站、轨道炮和弹仓之间的一系列事务达到。领域的所有部件在图2描述。轨道炮的一个特征是需要很短时间（几毫秒）内的大电流(兆安)。大电流由储能装置提供，例如电容。用持续的电源给电容慢慢充电，在开火时快速放电。这个充电-开火周期必须在操作场景中描述。

图4 状态机，轨道炮

同样的周期由Railgun块的状态机图捕获如图4。在系统被关闭之前，进入Discharging（放电中）状态。注意图4是SOI的行为，而图3是整个领域的行为。不过，它们通过图3中Railgun生命线上的状态不变量符号链接起来，展示了操作场景不同阶段的轨道炮状态。

图5 轨道炮输入，内部块图，MagicDraw绘制

最后，我们需要考虑轨道炮需要的输入。用SysML IBD (内部块图)在非常抽象的级别概括如图5。Railgun需要从Platform获得:

• 电力 (本例为AC)

• 操作指令(参见图3消息)
• 导航信息
• 炮弹重装

图6 Jama需求和 SysML约束块。 红线表示 Syndeia引用连接

我们在Jama中创建和管理主需求列表，但是我们要把它链接到其他用来验证需求的系统设计和分析模型。有许多方法，我们选择构造SysML中的约束块，来为某些性能需求提供直接的数学测试，并且创建Syndeia引用连接到Jama中的需求(图6)。

例如，图6中的Jama需求"炮弹能量应大于或等于5MJ"，连接到SysML条件约束, "verdict = if(actual < 5, 0,1)"，该约束返回两种结果： 真实能量<5MJ时返回0或fail； 否则返回1或pass。 出口速度需求的测试稍微复杂一点，条件需要速率3千米/秒和质量=1千克。

Syndeia中的引用连接不在两个模型元素之间共享或复制数据。即使分享或复制，以参数约束和参数的术语解析文本需求的能力在SysML中也没有标准化。但是，当需求仓储处于版本管理之下时，例如在Jama或DOORS NG中，Syndeia可以跨越引用连接检测到新的版本，使得SysML建模人员发现变更，访问新版本并手工更新约束。

图7 轨道炮分解，SysML块定义图

得到需求之后，我们可以开始在SysML中建造轨道炮系统架构。图7中，我们分解轨道炮为电力、轨道和炮弹子系统。

电力子系统进一步分解为：
• AC_DC_Converter（交流直流转化器），转换持续的交流电为直流电。
• Capacitor（电容），存储能量，直到通过电源开关放电给轨道系统。
• Power_Switch（电源开关）。

这个阶段，RailSystem（轨道系统）只包含两条轨道和电枢。 我们为电枢使用引用属性，该属性是炮弹子系统的一部分。

建模连接性和几何学

块定义图（图7）展示RailGun系统的组合，相关的内部块图（图8）展示系统内部的连接性。 端口上规定了每个部件或子系统的输入和输出类型。 端口由连接器链接起来。 下文我们将会讨论到，这个模型可以作为MATLAB Simulink分析模型的模型变换的基础。

图8 RailGun内部连接，SysML内部块图

在设计流程，机械CAD将用于设计各个组件，包括关键的轨道。图9中，用NX设计了一个U型槽梁的3D CAD模型，它将作为轨道的代表。决定轨道炮性能的一个关键参数是轨道长度。 

图9 3D CAD 设计, 轨道炮轨梁 (Siemens NX)。 插入了SysML参数图，链接到model1，z轴1毫米相当于轨道长度1米

使用Syndeia，我们可以通过模型变换连接，从NX中的CAD模型创建包含关键CAD参数的SysML块，标为model1，放在图9的底部。该块包含一个值属性的集合，其缺省值来自CAD设计。这些值包括质量、体积、重心和Bounding Box的尺寸。如果设计变更，Syndeia允许从CAD文件更新SysML值。NX不允许反向更新，因为这些是计算得来的值，不能从外部覆写。

图9中，model1链接到Rail，但我们需要确切说明Rail中的length参数如何和model1的尺寸相连。 为此我们插入一个SysML参数图到图9，该图连接到右上角CAD部件边框的z尺寸。 参数约束也把单位转换结合到模型中，从CAD文件中的毫米到SysML和分析模型中的米。 设计时，轨道长度的变更自动转换到正确的单位。

轨道炮分析

整合架构、设计和分析的一个常见问题是保持来自三个领域的模型一致。 在开发过程中，如果持续变更，保持一致就比较麻烦。 有两个解决问题的基本方法。

· 内在的

我们可以把分析和仿真模型嵌入到架构模型中。 例如，SysML有参数模型元素，可以连接值属性和约束，有工具可以执行这些模型，并返回结果到SysML模型。

这个方法的优势是架构和分析紧密耦合在同一工具中，使得分析容易被系统工程师把握。不过，架构建模工具通常对于分析和仿真来说不是最理想的，分析专家对放弃他们熟悉的专业工具持反感态度。

· 外在的

另一个方法是模型变换，即用一部分架构模型来在仿真工具中创建全等的模型。分析师向这个初始模型添加可执行的仿真所需的公式和其他基础设施。因为架构和分析模型可以变更和分叉，这需要比较和更新模型的机制。

图10 分层的Railgun分析方案

图10表达了内在分析的方法。使用较低保真度的近似捕获为SysML参数模型。灰色块代表系统组件或子系统，绿色块持有分析的约束公式。系统组件块持有组件的静态特征值，例如质量或电阻。在这个模型中，轨道长度来自CAD模型，通过参数连接和单位换算展示在同一图中。分析块持有约束以及分析的最终或中间值，例如炮弹能量或初速度，并引用组件块以获得静态值。

图11 SysML参数图，Projectile Performance块

分析划分为三层，这样有利于开发、测试和复用。

· ProjectilePerformance中是电磁轨道炮的物理性质。 块内部是如图11的参数模型。 从一些值开始，例如轨道电流、电阻和炮弹质量，可以计算得到例如exitVelocity（出口速度）和projectileEnergy（炮弹能量）等结果。 这个阶段的方程式只是粗略估算，不过，在详细的轨道几何学和支持结构还没有开发出来的情况下，足够了。 记住，SysML的参数关系是随意的，输入值和输出值直到后面实例化时才会定义。

图12 SysML 参数图, ElectricalPerformance块

· ElectricalPerformance描述产生高直流电流的电源系统的电学特征，捕获如图12的参数图。 由ElectricalEnergy约束块计算得到的shotEnergy值大于projectileEnergy，因为轨道系统阻抗和电感会导致电损。 一个关键参数是rechargeTime，在两次开火之间电容重新充电的时间。

· ReqtsVerification里面是以上计算得到的炮弹能量、出口速度和重新充电时间的值，以及量化的如图6所示的需求测试，返回关于这三个需求的二进制Pass/Fail验证结果。

待续……

[UMLChinaSicilia 摘译，转载请注明出处。文章观点不代表UMLChina观点。]

---

主题: 软件需求设计UML全程实例剖析 开课时间: 2019年8月24-25日(周六、周日)（9:00-12:00，13:30-17:30） 上课地点: 北京 费用： 每人2400元，含午餐。交通、住宿费请自理。可以开增值税专用发票和增值税普通发票。 微信报名： 18758097122 QQ报名： 1493943028 Email报名： umlchinacourse@163.com 咨询电话： 18758097122 报名交费： 步骤一、报名 教室座位有限，需要先报名。请通过以上任何联系方式告知我们您的姓名和单位，以便我们预留座位。 步骤二、交费 按以下方法办理交费，将交费凭证（截屏或照片）、发票单位名称（如果要开）通过以上任何方式告知我们。我们收到费用后会给您发听课证，听课证是一个pdf文件，上有详细听课地点和您的座位号。听课证上有详细地址和座位细节。 不方便现场交费，因为需按交费顺序安排座位，而且现场只有老师，无人收款。 如果您交费后因故未能参加，您的名额和上课时间将会一直保留。 交费方法： （1）支付宝支付到talk@umlchina.com （2）微信支付到18758097122 （3）如果是公司财务汇，可以汇到负责UMLChina商务事宜的以下公司账号: 户名：杭州先思软件技术有限公司 帐号：3310 6594 0018 0100 29896 开户行：交通银行杭州滨江支行 课前准备： 请下载以下资料： （1）最新版本的本次课程训练幻灯 https://pan.baidu.com/s/1YVpxyOV7QTwMqh4F3bJjgw （2）建模软件EA30天试用版 http://www.sparxsystems.com/products/ea/trial/request.html （3）UMLChina模型模板 https://pan.baidu.com/s/1YVpxyOV7QTwMqh4F3bJjgw （4）（可选）《软件方法（上）》第2版，自行到书店购买，亚马逊Kindle版：https://www.amazon.cn/dp/B07DFR2313；勘误：http://www.umlchina.com/book/errata2ed.htm。 （5）《软件方法（下）》目前公开内容，请在http://www.umlchina.com/book/softmeth0809.pdf下载 （6）课上可以专门以学员的项目作为主要讨论项目。如果您希望在课上讨论您的项目，麻烦下载https://pan.baidu.com/s/1YVpxyOV7QTwMqh4F3bJjgw填好后发给我们，以便老师针对您的项目相关领域事先做准备。

[训练介绍] 软件开发中，需求是解决“产品怎样好卖”的问题，设计是解决“降低生产成本”的问题。二者相辅相成，缺一不可。而且，不能相互取代。要迈向“低成本制造好卖的产品”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践各种技能。 在这个强调“做减法”的时代，建模是正确帮助您“做减法”的绝佳工具。 本训练就是教授如何使用UML2.5相关的需求和设计技能来全程实例剖析一个系统的过程。 本训练对每个开发工作流，结合讲解、做练习巩固、应用到实际项目三种方式，展示使用UML2.5相关技能开发软件系统的全过程，解答实际应用中的疑难细节问题。 [学员要求] 有一年以上项目经验的需求或设计（编码）人员。不需要您有“UML基础”，只需要您有项目经验。欢迎学员携带自己的项目来听课，由专家在现场进行剖析。 [专家] UMLChina首席专家 潘加宇。在1999年还是一名程序员时，利用业余时间创建了UMLChina，潜心研究软件需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务，到现在为止，已经上门为超过290家的软件组织提供服务，覆盖了国内各个领域的领袖企业，包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制.....等领域。 [课程大纲] 1. 概论 --需求和设计的关键区别 --核心工作流 --UML的统一 --使用UML开发过程、工具、资料介绍 2. 愿景 --愿景的要点 --如何揣摩愿景 --项目实作：愿景  3. 业务建模 --组织的外观和内观 --选取合适的建模业务单元 --业务执行者和业务用例 --业务序列图 --改进业务序列图 --项目实作：绘制业务用例图、业务序列图  4. 需求 --系统执行者要点剖析 --系统用例要点剖析 --从业务序列图映射到系统用例图 --项目实作：绘制系统用例图  --书写用例规约 --项目实作：书写用例规约  --通过关系整理用例 --需求启发技术 5. 结构分析之类图 --抽象和封装 --识别类及其属性 --识别类之间的泛化 --识别类之间的关联 --项目实作：绘制类图  --彩色建模技术 --典型分析模式 6. 行为分析之序列图 --序列图精要 --用例、类图、序列图的互动 --专家原则和单一责任原则 --老板原则和聚合根 --可视原则 --项目实作：绘制序列图  7. 行为分析之状态图 --状态图、类图、序列图的映射 --状态 --事件、动作和转换 --层次状态、历史状态 --转换执行序列 --分层和细化 --状态图和代码的映射 --项目实作：绘制状态机图  8. 架构和设计 --存储层的映射 --数据源层的映射 --业务层的映射 --界面层的映射 --领域驱动设计 9. 改进指南 --根据团队情况改进 --小步前进 --正确的改进心态 以上时间分配会根据项目特点和训练进程调整。