求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
目录
第一部分:SEBoK介绍
SEBoK 简介
系统工程导论
SEBoK 用户和用途
第二部分:系统工程基础
系统基础
系统方法在工程系统中的应用
系统科学
系统思维
用模型表示系统
第三部分:系统工程与管理
系统工程 STEM 概述
基于模型的系统工程 (MBSE)
生命周期过程简介
生命周期模型
概念定义
系统定义
系统实现
系统实施
系统集成
系统验证-1
系统验证-2
系统部署和使用
系统部署
系统操作
系统维护
Logistics
系统工程管理
技术规划
评估和控制
决策管理
风险管理
配置管理
信息管理
质量管理
度量管理
业务和任务分析
业务和任务分析
系统工程标准
相关标准
系统工程标准的应用
系统工程标准的校准与比较
服务的生命周期管理
第四部分:系统工程的应用
产品系统工程
服务系统工程
企业系统工程
Systems_of_Systems(SOS)
医疗系统工程
第五部分:启用系统工程
支持业务和企业执行系统工程
支持团队执行系统工程
支持个人执行系统工程
第六部分:系统工程相关领域
系统工程和环境工程
系统工程和工业工程
系统工程与地理空间/大地测量工程
系统工程和项目管理
系统工程和软件工程
系统工程与质量属性
第七部分:系统工程实施实例
系统工程实施示例:信息系统
系统工程实施示例:防御系统
系统工程实施示例:交通系统
系统工程实施示例:医疗系统
系统工程实施示例:空间系统
系统工程实施示例:管理系统
系统工程实施 : 矩阵示例
第八部分:新兴的知识
新兴的主题
 
 
目录
系统工程实施示例:防御系统
译者:火龙果Alice
856 次浏览
8次  

潜艇战联合战术系统

本文描述了生成美国海军(USN)潜艇舰队通用作战系统的系统工程和集成计划从传统的基于文档的系统工程(DBSE)到基于模型的系统工程(MBSE)的转换。这个主题可能对那些在其生命周期的维持和演化阶段处理程序的人特别感兴趣。有关其他信息,请参阅下文第五节:经验教训中提供的链接。

背景

现代潜艇通常服役20 - 40年。潜艇和它们的内部系统在发射时通常是最先进的,但是大多数海军发现有必要在操作寿命期内至少一次升级舰艇的战斗系统。威胁、技术和互操作性的发展推动USN不断升级其潜艇作战系统和关键部件,包括声纳(Fages 1998) (Ford and Dillard 2009)和战术控制系统(Jacobus and Barrett 2002)。

在过去的三十年中,潜艇作战系统已经从具有手动或点对点接口的多个独立系统(声纳、战斗控制、成像、电子战、武器控制等)演变为网络化的系统联盟(FoS)。令人困惑的是,这些组成系统在文献中经常被称为子系统。通常情况下,每艘新级潜艇都配备了新的作战系统,以及该级潜艇特有的相应后勤和维持尾部。

图1。1985年时代潜艇作战系统由点对点接口的独立组件系统组成的SysML块定义图(SEBoK Original)

在USN中,每个组件系统都有自己的采运程序、客户和承包商团队。这些系统从传统军事独有的计算平台上托管的遗留军事系统开始,已经发展到利用商业现货(COTS)计算和网络平台,并利用大量的COTS软件。

随着组件系统变得更加紧密地联系在一起,收购客户建立并合作资助了一个系统工程和集成(SE&I)计划,以管理系统之间的接口,管理技术插入和通用COTS硬件的过时,并集成和测试生产系统(Cooper, Sienkiewicz和Oliver, 2006年)。从弗吉尼亚级开始,这个SE&I计划扩展到包括新生产和现役潜艇现代化工作。随着时间的推移,各种潜艇级别的作战系统被聚合成单一产品线的变种(Zingarelli et al. 2010)。此外,独立的系统到系统的接口被合理化,在实践中变成多个系统之间共享的公共接口。

目的

潜艇作战系统SE&I计划每年提供更新的生产基线,以及每年建造或升级的每个潜艇级或子类的产品线变体。执行这一基准的生产系统将交付给新建潜艇,并以大约6年的周期对现役潜艇进行升级。通用作战系统产品线称为潜艇作战联合战术系统(SWFTS)。SWFTS被美国海军部署在洛杉矶(SSN 688)、俄亥俄(SSGN 726、SSBN 730)、海狼(SSN 21)和弗吉尼亚(SSN 774)级潜艇上,并被澳大利亚皇家海军部署在柯林斯(SSG 73)级潜艇上。SWFTS也计划用于下一代USN哥伦比亚(SSBN)和RAN未来潜艇级。与它所取代的潜艇作战系统相比,SWFTS显著降低了研制、维护和训练成本,同时提供了增强的作战能力,并促进了新能力或改进能力的快速插入(Zingarelli等,2010)。

图2。当代潜艇作战系统通过融合数据接口进行联网(洛克希德·马丁公司为美国海军生产)。2016年6月,美国海军批准公开发布,#16-348)

在USN中,每个组件系统都有自己的采运程序、客户和承包商团队。这些系统从传统军事独有的计算平台上托管的遗留军事系统开始,已经发展到利用商业现货(COTS)计算和网络平台,并利用大量的COTS软件。

挑战

美国海军潜艇舰队包含了级、亚级之间的实质性平台可变性,甚至是一个亚级中的单个舰艇。RAN Collins类提供了额外的可变性。平台的可变性导致作战系统的可变性。

SWFTS是一个系统联盟(FoS),每个平台托管20个不同项目办公室生产的40个系统子集。与系统的系统(SoS)和FoS一样,没有一个中心项目办公室可以指挥所有组件系统程序的合规性。相反,SWFTS的演变是通过谈判和共识来执行的。

每年必须制定许多基准;新的通用硬件基线在奇数年引入,而新的通用软件基线在偶数年引入(Jacobus, Yan和Barrett 2002)。此外,每年都要建立多个增量发展基线。一旦确定了生产线的年度生产基线,必须为当年建造或升级的每个潜艇级或子类开发改型(Mitchell 2012)。

与大多数其他国防项目一样,SWFTS SE&I项目面临着不断减少的资源完成更多任务的压力。尽管预算减少,但SE的范围一直在稳步增加。项目领导通过持续的SE流程改进做出了部分回应。改进包括测试自动化,需求管理过程和工具的变更(从电子表格到IBM®Rational®DOORS®到OMG®SysML®),改进的变更管理工具,以及DBSE到MBSE的转换,这是本案例研究的重点。通过每个主要的SE过程或工具改进,实现了大量的投资回报(ROI) (Mitchell 2014)。

系统工程实践

概述

在2009年期间,SWFTS SE&I项目进行了一项模型驱动架构(MDA)研究,以确定MDA是否应该成为该项目持续的SE过程改进的下一步。MDA研究预测转换为MBSE的投资回报率(ROI)为正。2010年1月,西南财经大学工商管理学院SE&I项目办公室启动了一项为期三年的工作,以开发和验证西南财经大学工商管理学院的FoS模型和MBSE流程。2013年,同时使用DBSE和MBSE开发了SWFTS基线。用DBSE产品对MBSE产品进行验证。在成功验证的基础上,SWFTS的SE&I项目将所有正在进行的工作过渡到MBSE。

直到2013年的过渡,SWFTS SE使用传统的DBSE。需求在DOORS中进行管理,工程师以数百列数千行的大型电子表格的形式进行评审和使用。每个变体的设计都被记录在Microsoft Office文件中。基线变更请求(BCR)记录在简报中,并由所有组件系统程序并行分析潜在影响。已批准的bcr被手工合并到DOORS和每个受影响的变体的修订基线文件中。

从2010年开始,客户社区投资了一个为期三年的MBSE转型工作。工程团队进行了深入的工具交易研究,以选择和建立MBSE环境。该交易研究导致选择MagicDraw™进行系统建模,使用Teamwork™作为模型存储库。

一旦安装了建模环境,MBSE转换团队就会构建、开发并填充SWFTS FoS接口的基于sysml的模型。该团队更新了SWFTS SE流程,以利用新的MBSE环境,约束MBSE流程生产的SE产品与DBSE流程生产的产品有效相同。

2013年,新的MBSE环境和流程被用于生产一套SWFTS基线SE产品。与此同时,DBSE工艺生产了同等的产品。对两组基线产品进行了详细比较,所有差异都可以追溯到根本原因。

该分析确定了大量的微小差异,这些差异都可以追溯到DBSE产品中的错误。这验证了MBSE工艺,并表明尽管初始MBSE基线产品比DBSE基线产品更劳动密集型,但新的MBSE工艺生产出更高质量的产品。经过验证后,SWFTS的SE&I程序转换为MBSE作为其基本流程。

自那次转型以来,SE流程改进一直在快速进行。需求管理已经从DOORS转移到MagicDraw中的系统模型。截至2016年,系统模型是需求、架构和FoS设计的基线。现在在模型中执行BCR影响分析,利用工具集的功能进行自动化辅助。变量作为系统配置在系统模型中记录。大多数SE产品都是按需生成的系统模型。

虽然MBSE最初的范围仅限于管理组件系统之间的接口,但一旦过渡成功,MBSE开始扩展,包括额外的SWFTS SE&I任务。MBSE现在开始扩展到组件系统项目以及整个潜艇作战系统SE&I项目。

经验教训

七个学习原则(LPs) (Friedman and Sage 2005)是针对系统工程知识的更广泛的应用领域提出的,并告知与案例研究最密切相关的SEBoK领域。它们是:

  • 需求可追溯性(LP1);
  • 通讯(LP2);
  • 生产力(LP3);
  • 质量 (LP4);
  • 管理变革(LP5);
  • 管理变体(LP6);
  • 生命周期 (LP7)

需求可追溯性 LP1:MBSE 提高了多个维度的可追溯性,但维护传统数据库和 MBSE 系统模型之间的需求可追溯性可能具有挑战性。 虽然 DOORS、MagicDraw 和 Teamwork 可以互操作以提供需求管理和可追溯性,但这种组合是脆弱的。 如果没有仔细的配置管理,同步可能会导致数据库损坏。 如果 DOORS 和 Teamwork 位于不同的服务器上,则维护连接可能会与不断发展的公司信息保障 (IA) 策略相冲突。

可以使用系统模型中的 SysML 语言非常有效地管理需求。 这种方法可以减少使系统模型与传统需求数据库系统保持同步所需的资源,并提高整体 SE 生产力。

通信 LP2:从系统模型生成的定制 SE 产品可以显着增强技术团队内部和客户利益相关者之间的通信。 系统模型的图形描述通常比大量的电子表格和文本文档更好地传达给人类利益相关者。 此外,由建模驱动的更高精确度可以减少技术和程序利益相关者之间的错误沟通。

在系统模型中拥有架构和设计,可以负担得起根据特定通信需求生成专门的 SE 产品,同时保持所有 SE 产品的一致性。 即使是认为他们理解设计的技术利益相关者也可以通过以不同的表示形式查看它来找到新的见解。

生产力 LP3:MBSE 通过增强团队内部的沟通、日常任务的自动化和成本规避来提高生产力。 DBSE 中使用的流程通常需要大量修改才能实现 MBSE 的潜在生产力增益。 特别是,必须修改审查流程以利用工具。

所选的建模工具限制了您如何实际地重新设计 SE 流程。 自动化可以取代大量的常规 SE 工作(文档生成、识别变更的潜在影响等)。

开发强大的建模风格指南和专业表示,以及在新团队成员加入该计划时向他们灌输的培训材料,是值得投资的。 MBSE 确实需要训练有素的建模人员,但并非所有系统工程师都必须成为熟练的建模人员。

为了有效量化 MBSE 的好处,程序需要仔细计划指标收集,然后坚持计划足够长的时间来收集有意义的数据。

质量 LP4:MBSE 过渡带来的大部分投资回报率都可以提高。 提高 SE 产品的质量可以减少交付给客户的系统中的潜在缺陷,从而降低维护成本并提高客户满意度。

与文档相比,模型对不精确性的容忍度更低。 提高的精度提高了 SE 产品质量,减少了缺陷产生和减少了缺陷逃逸。 产品生成的自动化可以使专门的 SE 产品价格实惠,进一步提高系统质量。

管理变更 LP5:如何理解和执行提议的系统变更在以模型为中心和以文档为中心的方法之间有着根本的不同。 在以文档为中心的方法中,重点是“我的最终输出应该是什么样的?” 在基于模型的方法中,重点是“这种变化对系统意味着什么? 系统的哪些其他部分会受到这种变化的影响?”

变更管理很难。 从 DBSE 迁移到 MBSE 时,必须预先仔细考虑该方法,并且必须设计系统模型以促进该方法。 变更管理也会影响工具的选择,因为不同的工具可以更好地适应不同的方法。

管理变 体 LP6:在 DBSE 中管理变体的最常见过程是“克隆和拥有”,其中每个新产品系列成员采用当时的基线并“分叉”基线以进行变体的演变。 这使得在整个产品系列中同步对核心基线的更改成为一个非常劳动密集型的过程。 将变体视为与模型中核心基线的偏差可大大降低管理产品系列中的变体的成本。

变体管理很困难。 必须预先考虑计划的方法,并且必须设计系统模型以适应它。 选择的方法会影响工具的选择和剪裁。

设计系统模型以将变体视为与核心基线的偏差。 然后,对核心基线的更改会自动在所有变体之间共享,并且对产品系列成员的影响仅限于核心基线更改对特定变体偏差的任何影响。 这也促进了变体之间的共性,这是一个关键的客户目标,因为共性降低了物流和培训成本。

生命周期 LP7:MBSE 可以在产品系列生命周期的早期或晚期应用。 虽然大多数使用 MBSE 的项目开始时都是基于模型的,但程序可以在生命周期的后期过渡到 MBSE。

从 DBSE 到 MBSE 需要认真的工程、仔细的思考、计划和实施。 SWFTS MBSE 过渡需要客户三年的投资。 这些时间和预算主要用于设计和开发系统模型以及重新设计 SE 流程。

以仔细定义的范围开始过渡。 一旦完成,MBSE 的范围就可以从那里扩展。

弗吉尼亚级潜艇

这个示例是直接为SEBoK开发的SE示例。它描述了弗吉尼亚级潜艇声纳系统项目。它特别强调了声纳系统体系结构的开发方法,以及它如何有助于商业现货产品的集成。

在弗吉尼亚级潜艇之前,声纳系统由专有组件和接口组成。然而,在20世纪90年代中期,美国政府转向使用商业开发产品——或商业现货(COTS)产品——作为一种节约成本的措施,以降低与自主研发相关的不断上升的成本。弗吉尼亚级潜艇系统设计代表了向基于cots的部件的过渡,并引发了声纳界采用的建筑方法的全球变化。该项目的领导舰“弗吉尼亚”号通过标准化,将核潜艇的历史采购部件数量减少了60%。与以往的声纳系统相比,弗吉尼亚级潜艇声纳系统体系结构提高了模块化、通用性、标准化、可靠性、可维护性和可测试性(RMT)。

建筑方法:标准化

基于新的 架构方法 和过渡的成功,系统架构专家开发了一组初始架构评估指标:

  • 共性
    • 物理共性(系统内)
      • 硬件 (HW) 通用性(例如,独特的线路可更换单元、紧固件、电缆和实施的独特标准的数量)
      • 软件 (SW) 通用性(例如,实现的独特 SW 包的数量、语言、编译器、平均 SW 实例化和实现的独特标准)
    • 身体熟悉度(与其他系统)
      • 已知供应商和分包商的百分比
      • 已知的硬件和软件技术百分比
    • 操作共性
      • 自动化操作功能的百分比
      • 所需的独特技能代码数量
      • 估计的操作培训时间(例如,从以前的系统开始和更新)
      • 估计的维护培训时间(例如,从以前的系统开始和更新)
  • 模块化
    • 物理模块化(例如,易于系统元素或操作系统升级)
    • 功能模块化(例如,易于添加新功能或升级现有功能)
    • 正交性
      • 跨多个处理元素和接口的功能需求被分割到的级别
      • 吞吐量要求跨接口的级别
      • 确定通用规范的级别
    • 抽象(即系统架构提供信息隐藏选项的级别)
    • 接口
      • 每个系统元素的唯一接口数量
      • 不同网络协议的数量
      • 显式接口与隐式接口
      • 架构包含隐式接口的级别
      • 系统中的电缆数量
  • 基于标准的开放性
    • 接口标准
      • 接口标准数与接口数之比
      • 基于标准的产品供应商数量
      • 应用/使用该标准的业务领域数量(例如,航空航天、医疗和电信)
      • 标准期限
    • 硬件标准
      • 外形尺寸与线路可更换单元 (LRU) 数量的比率
      • 基于标准的产品供应商数量
      • 标准期限
    • 软件标准
      • 专有和独特操作系统的数量
      • 非标准数据库数量
      • 专有中间件数量
      • 非标准语言数量
    • 一致性导向
      • 实施诊断和性能监视器/故障定位 (PM/FL) 的通用指南
      • 实现人机界面 (HMI) 的通用指南
  • 可靠性、可维护性和可测试性
    • 可靠性(容错)
    • 脆弱性的关键点(例如,系统负载占处理器、内存和网络负载的百分比)
    • 可维护性(例如,预期平均修复时间 (MTTR)、最大故障组大小、系统在维护期间是否可以运行)
    • 可访问性(例如,空间限制、特殊工具要求、特殊技能要求)
    • 可测试性
      • 内置测试 (BI​​T) 覆盖的 LRU 数量(BIT 覆盖率)
      • 错误的再现性
      • 记录/记录能力
      • 系统故障时的系统状态是否可以重建
      • 在线测试(例如,系统在外部测试期间是否正常运行以及访问外部测试点的难易程度)
      • 自动输入/刺激插入

其他要点

弗吉尼亚级潜艇采购展示了其他最佳实践。 Schank (2011)、GAO (2008) 和 General Dynamics (2002) 讨论了这些问题。

这些最佳实践包括严格的设计交易以控制成本、仔细考虑组件的技术成熟度以及程序稳定性的重要性。

概括

总之,弗吉尼亚级潜艇的工作促使声纳界用于设计潜艇声纳的传统架构方法发生了变化,并验证了从专有接口过渡到研发 (R&D) 和组件成本方面的成本节约。行业标准接口。 确定可行的架构评估指标列表是这项工作的另一个好处。


您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码: 验证码,看不清楚?请点击刷新验证码 必填



856 次浏览
8次
 
欢迎参加课程:
数据建模方法与工具
MBSE(基于模型的系统工程)
基于 UML 和EA进行分析设计