作者 | Brian Potter       译者 | 弯月

出品 | CSDN(ID:CSDNnews)

自动化规范检查这一概念源自“自动化建筑规范检查”——检查建筑设计是否符合规范的软件。本文提及的许多创意与想法其实很久以前建筑行业就已经尝试过了。

下面,我们来看一看自动化建筑规范检查系统的发展历史,以及我们可以从中学到哪些经验教训。

自动化规范检查的基本思想

首先,我们交代一下背景知识。新落地的建筑物必须符合当地建筑规范的要求,这一系列的规则涉及到建筑物的各个方面,比如混凝土的坚固程度、扶手的高度、楼梯间的距离必须短于X尺等等。建筑规范的体量非常大,美国几乎每个司法管辖部门都在使用的《国际建筑规范》,其仅基本规范就有 700 多页,而且它只是概述了一系列设计要求而已,具体的详情需要参考数百本文件和设计标准。根据深入参考的级别,所有这些要求加在一起可能高达10万多页,但是一幢建筑物通常只会受到其中一部分要求的约束。

政府非常关心建筑物是否符合规范,因此在申请建筑许可的过程中,需要由许可办公室的计划审查员(有时是多名计划审查员)审查建筑物的设计,以确保其符合规范。整个审查的过程非常耗时,例如在华盛顿金县,目前获取房屋建筑许可平均需要耗时20~30周。而对于同在华盛顿的圣胡安,平均计划审查时间为12~20周。这些是针对单一家庭住房,它们是小型建筑,需要遵守的建筑规范比《国际住宅法》更简单。如果是商业建筑,情况往往更糟。

由于计划审查员总是会提出一些设计师必须解决的意见,比如“这里的坡度不符合排水要求”,“这个面上的玻璃太多/太少”等,审查时间必然会被延长,设计团队需要与管辖部门反复拉扯几个回合,才能拿到许可。部分原因是由于建筑规范的复杂性,使得设计人员很容易忽略其中一些规定(尤其是不同司法管辖区之间有很大差异的规定)。部分原因是计划审查者和司法管辖部门之间存在差异和不一致,他们对规范的解读也不尽相同。例如,一项研究发现,在相同的法规条款下,同一栋建筑在某个司法管辖区内的违规行为是0,而在另一个司法管辖区则有 16 起违规行为。再加上美国共有2万多个许可司法管辖区,你需要花费大量时间来确定建筑物的设计是否符合规范。

这种协调的过程会导致成本增加(因为设计人员和司法管辖部门、承包商和检查员需要就是否符合规范要求这个问题来回拉扯),最坏的情况下还会导致项目出现重大风险(司法管辖部门不接受某些系统,或者能够接受的修改方案完全不可行)。因此,每个建筑项目都会为了确定是否符合规范要求而付出大量的时间和精力,还要搭上巨额成本,对于新型或创新建筑系统而言,这项开销尤其惊人。例如,2021 年美国的《国际建筑规范》就增加了关于大型木材建筑的规定,但大多数司法管辖区尚未采用,而且即使司法管辖区往往也不清楚管辖部门、消防管理部门接受什么,不接受什么。

为了打开这个症结,一种方法是使用自动化规范检查系统,即通过软件程序分析建筑设计并自动确定其是否符合规范要求。在理想情况下,人们足够信赖这种软件,并接受将检查结果作为合规性证明,就像车辆登记部门接受通过排放测试来证明你的汽车符合车辆排放法规要求一样。

如果真能达到这种接受程度,美国的许可程序就可以大大简化。不仅司法管辖部门可以减少审查建筑许可申请的时间和精力,而且建筑师和工程师也可以确信他们提交的设计符合规范要求,从而避免与许可办公室的来回拉扯。

随着司法管辖部门接受软件检查,此类软件可能会成为美国数千个许可司法管辖部门的抽象层,统一和简化许可要求。

这是一个非常吸引人的案例,因此自从建筑设计开始使用计算机依赖,人们就一直在尝试开发自动化规范检查系统。

自动化规范检查系统的发展简史

我们可以将自动化规范检查系统大致分为三个需要解决的问题:

● 以机器可解读的形式表示建筑规范要求;

● 以机器可解读的形式表示建筑物本身;

● 让利益相关者接受软件的输出符合规范合规性(软件的输出必须可靠、可验证且易读)。

(此处,我们还可以加入第四点,即执行实际的验证,尽管大多数人认为只要能够解决以上三个问题,第四点也就没什么难度了。)

由于自动化规范检查已经尝试解决了问题的不同部分,下面我们来分别看看各个子问题(实际上这些工作的区分很模糊,它们之间有很多重叠。)

通过软件表示规范要求

早期,自动化规范检查的工作重点在于创建表示建筑要求的软件,从20世纪60年代开始,Steve Fenves就致力于将建筑设计规范转换为大型决策表,这种新颖的决策过程表示方式不仅方便人类理解,而且容易构建到软件中。早在 1969 年,他就与美国钢结构协会(American Institute of Steel Construction,AISC)合作制定了钢材规范的决策表:

这项工作的重点不仅仅是研究如何通过计算机编程检查钢材规范,早在20世纪60年代,工程师编写的程序就能够完成工程计算,并将其与规范要求进行比较。此次,他们的目标是建立一个可靠的流程:首先,创建一个可以轻松评估逻辑一致性的规范格式(即决策表);然后,实现该规范,并保证最后的输出能够得到信赖。当时的做法(现在也一样)是将规范“硬编码”到软件中,这使得其输出难以评估。规范深埋在软件的一堆if-else中,无法验证这些实现是否正确。Fenves 设想了一个更健壮的过程,通过一个独立的数据结构来实现规范要求(这样就更加清晰,而且方便检查),然后再由一种“要求处理引擎”来处理。

纵观20世纪80年代,Fenves以及其他人在该领域付出了巨大努力。他与美国国家标准局(现为 NIST)联合开发了SASE系统,这是一种创建标准的方法,可确保生成的标准可供机器解读。后来,他又与AISC合作,开发电子版的LRFD规范。此外,他还帮忙开发了 SPEX 引擎(这是一种“标准处理引擎”,可独立于其他特定标准实现)。

除此之外,还有其他人也推出了类似的标准处理系统,例如 SICAD 系统,这也是一个标准处理引擎,美国国家公路与运输协会标准(AASHTO)就采用了这种引擎。然而,除了少数几个项目略有建树之外,该领域的大多数工作仍然停留在学术层面。

20世纪90年代,建筑信息模型(BIM)的发展为解决这个问题打开了新的局面。BIM允许通过计算机建模,以大型数据库的形式表示建筑物,随着这种建模越来越流行,人们开始开发“BIM检查引擎”,这类软件可以获取一系列要求(这些要求可以内置到软件中,也可以后期通过编程来设置),并检查BIM模型是否满足这些要求。1996年,芬兰开发出了Solibri,后来这款软件成为了该领域使用最广泛的软件(至今仍在使用)。除此之外,还有FORNAX 和 Express Data Manager等其他系统。从理论上来说,自动检查建筑物的设计是否符合规范并没有太大难度,我们只需为检查引擎提供适当的规则列表,而且未来许多自动化规范检查系统也都将采用这种方法。

新加坡政府的 Corenet 项目是这类系统中最有抱负的一个,该项目的目标就是打造一个自动化规范检查系统,当然还有其他方面的功能。设计师可以上传电子版的建筑设计,然后通过软件自动检查其合规性。该软件的第一次迭代于90年代开始开发(计划早在1982年就提出了,甚至早于BIM),最初计划使用二维对象CAD。后来被一个BIM系统所取代(该系统采用了FORNAX 检查引擎)。

虽然该项目最终未能取得成功(就像许多失败项目一样悄无声息地死去,原因不明),但最近Corenet-X 项目又复活了。项目的目标依然没有变化,只不过此次他们使用了Solibri模型检查器。

美国也有过类似的项目,比如SMARTcodes 和 AutoCodes等。

SMARTcodes 是 ICC 在 21世纪初的一次雄心勃勃的尝试,他们的目标就是开发这种自动化规范检查系统。ICC原本的计划是开发可解读规范的软件,然后再通过BIM模型检查软件进行评估。

由于ICC本质上是美国所有建筑规范的创建者,因此让司法管辖部门采用这个系统可以大大简化流程。虽然该项目取得了一些进展(他们甚至开发了软件将规范转化为模型检查规则),但他们在金融危机后失去了资金支持,项目也因此夭折。

图:SMARTcodes使用的规则创建工具

AutoCodes也是一个类似的项目,由Fiatech(“资本项目利益相关者”的行业联盟)于 2012 年启动,是“可复制建筑指南”项目的一部分。该项目有大量的合作伙伴,包括 ICC,并且完成了一些初步的工作,比如验证许可要求的解读是否缺乏一致性,但其他方面几乎没有任何进展。

尽管检查引擎得到了发展,但在“以机器可解读的形式表示建筑规范”方面几乎没有任何进展。这与Fenves在20世纪60年代所担心的情况大致相似,工程规范以及其他客观、定量的标准完全可以在软件中实现,但通常这类软件的设计需要专家的指导和监控。将规范转化成软件通常都采用了硬编码,因此软件会变成一个黑匣子,通常人们很难理解它为什么得出这样的答案。

时至今日,该领域的研究仍在继续,例如最近的一项研究尝试以机器可解读的形式实现新西兰建筑规范,但据我所知没有其他实现。

部分困难在于建筑规范本身,这项工作的重点在于将规范要求转化为清晰、明确的规则,但许多规范并不简单。Fenves 给出了 1993 年 BOCA 规范中的一个例子:

如果想通过一个软件来检查上述条款,首先我们必须搞清楚“什么是特殊的知识和努力”(special knowledge and effort),而且定义必须足够详细,必须涵盖到未来所有的可能性(比如一种新型门把手是否需要特殊的知识和努力?一种新型的锁机制呢?如何将其转化为软件可评估的陈述,同时又不需要建立一个关于世界如何运转的完整模型?)

在建筑规范中不难找到类似的规定,比如2018年《国际住宅规范》中的如下规定:

自动检查建筑物是否符合规定意味着,弄清楚如何向软件解释具体的含义。一般来说,创建机器可解读的建筑规范不仅意味着翻译规则本身,还需要翻译规则所反映的关于世界如何运转的所有默认假设。正如 Fenves 所说,“设计标准的大多数条款都提到了所有人类都应该知道的常识。不幸的是,我们并没有这种常识的规范化表示。每个人自然而然都知道这些常识而已。”

这些默认的假设会导致规范的解读模棱两可。从本质上讲,我们试图解决的问题是消除建筑规范的模糊性,使其易于解读,而这个问题也导致我们很难通过软件解决问题。

尽管困难重重,但我认为在解决这个问题上,我们即将迎来重大转折。以前的大多数努力都是手动将规范转化为一系列客观规则,但我认为在不久的将来人工智能系统就能直接评估现有的建筑规范。这类的尝试可以追溯到上个世纪90年代初期,尽管以前从未有成功的案例。但如今基于语言的人工智能模型正在迅速发展,我们可以借助OpenAI 的 Codex 这样的工具一探如何通过软件解读建筑规范。

创建适当的建筑物表示

在实现以机器可解读的形式表示建筑规范之后,下一步就是以机器可解读的形式表示建筑物本身。

大多数自动化规范检查的早期研究是在手绘或二维CAD的时代,这两种方式都可以通过一系列线条来表示建筑物,可惜软件无法理解其中的含义。因此,早期的自动化规范检查系统还曾尝试创建一个数据结构来表示系统可以理解的建筑物。

随着上个世纪90年代BIM的发展,大多数自动化检查系统都开始以BIM为基础,研究如何创建BIM模型才能评估合规性。这些尝试一般都依赖于 Solibri 或其他检查引擎来完成实际的规范评估。

创建可通过机器评估合规性的建筑物表示存在几个方面的挑战。一方面,BIM模型的创建并没有标准化的方法,不同的设计师会采用不同的方式来构建BIM模型。这意味着评估软件必须能够评估任意结构的数据模型,或者强制大家采用标准化的建模方式。

大多数自动检查系统的实现都采用了后一种方式。例如,SMARTcodes 计划与美国BIM标准的开发和推出相结合。新加坡目前正在尝试自动化规范检查的流程,显然Corenet-X也与某个非常严苛的BIM建模标准联手了。

据我所知,UpCodes AI是唯一没有采用标准化BIM模型的系统,这款软件可以评估Revit模型是否符合规范。但是,目前这款工具的开发已经停滞。

除了建模风格迥异之外,还有一个问题是为了创建一个可用于检查规范的建筑模型,我们必须添加大量信息。正如我在《 BIM、Revit 和数据库梦想》一文中所说:

……创建一个完整的建筑信息数据库需要付出巨大的努力。即便是中型建筑也拥有数十万个部件、数百种不同的规格和标准,还有无数个需要指定的参数。预先指定所有的参数是一项庞大的工作,而且还需要长期维护,才能确保其保持最新状态。大多数设计专业人员很快就会为了图省事和方便维护,而省略设计图中“不必要”的细节和元素。

这些问题经常困扰基于BIM的自动检查系统。例如,2009年有一个项目负责给GSA法院创建可用于自动检查的BIM标准,为了确保软件能够分析模型,他们需要手动标记不同的空间,而这项工作耗费了数百个小时,整个项目也因此陷入困境。(在AI项目中,手动标记输入数据的工作量也非常庞大,与此处我们的介绍有相似之处。)因此,一些当前的自动检查工作,例如 SEEBIM 研究项目,都在尝试通过计算机生成此类信息。

这项研究在以稳定的速度持续推进,但实际的实现案例并不多。但我认为,在未来5~10年内AI模型将在该领域取得重大进展。

输出验收

创建自动化规范检查系统的工作主要集中在问题1与2,即创建规范和建筑物的软件表示。但是,自动化规范检查系统的价值主要来源于解决第3个问题,即让利益相关者(建筑管辖部门、设计师和建筑商)接受软件的输出即为合规性证明。缺少这一步,那么之前所有的努力不过只是自动化了某些重复性的任务,并没有改变根本的流程。

当前大多数自动化规范检查系统的实现(以建筑设计软件的形式)甚至都没有尝试解决这个问题。例如,当前的工程软件包(如 RAM)一般都可以自动检查建筑物的整个结构是否符合规范要求。虽然这无疑节省了工程时间,但 RAM 打印输出上写着“所有检查均已通过”并不会改变许可流程,施工文件提交上去之后,计划审查员仍然会进行审查,并提出意见。

这个问题既是一个技术问题,也是一个政治问题。软件需要生成清晰、可验证的输出,而且还需要说服不愿承担风险的司法管辖部门和建筑商。最直接的解决这个问题的方法是自上而下,由政府出面领导(或至少由政府支持)自动化规范检查项目。事实上,许多自动化规范检查项目就采取了这种推动方式,比如SMARTcodes, AutoCodes 和 CoreNet等。

全球范围内还有其他一些由政府主导的自动化规范检查系统,在2020年的峰会上德国、挪威和爱沙尼亚等欧洲各国政府都展示了一些原型。其中,爱沙尼亚的系统似乎是最先进的,但这些系统都还未能完全实现。

成功的项目

以上,我们介绍了一长串尚未完成的项目。但是该领域也有一些成功的项目,比如ResCheck、ComCheck 和 SolarAPP 都是“野生”的系统,至少它们成功地实现了自动化规范检查系统的部分目标。

ResCheck 和 ComCheck 是美国能源部于上个世纪90年代开发的软件,分别用于验证住宅和商业建筑的能源规范合规性。这两款软件的工作方式很相似,设计师将相关的能量参数输入软件(通过下拉菜单和文本框),然后执行热流计算,最后再比较规范要求。ResCheck 和 ComCheck 与其他设计软件的不同之处在于,它的输出就代表了合规性。事实上,许多司法管辖部门要求将 ResCheck 或 ComCheck 的合规报告作为许可申请的一部分,有些甚至将 ResCheck 和 ComCheck 的合规性写入当地建筑规范。

SolarAPP也是一个类似的工具。这是一款由美国国家可再生能源实验室为住宅太阳能装置开发的基于网络的规范合规工具。SolarAPP 的工作方式与 ResCheck 和 ComCheck 类似,设计师通过一系列文本框和下拉菜单将设计参数输入到软件中,然后由软件检查其是否符合住宅太阳能装置的规范要求,最后再输出合规性报告。

但SolarAPP更进一步,它可以在相关司法管辖区内自动颁发建筑许可证,不需要人工计划审查员在上面签字。

SolarAPP 相对较新,去年才开始普及。截至 2021 年 9 月,美国已有 125 个司法管辖区同意使用该系统。NREL 对 5 个测试辖区进行的一项研究表明,如今申请许可的平均减少了一天左右,项目的安装和检查平均加快了12天。截至 2021 年 12 月,5 个测试辖区内审查人员共节省了 2000 多个小时。

这些成功的项目与那些未能成功的项目有什么区别?

一方面,ResCheck、ComCheck 和 SolarAPP 的关注范围非常狭窄,它们的目标不是检查整个建筑物,而是根据非常狭窄的规范要求列表检查合规性。因此,这类项目的开发速度非常快,而且验证输出是否正确也更加方便,例如SolarAPP会输出它所执行的每一个检查,而且输出的列表非常简单,完全可以通过人工复查。

另一方面,这些项目刻意回避了一些技术难题,这些软件相对都比较简单,可通过文本框和下拉菜单操作。他们没有解决一些常见的问题,比如将规范转换为软件可评估的规则,自动分析现有的BIM模型,也没有利用AI实现智能的功能。

换句话说,他们尽可能地忽略了问题1和2,却专注解决了问题3。例如对于 SolarApp,获得利益相关者的认可是流程的关键,与司法管辖部门合作以迭代的方式推进开发,征求有关应用的意见与输出反馈,直到生成每个人都能接受的输出。

我认为,接受与否是未来自动化规范检查系统发展的一个关键阻碍因素。也许在未来5~10年(或更早)人工智能模型就能够在正确解读建筑规范和建筑设计以及自动检查建筑物是否符合规范方面取得重大进展。但目前人工智能模型一般都是黑匣子,没有人清楚它们如何得出了特定的输出,因此将它们作为真正的自动检查系统仍将是一大挑战。

总结

  • 如果自动化规范检查能够得到普及,就能大大减少获取建筑许可所付出的时间和精力。

  • 自动化规范检查需要解决三大问题:将建筑规范要求转化为软件可解读的形式,将建筑设计转换为软件可解读的形式,以及让利益相关者同意软件的输出表明规范合规性。

  • 目前我们有一些软件可在狭窄的领域中自动执行部分规范要求检查,但需要专家的监督。其中大部分工作是设计软件,但偶尔也涉及其他学科,例如 SmartReview可以检查某些架构规范要求。

  • 为了创建广泛通用的自动化规范检查系统,人们已经投入了大量研究,而且还有很多政府支持的项目,但大部分都未能取得成功。

  • 获得成功的案例很少,主要是以特定范围内的规范为主,并专注解决问题3。

  • 在接下来的5~10年内,人工智能模型很可能会成功解决问题1和2,但问题3依然得不到解决,而且人工智能模型可能会导致解决问题3的难度加剧。

  • 自动化规范检查的大部分价值来自于解决问题3。

原文地址:https://www.infoworld.com/article/3660632/you-re-thinking-about-technical-debt-all-wrong.html

— 推荐阅读 —

《新程序员001-004》已全面上市,欢迎扫描下方二维码或点击进入立即订阅,即可畅享电子书及精美纸质书

自动化规范检查软件如何发展而来?相关推荐

  1. Model Inspector — 软件模型静态规范检查工具

    Model Inspector (MI)原厂商是韩国 Suresoft,是 KOLAS 公认测评机构,旨在提升安全关键领域软件可信度. MI 用于开发过程中模型的静态检查,包括规范检查.复杂度度量,提 ...

  2. 行业认证标准:如何达到DISA ASD STIG规范进行软件开发

    简化DISA ASD STIG的合规性 您的软件开发团队可以使用Parasoft满足所有要求的业界领先支持,简化对DISA ASD STIG的遵守.从深入的应用程序扫描(发现OWASP Top 10. ...

  3. 监控组态软件及其发展《转》

    "组态"的概念是伴随着集散型控制系统(Distributed Control System 简称DCS)的出现才开始被广大的生产过程自动化技术人员所熟知的. 在控制系统中使用的各种 ...

  4. Blender导出模型规范检查

    Blender导出模型规范检查模板(持续更新) 1.多边面检查 2.重合点.重面与游离点检查 3.法线朝向检查 4.锐边,UV缝合边检查 5.摆位和大小以及名称要标准 6.各个物件的原点要标清楚(全部 ...

  5. 《勒索软件防护发展报告(2022年)》正式发布,助力企业高效应对勒索软件攻击

    随着云计算.大数据.人工智能等新技术的快速普及和应用,全球网络攻击层出不穷,勒索攻击呈现出持续高发态势,并已成为网络安全的最大威胁之一.因此建立全流程勒索软件防护体系,成为了企业防御勒索软件攻击的首要 ...

  6. 施耐德 m340 编程手册_施耐德推出开放自动化平台 开启“软件驱动自动化”时代...

    原标题:施耐德推出开放自动化平台,开启"软件驱动自动化"时代 新闻概述: · 施耐德电气推出全球领先的以软件为中心的EcoStruxure开放自动化平台(EcoStruxure A ...

  7. MT3DMS软件的发展及其应用

    MT3DMS软件的发展及其应用   发表日期:2005年8月21日 吴剑锋 (南京大学地球科学系) MT3DMS是目前应用最为广泛的三维地下水溶质运移模拟软件.本文概略地回顾了MT3DMS软件的开发背 ...

  8. IDEA工具(阿里巴巴)代码规范检查插件

    1.代码规范 因为软件是需要人来维护的.这个人在未来很可能不是你.所以首先是为人编写程序,其次才是计算机 不要过分追求技巧,降低程序可读性. 简洁的代码可以让BUG无处藏身.要写出明显没有BUG的代码 ...

  9. 联想固体硬盘检查软件_固体。 软件设计原理

    联想固体硬盘检查软件 "It is not enough for code to work."― Robert C. Martin, Clean Code: A Handbook ...

最新文章

  1. oracle如何实现多副本,Oracle同一节点副本数据库启动
  2. 设计模式 - Iterator(迭代器)
  3. Linux-鸟菜-6-文件搜索
  4. c++-内存管理-内存对齐方式
  5. julia常用矩阵函数_Julia系列教程3 数学运算 矩阵运算
  6. python执行时间长被kill_用python记录运行pid,并在需要时kill掉它们的实例
  7. Super超级ERP系统---(7)货位管理
  8. 【线性分类器】(二)“深度学习”的鼻祖——感知器
  9. python中利用字典加密字符串_Python列表,字典和字符串操作
  10. python接入支付宝 40004 invalid-signature 错误原因: 验签出错
  11. shell训练营日常打卡DAY1
  12. 2008年7月28号,晴。时间在流逝——哈佛自习墙,今天是我攻读博士的第22天,昨天的收获还是不小的,至少让我明白,做任何事情,一定要尝试,一定要亲自动手
  13. vue 所有按钮属性、vue Button 所有按钮属性事件、vue a-button 所有按钮属性事件、vue 按钮所有属性事件、vue
  14. XML 是一种元语言, 可以用它来描述其他语言。
  15. VS 2022 C++ 自定义头文件示例
  16. 微信小程序的登录界面实现
  17. 简历制作案例分析及制作小技巧总结
  18. java:简单的点单系统
  19. 【踩坑合辑】7.14
  20. oracle 10g升级到11g

热门文章

  1. (6)基于 Elasticsearch 的实践——建立一个员工目录
  2. 树莓派 4位数码管时间显示
  3. 响铃:二手车水太深,汽车之家“诚信联盟”能成“抽水机”吗?
  4. RF基础(相位和波长、回波损耗和驻波比、电缆阻抗、极化、天线波束宽度)
  5. 【牛客刷题】前端--JS篇(二)
  6. 手把手教你注册 das 域名账户,埋伏空投
  7. Java——异常登陆模拟
  8. python的注释有哪几种_Python注释方式有哪些
  9. 微信小程序wxs语法
  10. 两种骨架提取的方法(color.rgb2gray和CV2)