当前位置:首页-文章-MBSE-正文

基于模型的系统工程的探索与实践

1、传统设计方式面临的挑战

在当前航空、航天、汽车等行业,对工业产品易用性、舒适性、安全性等方面要求的提高,导致当前工业产品电气化、智能化程度越来越高,产品复杂度的量级不断跃升。

传统的基于文本的系统设计方式存在天然局限,导致其越来越难以应对当前的复杂产品设计挑战,如:

  • (1)基于自然语言描述的设计文档一致性差,沟通效率低且容易出现歧义;
  • (2)自然语言容易引入形容词等模糊描述,很难保证准确性;
  • (3)文本描述的设计元素之间无法实现追溯分析,当出现设计变更时很难对变更影响进行准确评估;
  • (4)基于文本的设计方案无法进行前期仿真验证;
  • (5)设计方案无法与详细设计阶段的数字化模型(如CAD)关联;

MBSE技术的出现为应对这些问题提供了有效的应对手段。

2、平台总体架构及解决方案概述

能科采用西门子软件平台架构作为MBSE的实施平台。以Teamcenter+AWC作为基础数据平台,使用其中的需求管理+参数管理模块管理各层次产生的需求及指标参数;使用西门子基于capella工具为原型开发的SMW进行系统建模;使用基于AWC的模型管理和仿真数据管理模块定制开发的多学科协同仿真计算平台对系统模型进行仿真论证计算。

MBSE实践从用户需求出发,以ARCADIA系统工程方法论为理论基础,使用SMW建模工具开展系统功能、逻辑架构、物理解决方案建模,进行指标参数的拆分。

以Teamcenter+AWC平台为依托,管理下发功能、需求、指标参数、系统架构等模型,进行关联追溯,以模型的形式指导开展设计工作。通过协同计算平台进行多专业、多学科之间的协同,调用各种仿真计算工具对前期的设计方案进行论证计算,在设计早期排除一些不合理的方案,降低研发设计的成本,提高研发效率从而增强企业的核心竞争力。由过去以“文档为主,模型为辅”向“以模型为主、文档为辅”的全领域流程体系和平台进行建设。

3、面向MBSE的需求工程与参数管理

产品研制过程中,系统工程流程是围绕需求进行的,所有的活动,包括设计、仿真、验证等等,其最终目的都是为了设计、制造出满足客户需求的产品。

基于模型的系统工程的探索与实践 - 第1张

图 3-1 总体需求开发流程

为了将复杂产品的需求管理过程变得简单,并且可以追溯,将采用分层次的方法对产品进行分解,将复杂产品的项目、需求、研发工作分为项目层、产品层、分系统层来进行管理,而每层的管理过程是相似的,复杂装备系统的系统工程研制流程就是要在产品的每一层完成循环迭代过程。

下面以一个层级的需求、设计、验证等工作和流程来论述,在产品的每个层级所需要进行的产品系统工程研制过程的主要工作。

(1)需求捕获过程:

开发人员收集相关方的需求信息,实现外部需求文档导入和需求结构化管理,并赋予唯一的需求ID和进行需求属性定义。

基于模型的系统工程的探索与实践 - 第2张

图 3-2 需求条目化

(2)需求分析过程:

对收集到的需求进行分析和整理,去除与需求无关的信息,找出需求间的联系并解决。目的是为了分析和提炼用户真正、具体的需求。

可以借助系统架构建模与分析,实现高层级需求到低层级需求的逐层分解和分析。形成总体以及不同的分系统技术指标参数。需求分析是需求开发过程中非常重要的一步。

基于模型的系统工程的探索与实践 - 第3张

图 3-3 需求及指标参数拆分

(3)需求确认过程:

对分析出的需求与源需求的相关方进行确认,记录相关方的确认结果,更改需求状态为已确认。

(4)需求分配过程:

将需求及指标参数连同功能、架构下发给对应的部门以开展设计工作,更改需求状态为已分配。

基于模型的系统工程的探索与实践 - 第4张

图 3-4 需求分配

(5)需求验证过程:

对需求附加验证方法(分析、检验、演示、测试)。功能性需求通常需要测试验证产品的正确的行为,性能需求按照仿真计算或者检验等方式进行验证。

基于模型的系统工程的探索与实践 - 第5张

图 3-5 需求关联验证报告

需求追溯是需求工程中一项重要工作,需要建立追溯起追溯关系的对象有很多,如:用户功能性需求和系统顶层功能、系统顶层功能与系统功能性需求、系统需求与系统架构等。建立元素之间的追溯关系可以借助Teamcenter的追溯矩阵或者工作关联开展。

基于模型的系统工程的探索与实践 - 第6张

图 3-6 需求追溯矩阵

需求与系统中的元素建立好关联之后,就可以通过AWC的需求追溯工具对需求进行追踪,从而快速发现当高层级需求发生变化时会影响到的系统中的元素。

基于模型的系统工程的探索与实践 - 第7张

图 3-7 需求追溯

4、基于模型的系统功能及架构建模

传统的系统功能设计基于文档和借用历史经验的模式,而在复杂装备系统研发中,很多功能没有历史经验和数据继承,因此需要通过基于模型系统工程正向分析设计的途径来提高创新设计能力和研发可靠性,其中通过基于模型进行外部系统架构建模设计,捕获和分析客户需求。通过对产品系统架构建模设计,捕获和分析产品需求。通过对产品系统组成和设备、组件组成的架构分析,捕获和分析产品性能、方案设计的功能要求,同时通过与需求管理环境和系统试验环境的集成实现研发的快速验证管理迭代。

基于模型的系统工程的探索与实践 - 第8张

图 4-1 需求层级与Arcadia方法论的对应关系

按照ARCADIA系统工程方法论,将建模过程分为四部分:运行分析、系统分析、逻辑架构、物理架构,具体的使用过程可以根据需要进行裁剪。下面通过SMW工具中的模型化的视图说明系统工程建模过程。

4.1运行分析

运行分析的目的是理解用户想要做什么。Arcadia方法结合了美国国防部架构框架(Department of Defense Architecture Framework,简称DoDAF)的相关理念, 首先定义的是用户需要系统完成的任务,也就是用户需要具备的运行能力。

在运行分析阶段,只分析用户遇到的问题、用户的需要以及用户的潜在需求。这时并不需要确定系统的边界,当系统出现在运营分析中,就限定了给用户的解决方案, 也就没有办法评估相关方案是否是最佳的解决方案。

运行分析的对象是用户、用户在运营中的角色、用户完成的活动,分析的内容是用户活动是否存在问题和不足、是否有改进的空间。

运行分析完成后,系统工程师需要将不同用户的需要进行整理和分析,分析后得到统一的用户需求规范。

(1)运行能力及相关方定义(OCB):

针对用户需要拆分系统运行能力(目的),并根据每一种运行能力确定利益相关方。

基于模型的系统工程的探索与实践 - 第9张

图 4-2运行能力图OCB

(2)运行活动分析(OAIB、ES):

按照分析出来的运行能力,对相关方的运行活动进行添加、细化。OAIB通过描述、分析运行活动之间的输入、输出关系对活动进行添加、细化;ES通过相关方运行活动的先后时序对活动进行添加、细化。

基于模型的系统工程的探索与实践 - 第10张

图 4-3 运行时序图OES

(3)运行活动分配(OAB):

将分析出来的用户活动分配给相关方。

基于模型的系统工程的探索与实践 - 第11张

图 4-4 运行架构图OAB

4.2系统分析

在系统分析阶段,研究的是系统如何满足用户的需求。通过运行能力的细化,明确系统在用户运行分析中需要完成的任务,总结抽象系统需要具备的能力,定义系统需要完成的活动(具备的顶层功能),考虑运行约束给系统活动带来的限制。在系统分析阶段,还需要考虑系统活动完成所需的输入条件,也就是系统的外部接口。

运行分析完成之后,形成顶层系统需求。

(1)分析系统任务、识别系统能力(MCB):

从相关方的运行能力中分析出哪些属于系统的能力,对应关系包括全部实现、部分实现、不实现三种。

(2)分析顶层系统功能(SDFB、ES):

从相关方的期望(运行活动)中分析出哪些属于系统的功能,并按照顶层系统能力对顶层系统功能进行添加、拆分。

基于模型的系统工程的探索与实践 - 第12张

图 4-5 系统功能数据流图SDFB

(3)系统顶层功能分配(SAB):

划定系统边界,将细化出来的系统功能对系统和相关方进行分配,并定义系统与外部相关方之间的接口。作为高级别体系,系统分析阶段的SAB架构图将系统看作是黑盒,其内部情况未知。

基于模型的系统工程的探索与实践 - 第13张

图 4-6 系统架构图SAB

4.3逻辑分析

逻辑分析是系统功能的细化, 将系统功能分解为子功能,并在系统层面实现系统子功能的整合与分配。逻辑分析还解决系统内部约束、系统内部功能、功能关系、具体实现的技术以及潜在技术等方面问题。在逻辑层面,实现详细的系统分析,考虑系统的约束,平衡系统性能、安全性和可靠性等指标,以求得到最佳的系统方案。

逻辑比较类似于企业总体研发设计过程中所提及的子系统概念。逻辑分析结束后,形成子系统需求规范和逻辑架构。

(1)子系统顶层功能定义(LDFB、ES、LFBD):

将系统能力转化、拆分为子系统能力,通过识别出来的子系统能力,使用功能数据流分析法、时序分析法、树状拆解合成法分析子系统功能。

基于模型的系统工程的探索与实践 - 第14张

图 4-7 系统时序图ES

(2)逻辑架构定义(LAB):

将分析出来的所有子系统顶层功能消耗式地对子系统进行分配,并根据子系统之间功能数据的交互关系定义子系统之间的接口关系。

基于模型的系统工程的探索与实践 - 第15张

图 4-8 逻辑架构图LAB

4.4物理分析

物理分析是定义系统的具体实现方式, 考虑系统的物理特性, 以达到系统在质量、功耗、成本等物理层面的最优设计。物理分析和终端产品分析适用于不同的系统对象和系统组织形式。物理分析过程考虑的是系统如何实现,包括物理约束的系统架构选择,物理连接形式,各部件实现的功能等。

物理分析后,形成对组件的需求规范和物理方案架构。

(1)组件功能分析(PDFB、ES):

在组件层对系统功能进行定义。

(2)物理架构定义(PAB)架构图:

定义物理组件解决方案,对物理组件分配功能,定义物理连接及接口。

基于模型的系统工程的探索与实践 - 第16张

图 4-9 物理架构图PAB

物理体系完成之后,整个体系应开发到技术配置项的层次,软、硬件开发团队开始详细设计工作,其中的商业现货或者可重复使用的组件通过购买或者其他方式获得。

5、多学科协同仿真计算平台

总体设计人员在AWC的协同仿真计算平台中搭建仿真架构模型,对方案架构开展论证计算。仿真架构可以关联企业封装好的工业APP。

基于模型的系统工程的探索与实践 - 第17张

图 5-1 工业APP库

除了可以使用AWC的协同仿真计算平台自身进行程序封装、仿真工具集成调用外,协同仿真计算平台还可以与一些其他的与制造业相关的专业的低代码开发平台工具进行集成,例如西门子的mendix低代码开发平台。借助专业的低代码开发工具可以制作出很多复杂美观、操作便捷的工业APP界面,设计人员可以自己使用工业APP封装工具对仿真计算程序进行解析封装,调用各类仿真计算工具开展仿真计算,与协同仿真计算平台进行数据交互。

基于模型的系统工程的探索与实践 - 第18张

图 5-2 工业APP

本文来源:能科科技,作者:张振宇。

相关文章

换一批