一种基于数据驱动的智能主模型管理系统
技术领域
本发明涉及智能主模型管理领域，特别涉及一种基于数据驱动的智能主模型管理系统。
背景技术
随着计算机技术、网络技术和通信技术的发展和应用，企业信息化管理已成为提高企业经营管理水平和核心竞争能力的重要保障。然而当前很多企业的研发项目管理模式还停留于传统的线下管理，然而传统研发管理系统往往存在以下问题：
1.过程数据缺乏有效管理
目前实施很多的PDM系统，仅解决了产品研发阶段性结果数据的电子化集中存储与管理。数据管理的全面性、完整性不够，尚缺乏对研发过程数据(需求、设计、仿真、实验)的统一管理，且各个应用系统间的集成和数据交互度低，无法实现过程数据的有效共享、高效交换，研发过程的可重复性、可追溯性不高。
2.需求信息、技术指标难以追溯
产品需求的分解和变更贯穿了整个产品生命周期。而目前的需求信息主要依靠文档管理，需求信息缺乏结构化，无法与产品研发数据建立紧密的关联关系，两者的版本间缺乏有效的一致性管理，从而导致产品研发无法及时响应需求变更所带来的变化，无法为局部需求变更对整体研发所带的影响进行快速、准确的分析和评估，难以对需求符合性进行有效追踪。信息和指标变更的响应性、维护性和可跟踪性较低。
发明内容
本发明旨在至少解决现有技术中存在的技术问题，特别创新地提出了一种基于数据驱动的智能主模型管理系统。
为了实现本发明的上述目的，本发明提供了一种基于数据驱动的智能主模型管理方法，包括以下步骤：
S1，利用登录界面登录系统；
S2，利用登录界面登录系统后，在系统内进行相应的操作。
进一步地，在步骤S2中包括以下步骤：
S21，提交数据包：需要指定所依据的上游数据包版本；且每次数据提交操作都会触发一次版本更新；
S22，对专业数据包进行数据审批：
S23，对专业数据包进行谱系管理：
S24，进行专业协同；
所述数据提交操作可以同时包括多个对象，操作方式可以是新增、修改、删除、更名其一或者任意组合；
所述对象包括：文件和/或目录；
所述目录包括：模型和/或专业数据包；
所述版本更新包括：操作对象的版本号末尾+1，同时所有上级目录的版本号也+1。
进一步地，所述S21还包括：
采用“锁定-解锁”机制：版本更新之前需先锁定对象，锁定的对象只有解锁后才能允许其它人提交新的版本；锁定和解锁操作通过人工执行或自动执行；若只有一人有写权限时，则提交时自动锁定；当提交成功后，系统自动解锁。
进一步地，所述S22包括：
S2-1，判断提交的专业数据包的上游数据包是否有效；若上游数据包的审批状态为无效，则提交的专业数据包为无效，不能进入审批流程；若上游数据包的审批状态为有效或者审批中，则进入审批流程，执行下一步骤；
S2-2，判断是否是同一专业的专业数据包，若是，则可选的审批流程相同；
S2-3，判断提交的数据是否属于无需审批；若不是，则提交数据的用户可以选择审批流程；所述审批流程由数据区管理员针对专业指定。
进一步地，S3-1，判断专业数据包的版本是否为有效；若是，作为由系统自动判断技术状态的变化；
S3-2，判断专业数据包其上游的专业数据包的技术状态是否均为最新，并且其最新有效版本也是基于上游最新有效版本创建的；则专业数据包的技术状态为最新；
S3-2，判断专业数据包的技术状态是否为过时，若是，则其下游的专业数据包的技术状态均为过时；
S3-3，判断专业数据包的技术状态是否为待更新，若是，则需将本身技术状态置为待更新；
S3-4，判断专业数据包的技术状态是否属于从过时到最新的状态变化，若是，则其下游所有专业数据包的技术状态都自动置为过时。
进一步地，所述S24包括：
S4-1，创建协同数据区：
S4-2，多专业协同：
S4-3，客户端获取数据：
S4-4，客户端提交数据；
S4-5，技术状态检查；
所述S4-5包括：
S4-5-1，谱系追踪：设计师选择数据包，指定任意一个版本，查看其上下游的谱系信息，可以追踪到任意多层；
S4-5-2，技术状态一致性检查：设计师对三种技术状态进行标注，在目录树或在谱系视图上进行标注。
进一步地，所述S4-1包括：
S4-1-1，创建数据区：数据区管理员进行数据区初始化工作，所述数据区初始化工作包括：编辑数据区的目录结构、定义数据区内需要协同的专业、加入参与项目的人员之一或者任意组合；
S4-1-2，创建主模型：数据区管理员从外部导入一个主模型模板，进行主模型初始化工作，所述主模型初始化工作包括：修改主模型信息、修改目录结构、修改数据包谱系、指定数据包负责人之一或者任意组合；
或/和所述S4-2包括：三个专业数据包谱系关系为：第一专业数据包是第二专业数据包的上游数据包，第二专业数据包位于第一专业数据包的下游，第三专业数据包位于第二专业数据包的下游；
S4-2-1，专业数据包初始化：
初始化主模型：数据区管理员建立主模型并初始化，包括对主模型的目录结构和/或专业数据包的编辑修改，默认初始版本号为1；
启动主模型：数据区管理员启动主模型，此时所有版本状态都置为有效，技术状态都置为最新；
S4-2-2，专业数据包正常更新：
第一专业数据包更新：第一设计师上传一个新的专业数据包，版本不变，版本状态为自动置为无效；由于变化的是非有效版本，所以技术状态不变；然后进入审批流程，审批通过后，版本+1且审批状态置为有效，由于没有上游数据包，故技术状态变更为有效；
由于第一专业数据包的最新有效版本由V1变为V2，所以第二专业数据包的技术状态自动置为待更新；由于上游的第一专业数据包的最新有效版本由V1变为V2，所以第三专业数据包的技术状态自动置为过时；
第二专业数据包更新：第二设计师上传一个新的第二专业数据包，同时选择第一专业数据包的版本是V2，审批流程为“无需评审”；系统将上传的第二专业数据包版本置为V3，并将版本状态置为有效，技术状态置为最新；由于第二专业数据包发布了新版本，并且其上游的第一专业数据包和第二专业数据包都是最新状态，所以第三专业数据包的技术状态自动置为待更新；
第三专业数据包更新：上传一个新的第三专业数据包，同时选择基于上游的第一专业数据包版本是V2、第二专业数据包版本是V3，审批流程为“无需评审”；系统将上传的第二专业数据包版本置为V3，并将版本状态置为有效，技术状态置为最新；
S4-2-3，撤回已发布数据：
第一专业数据包更新：第一设计师上传一个新的第一专业数据包，审批流程为“无需评审”；系统将上传的第一专业数据包版本置为V2，并将版本状态置为有效，技术状态置为最新；由于第一专业数据包的最新有效版本由V1变为V2，所以第二专业数据包的技术状态自动置为待更新；由于上游的第一专业数据包的最新有效版本由V1变为V2，所以第三专业数据包的技术状态自动置为过时；
无效更新：第一设计师将最新的第一专业数据包V2版本手工置为无效，技术状态不变，但对应的版本由V2变为V1；由于第一专业数据包的最新状态由V2版本变为V1版本，而第二专业数据包最新的有效版本V1就是基于总体的V1版本进行设计的，所以技术状态自动恢复为最新；第三专业数据包与第二专业数据包一样，技术状态恢复为最新；
S4-2-4，无需更新声明：
第一专业数据包更新：第一设计师上传一个新的第一专业数据包，审批流程为“无需评审”；系统将上传的第一专业数据包版本置为V2，并将版本状态置为有效，技术状态置为最新；由于第一专业数据包的最新有效版本由V1变为V2，所以第二专业数据包的技术状态自动置为待更新；由于上游的第一专业数据包的最新有效版本由V1变为V2，所以第三专业数据包的技术状态自动置为过时；
无需更改：第一专业数据包更新的内容对第二专业数据包的设计没有影响，无需更改，由第二设计师在系统中进行无需更改声明，重新走审批流程，通过后技术状态自动置为最新；在第二专业数据包通过审批后，版本同步更新为V2，内容不变；
S4-2-5，向上游反馈消息：
第一专业数据包更新：第一设计师上传一个新的第一专业数据包，审批流程为“无需评审”；系统将上传的第一专业数据包版本置为V2，并将版本状态置为有效，技术状态置为最新；由于第一专业数据包的最新有效版本由V1变为V2，所以第二专业数据包的技术状态自动置为待更新；由于上游的第一专业数据包的最新有效版本由V1变为V2，所以第三专业数据包的技术状态自动置为过时；
反馈消息：第一专业数据包更新的内容会导致第二专业数据包的性能无法满足，对第一专业数据包的新版本通过版本注释的方式进行反馈，也可以提交第二专业数据包相应的计算数据之后反馈；第一设计师看到反馈消息后，重新调整了第一专业数据包，上传一个新的版本；第二设计师根据第一专业数据包的新版本重新设计。
进一步地，所述S4-3包括：
S4-3-1，同步远程数据：设计师创建一个本地目录，使用客户端工具将远程数据区的内容同步到本地，也可以查询和下载任意历史版本的数据；
S4-3-2，浏览查询数据：设计师在数据区的任意目录下，可以进行关键词查询、属性查询、参数值查询中的任一操作，对于TXT或/和PDF特定类型的数据文件可以进行预览，对于参数可以在线绘图显示。
进一步地，所述S4-4包括：
S4-4-1，提交本地数据：设计师提交一个文件或目录，如果系统判断出与远程最新版本有冲突，则需要人工解决冲突后才允许上传；上传的时候，需要指定基于上游哪个版本进行的更新，再选择审批流程；此时新版本的状态默认为无效；
审核人员对提交的数据进行审批，通过后版本状态置为有效；
S4-4-2，技术状态更新：技术状态的判断由系统自动进行。
本发明还提供了一种基于数据驱动的智能主模型管理系统，其特征在于，包括：
协同数据区、主模型、谱系关系、专业数据包、数据项；
协同数据区包括：型号项目的基本信息、项目团队，协同数据区对应一个型号项目，一个协同数据区包含不同设计阶段的多个主模型；
所述项目团队包括项目人员、项目角色、项目权限；
主模型包括：型号方案的基本信息、谱系关系、专业角色；一个主模型对应一个型号方案，一个主模型包含多个专业数据包；
所述谱系关系用于表示专业数据包的上下游关系，主模型通过谱系关系驱动设计活动；一个主模型对应一套谱系关系，谱系关系不允许跨主模型；
专业数据包包括：目录、文件、所属专业；一个专业数据包对应一套相关专业数据文件，一个专业包含多个专业数据包，专业数据包不允许跨专业；
数据项包括：一个专业数据包包含多个数据项，一个数据项对应一个数据文件；
所述数据文件包括：文本、图片、报告、表格之一或者任意组合。
综上所述，由于采用了上述技术方案，本发明的有益效果是：减少了专业之间数据交换成本，提高了协同的效率，使专业之间的谱系关系更加清晰，有助于保证迭代过程中技术状态的一致性。
本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：
图1是本发明的管理系统示意图；
图2是本发明应用场景示意图；
图3是本发明协同原理示意图；
图4是本发明创建协同数据区示意图；
图5是本发明三个专业数据包谱系关系示意图；
图6是本发明数据包初始化后三个专业数据包的示意图；
图7是本发明数据包正常更新示意图；
图8是本发明撤回已发布数据示意图；
图9是本发明无需更新声明示意图；
图10是本发明向上游反馈消息示意图；
图11是本发明客户端获取数据示意图；
图12是本发明客户端提交数据示意图；
图13是本发明技术状态检查示意图；
图14是本发明数据存储策略示意图；
图15是本发明版本演变过程示意图；
图16是本发明“锁定-解锁”机制示意图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。
2.1基本概念
如图1所示，智能主模型管理系统包括：协同数据区、主模型、谱系关系、专业数据包、数据项；
协同数据区包括：型号项目的基本信息、项目团队、下级目录，协同数据区对应一个型号项目，一个协同数据区一般包含不同设计阶段的多个主模型。
主模型包括：型号方案的基本信息、下级目录、谱系关系、专业角色；一个主模型对应一个型号方案，一个主模型一般包含多个数据包。
谱系关系包括：用于表示专业数据包的上下游关系，谱系关系是协同设计的依据，主模型通过谱系关系驱动设计活动。一个主模型对应一套谱系关系，谱系不允许跨主模型。
专业数据包包括：目录、文件、所属专业。一个专业数据包对应一套相关专业数据文件，一个专业会包含多个数据包，数据包不允许跨专业。
数据项：专业数据包中的一项数据内容，是版本管理的最小粒度，一个数据项对应一个数据文件，文件类型可以是文本、图片、报告、表格等等。另外在本系统中还定义了一种特殊文件格式——标准格式参数文件(.param)，一个参数文件中包含了一个或多个参数组，在Oracle数据库中，这些参数将被抽取出来另外以结构化方式存储，以提高数据查询分析的效率。
2.2基本原则
一、数据提交原则
1.每次提交操作都会触发一次版本更新，操作可以同时包括多个对象，操作方式可以是新增、修改、删除、更名。
2.版本的管理对象为文件和目录(主模型和数据包为特殊目录)，初始版本号为1；
3.每次版本更新，操作对象的版本号+1，同时所有上级目录的版本号也+1；
4.采用“锁定-解锁”机制，版本更新之前必须先锁定，锁定的对象，只有解锁后才能允许其它人提交新的版本。锁定和解锁操作可以人工执行，也可以自动执行。当只有一人有写权限时，提交时自动锁定；当提交成功后，系统自动解锁。
二、数据审批原则
1.数据审批的对象为数据包；
2.提交数据的用户可以选择可用的审批流程，有哪些审批流程可选由数据区管理员针对专业指定，其中也包括有一项特殊的审批流程为“无需审批”。同一专业的数据包，可选的审批流程也一样，为此需要在提交时限制同一批提交的数据包必须属于同一专业；
3.数据包有三种审批状态：无效-提交数据包但未启动审批流程；审批中-审批流程正在执行；有效-通过审批后被视为有效数据。
4.用户可以指定当前提交的版本是基于上游数据包的哪个版本创建的，默认是上游的最新版本，如上游数据包本身为无效，则本数据包只能是无效，不能进入审批流程，也不能选择“无需审批”选项。
三、谱系管理原则
1.谱系管理的对象为数据包，谱系定义了数据包之间的上下游关系；
2.数据包有三种技术状态：最新、过时、待更新。技术状态只针对数据包最新的有效版本而言，只有有效版本的变化才会触发技术状态更新，技术状态的变化都由系统自动判断，不允许人工修改；
3.最新状态的数据包，其上游数据包技术状态必须都是最新，并且其最新有效版本也是基于上游最新有效版本创建的；
4.过时状态的数据包，其下游数据包技术状态也只能是过时的；
5.待更新状态的数据包，如上游数据包技术状态都是最新，则表示设计过程已运转到本专业，需将本身技术状态置为待更新；
6.在用户提交数据包时，需要指定所依据的上游数据包版本；
7.数据包从过时到最新的状态变化，称为数据包的发布，当一个数据包发布时，其下游所有数据包状态都自动置为过时；
2.3应用场景
如图2所示，包括：
管理员，其职责是：1.部门、用户的创建和维护。2.系统的日常维护，包括统的安装、重启。3.用户权限的分配。
数据区管理员，其职责是：1.数据区的创建和维护。2.主模型的导入和初始化。
3.定义数据区内的专业划分。
专业设计师，其职责是：1.在专业权限内，查看自身负责的数据包和相关专业的数据包。2.在专业权限内，提交数据包。
专业审批人员，其职责是：在专业权限内，审批专业设计师提交的数据包，一般为专业组长或室领导。
2.4协同原理
如图3所示，在总体设计业务流程中，涉及到气动、结构、动力、弹道、制导、控制等领域，是复杂的多学科任务，由总体给出设计指标，经过多轮的专业级和系统级设计迭代，形成最终的总体方案。在基于智能主模型的数字化协同设计环境中，产品设计的核心数据采用智能主模型表达，同时智能主模型也是专业之间交换数据的媒介。相对于传统的设计方式，智能主模型减少了专业之间数据交换成本，提高了协同的效率，使专业之间的谱系关系更加清晰，有助于保证迭代过程中技术状态的一致性。
2.4.1创建协同数据区
协同数据区管理员的活动及操作如图4所示。
角色：协同数据区管理员
活动：创建协同数据区，创建主模型实例
2.4.2多专业协同场景
令三个专业的数据包谱系关系如图5：
数据包的状态信息有版本状态和技术状态两类，版本状态针对每个上传的数据版本，有无效、审批中、有效三种状态；技术状态只针对每个数据包的最新有效版本，有最新和过时两种状态。两者组合可以完成对技术状态的完全追溯。
一、数据包初始化
数据包初始化的具体情况如图6所示。
角色：数据区管理员
二、数据包正常更新
数据包正常更新的具体情况如图7所示。
角色：总体设计师，气动设计师，弹道设计师
三、撤回已发布数据
撤回已发布数据的具体情况如图8所示。
角色：总体设计师，气动设计师，弹道设计师
四、无需更新声明
无需更新声明的具体情况如图9所示。
角色：总体设计师，气动设计师，弹道设计师
五、向上游反馈消息
向上游反馈消息的具体情况如图10所示。
角色：总体设计师，气动设计师，弹道设计师
2.4.3客户端获取数据
客户端获取数据的具体情况如图11所示。
角色：设计师
活动：同步远程数据，浏览查询数据
2.4.4客户端提交数据
客户端提交数据的具体情况如图11所示。
角色：设计师，审核人员
活动：提交本地数据，技术状态更新
2.4.5技术状态检查
技术状态检查的具体情况如图12所示。
角色：设计师，数据区管理员
活动：谱系追踪、技术状态一致性检查
2.5关键技术
2.5.1数据存储策略
如图13所示，版本库是系统的基础模块，通过抽象的节点来建立数据之间的逻辑结构，并基于节点实现通用的版本控制功能，节点可以关联文件。节点的基本类型有目录和文件，在主模型模式下，还可以扩展为主模型、数据包、数据项。即使将来主模型的结构发生变化，通过抽象的节点也能够灵活适应。
系统采用Oracle数据库与文件服务器相结合的存储策略，属性、参数等结构化数据使用Oracle数据库存储，数据文件、文档等非结构化数据使用文件服务器存储。
2.5.2版本管理机制
如图14所示，版本控制是系统的关键功能，为了满足主模型版本管理和谱系追踪的要求，参考了SVN的版本控制原理，实现版本信息的存储和记录、本地数据区与远程数据区的同步、历史版本的追溯等功能。
版本控制需要同时支持B/S和C/S两种架构，在C/S客户端，需要进行本地数据区与服务器的同步，并且在提交数据时能够对当前数据是否基于最新版本修改进行检查。B/S客户端由于没有本地数据区，不能进行版本检查，只能默认为用户是基于最新版本进行的修改。
版本的演变遵循以下规则：
1.版本号为整数，初始为1，每更新一个版本自动+1，在一个版本库内，版本号永远是递增的；
2.文件和目录都有版本号，每次文件的版本更新，其所有的上级目录也同时更新，版本号与文件一致；
3.文件和目录的创建、删除、更名都要进行版本记录；
4.同一次提交操作包含多个的对象的修改，则记录同一个的版本号；
5.如发生多人同时修改的情况，先提交的版本正常更新，后提交的需要人为解决冲突后再提交；
6.复制文件/目录，原文件/目录的版本号不变，副本的版本号继续增加。复制操作不占用新的存储空间，只有修改后才进行存储；
如图15所示，举例说明版本的演变过程：
为了多人同时修改一个对象文件发生的冲突，系统采用“锁定-解锁”的机制，如图16所示，具体要求如下：
1.操作人在提交数据之前必须先对操作对象进行锁定操作；
2.为了简化锁定操作，在只有一人有写权限时，则锁定操作可由系统自动完成，无需人工干预；
3.锁定的对象，操作人只有进行了解锁操作之后，其它人才能进行锁定；
4.当提交数据成功后生成新的版本，系统可以自动解锁；
5.具有写权限的人都可以看到对象的锁定状态，包括锁定的时间、锁定的操作人等；
2.5.3谱系管理机制
数据包的谱系定义了数据包的上下游关系，为设计过程的演变和追踪提供依据。
谱系关系的定义应遵守以下原则：
1.谱系关系定义的对象为数据包整体，不关心具体的数据内容之间的关系；
2.任何一个数据包都可以定义一个或多个上游数据包和下游数据包；
3.不允许出现数据包谱系的循环定义，比如A>B>C>A；
4.谱系关系只在主模型内部定义，不允许跨主模型定义；
5.为了保证历史版本追溯的有效性，在主模型启动后，只允许新增谱系关系，不允许修改和删除已有的谱系关系。
由于谱系关系是一种多对多的关系，所以在数据库存储时，需要单独建立一张谱系关系表。以图5的谱系关系为例，记录谱系关系存储的内容如下。
ID
MODEL_ID
UP_ID
DOWN_ID
1
所属主模型的ID
总体数据包的ID
气动数据包的ID
2
所属主模型的ID
总体数据包的ID
结构数据包的ID
3
所属主模型的ID
气动数据包的ID
结构数据包的ID
技术状态由系统自动根据谱系关系和数据的最新有效版本进行判断，规则如下：
最新：上游数据都为最新，并且当前有效版本基于的上游版本也是最新有效的；
待更新：上游数据包都为最新，但当前有效版本基于的上游版本不是最新有效；
过时：上游数据包有过时或待更新的。
尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。
