协同设计方法及电子设备与流程

1.本发明涉及计算机辅助设计技术领域，具体涉及协同设计方法及电子设备。


背景技术：

2.在一个完整的建筑设计项目过程中会牵涉到比较多的相关专业，其中最常规的专业包括建筑、结构、给排水、暖通、电气。在一些复杂的项目中甚至还有一些设计专项，在这么多的专业之间需要在同一个项目之间能够达到高效的工作产值和上下游信息传递的准确性，需要有一个能够帮助设计师在项目下可以多人协同设计的工作模式。
3.目前已有的协同设计软件，大致有以下三种工作模式：(1)基于中心文件的协作模式，该模式在文件较大的情况下的卡顿问题；(2)项目下多人协作模式，需要事先划分各自的设计内容；(3)设置图层并指定用户，但是在大模型处理时模型缩放性能有极大的影响。


技术实现要素：

4.有鉴于此，本发明实施例提供了一种协同设计方法、装置及电子深，以解决模型的协同设计的问题。
5.根据第一方面，本发明实施例提供了一种协同设计方法，应用于设计端，所述方法包括：
6.获取目标工作单元；
7.响应于对所述目标工作单元中目标构件的协同设计，向服务端发送协同设计请求，以确定所述目标构件是否锁定；
8.当所述目标构件未锁定时，获取所述服务端基于所述协同设计请求确定的所述目标构件的关联构件；
9.加载所述关联构件并对所述关联构件进行关联设计，确定协同设计结果。
10.本发明实施例提供的协同设计方法，在协同设计时仅需要针对目标工作单元即可，而不需要加载完整的目标模型，保证了数据交互的实时性；且基于构件级的协同设计方法，从协同设计上突破文件与文件之间的隔阂，将协同的颗粒度降为构件级，使得数据与数据之间的连接不再局限在某一个文件中，便于实时共享设计结果，且在协同设计过程中同时对关联构件也进行关联设计，实现了同步更新，提高了协同设计效率；通过确定目标构件的锁定情况，可以减少协同工作过程中的权限审批流程，提高易用性。
11.结合第一方面，在第一方面第一实施方式中，所述获取目标工作单元，包括：
12.显示工作单元选择界面；
13.响应于对所述工作单元选择界面的选择操作，确定当前工作单元以及所述当前工作单元的参照工作单元；
14.加载所述当前工作单元以及所述参照工作单元，确定所述目标工作单元。
15.本发明实施例提供的协同设计方法，工作单元之间也存在关联关系，即参照与被参照的关系，通过在加载当前工作单元的同时也一并加载对应的参照工作单元，可以在避
免下载完整模型的同时保证协同设计的可靠性。
16.结合第一方面第一实施方式，在第一方面第二实施方式中，所述加载所述当前工作单元以及所述参照工作单元，确定所述目标工作单元，包括：
17.判断本地是否缓存有所述当前工作单元或所述参照工作单元；
18.当本地没有缓存所述当前工作单元或所述参照工作单元时，从所述服务端加载所述当前工作单元或所述参照工作单元，以确定所述目标工作单元。
19.本发明实施例提供的协同设计方法，在加载目标工作单元时首先从缓存中进行加载，即通过保留中间建模结果，可以避免从服务端再次加载时的数据下载过程，提高了协同设计的效率。
20.结合第一方面，在第一方面第三实施方式中，所述加载所述关联构件并对所述关联构件进行关联设计，，确定协同设计结果，包括：
21.获取所述目标构件以及所述关联构件的当前协同设计结果；
22.将所述当前协同设计结果与对应的历史协同设计结果进行比较，确定增量设计结果；
23.存储所述增量设计结果，以在预设条件下上传至所述服务端。
24.本发明实施例提供的协同设计方法，协同设计结果采用增量提交，即只提交部分变更过的构件，加快数据提交保存的效率。
25.结合第一方面第三实施方式，在第一方面第四实施方式中，所述存储所述增量设计结果，以在预设条件下上传至所述服务端，包括：
26.更新所述目标构件以及所述关联构件对应的工作单元的版本号；
27.存储所述版本号，以在预设条件下上传至所述服务端。
28.本发明实施例提供的协同设计方法，在构件进行更新时，仅更新构件对应的工作单元的版本号，并不对服务端的工作单元进行修改，可以保证其他设计端的参照工作单元的稳定，同时通过版本号可以获取历史快照。
29.根据第二方面，本发明实施例提供了一种协同设计方法，应用于服务端，所述方法包括：
30.接收设计端发送的目标构件的协同设计请求；
31.基于所述协同设计请求确定所述目标构件的协同设计是否锁定；
32.当所述目标构件的协同设计未锁定时，基于构件间的关联关系，查询所述目标构件相关的关联构件；
33.下发所述关联构件，以使得设计端对所述关联构件进行关联设计确定协同设计结果。
34.本发明实施例提供的协同设计方法，基于构件级的协同设计方法，从协同设计上突破文件与文件之间的隔阂，将协同的颗粒度降为构件级，使得数据与数据之间的连接不再局限在某一个文件中，便于实时共享设计结果，且在协同设计过程中同时对关联构件也进行关联设计，实现了同步更新，提高了协同设计效率；通过确定目标构件的锁定情况，可以减少协同工作过程中的权限审批流程，提高易用性。
35.结合第二方面，在第二方面第一实施方式中，所述方法还包括：
36.接收所述设计端发送的当前工作单元的选择请求，确定所述当前工作单元；
37.根据工作单元的关联关系，查询所述当前工作单元对应的参照工作单元；
38.将所述当前工作单元以及所述参照工作单元下发至所述设计端。
39.本发明实施例提供的协同设计方法，工作单元之间也存在关联关系，即参照与被参照的关系，通过在加载当前工作单元的同时也一并加载对应的参照工作单元，可以在避免下载完整模型的同时保证协同设计的可靠性。
40.结合第二方面，在第二方面第二实施方式中，所述方法还包括：
41.接收所述设计端上传的增量设计结果；
42.基于所述增量设计结果确定对应的存储数据库，以对所述增量设计结果进行存储。
43.本发明实施例提供的协同设计方法，通过将增量设计结果存储至对应的存储数据库中，以便于发挥不同类型的存储数据库的优势，保证存储效率。
44.根据第三方面，本发明实施例还提供了一种电子设备，包括：
45.存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行本发明第一方面，或第一方面任一实施方式，或者，本发明第二方面，或第二方面任一实施方式中所述的协同设计方法。
46.根据第四方面，本发明实施例还提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使计算机执行本发明第一方面，或第一方面任一实施方式，或者，本发明第二方面，或第二方面任一实施方式中所述的协同设计方法。
47.根据第五方面，本发明实施例还提供了一种协同设计系统，包括：
48.至少一个设计端，用于执行本发明第一方面，或第一方面任一项实施方式中所述的协同设计方法；
49.服务端，所述至少一个设计端连接，所述服务端用于执行本发明第二方面，或第二方面任一实施方式中所述的协同设计方法。
50.关于本发明实施例中电子设备、计算机可读存储介质以及协同设计系统的有益效果，请参见上文协同设计方法中的对应描述，在此不再赘述。
附图说明
51.为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
52.图1是根据本发明实施例的协同设计系统的结构示意图；
53.图2是根据本发明实施例的电子设备的结构示意图；
54.图3是根据本发明实施例的协同设计系统的设计架构示意图；
55.图4是根据本发明实施例的协同设计系统的数据交换方案的示意图；
56.图5是根据本发明实施例的协同设计方法的流程图；
57.图6是根据本发明实施例的协同设计方法的流程图；
58.图7是根据本发明实施例的协同设计方法的流程图；
59.图8是根据本发明实施例的协同设计方法的流程图；
60.图9是根据本发明实施例的分布式存储架构的示意图；
61.图10是根据本发明实施例的协同设计装置的结构框图；
62.图11是根据本发明实施例的协同设计装置的结构框图。
具体实施方式
63.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
64.本发明实施例提供了一种协同设计系统，如图1所示，该系统包括至少一个设计端10以及服务端20，至少一个设计端10与服务端20连接。其中，设计端用于基于构件级的协同设计，服务端20用于响应于设计端的协同设计并对协同设计的结果进行存储以保证各个设计端所采用的工作单元的版本统一。其中，服务端20所连接的设计端10的数量，可以根据实际需求进行设置，在此对其并不做任何限定。
65.关于设计端10以及服务端20的具体功能将在下文中进行详细描述。
66.本实施例提供的协同设计系统，通过提供一种bim项目下基于构件级的多人协同的设计模式，通过构件级协同，把数据从文件文档中解析出来，解决数据黑洞的问题，把设计师的设计数据在项目中真正的流转及关联起来，实现真正的无缝协作，让设计师能够在项目中共享设计数据并互相引用协作。其中，所述的构件级协同是一种在一个bim项目下能够通过针对单个或多个构件的使用权限的获取，并且可以局部按需加载项目下的他人设计数据，并保持关联更新，从而达到项目下多人协同工作。
67.进一步地，设计端10以及服务端20可以统称为电子设备，图2是本发明可选实施例提供的一种电子设备的结构示意图，如图2所示，该电子设备可以包括：至少一个处理器201，例如cpu(central processing unit，中央处理器)，至少一个通信接口203，存储器204，至少一个通信总线202。其中，通信总线202用于实现这些组件之间的连接通信。其中，通信接口203可以包括显示屏(display)、键盘(keyboard)，可选通信接口203还可以包括标准的有线接口、无线接口。存储器204可以是高速ram存储器(random access memory，易挥发性随机存取存储器)，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器204可选的还可以是至少一个位于远离前述处理器201的存储装置。其中存储器204中存储应用程序，且处理器201调用存储器204中存储的程序代码，以用于执行上述任一方法步骤。
68.其中，通信总线202可以是外设部件互连标准(peripheral component interconnect，简称pci)总线或扩展工业标准结构(extended industry standard architecture，简称eisa)总线等。通信总线202可以分为地址总线、数据总线、控制总线等。为便于表示，图2中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
69.其中，存储器204可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：ram)；存储器也可以包括非易失性存储器(英
文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(英文：hard disk drive，缩写：hdd)或固态硬盘(英文：solid-state drive，缩写：ssd)；存储器204还可以包括上述种类的存储器的组合。
70.其中，处理器201可以是中央处理器(英文：central processing unit，缩写：cpu)，网络处理器(英文：network processor，缩写：np)或者cpu和np的组合。
71.其中，处理器201还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，缩写：asic)，可编程逻辑器件(英文：programmable logic device，缩写：pld)或其组合。上述pld可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：cpld)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：fpga)，通用阵列逻辑(英文：generic array logic,缩写：gal)或其任意组合。
72.可选地，存储器204还用于存储程序指令。处理器201可以调用程序指令，实现如本技术任一实施例中所示的协同设计方法。
73.如上文所述，本发明实施例中的协同设计系统包括设计端以及服务端，将服务端部署在云端，使得该协同设计系统从设计架构上而言为一个端+云的平台。如图3所述，对于服务端而言，可以划分为3层设计，即api层、应用层以及数据存储层。
74.具体地，数据存储层表达了云端数据的存储结构，数据是通过数据库的各种关系表存储的。例如，构件数据表用于存放构件数据，包括：构件id，构件版本，构件几何数据，构件属性等。工作单元表用于存放工作单元数据，包括：工作单元id，工作单元版本，构件列表等。
75.应用层包括权控模块、协同模块以及数据模型，权控模块中的数据权限主要是针对数据安全的设计，内部定义了在不同场景下的数据是否允许访问。协同模块通过构件协同锁和消息机制有效的管控数据修改和数据访问的秩序，也负责解决同时修改构件数据引起的冲突。数据模型对接数据存储结构，管理着数据的内存模型，包括：项目、构件、工作单元、子项、版本管理、构件关系和索性搜索等核心数据对象。
76.api层通过数据模型和协同模型相关的调用接口提供了数据模型存储和协同能力，体现了易用性同时保证兼容性。
77.对于设计端而言，其可能是协同数据的生产者，也可能是协同数据的消费者，其主要通过ap层提供的数据存储和协同能力来实现自己的业务逻辑。从功能上可以划分为设计工具、web平台、碰撞检测及其他，其中，设计工具通过数据协同来完成复杂的设计，同时也把设计数据上传到了平台。web平台通过协同数据来展示3d场景和管理工程数据。碰撞检测是一个典型的基于协同数据的第三方应用，通过碰撞检测算法来分析构件在3d空间是否会产生碰撞。
78.该协同设计系统需要云端和涉及端的组件一起来完成多人系统的设计模式，云端的关键组件有权限控制中心、消息中心、构件关系搜索、构件属性搜索、项目级数据管理、工作单元管理。具体地，权限控制中心组件负责项目内构件权限的管理，用户只有申请到构件权限，才能进行进一步的编辑或者删除操作。权限控制中心的集中控制，保证了项目内同时最多只有一个人申请到构件的修改权限。用户完成修改后，进行提交，同时释放权限。
79.消息中心组件负责接受设计端的消息，根据消息性质的不同，进行单播或者广播；
推送服务端发生、需要用户感知的状态变化。其中，典型的消息有：在协同过程中，某个设计端推送了模型修改数据，其它设计端可以收到模型更新信息；若端1对构件的权限进行归还，所有者会收到已归还消息；管理员或者某个设计端修改了项目级配置，推送到云端之后，服务端会将消息广播到所有端。
80.消息中心组件还负责管理消息流转状态，例如某些设计端在消息发送时未上线，在下次上线时，云端负责将中间发生的消息补发到该设计端上。
81.构件关系搜索组件负责提供基于构件关系的快速搜索的引擎。构件是节点，构件之间的关系是边，整个关系形成一张有多个非连通有向图组成的大图，存储在云端。该组件提供查询对象之间关系是否存在、查询某个节点相关的节点等服务；并且在构件和构件间关系发生变化时，能快速重建关系。
82.构件属性搜索组件，负责提供按照某些属性，查询符合条件的构件的服务。这些关键、通用属性包括但不限构件的id、所属工作单元、构件类别等等。
83.项目级数据管理组件，其职责是管理项目级的公共的配置。这些配置需要在项目初始化的时候设置好，以便后续新建工作单元时引用这些数据，或者加载到共工作单元内使用。应对修改需求，项目级数据的修改需要有特殊权限，应设计成不是每个参与项目的成员都有权限。同时，这些修改应该在项目范围内发生作用，端上的工作单元应该根据云端项目配置数据，在合适的时候更新本地的引用或数据。因此还需要设定项目级数据的版本，并根据其内在涵义，在项目的同一个时刻，所有工作单元用的版本应该是相同的。典型的配置有标高、轴网、定位子项等等。
84.工作单元管理组件，其存在的目的是为了在构件之外，存储并管理工作单元之间的关系。工作单元之间，存在参照和被参照的关系，这些关系可能还有嵌套。比如一个工作单元，可以参照多个其它工作单元，在下次用户打开此工作单元时，同时打开被参照的工作单元。用户每次提交，使得工作单元的版本增加，此版本的作用在于1)保持参照的稳定；2)获取历史快照。例如，设计端a以及设计端b均参照工作单元c，若在设计端a对工作单元c进行了修改，此时工作单元c的版本号变更；但是，对于设计端b而言，在显示时仍保持原始工作单元c，在设计端b需要对工作单元c进行修改时，才会利用版本号对工作单元c进行更新，从而保证所有设计端参照的稳定。
85.对于设计端而言，其管件组件有建模引擎、缓存、数据转换传输。建模引擎组件，负责完成工作单元的加载、构件的显示、编辑，是设计数据主要的产生来源和使用方。缓存组件负责存储修改过下次需要提交的构件，在端上中断编辑后，下次打开工作单元首选从缓存中载入过程模型，即保留了用户的中间建模成果，又避免了从云端再次加载时的数据下载过程。数据转换传输组件，负责将建模引擎生成的模型数据，转化为可以存储、传输的格式，在端上计算和网络资源空闲的时候，上传到云端，或者用同步的方式，等待上传成功。加载模型的时候，如果数据未在本地缓存中，先从云端下载，转换格式化后，放入缓存，供建模引擎使用。这些格式要确保在不同的端之间能够互相识别，这些设计端上的建模工具，可能是同一个专业的，也可能是不同专业的。
86.为了进一步说明上述的协同设计系统，下面结合数据交换方案对其进行进一步描述。例如，图4示出了协同设计系统的一种可选的数据交换示意图。从实现架构上可以分成五层：产品平台或者工具层、建模平台层、协同平台转换层、协同平台sdk层，数据协同平台。
其中，产品平台或工具层主要负责生产数据，建模平台层负责管理数据，协同平台转换层负责数据间的转化，协同平台sdk层负责数据缓存和数据传输，数据协同平台负责数据加工和数据存储。
87.1)数据上传：经过产品平台或者工具端生成出的bim模型数据后，通过协同平台转换器机制，把平台的bim模型数据转换成数据平台要求的格式化数据，然后再通过协同平台sdk传输到数据协同平台，数据协同平台获取到bim数据后，进行云端数据存储。为了实现加速效果，在设计端会建立数据缓存机制，把变更的数据采取增量的方式缓存到本地和采用增量的方式把数据上传到协同数据平台。
88.2)数据下载：设计端通过api发起获取bim数据后，根据协同平台数据管理等机制从云端数据库中提取数据，经过网络传输设计到端上，然后通过协同平台的转换器机制，把数据协同平台格式化数据反流成建模平台能识别的bim模型数据，最后把数据加入到建模平台模型层，设计端通过建模平台管理数据机制，达到识别数据能力。
89.3)权限机制：在协同操作模式下，为了防止数据冲突，数据的修改是通过权限方案解决。当构件获取到修改锁权限后，则允许修改，否则不允许修改。修改数据前时，需要设计端通过api接口从数据协同平台中获取到锁权限。其中，该锁权限用于表征当前构件是否被锁定，即是否有其他设计端占用该构件，以保证同一时刻仅有一个设计端占用该构件。
90.在下文中将分别从设计端以及服务端详细描述具体的协同设计方法。
91.根据本发明实施例，提供了一种协同设计方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
92.在本实施例中提供了一种协同设计方法，可用于上述的设计端，图5是根据本发明实施例的协同设计的流程图，如图5所示，该流程包括如下步骤：
93.s11，获取目标工作单元。
94.设计端在针对目标bim项目进行协同设计时，仅需要加载相应的目标工作单元即可，而不需要加载完整的目标bim模型。这是由于在服务端会基于设计端所协同设计的构件进行关联关系的查询，确定出与该构件具有关联关系的关联构件，以实现关联设计。基于此，对于设计端而言，在设计时仅需要加载其关系的目标工作单元即可。
95.目标工作单元可以是基于需求从服务端获取到的，例如，在设计端提供有选择界面，用户在该界面进行选择，即可加载相应的目标工作单元。或者，当用户需要某一个目标工作单元时，可以先在本地进行搜索，确定本地是否缓存有该目标工作单元，若缓存有该目标工作单元，则直接从本地获取即可。
96.关于该步骤具体将在下文中进行详细描述。
97.s12，响应于对目标工作单元中目标构件的协同设计，向服务端发送协同设计请求，以确定目标构件是否锁定。
98.设计端提供有人机交互方式，用户通过在设计端的人机交互功能对目标工作单元中目标构件进行协同设计。例如，当用户需要对目标工作单元中的目标构件a进行协同设计时，设计端向服务端发送对于目标构件的协同设计请求，以确定目标构件是否锁定。
99.具体地，如上文所述，为了保证构件版本的统一，在同一时刻仅允许一个用户对同
一构件进行修改。服务端采用上述的协同设计锁对各个构件是否锁定进行监控，当构件被某一设计端占用修改，那么在服务端将该构件对应的协同设计锁设置为锁定；当构件被某一设计端释放，那么在服务端将该构件对应的协同设计锁设置为未锁定。基于此，当服务端接收到设计端发送的针对目标构件的协同设计请求时，服务端通过查找目标构件对应的协同设计锁，即可确定目标构件是否被锁定。当目标构件被锁定时，服务端可以下发提示消息，该目标构件被锁定不可修改，也可以通过其他方式提醒设计端的用户，当前目标构件不可修改。
100.s13，当目标构件未锁定时，获取服务端基于协同设计请求确定的目标构件的关联构件。
101.在服务端确定出目标构件未被锁定时，其搜索出目标构件的关联构件。结合图3所示的设计架构的描述，在服务端存储有构件数据表，为了该构件数据表能够被快速访问，通过构件关系搜索组件实现。即，在数据进行存储时，将其存储为主数据以及索引数据。其中，主数据即可对应于各个数据表，索引数据即为将主数据同步到搜索引擎，通过搜索引擎提供的搜索能力进行主数据的搜索。对应到此处的关联构件的搜索，将构件关系表同步到构件关系搜索组件，利用该构件关系搜索组件提供基于构件关系的快速搜索的引擎，以实现关联构件的快速搜索。
102.服务端在确定出目标构件的关联构件时，将该关联构件下发，相应地，设计端即可获取到该关联构件。
103.s14，加载关联构件并对关联构件进行关联设计，确定协同设计结果。
104.设计端在获取到关联构件之后，在本地加载该关联构件，在对目标构件进行协同设计的同时，对该关联构件进行关联设计。在协同设计过程中，实现了按需加载，保证了目标bim项目中各个构件的联动更新。此处的关联构件可以是其他工作单元中的，对于设计端而言，由于在服务端通过关联构件的搜索，使得即使在没有加载完整的bim模型的情况下，也能够对关联构件进行一并设计。
105.本实施例提供的协同设计方法，在协同设计时仅需要针对目标工作单元即可，而不需要加载完整的目标模型，保证了数据交互的实时性；且基于构件级的协同设计方法，从协同设计上突破文件与文件之间的隔阂，将协同的颗粒度降为构件级，使得数据与数据之间的连接不再局限在某一个文件中，便于实时共享设计结果，且在协同设计过程中同时对关联构件也进行关联设计，实现了同步更新，提高了协同设计效率；通过确定目标构件的锁定情况，可以减少协同工作过程中的权限审批流程，提高易用性。
106.在本实施例中提供了一种协同设计方法，可用于上述的设计端，图6是根据本发明实施例的协同设计的流程图，如图6所示，该流程包括如下步骤：
107.s21，获取目标工作单元。
108.具体地，上述s21包括：
109.s211，显示工作单元选择界面。
110.当用户需要对目标bim项目进行协同设计时，进入协同界面，相应地，在设计端显示工作单元选择界面，以供用户进行工作单元的选择。通过工作单元选择界面，以使得在设计端能够按需加载相应的工作单元，而不需要从服务端先加载完整的目标bim模型，在此基础上再进行协同设计。
111.s212，响应于对工作单元选择界面的选择操作，确定当前工作单元以及当前工作单元的参照工作单元。
112.用户在该工作单元选择界面进行选择，例如，在工作单元选择界面可以按系统类型，按类别等方式进行过滤参照，系统类型和类别等定义成了bim标准数据，通过bim标准数据机制，从协同平台数据库中筛选出来，确定当前工作单元以及当前工作单元的参照工作单元，实现按需加载场景。对于某一个工作单元而言，其通过需要参照其他工作单元进行设计，其自身也可能被其他工作单元参照。因此，在对当前工作单元进行设计时，需要选定参照类型或类别发送给服务端，服务端依据参照类型或类别进行筛选，确定出当前工作单元的参照工作单元。
113.s213，加载当前工作单元以及参照工作单元，确定目标工作单元。
114.服务端在确定出参照单元之后，将其与当前工作单元一并下发给对应的设计端，相应地，设计端即可加载当前工作单元以及参照工作单元。对于设计端而言，将当前工作单元以及参照工作单元称之为目标工作单元。其中，上文所述的目标构件可以是当前工作单元中的构件，也可以是参照工作单元中的构件，在此对其并不做任何限定。
115.在本实施例的一些可选实施方式中，上述s213可以包括：
116.(1)判断本地是否缓存有当前工作单元或参照工作单元。
117.设计端先在本地的缓存中进行当前工作单元或参照工作单元的搜索，以减少从服务端重复加载相应工作单元的过程。当本地没有缓存当前工作单元或参照工作单元时，执行步骤(2)；否则，执行步骤(3)。
118.(2)从服务端加载当前工作单元或参照工作单元，以确定目标工作单元。
119.(3)从本地加载当前工作单元或参照工作单元，以确定目标工作单元。
120.即，优先从本地进行相应工作单元的加载，只有在本地不存在该工作单元，或该工作单元的版本需要更新时，才从服务端进行加载或更新。
121.在加载目标工作单元时首先从缓存中进行加载，即通过保留中间建模结果，可以避免从服务端再次加载时的数据下载过程，提高了协同设计的效率。
122.s22，响应于对目标工作单元中目标构件的协同设计，向服务端发送协同设计请求，以确定目标构件是否锁定。
123.详细请参见图5所示实施例的s12，在此不再赘述。
124.s23当目标构件未锁定时，获取服务端基于协同设计请求确定的目标构件的关联构件。
125.详细请参见图5所示实施例的s13，在此不再赘述。
126.s24，加载关联构件并对关联构件进行关联设计，确定协同设计结果。
127.具体地，上述s24包括：
128.s241，获取目标构件以及关联构件的当前协同设计结果。
129.s242，将当前协同设计结果与对应的历史协同设计结果进行比较，确定增量设计结果。
130.在设计端将当前协同设计结果与构件对应的历史协同设计结果进行比较，确定出当前是对哪些部分进行的修改，进而确定出变化的部分，即增量设计结果。
131.s243，存储增量设计结果，以在预设条件下上传至服务端。
132.设计端在本地存储有增量设计结果，可以在网络空闲或预定时间将其上传至服务端。其中，预设条件可以为网络空闲或预定时间。
133.在本实施例的一些可选实施方式中，上述s243可以包括：
134.(1)更新目标构件以及关联构件对应的工作单元的版本号。
135.(2)存储版本号，以在预设条件下上传至服务端。
136.在设计端对目标构件以及关联构件进行相应的修改之后，对目标构件以及关联构件对应的工作单元的版本号进行更新，保存该版本号及其对应的修改后的工作单元。同样地，设计端在预设条件下将存储的内容上传至服务端。如上文所述，存储版本号而并不是直接对相应的工作单元进行更新，其目的在于保证其他设计端的参照工作单元的稳定。
137.在构件进行更新时，仅更新构件对应的工作单元的版本号，并不对服务端的工作单元进行修改，可以保证其他设计端的参照工作单元的稳定，同时通过版本号可以获取历史快照。
138.本实施例提供的协同设计方法，工作单元之间也存在关联关系，即参照与被参照的关系，通过在加载当前工作单元的同时也一并加载对应的参照工作单元，可以在避免下载完整模型的同时保证协同设计的可靠性。协同设计结果采用增量提交，即只提交部分变更过的构件，加快数据提交保存的效率。
139.在本实施例中提供了一种协同设计方法，可用于上述的设计端，图7是根据本发明实施例的协同设计的流程图，如图7所示，该流程包括如下步骤：
140.s31，接收设计端发送的目标构件的协同设计请求。
141.该步骤与上文图5所示实施例中的s12对应，当设计端需要对目标构件进行设计时，发送协同设计请求，相应地，服务端即可接收到该协同设计请求。
142.s32，基于协同设计请求确定目标构件的协同设计是否锁定。
143.如上文所述，服务端内通过协同设计锁确定各个构件当前是否被占用的情况。在服务端接收到协同设计请求之后，针对目标构件的标识进行检索，确定出目标构件对应的协同设计锁，基于协同设计锁的状态，确定目标构件的协同设计是否被锁定。
144.s33，当目标构件的协同设计未锁定时，基于构件间的关联关系，查询目标构件相关的关联构件。
145.在未锁定时，服务端通过搜索引擎在构件间的关联关系中进行搜索，查询目标构件相关的关联构件。该步骤与图5所示实施例的s13对应，详细请参见图5所示实施例的s13，在此不再赘述。
146.s34，下发关联构件，以使得设计端对关联构件进行关联设计确定协同设计结果。
147.该步骤与图5所示实施例的s14对应，详细请参见图5所示实施例的s14，在此不再赘述。
148.本实施例提供的协同设计方法，基于构件级的协同设计方法，从协同设计上突破文件与文件之间的隔阂，将协同的颗粒度降为构件级，使得数据与数据之间的连接不再局限在某一个文件中，便于实时共享设计结果，且在协同设计过程中同时对关联构件也进行关联设计，实现了同步更新，提高了协同设计效率；通过确定目标构件的锁定情况，可以减少协同工作过程中的权限审批流程，提高易用性。
149.在本实施例中提供了一种协同设计方法，可用于上述的设计端，图8是根据本发明
实施例的协同设计的流程图，如图8所示，该流程包括如下步骤：
150.s41，接收设计端发送的当前工作单元的选择请求，确定当前工作单元。
151.对应于图6所示实施例的s21，设计端向服务端发送当前工作单元的选择请求，在选择请求中不仅包括有当前工作单元的标识，还包括有参照工作单元的筛选条件。
152.s42，根据工作单元的关联关系，查询当前工作单元对应的参照工作单元。
153.服务端在接收到选择请求之后，可以基于工作单元的关联关系，查询到对应的参照工作单元。其中，关联关系是基于相应的筛选方式建立的，例如，基于系统类型、类别等分别建立相应的关联关系。
154.s43，将当前工作单元以及参照工作单元下发至设计端。
155.该步骤与图6所示实施例的s213对应，详细请参见s213的描述，在此不再赘述。
156.s44，接收设计端发送的目标构件的协同设计请求。
157.详细请参见图7所示实施例的s31，在此不再赘述。
158.s45，基于协同设计请求确定目标构件的协同设计是否锁定。
159.详细请参见图7所示实施例的s32，在此不再赘述。
160.s46，当目标构件的协同设计未锁定时，基于构件间的关联关系，查询目标构件相关的关联构件。
161.详细请参见图7所示实施例的s33，在此不再赘述。
162.s47，下发关联构件，以使得设计端对关联构件进行关联设计确定协同设计结果。
163.详细请参见图7所示实施例的s34，在此不再赘述。
164.本实施例提供的协同设计方法，工作单元之间也存在关联关系，即参照与被参照的关系，通过在加载当前工作单元的同时也一并加载对应的参照工作单元，可以在避免下载完整模型的同时保证协同设计的可靠性。
165.作为本实施例的一种可选实施方式，上述的协同设计方法还可以包括：
166.(1)接收设计端上传的增量设计结果。
167.(2)基于增量设计结果确定对应的存储数据库，以对增量设计结果进行存储。
168.该步骤与6所示实施例的s24对应，设计端先确定出增量设计结果，再在预设条件下将增量设计结果上传至服务端。服务端在接收到增量设计结果时，确定出其对应的存储数据库对其进行存储。
169.具体地，在服务端采用分布式存储架构将涉及数据存储在数据库中，该数据库的存储优势是数据的使用可以基于更小的粒度，并能提供搜索查询能力。其中，设计数据主要分为两类，一类是主数据，另一类是索引数据。
170.如图9所示，主数据包含专业模型、工作单元、构件和属性。主数据可以用三种数据存储技术来保存不同类别的数据，mysql保存专业模型和工作单元数据，其事务特性保障了并发一致性；hbase保存构件数据，构件数据量级为亿级别，hbase相对其他数据库在亿级别快速存取方面有很大优势，保障了数据的快速访问；obs保存文件型数据，对于大的几何、mesh、文件等数据保存在obs上。三个数据存储引擎的结合引入了并发的一致性问题，技术上通过mvcc(多版本并发控制)和悲观锁技术保障了数据存取满足acid的事务特性。
171.主数据中数据库的特点是读取速度快、一致性高，缺点是搜索能力差，为了弥补这个不足引入了两个搜索引擎支持搜索能力，将主数据同步到搜索引擎，通过elasticsearch
提供按照构件属性搜索构件的能力，通过图引擎提供按照关联关系搜索构件的能力。根据业务特点，将主数据与图引擎设计成cp系统，即强一致性，满足cap(c-一致性，a-可用性，p-分区容忍性)理论中的cp。将主数据与es设计成ap+base系统，即提供高可用性的基础上达到最终一致性。
172.通过将增量设计结果存储至对应的存储数据库中，以便于发挥不同类型的存储数据库的优势，保证存储效率。
173.在本实施例中还提供了一种协同设计装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
174.本实施例提供一种协同设计装置，如图10所示，应用于设计端，该协同设计装置，包括：
175.第一获取模块51，用于获取目标工作单元；
176.发送模块52，用于响应于对所述目标工作单元中目标构件的协同设计，向服务端发送协同设计请求，以确定所述目标构件是否锁定；
177.第二获取模块53，用于当所述目标构件未锁定时，获取所述服务端基于所述协同设计请求确定的所述目标构件的关联构件；
178.加载模块54，用于加载所述关联构件并对所述关联构件进行关联设计，确定协同设计结果。
179.本实施例还提供一种协同设计装置，如图11所示，应用于服务端，该协同设计装置，包括：
180.接收模块61，用于接收设计端发送的目标构件的协同设计请求；
181.确定模块62，用于基于所述协同设计请求确定所述目标构件的协同设计是否锁定；
182.查询模块63，用于当所述目标构件的协同设计未锁定时，基于构件间的关联关系，查询所述目标构件相关的关联构件；
183.下发模块64，用于下发所述关联构件，以使得设计端对所述关联构件进行关联设计确定协同设计结果。
184.本实施例中的协同设计装置是以功能单元的形式来呈现，这里的单元是指asic电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。
185.上述各个模块的更进一步的功能描述与上述对应实施例相同，在此不再赘述。
186.本发明实施例还提供了一种非暂态计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的协同设计方法。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(read-only memory，rom)、随机存储记忆体(random access memory，ram)、快闪存储器(flash memory)、硬盘(hard disk drive，缩写：hdd)或固态硬盘(solid-state drive，ssd)等；所述存储介质还可以包括上述种类的存储器的组合。
187.虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明
的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。