我怎样用Revit自动生成机电系统图?
逃课的单杠
2023年05月04日 10:21:29
只看楼主

提起绘制机电图纸,大家最头疼的恐怕就是绘制系统图了,因为Revit本身没有提供这样的功能,而传统方法是人工绘制、人工计算的方式,绘制的过程费事费力不说,反复修改的过程也是很让人头大,经常出现绘图遗漏、计算错误的情况。 当我们把基于Revit的机电正向设计引入到流程,这个问题就更加麻烦,因为Revit本身没有提供系统图生成的功能,BIM绘图和系统图就得走两条并行的路线,模型修改的时候就会让原本麻烦的流程更加麻烦。

提起绘制机电图纸,大家最头疼的恐怕就是绘制系统图了,因为Revit本身没有提供这样的功能,而传统方法是人工绘制、人工计算的方式,绘制的过程费事费力不说,反复修改的过程也是很让人头大,经常出现绘图遗漏、计算错误的情况。
当我们把基于Revit的机电正向设计引入到流程,这个问题就更加麻烦,因为Revit本身没有提供系统图生成的功能,BIM绘图和系统图就得走两条并行的路线,模型修改的时候就会让原本麻烦的流程更加麻烦。
他自己开发了一套电气专业的「机电模型系统图设计管理系统」,还凭借这个成果,拿下了第二届「BIMBOX」杯互联网BIM大赛「专项难题攻克赛区」的一等奖。
这个插件完成了前后端的数据联动,设计师只要在两个面板之间输入参数、点击按钮,就可以对系统图完成「一键生成、一键合并、一键编号、一键排序」的功能,帮助设计师简单做出完成度非常高的系统图。
另外,当时让所有评委竖起大拇指的,不仅仅是这个开发成果本身,而是胡说树借鉴了 DDD (领域驱动设计)的思想,还有从MVVM架构衍生而来的 MFFM (Model-Family-FamilyModel)模式,具有很强的推广性,可以在很多项目中,帮你快速解决开发工作,甚至是一般BIM工作的复杂难题。
别看DDD和MFFM这两个名字听起来陌生,通过今天胡说树的分享,作为代码白痴的我们都完全可以看懂并理解,无论你是否从事开发工作,都一定能给你带来参考和帮助。
接下来,就有请胡说树亲自来分享一下,一开始对系统同完全不懂的他,是怎样一步一步完成这个插件的开发的。
        
所谓「授之以鱼不如授之以渔」。接下来我以机电系统图开发这一实际案例,讲讲从我开始接手这个项目,是如何一步一步进行项目拆解与开发的。
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等)特点进行配合开发。

免费打赏

相关推荐

APP内打开