Electrical prefabrication within BIM
Setting the Scene
For the last few years I’ve been working in the electrical prefabrication environment on a few specific tasks: automatic spool sheet and shop drawing generation, packaging label printing, developing as-built assembly time tracking tools, estimating tools, and the overall improvement of communication between the shop team and design team. This article reviews the tech stack needed to maximize BIM value. I will explain one of the approaches to building data and demonstrate what can be accomplished to boost productivity and profitability of your design and prefabrication teams without Autodesk cloud solutions.
Overview
Prefabrication is a technique that divides complex electrical installations into manageable subassemblies that can be prefabricated off site: wall roughing, light fixtures, standalone transformer wiring, overhead and underground conduits, and a lot more. The design team is trying to make a universal process that reduces time, eliminates paper, and provides accurate and easy to use documents to create assemblies in the Pre-Fab shop as well as in the field.
This is what my team found out: Build data to do prefabrication.
Autodesk Revit (or ACAD) works as a graphical support of projects and the database works as informational support. Layout (outlets placement) in Revit, families should have “room calculation point”, so that every item gets associated with a room number. Tagging is also faster within Revit. All outlets need to be placed on the correct elevation not only to have a section view, but for wire calculation purposes.
Trying to build a library of “smart” families within Revit (keeping everything in a Revit schedule) was not successful for multiple reasons. One of the issues is that there are different versions of Revit. Even if there are a few Dynamo scripts that can help you update your library automatically, they are not as good as you think they are.
Now, this is where the database part begins.
Don’t get frustrated
Obviously, there are going to be a lot of different parameters to identify specific elements in a project: text, numbers, calculations, long texts (for example, a wall rough has 120 parameters). A prefabricated power product line includes brackets, boxes, plaster ring device covers, harnesses attached to devices, panels, j-boxes, struts, and so on and so forth.
Assemblies have to be built precisely otherwise prefabrication is not worth it.
Communication between modelers and a construction site team can be improved by revising shop drawings. But when we are talking about paperless workflow, time tracking, and displaying charts, you need to get away from MS Excel spreadsheets.
There is a Developer mode which allows scripting but the same file wouldn’t work on computers with different versions of MS Office. On top of that, it is impossible to share a file online with scripts attached to it and expect that it’s going to be a multi-platform solution. Coordination, especially when three or more people work on the same project, must not be overlooked. So, no matter how it turns out, basic spreadsheets are inefficient. It’s time to collect data in a simple database.
Database
At this point, it’s worth asking the question: “What would be the best way to group parameters for future utilization?”, or “Which one of those parameters should stay within Revit, CAD or a Database?”. Complete assemblies, including devices and whips, get purchased by contractors who want to benefit from total cost savings offered by prefabrication. Assembly standardization is a keystone at this stage: basic assembly, typical assembly, fully engineered system.
It is widely known that the assemblies depend on the conditions of walls or ceilings (stud size and height, ceiling type, face depth, fireproof, sound proof, waterproof, and so on). Construction schedules are tight and teams are overstretched. Electrical contractor purchasing practices result in using a range of different vendors for multiple reasons: in-stock inventory, competitive pricing on all bids, Information and education on the latest products and services, creative delivery and pickup options. For this reason, assembly configuration is a complicated and time consuming process. Not every box can be installed on any bracket, so we need to find options that work together. We came to the conclusion of using a database as an assembly configurator by creating a multitude of table-sources to pull information from.
At the end of the day we get a table of boxes, brackets, panelboards, etc.
The right technology is the catalyst to the design process.
Once you have your database set up and you are ready to pull parameters from Revit, you can start modeling and laying out engineer design. Make sure that everyone on the team has the same template to start with and the same file of shared parameters. So, we are only using a few basic parameters from Revit. This becomes a base for the procurement of the project.
Overall, there are three types of parameters: base, additional, and calculated. The majority of base parameters come from Revit: item number, room number, etc. Additional parameters are a pretty large category, this is the one that helps you configure a final product. Additional parameters include part numbers, manufactures, wall condition, tolerance, other project standards. Calculated parameters are final parameters that tie BOM files and reports together, these numbers also go into as-built and shop drawings.
Wires also go into database. Usually nobody counts flexible wiring lengths, like MC cables and flexible conduits. However, it is still a pretty solid chunk of money when you think about whip scraps in an average project (2ft*30¢*15,000=$9,000 minimum). Wiring does not physically exist in Revit in the same way that Cable Tray and Conduit do. There are calculations that determine wire size and length, but those are just numbers. The “Wires” Category refers to the annotative wiring that can be created in a View, not as a physically modeled element. If Wires must be illustrated in a 3D model, then the user must create a family to represent the geometry of the wire. The issue is how much effort and time you are willing to spend to find out the value. There are so many factors that influence the cable lengths. Think about obstructions in the building, regulations (cable separation, minimum distances, forbidden zones), slack in the cables, and so on.
For this reason, the true whip length would be reasonable to count within a database environment when you have wall lengths as a standalone parameter. It should be a simple algorithm which solves the track graph. The vertices are traces, and the edges are transitions between points. For trails of structures, the transition was carried out in the place of the closest approach. For pipes, this is through the beginning and end of the pipe. The diagram is a schematic representation of the graph with vertices V={1,2,3,4,5,6} (which is electrical outlets, panels, or conduits and so on and so forth) and edges E={{1,2},{1,5},{2,3},{2,5},{3,4},{4,5},{4,6}}. This way it creates a connection list of electrical devices. In addition to this, it is very important to include wall condition as additional parameters which help with the final assembly configuration.
Now we get to the point where there is external processes that require extractions of data from our tables. In some cases, the final format must be CSV. Therefore, data from the database needs to be exported into the following:
- Spreadsheets and spool sheets printing
- *.nc files for CNC machining
- *.csv files for automatic bender
- *.csv files for label print
It is better to keep all files that have been generated in the same database so you can give it up if needed. With the database we have an opportunity to store links to the documents that have been generated from it. The method is storing the logical address of the file in the file system, but we went further and kept files in SharePoint, which is storing everything in SQL tables. The documents are stored directly as blobs in the database.
End results and future opportunities
I can’t say enough about how important it is to have a good packaging and shipping concept. Even if the entire workflow at the shop is smooth there is still a pretty good chance that you can mess everything up during installation. There are a lot of examples when prefabricated electrical panels have been installed on the third floor instead of on the second. To avoid this situation, do not forget about database we have just created and use it to print out packaging labels.
This workflow is capable of solving a wide range of tasks and therefore is necessary for a modern developer even if it needs some adaptation to the database. Besides updated BOM files, spool sheets, shop drawings, and BIM standards (that you might want to update since you are launching a new workflow), the database would work as a backend. This would be accessed by users indirectly through an external application rather than by an application programming stored within the database itself or by low-level manipulation of the data.
