Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Intro 

Systems allows you to gain increased visibility in the planning, building and maintenance stages of a project. This is because a System in not a physical object, but an entity that connects two or more physical Components together such as Electrical, Heating, Plumbing, etc. This increased visibility into how these entities connect helps to reduce errors and anticipated potential complications before they happen. In short, the Systems Module enhances your team’s communication around projects while creating a record that can be utilized at all stages of the project. 

 

This document will provide guidance about the quickest way to get started using Systems, explore some more in-depth options, and then review the potential next steps for you to work with the dRofus Customer Success team to enable Systems in your projects. 

 

Why Systems?

Getting to Know Systems library.mp4

Imagine that you walk into your local library. You have been to this library before, but now things are much different. Books are everywhere. There are stacks on some shelves, other books are in piles on the floor. These books are not in any specific order by topic, author name, or title. 

 

So, what has made the library different? It is the organization and cataloguing of the books and resources in the library. This organization is the “invisible” variable that makes the library what it is. Being able to walk in and find a specific book by title or being able to browse for a book by topic is what makes a library a profound place to learn and gain understanding. 

 

Now, let’s imagine a well-maintained library. The books are on the shelves and everything organized by a categorization system. This is exactly what Systems are in dRofus. Systems provides an “invisible” organization to a project that allows for everyone to know how and where to find what is important to them, when they need it. This analogy is what we want you to keep in mind as you learn more about the function and importance of Systems. 

 

Definition: 

Systems can at times be a complex topic with challenging ideas. To better support this, here are some key terms that define the essential concepts around Systems. 

For each of the terms, we have highlighted each term in a 3D model of a ventilation unit.

System 

A System is not a physical object, but an entity that connects two or more physical Components together.

In the example, the ventilation Components (duct, air diffusers, etc.) are highlighted, but the air handling unit is not because it is a System Component and not part of the System.

Component 

A Component is an Occurrence of an Item that has been connected to a System.

Outside of the Systems Module, Item Occurrences in dRofus are typically associated with a Room. A Component does not need to be planned in a Room which allows dRofus to capture all objects in the model, not just the room-centric objects.

In the example model, an Occurrence of an Air Diffuser is highlighted as a single Component. 

System Component 

A System Component is a Component that owns and defines one or more Systems.
In the example model, the Air Handling unit is highlighted. This is connected to the Ventilation System as well as being powered by the Electrical System and supplied with water from the Plumbing System. 

System Components may get their number from a classification, or they can get their number from the Item they are an occurrence of.

Item and Occurrences

Everything in the Systems Module is built around Items. An Item that has been placed in a project is known as an Occurrence. An Item can have several Occurrences, and multiple Occurrences can be placed in multiple Systems.
In BIM terms, an Item can be equated to a 'Type' and an Occurrence can be equated to an 'Instance'.
In the example model, each Occurrence of the Air Diffusers are highlighted as a single Item.

Product

Product is the product specific Type you eventually purchase from a vendor. Will contain product data and be attached to the Items. An Item can have several Products connected so you can allocate different Products to different Occurrences of the same Item.

Classifications 

National or international standard that describes codes that are human readable once you become familiar with the codes (Omniclass, Uniclass) 

We recommend this and it should be used in dRofus. You can create a basic classification so that you can make it possible to separate between 

System numbering

System running number

The system number will depend on if you use a number-giving classification or not in the database. Number example can be the circuit number for electrical Systems, or you can define a specific number structure for Systems connected to a ventilation unit:

  • Fresh supply air = 1

  • Return air = 2

  • etc.

In our data model we have suggested that separate the System running number and the running number of the System Component using a colon. So a number for a supply air System may look something like this (if no classification has been used)

0303.109/001:01

Item number

Separator

System Component running number

Separator

System running number

0303.109

/

001

:

01

The System serial number is '01'. Identifying that this is the first System connected to the System Component.

Items Types Serial Number

A Type classification will provide a direct and unique reference to the designed object including the designed performance. The designed Type will also match a corresponding Product. E.g. the 200 electrical outlets could be solved be white double outlets. They could be documented one place - on the Type, regardless of what electrical System they are attached to.

Components Serial Number

When an Occurrence of an Item is created, will it automatic get a serial number after the Item classification. Together, the Item classification and the serial number is absolutely unique in the database. 
Since the number/code is unique, we can use this as an address in the central processing System, flow balancing and documentation. 

When we combine all these classifications, we have a human readable code that gives us a lot of information about a Component. 
Location (A01) - Building A floor 01
System (M.002) - Mechanical unit number 002
Component (23-33 25 13 11) - Customized Indoor Air Handling Units (OmniClass 23) 
Serial number (001) - Database generated serial number 

Complete code: A01+M.002:01 - 23-33 25 13 11/001

Location code

System Component, Air handling unit

Supply air, System

Component code - OmniClass 23

Serial number, first Occurrence of 23-33 25 13 11

A01

M.002

01

23-33 25 13 11

001

 

System Hierarchy

In BIM and in real life, 'System Components' can have many systems, but they are also components cross domain and can be connected to other systems. 

An air handling unit is normally a system component as it will be the owner of systems as:

  • Supply air

  • Return air

  • Air supply

  • Exhaust

However, the air handling unit can also be a component in an electrical system as it needs power supply from a electrical circuit. This graph of connections can be viewed hierarchically in the Systems module.

In the image below we are looking at the electrical domain and can see that the Air handling unit is connected to a Main power panel through a sub panel. By looking at the properties to the right we can also see that the Air handling unit is the system component for Supply air, Return Air, Exhaust air, and fresh supply air. 

 

  • No labels