Add Red Castle architecture concept — dual failover, digital twin, soft PLC

This commit is contained in:
jester 2026-03-23 19:10:06 +00:00
parent df038b0b2f
commit 071b07a9f5

153
red-castle/ARCHITECTURE.md Normal file
View File

@ -0,0 +1,153 @@
# Red Castle — System Architecture
*Captured from design session, March 23 2026. Ideas developed organically — treat as living concept document.*
---
## Core Problem
Small-to-mid manufacturers run production on PLCs with no redundancy. When the PLC goes down, the line stops. Enterprise redundancy (hot-standby PLC from Rockwell/Siemens) costs as much as the original system. These manufacturers can't afford that. They absorb the downtime instead.
**Red Castle solves this with a software-first, edge-first redundancy model at SMB price points.**
---
## Two Independent Failure Scenarios
### Scenario A — Internet / Cloud Goes Down
- Physical PLC keeps running **fully autonomously** — no dependency on internet for control
- Edge device enters local passive mode
- Cloud twin goes stale but production is unaffected
- Internet returns → twin resyncs, normal visibility restored
**Principle: Internet is for visibility and management only. Never for control.**
### Scenario B — Physical PLC Goes Down
- Edge device detects loss of PLC heartbeat
- Pulls current process state from digital twin (via internet/network)
- Activates soft PLC runtime on the edge device
- Takes over I/O — same sensors, same actuators, different controller
- Production continues at safe operating state
- Alert fired, failover event logged
- Physical PLC recovers → edge device hands control back, returns to passive mode
---
## The Edge Device — Two Operating Modes
### Passive Mode (Normal Operation)
- Sits silently on the plant network
- Monitors PLC heartbeat continuously
- Shadows I/O state and syncs with the digital twin
- **Zero footprint on the production process** — PLC doesn't know it's there
- Cheap to deploy, low risk, easy to justify to skeptical plant managers
### Active Mode (PLC Failure)
- Triggered by PLC heartbeat loss
- Pulls latest known process state from digital twin
- Spins up soft PLC runtime (IEC 61131-3 compatible)
- Assumes control of sensors and actuators independently
- Maintains safe process state until physical PLC is restored
- Graceful handback when PLC comes back online
**The edge device requires network/internet connectivity to function in active mode — this is intentional. It keeps the device simple and cheap (no need to store full program locally), pulls logic from the twin on demand, and allows remote updates without physical access.**
---
## Digital Twin Role
The digital twin is the connective tissue of the whole system:
- Continuously mirrors physical PLC state (tags, timers, counters, latch states)
- Hosted on edge-first infrastructure — runs on-premise or customer hardware, not forced cloud
- Provides the "last known good state" for failover
- Enables remote visibility and monitoring dashboard
- Feeds PLCDoc for automatic documentation and audit trails
- Can run in simulation mode for testing logic changes before deploying to physical PLC
---
## Soft PLC Runtime
- IEC 61131-3 compatible (Ladder Logic, Structured Text, Function Block)
- Runs on low-cost industrial edge hardware (mini-PC, industrial SBC)
- Not competing with Rockwell/Siemens — targeting non-safety-critical sequencing:
- Conveyors
- Filling and packaging lines
- Material handling
- Basic process control
- Safety-critical applications explicitly out of scope for v1
---
## Physical Architecture
```
Plant Floor
├── Physical PLC (Allen-Bradley / Siemens / other)
│ └── Controls sensors + actuators (primary)
├── Red Castle Edge Device
│ ├── Passive: monitors heartbeat, shadows I/O state
│ ├── Active: runs soft PLC runtime, controls same I/O
│ └── Requires: network connection to Red Castle cloud twin
└── Sensors / Actuators
└── Wired to BOTH PLC and Edge Device independently
Cloud / Edge Twin
├── Digital twin of PLC state (continuously synced)
├── Soft PLC logic mirror
├── Visibility dashboard
├── Failover state store
└── PLCDoc integration (auto-documentation, audit logs)
```
---
## Competitive Position
| Solution | Cost | Redundancy Type | OT Expertise Required |
|----------|------|-----------------|----------------------|
| Rockwell Hot Standby | $$$$ | PLC-to-PLC | Yes |
| Siemens S7 Redundancy | $$$$ | PLC-to-PLC | Yes |
| Red Castle | $ | PLC + Edge Device | No (managed service) |
**Key differentiator:** Hardware-diverse redundancy. A firmware bug, power fault, or hardware failure that takes down the PLC cannot affect the edge device because it runs a completely different stack on different hardware. This is more resilient than traditional hot-standby in certain failure modes.
---
## Sales Conversation
Not technology — a mode switch.
> "This device sits on your network doing nothing until your PLC dies. Then it keeps you running while you fix it. What does an hour of downtime cost you?"
If the answer is $5k$50k/hr (common in manufacturing), a $300500/mo subscription is an obvious yes.
---
## Revenue Model (Initial Thinking)
| Tier | Monthly | What's Included |
|------|---------|-----------------|
| Monitor | $99/mo | Passive monitoring only, visibility dashboard, no failover |
| Guardian | $299/mo | Full passive + active failover, 1 PLC |
| Guardian Pro | $599/mo | Multi-PLC coverage, PLCDoc integration, audit logs |
Hardware (edge device) sold separately or bundled — TBD.
---
## Open Questions (As of March 2026)
- [ ] State synchronization latency — how fast does the twin need to update for seamless failover?
- [ ] I/O wiring model — parallel wiring to both PLC and edge device, or switching relay?
- [ ] Edge device hardware spec — Raspberry Pi CM4 vs industrial mini-PC vs custom
- [ ] Handback protocol — how to safely return control to physical PLC after recovery
- [ ] Liability and scope boundaries for non-safety-critical definition
- [ ] Relationship between Red Castle edge device and ZeroLagHub infrastructure
---
*This document reflects a brainstorming session and is intentionally incomplete. Architecture will evolve with prototyping and customer discovery.*