CC1705

EVENTfocus
Stephen Holmes
is not down to the mapping, but to the
source data. That way you can go back
to source, identify it and correct it.
Mapping is essential because of the
different ways in which technologies work
and export data, but you need to sort that
out up front. Don't forget that the COBie
dataset has been separated from the live
model, so ensure that you validate and
verify wherever possible - and don't sign
your name against something with a big
price tag on it.
Five years ago exporting COBie and IFC
was a bit of a black art. Now, software
vendors have set up their software to
help people deliver COBie - but if you
start going 'off-piste' or custom design
then you are left to own devices.
DATA DELIVERY
"COBie," Stephen said, "Gives structure to
data - consistency - as long as everybody
is working to the same rules. Who actually
reads it, though?" On one large BIM
project, he explained, the management
company defining deliverables etc. asked
contractors to deliver COBie at concept,
and thirty companies had no option but to
send the minimal info available - the
name of the project and not much more.
Nobody opened the files received in the
first six months.
Furthermore, when you do receive
completed COBie data, how do you
check 100,000 lines of data with 50
columns? Everything has to be filled in,
but it doesn't tell you if anything is
missing - and the recipients don't have
the right expertise to properly validate the
information they've getting either.
It is better to check it at source using tools
like Solibri (see the article on page 16 of
this issue) where it can be validated
properly. COBie has its place, Stephen
said, but needs to be used properly. It's
also useful to know who doesn't need
COBie. Design teams for example have no
advantage having COBie and need to work
at native file-level. It's only when the project
starts getting complex that the consistency
of COBie comes into its own, and it begins
to serve as originally intended.
Design collaboration works better if you
share the model. If the data is exported
via IFCs it becomes static and can't be
progressed or built on until the
parametric elements needed to modify
the model have been reinserted. That
raises the pertinent question of whether
the only reason you are issuing COBie
data is for the BIM Consultant - patently
not the right reason.
Do all projects evolve beyond
recognition once they have been started?
It almost appears so from Stephen's
presentation. He argued against putting
in too much information - detailed MEP
equipment, rather than basic
performance requirements - because, as
likely as not, the detailed equipment is
likely to change when it all goes out to
tender, with the supplier substituted for a
cheaper one. Data moves, and so does
accountability. It's better to understand
the lifecycle of your data and what is
likely to happen to it.
Finally, the virtual building. How do we
plan for that? The software we're using
now may not be the same as that we'll be
using in five year's time. COBie data is
structured, but it will continually have to
adapt to include things like IoT, the ability
to feed lifecycle data back into the
model, the use of Smart Geometry, Big
Data Analytics and so on, without losing
sight of the basic requirement: "I've got
100 air filters to replace, what is the
optimum path for engineers to take to go
round and replace them?" You can't do
that with a flat data structure.
KEEP CALM AND COBIE ON
Stephen's talk gave us all quite a lot of
food for thought. In the next issue of the
magazine we'll look at the issues raised
in the seminar from a user's perspective,
and then focus on the Question and
Answer session that concluded the
event. For now we will conclude with this
wise piece of advice, again from Stephen
Holmes: "Start by understanding where
you want to go to as a business and
understand the client's needs before you
start pushing from your end."
www.caduser.com/seminars
12
May/June 2017