The Designer's organizational methodology for building industrial solutions systematically.
Modules → Designer → Four Pillars Methodology | How-to Guide
The Four Pillars methodology is the structured approach used within Designer to organize solution configuration. This proven methodology ensures scalability, maintainability, and performance by building solutions in a logical sequence from data foundation through user interface.
Key Principle: Each pillar builds upon the previous, creating dependencies that enforce good design practices.
Unified Namespace | Process Modules | Application Modules | Operator UI Modules |
Tags Asset Tree UserTypes (UDTs) | Devices Alarms Historian | Databases Reports Scripts | Security Displays Clients |
| Pillar | Context | Purpose | Modules |
|---|---|---|---|
| 1 | Data Foundation | Define data model and structure | Unified Namespace(Tags, Assets, UDTs) |
| 2 | Industrial Operations | Connect to field devices | Process Modules: Devices, Alarms, Historian |
| 3 | Business Operations | Process and analyze data | Application Modules: Datasets, Reports, Scripts |
| 4 | User Interaction | Present information | Operator UI Modules: Security, Displays (Clients) |
Implementation Sequence
The optimal implementation sequence, when configuring a solution, is to simply follow the order of the Four Pillars.
What the methodology describes — and what it doesn't
The Four Pillars describe module organization: where each module is configured, and the phase-gate order to build in. They are not a claim about how workflows run.
Every real solution workflow naturally spans all four pillars. An alarm reads a Pillar 1 tag, the Alarm module fires (Pillar 2), a script sends a notification (Pillar 3), and the operator acknowledges it on a display (Pillar 4). That cross-pillar flow is the normal shape of any solution — not an edge case, not an exception.
The methodology answers a different question — where is each module configured? Each module has exactly one home pillar. Alarms module is Pillar 2. Historian module is Pillar 2. Devices module is Pillar 2. Security module is Pillar 4. Both facts are true at the same time: runtime workflows span pillars; module configuration assigns each module to one.
The Unified Namespace (UNS) is your solution's data foundation - a single source of truth for all real-time and configuration data.
Tag Structure | Asset Tree | UserTypes |
|---|---|---|
|
|
|
Device Communications | Alarm Management | Historian |
|---|---|---|
|
|
|
Application modules add business logic, data processing, and integration capabilities to transform raw data into actionable information.
Datasets | Reports | Scripts |
|---|---|---|
|
|
|
Operator UI Modules enable operator control, and presents information to operators, managers, and stakeholders through interactive displays and dashboards.
Operator UI | Dashboards | Clients Access |
|---|---|---|
|
|
|
Solution ready to Run, validate, apply security, and deploy.
Runtime | DevOps | Deployment |
|---|---|---|
|
|
|
-> Runtime (Concept)
→ DevOps & Version Control (Reference)
→ Deployment (Reference)
| Benefit | Description | Impact |
|---|---|---|
| Structured Development | Clear sequence of implementation | 50-70% reduction in rework |
| Scalability | Foundation supports growth | Easy expansion without redesign |
| Maintainability | Organized architecture | Simplified troubleshooting |
| Reusability | Template-based approach | 40% faster development |
| Best Practices | Industry-proven patterns | Reliable solutions |