ARG software, intelligence and hardware each have a clear role. Explore what each system does, where it belongs and how it relates to the rest of the architecture.
Independent products, shared services and connected devices, with clear boundaries between experience, processing and physical control.
An engineering example using pump-pressure monitoring. Select each stage to see its input, processing and output. Actual paths depend on project equipment and configuration.
Engineering valueProtocol differences stay in the connection layer, while application logic consumes pressure.
Digital Twin combines ML analysis with an LLM assistant, RAG retrieval and project tools; Novexa connects AI to personal and business data and tasks. From on-controller learning and market analysis to knowledge retrieval and domain assistants, each path has its own data, models, tools and outputs, working alongside ENID, logic engines and product services.
From data to measurable predictions
Timestamped observations, features and input contracts
Fit the model; retain scalers, labels and versions
Classify a state or predict a future event
Walk-forward evaluation and recorded forecast outcomes
Evaluate a new model generation for runtime use
The market-analysis backend lifecycle is shown here; PLC learning has its own local lifecycle.
From knowledge and context to answers and actions
The request, user data and task scope
Retrieve relevant knowledge in RAG-enabled workflows
Use context and select tools appropriate to the request
Call tools through the system’s service and permission boundary
Return the answer and retain task history or results
Digital Twin’s RAG connects project knowledge to its assistant. EKOS has its own retrieval path; Operator and product assistants consume context in their respective workflows.
The twin connects equipment identity, observations, data quality, history and scenes. In one path, ARG AI trains models and analyzes equipment data. In the other, an LLM assistant uses RAG retrieval, conversation memory and project tools to investigate conditions and turn engineering requests into actionable proposals.
Project data and alarms, sensor history and technical documents; training data for the selected model.
ML for anomalies, consumption forecasts and maintenance; RAG for catalog, protocol and project-document knowledge; an LLM for multi-step investigation using state, alarm and history tools.
Forecasts and model metrics, explanations grounded in data and knowledge, and proposed project structures, dashboards, 3D scenes, rules and scenarios. Changes pass through the user confirmation workflow.
Example: “Investigate this equipment’s alarms and propose a monitoring dashboard.” The assistant gathers relevant data and knowledge, then presents a creation proposal for approval. In the ML path, equipment history supports numerical analysis; live site-data connections are defined during deployment.
The assistant uses selected context and account-scoped UDS data. Text and voice connect to domain tools; ERP, IoT and PC bridges carry explicit request-and-result workflows.
Text or voice requests, conversation history and relevant information selected from the user’s account.
An LLM builds answers from domain context and history; the voice workflow turns speech into text and tool commands. Image analysis extracts document or product information.
A personalized answer, recommendation or plan; connected workflows can execute a tool and return the service result to the conversation.
Examples: a spoken command is routed to a registered tool; an invoice image becomes reviewable structured fields; the business assistant uses the connected organization’s ERP context.
GMM, HMM and supervised model paths analyze market states; XGBoost forecasts transition destinations. Feature contracts, versioned models, walk-forward evaluation and episode tracking connect training to outcome validation.
Timestamped features and labels describe market moves. Training and prediction connect to an outcome ledger, preserving the first bar forecast for later evaluation against observed events.
ANOM learns an adaptive signal baseline with EWMA on the MCU and returns a BASIC variable. Warmup, consecutive-event confirmation, save/load and freeze define its local learning lifecycle.
Chunking, embeddings and a vector index combine with lexical search. Hybrid retrieval and RRF provide relevant context with source identity; document and embedding-model changes have an explicit lifecycle.
Prepared context and versioned memory connect to work orders and task-scoped tools. Candidate creation, validation, build, activation and restart have distinct stages, checkpoints and operation history.
Application profiles, crop knowledge and cultivation calendars provide assistant context. Recommendations remain in session history, while cost and revenue calculations support reviewable economic scenarios.
ENID and ACV carry point identity and state into runtime. Digital Twin connects these observations to equipment, scenes and history. Services, control logic and project adapters define command execution paths and connect analysis to visualization.
Smart-system platforms for industry, infrastructure, services and enterprise. Explore identity, local logic, learning, engineering operations and products through their processing and feedback boundaries.
Technical mechanismENID connects field messages, point models, logic and outputs. Point identity, device identity and command identity remain distinct.
Device data is decoded into ENID and the ACV model. Data consumption, hardware commands and internal value changes are separate paths. Device feedback re-enters ingestion only when a new report arrives; sending a command alone does not confirm execution.
Select a component to inspect its role and connections below. Scroll horizontally to explore the diagram.
A measurement or status report arrives from a device or gateway in the ingress protocol format.
Device serial and local point identity use explicit formatting and local/canonical conversions.
The same point can be addressed inside a device and across the system.
Decoder output is copied into a stable identity; category, direction, datatype and port select the point template.
Reusing a decoder does not replace the identity of an existing point.
Frame → ENID → ACV → rule → ENID → output frame separates engineering values from wire formats.
Adding an adapter does not require every consumer to parse a new protocol.
Project-scoped envelopes and idempotency keys bind the requested device, point and value.
A destination point and a particular change request are tracked separately.
A durable outbox tracks attempts and receipt progress with explicit retry limits.
Dispatch, device acknowledgement and observed state are distinguishable.
All components are visible. Select a system to inspect its role and connections.
Choose a use case and follow its path.
A building-monitoring path; sensor and gateway compatibility is specified per project.
Role, output and relationships at a glance