【智慧的钥匙】支持MBSE的3类典型企业信息管理系统研究

1年前浏览2935

.1.

摘要

多年的实践表明, 基于模型的系统工程 (MBSE) 没有被大规模采用的主要原因之一是缺乏对整个系统生命周期内各类模型进行管理的能力和手段。在此背景下, 介绍了模型管理与MBSE、产品生命周期管理 (PLM) 的概念及其之间的关系, 分析了不同行业的模型管理现状, 提出了模型管理的解决方案与技术方向, 最后给出了建设企业信息管理系统的建议, 以期为企业信息管理系统支持MBSE及后续发展提供思路。

.2.

引言

自2007年国际系统工程协会 (International Council on Systems Engineering, INCOSE) 发起基于模型的系统工程 (Model-based Systems Engineering, MBSE) 倡议后, 业界就开始不断尝试、探索并实践从传统上基于文档的系统工程 (Document-based Systems Engineering, DBSE) 向基于模型的系统工程转型之路。近年来, 随着人们越来越认可MBSE在大型、复杂系统/产品全生命周期过程中的应用潜力, MBSE开始在全球范围内受到广泛关注。由于MBSE的重要性与日俱增, 近年来系统工程界、工业界和工具界都开始探索更好的方法、手段和技术来实现系统全生命周期的模型管理。目前,关于产品生命周期管理(Product Lifecycle Management, PLM) 对模型管理的支持以及与MBSE的集成是国际系统工程界研究的热门主题。INCOSE就模型管理专门成立了工具集成与模型生命周期管理工作组 (Tools Interoperability and Model Lifecycle Management Working Group, TIMLM WG) , 旨在从数据交换标准层面上促成系统工程工具的集成和互操作,进而为模型生命周期管理奠定良好的信息交互环境。INCOSE德国分会PLM4MBSE工作组的研究主题也是PLM与MBSE的集成。它们认为, 传统系统工程主要在产品开发的早期应用, 与后续的产品开发、制造和维护阶段的PLM数据脱节, 而模型在更大范围的工程应用需要将MBSE和PLM结合, 在整个系统全生命周期内实现基于模型的开发与管理,也就是基于模型的工程(Model-based Engineering, MBE) , 这将是物联网和“工业4.0”的“赋能器”。当前, 大多MBSE最佳实践活动都基于系统开发早期(即概念设计阶段)开展,且对象管理组织(Object Management Group, OMG) 的系统建模语言Sys ML已成为事实上的架构模型描述标准被广泛采用。但详细设计阶段, 各专业领域所用的具体工具不尽相同, 有产品生命周期管理、应用生命周期管理 (Application Lifecycle Management, ALM) 、需求管理、仿真环境、项目管理、计算机辅助设计 (Computer Aided Design, CAD) 、计算机辅助工程 (Computer Aided Engineering, CAE)、电子自动化设计 (E-lectronics Design Automation, EDA) 等。

本文介绍了支持MBSE的模型生命周期管理(Model Lifecycle Management, MLM)的相关概念与关系, 分析了3类典型企业信息管理系统现状并提出了解决方案, 通过分析给出了几点启示与建议,可为企业信息管理系统更好地支持MBSE提供思路。

.3.

模型管理与MBSE,PLM的关系

3.1、模型与模型管理的概念

“模型”是指对某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式。在系统工程领域,“模型”就是使用可以被模型创建者及模型使用者充分理解的建模语言所表达的某一“事物”。每个模型可以表达系统不同方面 (如系统架构、结构设计以及性能分析等) 的信息。用同样的建模语言来表达某一对象的过程就称为建模。

模型生命周期管理指在整个系统开发生命周期内, 对建模支持工具和模型库内的异构模型的创建、读取、更新和删除 (Create, Retrieve, Update, Delete, CRUD) 操作保持同步的管理过程, 通过对模型配置项的管理来实现, 具体包括模型版本、变体 (variant) 、配置和基线、仿真分析结果以及分布在不同地理位置的多个用户所使用的工具。此外, MLM还包括对与模型、工具和分析结果 (包括谁更改了模型、更改的内容、时间和原因) 相关的所有元数据以及与模型应用情况有关的信息进行管理。模型生命周期管理系统 (Model Lifecycle Management System, MLMS) 是实施模型生命周期管理过程的一组要素, 包括人员、硬件、软件、数据和过程。

3.2、模型管理与MBSE、PLM的关系

MLM要解决的问题是建模信息随时间的同步, 以确保被建模系统全生命周期内的模型一致性。首先, MLM必须支持不同用户开发的不同类型模型, 这些模型通常分布在不同地方, 并且使用不同的开发工具。其次, 从模型得出的其他信息 (例如分析结果和模型查询结果) 必须与生成这些信息的模型保持同步。最后, 必须考虑到对产品簇和系统变体的模型管理, 这些模型之间有大量共性的方面, 只需要增加一些特定功能就可以满足不同客户的不同需求。

作为模型管理系统所要管理的对象, 模型的概念和基于模型的设计方法实际上在嵌入式软件、电子、机械与测试工程领域已应用多年, 只是各自独立设计、单独管理, 相互之间很少产生信息交互关系。而随着现代信息物理系统越来越呈现高度集成、融合的多学科特点, 其复杂度和性能要求越来越高。与此同时, 企业所面对的业务挑战越来越严峻, 如更短的上市时间、严格的安全性要求、更高的质量要求以及更加严苛的合规性等。这些因素驱使工程领域的创新者们开始考虑在系统设计中使用建模、抽象和多学科分析技术, 构建对系统定义的共同理解并利用模型代替传统系统工程中的文档作为系统设计依据和主要工件, 实现系统级的多学科协同设计, 于是便出现了MBSE概念。

“模型”是MBSE的核心所在, 每个模型可以表达系统不同方面 (如系统架构、结构设计以及性能分析等) 的信息。如今, 随着系统复杂性的不断提高以及全球市场需求的多样性,人们越来越认识到MBSE在系统全生命周期中的应用潜力。为了充分发挥MBSE的作用与潜力, 需要将系统建模和MB-SE作为基于模型的大型工程项目的必要组成部分, 并与系统生命周期中其他工程学科模型和建模活动有机结合。这就对模型生命周期管理提出了迫切的需求。

在整个产品生命周期中, 将概念设计直到产品回收期间所产生的信息都在一个通用环境中进行管理是基本的要求, 但是, MBSE方法和工具本身并不具备模型管理能力。就现今的PLM系统而言,也没有实现这样的要求,它只是对来自于机械、电气和软件工程领域的不同工作成果进行管理, 并且这些成果在逻辑上也没有建立任何依存关系。尽管PLM系统声称是现代跨学科虚拟产品开发的支柱, 但事实上它对非机械领域或跨学科开发的支持力度仍然较弱。于是业界提出, 需要PLM系统能够将产品整体视为一个多学科系统, 提供对MBSE结构和工件 (artifact) 的管理。今后, PLM系统也要从以文档为中心向逻辑上互连的工件转变。

MBSE与PLM的关系如图1所示。

Fig.1 Relationship between MBSE and PLM

.4.

当前企业信息管理系统现状

根据目前大型工业企业MBSE实践的经验, 为了实现贯穿系统全生命周期的多学科无缝追踪追溯,最关键也最有挑战的就是对各类、各种模型的全生命周期管理。多年的实践表明, 尽管目前的MBSE实践可以通过具有含义的模型来表达系统或产品的功能架构, 实现基于模型的系统架构设计, 但缺乏对整个系统生命周期各类模型进行管理的能力和手段。这也是MBSE当前实践大多停留在系统概念阶段且仅在部分大型工业企业展开而没有被大规模采用的主要原因之一。

MLM涵盖广泛的模型和工件, 需要解决管理、业务、可用性、功能性和性能各方面的问题, 而各企业的现状及部署MLMS时所面临的挑战和需要解决的重点也各不相同。本节将对产品开发生命周期中采用了MBSE技术的3类企业的信息管理系统现状进行总结。

4.1、大型复杂消费品产品线制造商

这类企业的特点是有大量可选的产品变体和软件驱动的特征 (如“大规模可定制”机电一体化产品),在设计和构建这类复杂产品线中模型发挥着越来越重要的作用。系统级模型正成为将软件和硬件设计工件结合在一起的“粘合剂”,为产品线定义奠定基础。在产品线工程中, 通过将模型元素与支持各种变体配置的模型连接关系进行组合, 可快速实现满足一系列要求的设计与制造。

这类产品的实现中, 越来越多地通过自动代码生成或模型驱动的制造系统将模型直接转化为实际的软件或硬件组件。因此, 要求模型必须能体现产品可变性的多个维度, 而模型管理系统需要提供相应的支持。

在这类企业中, 现有的信息管理系统的支持能力如下:首先, 目前所用的大多数PLM系统具备对产品变体的管理能力, 但它们与建模工具的集成度有限, 这主要是由于缺乏支持这种集成的标准以及明确的建模语言;其次, 从产品变体的角度看,由于PLM系统的前身是擅长处理复杂CAD数据的产品数据管理 (Product Data Management, PDM) 系统, 因此PLM系统对软件和系统级模型的支持度比对CAD模型的支持要弱;最后, 尽管ALM系统也开始具备产品线能力, 但ALM系统采取以软件为中心的视角解决问题, 一直无法与硬件或系统设计方法相匹配。

综上所述, 目前, 这类企业的信息管理系统对系统级模型的管理缺乏有效的工具来支持。在这种复杂产品线工程中, 手动方式和其他有效的模型变体配置方法已达到其应用极限, 如果不具备强大的模型管理能力, 则难以在整个产品线生命周期内的任意时刻快速获取所有模型的正确配置, 来执行某个产品变体的大规模设计、仿真与制造。

4.2、大型复杂防务系统集成商

这类企业的特点是关注模型管理中建模工具的集成和上下游的协作问题, 希望通过协作的方式对实物系统的集成功能和性能进行虚拟化验证。这两个方面的实现都和基础标准的广泛应用有关。

在建模工具集成方面, 企业当前的主要困境在于如何对各类工具作出正确的投资选择。为了做出更好的投资决策模型, 需要对未来的能力和未来的成本作出准确预测。只有各类标准越来越全面且被广泛认可, 且行业成员对模型的未来应用越来越有信心后, 才能决定在最合适的工具上增加投资。

而良好的协作也与标准化程度有关, 标准化程度越高, 协作可能性越强。例如, 与建模实践、模型架构 (model schemas) 、模型质量检查规则等相关的内部标准是组织内协作的第一步。随着各类标准被各公司及其客户和供应链采用, 为系统数据的进一步协作奠定了能力基础。在认识到标准的重要性后, 必须对继续使用目前不完善标准的成本和采用新标准的价值不断地进行对比评估, 综合权衡后再作出实施决策。

这类企业实施模型管理首先需要对纳入管理范围的模型的类型、控制范围以及管理方法进行明确和规范, 进而选择可以解决核心问题的行业标准加以实践。在这一过程中, 为了获取更大的市场份额, 供应商会倾向于推广其所用的标准, 但它并不一定做好了随时应对系统真实部署的准备, 最终还是要靠企业自身多加实践。

4.3、大型航空航天、防务、安全系统制造商

这类企业的特点是通常采用多种建模工具来解决系统模型不同方面的问题, 包括UML或Sys ML工具、分析工具、数据管理工具以及其他支持工具 (如源代码管理工具、缺陷管理工具、工作流程工具和需求管理工具) 。但这些特定建模工具自身不具备版本控制机制, 而是通过提供与多种配置管理工具的接口来实现模型管理。由于模型库本身是一组文件, 因此, 这种方式是可行的。

对于系统模型, 企业利用Sys ML建模工具创建系统模型, 并将物理模型存储为一组文件, 每个文件代表一个配置项,文件的颗粒度可以通过建模工具的属性来配置,通常会规定“包”级别的配置项颗粒度。在软件开发时,可以在更低级别上(例如对象类)开展工作。在规定配置项级别后, 需要确定文件系统物理结构。可以选择一个分层级的文件系统来存储物理模型, 层级关系反映逻辑模型的包层次结构;也可以选择扁平化的文件系统, 其中, 无论逻辑模型采用哪种包结构, 配置项都存储在同一个目录中。

目前, 这类企业的做法是以一种尽量减少并行检出需求的方式组织这些配置项, 以最大限度减少模型合并的需求。此外, 这类企业希望模型管理系统能提供全面的需求追踪追溯能力, 而需求通常位于单独的需求管理工具中, 因此, 还必须解决需求条目与模型内容间的同步。

.5.

支持MBSE的企业信息管理系统解决方案

5.1、模型存储机制解决方案

5.1.1、多个本地存储库方法

这种方法是默认的, 也是模型管理中最常见的方法。在该方法中, 单个团队或者集团/组织内部多个团队的成员通过个人计算机或共享驱动器的文件系统来存储他们开发的模型。许多情况下, 逻辑存储库和物理存储库是相同的, 都是本地存储区的一部分。

这种方法通常没有正式的版本控制, 对模型历史的跟踪通过识别模型文件上的时间戳变化来实现;即使应用了正式的版本控制, 执行过程也可能是高度手动的, 不容易被完全遵守。这种方法利用电子邮件或共享驱动器通过文件传输实现团队内部和团队之间的模型共享, 模型更新后仅作临时性通知或根本不进行通知, 对设计模型与分析模型或相应的分析结果之间的跟踪有限。

对于那些不太需要模型管理的系统模型, 可将多个本地存储库方法与其他方法结合使用。例如, 可以通过多个版本控制模型库控制设计模型, 但并不覆盖分析模型 (或模型分析结果) 。

5.1.2、单个版本控制的模型库方法

在该方法中, 团队或者组织选择具有正式版本控制的单一存储库来管理所有不同类型的模型, 如需求、架构、CAD、CAE、软件、部件库等。这意味着, 单个物理模型库可能被映射到为多个团队、项目或工程领域服务的多个逻辑存储库。

在大多数现代企业中, 由于产品开发涉及多学科设计工件, 通常, 每类存储库用于管理特定类型的模型, 如用于CAD、CAE和物料清单 (Bill of Material, BOM) 的PLM系统、用于软件代码的源代码管理系统、用于大量实例数据集合的数据库、用于供应链信息的企业资源规划 (Enterprise Resource Planning, ERP) 系统等。因此, 普遍认为将所有信息都整合到一个单一存储库很难实现。

5.1.3、多个版本控制的模型库方法

与单个版本控制模型库方法相比, 该方法为模型管理提供了一个更好的机制。它允许不同的工程团队选择最适合的工具和存储库来管理其模型。每个存储库都提供正式版本控制, 大多数企业都有多个版本控制的存储库。

尽管采用这种方法可以更容易管理单个系统模型, 但在模型同步、通知和可追溯性方面则面临严峻挑战。由于各种模型被独立管理, 因此, 需要一种能实现对多个分布式模型资源的链接、跟踪、监视与报告的技术手段。

5.2、模型治理和安全解决方案

许多现代产品开发环境需要严格的安全性考虑。虽然在军事和防务应用中, 这是一个显而易见的要求, 但随着知识产权保护成为备受关注的问题, 现代消费电子产品、汽车、医疗设备等领域对安全性也提出了同样的要求。虽然模型生命周期管理系统通常位于由适当授权/认证机制 (例如轻量级目录访问协议) 保护的企业内部网中, 但并不足以实现有效的MLM治理。模型生命周期管理系统需要在不同颗粒度等级上管理模型安全性和访问权限, 因此, 除了企业内部网安全模型之外, 还需要其他机制。

在模型治理与安全性方面, 当前的解决措施如下:

(1) 无安全措施

单个用户拥有所有权限和内容, 对于周期短的小型项目而言, 这种方式是可以接受的, 但个体会成为模型或模型配置项更新和管理的瓶颈。

(2) OS认证

多用户OS访问限制, 内容无归属。对于小型静态团队来说, 如果建立并遵循程序化的模型治理机制, 那么, 这种方式是可接受的, 但对变更的不完整跟踪会导致变更原因总被质疑。在团队构成不断变化的情况下, 缺乏独立分配的访问控制会给信息安全保证带来风险。

(3) 轻量级目录访问协议 (Lightweight Directory Access Protocol, LDAP)

由外部服务器管理用户和访问, 内容无归属。由于这种方法提供了更好的机制来限制授权用户的访问, 因此, 它比前一种方式稍好些, 但该方法仍然需要程序化的模型治理机制。

(4) 内容变更管理

配置管理系统会对提交历史版本的人员进行跟踪, 但原子级操作不具名。这种方法中模型配置项变更记录的颗粒度更大, 对先前方法有了更好的改进。对于人员构成会随时间变化的大型多学科团队而言, 这种方法是必要的。

(5) 需要认证的基于角色的访问

原子级操作具名 (Atomic-level Attributability) 。原子级的访问控制、变更控制和具名可以实现最精确且可追踪的模型管理系统, 它允许以不同的模型元素颗粒度等级实现完整的模型安全。这种方法被认为是最先进的模型生命周期管理系统安全模型, 但实际上, 目前很少有系统能对此提供支持。

5.3 实现异构模型通信的新技术方向

由于现有的解决方案并不能完全满足MLM的要求, 各种可实现异构模型通信的新技术应用而生, 这些技术可以分为如下3类:

(1) 语言和数据表示

这一类技术为在异构工具和存储库中实现数据表示和通信的基础技术, 包括数据表示语言, 如XML、JSON、RDF、EXPRESS;数据操作/编程语言, 如Java、C++和Python;数据通信语言和协议, 如SOAP、WSDL和REST。通常, 一个建模/仿真工具以及模型库会支持一种或多种语言, 以实现它们所管理的信息/模型间的交互。

(2) 信息模式与本体

这一类技术包括基于标准的以及针对特定工具的信息模式 (或本体) , 为工具所管理的模型提供语义。本体可用于表达广泛的系统/产品, 如用于描述系统或体系架构的Sys ML/UPDM标准;特定的产品系列, 如分别用于表达机械和机电产品系列的10303 (STEP) AP203和AP210标准;产品信息的特定方面, 如用于表达基于方程的行为模型的Modelica、用于表达产品几何结构/拓扑的STEP Part 42、用于表达需求的STEP AP233和需求交换格式RIF或ReqIF、用于表示动态仿真模型的功能样机接口 (Functional Mock-up Interface, FMI) 以及用于表达全生命周期信息的PLCS (Product Life Cycle Support) 和生命周期协作开放服务 (Open Services for Lifecycle Collaboration, OSLC) 等标准和规范。

(3) 工具和特定存储库接口

这一类技术包括适用于建模/仿真工具和存储库的各种应用程序编程接口 (Application Programming Interface, API) 。由API提供连接、查询和导入/导出模型和模型要素的服务。API基于某种语言和方法开发 (如上述第一类技术) , 并且可以支持开放式标准 (如上所述第二类技术) 以满足不同等级的一致性要求。这类API接口示例包括用于Teamcenter的SOAAPI和用于Windchill、PLM系统的Info*Engine API、STEP模型绑定的通信语言Java和C++SDAI等。

在上述现有解决方案和新兴技术中, 对MLM而言, 目前最紧迫的是缺乏可以与商用现货建模和仿真工具及存储库实现信息交互的完整的API或标准的/自定义的元模型。

.6.

启示与建议

MLM的实现是一个宏大而宽泛的课题, 它对企业采用MBSE作为主流系统工程实践而言至关重要。随着现代系统设计中MBSE实践的不断推进, 模型生命周期管理系统将成为端到端设计和开发工具链的重要组成部分。与数据库、源代码配置管理、产品生命周期管理以及企业内容管理一样, 模型生命周期管理系统也将被企业视为一项“必须具备的”能力。

6.1、基于行业标准实现工具链集成

工具链集成是模型生命周期管理的一部分。研发生产中各类IT基础设施的互操作是实现产品数字化开发的关键。为了确保工具的互操作性并避免供应商的封锁,这些工具必须基于国际认可的标准实现。如面向服务的架构(Service-oriented Architecture, SOA) 已经展现出其通过工具链集成整合部分IT解决方案的潜力, 而生命周期协作开放服务已被许多供应商支持, 用于实现工具的集成。

6.2、确保PLM与其他学科专用管理系统的互通和协作

尽管PLM有望成为跨学科产品管理的支柱, 但它无法取代各学科专用的管理系统 (如ALM) 。因此, 必须确保PLM和这些专用系统的互通和协作。目前, 这类相似系统都在试图整合彼此的功能, 它们的共存对IT系统间的互操作性提出了更高的要求。因此, 在异构IT环境下, 强烈需要对联邦式系统方法提供支持。这意味着, 要尽量通过各类专用的IT解决方案 (如PLM、ALM、ERP) 之间的协作、互通来共同完成跨学科的产品生命周期管理, 而不是试图将其他系统的解决方案都整合到某一个系统中。

6.3、需要进行深刻的组织变革

为了在组织内实现基于模型的工程, 除了新工具和方法外, 还需要进行深刻的组织变革。迄今为止, 在开发团队中还没有系统工程师角色的企业不仅需要聘请一些具备这一技能的人员,而且还需要确定新的角色和职责。ISO/IEC 15288为此提供了一个很好的指导:建立所谓的“集成产品开发团队” (Integrated Product Development Team, IPDT) , 在该团队中, 系统架构师负责系统总体概念设计, 同时协调其他开发团队。但与任何其他基本的组织变革相同, 从传统泰勒型组织向这种协同式的系统工程转变相当困难。因此, 必须做好充分的准备和支持, 而通常中间过程会花费相当长的时间。

.7.

结语

MLM当前所面临的各种挑战需要通过企业内部甚至业界的共同努力来解决。在这一过程中, 企业信息管理系统建设需要充分利用相邻领域 (例如配置管理、产品生命周期管理和企业内容管理) 的当前实践和主题专家的经验, 消化吸收、避免错误, 加速推进MLM的实现。随着企业信息管理系统对MBSE的支持能力不断提高, 更多的企业将愿意采用MBSE作为企业级的最佳实践, 进一步形成良好的MBSE生态环境, 从而大力提升大型复杂系统的研发效率。

End