DOCUMENTO 3 — TÉCNICO

Especificación preliminar del sistema

Universal Experimental Digital Twin Environment

Arquitectura, requisitos, modelo de datos, simulación, experimentación, interoperabilidad, validación y requisitos verificables

Salvador Lechuga Lombos - Aprocean — 2026

Resumen

El Universal Experimental Digital Twin Environment (UEDTE) propone una infraestructura digital destinada a convertir objetos y sistemas tecnológicos en entornos experimentales modificables, reproducibles, interoperables y evolutivos.

Un gemelo digital convencional representa un objeto o sistema. UEDTE pretende añadir una capa experimental que permita:

Detener → Abrir → Modificar → Simular → Comparar → Fusionar → Experimentar → Validar → Evolucionar.

El sistema se plantea como una arquitectura general aplicable a máquinas, vehículos, robots, instrumentos científicos, sistemas energéticos, vehículos submarinos, infraestructuras, tecnologías históricas y conceptos tecnológicos experimentales.

La especificación v0.2 incorpora especialmente el modelo formal de experimentos y simulaciones, la generación de variantes o forks, la fusión de gemelos, la trazabilidad de resultados y la conexión entre modelos digitales y prototipos físicos.

La hipótesis fundamental del proyecto es:

Una infraestructura interoperable de gemelos digitales modificables y reutilizables puede ampliar el espacio de soluciones exploradas y reducir determinados costes temporales y materiales de la experimentación tecnológica.

Esta hipótesis no se considera demostrada. El propio UEDTE deberá proporcionar los instrumentos necesarios para ponerla a prueba.

1. Introducción

El desarrollo tecnológico convencional suele presentar una secuencia relativamente lineal:

idea → diseño → prototipo → ensayo → modificación → nuevo prototipo.

Cada iteración puede requerir tiempo, materiales, fabricación, instrumentación y recursos humanos.

Los sistemas de simulación han reducido parte de estas limitaciones, pero habitualmente el modelo digital continúa siendo tratado como una representación de un producto concreto.

UEDTE propone un cambio de enfoque:

el gemelo digital deja de ser únicamente una representación y se convierte en un objeto experimental.

El usuario puede intervenir sobre él, generar variantes, comparar alternativas, incorporar componentes desarrollados por terceros y registrar el conocimiento generado por cada experimento.

2. Objetivo del sistema

UEDTE deberá proporcionar una infraestructura capaz de:

representar objetos tecnológicos;
descomponerlos jerárquicamente;
describir sus componentes;
representar materiales y propiedades;
describir interfaces;
congelar estados operativos;
modificar componentes;
generar versiones independientes;
ejecutar simulaciones;
registrar experimentos;
comparar resultados;
incorporar incertidumbre;
conservar la procedencia;
fusionar componentes y gemelos;
conectar simulación y prototipo;
registrar validaciones;
permitir colaboración;
reutilizar conocimiento;
facilitar educación e investigación;
construir un historial reproducible de evolución tecnológica.

3. Principio fundacional

CUATRO OJOS VEN MÁS QUE DOS

El concepto parte de una idea sencilla:

Cuantas más personas puedan observar, modificar, comparar y experimentar sobre una representación común de un sistema, mayor puede ser el espacio de soluciones explorado.

Sin embargo, UEDTE no presupone que una comunidad numerosa produzca automáticamente mejores soluciones.

La plataforma deberá comprobar experimentalmente qué ocurre cuando aumentan:

participantes;
variantes;
reutilización;
capacidad de simulación;
diversidad de conocimientos;
velocidad de evaluación.

Por ello, el proyecto es simultáneamente:

infraestructura tecnológica + metodología experimental + hipótesis científica.

4. Principios de diseño

4.1 Modularidad

Todo sistema deberá poder descomponerse en componentes reutilizables.

4.2 Interoperabilidad

Los componentes deberán poder integrarse cuando sus interfaces sean compatibles.

4.3 Reversibilidad

Una modificación nunca deberá destruir el modelo original.

4.4 Trazabilidad

Toda modificación deberá poder remontarse hasta su origen.

4.5 Reproducibilidad

Un experimento deberá poder volver a ejecutarse con las mismas condiciones.

4.6 Proveniencia

Deberá conocerse quién creó, modificó o aportó cada elemento.

4.7 Validación

La simulación no deberá confundirse automáticamente con evidencia experimental.

4.8 Escalabilidad

La arquitectura deberá poder trabajar desde un componente hasta un sistema complejo.

4.9 Accesibilidad progresiva

La complejidad deberá aparecer según las necesidades del usuario.

4.10 Conservación del conocimiento

Los resultados negativos y las variantes descartadas también deberán conservarse.

5. Arquitectura conceptual

UEDTE

│

┌────────┴────────┐

│ │

OBJETO ENTORNO

│ │

COMPONENTES CONDICIONES

│ │

└────────┬────────┘

│

ESTADO

│

SNAPSHOT

│

MODIFICACIÓN

│

FORK

│

EXPERIMENTO

│

SIMULACIÓN

│

RESULTADO

│

COMPARACIÓN

│

VALIDACIÓN

│

FUSIÓN

│

EVOLUCIÓN

6. Modelo conceptual del objeto UEDTE

Cada objeto deberá contener, como mínimo:

OBJECT

├── Identity

├── Geometry

├── Components

├── Materials

├── Interfaces

├── Physics

├── Constraints

├── Behaviour

├── Environment

├── State

├── Experiments

├── Simulations

├── Results

├── Versions

├── Provenance

├── Validation

├── Rights

└── Security

Este modelo permitirá representar tanto un componente individual como un sistema completo.

7. Identidad

Cada objeto tendrá un identificador único.

Campos preliminares:

object_id
object_name
object_type
version
status
autor

institution
creation_date
parent_object
license

Los identificadores deberán permanecer estables aunque el objeto evolucione mediante nuevas versiones.

8. Estados del objeto

Se propone:

Estado	Significado
CONCEPT	concepto inicial
MODEL	modelo digital
SIMULATED	sometido a simulación
EXPERIMENTAL	utilizado en experimentación
PROTOTYPE	prototipo físico
VALIDATED	validado según criterios definidos
RETIRED	retirado

La transición entre estados no será automática cuando implique validación física.

9. Descomposición jerárquica

Un objeto podrá representarse:

Sistema → subsistema → módulo → conjunto → componente → elemento.

Ejemplo:

BUQUE

└── PROPULSIÓN

└── MOTOR

└── SISTEMA DE INYECCIÓN

└── INYECTOR

└── ELEMENTO

Cada nivel podrá tener identidad propia.

Esto permite modificar un componente sin necesidad de reconstruir todo el sistema.

10. Estado digital

UEDTE introduce el concepto de:

DIGITAL STATE SNAPSHOT

Es una captura reproducible del estado de un sistema en un instante determinado.

Podrá incluir:

posición;
velocidad;
temperatura;
presión;
energía;
carga;
estado de sensores;
parámetros de control;
variables ambientales;
estado de cada componente.

Esto permite realizar una intervención sobre un sistema digital en un punto temporal concreto.

11. Cirugía digital

La Digital Surgery constituye una de las funciones características del sistema.

Proceso:

SNAPSHOT

↓

SELECCIONAR COMPONENTE

↓

ABRIR

↓

MODIFICAR

↓

COMPROBAR COMPATIBILIDAD

↓

CERRAR

↓

SIMULAR

El modelo original permanece intacto.

La intervención genera una nueva versión.

12. Fork experimental

Toda modificación significativa deberá poder generar:

VERSION ORIGINAL

↓

FORK A

FORK B

FORK C

Cada rama conserva su propia genealogía.

Esto permitirá comparar simultáneamente distintas soluciones.

13. Experimento

UEDTE distingue expresamente entre:

SIMULACIÓN

Ejecución computacional de un modelo bajo determinadas condiciones.

EXPERIMENTO

Proceso estructurado destinado a responder una pregunta mediante una hipótesis, una intervención y una evaluación.

Un experimento deberá incluir:

experiment_id;
objeto;
versión;
hipótesis;
objetivo;
estado inicial;
modificación;
condiciones;
simulaciones;
resultados;
análisis;
autor;
fecha;
validación.

14. Estados del experimento

Se propone:

PLANNED

↓

READY

↓

RUNNING

↓

SIMULATED

↓

EXPERIMENTAL

↓

ANALYZED

↓

VALIDATED

También podrán existir:

REJECTED
INCONCLUSIVE

Un experimento rechazado o inconcluso seguirá formando parte del conocimiento del sistema.

15. Simulación

Cada simulación deberá identificar:

simulation_id;
experiment_id;
objeto;
versión;
tipo;
motor;
versión del motor;

configuración;
condiciones iniciales;
condiciones de contorno;
parámetros;
entorno;
solver;
recursos computacionales;
duración;
resultados.

16. Tipos de simulación

Se propone inicialmente:

MECHANICAL
STRUCTURAL
CFD
THERMAL
ELECTRICAL
CHEMICAL
CONTROL
MULTIPHYSICS
SYSTEM
AGENT
OTHER

La arquitectura deberá permitir incorporar nuevos tipos sin modificar el núcleo del sistema.

17. Multifidelidad

UEDTE no deberá exigir siempre simulaciones de máxima fidelidad.

Se proponen:

Nivel	Aplicación
LOW	exploración rápida
MEDIUM	ingeniería preliminar
HIGH	análisis avanzado
HPC	problemas de elevada complejidad

La lógica será:

explorar barato → seleccionar → aumentar fidelidad → validar.

18. Experimentos multifactoriales

El sistema deberá permitir modificar simultáneamente varias variables.

Ejemplo:

diámetro de hélice;
RPM;
masa;
temperatura;
corriente.

Se podrán generar matrices de experimentación y parameter sweeps.

Esto permitirá explorar automáticamente grandes espacios de diseño.

19. Resultados

Los resultados podrán ser:

escalares;
vectores;
campos;
series temporales;
imágenes;
mallas;
gráficos;
informes;
datasets.

Cada resultado deberá conservar:

unidad;
incertidumbre;
confianza;
procedencia;
modelo utilizado.

20. Comparación

UEDTE deberá poder comparar:

ORIGINAL

vs.

MODIFICADO

vs.

SIMULADO

vs.

EXPERIMENTAL

Ejemplo:

Variable	Original	Variante	Diferencia
Potencia	X	Y	+X %
Consumo	X	Y	-X %
Vibración	X	Y	-X %
Temperatura	X	Y	+X °C

La plataforma deberá evitar presentar una mejora parcial como una mejora global.

21. Incertidumbre

Todo resultado relevante podrá incorporar:

incertidumbre;
intervalo;
confianza;
calidad de datos;
nivel de fidelidad;
disponibilidad de validación.

Ejemplo:

Potencia estimada: 118,4 kW
Incertidumbre: ±X
Confianza del modelo: 0,82
Validación física: pendiente.

22. Validación

UEDTE establece una separación estricta:

MODELO

↓

SIMULACIÓN

↓

RESULTADO COMPUTACIONAL

↓

ENSAYO FÍSICO

↓

COMPARACIÓN

↓

VALIDACIÓN

Una simulación no convierte automáticamente un diseño en tecnología validada.

23. Conexión con prototipos físicos

La plataforma deberá poder representar:

MODELO DIGITAL → PROTOTIPO → ENSAYO → DATOS → GEMELO ACTUALIZADO

Los datos físicos podrán utilizarse para:

calibrar;
detectar errores;
modificar parámetros;
actualizar modelos;
estimar incertidumbres.

Se establece así un ciclo cerrado:

Digital Twin ↔ Physical Prototype

24. Experimental Fingerprint

Cada experimento reproducible podrá generar una:

UEDTE EXPERIMENTAL FINGERPRINT

Construida a partir de:

versión del objeto;
versiones de componentes;
parámetros;
estado inicial;
condiciones ambientales;
condiciones de contorno;
motor de simulación;
versión del motor;
configuración;
recursos relevantes.

Su objetivo será permitir identificar inequívocamente una ejecución experimental.

25. Fusión de gemelos

UEDTE introduce:

DIGITAL TWIN FUSION

Dos objetos independientes podrán combinarse si sus interfaces son compatibles.

El sistema deberá analizar:

geometría;
coordenadas;
unidades;
interfaces;
energía;
señales;
comunicaciones;
cargas;
materiales;
restricciones;
temporalidad.

Resultado:

COMPATIBLE

COMPATIBLE CON ADAPTACIÓN

INCOMPATIBLE

26. Contrato de interoperabilidad

Cada módulo podrá disponer de un:

DIGITAL INTEROPERABILITY CONTRACT

que describa:

entradas;
salidas;
unidades;
interfaces;
tolerancias;
requisitos energéticos;
protocolos;
límites;
dependencias;
restricciones.

Esto permitirá convertir los componentes en piezas reutilizables.

27. Inteligencia artificial

La IA podrá intervenir en cinco funciones principales:

1. Asistencia

Explicar el modelo.

2. Análisis

Detectar relaciones y dependencias.

3. Generación

Proponer variantes.

4. Exploración

Ejecutar grandes conjuntos de alternativas.

5. Descubrimiento

Detectar configuraciones o relaciones no evidentes.

La decisión final sobre una modificación relevante deberá permanecer bajo control humano según el nivel de riesgo.

28. Ciclo IA experimental

GENERAR

↓

SIMULAR

↓

FILTRAR

↓

RANKING

↓

PROPONER

↓

VALIDAR HUMANAMENTE

↓

EXPERIMENTAR

La IA será, por tanto, un explorador del espacio de soluciones, no un certificador automático.

29. Proveniencia

Cada componente deberá conservar:

origen;
autor;
fecha;
versión;
modificaciones;
fuente;
licencia;
colaboradores;
validaciones.

Esto será especialmente importante cuando se fusionen modelos de instituciones diferentes.

30. Escala de confianza de procedencia

Se propone:

Nivel	Significado
CONF-0	desconocido
CONF-1	hipótesis
CONF-2	inferencia
CONF-3	documentado
CONF-4	experimental
CONF-5	validación independiente

Esta escala es una propuesta UEDTE y no un estándar internacional existente.

31. Reconstrucción histórica

UEDTE podrá representar tecnologías históricas.

El sistema deberá distinguir:

DOCUMENTADO

RECONSTRUIDO

INFERIDO

HIPOTÉTICO

Esto permitirá reconstruir máquinas, instrumentos y sistemas a partir de:

planos;
fotografías;
patentes;
documentos;
restos físicos;
catálogos;
testimonios.

32. Ciencia ficción y SF-TECH ATLAS

UEDTE podrá recibir conceptos procedentes de:

SF-TECH ATLAS

El proceso será:

FICCIÓN → CONCEPTO → DESCOMPOSICIÓN → HIPÓTESIS → MODELO → SIMULACIÓN → EXPERIMENTO

El concepto ficticio no será tratado como evidencia científica.

33. Educación

UEDTE deberá proporcionar distintos niveles de acceso:

Explorer

Exploración visual.

Student

Modificación básica.

Technical

Parámetros de ingeniería.

Researcher

Experimentos y simulaciones.

Expert

Modelos avanzados, datos y validación.

La interfaz deberá ocultar complejidad innecesaria sin eliminar la posibilidad de acceder a ella.

34. Arquitectura funcional

┌─────────────────────────────┐

│ USER INTERFACE │

├─────────────────────────────┤

│ REPRESENTATION ENGINE │

├─────────────────────────────┤

│ SEMANTIC MODEL │

├─────────────────────────────┤

│ PHYSICS ENGINE │

├─────────────────────────────┤

│ EXPERIMENTAL ENGINE │

├─────────────────────────────┤

│ AI ENGINE │

├─────────────────────────────┤

│ INTEROPERABILITY ENGINE │

├─────────────────────────────┤

│ PROVENANCE / DATA / AUDIT │

├─────────────────────────────┤

│ VALIDATION / REPRODUCTION │

└─────────────────────────────┘

35. Requisitos funcionales preliminares

ID	Requisito
FR-001	Crear objetos UEDTE
FR-002	Crear componentes
FR-003	Asociar componentes
FR-004	Crear snapshots
FR-005	Modificar componentes
FR-006	Crear forks
FR-007	Ejecutar simulaciones
FR-008	Crear experimentos
FR-009	Registrar resultados
FR-010	Comparar variantes
FR-011	Fusionar objetos
FR-012	Registrar procedencia
FR-013	Registrar validaciones
FR-014	Reproducir experimentos
FR-015	Exportar modelos
FR-016	Gestionar permisos
FR-017	Incorporar datos físicos
FR-018	Registrar incertidumbre
FR-019	Mantener historial
FR-020	Facilitar colaboración

36. Requisitos no funcionales

El sistema deberá priorizar:

interoperabilidad;
seguridad;
disponibilidad;
escalabilidad;
auditabilidad;
reproducibilidad;
extensibilidad;
accesibilidad;
eficiencia;
conservación de datos;
control de versiones.

37. Matriz de requisitos verificables

Esta matriz transforma los requisitos conceptuales del SRS en requisitos susceptibles de comprobación objetiva.

Se adopta inicialmente la siguiente clasificación de verificación:

I — Inspección: revisión de estructura, documentación o configuración.
A — Análisis: cálculo o evaluación de datos.
D — Demostración: ejecución funcional observable.
E — Ensayo: prueba controlada con datos o condiciones definidas.

37.1 Matriz principal

ID	Requisito verificable	Criterio de aceptación	Método	Evidencia
VR-001	Cada objeto deberá poseer identificador único	No existen dos objetos activos con el mismo object_id	D/I	Registro de objetos
VR-002	Cada objeto deberá tener versión	Toda modificación genera una versión identificable	D	Historial de versiones
VR-003	El sistema deberá conservar el objeto original	Una modificación no altera la versión de origen	D/E	Comparación hash/versiones
VR-004	Deberá ser posible descomponer un objeto	El usuario puede navegar sistema → componente	D	Árbol jerárquico
VR-005	Cada componente deberá tener identidad propia	El componente puede identificarse independientemente	I/D	Registro de componentes
VR-006	Deberán registrarse las interfaces	Cada interfaz definida contiene tipo, entradas/salidas y unidades	I	Ficha de interfaz
VR-007	Deberá poder crearse un Snapshot	El sistema reproduce el estado almacenado	D/E	Snapshot reproducible
VR-008	Un Snapshot deberá ser inmutable	El estado original no cambia al crear variantes	D	Auditoría
VR-009	Deberá poder modificarse un componente	Una modificación genera una nueva variante	D	Fork
VR-010	El sistema deberá conservar la genealogía del Fork	Puede reconstruirse el origen de cada variante	I/D	Grafo de versiones
VR-011	Deberá poder crearse un experimento	El sistema permite registrar hipótesis, objetivo y condiciones	D	Registro EXP
VR-012	Un experimento deberá estar asociado a una versión	No puede existir un experimento sin referencia al objeto	I	Metadatos
VR-013	Deberá poder ejecutarse una simulación	Se genera un resultado asociado al modelo	D/E	Log de ejecución
VR-014	La simulación deberá identificar el motor empleado	Se registra nombre y versión del motor	I	Metadatos
VR-015	Deberán registrarse las condiciones iniciales	Todas las variables definidas aparecen en el registro	I	Ficha de simulación
VR-016	Deberán registrarse las condiciones de contorno	Las condiciones utilizadas son recuperables	I	Ficha de simulación
VR-017	Deberán registrarse los parámetros	Los valores utilizados pueden recuperarse	I	Dataset
VR-018	Deberán conservarse los resultados	El resultado permanece vinculado al experimento	D/I	Registro de resultados
VR-019	Los resultados deberán indicar unidades cuando proceda	Cada magnitud física tiene unidad definida	I	Dataset
VR-020	Deberá poder compararse una variante con su original	Se genera una comparación cuantitativa	D/E	Informe comparativo
VR-021	Deberá poder registrarse incertidumbre	El resultado admite valor de incertidumbre o estado N/A justificado	I	Dataset
VR-022	Deberá distinguirse simulación de ensayo físico	El sistema mantiene estados separados	D/I	Registro de estados
VR-023	Deberá poder registrarse un ensayo físico	Se almacenan condiciones, instrumentación y datos	D	Registro experimental
VR-024	Deberá poder reproducirse una simulación	Misma configuración produce una ejecución identificable	E	Experimental Fingerprint
VR-025	Deberá poder calcularse una huella experimental	El sistema genera un identificador reproducible de configuración	A/D	Fingerprint
VR-026	Deberá poder fusionarse al menos dos objetos compatibles	La plataforma genera un objeto combinado	D/E	Modelo fusionado
VR-027	Deberá detectar incompatibilidades	El sistema identifica al menos una incompatibilidad conocida	D/E	Informe de compatibilidad
VR-028	Deberán conservarse los objetos originales tras una fusión	Los objetos fuente permanecen independientes	D	Historial
VR-029	Deberá registrarse la procedencia	Cada componente externo tiene fuente y autor	I	Provenance record
VR-030	Deberán registrarse las licencias	Los objetos incorporan información de derechos	I	Metadatos jurídicos
VR-031	Deberá mantenerse un registro de auditoría	Las operaciones críticas quedan registradas	D/I	Audit log
VR-032	Deberán existir diferentes niveles de acceso	Un usuario no autorizado no accede a contenido restringido	E	Prueba de permisos
VR-033	Deberá poder exportarse un objeto	Se obtiene una representación externa válida	D	Archivo exportado
VR-034	Deberá poder importarse un objeto compatible	El objeto recupera su estructura mínima	D/E	Prueba de importación
VR-035	La IA deberá identificar sus propuestas como generadas por IA	Las propuestas aparecen marcadas	I/D	Registro AI provenance
VR-036	Una propuesta de IA no deberá convertirse automáticamente en validación	La transición requiere acción autorizada	D/E	Prueba de flujo
VR-037	Deberá conservarse información de simulaciones fallidas	Una ejecución fallida deja registro técnico	D	Log de error
VR-038	Deberán conservarse resultados negativos	Un experimento rechazado permanece consultable	D/I	Base experimental
VR-039	Deberán distinguirse datos documentados de inferidos	La procedencia contiene nivel de confianza	I	Provenance
VR-040	Deberá poder reconstruirse la genealogía experimental	Desde resultado puede recuperarse objeto, versión y experimento	D/E	Traceability test

37 BIS. TABLA DE CONTROL DE ALCANCE

La presente tabla establece los límites funcionales y tecnológicos de la especificación UEDTE-SRS v0.2.

Su objetivo es evitar que el proyecto intente resolver simultáneamente todos los problemas asociados a los gemelos digitales, la simulación, la inteligencia artificial, la robótica, la interoperabilidad y la experimentación física.

El principio rector será:

Primero demostrar el núcleo experimental de UEDTE; después ampliar progresivamente sus capacidades.

37 BIS.1 Control general del alcance

ID	Área	Incluido en v0.2	MVP	Futuro	Fuera de alcance actual	Prioridad
SC-001	Identidad de objetos	✓	✓	—	—	MUST
SC-002	Componentes modulares	✓	✓	—	—	MUST
SC-003	Jerarquía objeto-componente	✓	✓	—	—	MUST
SC-004	Versionado	✓	✓	—	—	MUST
SC-005	Snapshot de estados	✓	✓	—	—	MUST
SC-006	Modificación digital	✓	✓	—	—	MUST
SC-007	Fork experimental	✓	✓	—	—	MUST
SC-008	Registro de experimentos	✓	✓	—	—	MUST
SC-009	Registro de simulaciones	✓	✓	—	—	MUST
SC-010	Comparación de variantes	✓	✓	—	—	MUST
SC-011	Trazabilidad	✓	✓	—	—	MUST
SC-012	Proveniencia	✓	✓	—	—	MUST
SC-013	Reproducibilidad	✓	✓	—	—	MUST
SC-014	Incertidumbre	✓	Parcial	✓	—	SHOULD
SC-015	Ensayo físico	Conceptual	—	✓	—	FUTURE
SC-016	Gemelo físico-digital cerrado	Conceptual	—	✓	—	FUTURE
SC-017	Fusión de gemelos	✓	Parcial	✓	—	SHOULD
SC-018	Interoperabilidad CAD/CAE	Conceptual	—	✓	—	FUTURE
SC-019	IA generativa	✓	—	✓	—	SHOULD
SC-020	IA autónoma de exploración	Conceptual	—	✓	—	FUTURE
SC-021	Simulación multifísica avanzada	Conceptual	—	✓	—	FUTURE
SC-022	HPC	—	—	✓	—	FUTURE
SC-023	UEDTE-OCEAN 001	Definido	—	✓	—	FUTURE
SC-024	SF-TECH ATLAS	Definido	—	✓	—	FUTURE
SC-025	Patrimonio tecnológico	Definido	—	✓	—	FUTURE
SC-026	Plataforma educativa	Conceptual	—	✓	—	FUTURE
SC-027	VR/AR	Conceptual	—	✓	—	FUTURE
SC-028	Interfaz holográfica	Conceptual	—	✓	—	FUTURE
SC-029	Robótica física autónoma	—	—	✓	—	FUTURE
SC-030	Certificación industrial	—	—	—	✓	OUT
SC-031	Certificación de seguridad de sistemas críticos	—	—	—	✓	OUT
SC-032	Sustitución de ensayos físicos obligatorios	—	—	—	✓	OUT
SC-033	Sustitución del ingeniero/experto	—	—	—	✓	OUT
SC-034	Validación automática por IA	—	—	—	✓	OUT
SC-035	Garantía de que una simulación representa la realidad	—	—	—	✓	OUT

37 BIS.2 Definición de las categorías

INCLUIDO

Forma parte de la arquitectura conceptual de la versión v0.2.

MVP

Debe demostrarse mediante el primer prototipo funcional.

FUTURO

Está previsto en la evolución del sistema, pero no deberá retrasar la demostración del núcleo.

OUT — FUERA DE ALCANCE

No forma parte del sistema UEDTE definido en esta versión y no deberá utilizarse para evaluar negativamente el MVP.

37 BIS.3 Núcleo mínimo de UEDTE

El núcleo que deberá demostrarse antes de ampliar el proyecto será:

UEDTE MVP

│

┌───────────┴───────────┐

│ │

OBJETO COMPONENTE

│ │

└───────────┬───────────┘

│

SNAPSHOT

│

MODIFICACIÓN

│

FORK

│

EXPERIMENTO

│

SIMULACIÓN

│

RESULTADO

│

COMPARACIÓN

│

TRAZABILIDAD

│

REPRODUCIBILIDAD

Si este circuito funciona de extremo a extremo, UEDTE podrá considerarse técnicamente demostrable en su primera etapa.

37 BIS.4 Lo que deliberadamente NO intenta resolver UEDTE v0.2

La especificación no pretende todavía:

desarrollar un nuevo motor CFD completo;
desarrollar un nuevo solver FEM completo;
sustituir los principales paquetes CAD/CAE existentes;
construir un supercomputador;
desarrollar un robot submarino físico completo;
certificar sistemas industriales;
certificar sistemas de defensa;
sustituir ensayos físicos reglamentarios;
garantizar automáticamente la seguridad de un diseño;
sustituir la responsabilidad profesional del ingeniero;
convertir automáticamente una simulación en evidencia experimental;
crear una inteligencia artificial autónoma capaz de aprobar sus propios diseños.

Estos elementos podrán integrarse mediante interoperabilidad o desarrollarse en fases posteriores.

37 BIS.5 Frontera entre UEDTE y herramientas externas

UEDTE no necesita desarrollar internamente todas las tecnologías utilizadas.

La arquitectura podrá funcionar como capa experimental de integración.

UEDTE

│

┌────────────┼────────────┐

│ │ │

CAD CAE IA

│ │ │

├────── SIMULACIÓN ───────┤

│ │ │

└──────── EXPERIMENTO ────┘

│

RESULTADO

│

VALIDACIÓN

Por tanto, un motor externo de simulación podrá ser utilizado siempre que:

pueda identificarse;
pueda registrarse su versión;
puedan documentarse sus parámetros;
puedan recuperarse sus resultados;
pueda establecerse su relación con el objeto experimental.

37 BIS.6 Control de expansión del proyecto

Toda nueva funcionalidad propuesta deberá responder previamente a cinco preguntas:

Pregunta	Criterio
1. ¿Es necesaria para el núcleo?	Si no, puede pasar a FUTURO
2. ¿Es verificable?	Debe existir una prueba objetiva
3. ¿Es interoperable?	No deberá crear un sistema cerrado innecesariamente
4. ¿Es reproducible?	Debe poder conservarse su configuración
5. ¿Aumenta el valor experimental?	Debe justificar su complejidad

Una función que no supere estos criterios no deberá incorporarse automáticamente al núcleo.

37 BIS.7 Criterio de entrada de nuevas funciones

Se propone un mecanismo:

PROPUESTA → EVALUACIÓN → CLASIFICACIÓN → PRIORIZACIÓN → DESARROLLO → VERIFICACIÓN

Cada nueva función recibirá una de las siguientes etiquetas:

CORE
MVP
EXTENSION
RESEARCH
FUTURE
OUT

Esto permitirá evitar la expansión incontrolada del proyecto.

37 BIS.8 Control de alcance específico de UEDTE-OCEAN 001

El demostrador submarino tendrá asimismo límites propios.

Incluido inicialmente

vehículo submarino digital;
estructura;
propulsión;
energía;
sensores;
navegación;
comunicaciones;
entorno oceánico;
manipulación;
simulación;
experimentación digital;
comparación de configuraciones.

Posterior

integración con hardware real;
pruebas en tanque;
pruebas en mar;
manipulación autónoma avanzada;
micro-ROVs;
navegación autónoma avanzada;
integración de sensores especializados.

No necesario para el primer demostrador

construir un AUV/ROV operacional completo;
alcanzar inmediatamente grandes profundidades;
resolver todas las comunicaciones submarinas;
desarrollar una IA submarina completamente autónoma.

El objetivo inicial será demostrar el método UEDTE aplicado al dominio submarino, no fabricar inmediatamente un vehículo submarino definitivo.

37 BIS.9 Control de alcance de SF-TECH ATLAS

SF-TECH ATLAS funcionará como módulo experimental complementario.

Incluido

FICCIÓN → CONCEPTO → HIPÓTESIS → MODELO → SIMULACIÓN

Futuro

EXPERIMENTO → PROTOTIPO → VALIDACIÓN

Fuera de alcance

Considerar que una idea procedente de ciencia ficción constituye por sí misma una predicción científica o una tecnología demostrada.

El sistema deberá conservar siempre la separación entre:

obra ficticia → interpretación → hipótesis tecnológica → evidencia científica.

37 BIS.10 Regla de oro del alcance

La especificación adopta la siguiente regla:

UEDTE no necesita resolver todo el problema tecnológico para demostrar que su metodología funciona.

El primer objetivo es mucho más concreto:

demostrar que un objeto digital puede convertirse en un objeto experimental reproducible, modificable, versionable y trazable.

Una vez demostrado ese núcleo, podrán añadirse:

fusión → IA → simulación avanzada → patrimonio → SF-TECH → educación → robótica → experimentación física.

37 BIS.11 Criterio de congelación del alcance

Antes de iniciar el desarrollo del MVP deberá establecerse una:

SCOPE FREEZE v0.2

Durante esta fase únicamente podrán incorporarse cambios que afecten a:

seguridad;
corrección;
interoperabilidad esencial;
reproducibilidad;
trazabilidad;
cumplimiento de requisitos MUST.

Las nuevas capacidades deberán registrarse como propuestas para v0.3 o posteriores, evitando modificar continuamente el objetivo del primer demostrador.

37 BIS.12 Indicador de control de alcance

Se propone incorporar un indicador sencillo:

Scope Stability Index — SSI

[
SSI = \frac{N_{requisitos\ estables}}{N_{requisitos\ totales}}
]

Un valor elevado indicará que la arquitectura se encuentra suficientemente estabilizada para iniciar desarrollo.

También podrá medirse:

[
Scope\ Growth =
\frac{N_{requisitos\ nuevos}}{N_{requisitos\ iniciales}}
]

El objetivo no será maximizar el SSI artificialmente, sino detectar tempranamente una expansión descontrolada del proyecto.

37 BIS.13 Registro de cambios de alcance

Toda modificación relevante deberá registrar:

Campo	Contenido
change_id	Identificador
date	Fecha
proposer	Proponente
description	Cambio
reason	Justificación
impact	Impacto
priority	Prioridad
version_target	Versión objetivo
decision	Aprobado/rechazado/pendiente
evidence	Evidencia

Esto permitirá que la propia evolución de UEDTE sea trazable.

37 BIS.14 Decisión de alcance para DOCUMENTO 3

Con esta matriz, DOCUMENTO 3 — UEDTE-SRS v0.2 queda definido como:

Especificación preliminar del núcleo técnico y experimental de UEDTE, no como especificación completa de toda la plataforma futura.

La frontera queda establecida entre:

AHORA

Objeto → componente → snapshot → modificación → fork → experimento → simulación → resultado → comparación → trazabilidad → reproducibilidad.

DESPUÉS

fusión → IA avanzada → UEDTE-OCEAN → SF-TECH → patrimonio → educación → hardware → validación física.

NO ES OBJETIVO

sustituir ingeniería profesional, ensayos reglamentarios, certificación industrial o validación física mediante simulación.

Esta separación deberá mantenerse en las siguientes versiones del SRS.

37 BIS.15 Conclusión

La tabla de control de alcance permite que UEDTE conserve una característica fundamental:

ambición en la visión, pero disciplina en la ingeniería.

El proyecto puede aspirar a convertirse en una infraestructura universal de experimentación tecnológica sin pretender construir todas sus capacidades simultáneamente.

El principio de desarrollo será:

NÚCLEO → DEMOSTRACIÓN → MEDICIÓN → VALIDACIÓN → EXTENSIÓN.

No:

IDEA → TODAS LAS TECNOLOGÍAS A LA VEZ.

37 TER. CRITERIOS DE ACEPTACIÓN DEL MVP

UEDTE-SRS v0.2 — Minimum Viable Product Acceptance Criteria

37 TER.1. Objetivo

Esta sección define las condiciones mínimas que deberá satisfacer el primer prototipo funcional del Universal Experimental Digital Twin Environment (UEDTE).

El MVP deberá demostrar que un objeto digital puede convertirse en un entorno experimental en el que sea posible:

Crear → Descomponer → Capturar estado → Modificar → Versionar → Simular → Comparar → Reproducir → Trazar.

La aceptación no dependerá de la cantidad de funcionalidades desarrolladas, sino de la demostración verificable de este circuito completo.

37 TER.2. Escenario de demostración

Se utilizará un modelo digital simplificado de un motor naval o de un sistema electromecánico equivalente.

El modelo incluirá, como mínimo:

Un objeto principal identificable.
Tres componentes o subsistemas diferenciados.
Relaciones entre los componentes.
Un conjunto de parámetros modificables.
Un estado inicial reproducible.
Un experimento con hipótesis y objetivo.
Una simulación ejecutable.
Un resultado cuantitativo comparable.
Un historial de versiones y modificaciones.

El motor naval será un caso de demostración, no una limitación de la arquitectura general.

Importante: el MVP podrá utilizar un modelo físico simplificado y un motor de simulación existente. No será necesario desarrollar un solver multifísico propio ni fabricar un motor real.

37 TER.3. Matriz de aceptación funcional

ID	Criterio de aceptación	Condición para aprobar	Evidencia exigida
AC-001	Creación del objeto	Se crea un objeto con identificador, nombre, tipo y versión	Registro del objeto
AC-002	Descomposición	Se visualizan al menos tres componentes diferenciados	Árbol de componentes
AC-003	Propiedades	Se consultan y modifican propiedades autorizadas de un componente	Ficha antes/después
AC-004	Snapshot	Se guarda y recupera un estado inicial completo para el modelo de prueba	Archivo y comparación
AC-005	Integridad del original	La modificación de una variante no altera la versión original	Comparación de versiones
AC-006	Fork	Se crea una variante independiente con identificador propio	Grafo de versiones
AC-007	Registro experimental	Se registran hipótesis, objetivo, condiciones y modificación	Ficha del experimento
AC-008	Simulación	Se ejecuta una simulación y se obtiene un resultado interpretable	Log y resultado
AC-009	Configuración	Se recuperan los parámetros y condiciones de la ejecución	Registro de configuración
AC-010	Comparación	Se comparan el modelo original y la variante mediante al menos una variable cuantitativa	Informe comparativo
AC-011	Repetición	Se repite una ejecución con la misma configuración y se comprueba su consistencia	Informe de repetición
AC-012	Trazabilidad	Desde un resultado se recuperan el experimento, el objeto, la versión y los parámetros utilizados	Prueba de trazabilidad
AC-013	Registro de errores	Una ejecución fallida genera un registro consultable	Log de error
AC-014	Exportación	Se exporta y vuelve a importar un objeto de prueba conservando los campos obligatorios	Prueba de ida y vuelta
AC-015	Estados de validación	Una simulación no se presenta automáticamente como ensayo físico validado	Prueba del flujo de estados
AC-016	Documentación	Existe una guía para repetir la demostración desde el inicio	Manual de ejecución

37 TER.4. Criterios cuantitativos

Además de comprobar las funciones, el MVP deberá superar los siguientes umbrales iniciales.

Indicador	Umbral propuesto	Método de comprobación
Objetos de prueba creados	Al menos 1	Inspección del registro
Componentes diferenciados	Al menos 3	Inspección del modelo
Variantes independientes	Al menos 2	Prueba de versionado
Experimentos completos	Al menos 1	Inspección de metadatos
Simulaciones completadas	Al menos 2 ejecuciones de prueba	Logs de ejecución
Variables cuantitativas comparadas	Al menos 1	Informe de comparación
Parámetros recuperables	100 % de los parámetros declarados obligatorios para la prueba	Verificación automática
Requisitos MUST del MVP superados	100 %	Matriz de trazabilidad
Resultados con procedencia recuperable	100 % de los resultados aceptados en la demostración	Prueba de trazabilidad
Errores críticos abiertos	0	Registro de incidencias

Estos umbrales son objetivos iniciales de aceptación propuestos para UEDTE; deberán ajustarse después de definir la arquitectura, el entorno de ejecución y el modelo de prueba.

37 TER.5. Reproducibilidad: distinción necesaria

El criterio AC-011 deberá distinguir dos situaciones:

A. Repetición determinista. Cuando el modelo y el motor permitan una ejecución determinista, las entradas idénticas deberán producir resultados idénticos dentro de la tolerancia numérica declarada.

B. Repetición no determinista o sensible al entorno. Cuando intervengan aleatoriedad, paralelismo, diferencias de hardware u otros factores, el sistema deberá registrar esas condiciones y comprobar la consistencia dentro de tolerancias justificadas.

No se exigirá igualdad exacta de resultados en todos los motores de simulación. Se exigirá que las diferencias puedan explicarse y evaluarse.

37 TER.6. Prueba integral de aceptación

Se realizará una prueba de extremo a extremo denominada UEDTE-MVP-TEST-001.

Crear un objeto digital.
Incorporar al menos tres componentes.
Definir sus propiedades y relaciones.
Guardar un Snapshot inicial.
Registrar un experimento y su hipótesis.
Crear dos variantes independientes.
Modificar un parámetro en una de ellas.
Ejecutar la simulación de referencia.
Ejecutar la simulación de la variante.
Comparar los resultados.
Repetir una ejecución.
Recuperar la configuración completa de cada resultado.
Comprobar que el objeto original permanece intacto.
Exportar el registro del experimento.
Verificar que la simulación no ha sido etiquetada indebidamente como validación física.

La prueba deberá documentarse con capturas de pantalla o registros, datos de entrada, resultados, versiones y una lista de incidencias.

37 TER.7. Clasificación de incidencias

Nivel	Definición	Efecto sobre la aceptación
P0 — Crítica	Pérdida del original, corrupción de datos o vulneración grave de permisos	Rechazo
P1 — Alta	Fallo de una función MUST o imposibilidad de reproducir la prueba esencial	Rechazo
P2 — Media	Función secundaria defectuosa con alternativa documentada	Aceptación condicionada, si no afecta a un MUST
P3 — Baja	Defecto visual o mejora no esencial	Puede aceptarse con registro pendiente

Ninguna incidencia P0 o P1 podrá permanecer abierta al declarar aceptado el MVP.

37 TER.8. Condiciones de aceptación final

El MVP se considerará ACEPTADO cuando se cumplan simultáneamente estas condiciones:

Todos los criterios funcionales AC-001 a AC-016 han sido comprobados o se ha justificado formalmente cualquier criterio no aplicable.
Todos los requisitos clasificados como MUST están superados.
Se ha completado satisfactoriamente la prueba UEDTE-MVP-TEST-001.
No existen incidencias P0 ni P1 abiertas.
Se conservan las evidencias de ejecución.
La documentación permite repetir la demostración.
Se mantienen la integridad del original, la trazabilidad y la distinción entre simulación y validación física.

Si alguna condición esencial no se cumple, el resultado será NO ACEPTADO o ACEPTACIÓN CONDICIONADA, según la naturaleza de las incidencias y siempre que no se incumpla un requisito MUST.

37 TER.9. Exclusiones de la aceptación

La aceptación del MVP no demostrará por sí misma:

Que UEDTE mejora cualquier proceso de diseño.
Que las simulaciones representan fielmente cualquier sistema real.
Que el sistema puede fusionar automáticamente cualquier gemelo digital.
Que la IA produce diseños técnicamente correctos.
Que el sistema sustituye los ensayos físicos.
Que el modelo naval es apto para operar en el mar.
Que el software cumple requisitos de certificación industrial.

Estas afirmaciones exigirán ensayos específicos posteriores.

37 TER.10. Acta de aceptación

La entrega del MVP deberá incluir un acta con los siguientes campos:

Campo	Contenido
Identificador	UEDTE-MVP-ACCEPTANCE-001
Versión evaluada	Versión exacta del prototipo
Fecha	Fecha de la evaluación
Entorno	Hardware, sistema operativo y dependencias
Responsable de la prueba	Persona o equipo evaluador
Casos ejecutados	Identificadores de las pruebas
Resultado por criterio	Aprobado, rechazado o no aplicable
Incidencias abiertas	Listado y clasificación
Evidencias	Logs, datasets e informes
Decisión	Aceptado, condicionado o rechazado
Aprobación	Responsable autorizado

37 TER.11. Regla de aceptación

Un MVP no se acepta porque funcione durante una demostración; se acepta porque sus funciones esenciales han sido verificadas, sus resultados quedan registrados y otra persona puede repetir la prueba.

Este criterio convierte UEDTE en algo más que una visualización de gemelos digitales: lo convierte en una infraestructura experimental susceptible de evaluación técnica.

La siguiente etapa será desarrollar el prototipo, ejecutar los casos de prueba y publicar los resultados, incluidos los fallos y las limitaciones detectadas.

38. Matriz ampliada de requisitos de simulación

Para los primeros demostradores se recomienda una matriz específica de simulación.

ID	Requisito	Verificación
SIM-001	Seleccionar objeto y versión antes de ejecutar	D
SIM-002	Registrar motor y versión	I
SIM-003	Registrar parámetros	I
SIM-004	Registrar condiciones iniciales	I
SIM-005	Registrar condiciones de contorno	I
SIM-006	Registrar configuración del solver	I
SIM-007	Registrar recursos computacionales relevantes	I
SIM-008	Asociar resultados al experimento	D
SIM-009	Permitir simulación multifactorial	E
SIM-010	Permitir diferentes niveles de fidelidad	D/E
SIM-011	Comparar resultados de diferentes variantes	D/E
SIM-012	Identificar una ejecución concreta	A/D
SIM-013	Detectar configuración incompleta	D
SIM-014	Impedir presentar una simulación como validación física	E
SIM-015	Conservar el registro de una ejecución fallida	E

39. Matriz ampliada de experimentación

ID	Requisito	Criterio de aceptación	Método
EXP-001	Crear hipótesis	Campo obligatorio disponible	D
EXP-002	Definir objetivo	Objetivo registrado	D
EXP-003	Definir estado inicial	Snapshot asociado	D
EXP-004	Registrar modificación	Cambio identificable	D
EXP-005	Registrar condiciones	Condiciones recuperables	I
EXP-006	Ejecutar simulación	Resultado vinculado	E
EXP-007	Registrar análisis	Informe asociado	I
EXP-008	Clasificar resultado	VALIDATED/REJECTED/INCONCLUSIVE, etc.	D
EXP-009	Conservar experimento	No se elimina al crear una variante	D
EXP-010	Reproducir experimento	Configuración recuperable	E

40. Matriz de interoperabilidad y fusión

ID	Requisito	Criterio
INT-001	Identificar unidades	Todas las magnitudes relevantes tienen unidad
INT-002	Identificar interfaces	Interfaces documentadas
INT-003	Comprobar geometría	Compatibilidad geométrica evaluada
INT-004	Comprobar energía	Requisitos energéticos comparados
INT-005	Comprobar señales	Entradas y salidas compatibles
INT-006	Comprobar límites	Restricciones comparadas
INT-007	Generar informe	Resultado de compatibilidad registrado
INT-008	Crear sistema fusionado	Modelo resultante identificable
INT-009	Mantener trazabilidad	Componentes fuente recuperables
INT-010	Preservar objetos originales	Las fuentes permanecen intactas

41. Matriz de validación

La validación deberá tener distintos niveles.

Nivel	Descripción	Evidencia
V0	Concepto	Descripción
V1	Modelo digital	Modelo reproducible
V2	Simulación	Resultado computacional
V3	Simulación reproducible	Reejecución
V4	Prototipo	Objeto físico
V5	Ensayo físico	Datos medidos
V6	Validación independiente	Evidencia independiente

Estos niveles son una escala propuesta para UEDTE, no una norma internacional.

La transición entre niveles deberá quedar documentada.

42. Matriz de trazabilidad

La relación entre requisitos, implementación y pruebas deberá poder representarse:

REQUISITO

↓

FUNCIÓN

↓

COMPONENTE SOFTWARE

↓

CASO DE PRUEBA

↓

RESULTADO

↓

EVIDENCIA

Ejemplo:

VR-013

↓

Motor de simulación

↓

SIM-ENGINE-TEST-001

↓

Ejecución

↓

Resultado

↓

Log + Dataset

Esto permitirá construir posteriormente una Requirements Traceability Matrix — RTM completa.

43. Casos de prueba iniciales

Se proponen como mínimo:

TEST-001 — Creación de objeto

Crear un objeto UEDTE y comprobar su identidad.

TEST-002 — Snapshot

Capturar un estado y comprobar su reproducción.

TEST-003 — Cirugía digital

Modificar un componente y demostrar que el original permanece intacto.

TEST-004 — Fork

Crear dos variantes independientes.

TEST-005 — Simulación

Ejecutar una variante y recuperar sus resultados.

TEST-006 — Reproducibilidad

Repetir una simulación con idéntica configuración.

TEST-007 — Comparación

Comparar original y variante.

TEST-008 — Fusión

Combinar dos objetos compatibles.

TEST-009 — Incompatibilidad

Introducir deliberadamente una incompatibilidad y comprobar su detección.

TEST-010 — Proveniencia

Reconstruir el origen de un componente.

TEST-011 — IA

Generar una propuesta y comprobar que queda marcada como AI_PROPOSED.

TEST-012 — Validación

Comprobar que un resultado simulado no adquiere automáticamente estado de validación física.

44. Requisitos críticos

No todos los requisitos tienen la misma importancia.

Se propone la siguiente clasificación:

Prioridad	Significado
MUST	imprescindible para el MVP
SHOULD	necesario para una versión operativa
COULD	mejora deseable
FUTURE	evolución posterior

Los requisitos VR-003, VR-007, VR-009, VR-011, VR-013, VR-018, VR-020, VR-022, VR-024, VR-026 y VR-040 deberían considerarse inicialmente MUST.

45. Criterio de aceptación del MVP

El MVP de UEDTE podrá considerarse funcional cuando pueda demostrar de extremo a extremo:

CREAR OBJETO

↓

CAPTURAR SNAPSHOT

↓

MODIFICAR COMPONENTE

↓

CREAR FORK

↓

EJECUTAR SIMULACIÓN

↓

REGISTRAR RESULTADO

↓

COMPARAR

↓

REPRODUCIR

↓

RECUPERAR TRAZABILIDAD

La demostración deberá quedar acompañada de evidencia verificable.

46. Métricas del sistema

UEDTE deberá medir su propio rendimiento.

Indicadores iniciales:

tiempo de creación de variante;
número de variantes exploradas;
tiempo de simulación;
reutilización de componentes;
número de fusiones;
errores detectados;
tiempo hasta solución;
número de prototipos físicos;
correlación simulación/ensayo;
diversidad de soluciones;
participación;
reproducibilidad.

47. Hipótesis científica de UEDTE

La hipótesis principal se formula:

Una infraestructura interoperable de gemelos digitales modificables, reutilizables y experimentalmente trazables puede ampliar el espacio de soluciones exploradas y reducir determinados costes temporales y materiales asociados a la experimentación tecnológica.

Esta hipótesis contiene varias variables susceptibles de investigación.

Variable independiente

Uso de UEDTE.

Variables dependientes

tiempo;
número de soluciones;
coste;
diversidad;
calidad;
errores;
prototipos necesarios.

48. Experimento fundacional

UEDTE-EXP-001

Comparar dos grupos que resuelvan el mismo problema tecnológico.

Grupo A

Metodología convencional.

Grupo B

Metodología UEDTE.

Comparar:

número de soluciones;
tiempo;
coste;
diversidad;
calidad;
número de errores;
número de variantes;
resultado físico.

No deberá suponerse previamente qué grupo será superior.

49. Criterio de éxito

UEDTE no deberá considerarse validado porque la plataforma funcione técnicamente.

Será necesario demostrar experimentalmente que proporciona ventajas medibles.

Podrían aparecer tres resultados:

Resultado A

Ventaja significativa.

Resultado B

Ventaja limitada o específica.

Resultado C

No se observa ventaja.

Los tres resultados serán científicamente útiles.

50. MVP

El primer Minimum Viable Product podría limitarse a:

Objeto

Un motor naval simplificado.

Funciones

visualización;
descomposición;
modificación;
snapshot;
simulación;
comparación;
fork;
historial.

Posteriormente:

MVP → UEDTE-OCEAN 001 → Fusión → IA → Validación física.

51. Primer demostrador aplicado

El primer demostrador especializado será:

UEDTE-OCEAN 001

Un entorno digital experimental para sistemas submarinos.

Permitirá estudiar:

estructura;
propulsión;
energía;
navegación;
sensores;
manipulación;
comunicaciones;
entorno oceánico.

Su objetivo no será solamente representar un vehículo submarino, sino comprobar la capacidad de UEDTE para evolucionarlo digitalmente.

52. Ecosistema futuro

La arquitectura podrá extenderse a:

aeronaves;
buques;
robots;
sistemas espaciales;
vehículos terrestres;
instrumentos científicos;
sistemas energéticos;
medicina;
patrimonio industrial;
tecnologías históricas;
conceptos de ciencia ficción.

La plataforma no deberá estar limitada a una industria concreta.

53. Hoja de ruta

v0.1

Concepto y arquitectura.

v0.2

Especificación técnica preliminar.

Estado actual propuesto.

v0.3

Prototipo funcional.

v0.4

Primer entorno experimental.

v0.5

UEDTE-OCEAN 001.

v0.6

Fusión de gemelos.

v0.7

IA experimental.

v0.8

Validación física.

v0.9

Interoperabilidad ampliada.

v1.0

Plataforma experimental estable.

54. Relación entre documentos UEDTE

DOCUMENTO 1

CUATRO OJOS — UEDTE

Visión conceptual

│

▼

DOCUMENTO 2

ATLAS VISUAL

Arquitectura gráfica

│

▼

DOCUMENTO 3

UEDTE-SRS v0.2

Especificación técnica

│

├───────────────┐

▼ ▼

DOCUMENTO 4 DOCUMENTO 5

UEDTE-OCEAN 001 SF-TECH ATLAS

Demostrador Hipótesis

│ │

└───────┬───────┘

▼

DOCUMENTO 6

UEDTE-PROTOCOL

Protocolo experimental

55. Limitaciones actuales

Esta especificación no constituye todavía una implementación completa.

Entre las cuestiones pendientes figuran:

elección definitiva de estándares;
motores de simulación;
arquitectura de almacenamiento;
interoperabilidad CAD/CAE;
representación semántica;
gestión de grandes datasets;
simulación multifísica;
seguridad;
derechos de propiedad intelectual;
gobernanza;
escalabilidad computacional;
validación experimental.

Por tanto, UEDTE-SRS v0.2 debe considerarse una especificación preliminar de investigación y desarrollo, no un estándar industrial consolidado.

56. Conclusión

UEDTE propone transformar el concepto tradicional de gemelo digital.

En lugar de:

"Aquí está la copia digital del objeto."

plantea:

"Aquí está el objeto digital. Puedes detenerlo, abrirlo, modificarlo, experimentar con él, compararlo, combinarlo con otros objetos y estudiar cómo evoluciona."

La diferencia es conceptual pero también arquitectónica.

UEDTE intenta convertir el gemelo digital en una:

INFRAESTRUCTURA EXPERIMENTAL DE CONOCIMIENTO TECNOLÓGICO

Su unidad básica deja de ser solamente el objeto.

Pasa a ser:

OBJETO + ESTADO + MODIFICACIÓN + EXPERIMENTO + SIMULACIÓN + RESULTADO + VALIDACIÓN.

Y su unidad de evolución deja de ser únicamente la nueva versión de un producto.

Pasa a ser:

UNA VARIANTE REPRODUCIBLE DEL CONOCIMIENTO.

57. Principio final

CUATRO OJOS VEN MÁS QUE DOS

Pero el objetivo último de UEDTE no es simplemente disponer de más ojos.

Es conseguir que cada ojo pueda:

ver → comprender → modificar → experimentar → aprender → compartir.

Y que el conocimiento obtenido por uno pueda convertirse en el punto de partida del siguiente.

De esta manera:

cada experimento alimenta al siguiente,

cada componente puede convertirse en una pieza reutilizable,

cada fracaso puede convertirse en conocimiento,

cada gemelo puede fusionarse con otro,

cada generación puede comenzar desde donde terminó la anterior.

ANEXO A — Estructura mínima de datos

{

"object_id": "UEDTE-OBJECT-0001",

"name": "Objeto experimental",

"type": "SYSTEM",

"version": "0.1",

"status": "MODEL",

"components": [],

"experiments": [

{

"experiment_id": "EXP-0001",

"object_version": "0.1",

"title": "Experimento inicial",

"hypothesis": "Hipótesis experimental",

"status": "PLANNED",

"initial_state": {},

"modification": {},

"conditions": {},

"simulations": [

{

"simulation_id": "SIM-0001",

"simulation_type": [

"MECHANICAL",

"THERMAL"

"engine": "UEDTE-Solver",

"engine_version": "0.1",

"model_configuration": {},

"initial_conditions": {},

"boundary_conditions": {},

"parameters": {},

"results": []

}

"results": []

}

"provenance": {

"source_type": "ORIGINAL",

"source_id": "UEDTE",

"author": "Aprocean"

}

Este esquema es conceptual y preliminar. No representa todavía un estándar oficial ni presupone una implementación concreta.

ANEXO B — Principio operativo UEDTE

DETENER

Capturar el estado.

ABRIR

Acceder a la estructura interna.

MODIFICAR

Intervenir sobre un componente.

SIMULAR

Ejecutar el modelo.

COMPARAR

Medir diferencias.

FUSIONAR

Combinar soluciones.

EXPERIMENTAR

Formular y comprobar hipótesis.

VALIDAR

Contrastar con evidencia.

EVOLUCIONAR

Conservar y reutilizar el conocimiento obtenido.

ANEXO C — Matriz resumida de verificación del MVP

Dominio	Requisitos MUST	Prueba principal	Evidencia
Objeto	VR-001 a VR-005	Crear/modificar objeto	Registro + historial
Snapshot	VR-007/008	Congelar y recuperar estado	Snapshot
Modificación	VR-009/010	Crear Fork	Grafo de versiones
Experimento	VR-011/012	Registrar hipótesis	EXP record
Simulación	VR-013–018	Ejecutar simulación	Log + resultados
Comparación	VR-020	Original vs variante	Informe
Reproducibilidad	VR-024/025	Reejecución	Fingerprint
Fusión	VR-026–028	Integrar dos objetos	Gemelo fusionado
Proveniencia	VR-029/030	Recuperar origen	Provenance
Seguridad	VR-032	Acceso autorizado/no autorizado	Test de permisos
IA	VR-035/036	Propuesta IA + aprobación humana	Audit log
Trazabilidad	VR-040	Resultado → experimento → versión	RTM

Estado del documento

UEDTE-SRS v0.2

Tipo: Especificación técnica preliminar.

Estado: Propuesta de investigación y desarrollo.

Nivel: Documento técnico preparatorio para prototipo y demostración.

Próxima evolución prevista: UEDTE-SRS v0.3 + UEDTE-PROTOCOL v0.1.

Principio de verificación: Todo requisito crítico deberá poder demostrarse mediante inspección, análisis, demostración o ensayo, y deberá existir evidencia recuperable de su resultado.

Aprocean — 2026

miércoles, 4 de noviembre de 2026

37 BIS. TABLA DE CONTROL DE ALCANCE

37 TER. CRITERIOS DE ACEPTACIÓN DEL MVP

Datos personales