Data Design System ASA (DDS) has developed CAD software for the building industry since the early 80's. DDS has since the beginning chosen a different approach than most other systems to solve the complexity related to the design of a building and it's contents. Instead of defining a classical CAD model, DDS design a 3D-information model of the building. This information is the actual objects that the building consists of, and the relations between them. The type of information stored, are not only information for producing drawings, but also the necessary information for relevant calculations such as bill of quantities etc.

A printed drawing produced by the DDS system is only one of many types of presentations that can be extracted from this intelligent building model. When creating this information model, the user will usually start by defining the building plan. The system has a built in trade intelligence that controls the input and adds information as the users enter information. Once the plan is complete, a 3D building information model has, in reality, been constructed. All relevant drawings, calculations and data can be generated from this model. Both entering and editing of the information model is of course done using trade terminology that the user is familiar and comfortable with. Standard regulations and local building practices from each trade are built into the company's individual "Partner" application packages.

DDS has been focused in the interoperability between the different crafts/areas within the building industry. This has resulted in a number of highly specialised applications, also know as the "DDS Partner" family:

• HousePartner
• TerraPartner
• InteriorPartner
• HVACPartner
• ElectroPartner

One of DDS objective is to produce applications that are completely integrated and open to data exchange also with other systems. Today’s "DDS Partners" are certified for the IFC 1.5.1 architectural model, i.e. an IFC import and export roundtrip is possible. However element’s that is not yet defined in IFC or the typical architectural model is either lost or converted to geometry (i.e. electrical elements).

When a building model is passed from one application to the next through IFC is defined as important that information is not lost (roundtrip compliant in IFC). However it’s important that relevant information also can be added to the model.

The present IFC model does not support many electrical objects. An electrical model within IFC would be a milestone regarding export and import of CAD construction drawing’s where electrical appliance is drawn. The technical installations (electrical and HVAC) in a building represent in many cases more than 40% of the cost. When it comes to building maintenance later on in the "buildings lifecycle" it’s very important to also have an "as built" documentation. Many of today’s Facility Management systems have links with architectural software. However the information for the electric installations are very poor in these systems.

In order to make IFC a big success one must of course focus on the actual information flow in a building design and maintenance process. Most architectural software allows the users to place "symbols" for important "electrical functions". However the model of the building is transferred from the architect to the electrical and HVAC engineers to do the professional planning. The value of good communication in a planning process is much higher between the architect and the electrical engineer, than between two electrical engineers working with software from different vendors.

If this information could be transferred back also to the architectural software, the value of the information model would be significantly higher. Even if the architectural software are not design to handle all the "intelligence" of a technical installation, the information for as documentation and for maintenance of the building would be important. As an example, the user should at least be able to "click" on a power outlet and get information for which central and circuit this is connected to.

DDS therefore feel that the best approach for the further evolution of IFC for electrical should be aimed towards a two-way information exchange between architectural software and electrical installation software. If not, the implementation can easily get to complex and we end up with an IFC specification that are designed for information exchange between electrical software which is not for the benefit of typical building projects.

If the architectural software can build a basic and minimal "IFC info" into their electrical symbols that is also transferred via. IFC, the professional systems can be user to complete and document the installation. The architectural software can then receive the finished installation with additional information attached more or less as a electrical "proxy" object, with useful information for both documentation and facility management. Whether or not the actual cables are displayed of not is less significant. In other words: Electrical symbol in drawing will contain info like circuit and central connected to the appliance showed. This will give the user a complete overview of the electrical equipment in the building.

Architect/designer ®

• Design building.
• Electrical appliance, i.e. outlet, light cooker,, switch, oven, TV, suggestions is drawn.
• IFC export to electrical designer

Electrical designer ®

• IFC import
• Electrical appliance is adjusted and gets electrical properties. Circuits are made.
• IFC export to architect (in many cases also including HVAC design)

Architect/designer ®

• IFC import
• A full and comprehensive documentation of the building and it’s technical functions

It’s at this stage the facility manager have a great benefit by importing the CAD drawing directly from the electrical designer or from the architectural software. Every installed electrical object has placement, circuit id, central and other general electric properties like voltage, current, fuse connected etc. All these values will be useful when managing building.

A mean to reach this objective is to extend our co-operation with IAI to also assist within the input of electrical objects into the IFC model.

DDS suggests electrical features implemented in the existing IFC model. As a pragmatic approach DDS will proceed with the electrical data model concept at hand. IFC roughly have to classes which off course inherence from IfcRoot:

• IfcObject
• IfcPropertyDefinition

All data within the classes is OPTIONAL, and they are not locked for future changes.

IfcElectricalElement class if a part of the IfcObject inherence hierarchy:

Each electrical equipment belongs in their own category with mutual feature. These categories will be presented as classes and with inherence/qualities from IfcElectricalElement.

It’s important to recognise that the electrical equipment/element is at this stage without any electrical voltage properties, because the equipment is not yet connected to any electrical supplier. This way any designer may "throw out" electrical appliances without any electrical expertise. The electrical elements are electric symbols already known to most designers.

IfcElectricalElement is the mother class of all electrical element equipment and describes in general electric NON electrical settings:

MountningTypeEnum : enum

{

iSURFACEMOUNTED,

iHIDDENMOUNTED

iFLUSHMOUNTED,

iUSERDEFINED,

iNOTDEFINED

}

InputElectricCurrentTypeEnum : enum

{

iALTERNATING,

iDIRECT,

iNOTDEFINED

}

InputPhaseTypeEnum : enum

{

iONEPHASE,

iTREEPHASE,

iUSERDEFINED,

iNOTDEFINED

}

PlacingTypeEnum : enum

{

iROOF,

iWALL,

iFLOOR,

iNOTDEFINED,

iUSERDEFINED

}

MountningTypeEnum : enum

{

iSURFACEMOUNTED,

iHIDDENMOUNTED

iFLUSHMOUNTED,

iUSERDEFINED,

iNOTDEFINED

}

PlacingTypeEnum : enum

iROOF,

iWALL,

iFLOR,

iNOTDEFINED,

iUSERDEFINED

PhaseTypeEnum : enum

{

iTREEPHASE,

iONEPHASE,

iUSERDEFINED,

iNOTDEFINED

}

HasGround : OPTIONAL bool

NominalPower : OPTIONAL double in [Watt]

NominalCurrent : OPTIONAL double in [Amp]

NominalVoltage : OPTIONAL double in [Volt]

MaxCurrent : OPTIONAL double in [Amp]

MaxDimensionLead : OPTIONAL double in [mm▫]

MaxVoltage : OPTIONAL double in [Volt]

NumberOfPoles : OPTIONAL int

IfcCentral is the commen place for circuits and electric elements to connect. A Central in drawing may be a simple fusebox or even an large empty place where electric circuits are made.

CentralTypeEnum : enum

{

iHIGHVOLTAGECENTRAL,

iMEDIUMVOLTAGECENTRAL,

iLOWVOLTAGECENTRAL,

iUSERDEFINED,

iNOTDEFINED

}

IfcCircuit are always connected to IfcCentral and is in full given by type of circuit in central:

CircuitTypeEnum : enum

{

iINLET,

iNEXTCENTRALSUPPLY,

iLIGHT,

iSOCKET,

iLIGHTANDSOCKET,

iHEAT,

iCONTROLCURRENT,

iENGINE,

iEIB,

iPLC,

iLOWCURRENT,

iFIREALERTSYSTEM,

iTELEDATA,

iRESERVE,

iUSERDEFINED,

iNOTDEFINED

}

All electrical circuits have a safety fuse. Fuse it not normally drawn, but a part of the electrical equipment when it’s connected into a circuit. Therefore this class is essential when we will explain and set the properties of each equipment. We also take in consideration that a circuit may in some cases be without a fuse, e.g. low voltage circuit.

CircuitPlacementEnum : enum

{

iCIRCUITSTART,

iCIRCUITEND,

iNOTDEFINED

}

FuseFunctionEnum : enum

{

iOVERLOAD,

iSHORTCIRCUIT,

iOVERLOADANDSHORTCIRCUIT,

iUSERDEFINED,

iNOTDEFINED

}

FuseFunctionEnum : enum

{

iEARTH,

iEFFECT,

iEFFECTPATRON,

iENGINE,

iNOTKNOWN,

iUSERDEFINED

}

A fuse always has some kind of characteristic connected to how fast/slow the fuse react to release current. In this case we are in need of an international standard table to present all the qualities, we use char so that all types may be represented.

FuseCharacteristicType : OPTIONAL char

SwitchOffCurrent. : OPTIONAL double in [Ampere]

ShortCircuitCurrent. : OPTIONAL double in [Ampere]

SwitchOffTime. : OPTIONAL double in [sek]

Typically a light switch, but other switch definition may be helpful.

SwitchEnumType : enum

{

iLIGHT,

iMAIN,

iFIRE,

iREMOTE,

iPHOTO,

iREGULATING,

iUSERDEFINED,

iNOTDEFINED

}

Electrical tap point.

OutLetBaseTypeEnum : enum

{

iDIRECT,

iPLUGGED,

iNOTDEFINED

}

OutletTypeEnum : enum

{

iPOWEROUTLET,

iTELECOMOUTLET,

iDATAOUTLET,

iTELEVISIONOUTLET,

iUSERDEFINED,

iNOTDEFINED

}

Different light types and special mounting.

LightMountingTypeEnum : enum

{

iROOFMOUNTED,

iWALLMOUNTED,

iSUSPENDEDCEILINGMOUNTED,

iFLUSHMOUNTED

iUSERDEFINED,

iNOTDEFINED

}

LightTypeEnum : enum

{

iLIGHTFIXTURE,

iLIGHTINCAND,

iSPOTLIGHT,

iLIGHTBUS,

iUSERDEFINED,

iNOTDEFINED

}

LightPendulumLength : OPTIONAL : double in [mm]

NumberOfTubes : OPTIONAL : int in [piece]

General heating types

HeatingTypeEnum : enum

{

iOVEN,

iCABLE,

iELEMENT,

iFAN,

iRADIATOR,

iUSERDEFINED,

iNOTDEFINED

}

Both low- and medium voltage sensors.

SensorTypeEnum : enum

{

iLIGHTDETECTOR,

iFIREDETECTOR,

iHEATDETECTOR,

iMOVEDETECTOR,

iWATERDETECTOR,

iMOISTDETECTOR,

iUSERDEFINED,

iNOTDEFINED

}

Cable which connect electrical elements into a circuit

CableTypeEnum : enum

{

iHIGHVOLTAGECABLE,

iMEDIUMVOLTAGECABLE,

iLOWVOLTAGECABLE,

iUSERDEFINED,

iNOTDEFINED

}

CableMaterial : enum

{

iAL,

iCU,

iAIR,

iUSERDEFINED,

iNOTDEFINED

}

CableCurrentAbility : OPTIONAL : double in [Amp]

CableLeadDiametre : OPTIONAL : double in [mm▫]

CableLength : OPTIONAL : double in [mm]

Housekeeping electric stuff.

ElectricalApplianceTypeEnum : enum

{

iRADIO,

iTELEVISION,

iFRIDGE,

iDISHWASHER,

iWASHINGMACHINE,

iMICROWAVE,

iCOOKER,

iOVEN,

iLAMP,

iUSERDEFINE,

iNOTDEFINED

}

Engine is a mutual element class and includes both motor and generator.

EngineTypeEnum : enum

{

iMOTOR,

iGENERATOR,

iTURBINE,

iUSERDEFINED,

iNOTDEFINED

}

EngineHouseTypeEnum : enum

{

iSEALED,

iOPEN,

iUSERDEFINED,

iNOTDEFINED,

};

EngineWindingTypeEnum : enum

{

iSYNCHRONOUS,

iASYNCHRONOUS,

iSERIESWOUND,

iPARALLELWOUND,

iUSERDEFINED,

iNOTDEFINED

}

StartCurrentFactor : OPTIONAL : double

DataTeleTypeEnum : enum

{

iCOMPUTER,

iPRINTER,

iSCANNER,

iTELEPHONE,

iTELEFAX,

iCAMERA,

iMONITOR,

iLAPTOP

iUSERDEFINE,

iNOTDEFINED

}

When electrical equipment/element is connected into a circuit they get several new kinds of qualities. These qualities are based on the information given by the IfcElectricalBaseProperties class and the derived classes.

The most needed electrical properties are included within IfcElectricalBaseProperties. This is typical type of current, current size, voltage size etc. All these values are actually inputted to the element.

ElectricCurrentTypeEnum : enum

{

iALTERNATING,

iDIRECT,

iUSERDEFINED,

iNOTDEFINED

}

ElectricLoadType : enum

{

iVARIABLE,

iSTABLE,

iNOTDEFINED

}

EffectiveCurrent : OPTIONAL : double in [Ampere]

EffectiveVoltage : OPTIONAL : double in [Volt]

Effect : OPTIONAL : double in [Watt]

MaxTotalVoltageDrop : OPTIONAL : double in [%]

Temperature : OPTIONAL : double in [Cº]

SameTimFactor : OPTIONAL : double

UtilizationFactor : OPTIONAL : double

Inherits from IfcElectricalBaseProperties

IfcElectricalACProperties provides equipments with alternating current properties.

PhaseConnected : OPTIONAL : int in [Piece]

Frequency : OPTIONAL : double in [Hertz]

CosinusPhi : OPTIONAL : double in [Rad]

Inherits from IfcElectricalBaseProperties

IfcElectricalDCProperties provides equipments with direct current properties.

NumberOfConnectedPoles : OPTIONAL : int in [Piece]

The basic idea is to make a model that can manage a single electric appliance object and multiple electric equipment’s wrapped into a circuit. It’s important to be able to harvest the electrical object data into a circuit and therefore the composition of Elements versus Properties must be manageable.

Reversible import and export within these attributes is required. Together with IAI, DDS will be able to make a relatively easy electrical IFC where these capabilities come to live.