I took a long time to write this entry, because I did not know how I could start the series devoted to the Trimble Quadri platform. To begin with, after many attempts, I decided to describe a functionality that is unique in its own way.
So I will start with the functionalities that support self-control in the project.
This is the first entry in a series dedicated to the functionalities of Trimble Quadri platform. Hopefully at the end of this series you will understand why this is one of the leading, if not the best CDE platforms on the market.
About Quadri I also mentioned in the context of model driven management: LINK
Table of contents
In direct terms, poor self-control causes the most problems in a project. It is often treated superficially or is not carried out at all. If the self-inspection had been conducted better, then there would be fewer collisions detected in the multi-discipline model. This would also imply that there would be fewer geometric inefficiencies and not enough information at a later stage in the project.
The key to the good control
The key to a well-conducted self-control is checking the designed model in the context of other designed models in real time (being more optimistic, once a day) based on a previously defined checklist. The task may seem trivial to some, and difficult to accomplish for others.
If the discipline designer works in the authoring software in which he designs, he saves the design data in a native file on the local disk. The design result, at a certain point in time (milestone), is delivered by him to a common database. Such a characteristic point in the project can be multidisciplinary control. For the purposes of the entry, let’s assume that multidisciplinary control takes place once a month.
The design result may change several times over the course of a month. This is very common in the early stage of the project, when we are just developing the concept. In the BIM world, we would call this period between LOD (MMI) 100-200. Therefore, it often happens that the project result is out of date after a few days from the export from authoring software.
In this case, the designer is forced to make direct contact with another designer. And as you can imagine, in most cases, an attempt to contact is made only when it turns out that a collision between industries has been detected during an multidisciplinary meeting.
The path a file has to travel from one designer to another is often unauthorized. It often requires a designer to spend time generating a file that is hosted by a program operated by another designer. In the long run, such a process increases the risk of tedious and time-consuming control.
Direct API connection
In this case, Quadri offers a solution. Trimble Quadri allows you to save the designed model (according to ISO 19650: work in progress) directly on the platform. This is possible thanks to the direct connection of Quadri’s API (Application interface) with authoring software. The only change for the designer is that in addition to the file saved locally as backup, he should send the graphical result from his program (via the add-on dialog) to Quadri. Preferably as often as possible.
It’s hard to convince all designers to work this way. However, let’s assume that the largest disciplines work this way. They save their design result on the Quadri platform. Why the largest? Because each change in the solution at a later stage is simply more expensive. It is therefore worth carrying out a good self-control, starting with these disciplines.
How, then, can we be sure that the design basis with which the designer compares his result is in the final version?
Server
Here we use Quadri functionality. All the results are on the server (let’s call it a cloud server to simplify). In short, the platform allows you to save and present design results in a graphical manner in one place almost in real time. It all depends on how often the designer presses the “send” button in his program (add-on). In more intense phases of the project, updating the design model may take place from several to several times a day. In this case, designers have always access to the current version of the data.
When we work on the basis of file exchange, delivering files and updating the central model is very difficult and time-consuming. This is due to the fact that in the case of large models, the data processing and upload time is correspondingly extended. What in the case of a large number of updates can significantly reduce the effectiveness of such a solution.
Thus, in the context of conducting correct and effective self-controls, it is crucial to intensify iteration with other disciplines through real-time interaction. Working with data on a shared (cloud) server makes it easier for us.