Streamlining IFC

With previous new IFC versions there has been much celebration on how many new entities have been added and how large and comprehensive IFC now is (an astonishing 776 classes and counting).

But if it isn’t already, there is a serious danger of IFC becoming bloated.

Rather than extending, I think now is the right time to be talking about streamlining and modernising the fundamentals of the standard to improve the ease of implementation and accessibility into the future.

Here are some ideas based on practical usage experience.

Remove all property sets

Currently IFC is a schema (entities and attributes) and property sets. I believe IFC would be much stronger if it was schema only.

While a schema can be universally adopted across every project in the world, the properties can change completely depending on client requirements and project specific processes.

I would remove all predefined property sets (like Pset_SanitaryTerminalTypeCommon) because compared to the schema, they add relatively little value.

This would be a good first step to slimming down and focusing on the IFC schema.

Properties are very important, but should be handled by an entirely separate standard, such as the buildingSMART Data Dictionary.

Remove the ‘Ifc’ prefix from all entities

A simple one, but it is incredible how much more readable and clear the standard becomes once the ‘Ifc’ prefix is removed. A wall should be a Wall, not an IfcWall.

Clean up the inheritance tree

(The following are based on IFC4add2, but the same applies to most versions)

Microsoft advises that having classes with more than 4 levels of inheritance is bad design and “can be difficult to follow, understand, and maintain”.

The IFC specification has 353 classes that are 5 or more levels deep, of those an incredible 117 are 9 levels deep!

Having that many layers of abstraction is incredibly excessive. Just because some entities share attributes doesn’t mean a parent class should be created at the expense of readability.

As a start, Relationships can be removed from the main Rooted tree. A relationship does not really need a name, description, or owner history. It is debatable whether they even need a GlobalId.

I also don’t think anyone could convincingly argue that nearly 50 different classes are required to meaningfully represent relationships and remain easily implementable.

Remove IfcPropertySets from the rooted tree too and then IfcObject and IfcTypeObject can be the new top level entities. This reduces the maximum inheritance to 7, which is still extremely high!

A single IfcPropertySet class

The property set concept of a list of name-value pairs is very simple and highly universal. There’s no need for all the predefined sets, including quantity sets, and templates. I’m certain a single IfcPropertySet class would be sufficient for 99% of use cases and also does not need to inherit from Root.

Remove Base64 GlobalIds

It is for purely historical storage reasons that IFC uses GUIDs converted to Base64 using a unique character mapping scheme. The amount of space that it saves in the modern IT environment is nothing.

GlobalIds should now be in the standard Base16 format so that more existing software libraries can read, process, and create them, rather than requiring a custom algorithm.

Scrap the ISO10303 support

Currently there is an XSD and a ISO10303 EXPRESS schema definitions. Rather than continue with such an outdated and unsupported format, the EXPRESS schema should be scrapped with the focus on the XSD schema definition that is far easier to develop against. I’m aware that there are some aspects that can’t be specified in XSD, but if thousands of other formats can be specified using just XSD, then I don’t believe IFC is so special as to be an exception.

Because the STEP file format has relatively very few tools supporting it, IFC in XML format and zipped should be the only format recognised by buildingSMART.

A zipped XML file is the standard approach for all Open Office and Microsoft Office files and should be more than sufficient.

Summary

The aim of this blog post  is to encourage people to consider streamlining the IFC standard to make it easier to use, understand, and implement by everyone.

These are just a few ideas to get things rolling, and I’ve not even mentioned issues like the complexity of interpreting IFC geometry and possible improvements to how it’s documented.

If you have any ideas please free to add them below.

Advertisements

The impossible problem of naming things

Is there any situation more socially awkward than not knowing someone’s name and having to describe them to someone else?

“Erm, you know that tall guy? Kinda slim? Talks fast? Short brown hair? In the engineering department?”

Even deciding what attributes to use to describe them is fraught with difficulties.

And in Building Information Modelling is there anything more contentious than how to name something?

No system ever seems to satisfy everyone’s requirements. The British Standard, Publicly Available Standard, and International Standard documents do a good job but they’re far from perfect. Whether it’s zone, document type, or classification system, there’s always some part of it that just doesn’t seem to work properly for users.

Files, library objects, layers, instances of objects, and even classification systems themselves suffer from this problem.

Why?

Why is it so difficult to name things?

Many decry “dinosaurs” who don’t want to change, or the standards bodies that don’t know about the real world, or simply poor implementation.

But I believe it is because of the unresolvable conflicts between human needs and information management needs.

Humans need names to be readable, simple, understandable, and easy to remember. For information management we need names to be easy to process, flexible, yet also rigidly structured.

Human needs

There’s a good reason why giving people names is a concept used in every human society, it allows us to make reference to people easily.

Sure, a person’s name doesn’t really tell us anything about that person, but given context at least we can work out who is being talked about.

Construction projects have many documents and we need a way to reference specific ones, so naturally we use “names”. However, we can’t just give them names like Steve or Roger, instead we try to inject some context and logic into them with names like AH-CHT-Z1-00-DR-M-55_11_20-1001.

Assuming we have memorised the standard, we can have a good guess about what this document contains, but it still leaves an awful lot to the imagination and is not very readable.

It is also a huge assumption that everyone would know what all the codes stand for, so it’s not very simple.

It’s not particularly memorable either,

Information needs

The concatenation problem

To create a contextual name we have to concatenate different information, and we have to be selective about which information to include, which means potentially useful information is excluded.

We also have to shorten down descriptions to simple codes, e.g. DR = Drawing, M2 = Model, ZZ / XX =???.

And then to actually process that name back into useful data it must be split up and inferred based on the position and short codes. It’s all very difficult to process.

The multiple problem

There’s the multiple problem, what happens when a document covers more than one zone, level, type, role, or classification? Ideally there should be a list of possible values, but we can’t put that in a concatenated name, certainly not without making it overly long. The workaround is to just class them as multiple or none applicable without specifying what the multiple even are. A name isn’t flexible enough to allow for these possibilities.

The string problem

There’s also the problem that a name is always just a string of characters. To enforce the structure of a string of characters is a very difficult thing to do. See the code needed just to validate email addresses, which doesn’t even take into account the content itself. In this respect, names are too flexible and not rigidly structured enough.

Are names necessary?

With all these problems, it brings us to an important point. In a digital, structured data environment do we even need names or naming conventions?

Rather than a name, uniqueness could be ensured using proper Globally Unique IDs.

All the current fields in a name could instead be a list of properties that, without the restriction of having to form a name, could eliminate the need for short codes and use much more readable full words.

For humans, we could have unlimited length descriptions, and even additional fields in any format appropriate.

This could avoid the concept of concatenating fields which is just a compromise between humans and information and makes data dumber.

Conclusion

Let’s forget about names. A name should be anything anyone wants it to be. If we need more context then look at the attached raw data. Because after all, the data is where the focus should be.

4 predictions I got wrong

After deciding that a blog post listing the things I don’t know hasn’t reduced my employment chances enough, I’m following it up with a look back at some technology predictions I made when I was younger that I got wrong.

Engineers are at the cutting edge of technology

As a kid I was super excited to go do some work experience at a real engineering office. “These guys are going to be super cool and using amazing technology to produce awesome designs” I thought to myself.

Imagine my surprise when I’m placed in front of a black screen and told to draw 2D lines by typing commands. #WhatYearIsIt! I was blown away by the dumbness of it and knew there must be a better way. (hint: there is)

Tablets will never catch on

This is probably the most embarrassing failed prediction seeing as I now use a tablet everyday at work and my role is to get others to use them too.

But when the iPad first came out I struggled to envision any serious uses. It may seem obvious now, but ‘a big iPhone’ was not intuitively something useful.

Widespread parametric IFC support

When I saw the demonstration of parametric IFC all that time ago it blew my mind so much I was sure it was going to take off, sadly I’ve not heard of anything since and interest has fizzled out.

All engineers would know programming

One of my philosophies is to learn the skills of tomorrow today. When I was 18 I saw the rise of software and it’s power to do work 100s of times faster than humans so I taught myself programming thinking it was going to become a base skill all engineers would need to know.

This has turned out to not be the case, but I’m very glad I do know programming now because it has opened many doors in my career.

The Scourge of Acronyms

“Do you want a chuddy?”, “That teacher is proper dry.”, “Don’t get caught wagging it!”.

As kids everyone loved making up their own words and secret codes. A big part of the fun is that those outside of your group don’t know what you’re talking about, but you feel special because you’re an informed insider.

Unfortunately it seems to me that this behaviour unconsciously carries through into adulthood.

“We need to raise an RFI about an NCR, the FCR on CCSC about BIM MEP IFC is DOA. We need an IDS ASAP”.

It feels great to talk like that, it makes us feel clever and like we’re in on a secret code that only the insiders can understand, just like when we were kids.

But acronyms are truly a scourge in any multi-disciplinary team based environment, which is basically every construction project. They hinder communication, they are inaccessible, and isolate those people that haven’t memorised them yet.

Meaningless

Over usage of acronyms make things become more abstract as the original terms lose meaning.

A recent Twitter poll showed that people can’t even agree what the P in MEP stands for! The acronym has become so far detached from its original meaning that no one knows what words it comes from anymore.

I once queried someone who was using an unfamiliar acronym in an email who subsequently admitted they didn’t actually know what it stood for. The acronym had taken on a life of its own.

Tesla and SpaceX CEO Elon Musk stated in a company wide memoExcessive use of made up acronyms is a significant impediment to communication” (The whole memo is worth reading).

Some people even specifically try to change an acronym’s meaning, like changing the M in BIM from Modelling to Management. This does nothing but cause confusion, for example compare the title and heading and first line of this Tekla article.

In fact, BIM is a great example of when the scope of an acronym expands way beyond its original meaning without thought to the underlying fundemental concepts.

Advantages of acronyms

Writing this post challenged me to think if there are any legitimate reasons for ever using acronyms.

In written documents it can save space, but in this age of becoming increasingly paperless, is saving a very extra bytes really worth it? I reckon that most people’s typing speeds are fast enough these days that the time saving is negligible.

On services drawings acronyms are used frequently to describe systems, for example SA (Supply Air), DHW (Domestic Hot Water), and LTHW (Low Temperature Hot Water). However, I’ve seen the likes of CWS (Cold Water Service / System), MCWS (Mains Cold Water Service), and DCW (Domestic Cold Water) all referring to the exact same type of system.

Even with explanatory legends this can cause confusion and is inaccessible to newcomers.

It is only due to physical paper size limitations and space that means having the full description is unfeasible, however as we move further towards digital ways of working and are less restricted by dead trees, this should become less of a problem.

In speech an acronym does decrease the amount of syllables needed so perhaps they’re useful here? (“WWW” being an interesting exception!)

Unfortunately, I think the area where acronyms are worst is in spoken communication. Whether thats meetings, phone calls, or casual conversations, because unlike a reader who can at least pause and research an acronym, a listener will either have to ask the speaker to explain or continue despite not fully understanding.

Stopping the spread

About 12 months ago to counter the acronym scourge I started to restrict my usage of acronyms to those I was sure that my specific discipline understood.

Then I realised how often I’m interacting with other disciplines so I began using only general construction acronyms.

Recently I’ve been working with apprentices and others brand new to the construction industry to whom even “RFI” (Request For Information) is a new and confusing term.

So while it is only a little thing and may well go unnoticed by many, in all emails, documents, and speech I try to always spell out full phrases every time. This way there is no ambiguity.

I did consider the convention of explaining the full phrase the first time with the acronym explained, e.g. “Bar Bending Schedule (BBS)”, but I still wasn’t happy that I was being as clear as I could be so now I just stick to the full phrase every single time.

The only exceptions are those acronyms understood by the general populace, such as ICT, HMRC, or ASAP.

I now feel the quality of my communication is far better and I am much better understood by others.

I encourage all others to try this and see how much clearer your communication becomes.

(NB: Anyone daring to point out the difference between acronyms and initialisms gets a Special Loser Award for Pedantary.)

Fair criticisms of IFC

IFC is the best schema for exchanging construction and facilities management project information.

There are many unfair criticisms of Industry Foundation Classes (IFC) files when often it is bad software implementation, bad setup, or bad model management at fault.

But that’s doesn’t absolve IFC from any criticism at all.

This article is based on my day-to-day experience of creating, exporting, importing, developing, and managing data with IFC and is where I believe it is fair to say IFC has got it wrong.

Version numbering

IFC2X3

Why is it an X instead of a full stop like every other app or schema in the world? IFC 2.3 makes much more sense. Not to mention the latest IFC2 version is actually IFC2X3 TC1. Again, how much more understandable would IFC2.3.1 be?

No IFC3

IFC was skipping version numbers before Windows and iPhones made it popular. Skipping number 9 is pure marketing strategy but there’s no excuse for missing 3 in this context.

IFC4add1

Obviously with IFC4 people realised that X is a bit silly, but then instead of adopting best practise and going for IFC 4.1 we now have IFC4add1 and IFC4add2 in the works. There’s even discussions of IFC5. Or perhaps it’ll be IFC5x2TC5Add1ITVBBQ?

Ugly documentation

Once you get used to it, the online documentation is actually quite functional but my goodness, it looks appalling and fails massively from a user experience point of view. Documentation can be both functional (for the power user) and visually appealing (for the new comer). Introductory diagrams full of circles, triangles, and hexagons talking about “resource domains” and “geometry topologies” are not helpful to wide adoption.

Emma Hooper of Bond Bryon BIM put together a great tutorial on using the documentation, but when an animated tutorial is needed to use documentation you know that something somewhere has gone very very wrong.

Ancient schema language

I’m certainly not suggesting that just because something is old it is not useful (my Dad is still good at DIY) and just because something is popular doesn’t mean it is good.

But, with the EXPRESS schema language and STEP file format being over 25 years old and in little use outside of IFC, there are very few people able to transfer existing knowledge or apply existing technologies to IFC.

This means almost every technology for IFC has to be learnt and built from scratch specifically for IFC, increasing cost significantly and meaning we’re unable to take advantage of developments in other domains. For the vast majority of people understanding IFC is still a very steep learning curve.

Too flexible

IFC proudly claims to support a huge array of geometry, but with very little restriction.

For example, one of the simplest possible construction items is rebar. Its just a bent bar of metal. But I’ve seen an exported piece of rebar’s IFC geometry described differently in nearly every rebar detailing tool. This causes inconsistency in how it is displayed in different tools and makes implementation of custom tools very difficult.

The Coordination View MVD (helpfully renamed to Reference View in IFC4) restricts geometry somewhat, but still leaves a little too much wriggle room. And of course usage of MVDs is still not widely understood and implemented.

IFC, IDM, MVD, bsDD, IFD, WTF??

Too many acronyms.

Emphasis on file based exchange

The emphasis on a file based approach is increasingly at odds with modern cloud and web based approaches.

The emphasis needs to switch to APIs and databases instead of files to allow for microservices and lightweight apps. The likes of speckle.works is headed in the right direction.

Summary

As I always say, IFC is the best available schema for construction and facilities management project information. But, I believe it needs to modernise to be suitable for the next generation.

Why I love construction

I love engineering.

There are many types of engineering out there. Aerospace, automotive, manufacturing, software, electrical, mechanical etc.

Construction is usually seen as grubby, unsophisticated, and relatively unattractive, especially compared to those making shiny electronic gadgets, or designing aeroplanes, or assembling cars on advanced robotic assembly lines.

But I love construction.

In fact, I think construction is the ultimate form of engineering!

I really do think this for so many reasons, so I thought I’d list them here…

Scale

Even the smallest construction projects are physically huge compared to most forms of engineering.

A simple house is bigger than an electronic gadget, a car, and most manufactured products.

And at the extreme end buildings can be 100s of metres high or have 100s of square metres of floor area. Infrastructure like roads and rail can stretch for 100s of kilometres.

Construction creates the largest structures on the planet.

Uniqueness

The outputs from construction are almost always unique. Very rarely are 2 buildings the same.

Some bemoan this lack of standardisation but it really is driven by customers and demonstrates the importance that society places on buildings.

We can accept having the same car or phone as thousands of others (with just some skin deep differences), but rarely do people want many buildings that look the same.

For people, the houses they live in are often their ultimate expression of self, businesses spend small fortunes on ensuring their buildings are distinctive, and infrastructure is so often dictated by the geology and geography.

Personal

Tim Cook may talk about how the Apple Watch is a personal product, and other tech firms boast about how much time users spend on their apps.

But added together, most people spend most of their time working, living, and sleeping inside buildings and utilising infrastructure.

I would therefore argue that buildings have a much greater personal connection to us than any other product of engineering.

Impact

If you take a birds eye view of our planet you wouldn’t see cars, or planes, or gadgets. No, the things that you would see are our constructions, the buildings and infrastructure we have built to make our lives better.

Construction is an industry that very literally changes the face of the planet.

Legacy

The products that are made by the construction industry last longer than any other type. Aeroplanes might have a 20-25 year life span, cars typically up to 20, manufactured products generally 15 years, you’d be lucky to get 10 years out of electrical products nowadays, and it’s rare for any significant piece of software to last much more than 5 years.

Construction on the other hand…

Commercial offices can have design lives of up to 40 years, most houses are at least 50 years old, and infrastructure can easily last 60, 70, or even 100+ years.

Being involved in construction ensures you can leave a legacy like no other.

Variety

The variety of projects that you get to work on can touch on all parts of the economy. From houses to hospitals, from offices to power stations, from bridges to schools.

Other forms of engineering are often highly industry specific.

Mix of disciplines

A typical construction project involves a wider array of disciplines than any other type of engineering.

It’s not uncommon for a construction project to have architects, structural engineers, civil engineers, geotechnical engineers, environmental engineers, mechanical engineers, and electrical engineers, all working together and coordinating designs.

Of course this doesn’t include all the non-engineering support functions like Quantity Surveyors, Project Managers, Commercial, Planners, Procurement, Plant etc, too.

The amount of opportunity in construction to work with and learn from so many others different from yourself is surely unparalleled in engineering industries.

Dynamic

Some businesses may claim that their workplace is “dynamic” because they have cool chairs and table tennis, but most engineers work in an office or at best in an occasionally changing factory setting.

However, there’s nothing more dynamic than being based on a construction site where your workplace is literally changing every single day.

History

If you enjoy construction, the great thing is that there’s so much history in construction to look back at. No other engineering based industry can claim to be thousands of years old.

Scattered around the world are construction projects that have stood for more than a thousand years.

In summary, when it comes to engineering, construction is the biggest, the most unique, leaves the biggest impact and legacy, is the most varied, the most dynamic, and has the greatest history.

I love construction and you should too.

Things I Don’t Know As Of 2018

I was really inspired by Dan Abramov’s post Things I Don’t Know As Of 2018:
https://overreacted.io/things-i-dont-know-as-of-2018/

I wholeheartedly agree that being honest about our knowledge gaps (i.e. things we don’t know) is really important.

Too often when people are in meetings or talking with colleagues they’ll hear a new term or acronym but keep quiet because they fear that admitting a lack of knowledge is a sign of weakness.

This can lead to misunderstandings, and uninformed and incorrect decisions.

Saying “I don’t know” shouldn’t be so difficult.

Therefore, to help promote the admission of ignorance, here are 9 things I personally do not know:

Money

What’s the difference between finance, commercial, and accounting? Don’t ask me I haven’t a clue. Then there’s all the terms like purchase orders, approvals, invoices, credits notes, payment applications, which do magical stuff behind the scenes by people with a much better knowledge of those things than me.

Contracts

JCT, NEC, RIBA, and more. From my point of view we have a building to build so let’s just build it, simple eh? (I’m told that no, apparently it’s not simple)

Diverse CAD systems

I don’t know ArchiCAD, Tekla, Microstation or any other CAD system which isn’t Autodesk based. This is the one I’m most disappointed with. While I can use many BIM viewers and utilities because they can be picked up relatively quickly, modelling tools take much longer to grasp and so far I’ve only ever had opportunities to work with Revit, Autocad, and Inventor. I know I’m missing out on some great alternative work flows and concepts.

IT infrastructure, network security, and management.

I don’t know what equipment is used or the ins and outs of Active Directory, enterprise grade routers etc.

SQL

This is a big one. I can do a couple of basic SELECT and WHERE queries, but for anything more than that I’m going to copy and paste from Stack Overflow.

Architectural design process

I’m totally ignorant of how architects start with an almost blank slate and then flesh out all the details. I’ve only ever joined projects after the core architectural layout work has already been done.

Civil and Structural Engineering design process

Same as above.

Coordination of daily site activities

Large sites seem to have dozens of different trades all criss crossing each other in an elaborately choreographed dance. A high level gantt chart is one thing, but how this low level management of people, materials, and plant works is beyond me.

How building sites get people to them

If there’s a new building site in the middle of nowhere which requires a couple hundred of operatives, where do they come from? All sites always seem to be full of people but I’ve always wondered how does recruitment work with such a project and geographic specific based industry.

I don’t necessarily want to know all these things and it isn’t a list of goals for me to complete, but I found it surprisingly fun to write this.

So, what do you not know?