 |
Articles
18 Nov 2010 A More or Less Optimistic Update on BIMAlexander Bausk 
The current state of thought in the AEC industry views Building Information Modeling (BIM) as pretty much established mainstream technology. Nevertheless, BIM has seen little implementation in the CIS market to date. Regionally-savvy CAD experts, academics and pundits have been heavily enthusiastic about BIM in the recent years but its route to an average workplace has been hindered by various reasons.
With this in mind, it is small wonder that the COFES-Russia seminar recently held in Moscow and its BIM workgroup reignited discussion over BIM, its very definition and prospects.
After the COFES seminar had done its job introducing participants'
initial positions to each other, multiple publications emerged at isicad.ru, followed up by mostly very insightful comments. (See more details about the authors in David
Levin's blog post, where he also provides an even better
introduction.)
With this summary, I will try to cover most articulated viewpoints in this highly enjoyable discussion, inevitably plunging into a somewhat biased depiction of alleged BIM problems and possible ideas of alternative solutions.
A Doubt to Begin with
The above mentioned discussions can be summarized as an interchange of insight among professionals from very different backgrounds and resulting formation of two contradicting viewpoints: one being that BIM in its current incarnation is a de-facto choice for everyone striving to be relevant in the future, and the other questioning the postulated BIM benefits and pointing out systemic weaknesses like disregard of prior practice and problems with existing projects.
The discussion evolved beyond the trivial exchange of "yes it can - no it can't" as Alexander
Yampolsky's clearly skeptical feature argued that reality replication with BIM is by no means acceptable to the majority of projects and while throwing BIM techniques into the process may improve design quality, the single fully integrated model is unachievable.
In a spectacular backlash, Vladimir Talapov delivered a series of articles (1, 2, 3, 4) that comprised a true manifesto of a BIM enthusiast, elaborating history of the catchword and citing works of Frank Gehry as state-of-the-art examples of BIM success. Most of the praise given to BIM is justified and in line with well-known arguments like project coherence, bigger savings and the need to catch up to the growing needs of owners.
Yet, in its eulogy to the BIM paradigm, the series has thrown into discussion quite a few easily attackable statements. It postulated that the early concepts of the 70’s and the today’s vision of BIM are essentially the same thing, and included into BIM definition any technology that makes use of parametric technology, information linking and attachment of additional data to a model of any dimensions. When it went on to labeling BIM skeptics as luddites, the battle lines were drawn and the next feature authored by yours truly was predictably named “A Less Optimistic Viewpoint at BIM”. In it, an effort was made to push back the enthusiastic pressure by reiterating on BIM definition and describing reservations about industry-wide BIM embracement – as seen from the trenches – to the CAD cognoscenti.
A Less Optimistic Definition of BIM
A short analysis of (acceptably) recent publications shows that even among the English-speaking, early-adopter majority there is still much ambiguity about the meaning of BIM (for example, CAD management guru Robert Green views BIM as a superstructure over 3D design while showing awareness of this ambiguity), and that’s only more true for the AEC community in Eastern Europe.
Over the course of the current discussion, BIM proponents have characterized the approach as being fully integrated, internally linked, intellectually tied to geometry, allowing for painless editing, revising, interdisciplinary liaison, digital processing and manufacturing – basically all possible virtues of an integrated design process. There is, however, a much more specific definition of present-day BIM naturally following from market requirements and available functions of current software packages which employers and users recognize as BIM flagships.
In a nutshell, there are three things that are required from a workflow to qualify for BIM:
- geometrical model that allows for advanced shape and space control and collision detection, which almost inevitably limits us to 3D implementations;
- parametric objects with intellectual links and constraints between them;
- possibility to include any relevant information with the geometrical model for automated processing.
In a nutshell, the article asserts that all the benefits of BIM are derived from these three pillars. What isn’t derived is the possibility to turn BIM into an AEC-tailored Product Lifecycle Management (PLM) solution. BIM is essentially an equivalent of PDM, not PLM, and the newly invented acronym, BLM (Building Lifecycle Management) is unlikely to change this.
The reasons for this are the current inability of BIM to handle the enormous amount of highly formalized and regulated maintenance documentation that is usually associated with complex objects like, say, industrial structures. BIM requires the paperwork and existing processes to align to its needs, not otherwise – and the current building will repulse too big and too unavailing a change that BIM would bring into maintenance hurdles. In other words, the more heterogeneity there is in the information to be incorporated into BIM in a given project, the more BIM is likely to go out of the window on that project.
Moreover, while the undeniable benefits of BIM were discussed in detail in the series by Vladimir Talapov and in the discussion that followed, there are some less-obvious fallacies with BIM implementation that were brought into attention of the CIS AEC community over the course of discussion (some of them are naturally in line with general BIM criticism that one encounters in many sources), some of them being neglect for engineers’ needs, loss of established workflows, lock-in to a specific solution provider, trading versatility at the price of niche efficiency, and much larger effort required since more information means more detailing and additional work required to interlink it. (This is apparently the cause of the efforts to make BIM serve the object during service life since it increases the overall output per spent effort.)
This was, of course, not to question the already-proven BIM worthiness, but it came up to being more than enough to dilute the praise and get more realistic about BIM prospects with the CIS region.
Update on BIM: the Complexity Challenge
Now before the final conclusion given in the article is described, there is a really interesting issue to take into account. In a double shot, Vladimir Talapov and Vladimir Malukh of LEDAS delivered two independent yet strongly connected opinions about what mechanical CAD applications are able to do to the AEC industry.
Talapov’s article put a spotlight to the history of highly successful BIM pioneers Gehry Technologies and their Digital Project software (that being in essence the heavily modified MCAD juggernaut, CATIA), arguing that BIM would be the answer to challenges posed by complex architectural shapes similar to those used in the distinctive Gehry-tecture style.
Malukh in his viewpoint went on to describe how MCAD software makes it way to AEC and where it can be seen as a natural replacement for traditional solutions. He provided usage cases for each of the four major MCAD modeling engines and set up a list of causes for MCAD to go into AEC, that causes being:
- more advanced complex modeling tools when compared to niche products;
- parametric technology being a standard rather than a novelty;
- rich tools for design variations and versions control;
- native support for MEP needs;
- seamless integration with other machinery and equipment modeling;
- seamless (well, I’d rephrase this as less painful) transfer to structural analysis and back to the model;
- ready-to-go PDM/PLM infrastructure;
- prospects for construction technology to borrow more from MCAD manufacturing.
Summing up these two accounts on MCAD with regards to BIM and AEC, there is one clear pattern to observe. There are buildings and structures that fit well into this MCAD paradigm and, as Vladimir Talapov noted, may explicitly require 3D modeling tools and paperless, machine-driven manufacturing in order to be actually buildable. These are the projects possessing complex shapes and machine-like connections of elements.
In this case, the highly automated, MCAD-level craftsmanship is required and is responsible for these projects being better fit for PDM (and, by extension, MCAD tools) implementation. The point is, it’s actually a machine-like building to begin with. But what’s its connection to the BIM technology in question?
Where do we go with BIM
The described advent of MCAD into AEC essentially means rebuilding the BIM technology on an existing PDM and modeling platform. Yet the fact that BIM goes along well with MCAD-specific PDM tools does not mean that one just has to disguise PDM with architectural and structural engineering tools in order to repeat its success.
If we look at current BIM not as at modeling itself (that would basically be a 3D and parametrics talk) but as a process, we see that, in practice, it effectively boils down to an out-of-the-box solution implemented as seen by a specific vendor, driven by it’s view on the future rather than by users’ needs. This means that the BIM technology has to evolve into – or at least provide an alternative of – something more easily tailored to the existing needs and workflows of its users.
It is all too well illustrated by the example of Gehry Technologies who actually had to develop their own BIM system on their way to success. Of course, few are able to climb over to the opposite side of the CAD retail counter, and unique projects are, well, what unique is about: rare. To proliferate from the seeds of state-of-the-art skyscrapers and technological wonders to the average user, BIM must get smaller and modular. Here are some speculations provided in the initial article and augmented by the more recent opinions.
Not fitting everything into BIM workflow. Instead, fit BIM technology into a customized workflow. Single, integrated, all-embracing building data model is a myth and software vendors will have to deal with it sooner or later.
Providing a new level of data exchange. Communication is the key, and as far as CAD tools are in question, communication means automation. The lower-level automation still isn’t a resolved issue. Automatic links from Excel and MathCAD worksheets, Matlab calcs and FEA design models back to the BIM software could unite the existing established workflows with however advanced BIM deployments. (Not to mention that engineers are notoriously lazy and would be happy to pretend they are not evolving while in fact catching up with the progress anyway.)
Going modular. There has been a long tradition of software tools development by engineers for their own needs. To revive this practice, easily embeddable parametric or constraining engines, analytical geometry tools, 3D modeling tools able to populate the classic engineering analysis software would bring BIM to the majority of desktops sooner that one would think.
About author
Alexander Bausk, C.Phil., is a structural engineer and CAD professional with the Nuclear Structures Lab at Pridneprovsk State Academy for Civil Engineering and Architecture in Dnipropetrovsk, Ukraine.
He has been working on nuclear structures reliability, safety regulations, and structural assessment for over 6 years, developing CAD workflows and introducing digital technologies to the structural assessment sector.
He authors a blog at http://bausk.wordpress.com and can be reached via bauskas@gmail.com.
Permanent link :: http://isicad.net/articles.php?article_num=14108
|
 |
