Why are files exported from Revit protected?

That's the nature of an i-model, regardless of its source.  

The i-model FAQ may help to better answer these questions:  communities.bentley.com/.../i_2D00_model-faq.aspx

Well I have to say that's rubbish!! How is someone supposed to work with a read only file? What is the use and sense of that? The link you gave doesn't explain why the Revit plug-in exports non usable i-models!

Our office is looking at Revit instead of BA at the moment, and I'm trying to see if the information produced from Revit via the plugin is any use when used inside MicroStation. Obviously not! I assume that any .dwgs exported from Revit are also read only and not usable.

I really can't believe that the plug-in doesn't give options for this.

PS:

" Hmmm...  In many (most?) of the cases we've seen in support, clash detection review is not often performed by the same people doing the modeling.  Not to mention multi-discipline projects where individual teams are working on the project.  "

This smacks of old skool 1970's Detroit way of working ! Whack everything onto the assembly line, wastefully reject most of the production run using 'Quality Control' by others. A process devised by MBA manager types and not the actual workers, at the time. 'No comment' if you want to stick with it, but i-models should also try to support less discredited ways of working like trying to provide the best tools to the guys actually doing the work so that mistakes are avoided at source. In car manufacturing terms, I guess it's more Toyota 'Kaizen' or Volvo 'Quality Circles' than '70's GM.

" our office doesn't want to manipulate a consultant model in any way. We just was a way of notifying them that a conflict exists so they can make the change."

How incredibly weird. I can see lots of people at the coal face ignoring this. Its pretty unworkable. So, the structural engineer has got the column in the wrong place. I need to model and develop the floor plan. What do I do? Red line the column, email to engineer, wait for him to change it, re-import the stuff..... then I decide it creates a problem with something else.... Go back to Jail ... Do not pass Go.

OK, you could revert back to using the normal CAD (X)refs and make your mods. But why have two parallel file systems and the resultant 'un-BIM-my' duplication / data re-entry? Its already a bit crazy with having to manage revisions. Also don't forget the external component libraries / datasets and attribute database(s) as well. The way i-models includes all the 'items' or 'component' data with the CAD geometry is great. Why make it read-only?

The way ISM works embodies the exact opposite of the rigid 'throwing data over the wall', silo based working. you are describing. ISM consolidates both analysis and design data in one file, so that when analysis is done by one party, they can directly change the designer's model to solve the problem / optimise the design. None of this jobs worthy 'email them back and wait' ping-pong stuff.

These problems are just the tip of the iceberg, if you consider MDO. Design / engineering processes are increasingly about testing out and searching for balanced solutions across disciplines. Each with their own criteria, issues, parameters, data types and work processes. All of the parties will want to 'run their model' and propagate changes on to the other parties elements / domain in various degrees. Dealing with this will need better and more truly collaborative approaches than the 'compartmented silo-based, design responsibility matrix' way of working we all know and love..:-)

One big difference with ISM is that it's not a cross-discipline format.   When you're dealing with models that include architectural, structural, HVAC and plumbing components, it does tend to change things.

Granted, I wouldn't be surprised if at some point the i-model format or some variation thereof was made read/write by default, but I guess we'll only know when the time comes!

Until then, as archaic as the workflows you've described may or may not be, they are very common and probably not going away any time soon.  Kinda like 2D drafting.    ;-)

Hi Steve,

" Until then, as archaic as the workflows you've described may or may not be, they are very common and probably not going away any time soon.  Kinda like 2D drafting.    ;-) "

Sure, you are right, but history is strewn with practices that have come and went, and we seem to be forever walking backwards into the future..

Have a look at Set-based Design and some of the research done at the Lean Construction Institute. There is a particularly funny paper by Lottaz et al that looked at the way architects, services and structural went abound designing a beam penetration. I couldn't find the original paper, but its briefly described on page 4 here.  I would encourage you to find the original paper. I cringed when I read it, as its pretty damning of the way things are done in the AEC field.

Essentially, there is such a thing as 'negative iteration' and matrix responsibility-based working, as facilitated by red-lining, tends to discourage true collaborative working. SBD techniques are also interesting, especially if Bentley is interested in how parametrics can help the normal frontline designer, who isn't into blobby forms, but that's another discussion.

Intra or Cross disciplinary changes: I don't see the big difference. Maybe you can expand. You still have one person / domain propagating changes to another. The point is that it is possible, and I would argue, if done in a structured way (like SBD), a good thing that should not be shut out or suppressed as a work practice.

Dominic

I only read bits and pieces, including page 4, but that is an interesting article.  Though I do wonder how you find (and read) all this stuff!  :)

It seems to me that the HVAC subcontractor should have been consulted first, since who else is going to know the right size pipe and/or spacing?  That information should have been passed to the engineer to make sure the proposed openings were structurally sound.   I don't know why the architect was involved up front in beam openings though...   Location of beams?  Sure.  But beam openings?   Hmmm...

Anyhow...  Cross-discipline modifications are great in theory, but we see very few people who are actually adept and knowledgeable enough do to that; e.g., to calculate airflow requirements for duct sizing and placement, to place those ducts within a structure while understanding whether or not beams/columns can be shifted, and have the aesthetic understanding to know whether it all suits the intended design.   Because blindly making changes without understanding their potential downstream effects could be considered a negative iteration.    ;-)

Well, enough rambling from me...  I'm not in the AEC business, I simply help support products that are used in that businelss.  But I have seen enough to recognise that reality ($$) usually isn't optimal.   However, we can certainly continue to improve things from our end, and hopefully changes coming down the pike will help solidify the PIF.  (Postive Iteration Factor, I just made that up).  

FYI:

Under most building contracts, the architect has a large coordination role as lead designer or consultant. I guess this is why the architect is involved in the example.

E.g. In Germany, the architect (who actually graduates with an engineering degree) is responsible for coordinating all penetrations related to the building services, and coordinates the structural engineers drawings. He has a vested interested in this as he is often responsible for coordinating the subcontractors on site (bauleitung). General contracting is still comparatively rare and has a reputation for being expensive in Germany. In the UK, there are similar obligations, although the structural and services engineers tend to keep it to themselves as much as possible, because the architects are pretty disinterested and hopeless at it. I suppose the predominance of structural steel framing (as opposed to concrete on the continent) makes this easier.

The UK has pretty quaint contractual defaults, where the contractor is not obliged to coordinate at all unless the appropriate contractual amendments are included. I think is a hold over from the Victorian days when the 'educated classes' had all the knowledge and the builders were seen as uneducated 'putter-uppers' that needed to be instructed by their 'betters'. The UK legal profession loves this separation of responsibilities as it makes it easy to apportion blame when something goes wrong.

I think that there are similar requirements in the US. Although, the architect seems to be able to deliver a seemingly comprehensive set of drawings and then walk away, post tender, leaving the contractor or local architect to coordinate.

Calculation: I think you have hit the nail on its head. As the example illustrates, there is NO calculation involved. The architect notices that the services penetration is too big or in the wrong position, but he can't calculate the minimum penetration size himself, and starts an iterative process, by telling the services engineer to slim his duct down. From past experience he knows the services 'engineer' is a lazy git who won't redo his all calcs / routing (hand made) from diffuser back to the plant room just to comply, because he would rather be in the pub before 5pm (Sensible!). The structural engineer also doesn't want to recheck his calcs, most probably because he has already spent his fee by the time the detailed coordination phase rolls about, because of the endless options the silly architect went through during the design stage. And, all of them know that changes often have knock-on effects that are hard to predict, and the contractors (and their lawyers) are just waiting for them to issue information late so that they can cash in on prolongation claims. And so it goes...round and round :-)

FYI:

Under most building contracts, the architect has a large coordination role as lead designer or consultant. I guess this is why the architect is involved in the example.

E.g. In Germany, the architect (who actually graduates with an engineering degree) is responsible for coordinating all penetrations related to the building services, and coordinates the structural engineers drawings. He has a vested interested in this as he is often responsible for coordinating the subcontractors on site (bauleitung). General contracting is still comparatively rare and has a reputation for being expensive in Germany. In the UK, there are similar obligations, although the structural and services engineers tend to keep it to themselves as much as possible, because the architects are pretty disinterested and hopeless at it. I suppose the predominance of structural steel framing (as opposed to concrete on the continent) makes this easier.

The UK has pretty quaint contractual defaults, where the contractor is not obliged to coordinate at all unless the appropriate contractual amendments are included. I think is a hold over from the Victorian days when the 'educated classes' had all the knowledge and the builders were seen as uneducated 'putter-uppers' that needed to be instructed by their 'betters'. The UK legal profession loves this separation of responsibilities as it makes it easy to apportion blame when something goes wrong.

I think that there are similar requirements in the US. Although, the architect seems to be able to deliver a seemingly comprehensive set of drawings and then walk away, post tender, leaving the contractor or local architect to coordinate.

Calculation: I think you have hit the nail on its head. As the example illustrates, there is NO calculation involved. The architect notices that the services penetration is too big or in the wrong position, but he can't calculate the minimum penetration size himself, and starts an iterative process, by telling the services engineer to slim his duct down. From past experience he knows the services 'engineer' is a lazy git who won't redo his all calcs / routing (hand made) from diffuser back to the plant room just to comply, because he would rather be in the pub before 5pm (Sensible!). The structural engineer also doesn't want to recheck his calcs, most probably because he has already spent his fee by the time the detailed coordination phase rolls about, because of the endless options the silly architect went through during the design stage. And, all of them know that changes often have knock-on effects that are hard to predict, and the contractors (and their lawyers) are just waiting for them to issue information late so that they can cash in on prolongation claims. And so it goes...round and round :-)

PS:

So, this is the main reason why I am a bit allergic to 'over the wall, red-lining, don't touch my stuff' style coordination. My personal experience is that it sucks and only serves to let middle managers off the hook because they can blame each other.

In a way, all of these arguments were rehearsed years ago with ProjectBank. See comp.cad.microstation discussion with KB and Mark Hamstra etc. I thought Bentley was way ahead of the curve then, and still think so today.... I think.

Set based Design:

In more formal terms, SBD is described as a better alternative to 'point-based' iteration; an approach that avoids the dreaded 'negative iteration' by defining the problem / design intent in terms of a set of solutions that are driven by solving a system of constraints / parameters, rules etc. I.e. the 'CALCULATION' that was missing in the previous example.

But the calculation's 'sphere of influence' / propagation is context-specific, and is is inherently cross-disciplinary ! Embedded GC scriptlets (or EC's): where are you?

One of the main benefits to be derived from ProjectBank / ECM's shift from the traditional file-based set-up to a big transaction-based database (like what we are seeing with OpenPlant today) is that it will allow the designer to 'check out' the relevant data and manipulate it, without worrying about which 'file' it was saved in. Sorry, middle managers, your data is being messed about by some one else.... but don't worry Bentley is also providing you with change tracking and transaction management tools, so your ISO 9000 QA certification is safe... somewhat.

OpenPlant: Unfortunately, there seems to be a two-tier situation emerging. Top tier with all the middleware required to enable working in a 'seemless' way, and a lower tier that is still limited by the old file-based ways. It's ironic that 'seemless' is most useful for the initial design stages, which usually won't have the expensive, labourious to set up middleware available.

i-models, especially ISM seem like an interesting middle ground that could offer the best of both worlds.... if they can be write enabled.