The main purpose of this section is to introduce the ECS pattern and to elaborate on the principles that support it. We will do this through comparing the ECS pattern with other, more well-known patterns commonly found in the field of Digital Twin Engineering. Furthermore, the section will list some terminology and illustrations on the pattern that support later sections.
To explain what the ECS pattern is, it is useful to compare it with the OOP paradigm. OOP provides practical aspects such as encapsulation and inheritance. Encapsulation provides the benefit of keeping related code, both variables and methods, together. This approach is also used by the Entity-Component architecture, which should not be confused with the Entity-Component-System Architectural pattern. Inheritance provides benefits for which code reusability is the primary one. However, in some applications, the hierarchical structure could become problematic if the structure does not account for a certain new type of entity.
As mentioned, the ECS pattern has its roots in game development, where iterative development is common. The ECS pattern has the benefit of providing a high separation of concerns, which allows separate development teams to concurrently develop elements for their system, as well as to support more iterative development [1], [2]. The pattern achieves this by defining entities as compositions of components instead of having entities inherit properties from components. In short, the ECS system pattern is defined through three major elements: Entities, Components and Systems.
Entities are nothing more than a container with a unique identifier that is composed of components. Although this often implies that an entity can be represented by a simple integer, this is often extended with more descriptive information to clarify the desired purpose of the entity, as well as a name [3]. To be usable, it is important that the entities can be easily managed. Sometimes, depending on the components of which the entity is composed, a family label is assigned to the entities. Such a label could be used to quickly discover entities that are composed of similar components.
Components represent data. If well-designed, they are generic, small, and reusable. A component, to some extent, could be considered as a collection of properties. Geometry is a proper example, as this can be defined in different ways using different properties (e.g. length, width). Components could also be slightly more abstract, where a component itself serves as an identifying label to the entity that is composed from it (an example from game-design could be the differentiation between ally or foe).
In the ECS pattern, the components are different from other entity-component designs, as they do not describe behavior. In classical OOP and Object-oriented composition, components include behavioral functionality, which is part of the encapsulation principle. The ECS completely decouples this, as behavior is determined based on the composition of Components, where Systems calculate state-changes to entity-component data.
Systems act on entities, computing mutations to relevant components. Systems act only upon certain entities, which depend on the components it has. As a very basic example, if gravity exists within the simulated world, a Gravity System could be responsible for calculating vectors based on the mass of entities. This system could act upon entities that are composed of a mass component. In this way, the behavior of an entity is determined by the systems that act on the entity.
In naive implementations, Systems have to iterate over all entities to determine which should be processed. This can be expansive, especially in software systems where timing is important. The concept of entity families mitigates this, providing dynamic grouping of entities based on their component composition [3], [4].
To clarify the differences between classical OOP and use of the ECS pattern, we provide a small example. Figure 1 shows a simple class diagram that could be used to define different vehicles. The specialized classes LandVehicle and SkyVehicle inherit properties and methods from the Vehicle class. Each specialization might provide different implementations for the indicated methods as the way in which this is performed might differ. Further specialized classes could differentiate helicopters from airplanes and cars from bicycles. Similarly to actuation in a Digital Twin system, assume that an external actor controls the vehicles velocity. The public methods represent user controlled actions, while the updatePosition() method represents some logic that continuously updates the position of the vehicle based on its velocity and current position.
When using the given classes, it becomes difficult to model a bicycle with flight capabilities. Multiple-inheritance could be used, but given the possibly different implementations of the shared methods, its behavior would likely have to be manually defined.
Object-Oriented composition could be utilized, resulting in an Entity-Component implementation where entities are composed of the components which include behavioral components. However, this approach does not separate behavior from data. This approach could introduce additional overhead [5]. Furthermore, to optimize this, software developers would have to optimize each individual method. This is more difficult to maintain and evolve.
Using the ECS pattern, a vehicle entity could be modeled by composing it with desired components. Figure 2 shows how this can be done. An Input System would process entities with the user-controlled and linear velocity components. A different system could be defined that acts on entities also composed of the angular velocity component, but the input system could also provide additional logic when this component is present. Finally, the Position System would act upon every entity with a velocity and position component, and calculate the new positions.
Instead of requiring each entity to be scheduled for processing, only the Systems would require this when using the ECS pattern. In the given example, there would likely need to be some orchestration defining the order in which the systems are executed, as otherwise race conditions could occur. As such, the ECS pattern is not a panacea. It has uses in certain applications, specifically those in which many entities exhibit equal or similar behavior, as it reduces the overhead required. Furthermore, this approach allows entities to be adjusted at run-time, or even new systems to be introduced [1].
