Modules
1. Current state of technical systems
Technical systems today are predominantly designed in a product-oriented and function-bound manner. Power supply, data routing, protection, and device integration are typically tightly interlinked and often defined at an early stage of planning.
Even modern architectures are usually structured at the device level or, at most, at the zone level. The underlying infrastructure is designed to be project- and application-specific and offers only limited adaptability.
As a result, changes, extensions, or new requirements do not have a localized impact, but affect the system structurally. They regularly lead to rewiring, custom solutions, or deep interventions in existing systems.
The architecture itself does not emerge from a predefined structural order, but rather from the aggregation of individual products.
2. Structural consequences of this logic
The tight coupling of infrastructure, function, and usage does not remain without consequences. It shapes technical systems in their overall structure and manifests itself in several recurring patterns:
- Systems are difficult to compare, as their structure emerges from the respective concrete implementation.
- Interchangeability remains limited because individual components also embody architectural decisions.
- Migration of existing technology often requires extensive modifications.
- Innovation primarily takes place at the component or product level, rather than at the level of the overall system.
As a result, the architecture itself remains largely implicit and is rarely deliberately designed or systematically evolved.
3. Modules as systemic roles
This is where the modular role-based logic comes into effect.
Modules are not devices, assemblies, or products. They describe systemic roles that exist independently of their specific technical implementation.
What matters is not how a module is realized, but which function it fulfills within the system. The role remains stable even as technology, manufacturers, or implementations change.
This makes it possible, for the first time, to clearly separate:
- architectural role
- physical implementation
- concrete use within the system
This separation forms the basis for structuring systems architecturally without committing prematurely to specific products or technical solutions.
Overview of module roles
| Module | Systemic role | Classification |
| PowerCore | Structural role for energy pathways within the architecture | Architecture-defining |
| CoreConnector | Defined handover point between systemic module roles | Architecture-defining |
| DistribuCore | Structural organization of distribution and continuation of pathways | Architecture-defining |
| DeviceCore | Decoupling of end devices and infrastructure through a unified system role | Integrative |
| LegacyCore | Transitional role for integrating existing, non-modular systems | Integrative |
| HybridCore | Structured coupling of different energy or system domains | Integrative |
| MeasureCore | Systemic role enabling context-based measurements | Extending |
4. Why this role-based logic makes systems adaptable
By separating role and implementation, a form of stability emerges that is not based on fixed products, but on a clear system order.
- The architecture remains consistent while individual modules can be replaced, extended, or newly combined.
- Systems can be developed incrementally without losing their fundamental structure.
- Existing technology can be integrated without having to be redefined.
Modules do not operate in isolation, but in interaction. Together, they form the structural framework within which technical solutions can be created and further developed.
5. Central module roles of the architecture
Some modules carry the architecture in a particular way. They define the fundamental systemic pathways and transitions on which the overall system is built.
These include in particular:
- PowerCore as the structural role for energy pathways
- CoreConnector as the architecture-defining handover point between modules
- DistribuCore as the structural organization of distribution and continuation
These modules do not define what is connected or how it is used. They define how system components relate to one another. Without these roles, only isolated technical components would exist, but no coherent system.
6. Modules for integration, transition, and practical applicability
Additional modules are designed to connect real-world technical environments to the architecture and to enable transitions between existing and modular structures.
These include in particular:
- DeviceCore, which decouples end devices from the infrastructure
- LegacyCore, which enables the gradual integration of existing systems
- HybridCore, which allows the structured coupling of different domains
These modules are essential for migration, reuse, and transition. They ensure that the architecture does not remain theoretical, but can be implemented step by step within existing technical environments.
7. Extending module roles
In addition, there are modules that assume specific systemic tasks, for example in the areas of measurement, protection, or analysis.
These roles extend the architecture without altering its fundamental logic. They are optional, value-adding, and deliberately not required to understand the core functional principle of the architecture.
In this way, the architecture remains open to future requirements, new technologies, and additional module roles.
8. Licensing and further development
The modules are conceived as architectural building blocks. They are designed to be integrated, further developed, and licensed by partners.
ELVARO™ does not pursue a production-driven approach. The modules provide a structural framework within which manufacturers, integrators, and developers can realize their own technical solutions without having to rethink the underlying architecture.
Details regarding cooperation, licensing, and integration are addressed as part of individual discussions.