首页 » 理论知识 » 正文 理论知识 见闻眼界 我怎样用Revit自动生成机电系统图?| 胡说树经验分享 2023-05-04 分享 你好,这里是BIMBOX。 提起绘制机电图纸,大家最头疼的恐怕就是绘制系统图了,因为Revit本身没有提供这样的功能,而传统方法是人工绘制、人工计算的方式,绘制的过程费事费力不说,反复修改的过程也是很让人头大,经常出现绘图遗漏、计算错误的情况。 当我们把基于Revit的机电正向设计引入到流程,这个问题就更加麻烦,因为Revit本身没有提供系统图生成的功能,BIM绘图和系统图就得走两条并行的路线,模型修改的时候就会让原本麻烦的流程更加麻烦。 这个问题,被我们的一位老朋友,来自福建博宇建筑设计有限公司的@胡说树,通过非常创新的方法解决了。 他自己开发了一套电气专业的「机电模型系统图设计管理系统」,还凭借这个成果,拿下了第二届「BIMBOX」杯互联网BIM大赛「专项难题攻克赛区」的一等奖。 这个插件完成了前后端的数据联动,设计师只要在两个面板之间输入参数、点击按钮,就可以对系统图完成「一键生成、一键合并、一键编号、一键排序」的功能,帮助设计师简单做出完成度非常高的系统图。 另外,当时让所有评委竖起大拇指的,不仅仅是这个开发成果本身,而是胡说树借鉴了DDD(领域驱动设计)的思想,还有从MVVM架构衍生而来的MFFM(Model-Family-FamilyModel)模式,具有很强的推广性,可以在很多项目中,帮你快速解决开发工作,甚至是一般BIM工作的复杂难题。 别看DDD和MFFM这两个名字听起来陌生,通过今天胡说树的分享,作为代码白痴的我们都完全可以看懂并理解,无论你是否从事开发工作,都一定能给你带来参考和帮助。 接下来,就有请胡说树亲自来分享一下,一开始对系统同完全不懂的他,是怎样一步一步完成这个插件的开发的。 你好,我是胡说树。 我在第二届BIMBOX互联网BIM大赛的难题攻克赛区中,发布了「机电系统图设计管理系统」作品,它主要是通过代码与族的相互配合,在Revit上实现机电系统图的快速设计,以及数据的联动计算,解决了机电系统图绘制繁琐、绘图遗漏、计算错误、图纸对不上的情况。 这里说的机电系统图,在项目里也称作电气系统图、配电系统图等等。 很多小伙伴看了比赛之后,都说想知道是这个作品是怎样完成的,也想进一步了解怎样结合开发与族的设计,帮助机电设计提高效率。 所谓「授之以鱼不如授之以渔」。接下来我以机电系统图开发这一实际案例,讲讲从我开始接手这个项目,是如何一步一步进行项目拆解与开发的。 1 闽南趣闻 开始说道之前,先讲个段子。 前阵子和朋友去闽南吃东西,一个当地老板对朋友说:美女,很水哦,要买什么吗? 朋友疑惑的问我:为什么老板既夸她是个美女,又说她是个水货?这也太奇怪了吧! 我一听就乐了,跟她说:现在美女都成通用词了,人家见到你肯定先夸美女啦,至于说你很水嘛,在闽南的意思就是夸你水灵、漂亮啊。 你看,同一句话,语境不同,我跟朋友理解起来就产生了偏差。 我们可以从这件小事儿引出一对概念: ➤ 通用语言 这是用于规定讲话双方共同遵守和理解的语言规范,使其拥有确切的语义。只有大家都只把漂亮的女生叫做美女,那么美女才具有准确的定义,见到女孩子就说美女,那这个词的赞美之意也就逐渐消失了。 ➤ 界限上下文 语言离不开特定的领域环境,只有确定边界,才可以对语言有一个准确的理解。这个环境也就是界限上下文。只有确定了「在闽南逛街,老板在招呼人」这个特定环境下,才知道很水是很漂亮的意思,而不是说一个人是水货。 只有在确定的界限上下文中,通过通用语言,才能确保沟通的高效和准确。我们的故事就从这个定义正式开始。 2 跨专业沟通有点难 两年前我接手了一个课题,基于BIM正向设计的理念,在Revit上做一个机电模型系统图设计管理系统。 土木专业出身,从事BIM开发的我,对机电专业的知识一无所知。于是先去请教资深的机电专业设计人员,这是他们提供的传统模式下的CAD图纸。 对于非专业的我来说,一看这图纸就晕头转向了。怎么才能短时间了解足够多的知识,支撑我开始编写这个系统呢?这确实令我相当苦恼。 我尝试着让机电工程师说明系统图具体要做些什么,但接收到的反馈大多都是专业性很强的术语。虽然他们是优秀的机电设计师,但是软件知识却略显单薄,而我机电的知识也太有限了,不过还是大致摸到了他们的痛点。 配合中了解到,设计师们有着深厚的专业功底,CAD技能也没得说。但传统方法绘制系统图时,往往需要在CAD中绘制系统图图块,在Excel中进行电路系统的计算. 一个项目下来,需要反复修改、绘图、再修改、再绘图。尽管可以在Excel中进行一些简单的逻辑计算以加快设计效率,但这些知识显然无法帮助他们大幅度提高效率。 最初的几次碰头会面让人气馁,但我们在多次的鸡同鸭讲的配合中渐渐看到了实现的可能性。在配合交流的过程中设计师们总会提及:系统、干线、前端、后端等等这些关键词,以及这些关键词怎样配合最终形成了最后的系统图。 那么我就想,是否可以按照DDD(Domain-Driven Design)领域驱动设计的思想,对机电系统图领域进行拆解。 这里稍微解释一下领域驱动设计,它是由Eric Evans在2004年发表的一种软件开发方法论,是「面向对象」思想的延伸,目的是通过深入了解业务领域,包括业务流程、规则和概念等,在把问题领域的概念映射到软件中,创建一个更贴近实际需求的软件系统。 这里说的领域就是一个问题域,用于解决特定环境下的特定问题,它可以是一个项目、一个模块,或者一个具体的业务层,在沟通环节中,对需求进行拆解。 在这个过程中,开发人员不是站在自己的角度看问题,而是站在业务的角度、用迭代的开发模式,不断地与业务专家沟通和协作,对需求进行拆解,并不直接产出代码。 目前,DDD主要用在后端开发、微服务开发。我们进行evit二次开发时是否可以借鉴其思想精髓呢?答案是肯定的。 经过探讨和思考,我初步确定了下面的思路: 点击一级后端,即可以连续生成多个一级后端;框选多个一级后端,即可以生成一个一级前端和一个二级后端。通过联动计算,可以根据末端数据,实时对回路上的其他数据进行更新计算,最终汇总生成系统图。 3 系统图的奇思妙想 有了理论指导和初步构想,我就开始了正式的行动,一共分为四步,分别是领域分析、确定领域模型、设计领域服务、设计系统族。 第一步:领域分析 在跟机电设计师们交流沟通过程中,我们了解到机电系统图具有相当的复杂性。这里面包括: ➤ 图形与计算的多样性 系统图由非常多的微小元件构成,包括开关、继电器、接触器等等,还需要一系列补充说明文字。不同的输入功率数值,会影响计算电流的变化,从而需要进一步选择对应的开关和电缆。 ➤ 上下游数据的关联性 一条干线上会呈现一对多的树形分布方式,回路计算时,需要关联上下游的图元数据,进行整条干线回路的电路计算。 基于这两方面的痛点和需求,我建立了这样的思考: 可以设计一些族作为机电图元的图形表示。通过植入ID参数,程序驱动这些族完成系统图的一系列业务作业。这些族不仅仅是图库,而是作为系统图的数据载体,可以在系统图的图元间传递数据。 根据沟通的结果,我们提炼出了一系列关键词,包括干线、前端、后端等等。接下来就先屏蔽一些微小机电元件的细节,仅以前端和后端作为最小单元进行开发设计,再通过前、后端汇总生成干线图,以及各类系统图。 经过这样的分析,我把一个开发过程分成了两个部分,分别是族和程序,让它们各司其职,再互相帮衬。 接下来我又进一步思考,是不是可以借鉴MVVM(Model-View-ViewModel)开发架构,提出一个MFFM(Model-Family-FamilyModel)模式? 也就是说,结合Revit族的可操作性和低代码特点,将机电系统图这个领域分为三层: Model层:代码不再关注表现层的具体实现,只需要处理业务逻辑,细分为2两大模块。计算模块负责进行前端、后端的联动计算;生成模块负责生成业务逻辑相关的前、后端族,以及最终需要的干线图和系统图。 Family层:通过族的形式,展示系统图图元的几何图形样式,同时族参数承载了几何图形数据。 FamilyModel层:把专业性较强的、与表现相关的计算过程,从代码中分离出来,转移到族里面,利用这些专业性参数,驱动表现层的图形表达。 第二步:确定领域模型 在了解领域相关知识之后,我对领域对象建模,也就是抽象出领域模型的概念,可以进行这样的定义: 前端表示配电箱进线,它既汇总本级后端数据,也将数据传递给上一级后端; 后端表示配电箱出线,它既接受下一级前端数据,也将数据传递给本级前端。 定义之后,就可以着手进行前端、后端、干线等领域模型的确定。 将前端、后端,进行高度抽象为IEnd接口,提供基础数据,包括自身Id和回路信息,回路信息提供回路等级、回路数、回路系数等属性。 设计继承自IEnd的IFrontEnd前端接口,额外定义了上一级后端ID和本级后端ID集合。 设计继承制自IEnd的IBackEnd后端接口,额外定义了本级前端ID和下一级前端ID。 前端根据业务需要,可以细分为普通前端类、潜污泵前端类等等;后端根据业务需要,可以细分为普通后端类、消防风机后端类、双速风机后端类等等。具体实现类的属性方法这里就不再列出了,小伙伴可以根据项目需要定义。 第三步:设计领域服务 这一步主要工作,是识别出领域模型中的一些复杂业务逻辑,把它封装为领域服务,再进行领域服务注入。在机电系统图的设计中,领域服务可以包括关联服务、自动编号,回路计算等核心域服务;也可以包括异常处理、故障诊断等通用域服务。 第四步:系统族设计 根据上述的思路和要求,建立系统族,要能实现展示系统图图元的几何图形,同时族参数承载几何图形数据,添加了包括自身ID、回路等级、本级前端ID、下级前端ID的约束参数,还添加了功率、Kc、单三相等系统参数,以及尺寸标注、文字和各种图元的可见性参数。 最终的前端族和后端族中写入了大量参数,虽然看起来很复杂,但低代码的「族」还是帮助程序减少了大量的代码工作,这也是我是用MFFM架构很大的好处。 4 开发成果使用 最终的开发成果,是Revit上直接安装的插件,分为用于联动计算的计算面板,和用于生成前端、末端的选择设计面板,设计师的全部操作都在这两个面板上完成。 第一步:设计师先根据面板,灵活选择操作,自动生成想要的末端。可以连续选择、设计和生成多个末端,末端参数也可以手动调整修改。 第二步:框选一级末端,生成一级前端和二级末端。 第三步:编辑系统图,点击面板新增两个末端。点击系统图计算器的同级关联,可以让两个新增的末端回路也加入联动计算。同样,点击系统图计算器的跨级关联,也可以让本级前端与上一级的末端联动计算。 另外,特殊末端同样可以一键生成并联动计算。 第四步:当末端有多根单相回路时,按顺序手动输入过于繁琐,可以用插件一键顺延编号和顺延相续。 第五步:一键自动过滤组合,可以生成系统干线图、电气火灾监控系统图、能耗监控系统图、消防设备电源监控系统图。 除此之外,值得强调的是,点击系统图计算器中的计算回路,可以把所有回路的功率和其他相关电气参数全部统计计算,并且把结果也像更上级的末端发送,进行联动。 5 总结:创新与限制 目前,这个插件仍然有一些局限性,由于Revit本身机制的原因,嵌套了很多参数的族,一次性生成大批量图元可能会造成卡顿;另外需要有一定做族经验的机电设计人员,把专业性的图形表达以族的形式表现出来。 这次开发,我借鉴了DDD领域驱动设计的核心思想,通过关注业务需求,把机电系统图进行了领域模块的拆解,降低了整体的复杂度。 同时,借鉴了MVVM模式,开辟了「MFFM」模式,通过族的形式将一部分专业性强、与图形表现相关的计算逻辑从代码中抽离,让程序代码不再关注几何表现,而是专注于实现和业务相关的数据传递,降低了耦合性和开发难度。 其实,不论借鉴哪种思想、采用哪种模式,归根结底还是为了实现系统的「高内聚,低耦合」,才能应对复杂动态的业务需求变化。我认为这两种思路不只能用于这类插件的开发,而是可以推广到很多其他的开发和服务项目中。 今天的分享并不是一套拿走就能用的代码实现,而是告诉小伙伴们遇到一个复杂的、不了解的项目时,如何进行业务需求分析、拆解,有步骤有条理的进行项目开发, 如果你正在解决一个难题而毫无头绪,不妨按今天的步骤试试看:先进行领域分析,再确定领域模型,最后定义领域服务,还可以结合主体软件(Revit等)特点进行配合开发。 BIM不止于机电,我是胡说树,我们下次再见! 好了,胡说树的分享就到这儿啦,希望能给你带来参考。 胡说树不是第一次在BOX分享干货了,上次和我们一起写下的《终于搞清了Revit的5个定位点都是啥?怎么用?怎么对齐?》,帮助很多小伙伴搞清了多年困扰的问题,老孙也把这个重要的知识点补充到了《Revit闪电入门课》里面。 终于搞清了Revit的5个定位点都是啥?怎么用?怎么对齐? 2022-06-30 如果大家对Revit深度知识、机电正向设计这方面的话题感兴趣,我们也会邀请胡说树尽量多地给大家分享他热乎的经验。 如果你有BIM正向设计方面开发需求,也可以联系我们,BOX帮你和胡说树搭个桥。 最后,我们也在陆续邀请「BIMBOX」杯互联网BIM大赛的获奖小伙伴,来分享他们作品的思路和创造过程,如果你也是其中之一,欢迎随时联系我们。 有态度,有深度,这里是BIMBOX,咱们下次见! 60集大长篇!Revit2022全专业闪电入门,一本书的价格雇一名时间保姆 2021-06-16 这届神仙打架?!BIM互联网大赛全部作品公开! 2022-01-10 本篇文章来源于微信公众号: BIM清流BIMBOX 标签:见闻眼界 · 观点 收藏0 分享
理论知识 见闻眼界 2024-08-19 生成式设计:不是参数化设计、也不等于AI 设计 很多人第一次看到生成式设计,都会误以为它是人工智能,或者至少是人工智能的一部分。也有人经常搞混了参数化设计和生 …
暂无评论
要发表评论,您必须先 登录