MBSE应用于系统研发的效能分析

姚 元,周传睿,梁 浩

(南京电子技术研究所, 江苏 南京 210039)

0 引 言

从20世纪60年代开始,系统工程 (SE) 在航天、国防等领域一直被用于对复杂系统的研发管理[1-5]。传统的系统工程以文档和实物等形式为依托。以系统工程的典型V型模型为例,系统的设计阶段主要包括需求分析与规格定义、系统功能与架构设计、子系统设计等,该阶段自顶向下,根据需求将任务进行分解,再将任务下发到不同部门,各部门之间的信息传递载体主要为书写文档、数据等。系统的实现阶段主要包括零部件、组件、设备、子系统再到整个系统的集成,集成完成以后进行技术测试和确认交付等。

随着国防技术的不断发展,系统的规模和复杂度都在不断增长,传统基于文档的系统工程 (TBSE) 难以满足复杂系统的研制需求[5]。一般而言,系统复杂度越高,研发文档数量越多,出现问题的风险就会越大,传统TBSE的不足也就越加凸显。在系统设计阶段,各部门内部的文档书写习惯以及数据表达格式等存在差异,不同的学科领域可能使用不同的术语或公式,导致部门内外之间信息传递过程的效率降低。部门研发人员在阅读技术文档时费时费力,甚至产生误解,导致各部门协同效率大大降低。在实物集成阶段,常规通过对实物样机进行测试的方式虽然真实有效,但也存在弊端。一方面,如果设计方案中存在的问题在实物集成阶段才被发现,解决问题的成本和周期会大大增加。另一方面,实物样机与产品的设计方案以及责任单位之间的映射关系不严格、不规范,在出现问题时,不利于问题的追查定位与回溯。

随着信息技术及数字建模仿真技术的快速发展,基于模型的系统工程 (MBSE)[6-12]成为近年来复杂系统设计和技术管理的研究热点。与传统TBSE不同,MBSE采用数字模型来承载信息,具备知识统一表述、沟通交流效率高、知识再利用增强、系统研发风险减小等潜在优势,有望大幅提升复杂系统研发的效益[11-14]。

然而,在许多实际系统研发案例中,应用MBSE并没有获得期望中的高得益,有些案例中甚至出现效果不及TBSE的情况。文献[12]通过文献计量学分析,对2022年以前出版的MBSE重要文献进行了调查,认为当前处于开发和应用第二代MBSE技术的初期阶段,未进入技术成熟期。从技术发展阶段上解释了MBSE应用不及预期的根源,但缺少细化的原因分析。探究MBSE应用不及预期的原因并提出改进建议十分重要。但目前针对以上问题的分析较少,往往归咎于MBSE尚处于发展完善阶段[12]、设计师接纳新设计模式动力不足、投入精力不够等,却忽视了实际系统研发场景与期望应用场景的差异、应用MBSE的代价等因素,导致所采取的改进措施效果不甚理想。

本文建立了一种应用MBSE的效能模型,从得益和代价两个方面分析了相比传统的TBSE,MBSE带来的效能提升指标,用以表征MBSE在系统研制过程中发挥作用的有效程度;使用提出的效能模型针对应用MBSE不及预期的原因进行了分析;基于得益最大化且代价最小化原则,提出了MBSE应用于系统研发以及MBSE试点和推广的相关建议。

1 应用MBSE的效能模型

1.1 基本效能模型

为了比较应用MBSE相比传统TBSE带来的效能差异,给出基本效能模型

E=G-L

(1)

式中:E表示应用MBSE相比应用TBSE的效能变化,主要体现为以系统研发成功为基本前提的成本和周期变化;G表示应用MBSE的得益与应用TBSE的得益之差,包括研发效率提升和质量改善的变化等;L表示应用MBSE的代价与应用TBSE的代价之差,包括学习成本、人力物力资源消耗的变化等。

1.2 应用MBSE的得益

1.2.1 应用MBSE的期望得益Ge

诸多文献均提到了应用MBSE相比传统TBSE可以带来的益处,本文将其定义为应用MBSE的期望得益Ge,即声称、预计可以获得的研发质量的改善。期望得益Ge主要包括以下内容:

(1) 消除歧义,统一语言,提升沟通效率

在传统TBSE中,由于个人理解的不同,文字描述有时会产生不同的解读,造成歧义和误解。MBSE使用统一、规范、严格的模型对系统的功能、接口等进行准确描述。直观、无歧义的模型可以有效避免信息传递过程中可能产生的多义性,从而提高团队成员之间信息理解的一致性。此外,MBSE模型可以在多学科、多领域之间互联且协同,有利于不同领域的设计人员以易于理解的方式描述各子系统之间的接口规范以及关联关系,提高跨学科、跨领域的沟通交流效率[9]。

(2) 需求、状态变更关联传递

在传统TBSE中,当需求、技术状态发生变更时,需要人工更改相关联的所有文档。当相关文档数量较多时,变更工作量大且容易发生遗漏,导致不同文档内容相互之间不一致。MBSE抛弃了传统的文档管理方式,更加明确了系统模型和需求之间的关系,各系统模型之间相互联动,当发生需求、状态变更时,各类变更自动关联、传递,系统更改带来的影响也更透明。

(3) 及早发现问题,支持跨系统设计

MBSE可以通过模型对系统进行多角度分析,在设计的早期进行系统验证,从而降低风险,同时缩短设计更改周期。在系统视角层面,MBSE通过构建数字化设计成果,可以通过工具辅助自动生成任意跨系统视角视图,帮助工程师在系统间发现问题,弥合传统手段下因系统视角缺失导致的设计遗漏、系统间数据不匹配等问题。

(4) 降低重复开发工作量

MBSE模型严格、规范,具有模块化特征,可以重复利用,避免功能类型相同模块的重复开发,并使得系统研发过程中的信息获取以及再利用变得便捷高效,进而实现系统设计重用、设计自动化,提高设计效率[9]。对同一个项目产品的生命周期维度,系统前期的架构设计成果可以向后期详细设计成果(软件接口、电原理图、线缆图等)进行模型传递,避免人为二次劳动。

1.2.2 应用MBSE的实际得益Gr

将MBSE应用于某个具体系统的研发时,实际能收获到的相比于传统TBSE的益处,与其期望或者声称的得益Ge往往存在一定差距。本文将某个具体系统实际能获得的研发质量上的改善定义为应用MBSE的实际得益Gr,定义

Gr=rGe

(2)

式中:r表示应用MBSE的实际得益与期望得益的匹配度,0

(1) 系统的复杂度

与TBSE相比,MBSE可以满足具有更高复杂性产品的系统开发要求,因此产品越复杂,基于MBSE研发模式的得益越高。但是当某个具体系统的复杂度不够高时,应用MBSE相比于TBSE,获得的得益会较低。以系统复杂度C为因变量,应用MBSE相比于TBSE的实际得益曲线如图1所示。随着系统复杂度增高,应用MBSE得益越高。但是在一定的复杂度门限CT以下,应用MBSE相比于TBSE的得益非常低。只有系统复杂度超过门限CT后,MBSE的实际得益才迅速提升,并逐渐接近MBSE的期望得益。

图1 应用MBSE相比TBSE的得益随系统复杂度的变化

值得注意的是,系统的复杂度是一个相对概念,而非绝对概念。同一个系统的复杂度C会因不同研发团队的专业能力、研发经验等因素的不同而存在差异。以雷达系统为例,某个大型雷达系统对没有雷达设计经验的研发团队而言,复杂度非常高,但是对拥有丰富雷达设计经验的团队而言,其复杂度则可能为中等。在相对复杂度不高的情况下,应用MBSE相比于TBSE的得益也会相应降低。

(2) 系统面临的实际瓶颈问题

系统研发过程中会遇到许多瓶颈问题,如需求变更频繁、沟通交流效率低下、关系协调困难、技术风险高等。不同的系统所面临的研发瓶颈问题并不相同。

一方面,当某个具体系统的主要瓶颈问题,与MBSE期望所能解决的问题完全匹配时,应用MBSE将获得较高的得益。反之,当其主要瓶颈问题与应用MBSE的期望得益不匹配时,应用MBSE将难以获得期望的得益。另一方面,当系统研发中存在MBSE所能解决的问题,但是这些问题并不是核心关键问题时,应用MBSE解决该问题所获得的实际得益也较低。例如,当研发团队成员彼此沟通交流经验丰富,依托传统TBSE模式已经形成了高效、准确的沟通渠道与方式时,MBSE所期望的消除沟通歧义性得益将变得较低;而当研发团队成员彼此较为陌生,缺乏沟通交流经验且专业跨度较大时,MBSE所期望的消除沟通歧义性得益将会较高。

1.3 应用MBSE的代价

应用系统工程本身也需要付出人力、物力、时间等资源代价。同样,相比TBSE,应用MBSE也可能付出一定的额外成本,主要包括建模成本、学习成本、试错成本以及匹配成本等,即

L=Lm+Ls+Lf+Lo

(3)

1.3.1 建模成本Lm

复杂产品往往包含多个子系统,不同子系统之间关联关系不同,每个子系统内部的功能特性也不同,内在机理难以具体描述,因此具有很高的复杂度,使得建立可信的复杂产品模型需要面对高昂的建模成本。

复杂产品的研制任务往往具有复杂性、多元性、自主性等特点。系统模型的建立通常以系列化、通用化、标准化为指导思想,需要制定一系列建模的标准规范,并按照统一的规范开发各种仿真系统。建模过程中,需要投入总体到分系统的上下游产业链内的产品研制人员与数字化建模实施人员,需要配备为相应规范、系统模型、建模工具提供支撑的供应商和科研院所等。需要各研究部门、生产和管理部门共同协作完成,且该过程需要覆盖从需求分析到设计论证、生产加工、组装、测试,直到最终交付、维护的完整生命周期,导致利用建模手段研究复杂工程体系的全过程需要大量的人力、物力以及时间成本。

1.3.2 学习成本Ls

应用MBSE的前提是学习理解并熟练掌握MBSE。

传统TBSE已经在国内系统研发中应用了几十年,随着系统研发实践的不断深入,各企业结合实际情况在标准TBSE流程基础上进行了改良与裁剪,各自形成了非常成熟、深度匹配的企业流程规范。研发团队学习TBSE的成本付出较低。

MBSE作为系统工程最新的发展方向,正处于发展变化之中,其自身比较复杂,而且与各企业系统研发的实际情况匹配还不够深入,研发团队学习MBSE原理需要付出额外的时间、金钱和人力成本,并且学习越深入,学习成本越高。

此外,对MBSE工具的熟练掌握也需要付出学习成本。MBSE工具包括建模工具以及软件,对这些新型工具的学习也需要付出一定的成本。相比之下,在传统TBSE中,对文档类设计工具的掌握已成为设计师的基本必备技能,学习成本相对小很多。

1.3.3 试错成本Lf

应用MBSE的试错成本主要包括:

(1) 未正确理解和应用MBSE的试错成本

MBSE作为系统工程的新兴发展方向,其自身的知识体系较为复杂,对其概念内涵、运行机理的理解尚未形成统一、规范、成熟的标准。同时,目前主流MBSE方法基本来自国外[10],如IBM的Harmony-SE、Vitech MBSE方法论以及INCOSE面向对象的系统工程方法等。方法论的外源性导致国内研发人员在学习MBSE方法论过程中容易存在一定的认识障碍。不具备资深MBSE研究经验的设计人员,很容易进入传统的研究路径并对MBSE抵触。当对MBSE的理解与运用掌握存在偏差时,会因为错误的应用方式而带来一定的试错成本。例如建立模型的颗粒度不满足要求需要重新建模,机械套用MBSE流程导致不达标等。

(2) MBSE设计工具不够完善导致的试错成本

当前面向MBSE的建模及设计软件和工具仍处于发展完善之中,一些设计工具存在模型运行速度慢、不支持协同建模设计、不支撑复杂系统的全要素动态行为仿真、与其他设计工具交互困难等问题,还需要设计师在试用中反馈问题以促进MBSE设计工具的优化迭代和完善。设计师在试用这些尚未完善的MBSE设计工具时,就会造成额外的试错成本。

1.3.4 过度应用成本Lo

MBSE作为系统工程最有前途的发展方向之一,往往被寄予厚望,希望被广泛应用于系统研发的各个方面。然而,大量系统研发的工程实践表明,在系统研发中应用系统工程并不是越多越好,因为应用系统工程本身也需要付出人力、物力、时间等资源代价。实践表明,系统工程付出占项目总付出的比例为14%左右时[5],可以获得收益和代价的最佳平衡。在系统工程上的投入超过14%时,系统研发会因为在MBSE上付出了过多的投入而造成额外的进度拖期和成本超支。

1.3.5 应用MBSE代价的时间递减性

上述应用MBSE的各类代价,均会随着MBSE技术的逐渐成熟与日益推广而逐步降低。在应用初期,需要建立大量模型,对MBSE接触不多、对MBSE理解不深入、 MBSE设计工具不够完善、对MBSE应用过度,往往导致各类成本均较高。

在应用中后期,随着模型库里的内容逐步丰富,建模技术的不断成熟和规范化,以及模型可重用特征带来的模型重复利用率提升,建模成本将会越来越低。当MBSE普及程度比肩TBSE时,MBSE相比于TBSE的学习成本就可以忽略不计,而随着对MBSE理解的深入和MBSE设计工具的逐步完善,试错成本也会越来越低。当系统工程师对MBSE持有理性的期望时,其过度应用成本也会降低。

总而言之,应用MBSE的成本和代价主要集中于初级阶段。随着时间的推移,各类代价将呈现稳定下降的趋势,如图2所示。

图2 应用MBSE的代价随时间逐渐降低

2 应用MBSE效能未及预期原因分析

基于应用MBSE的效能模型,可以解释为何在许多实际系统研发案例中,应用MBSE并没有获得期望的高于TBSE的效能。当得益G小于代价L,致使总效益E<0时,应用MBSE并不能获得更好的系统研发效果和体验。

应用MBSE未达到预期效能的典型情况包括:

(1) 选择了相对简单的系统应用MBSE,导致相比于TBSE的得益较低。

(2) 所选择系统面临的主要风险与挑战与MBSE所能解决的问题匹配度不高,导致相比于TBSE的得益较低。

(3) 系统可复用的模型较少,需要重新建立大量的模型,导致建模成本较高。

(4) 选择缺乏MBSE知识背景的设计师开展MBSE的学习和应用,导致学习成本较高。

(5) 选用的MBSE设计工具成熟度较低,导致试错成本较高。

(6) 对MBSE的效能预期过高,过度应用MBSE导致成本较高。

3 应用MBSE的优化建议

基于应用MBSE的效益分析模型,为了指导系统研发实践,提高应用MBSE相比于传统TBSE的效益,提出以下建议。

3.1 最大化得益

(1) 选择具有合适复杂度的系统应用MBSE

在尝试对某特定系统应用MBSE之前,首先需要评估TBSE的适用性,根据产品研发的复杂度和成熟度,决定是否应用MBSE。对简单或成熟类型的系统,当TBSE已经可以很好解决该系统研发所面临的技术管理等问题,且应用MBSE获得的得益较少时,建议优先考虑传统的TBSE。只有当系统复杂度较大,超出TBSE的应用范畴时,应用MBSE才更为必要。

(2) 评估MBSE与所选系统主要矛盾之间的匹配性

当系统研发面临多专业的沟通协调、数量庞大的需求管理、频繁的需求变更、数量巨大的文档及其版本更迭等主要矛盾时,应用MBSE是合适的。而当系统研发中上述问题并不突出(用传统的TBSE就能很好解决),甚至上述问题并不存在时,应用MBSE得益不高。

3.2 最小化代价

(1) 保证一定的模型重用度

完善模型相关的开发标准,包括模型的描述组件标准、建模语言标准、模型接口标准、模型关联关系描述标准等,建立一套领域相关性低,能够实现多学科、多团队并行开发的建模方法,保证MBSE能较好运用于不同复杂度系统的研发,并降低建模成本。

(2) 保证设计师对MBSE具备一定的掌握程度

首先,已经具备一定系统工程技术能力的骨干需将所学知识进行传授。其次,应让更多的员工参与到系统工程的相关培训和学习当中,加强考核。最后,各部门员工应按计划保障项目的开展。新员工将重点放在相关工具软件的学习应用上,老员工则将重点放在工程经验的传承上,新老员工一起完成软件的学习和相关模型的建立,同时保障项目的应用推广。

(3) 保证MBSE设计工具的基本可用性

加大对MBSE软件研发的投入,通过自主研发,不断降低对国外建模工具等的依赖,降低MBSE工具和软件的使用成本。

(4) 适度应用MBSE

对MBSE的发展热潮持理性态度,保持对应用MBSE所能带来得益的合理预期,努力将系统研发中对应用MBSE的投入占系统研发总投入的比重控制在14%左右,以避免过度应用MBSE造成的成本。

(5) 提升企业的整体数字化水平

企业在系统研发中应用MBSE时,其付出的代价受到企业的整体数字化水平影响,包括数字化氛围、数字基础设施完备程度等,数字化水平越高,应用MBSE的阻力及代价越小,故需要努力提升企业的整体数字化水平。

3.3 明确试点应用和推广应用的区别

一般而言,应用MBSE的过程分为试点和推广两个阶段。如果不加以区分,可能产生错误的应用MBSE的预期。

试点阶段的主要目标,并不是单纯演示和证明应用MBSE相比于TBSE的优势和先进性,而应充分考察应用MBSE的得益和付出的代价,为后续推广应用阶段提供有参考价值的指导建议。在试点阶段,为了便于快速打通MBSE的流程,通常会选取相对成熟和简单的系统进行应用,并安排新人使用还不够完善的MBSE设计工具进行尝试。依据上文分析,此种试点配置往往会导致应用MBSE相比于TBSE的得益较低、代价较高,往往难以形成更好的研发体验和示范。此时,不能因为试点效果不佳而否定MBSE,因为试点阶段的主要目标在于走通流程、仔细考察应用MBSE的得益和代价,以指导后续推广阶段的应用。

在推广阶段,则需要按照得益最大化、代价最小化原则,仔细评估将MBSE应用于某一个特定系统后可能获得的得益和付出的代价,并竭力提高得益、降低代价。若经过评估和策划仍不能保证得益超过代价时,选择传统TBSE则更为明智。

4 结束语

MBSE作为系统工程最新的发展方向,为解决系统研发所面临的日益增长的系统复杂度问题带来了有潜力的解决方案。本文主要针对应用MBSE不及预期的问题进行探究。首先,建立了一种MBSE的效能分析模型,提供了定量评估MBSE在系统研制过程中发挥作用的有效程度的解决方案。模型从得益和代价两个方面分析了相比于传统TBSE,MBSE带来的效能变化。接着,结合模型对应用MBSE不及预期的问题给予了解释。基于得益最大化和代价最小化原则,提出了MBSE应用于系统研发的优化建议,并对MBSE的试点和推广提供参考意见。

时至今日,国内MBSE的应用依然处于初级阶段,大量相关问题亟待解决。MBSE的未来发展需要大量的基础理论和方法的研究,并在长期的工程实践中不断完善和优化。