DIRAC: Unified Compute Architecture Framework¶

Unifying All Compute Through Intent-Driven Messaging

DIRAC (inspired by physicist Paul Dirac's unifying equations) represents OVES's compute architecture framework—a messaging-based ecosystem that transforms fragmented business systems into a unified, intent-driven platform through standardized messaging and topic exchange conventions.

DIRAC unifies business systems through twin central coordinators: FED (Federated API) and BRO (Messaging Broker), connecting six specialized domains: ARM, Odoo, ABS, BIA, TEAMS, and UXI.

Architecture Overview¶

DIRAC Framework Architecture

Twin central coordinators FED (Federated API) and BRO (Messaging Broker) orchestrating six functional domains with UXI as the primary interface layer

Core Philosophy: Intent-Driven Messaging¶

DIRAC establishes a universal messaging vocabulary enabling: - Clear Intent Expression: System interactions express what needs to happen, not how - Loose Coupling: Systems communicate through messages, not direct dependencies
- Event-Driven Coordination: Real-time responses to business events - Scalable Integration: New systems integrate by adopting messaging conventions

Topic Exchange Conventions¶

Standardized topic hierarchies based on emit/echo pairing:

emit/{domain}/{service}/{resource}/{id}/{event}   # Event notifications
echo/{domain}/{service}/{resource}/{id}/{event}   # Response confirmations
call/{domain}/{service}/{resource}/{id}/{verb}    # RPC-style commands
cmd/{domain}/{app}/{region}/{fleet}/{item}        # IoT device commands
dt/{domain}/{app}/{region}/{fleet}/{item}         # IoT data transfer
meta/{domain}/{app}/{region}/{fleet}/{item}       # Retained metadata

Emit/Echo Pattern: - emit: Initial event or request - echo: Acknowledgment or response
- Correlation: MQTT v5 correlation-data and response-topic - Tracing: trace_id user properties for distributed tracing

Example:

emit/abs/service/battery_swap/BSS-001/request
  → Processing by ABS
  → echo/abs/service/battery_swap/BSS-001/confirmed

DIRAC Components¶

Visual Diagram Color Coordination System¶

Purpose: To enhance understanding across all DIRAC documentation, diagrams, and training materials, a consistent color coding system is used to distinguish between Actors (who interact with the system) and Systems (what orchestrates the business logic).

Standard Color Palette (5 Colors):

Category	Color	PlantUML Code	Applied To
External Actors	Wheat (beige)	`#wheat`	Riders, Customers, End Users
Internal Actors	Light Green	`#lightgreen`	Attendants, Staff, Operators (affiliated with business)
Core DIRAC Systems	Light Cyan (light blue)	`#lightcyan`	ABS, ARM, BRO, FED, BIA, BSS Agent
External Business Systems	Gold (yellow)	`#gold`	Odoo ERP, Third-party integrations
Physical Assets/Infrastructure	Light Gray	`#lightgray`	Batteries, Stations, IoT devices, Swap Network

Design Rationale: - Actor vs System Separation: Colors clearly distinguish who acts from what orchestrates - Business Affiliation: Internal actors (staff) use different color than external actors (customers) - System Boundaries: Core DIRAC (light cyan) vs external systems (gold) are visually distinct - Physical vs Digital: Assets/infrastructure (gray) separate from digital systems - Simplicity: Limited to 5 colors for clarity and consistency

Application Guidelines:

Activity Diagrams: Use actor colors for swimlanes, system colors for brief context
Sequence Diagrams: Apply colors to all participants (actors and systems)
Architecture Diagrams: Use system colors for component boxes
Training Materials: Consistent colors help learners track actors across scenarios
Developer Documentation: Visual consistency reduces cognitive load

Benefits: - Cross-document continuity: Same color = same role across all diagrams - Faster comprehension: Instant recognition of actor vs system - Training efficiency: Staff and clients quickly identify familiar roles - Scalability: Simple palette works across all DIRAC domains

All diagrams in /docs/diagrams/ follow this color coordination system.

DIRAC Components¶

FED: Federated API Layer¶

Role: Standardized abstraction layer providing unified access to all subsystems

Core Capabilities: - Standardized Interface: OVES-opinionated API design - Cross-Referenced Data: Unified data model with referential integrity - API Federation: Combined schemas from multiple subsystems - Single Access Point: All subsystem interactions flow through FED

BRO: Central Messaging Broker Exchange¶

Role: MQTT-based messaging hub orchestrating inter-system communication

Core Capabilities: - MQTT-Based Messaging: Lightweight messaging via EMQX - Emit/Echo Coordination: Request-response tracking with correlation - Topic Management: Hierarchical organization with access control - Message Persistence: Reliable delivery with replay capabilities

Messaging Architecture:

IoT Device Communication:

dt/{dom}/{app}/{rt}/{fl}/{it}      # Compact data frames
cmd/{dom}/{app}/{rt}/{fl}/{it}     # Device commands
meta/{dom}/{app}/{rt}/{fl}/{it}    # Retained schema definitions

Service-to-Service Communication:

emit/{dom}/{svc}/{res}/{id}/{evt}  # Service events
echo/{dom}/{svc}/{res}/{id}/{evt}  # Response confirmations
call/{dom}/{svc}/{res}/{id}/{verb} # RPC-style commands

Message Structure:

{
  "sid": "schema.v1",           // Schema identifier
  "ts": 1730182103,            // Unix timestamp
  "trace": "abc-123",          // Distributed tracing ID
  "seq": 412,                  // Monotonic sequence (IoT)
  "id": "msg-uuid",            // Message correlation ID
  "d": { /* payload data */ }  // Actual message content
}

ARM: Asset Relations Management¶

Role: IoT-centric asset management system

Core Capabilities: - Digital Twin Management: Virtual representations of physical assets - Asset Lifecycle Tracking: Complete asset history - Relationship Mapping: Asset relationships and hierarchies - Maintenance Orchestration: Predictive maintenance scheduling

Odoo: Enterprise Resource Planning Platform¶

Role: Business operations platform handling CRM, payments, inventory, and financial management

Core Capabilities: - Customer Relationship Management: Complete customer lifecycle - Financial Operations: Accounting, invoicing, payment processing - Inventory Management: Stock control, procurement, supply chain - Sales Operations: Lead management, opportunity tracking

ABS: Asset-Based Services Universe¶

Role: Specialized platform for asset-as-a-service business models

Core Capabilities: - Service Model Definition: Flexible business model templates - Service Lifecycle Management: End-to-end service delivery - Dynamic Pricing: AI-driven pricing optimization - State Management: Advanced FSM-based service and asset state tracking

BIA: Business Intelligence Agents¶

Role: AI-powered analytics and automation platform

Core Capabilities: - Flow-Driven Automation: n8n and NodeRed integration - LLM Integration: Large language model access - Vector Database: Embedding storage for semantic search - Predictive Analytics: ML models for forecasting

TEAMS: Communications System¶

Role: Microsoft-based communications and document management

Core Capabilities: - Communication Platform: Microsoft Teams integration - Document Management: Business documents and records - Workflow Integration: Business processes and communication patterns - Knowledge Base: Centralized institutional knowledge

UXI: Unified User Experience Platform¶

Role: Single, web-native interface providing access to all DIRAC capabilities

Core Capabilities: - React-Based Architecture: Modern, responsive web and mobile experiences - Component Library: Reusable UI components - Progressive Web Apps: Mobile-optimized experiences - Role-Based Interfaces: Customized experiences by user roles

Integration: - Single API Access: UXI interacts exclusively with FED - Real-Time Updates: Live data via BRO messaging - Unified Interface: Single interface for all DIRAC capabilities

Implementation Phases¶

Phase 1: Foundation - Deploy central messaging broker (BRO) - Integrate existing ABS platform with BRO - Establish ARM platform and initial asset integrations - Begin UXI platform development

Phase 2: Expansion - Full Odoo integration - Deploy BIA platform with automation workflows - Expand ARM coverage to all asset types - Launch UXI with core functionality

Phase 3: Integration - Complete integration of all DIRAC components - Full UXI deployment - Advanced BIA capabilities with ML/AI integration - Establish DIRAC as unified operational platform

Phase 4: Optimization - Advanced automation and AI capabilities - Third-party ecosystem development - Global scaling and optimization

Technical Principles¶

Messaging-First Design: All interactions through standardized messaging
Event-Driven Architecture: Real-time responsiveness
Loose Coupling: Independent system evolution
Web-Native Architecture: Cloud-first deployment
API-First Design: Seamless integrations
Intent-Driven Computing: Clear business intent expression

DIRAC transforms fragmented operations into a cohesive, intelligent platform through messaging-first architecture and unified user experience.