系统工程与MBSE应用随想

  • A+
所属分类:安全闲碎

做系统开发以来,再到现在做第三方的技术服务工作,逐渐地对系统生命周期开发过程及工具方法熟悉了起来,遇到问题即使不能直接想到答案是什么,但也会知道到哪里去找答案。但心里一直有个疑问,这套方法论来自于哪里,现在终于找到了答案,这就是系统工程学


最早接触系统工程这个名词是在大学期间,记得上控制理论课程时介绍过系统工程,了解到中国开展系统工程研究的第一人是著名科学家钱学森先生,这是一门综合性学科,注重解决系统的整体问题,有别于机械、电子、软件、气动等单一学科。但这个学科对于初出茅庐的大学生来说,很难理解到很深的层次,当时只是一知半解。


一、什么是系统工程


在工作后开始从事轨道交通信号系统的研发工作,相比于常规的系统开发,信号系统属于安全苛求系统,开发要求非常之严谨,层级也很复杂,包括大系统、子系统、再到子系统的软件和硬件。开发过程按照轨道交通EN50126的全生命周期V模型开发,包括系统开发划分为多少个阶段,每个阶段的输入是什么,采用什么样的工具方法,需要什么专业的人来做,输出交付物是什么。再看其它行业的开发过程,如工控领域的IEC61508、汽车领域的ISO26262,也采用了相同的开发模型和类似的工具方法。不仅限于电子系统,航空航天的复杂系统也是采用这样的开发模型,看来有一种相同的方法驱动着不同领域中的复杂系统开发。


对于轨道交通、汽车、航空航天等行业的控制系统,都属于复杂系统,有着多样的系统特性,按照主制造商-一级供应商-二级供应商的项目管理模式,系统的研发生命周期长,项目失败的成本非常高。因此运用系统工程方法,作为其核心的系统工程师应关注系统的总体问题,系统与外部环境、其它系统的之间联系,把不同专业的工程师、不同子系统有机地集成于一体,取得系统性能和成本的平衡。


在国际系统工程协会INCOSE官网有对系统工程和系统工程师的定义,原文为:

Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.

系统工程是一种跨学科和综合的方法,可以使用系统的原理和概念以及科学、技术和管理方法来使能工程系统成功地实现、使用和处置(淘汰)。


Systems engineers are at the heart of creating successful new systems. They are responsible for the system concept, architecture, and design. They analyze and manage complexity and risk. They decide how to measure whether the deployed system actually works as intended. They are responsible for a myriad of other facets of system creation. 

系统工程师是创造成功的新系统的核心。他们对系统的概念、架构和设计实现负责,对系统的复杂性和风险分析和管理,决定如何衡量已部署的系统是否达到预期要求。他们还负责创造系统的其它各方面。



系统工程与MBSE应用随想

二、系统工程的困境


而在现实中,系统工程并没有得到足够的重视,对于系统工程开发周期的理解过于机械化,片面或浅显地理解标准的要求,有意或无意地忽视系统开发的主要过程,以下的问题非常常见:

  • 变更成本高:系统生命周期开发过程产生了大量的文档,从需求规格、架构设计、子系统需求、子系统的软件需求/硬件需求、系统软件组件的概要设计、详细设计,硬件单板的技术规格,原理图,机械结构设计,3D图/2D图,……每个阶段的输出作为下个阶段的输入,环环相扣。当其中的一个需求发生变更,与它关联的文件修改工作量工程浩大,或者干脆不改文件,依靠会议沟通或人与人之间的口口相传;

  • 无法维持一致性:不同层次的文件之间缺乏一致性,虽然有一些需求管理工具可以管理文档之间的一致性,但在中间过程很难保证自上而下的一致性和可追溯性,需要在项目快要完成的最后阶段花费大量精力去补充修改文档;

  • 产生大量僵尸文档:为满足客户需求或标准的认证要求,项目完成了很多的安全分析报告、可靠性报告、验证报告,但这些文件似乎只是为了满足合同要求或标准的合规性要求,没人关注做这些文件的目的。完成的报告只是静静躺在那里,看不到它们起到的作用;

  • 理解歧义:不同工作角色,如系统集成方与一级供应商,系统工程师与各专业工程师,研发工程师与测试工程师采用文档的方式交互各自对于系统的理解,甚至双方不会见面,由于双方对文字理解的歧义导致的设计偏差时有发生,造成工期延误、成本增加。


三、一种系统工程方法——MBSE


面对这些不可回避的问题,系统工程有没有更好的方法去解决这些问题,帮助系统工程师应对复杂系统产生的大量文档以及需求频繁变化的挑战。下面介绍一种方法:基于模型的系统工程(MBSE)


MBSE方法最早从2007年,国际系统工程协会INCOSE开始推广基于模型的系统工程(MBSE)方法,现在由OMG(对象管理组织)和INCOSE两大组织支持,MBSE从提出概念开始,得到了迅速的认可和应用,尤其是在航空航天和国防领域,MBSE方法已经成为了重点应用。美国国家航空航天局(NASA)、美国波音公司、洛克希德-马丁公司、欧洲空客公司、达索公司都在多种型号的不同研发阶段进行了尝试。在中国,中国商用飞机有限公司、中国航空工业集团、中国航空发动机集团等航空工业企业也纷纷加入这一领域,积极地开展课题研究。


系统工程与MBSE应用随想

MBSE相比基于文档的系统工程的优点,上网找找都可以列出很多,比如说:

  • 保持了系统的精确性、一致性和可追溯性;

  • 统一的模型包括了系统需求分析、架构设计、需求管理、性能分析、仿真、测试各个方面;

  • 通过模型的应用使系统开发过程形式化,减少人为失误;

  • 便于不同专业工程的信息沟通,包括软件、硬件、机械、仿真和测试;

  • 可以在项目早期开展需求的验证,由V模型变为W模型。


MBSE是否意味着采用了这种方法,我们所开发的产品就可以对原来的性能更好、成本更低,开发周期更短。首先要理解不管是DBSE(document based system engering)还是MBSE,它的核心都是系统工程方法论,都会执行例如《INCOSE系统工程手册》所描述的生命周期活动,它们的生命周期活动是一致的,而DBSE和MBSE的区别在于生命周期模型各阶段的输出物由曾经的文档变成了模型。引用《Sysml Distrilled》作者Lenny Delligatti的一句话:


A diagram of the model is never the model itself; it is merely one view of the model.

模型的图永远不是模型本身,而是模型的一个视图。


具体解释为:系统就是你所要设计满足预期要求的那个对象,它的模型在你设计前已经存在了,即你所要达到的结果。你的建模只是从不同的维度把它描绘出来,如通过需求图描述它的需求关系,通过模块图描述它的内部子系统、组件之间的层次关系和它们之间的关联关系,通过用例图描述它应用的各类场景中的行为等等。


对于系统工程师来说,不能说采用了MBSE方法就能减轻对他们的能力要求,降低系统设计所需要的技术要求和管理要求;对于用户来说,采用了MBSE能又快又好产生好的产品。


因此,对于有理想,有目标,有能力的系统工程师们,他们在第二节的那些困局中,有了一个通往目标的梯子,前进的路,还是需要自己去走。想要用好MBSE的人,他们既要有系统工程思维,实现系统所需要的技术能力和组织能力,也要学习MBSE建模语言、建模方法和建模工具,对于他们的要求来说是更高了


本文作为一个MBSE的随想,未对具体的技术进行展开,笔者正在从事MBSE工程学方法在轨道交通行业系统开发、Safety & Security分析、可靠性设计的课题研究,后续也会在公众号发布一些应用实践的文章,欢迎有志于此的系统工程行业同仁一起交流。


参考:

  1. Systems Engineering (incose.org)

  2. start [MBSE Wiki] (omgwiki.org)

  3. SysML Dristrilled - A Brief Guide to the Systems Modeling Language - Lenny Delligatti


本文始发于微信公众号(薄说安全):系统工程与MBSE应用随想

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: