Remote collaboration with Revit
While technology makes it easier for people to work together, people are spreading further and further apart. Employees are dispersed between multiple offices, work from home or on the road, and sit in different cities and different countries. For example, CASE has 40 people working from nine cities in North America, South America, and Europe; HP has approximately 300,000 people working from more than 170 countries.
Remote collaboration with Revit remains a major pain point. The problem is far from solved, but there are a number of ways to approach it without getting on a plane. In this article we discuss some of these approaches.
Types of collaboration
There are two primary ways to use Revit remotely. The first is to use virtualization. In essence, you use your computer to virtually control a computer already inside the local network—a bit like screen sharing. The second way is to send Revit files across a wide area network (WAN).
The advantage of virtualization is that you can interact with others on the network as if they were all local to one another. The advantage of WAN collaboration is that it works with most existing IT infrastructures. We’ll save virtualization for another article and for now focus on the best ways to use Revit across the WAN.
Configuring models for collaboration
In general, collaborating on a model over a WAN is much like collaborating on a model within your local office. The Revit Server has a central model—that is, the definitive copy of the project. Users copy this model onto their local machine and check out worksets. The worksets effectively block others from making changes to certain parts of the central model while the user is editing elements on a workset. Once the user returns the workset, all the modifications are synced with the central model and the design marches forward.
The main difference between collaborating over a WAN compared to working locally is the capacity and latency of the links between the local machines and the central servers. This difference can be orders of magnitude. A file that takes seconds to send on a local network can take minutes or even hours to send outside the network across a WAN. For this reason, file size matters.
The model should be clean and well structured. Purge unused elements, make sure families are lightweight (generally you want them less than 1MB), and resist the temptation to over-model. Avoid linked files such as linked AutoCAD files, point clouds, and texture images. If linked files are used, put them on a separate worksheet so users can control whether they are downloaded. Performance can be further increased by occasionally compressing the central file, which can be done in the dialogue box that opens when you synchronize with the central model.
To avoid synchronization conflicts, the model needs to be segregated in such a way that users can checkout the elements they need without blocking others from doing so. There are a range of strategies for segregating the model. In general, related elements should be grouped on the same workset. The grouping should follow how the team works. So if one person is responsible for casework, put all the casework on a worksheet together. But if the fit-out is being done floor by floor, divide the casework between the appropriate fit-out worksheets. Be careful about over-segregating the model since having too many worksheets (and poorly named worksheets) makes it hard to ensure people are contributing to the correct worksheet.
On large projects it may be necessary to use multiple models. To avoid coordination issues, the models should not be dependent upon one another. Ideally each model would encapsulate an isolated aspect of the project. For example, a multi-tower development might place separate buildings in their own independent models.
Whatever the segregation strategy, it is important that the project team understands the model structure. This is especially pertinent if those working remotely have come from outside your organization, and are therefore, unfamiliar with your working methods. These project standards should be agreed upon at project kickoff and then documented in the BIM execution plan.
Network configurations
There are a number of ways users can set up a WAN connection. The easiest is through a VPN connection. Once users establish a VPN connection to the network hosting the central server, they are essentially part of that network. They can sync and check out worksets just like they would on the local network. The major downside is that the connection is being made through the internet rather than the local network. This method can become extremely slow if the connection is bad or the VPN swamped with other connections.
Revit Multisite gets around some of these problems by creating local copies of the central server. These local copies are called accelerators, and each office can have their own accelerator. Users get the speed benefit of working locally, while the accelerators send data between each other in the background to ensure everything is in sync. There is some cost and time involved in setting up the accelerators, so unlike a VPN this isn’t a solution you can quickly access on the road. But for permanent workplaces, this solution works well. Users may find the multi-server/accelerator setup confusing, so some time should be set aside to teach best practices.
Both VPN collaboration and Revit Multisite can benefit from WAN acceleration. Essentially a device like Panzura Controller or Riverbed Stealhead is placed at either end of the connection between offices. These devices compress the data as it is sent, which significantly reduces the amount of data being sent. While effective, they are unfortunately expensive, so perhaps not suitable for every office.
HP Remote Graphics Software
We’ll go into virtualization in depth in a future article. For now, suffice to say, setting up VPNs and server accelerators are not the only way to collaborate remotely. If you want to experiment with virtualization using the infrastructure and equipment you have today, you might want to try HP’s Remote Graphics Software (RGS). With RGS on HP Workstations that offer Intel® Xeon® processors and Intel® Core™ processors , you can log on to a remote workstation and control it from wherever you are. This means that the workstation can be on the same local network as the Revit Server, allowing super fast model syncing even though you are not part of the local network.
Unlike other screensharing software, RGS is optimized for graphics-intensive workflows like Revit, so responsiveness is great. It also includes HP Velocity, which improves the remote connection on poor network connections. Its advanced compression algorithm reduces bandwidth requirements by as much as 50 percent, and it supports multiple displays and remote USB connections.
In addition to using RGS to explore virtualization, you can use it to collaborate with colleagues on a shared screen in real time, which makes it a nice tool for remote design reviews and remote classrooms.
One more thing that is really cool about the just-released RGS 7.0: it has a special set of features for Windows 8 tablets, including customizable multi-touch commands (turn swipes into hotkeys and pinches into camera zoom), and the ability to use the entire screen as a track pad.
HP RGS is available for around $200 per seat. However, if you have an HP Z Workstation, it is included for free. You can download it at www.hp.com/go/rgs.
