The Entity Component System Software Pattern for AEC

Introduction to Entity-Component-System for BIM Developers

The NXT BLD conference is today and regrettably I wasn’t in attendance, but I did listen in virtually.

In my opinion one of the more interesting topics for software developers was Greg Schleusner AIA talking about Entity Component System (ECS) software architecture pattern and its potential application to Architecture Engineering and Construction (AEC) industry.

What is ECS?

ECS is a software architectural design pattern.

In ECS all data is stored in components which reference entities. Entities have no intrinsic data themselves, they are just identifiers (e.g., UUIDs, URIs, or integers). All data is contained in components, which refer to entities via their identifier. Components can be added to or removed from entities dynamically. Systems are software applications (or features) that operate on components.

What is an Entity?

An entity is any part of the project you might want to talk about, or that could be referenced from a document or piece of software. It could be physical, abstract, concrete, meta, singular, or composite. It could pertain to the project data, design, delivery, planning, the construction.

Some examples of entities could include: beams, wall, risers, buildings, outlets, documents, milestone, stakeholder, document, level, room, building, family types, etc.

What is a Component?

A component is a set of one or more related data points with a similar purpose and representation, associated a particular entity. In other words, a set of fields or properties.

Some example of components could include: geometry, rendering material, physical material, bounding box, property set, location, etc.

ECS Compared to Object-Oriented Design

ECS can be best understood for most developers by contrasting it with the more traditional object-oriented API approach where the things that you want to talk about (the entities) are represented as objects (instances of classes), which directly contain properties and fields which reference the data related to those entities.

In most object-oriented programming languages, each object has a fixed schema (data type) and a-priori knowledge of what kind of data it can reference.

In the ECS model, the relationships between entities and data are inverted. The components contain the data and reference the entities.

This is a very simple yet powerful concept!

We can compose arbitrary components together in different ways, with the entity needing to know anything about the different components.

ECS and the Open-Closed Principle

A famous software design principle is the open-closed principle. It states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification".

Ironically, Bertrand Meyer first stated it specifically about object-oriented programming, but it highlights one of the key weaknesses of many object-oriented programming languages. I either can’t add fields to existing objects (e.g., Java, C#, C++), or if I can (e.g., JavaScript, Python) I can’t prevent modification.

Using ECS I can dynamically associate new data with existing objects without recompilation or modification.

Of course, ECS is a software design approach. It can be implemented in an object-oriented programming, it is just another way of thinking about how to organize and structure your data types.

Roots in Game Engine Design

ECS first became widely known in the context of game engine development, as a way of providing better performance through improved memory locality.

When data is organized in the OOP manner, i.e. by game object, then traversing all component data of a specific type, means walking the entire game object tree, and collecting the data that we want. This would involve access memory in a non-linear and unpredictable manner. This is not cache friendly and you would visit more objects than necessary. As a result it can be slow.

Using an ECS approach component data could be grouped by component type together in linear memory arrays.

ECS for Distributed Computing

The AEC industry has an interesting challenge. Data for a single project exists in a myriad of file formats (both open and closed) managed by geographically dispersed teams with different roles, responsibilities, and data management policies. This data will change continuously throughout the lifetime of the project.

Coordinating all this data into a single set of construction plans is complex and time consuming.

The ECS model is interesting for this workflow, because if two applications share the identification of the entity (e.g., a name or UUID), then they can both co-manage relevant data about the same entities in the form of components without ever needing to be aware of each other.

Implementation Challenges

If multiple pieces of software house different components we still want to be able to query data across the different representations, and to assure a common entity identification system.

At the heart of this challenge is the fact that multiple documents can often refer to the same concept (i.e., entity), but there is no central method for resolving what entity is being referred to.

This is what I refer to as the "Identity Problem" and was the subject of our 2024 Zurich AEC Hackathon prize-winning project.

We also need to bring all the data together in the end to create construction documents such as: bills of materials, construction plans, and 3D renderings.

Not unlike the problem faced by film studios when they need to bring together assets created by different departments using different pieces of software into a final rendered frame. This is the subject of USD.

Luckily this is a much more tractable problem, than trying to make all vendors and stakeholders conform different software applications and processes to a shared and precise representation of the data.

The World Wide Web as a Model

The world wide web demonstrates a potential solution to the problem of distributed data in different formats. A web-page consists of links to documents (“resources”) via a unique identifier (URI) which uniquely identifies the document and a MIME type which describes the format of the data.

A web-server can serve any requested documents to a client (e.g., a web-browser), and even describe it's mime type, whether or not the client knows how to read or render the document.

Either way, the client can still access the resource data (called a "payload" in the Strange Matter specification) store it, and pass it to other applications.

What Next?

I believe we will two things to start making an ECS system viable for real-world project:

1. A standard for describing meta-information about components (e.g., where their data is hosted, when they were created, what format their data is, etc.). This is in part what the Strange Matter specification is attempting to address.
2. A system for creating entity ids, tracking component meta-data at a project level, and resolving UUIDs. This is what I am hoping that Ara 3D Connect could evolve into.

In both cases, I think the ideas need to be refined by being putting through some real-world tests.

I'd appreciate your thoughts on the subject. Any questions? Do you think I am missing some important considerations? Anything you want to add?

Perhaps you are interested in collaborating on trying out an implementation of ECS in your next construction project?

If so, let's talk!