Reflections at Keppel Bay ... the crowns are an architectural feature and an area of complexity.
IFC bridges gaps in interoperation
A common language to ensure interoperability between software is the need of the hour, says buildSmart ME president TAHIR SHARIF, while highlighting how adopting Industry Foundation Classes (IFC) within the OpenBIM format resolves key issues in complex projects.
01 June 2011
A RISE in the complexity of projects has generated an increased need for specialisation in architecture, engineering and construction (AEC) services and associated design tools. However, the more specialised the tools become, the more difficult collaboration between them becomes. A workable solution should encourage specialisation and at the same time find a common language that bridges the gap of interoperation.
The complexities in the development of a built environment arise from the client’s desire for iconic solutions, the architect’s pursuit for innovation or the engineer’s demand for sophisticated solutions. Added to this are requirements for more accurate assessments of environmental sustainability, efficient building performance and low running costs, as well as more accountability in construction methodology and costing. In short, as the complexity of buildings increases so too do performance requirements in design, construction and operation.
Corresponding to the increase in complexity is the demand for evermore specialised consultants and subcontractors and for multilayered construction processes. Two issues have emerged in response to this shift. On the one hand, we find that traditional documentation methods can no longer serve the demands of complex architecture or the unique requirements of the specialist consultant. On the other hand, we are seeing an expanding communication void forming between the various disciplines, and consequently between the tools they employ. As evidence of this, we can identify difficulties within the construction process arising from these two issues.
 |
Some examples relating to the inability of given tools to meet the increased complexity of a project include:
• Limitation of 2D documentation to effectively represent complex geometry for visualisation and coordination;
• Absence of mechanisms in traditional documentation methods that ensure consistency, such as synchronising changes between plan and elevation, or plan and schedule; and
• Inability to represent sequencing and time-based functions.
In addition, the lack of open, standardised and consistent communication creates another set of issues:
• Delayed communication (and often incomplete information) in providing design updates and clarifications to all concerned parties;
• Inability of existing processes to propagate changes across multiple platforms; and
• Communication disruption and time-wastage where project standards are not correctly implemented or different subcontractors are using non-compatible CAD software.
For the most part, we see these two issues being dealt with quite separately. In response to the first issue, one finds the development of increasingly sophisticated building information modelling (BIM) software able to undertake complex modelling and manage multiple rule-based tasks. This has demonstrated tremendous success in addressing the first set of issues.
However, there has been limited success in responding to the second set. To address the issue of information flow, one must look to data exchange by means of a collaborative platform. Such platforms enable centralised data to be accessed by any project member at any stage of the project and often from any geographical location. In the realm of BIM, however, the process is more complex. It is not simply a matter of sharing information, but also ensuring that the data is openly compatible – that is, the content generated in one software is legible to another given software. This tends to mean reducing content to the lowest common denominator, sometimes in 2D form or as simple 3D geometry without the valuable BIM content.
This scenario is counter-productive as the high-level content produced in specialist software is made largely ineffectual when it enters the collaborative environment. The solution then is to ensure that while the software continues to excel in specialisation, it also conforms to a standardisation; a common language.
Common language for AECOO
The architecture, engineering, construction, owner and operator (AECOO) industry benefits from the specialisation of its disciplines and the diversity of its tools, and yet the success of a project is dependent on the ability of all parties to collaborate effectively. As much as we may applaud the emergence of specialist disciplines and new technologies, so too must we ensure that the industry retains a common language of communication.
In the realm of BIM, we see this paradigm come to a head. The industry is best served by the ability of software to perform increasingly complex tasks – processing compound geometry, assessing inputs from performance analysis data, and synchronising between multiple interfaces. Nevertheless, the ultimate value of this software is in its ability to disseminate this information to other project stakeholders.
 |
|
The geometry of the clubhouses is derived from a complex intersection of angled planes and elliptical cylinders. |
Unfortunately, we still find that collaborative platforms deployed on a project are often not capable of processing the wealth of BIM content generated in the original authoring software. In many cases, we see BIM reduced to basic 3D geometry, devoid of valuable BIM content. In other cases, one can still find a preference for 2D CAD output or even PDF documentation. This is certainly taking the ‘I’ out of BIM.
The direction that the industry ought to be taking is to ensure that the software deployed on any given project has the ability to communicate in a common standardised language. This is the principle of OpenBIM, which promotes the use of IFC (Industry Foundation Classes) as an industry standard for interoperability.
IFC is an application-neutral object-oriented file format developed specifically for the AECOO industry. Model content is represented accurately in terms of geometry and system-based parametric data. The IFC data model is based on class definitions of elements that represent the parts of buildings, or elements of the process, and contain the relevant information about those parts. The data focuses on those classes that are needed to share information (rather than processing it in a particular proprietary software). Most of the leading BIM software have established interoperability (import/export functions) with the IFC format, and it is widely considered the industry standard for OpenBIM.
Case study
Architect Daniel Libeskind’s first residential showcase project in Asia, Reflections at Keppel Bay, provides an illustrative example of the role of OpenBIM in collaboration between disciplines in projects of architectural complexity.
Reflections at Keppel Bay is an iconic design for luxurious waterfront living at the entrance to Singapore’s historic Keppel Harbour. The development features six high-rise towers of 24 and 41 storeys, 11 spacious six- to eight-storey villas and two clubhouses, totalling 193,400 sq m of gross floor area.
The developer of the project is Singapore-based multinational company Keppel Corporation and the main contractor is WohHup. The project, which is currently under construction, is expected to be completed in 2012.
The complex nature of the architectural design presented numerous challenges to the contracting team. Principal among these was the limitation of 2D documentation to accurately represent complex three-dimensional geometry. The crest of the towers and the ground level clubhouses were two areas of particular interest.
The Tower Crown: The design of the towers is non-uniform and curvilinear. The glass facades have bi-directional curvature and are gradually tapering towards the tower crest. The structure of the facades is notionally extended beyond the slanted roofline to form the crown of each building. Within the building crowns are terraced sky gardens. This is one of the strongest architectural features of the towers, but also an area of complexity.
Initial design and technical drawings were produced as traditional 2D documentation by the architects and engineers. These were issued to the contractor for estimation and site preparation. The technical team of WohHup evaluated the drawings and produced another set of 2D detailed fabrication drawings for construction. However, when it came to establishing setting-out points for the steel roof members for fabrication and installation, the technical team was unable to accurately determine the 3D coordinates. This halted the construction of the tower crown and delayed subsequent trades, prompting the main contractor to find a new way forward.
The Clubhouse: The geometry of the clubhouses is derived from a complex intersection of angled planes and elliptical cylinders. Without referencing the underlying geometry, the building is virtually impossible to construct. As with the towers, initial documentation had commenced in 2D. Base plates had already been cast onsite before it became apparent that key setting-out points could not be accurately established from the 2D documentation.
A BIM solution
To resolve these issues,WohHup engaged the virtual construction team from Consoft Asia, which developed a detailed BIM referencing the underlying geometry of each building. This enabled them to accurately model complex components and establish precise three-dimensional setting-out points.
In the case of the clubhouse, the complex configuration and acute angles of the design meant there were minimum tolerances available. The base plates that had already been cast onsite were modelled in the BIM and necessary adjustments were made to the facade. The facade members were modelled in detail and the installation process was simulated to ensure buildability.
In the context of the towers, the utilisation of the BIM enabled the resolution of previously undetected conflicts. One such example was an intersection detail in the crown framing involving up to eight tubular members, each 457 mm in diameter. The connection as it was indicated in the existing documentation was unbuildable. The item was flagged to the architecture and engineering team and an alternative solution was developed. The estimated savings in identifying this conflict prior to fabrications was several hundred thousand dollars.
The BIM was later made available to other subcontractors involved in structural, facade and curtain-wall systems. It was also utilised for optimising the operation of the tower’s building maintenance units (BMUs).
Making the BIM available to the broader project team highlighted problems in itself. Each contractor had its chosen software and not all software were compatible. Consoft nominated a common data scheme for interoperation between all the relevant software. IFC was adopted as the OpenBIM format and each subcontractor was able to export its model in IFC format and integrate it into the central model, which was managed by the main contractor.
With the integration of subcontractor models, the main contractor was able to identify and resolve a broader range of cross-disciplinary issues, including clashes between building elements; connections of the curtain-wall to the structure; alignment of joints of the curtain-wall; waterproofing; alignment of the steel crown members to the curtain-wall grid; and coordination of planters with the structural supports for the steel crown structure.
