Interoperability with Other Disciplines
Architects must continuously share their design with many project stakeholders during the whole project lifecycle. Today they spend more time on communicating their design intent with other project participants than on their actual design work. To further complicate matters, the type and the content of the required data often differs greatly depending on who wants to use it.
The BIM model provides the ideal platform for sharing the building data inside and outside of the office. IFC and other file protocols allow the BIM program to communicate with diverse applications, such as structural, energy analysis and collision detection programs.
This chapter describes how ARCHICAD supports different means of communication outside the architect’s office.
BIM as a Platform for Communication
Designing, constructing and maintaining a building is usually a very complex process that requires the close co-operation of several people working in different fields. The figure below shows the many possible participants of a building project, including the building owners, developers, contractors, engineers, facility managers and of course the architect. The architect has a very important role in this hierarchy, since he/she is the only one who continuously has to provide data about the current status of the design for all the other project stakeholders. If an architectural firm does not adapt to this communication-centric and collaborative world, it will slowly be cut out from big projects.
The BIM Model as Platform for Project Communication
The BIM method offers a very efficient and automated communication platform for the building industry. By using the BIM model in practice, the architect will not be the only beneficiary of the virtual project. The owner and all the members of the project team also benefit. This notion, of moving from a “file-based environment” towards a “data-based environment”, is what we call a BIM project.
The BIM model, when imported into external analysis programs, allows a wide range of analytical activities including structural analysis, energy efficiency analysis and code checking (collision detection). These tools help minimize the risk of construction and design errors.
One of the key problems of building lifecycle management is that project participants require different types of information from the architect. Data that the construction company needs are quite different from those required to operate a completed building. ARCHICAD is able to communicate with other programs via several file formats.
ARCHICAD supports many File Formats
Importing Data to ARCHICAD: Merge vs. Link vs. Open
The possible ways of using the model data, CAD drawings and reports received from another application in ARCHICAD are the following:
Merge
Use Merge to add the model or drawing content (or part of it) to the currently running ARCHICAD project. Merged model data are converted into native ARCHICAD elements, which can then be used as a protected or editable reference. The imported content, used as a reference, is separated from the host project elements, and can be displayed together or independently from the original project data by choosing a visualization technique.
Link
As another “reference” possibility, you may open a received 3D model as a new ARCHICAD project first - e.g. to visually filter out the parts you will need - then link the project, or a part of it, to your current project as a hotlink, which will serve as (non-editable) content. Depending on the file formats you can also use XREF and/or Drawing connection to link external drawings into ARCHICAD projects.
Open
The Open command launches a model or CAD drawing as a separate ARCHICAD file, independent of any other project currently open in ARCHICAD. This imported file can be added later as a reference to the appropriate part of another ARCHICAD project as mentioned before.
GRAPHISOFT offers outstanding tools that support a smooth all-round workflow for architects. But architects don't live in their own world; they have to cooperate with partners in other segments of the wider AEC workflow.
Nowadays, one of the top wishes from vendors in ‘BIM’ surveys is improved BIM solutions for interoperability with other software applications:
•Architects have different requirements for their BIM than engineers: modeling conventions and the model’s internal logic may differ significantly. It is important to note that the architectural BIM is NOT the same as the BIM of other disciplines.
•Typically, engineering applications (for example the structural, the mechanical and energy design applications) are different in each country. Engineers naturally prefer programs that support the standards of their own country, and these are usually specific local applications.
How can we ensure that an architectural program like ARCHICAD is able to work together with hundreds of local engineering programs? Which conditions must be met to achieve interoperability? There are two key conditions for interoperability to work:
1)Support for the so-called „reference model”, and
2)Support for an open-source, yet standardized data exchange format (with quality requirements)
The OPEN BIM concept provides an answer. Simply put, OPEN BIM is the implementation of the reference model on an open platform.
Each discipline is responsible for its own work. For example, the structural engineer is responsible for the load-bearing parts of the building which she/he calculates according to local design standards. This consideration requires that each discipline be able to edit and modify its own model, while using the others’ models only as a protected reference alongside their own. The models coming from the various disciplines, even if they may seem similar at first glance, are in fact quite distinct in their details. For example: the architects define the contour of a slab, using a slab element, while the structural engineer, doing design calculations with hollow core concrete slab panels, defines the final load-bearing structure. But the models of the two disciplines differ in several ways: in the element type used, size, number of elements used, level of detail in the intersections, and the relative positions of the elements.
A basic tenet of model referencing is that data loss, whether geometrical or other data, is not permissible.
The “geometry” part means that a referenced model element must be shown in our own project with its original geometry and position. The “data” part means that the reference model has to contain all data relevant to collaboration with the other discipline. For example, relevant data for an architect include the exact material and profile data defined by the structural engineer in the structural model.
How do we choose the right format for interdisciplinary collaboration? Which requirements and considerations must the format fulfill?
•It must support the elements’ 3D representation.
•It must be able to store data.
•It is not enough for it to include a large database; the database must be filterable, so that each discipline can extract just the data that it considers important.
•It must fulfill the requirements of the reference model concept.
•The format code must be open to any software developer. This is necessary to ensure global collaboration among local programs, as well as the major, internationally used ones.
•To enable fast code implementation, the code must have a simple scheme structure.
•In order that the code be understandable and implemented anywhere in the world, its language must be in English. In addition, however, it should be possible to localize, for example, the standard properties for various countries.
Among the various available file formats, it is Industry Foundation Classes – or IFC – which meets all of these requirements. IFC has been developed by buildingSMART, a non-profit industry-led organization, since 1994.
BuidingSMART is an alliance of organizations dedicated to bring about a coordinated change for the improvement of productivity and efficiency in the construction and facilities management industry.
For more information, see: http://www.buildingsmart.com/.
BuildingSMART promotes effective information exchange among all software platforms and applications serving the AEC+FM community by adopting BIM. Major application vendors in the fields of Building Information Modeling, Structural engineering, HVAC design, thermal analysis, code checking, quantity take-off and cost estimation have all incorporated IFC compatibility into their products.
GRAPHISOFT has been developing IFC since 1996, and continues its pioneering work by implementing and supporting the latest standard version and its major subsets (called “Model View Definitions”, see later). The building model can also be exported back to the many other systems that support IFC. More than 180 applications have been already registered as IFC file supporters at buildingSMART.
For more information, see: http://www.buildingsmart-tech.org/implementation/implementations.
An IFC Schema is a particular version of the IFC standard. ARCHICAD supports both the IFC 2x3 and IFC 4 Schemas.
An IFC Schema is basically a large code. Imagine a big thick book, in which each chapter describes a particular data exchange workflow. Each of these “chapters” is called a “Model View Definition” (MVD). An MVD defines a legal subset of the IFC Schema and provides implementation guidance for all IFC concepts used within this subset.
For example:
•The “Coordination View” chapter includes the specification for sharing of building information models among the disciplines of architecture, structural engineering and building services.
•The “Basic FM Handover View” chapter defines the data requirements for facility management, for example how to describe the space containment and the base quantities of its members.
•The “Space Boundary Add-On View” chapter sets the rules for sharing models for energy analysis purposes, for example how to export the relation between the spaces and the building elements that surround them.
•The IFC4 Schema further divides the Coordination View into two separate Model View Definitions:
IFC4 Reference View: Suitable for BIM workflows based on reference models, where the exchange is mainly one-directional.
IFC4 Design Transfer View: Provides building information with support for editing of interconnected elements: for example, an architect providing building design information to an engineer to make geometric modifications. Note that the Design Transfer View is not meant for round-trip model exchange scenarios.
The above mentioned MVDs are the most important ones for architects and architectural applications:
•In the U.S., the Space Boundary-based IFC data exchange is required for federal contracts;
•The ‘Basic FM Handover’-based IFC database is the starting-point for the COBie (Construction Operations Building Information Exchange) documentation standard required in many English-speaking countries; and
•The currently most widely implemented IFC view is the ‘Coordination View’, the foremost tool for sharing building information using the reference model concept among the different disciplines all over the world.
ARCHICAD supports all of these major Model View Definitions.
How can the users of design software be sure that their software is compliant with the proper IFC standard and can truly collaborate with other programs? For this purpose, there are official certification processes for each MVD, run either by buildingSMART or by the organizations who defined the actual MVD. In this certification process, the participant software products are tested for how well they fulfill the requirements of the MVD.
GRAPHISOFT is committed to ensuring that its products are professionally certified. To this end, GRAPHISOFT takes part in the key “challenges” which test IFC capabilities, and participates in the official buildingSMART-operated certification processes.
Typically, software users also test how well they are able to share their models with other professionals. The general conclusion is that IFC works on the vast majority of projects, provided that the users know and learn the interoperability capabilities of the BIM applications they use.
Thanks to the IFC open platform, all disciplines are able to participate in the data-exchange workflows of all phases of 3D model-based development: schematic design, design development and construction documentation.
A real collaboration workflow is bi-directional and dynamic – that is, there are continuous round-trip iterations. Thus, it involves not just the simple exchange of models in both directions. It also involves complex operations, such as cyclically repeated comparison and update processes.