我怎样用Revit自动生成机电系统图？

提起绘制机电图纸，大家最头疼的恐怕就是绘制系统图了，因为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等）特点进行配合开发。

• 0人已收藏

• 0人已打赏

  免费
• 0人已点赞

• 分享

  复制链接 新浪微博 微信扫一扫