Isomorphic Architecture - DigiPhusion Edge Layer

Complete guide to isomorphic software-defined automation (SDA) principles and implementation

1. Overview 2. What "Isomorphic" Means 3. Traditional Systems Problems 4. DigiPhusion's Isomorphic Model 5. Structural Components 6. Data Flow Architecture 7. Isomorphic vs Traditional Twins 8. Isomorphic Execution Model 9. Where AI Fits (Safely)10. Implementation Status 11. Benefits 12. Anti-Patterns to Avoid

Overview

DigiPhusion Edge Layer is built on isomorphic software-defined automation (SDA) principles, where the software model maintains a 1:1 structural and causal mapping with the physical automation system.

What "Isomorphic" Means in This System

Definition

There is a 1:1 structural and causal mapping between the software representation and the physical system.

Bidirectional Mapping

Physical World	↔	Software Representation
Motor	↔	Motor class with physics model
Drive	↔	Control + limits + diagnostics
Encoder	↔	Time-synchronized signal stream
Conveyor	↔	Graph + flow constraints
Robot arm	↔	Kinematic tree + state machine
Sensor	↔	Typed data with quality indicators
PLC I/O	↔	Tag with data type + metadata
Fault condition	↔	Explicit state transition
Safety circuit	↔	Policy rule with guarantees

Key principle: If you change one side, the other changes predictably.

Why Traditional Systems Are NOT Isomorphic

Legacy Automation Problems

Traditional PLC systems are behaviorally coupled but structurally opaque

Problem	Impact
Ladder logic doesn't model physics	No simulation capability
I/O maps hide device semantics	Can't reason about system state
Scan cycles approximate time	No deterministic guarantees
Safety/motion/logic in silos	No unified model

Result: The software controls the system but does not represent it.

This breaks isomorphism and prevents:

Cloud/edge orchestration
Simulation before deployment
Hot-swapping hardware
Deterministic rollback/replay
AI-driven optimization

DigiPhusion's Isomorphic Model

Core Architecture Principle

Hardware becomes an execution target for software models.

The same model runs in:

Cloud

Design, training, simulation

Edge

Real-time execution

Dashboard

Visualization and monitoring

Different runtimes, same structure → isomorphic execution

Structural Components

1. Tags (Isomorphic Signals)

interface Tag {
  id: string
  name: string
  path: string                    // Hierarchical structure
  dataType: TagDataType          // Typed (not just number)
  value: TagValue                // Current state
  quality: TagQuality            // Good/Bad/Uncertain
  timestamp: number              // Time-synchronized
  unit?: string                  // Physical units
  min?: number                   // Physical constraints
  max?: number                   // Physical limits
}

Isomorphic property:

Each tag maps to a real physical signal with:

Type safety (INT16, FLOAT32, BOOL, STRING)
Quality indicators (sensor health)
Temporal ordering (synchronized timestamps)
Physical constraints (engineering units)

2. Assets (Isomorphic Devices)

interface Asset {
  id: string
  name: string
  type: AssetType               // Motor, Sensor, PLC, etc.
  parentId?: string             // Hierarchical topology
  tags: string[]                // Associated signals
  metadata: {
    manufacturer?: string
    model?: string
    serialNumber?: string
    location?: string
    commissioned?: string
  }
}

Isomorphic property:

Each asset represents a physical device with:

Hierarchical structure matching physical topology
All associated signals grouped
Metadata matching nameplate data

3. Digital Twins (Isomorphic State Machines)

interface DigitalTwin {
  deviceId: string
  desired: Record<string, any>    // Commanded state
  reported: Record<string, any>   // Actual state
  delta: Record<string, any>      // Diff (shows divergence)
  metadata: {
    timestamp: number
    version: number
    syncStatus: 'synced' | 'syncing' | 'diverged'
  }
}

Isomorphic property:

Same state machine runs on edge and cloud
Desired state = software command
Reported state = physical reality
Delta = physical system deviation (e.g., motor stall)

4. Policies (Isomorphic Control Logic)

interface Policy {
  conditions: Condition[]        // State predicates
  actions: Action[]             // State transitions
  schedule?: Schedule           // Temporal constraints
  continueOnError: boolean      // Fault handling
}

Isomorphic property:

Policies encode:

Safety interlocks (if temp > limit → shutdown)
Timing constraints (execute only during shift A)
Causal relationships (if sensor fault → stop motor)
These rules apply equally to simulation and production

Data Flow Architecture

┌─────────────────────────────────────────────────────────────┐
│  Physical Automation System                                  │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │  Motor   │  │  Sensor  │  │   PLC    │  │  Robot   │   │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘   │
│       │             │              │              │          │
│       └─────────────┴──────────────┴──────────────┘          │
│                         │                                     │
└─────────────────────────┼─────────────────────────────────────┘
                          │ I/O, Fieldbus, Industrial Ethernet
                          │
                    ┌─────▼─────┐
                    │   Edge    │ ◄── Rust Server
                    │  Device   │     WebSocket Server
                    │           │     Policy Engine
                    │  (Iso-    │     Tag Manager
                    │   morphic  │     State Machine
                    │   Model)   │
                    └─────┬─────┘
                          │ WebSocket (JSON)
                          │ Isomorphic Messages
                          │
                    ┌─────▼─────┐
                    │  Browser  │ ◄── React Dashboard
                    │ Dashboard │     Same Model
                    │           │     Read-only View
                    │ (Iso-     │
                    │  morphic   │
                    │  Twin)     │
                    └─────┬─────┘
                          │ HTTPS / WebSocket
                          │ State Sync
                          │
                    ┌─────▼─────┐
                    │   Cloud   │ ◄── AWS IoT Core
                    │  Backend  │     Device Shadow
                    │           │     Same Model
                    │ (Iso-     │     Analytics
                    │  morphic   │     Training
                    │  Replica)  │
                    └───────────┘

Isomorphic layers:

Edge: Executes model in real-time with physical I/O
Dashboard: Visualizes same model (read-only)
Cloud: Stores same model for analytics/training

Isomorphic vs Non-Isomorphic Digital Twins

Non-Isomorphic (Traditional "Digital Twin")

Physical Device → Telemetry Stream → Database → Dashboard
                  (one-way)         (aggregate)  (visualization)

Properties:

Read-only: Cannot command physical system
Statistical: Aggregated, not causal
Visualization-centric: Pretty charts, no control
Lossy: Information lost in transformation
Non-deterministic: Can't replay or simulate

Isomorphic (DigiPhusion Model)

Physical ↔ Edge Model ↔ Cloud Model
(reality)  (executor)   (orchestrator)

Properties:

Bidirectional: Commands flow down, state flows up
Structural: Same state machine everywhere
Causal: Understands cause and effect
Lossless: Full fidelity state replication
Deterministic: Can simulate before deploy

Example:

Traditional: Dashboard shows motor is running at 1750 RPM
Isomorphic: Dashboard shows motor state machine is in RUNNING state with setpoint=1800, actual=1750, delta=-50 (indicates slip)

Isomorphic Execution Model

Same Model, Different Runtimes

Environment	Runtime	Capabilities
Cloud (Design/Training)	Node.js/Deno V8 isolates	• Design • Simulation • Training • Analytics
Edge Device (Production)	Rust RTOS Tokio runtime Deterministic	• Real-time • I/O control • Safety logic • Local policy
Dashboard (Monitoring)	Browser JS/WASM React	• Monitoring • Visualization • Manual control

Key: Different runtimes, same structure.

Where AI Fits (Safely)

AI can augment SDA systems only if it respects isomorphism.

Safe, Isomorphic AI Roles

1. Parameter Tuning

AI learns: optimal PID gains within bounded ranges
Isomorphic: Still uses same control structure

2. Fault Classification

AI predicts: bearing fault from vibration signature
Isomorphic: Maps to known fault states in model

3. Optimization

AI optimizes: production schedule
Isomorphic: Respects timing constraints in model

4. Predictive Maintenance

AI predicts: motor failure in 72 hours
Isomorphic: Uses causal signal history, not correlation

Dangerous, Non-Isomorphic AI

1. End-to-end Black-box Control

❌ AI directly outputs motor voltage

✅ AI tunes PID setpoint within safety limits

2. LLMs Generating Control Logic

❌ GPT-4 writes ladder logic

✅ Human writes declarative model, AI optimizes parameters

3. RL Without Physics Constraints

❌ RL agent learns to overspeed motor

✅ RL constrained by physics model limits

Principle: AI augments the isomorphic model, it does not replace it.

Implementation in DigiPhusion

Isomorphic Foundations (Implemented)

1. Type-safe Protocol src/lib/websocket/protocol.ts

Zod schemas ensure message isomorphism
Same types on browser and edge

2. Tag Schema src/types/tag.ts

Tags map 1:1 to physical signals
Quality indicators track sensor health
Typed values (not generic numbers)

3. Policy Evaluator src/lib/policy/evaluator.ts

Same rule engine runs anywhere
Deterministic evaluation
Causal conditions (not correlations)

4. Digital Twin Types src/types/digital-twin.ts

Desired/Reported state pattern
Delta calculation (shows divergence)
Conflict resolution via timestamps

Next Steps for Full Isomorphism

1. Physics Models

Add unit tests with physics constraints
Motor: acceleration limits, thermal limits
Conveyor: load capacity, belt speed

2. Temporal Guarantees

WebSocket → deterministic scheduler
Add deadline monitoring
Priority-based message queuing

3. Simulation Mode

Run same model without hardware
Virtual I/O for testing
Deterministic replay from logs

4. Edge/Cloud Parity

Same Rust core on both
TypeScript as thin wrapper
Shared model repository

Benefits of Isomorphic Architecture

1. Simulation Before Deployment

Run the exact same code in simulation with virtual I/O

# Simulate production
cargo run --features simulation

# Deploy to edge
cargo run --release

2. Hot-Swap Hardware

Replace physical motor with different model:

Software model stays the same
Only I/O driver changes
No ladder logic rewrite

3. Deterministic Debugging

Replay production failure in development

// Record production state
const log = await edge.exportStateLog()

// Replay in simulation
await simulator.replay(log)
// Exact same state transitions

4. Cloud/Edge Orchestration

Command from cloud, execute on edge

Cloud: desired = {state: "RUNNING", setpoint: 1800}
Edge: reported = {..., actual: 1750}
      delta = {actual: -50} // Motor slip

5. Testable Safety Logic

Prove safety properties in simulation

// Test emergency stop in simulation
await simulator.triggerEmergencyStop()
assert(allMotors.state === 'STOPPED')
assert(safetyCircuit.state === 'SAFE')

Anti-Patterns to Avoid

Breaking Isomorphism

1. Magic Numbers

❌ if (value > 150) { ... }

✅ if (temperature > motor.maxTemperature) { ... }

2. Stringly Typed

❌ tag.value = "123.45"

✅ tag.value = 123.45; tag.dataType = TagDataType.FLOAT32

3. Implicit State

❌ motor.speed = 0 // Is it stopped or starting?

✅ motor.state = MotorState.STOPPED; motor.speed = 0

4. Lossy Aggregation

❌ avgTemp = sum(temps) / count

✅ tempSamples = [...]; statistics = computeStats(tempSamples)

5. Time Approximation

❌ setTimeout(controlLoop, 100) // ~100ms

✅ realTimeScheduler.schedule(controlLoop, { period: 100, deadline: 110 })

Last Updated: 2025-12-20

Status: Foundational isomorphism established, physics models in progress

Back to Architecture Overview

DigiPhusion

Isomorphic Architecture - DigiPhusion Edge Layer

Table of Contents

Overview

What "Isomorphic" Means in This System

Definition

Bidirectional Mapping

Why Traditional Systems Are NOT Isomorphic

Legacy Automation Problems

DigiPhusion's Isomorphic Model

Core Architecture Principle

Structural Components

1. Tags (Isomorphic Signals)

2. Assets (Isomorphic Devices)

3. Digital Twins (Isomorphic State Machines)

4. Policies (Isomorphic Control Logic)

Data Flow Architecture

Isomorphic vs Non-Isomorphic Digital Twins

Non-Isomorphic (Traditional "Digital Twin")

Isomorphic (DigiPhusion Model)

Isomorphic Execution Model

Same Model, Different Runtimes

Where AI Fits (Safely)

Safe, Isomorphic AI Roles

Dangerous, Non-Isomorphic AI

Implementation in DigiPhusion

Isomorphic Foundations (Implemented)

Next Steps for Full Isomorphism

Benefits of Isomorphic Architecture

1. Simulation Before Deployment

2. Hot-Swap Hardware

3. Deterministic Debugging

4. Cloud/Edge Orchestration

5. Testable Safety Logic

Anti-Patterns to Avoid

Breaking Isomorphism