而是项目信息的有序组织
CDE是国内BIM发展被忽略的一个名词
所以这篇文章聊一聊Common Data Environment
封面来源：gofore.com
本文约有9700字，阅读需要约35分钟
前言
本文写了很久，因为用一篇文章来讲明白CDE是什么的难度无异于用同样的篇幅讲明白BIM是什么。和BIM一样，CDE也可以用简单的一句话来概括，简单的名词与定义可方便技术的普及与推广，但也容易造成理解的误区。复杂的定义可以说明技术的本质，但也会让人感觉繁琐而远离这个技术。
在反复修改了很多次之后，我还是把这篇文章又写成了近万字的长文。但即使如此我感觉也没能描述清楚CDE是什么，因为比起技术，CDE更像是一种项目管理的意识形态。
– 01 –
CDE概述
如果翻阅世界主要国家的BIM标准，我们会发现这些标准对BIM的陈述都是围绕着Common Data Environment（CDE）展开：CDE在整个BIM的流程中占据核心的位置。
CDE在BIM的理论体系中是一个和IFC、LOD(LONI)等一样重要的名词，但在国内却很少被提到，甚至还没有统一的翻译。或者说国内一直有类似于“CDE”的表述存在，但还未形成像国外那样系统性的方法论、标准、产品体系。
CDE在BIM体系中的位置，图片来源:PAS 1192-2
国外的东西不代表就是好。但我觉得还是可以用一篇文章来系统性的聊一聊这个在BIM体系里非常重要但在国内却较少提及的Common Data Environment。
– 02 –
CDE发展史
像以前的文章一样，在正式介绍CDE前，我们简单介绍下CDE的发展史，看一看为什么会出现这个名词。
2.1 项目信息管理诉求
CDE出现的最大原因便是建设过程对项目信息管理的诉求：建筑是一个异常庞大而复杂的系统，涉及到的专业、参与和使用方众多，其生产过程中产生的信息庞大，而且这些信息随着建设、使用过程又是动态变化且需多方协调的。
建筑行业对信息管理的诉求
所以建筑行业一直在寻找一系列的方法，用来把生产过程的信息有效管理起来、提升信息使用和协作效率的方式，避免因信息偏差与错误造成的生产浪费。
2.2 方法的发展
这个探索的过程大致按照两个逻辑主线开展着：一个是信息与信息之间，一个是信息自身内部：
1、信息与信息之间：
这是我们广义理解的信息管理，大致的意思就是如何把项目的各类信息（文档）进行有效的归类、管理，以方便使用和协作。
在上个世纪60年代开始，欧美主要国家一方面开始用编码的方式对建筑生产对象进行分类、编号，例如每个材料、每个施工对象都有一个统一的编码；
感兴趣的同学可以继续阅读BIMBOX的《空间基因：建筑信息编码简史》，点击图片阅读原文，图片来源：BIMBOX
另一方面行业对建设过程所需生产的信息对象也进行规范化，例如把信息分为图纸、变更、方案、报告等。
这样一来，项目信息便形成了结构化的形式，不同管理人员更容易对信息进行检索、应用、协作、更新、维护。
文档分类与归类，图片来源：BIMBOX，点击图片阅读BIMBOX《空间基因：建筑信息编码简史》
2、信息自身内部：
除了信息与信息之间需要结构化的形式，信息里面的内容也需要同样的规范。
例如图纸：图纸与图纸之间可以通过结构化进行梳理，但是一张图纸内部本身也包含了大量信息，这些信息往往是更为重要的直接工程信息。为了更方便和准确的从一张图纸中获取工程信息，欧美主要国家也对信息里面内容的规范化做了大量工作。
还是以图纸为例，英国在1969年就发布了针对制图规范化的BS 1192:1969，即通过对图纸内容表达方式的统一，例如绘图原则、视图设置、注释等，确保各方能在同一个图形文件中快速、准确获取相同的信息。
BS 1192-1:1984,计算机制图规范,图片来源:BSI官网
随着商业计算机和CAD的出现，英国时隔15年后对1192进行了升级：在1984年发布了针对计算机制图而更新的BS 1192系列。随着计算机的进一步发展和三维CAD的流行，BS 1192在1990年进行了再次更新，对三维制图进行了规范。
同编码标准一样，除了英国以外的主流国家均有类似的标准发布。这些标准的本质都是对工程信息的主要来源：图形信息（graphic information）的自身内部信息结构进行规范统一。不仅图形信息，主要工程文档类型均有类似的管理标准，例如对特定文档的目录、包含内容、制式等。
3、信息管理的方法
长久以来，建设工程行业一直通过编码、文档等管理标准的集成应用，来对项目信息进行有序的组织和管理。这两条技术逻辑线与管理方法的融合，最后形成了像BS 1192-2007这样的标准，也就是CDE的形态。
本文后面将提到的BS 1192-2007便是编码、图纸、文档、流程标准的集成（参照本文第2.5节：CDE名称的出现）。考虑到BS 1192-2007是ISO 19650的前身，所以我们现在说的”BIM”其实在很久之前就以编码、制图规范、信息管理、标准化流程等形式存在了。
2.3 工具的发展
顺着方法的发展，行业对应的工具也顺应发展着。
一方面是生产信息的工具本身，这些工具除了自身开发的功能外，对标准的要求也做了大量的适配。例如CAD中的图层、注释等表达方式，制图构件库的分类、展示、以及编码、命名、信息录入等内置功能，都是为了更好地匹配当时的制图规范要求。
另一方面是针对信息与信息之间的管理，行业开始出现文档管理系统（DMS）。在没有计算机时，管理人员通过编码和便签对纸质文档进行有序归类，方便管理和查阅。计算机出现后，纸质文档开始逐步电子化。
没有计算机时的文档管理，图片来源：ViewPoint.com
随着电子文档的增多，文档管理系统开始出现，但这时的文档管理系统主要是把纸质文档管理的动作电子化，工作方式没有显著改变。
到了90年代初，随着独立商业网络的发展，电子文档的存储和传递方式开始逐渐丰富：网页、FTP、邮件、OA、各类存储载体等。这个时候，部分文档管理系统也开始反向对建筑行业工作流程的规范化提出要求，而一部分流程又被吸收到了前面所说的标准中。
ProjectWise前身TeamMate对文档的管理流程和包含内容，图片来源：Bentley Communities
其中比较有代表性的产品包括已经有40多年历史现在还广泛使用的ViewPoint、有30多年历史的TeamMate(ProjectWise前身)等。如果翻阅ViewPoint、ProjectWise等产品的历史文档，都还能找到对1192历史系列标准的支撑说明。
所以产品和方法一直是处于相辅相成的发展状态。
2.4 方法和工具的固化
随着时间的推移、技术的发展，关于工程信息管理的方法、标准、产品开始越来越融合。方法论和配套产品开始逐渐固化并细分。
首先，行业逐渐把项目信息类型做了对应的分类，不同的项目信息类型对应的管理方式也不同。BS 1192-5:1990开始将建筑信息分为了三大类：
-
图形信息(Graphic information):指二三维CAD、GIS等用数字方式表达空间位置和形状）
-
非图形信息(Non-graphic information,Documentation):我们广义理解的各类文档
-
数据(Data)：数字与数字等数据信息。
BS 1192-5: 1990(BS 1192:2007和ISO 19650-1的爷爷辈标准), 图片来源：BSI官网
其次，行业对不同信息类型的阶段做了区分：信息在不同阶段的管理方式是不一样的（可参考本文第3.3节：CDE工作场景）。
BS 1192对信息的4个阶段定义，图片来源：BS 1192:2007
与方法论配套的产品也在一直进化着，针对不同信息类型和不同阶段，开始有了产品区分（可参考本文第4.1节：CDE产品概述）。
因为内置了一系列标准化的支撑项目管理和信息管理的方法论，这些产品也和我们理解的传统网盘有了明显的区分 (很多人会误把CDE等同于网盘)。
2.5 CDE名称出现
随着时间推移到2007年，英国在这一年对BS 1192进行了再次升级，使其变成了广义的建设全过程的信息管理和协作标准：《建筑，工程和施工信息的协同生产-实务守则》（Collaborative production of
architectural, engineering and construction information. Code of practice）。
按照BS 1192:2007的导言，其内容涉及了以下几个标准：
-
ISO 82045-5 文档管理标准
-
ISO 12006-2 编码标准
-
ISO 13567-2 CAD制图规范
Common Data Environment (CDE)便是在BS 1192-2007中第一次被提及：BS 1192-2007把前面所提到行业几十年对项目信息管理所探索的方法、标准、工具囊括到了这个叫“CDE”的名词里。
BS 1192-2007对CDE的定义如下：CDE是一个确保项目各方信息源统一的方法。（A “Common Data
Environment” approach should be adopted to allow information to be
shared between all members of the project team.）。BS
1192-2007原文强调了 “Approach”，所以CDE是一个方法和过程，而不是一个单纯的平台。
2.6 BIM Level 2 / ISO 19650
CDE最早出现时并不是针对BIM的技术，但随着技术的发展，BIM逐渐成为项目信息的重要来源，加之英国又开始推动本土BIM标准的国际化，CDE开始逐渐成为BIM的底层技术。
拓展阅读：英国的BIM顶层设计，点击图片阅读原文
其实不止是英国，全球主要国家的BIM体系在发展中都出现了类似“CDE”形态的概念：即通过一系列的工具、方法、标准来对项目信息进行协作与管理。
美国早期BIM标准也在描绘类似于CDE的形态，图片来源：NBIMS v1.0
但随着BIM Level 2的强制令的推行，和英国BIM标准的国际化，英国所提出的“CDE”开始变成国际上广泛认可的一个名词：Autodesk，Bentley，Oracle等国际主流软件公司，均开始用CDE这个名词来描述其对应的信息管理产品。
CDE名词逐渐被国际接受，用来描述项目信息管理所对应的方法、标准和产品，图片来源：buildingSMART
– 03 –
Common Data
Environment
花这么多篇幅讲历史主要是为了说明两个论点：
1、CDE不是人造的技术，它是行业发展到一定阶段必然出现的产物：是几十年工程管理诉求和经验总结出来的方法论、产品和标准体系，只不过恰巧取了一个名字叫“CDE”。
2、大部分人对CDE的认知是一个网盘或者协同平台，但CDE不局限于此：一方面CDE针对不同应用场景需要不同的产品做支撑；另一方面，没有方法论、流程、标准的支撑，单纯的CDE产品体系发挥不了作用。
表达完这两个论点，开始正式进入到CDE的介绍。
3.1 CDE定义
其实和BIM一样，不同的人心目中对CDE有着不同理解与认知。按照CDE的起源和发展历程，ISO 19650对CDE的定义应该血统最正：在项目或资产管理中，对来自所有信息源信息的收集、管理、传递的过程。（Agreed source of information for any given project or asset, for
collecting, managing and disseminating each information container through a
managed process.）。
简而言之，CDE是项目在建设和运营阶段信息管理所需要用到的一系列方法和一系列工具。
简单的名词与定义可方便技术的普及与推广，但也容易造成理解的误区。越复杂的定义越能说明技术的本质，但也会让人越远离这个技术。所以这里简单又复杂地提炼几个CDE要点：
1、CDE作为BIM的基础性技术，并不代表只涉及BIM模型相关的内容，还包含文档、图纸、影像资料、数据等一切工程信息。实际上ISO 19650就是项目信息管理标准，国外现在把项目信息管理所涉及的动作都会归类到“BIM”里。
2、CDE对应的并不只是一个软件，就像“BIM”不是一个软件一样。CDE背后对应的是一个软件体系：不同类型的信息在不同管理阶段需要不同的软件做支撑。
3、CDE不止是软件，单纯的软件不能解决问题，需要有配套的方法，这个配套的方法与标准体系也是CDE的一部分。
3.2 CDE包含内容
1、首先CDE对项目信息类型进行了分类，顺着BS 1192-5:1990对项目信息的分类，ISO 19650将建设过程所涉及的信息分类进行了固化：
-
文档(Documentation):我们广义理解的各类文档，包括方案、日报、影像资料等，可以整体理解为工程电子资料；
-
几何/图形信息(Geometrical Information):二三维CAD、BIM、GIS等图形信息
-
数据信息(Alphanumerical Information):所有用数字和字母表达的信息，也就是数据。
项目信息类型分类，图片来源：ISO 19650-1
2、其次，CDE对信息所处的阶段进行了分类，每种工程信息的生产与应用都包含了4个阶段：
工作状态(Work in Progress):信息在自身手中编辑工作时的状态；
共享状态(Shared):信息共享给其他人进行协作编辑、审核时的状态；
发布状态(Published):信息的里程碑版本，正式从一个团队手上移交给其他团队的状态；
存档状态(Archive):里程碑文件的存档，供未来回溯查阅使用。
项目信息生产和应用过程中的4个阶段，图片来源：ISO 19650-1
3、CDE定义了不同类型的信息在不同阶段的管理方法
三类工程信息在四个阶段的管理会涉及到不同的工具，同时也会涉及到不同的管理流程与要求，例如从一开始的EIR到BEP，再到其中的Data
Segration & Federation、MPDT、TIDP、MIDP、编码、MetaData(元数据)、Attributes(数据)等，都是CDE管理所涉及的方法。
CDE的项目信息管理流程，图片来源：PAS 1192-2
与CDE相关的配套支撑工作,图片来源:PAS 1192-2
为了避免这篇文章太过复杂(其实并不复杂，复杂的是英文单词)，本篇文章将跳过对这些名词的阐述，先从工具与工作场景对CDE进行解释。未来JoyBiM会对ISO
19650以及CDE中所有涉及的名词与方法论进行阐述，最终把ISO
19650的逻辑线串联成一个闭环。
拓展阅读：Employer Information
Requirements，点击图片阅读原文
3.3 CDE工作场景
为了更好的阐述CDE是什么，这里直接用CDE的工作场景来进行阐述。（备注：下面提到的软件都可以看做是CDE的体系，但仅是举例，并不是唯一工具。）
1.文档(Documentation)
拿一个项目在编写施工技术方案的过程作为工作场景：
总包技术部的技术人员首先会通过Word软件编制了一个初步的技术方案。这时这个技术方案文档便处于“工作状态（Work in Progress），存储在自己的电脑上；
然后技术方案需要有部门和管理人员的审核、讨论，这时技术员将技术方案文档从个人电脑存储到了OneDrive并在SharePoint上发布，形成了“共享状态（Shared）”
由于技术方案众多，技术员在SharePoint上给方案做了对应的文档分类、编号、命名、版本、内容概述、涉及人员等方面的备注（这个就是元数据的一种形式），方便后期对文档的统一管理；
发布完成后，各个部门与领导班子通过SharePoint与Office 365的协作功能，对方案进行审核与协同编辑，所有协同编辑的内容会留痕，并且大家对审核一直进行逐一回复和销项；
不同部门对技术方案进行审核、批注、修改和销项，图片来源：基于SharePoint的Office 365协作图片(实际项目截图，文字做了模糊处理)
所有问题销项后，技术方案可以报送监理与业主，于是项目在SharePoint快速走完内部审批流程，将技术方案变成”发布状态”（Published），正式上传至业主指定的Aconnex进行审批。
有关这个文档的所有操作都会留痕，所有版本随时可追溯。文档被赋予元数据(可以理解为属性)，方便对文档进行结构化管理。
最终方案审批通过并按方案执行完毕后，技术方案变成“存档”状态（Archived），在指定的媒介中进行保存。
以上的这些工作会有固定的管理方法论作为支撑：如TIDP、MIDP等（文档交付规划、计划）。
2.几何/图形信息(Geometrical Information)
几何信息的CDE工作方式与文档类似，例如针对设计工作：
设计团队的某个专业首先在Revit环境中开展自身的设计工作（Working in Progress阶段）；
设计成果到一定阶段后便将模型在一个服务器环境或者BIM
360 Design或BIM 360 Coordinate中发布，开展跨专业的协同设计（Shared阶段）；
协同且设计完成后，设计成果在Aconnex上向业主移交，变成Published状态。此时业主把设计模型移交总包或分包，总包或分包又进行到另一个阶段深化设计的Working in Progress、Shared、Published的状态。对应的工作环境可能从BIM 360 变成了ProjectWise。
最终所有的模型和执行完毕，都进入到“存档”状态。
与文档类似，几何信息管理也有固定的管理方法论作为支撑：MPDT，Data Segregation & Federation、TIDP、MIDP(模型拆分、整合、职责、交付计划)、Information Exchange(信息交互原则)等工作。
3.数据信息(Alphanumerical Information)
数据包含了设备运行状态数据、监控数据、通过信息化手段填写的生产数据，这些数据因为获取设备和工具的不同，分布存储在不同的服务器上。数据在这个阶段可以理解为Working in Progress阶段。
为了更好集成应用数据，项目建立了SQL数据库，获取各类数据源，并按照管理需求对数据进行结构化处理，形成结构化数据。数据在这个阶段可以理解为Shared阶段。
项目将数据库接口开放，并集成到PowerBI、或BIM 360、Aconex的数据集成展示功能中，对数据进行分析应用。数据在这个阶段可以理解为Published阶段。
最终，项目建设过程中的整体建设数据备份打包，形成Archive阶段。
数据管理也有配套的方法论：项目需要什么样的数据、数据来源、以什么方式呈现、做什么应用，项目都会在BEP中的Attribute Data中提前规划好并明确流程机制。
不同阶段不同信息类型所涉及到的CDE工具
为了方便对CDE的理解，我从总包角度画了一张图，阐述不同阶段不同信息类型所涉及到的工具。但也要再次强调，里面所有的工具都可以国产替换，CDE是一个体系，工具只是实现这个体系的载体。
3.4 CDE的作用和意义
讲完CDE的工作场景，很多人会意识到里面的很多应用便是我们日常的工作内容：CDE其实就是把我们日常项目信息管理中的各种习惯进行了规范，整理成了一个标准。
基于CDE管理的项目信息在不同维度的作用，图片来源：ISO 19650-2
ISO 19650里有一张图，阐明如果所有的项目信息都按照统一的结构化方式进行管理，对建筑行业可以产生几个维度的作用。
第一个维度：确保项目管理过程各方信息源的统一，提升信息协作的效率。同时将信息结构化，方便查阅和使用与项目管理；
第二个维度：不同项目信息按照统一的方式进行结构化管理，可作为未来项目、企业管理的决策依据，成为显性化的知识；
第三个维度：结构化的信息是未来信息技术进一步发展的基础，如机器学习、人工智能等技术的发展，均需要结构化的信息做支撑。
所以这些看似不起眼的一个个微小的工作，其实就是建筑行业未来走向智能化的基础。
拓展阅读：人工智能需要什么样的BIM，点击图片阅读原文
3.5 CDE总结
由于配套的是项目和资产管理过程中的信息管理体系，项目和资产管理的特性造成了CDE字面意义上看似简单但实际庞大而复杂。
如果需要用简洁的语言来总结CDE的特征，可以包括以下几点：
-
CDE可以理解为项目和资产信息管理所涉及的工具和方法
-
CDE不局限于建设过程，也包含运维阶段，CDE对应的是广义的“项目管理”
-
CDE是BIM的底层技术之一，但CDE不局限于模型，还包含文档和数据
-
CDE不是一个平台也不是一产品，CDE对应的是一个产品体系：不同的信息类型在不同阶段需要用到不同工具
-
CDE不只是产品，还需要有配套的方法、标准体系支撑
这张图说明两层意思，第一和第三段话是说明一个项目针对不同的场景会用到不同的CDE工具，第二段是说明CDE已成为欧美发达国家建设工程项目的标准配置。图片来源：《英国建筑标准院：2020
BIM Report》
– 04 –
典型CDE产品形体介绍
方法与标准都需要有工具来支撑，CDE也是。配合产品的介绍，可能会让大家对CDE有更直观的认知。
4.1 CDE产品概述
本文尝试着按照不同项目信息类型在不同阶段的应用场景，对现有的CDE产品做了一个分类，但这个分类只是依据个人的理解，并不一定准确。
各阶段针对不同信息类型的CDE产品(部分)
所以CDE并不是一个平台，而是针对不同应用场景需要有不同的工具做支撑。和BIM一样，我们在项目实施时喜欢问“选用的什么BIM平台”，但实际上BIM在解决不同问题也是用的不同的工具。
如果一定要说一个“项目用的什么CDE/BIM平台”，这个平台一般是指由业主方建立、面向所有参建单位Published阶段信息管理的平台，例如ProjectWise、Aconex、BIM
360 Docs等，这个就是我们日常理解的平台。
除了业主单位建立的大统一平台外，所有参建团队针对其不同类型的信息管理会用到不同的内部CDE工具（Work in Progress和Shared阶段）。
CDE产品市场占用率排名，数据来源《英国建筑标准院：2020 BIM Report》(这张图可能会造成一部分人的困惑，因为里面有网盘类的产品存在，具体可参考可参考本文第4.2-4.7节的详细CDE产品介绍)
以施工单位为例：
施工单位内部的文档协作可以是“内部服务器+Office/WPS”，也可以是“OneDrive/SharePoint+Office”。
施工单位内部的模型协作可以是“内部服务器+Revit与Navisworks”；和外部参建单位可以是“BIM 360 Design+Coordinate”，或者建立一个外网可访问的“服务器+
Revit与Navisworks”。
施工单位数据协作可以是“SQL数据库+PowerBI”。
所有的信息最终会发布到业主方的平台进行共享与应用。
再次引用这张图
我还尝试着将目前市场上的CDE产品形态也做了一个分类。
4.2 ProjectWise类CDE
ProjectWise可以算是最CDE的CDE产品。因为ProjectWise的发展在一定程度上贡献了一部分CDE的理论体系。而ProjectWise所覆盖可管理的文档类型和阶段最为全面。
因为几十年的发展，以及ProjectWise对各类主流文档、CAD软件的协同编辑插件研发，使得其不仅可以作为各个参建单位各类文档类型在Working
in Progress和Shared阶段的CDE，也可以做面向所有参建方所有文档在Published阶段的综合性CDE。
ProjectWise架构，图片来源：ProjectWise官网
所以ProjectWise比较符合我们所说的大一统的平台，但实际上ProjectWise针对不同信息类型在不同阶段的管理，采用的是不同的模块与插件。同时，即使功能最多，如果没有良好的组织架构和工作流程来支持，项目可能只是买了一个昂贵的网盘。
4.3 ACC/BIM 360类CDE
Autodesk Construction
Cloud(ACC，可以理解为BIM 360系列产品的升级)是一个比较新的CDE形态，相对符合国内人员对“平台”尤其是“BIM平台”的认知。
ACC大致的架构是，基于一个引擎底层Forge，所有信息通过Forge引擎转化为统一的数据格式，并通过BIM 360 Docs作为用户浏览Forge信息的载体，同时具备基本的工作协同功能。
BIM 360 Docs上的项目信息作为整体项目的数据底层，用不同的模块开展相关的应用，从而支撑不同业务实施。例如360 Design用于协同设计、360 Plan用于进度成本管理、360 Build用于现场管理、BIM 360 OPS用于运维和资产管理。
ACC架构，图片来源：Autodesk官网
ACC作为CDE本身也是各个业务开展的工具，业务实施的数据直接在CDE中变成项目信息的一部分，共同的数据底层提升不同应用模块之间的数据关联性和数据传递性，更好地支持项目层面、区域层面、公司层面的协作，提升生产效率。而应用数据后期成为Autodesk Construction IQ的决策依据。
拓展阅读：Autodesk University 2019
4.4 Asite/Aconex类CDE
ASite、Acconex之类的CDE主要是面向业主的CDE，针对参建各方基于Published阶段的文档进行管理，不具备Working in Progress阶段的文档协作功能，但会基于文档开展一部分与项目管理相关的业务管理工作。
如业主指定ASite、Acconex等作为项目CDE，参建单位往往还需配置不同文档和图形在Working in Progress阶段的CDE，例如SharePoint、BIM 360 Design等。
Aconex模块，图片来源Aconex官网
4.5 OneDrive/SharePoint类CDE
项目信息不仅仅是图纸、模型和数据，我们日常工作的所有文档实际上都是项目信息管理的对象，且均需要协作。所以，很多我们日常使用的工具其实就是CDE的组成部分。例如OneDrive+Office365/SharePoint其实就是目前行业针对日常文档协作与管理的CDE。
SharePoint架构
4.6 网盘类CDE
其实即使介绍到这里，很多人对CDE的认知可能还是绕不开“网盘”。事实上根据英国建筑标准院的调研，市场占有率最高的CDE里也包含了“网盘”类的产品：ViewPoint、Dropbox、OneDrive、Google
Drive等。
但CDE与网盘有着本质的区别：“网盘”需要具备按照标准开展项目信息管理的能力才能称为“CDE”，例如元数据、版本追踪、协同工作、流程审批等。
事实上，这些 “网盘”都是发布了针对建筑行业的专属版本后，才被归类到“CDE”：例如Viewpoint的for Project、Dropbox的Construction版、Google Drive+WorkSpace等。
国外大部分”网盘”公司都推出了针对建筑行业工作流程和业务场景的专属版本，例如DropBox的Construction版，所以往往被作为Publish阶段的CDE使用，图片来源: DropBox
4.7 其他CDE形态
任何对文档、图形、数据其中一项的信息源统一的管理工具都算是CDE。例如CIC协会认为监控、监测类的IoT数据可以归类为图形和数据信息，所以类似于国内智慧工地的产品在某种程度上也具备了CDE的形态。
香港把类似于“智慧工地”的产品(Digital Works Supervision System,DWSS)看做是CDE的一部分,针对数据和图像信息在Shared和Published阶段的CDE(下篇文章会聊智慧工地这个话题)，图片来源：香港MES
同时CDE不局限于建设过程，运维过程也需要有CDE，因为运维过程也会产生文档、数据等信息。这也是为什么EcoDomus这个运维产品也被认为是CDE的原因。
EcoDomus作为运维阶段的CDE，图片来源：EcoDomus官网
– 05 –
国内CDE现状
在“BIM”出现后，国内一直有CDE意识形态的产品存在：“BIM协同平台”、“项目协同平台”、“数字项目平台”、包括“智慧工地”等，这些“平台”类的产品在某种程度上包含了对文档、图形、数据的管理诉求，所以可以看做是具备CDE的特性。
但从目前五花八门的“平台”类型和产品形态可以看出：我们已经具备了“CDE”的意识形态，但还没能把这个意识形态总结成一个方法体系。
CDE虽然是行业发展到一定阶段必然出现的产物，但是这个发展是经历了几十年的方法论、产品体系、应用实践不断交互打磨出来的。所以CDE出现的意义是将管理的共性需求梳理出来：把一系列的管理诉求结合技术现状总结成了一套规范的方法，然后再反过来促进产品的发展。
但国内的“平台”类产品目前似乎都面临着一个困境：跳过了总结共性方法的阶段，直接用工具来匹配各种不同甚至畸形的管理需求，以致出现了很多畸形的产品。大部分“平台”类产品从一开始就要面对五花八门的定制化需求。
还是用这张图举例，国内的“平台”似乎要做一个能集成上面所有产品的东西
同时，国内外 “平台”类的产品似乎在往两个方向发展：
建筑行业软件产业生态，都可以看做是CDE的组成部分，不同产品用标准和流程串联到一起，图片来源：Autodesk
所以“CDE”这个名词其实超越了产品，产品只是一个依托，更重要的是方法论。如果没有方法的支撑，单纯的CDE平台意义不大。
前文提到了国内的“BIM协同平台”、“智慧工地”在某种意义上具备了CDE的意识形态，如果把“BIM协同平台”、“智慧工地”目前所面临的问题、与CDE所包含的工作结合在一起看，似乎就能明白国内CDE目前的现状。
– 06 –
从CDE衍生出的思考
建筑行业所有涉及到信息技术的名词都在描绘一个“自动化”、“智慧化”的美好未来。但是“智慧”无法仅依靠硬件的躯壳和软件的算法实现，需要大量的信息作为决策基础。
CDE便是在解决项目管理问题的同时、将项目信息转化为“结构性信息”(Structured Information)的过程。统一的“结构性信息”是建筑行业实现“智慧化”的基础。
香港大学对CDE与建筑行业自动化的描绘，图片来源：inno.emsd.gov.hk
技术的制约:人。点击图片阅读原文
很多信息技术在应用层面推广到一定阶段后，大家都会发现，阻碍技术发展的其实不是技术本身，而是人。抛开核心底层技术，我们很多科研和应用的热点，本质上还是处于造“躯壳”的阶段，缺少了能让“躯壳”真正动起来的基础性工作。
CDE便是一个比较能说明问题的代表。
18J820图集适用于采用装配式建筑结构体与建筑内装体集成化建造的新建、扩建和改建的住宅建筑设计。供建设单位、设计单位等相关人员使用。图集的编制，对使用者全面掌握行业标准《装配式住宅建筑设计标准》的内容和要求，有很强的指导意义。
18J820图集的编制是配合《装配式住宅建筑设计标准》JGJ/T398-2017的颁布和执行，将标准中部分重要条文通过图示、表格等形式简明、清晰、准确的反映规范原意，有助于使用者更好地理解和执行规范。图集内容按《装配式住宅建筑设计标准》章节的条文顺序排列编制，做到一一对应，共分为8个部分编制：1）总说明；2）术语；3）基本规定；4）建筑设计；5）建筑结构体；6）建筑内装体；7）围护结构；8）设备及管线。18J820图集总说明及条文图示所编内容全面，充分体现采用装配式建造的住宅建筑设计思路及技术要求。内容精炼、条理清晰，条文与图示编制契合度高，图示反映条文原意并突出装配式住宅设计及建造技术的特点，易于设计人员通过图示正确执行行业标准《装配式住宅建筑设计标准》JGJ/T398-2017。内容索引：目录……..1
“中国建设工程鲁班奖（国家优质工程）”作为我国工程质量最高奖，她的创建已成为建筑业贯彻落实“百年大计、质量第一”和《质量发展纲要》(2011一2020年)的重要举措。通过创建鲁班奖向社会奉献了一大批安全、适用、美观、耐久、节能、环保的精品工程，极大地推动了我国工程质量管理水平的稳步提升，给社会留下了宝贵的物质文化遗产。
1总则
1编制依据
1编制依据
1编制依据
1范围
说明书
二、设计依据
(四)本系列通用参考图适用于地震动峰值加速度Ag≤0.2g,地震动反应谱特征周期Tg<0.55s。本册适用于地震动峰值加速度Ag≤0.05g·
pdf图集不够清晰，但附全套cad版图纸
1 范围
目次
1总则
前言
为提高湖南省农村小型水利工程建设质量，推进农村小型水利工程建设规范化、标准化与生态化，充分发
内容摘抄：1范围
1 范围
根据天津市住房和城乡建设委员会下达的《市建委关于下达2018 年天津市建设系统工程建设地方标准编制计划的通知》（津建科[2017]520 号）要求，规程编制组经广泛调查研究，认真总结实践经验，参考有关国内标准和国外先进标准，在广泛征求意见的基础上，制定本规程。
1 总则
1编制依据
1总则
1总则
《化工工艺设计手册》(第五版)分上、下两册出版,共含6篇53章。上册包括工厂设计、化工工艺流程 设计、化工单元工艺设计3篇;下册包括化工系统设计、配管设计、相关专业设计和设备选型3篇。 《化工工 艺设计手册》在保持原有内容框架的基础上,在化工工艺设计内容的系统性、完整性上实现了跃升,以化工工 艺流程设计、设备工艺设计、工艺系统设计的三大基本程序为核心,形成了化工企业工艺设计内容的完整序 列。本次修订反映了第四版出版以来化工工艺设计技术和方法上的新进展,除新增化工工艺流程设计一篇外, 其他各篇在专业内容和设计现代化方面都进行了充实,内容更为翔实和丰富。 本书可供化工、石油化工、医药、轻工等行业从事工艺设计的工程技术人员使用,也可供其他行业和有关 院校的师生参考。本附件为下册，上册地址：高清带书签PDF《化工工艺设计手册 上册 第五版》以下为《下册》内容目录：第30章 管道及仪表流程图设计 3 1 管道及仪表流程图的设计基础 3 1.1 工艺设计包提交的内容 3 1.1.1 设计基础 3 1.1.2 工艺说明 3 1.1.3 工艺流程图 4 1.1.4 物料平衡和能量平衡 4 1.1.5 管道及仪表流程图 4 1.1.6 工艺设备表 5 1.1.7 主要工艺设备的工艺规格书 5 1.1.8 自动控制和仪表 5 1.1.9 管道设计 5 1.1.10 电气设计 5 1.1.11 泄放阀和安全阀 5 1.1.12 分析手册 5 1.1.13 工艺操作手册 5 1.2 P&ID设计需要的资料 5 2 管道及仪表流程图的设计过程 9 2.1 管道及仪表流程图 A 版 (初步 条件版) 9 2.2 管道及仪表流程图 B版 (内部 审核版) 9 2.3 管道及仪表流程图 C版 (用 户批准版) 10 2.4 管道及仪表流程图0版 (设计版) 10 2.5 管道及仪表流程图1版 (详细 设计1版) 10 2.6 管道及仪表流程图2版 (详细 设计2版) 10 2.7 管道及仪表流程图3版 (施工版) 10 3 管道及仪表流程图的管道编号 10 3.1 管道编号 11 3.1.1 需要编号的管道 11 3.1.2 不需要编号的管道 11 3.1.3 管道号的组成 11 3.2 管道编号的标注规则 11 3.2.1 一般要求 11 3.2.2 标注规则 11 3.3 管道特性表 12 3.3.1 管道特性表的填写方法 12 3.3.2 管道特性表的内容说明 12 4 管道及仪表流程图校审提纲 12 5 设计压力和设计温度 19 5.1 设计压力 19 5.1.1 术语说明 19 5.1.2 设计规范 20 5.1.3 设备设计压力的确定原则 20 5.1.4 各类系统中设备最高压力的 确定 20 5.1.5 管道设计压力的选取 22 5.2 设计温度 22 5.2.1 设备设计温度的确定 22 5.2.2 管道设计温度的确定 23 第31章 管道及仪表流程图基本单元 典型设计 24 1 泵的管道及仪表流程图设计 24 1.1 离心泵的典型设计 24 1.2 往复泵的典型设计 25 2 容器的管道及仪表流程图设计 25 3 塔设备的管道及仪表流程图设计 27 3.1 蒸馏塔的典型设计 27 3.2 再沸器的典型设计 27 3.3 冷凝器和回流罐的典型设计 27 4 储罐的管道及仪表流程图设计 31 5 换热器的管道及仪表流程图设计 31 6 空冷器的管道及仪表流程图设计 32 7 加热炉的管道及仪表流程图设计 33 8 压缩机的管道及仪表流程图设计 33
1 总 则
1 范围
为规范我省装配式纤维增强硅酸钙板复合墙体在建筑装饰装修工程中的应用，促进我省装配式复合墙体的推广应用，做到安全适用、质量保证、经济合理，制定本图集。本图集适用于福建省新建、改建、扩建民用建筑和一般工业建筑采用装配式纤维增强硅酸钙板复合墙体作非承重内隔墙工程的设计。
4.0.3轻钢龙骨纤维增强硅酸钙板复合墙板应符合现行行业标准《轻钢龙骨式复合墙体》JGT544的规定。
（略）闽2022-J-51图集内容索引：目录1~2