Este documento constituye un documento de trabajo y una propuesta metodológica para la verificación y validación de modelos de simulación basada en el enfoque H-M-E. Su objetivo es describir un marco conceptual y técnico que permita analizar la coherencia interna, la adecuación estructural y el grado de validez de un modelo con respecto a los objetivos para los que ha sido construido.
El contenido de este documento no describe ni especifica ninguna aplicación software concreta, ni debe interpretarse como una validación de una herramienta de simulación particular. El marco presentado es intencionalmente independiente de la tecnología, de la implementación y del entorno de ejecución en el que los modelos puedan ser desarrollados o evaluados.
No obstante, se asume que las herramientas de simulación que adopten este enfoque —entre ellas el motor de simulación GPSS-Plus— incorporarán de forma progresiva las técnicas, métricas y mecanismos necesarios para permitir la aplicación práctica de esta metodología. Dicha adopción no implica exclusividad ni dependencia, y no condiciona la validez del marco a una implementación específica.
El modelo H-M-E debe entenderse, por tanto, como una propuesta abierta y sujeta a revisión, cuya aceptación y evolución dependen del contraste con distintos dominios de aplicación, de su uso en diferentes contextos y de la evaluación crítica por parte de la comunidad.
Este documento se publica con el claro propósito de ser opinable, criticable y debatible.
Los enfoques clásicos de verificación y validación (V&V) de modelos de simulación se apoyan, de forma explícita o implícita, en una concepción de caja negra: el modelo se interpreta como una función opaca que transforma un conjunto de entradas en salidas observables, y cuya corrección se evalúa comparando estadísticamente dichos resultados con datos históricos o con el juicio de expertos.
Esta concepción resulta adecuada cuando el modelo se aproxima a una función pura y determinista. Sin embargo, en el modelado de sistemas reales complejos, esta situación es la excepción y no la norma. Un modelo de simulación rara vez implementa relaciones del tipo f(a,b); en su lugar, describe procedimientos que interactúan con un estado dinámico, evolucionan en el tiempo y dependen del comportamiento concurrente de otras entidades. El mismo procedimiento, invocado con los mismos parámetros, lo normal es que produzca resultados distintos en función del instante, del contexto y de la historia previa del sistema.
En este escenario, el modelo deja de ser una “caja negra” funcional y pasa a ser un entorno vivo cuyo significado reside en su estructura interna y en sus dinámicas de ejecución. Validar únicamente las salidas equivale entonces a ignorar la semántica del proceso que las genera. Métodos como el Test de Turing de simulación o la comparación directa de KPIs pueden producir validaciones fortuitas: resultados aparentemente correctos obtenidos por razones equivocadas.
Dicho de otro modo, un modelo que habitualmente corre bajo unas circunstancias no puede ser validado estadísticamente cuando esas circunstancias cambian. Lo que está vivo no suele tener nunca dos circunstancias iguales.
La estadística es válida allí donde el fenómeno es estadísticamente repetible. Cuando el entorno cambia y esa repetibilidad se rompe, el modelo deja de ser una caja negra por naturaleza.
Los motores de simulación existen precisamente porque la realidad no es una función pura. Y, sin embargo, se les valida como si lo fueran.
1. Métodos Basados en Juicio de Expertos (El "Face Validation")
Es el más común.
2. Métodos Estadísticos y de Caja Negra (El estándar actual)
Se centran en los números, no en el porqué de los números.
3. Métodos Formales y de Verificación Lógica (Rigor Matemático)
Es el utilizado para chips electrónicos (Verificación Formal).
En todos ellos se adolece de ciertos sesgos:
Se intenta validar que el modelo mental es correcto antes de que exista el código. Es un ejercicio puramente teórico donde el experto "supone" que el diseño podrá funcionar y funcionará.
Se asume que si las distribuciones de entrada (inputs) se parecen a los datos históricos, el modelo es válido. No se cuestiona que si actualmente observamos una campana de gauss puede que sea un sesgo en la entrada y buscaremos esa respuesta e incluso la forcemos pudiendo ser en realidad una triangular.
4. PROPUESTA Método H-M-E (Consistencia Semántica asistida por IA o externo no experto)
Basado en la equivalencia de 3 modelos (H) Historia - (M) Modelo - (E) Ejecución.
Hasta ahora se partía que técnicamente la idea de una validación y verificación (V&V) era:
1. Definición del Alcance y Objetivos
¿Qué sistema estás modelando?
¿Cuáles son las métricas de rendimiento (Key Performance Indicators - KPIs) que el modelo debe predecir?
2. Verificación
¿El modelo hace lo que se supone que debe hacer?
2.a.- Inspección del Código/Lógica: Revisar si las transiciones de estado, la lógica de decisión, y la programación de eventos siguen el diseño conceptual.
2.b.- Pruebas de Trazabilidad: Seguir manualmente una entidad a través del sistema para asegurar que se comporta como se espera en cada paso.
2.c.- Prueba de Condiciones Límite: Asegurar que el modelo se comporta de manera razonable bajo condiciones extremas (ej. sin fallos, sin recursos, con saturación total).
3.- Validación
¿El modelo es una representación precisa de la realidad?
3.a.- Validación de Datos de Entrada ¿Las distribuciones estadísticas que definen las llegadas, los tiempos de procesamiento, o las fallas de la máquina (ej. Weibull, Exponencial) coinciden con los datos históricos del sistema real?
3.b.- Validación de Datos de Salida (Métricas) Comparación de KPIs: Ejecutar el modelo con datos de entrada históricos y comparar las métricas clave de salida (rendimiento, utilización) con las métricas históricas del sistema real.
En resumen
El enfoque V&V tradicional asume que el modelo es una “caja negra lógica”: solo puede verificarse mediante revisión manual del código y validarse mediante comparación estadística. Responden a las preguntas tipo “¿Con estos inputs pasados por la caja negra obtengo ciertos outputs?”.
Lo que nunca se valida es la coherencia semántica entre Historia ↔ Modelo ↔ Ejecución. En nuestro caso responde a la pregunta “¿Lo que hay en la caja negra es lo que queríamos crear?”
La llegada de los auditores de lenguaje natural (IA) permite romper esta estructura que contiene ciertos errores inherentes a las capacidades hasta ahora conocidas.
El método H-M-E no sustituye los procesos clásicos de validación empírica o estadística, los incluye. Su objetivo es actuar como una fase previa de pre-validación semántica, asegurando que el significado del modelo esté explícito, consensuado y verificable antes de cualquier contraste con la realidad. Y posteriormente acotar y optimizar el uso de los métodos clásicos, evitando su aplicación indiscriminada o errática.
Por ello, se formula un nuevo modelo de verificación y validación de modelos DES basado en 3 niveles de realidad:
NIVELES:
1. La Historia (H) (Modelo Narrativo)
Es el modelo mental explícito: el relato del que surge el modelo.
Ejemplo: “Vehículos que entran por A, pasan por B, pueden desviarse a C, consumen gasolina según su velocidad...”.
2. El Modelo (M) (Modelo Formal)
Es la implementación en código fuente:
- bloques (facility, queue, seize, release...),
- control de flujo (if, while, for...),
- estructuras de datos, eventos, etc.
- grafos y comentarios.
3. La Ejecución (E) (Modelo Empírico)
- 3.1. Código máquina / pasos de programa (E_pc)
La secuencia detallada de instrucciones ejecutadas (PC, eventos, cambios de estado).
- 3.2. Trazas de rutas (E_rutas)
Para cada entidad: el “camino” que ha seguido por el modelo/escenario, inequívoco. (1,17,18,20…)
- 3.3. Métricas obtenidas (E_kpi)
Los resultados estadísticos: medias, colas, tiempos en sistema, contadores, etc.
PIPELINE
Con estos 3 niveles se conforma el siguiente PIPELINE de proceso V&V formulado en 5 fases:
Fase 1: Ingeniería inversa: H ← M (Historia desde el Modelo)
- A partir del Modelo (M), la IA genera una nueva Historia inducida (H*): una interpretación narrativa-formal de lo que hace el modelo.
- El modelador compara H* con su Historia mental o documental original (H).
- El modelador puede y debe llegado el caso, compartir H* con aquellos terceros implicados.
- Llegado el caso se modifica M para volver a generar un nuevo H*. Puede ser un cambio en el código o un simple comentario en el mismo para afinar la interpretación.
Condición de cierre:
- Nada puede estar en la Historia que no esté en el Modelo.
- Nada puede estar en el Modelo que no aparezca en la Historia.
Denotamos por H* la historia inducida por el modelo M mediante auditoría IA. La condición de cierre es la Paridad Semántica:
H* === M
De esta fase sale:
- Una Historia consensuada H_c (lo que el modelo “significa”).
- Un conjunto explícito de checkpoints o KPIs a validar (K):
El estatus contractual de H_c no implica corrección ontológica del modelo respecto al sistema real, sino acuerdo explícito y verificable sobre el significado del modelo construido. Dicho de otra forma: responsable, modelador y auditor se han puesto de acuerdo en qué debe representar exactamente el modelo.
(ejemplo: cosas del tipo “número medio de vehículos que pasan por el tramo X”, y otros invariantes o patrones que se quieran fijar.)
Además, esos K deben estar o bien ya en el modelo calculados o bien ser generables de forma automática por el informe de ejecución.
**Nótese que la IA o auditor nunca sabrá de la existencia de una Historia previa (H), aunque esta se haya redactado formalmente como documento de requisitos, ni de la intención del modelador.
Su única fuente de información es el Modelo (M), a partir del cual genera una Historia inducida (H*).
Este proceso puede repetirse tantas veces como se modifique el Modelo.
Solo cuando una Historia inducida H* es aceptada explícitamente por los responsables del modelo, esta adquiere estatus contractual y pasa a denominarse Historia consensuada (H_c), reemplazando cualquier relato previo o intención implícita.
Un modelo correctamente diseñado debe poder ser interpretado por auditores de capacidad limitada sin pérdida de coherencia semántica. El proceso no valida ni juzga la IA, sino la claridad estructural y semántica del propio modelo.
El método H-M-E reduce significativamente el desarrollo y mantenimiento de documentos externos al modelo. El enfoque H-M-E elimina la redacción manual de requisitos y la sustituye por una historia inducida (H*) generada directamente a partir del modelo ejecutable.
La forma y el nivel de detalle de la Historia inducida H* no se imponen externamente. Emergen de la estructura, granularidad y claridad del propio modelo M. Por tanto, cualquier canonización de H* es consecuencia directa de la evolución de M, no de un formato narrativo previo.
En caso de usar varios auditores, se selecciona la historia inducida que hace menos suposiciones no observables sobre M. (Se prioriza la historia inducida que introduce el menor contenido semántico y no la que pueda estar rellenando huecos existentes)
En el contexto del método H-M-E, toda ambigüedad detectada durante la inducción de H* se interpreta como evidencia de ambigüedad semántica del modelo M, no como un fallo del proceso de V&V.
Fase 2: Definición de los KPIs
Con H_c ya contractual, se define O* — el conjunto de conceptos observables y relaciones temporales/estructurales bien definidas inducidas desde el modelo M.
Para ello, la IA responde a: “Dado el modelo explícito M, enumera qué conceptos observables existen y qué relaciones temporales o estructurales están bien definidas.”
A partir de O*, el responsable del sistema define Kc — el conjunto de KPIs contractuales, cumpliéndose que Kc ⊆ O*.
Todo KPI debe corresponder a un observable explícito del modelo.
En este enfoque, los comentarios, los nombres y la descomposición del modelo no mejoran la legibilidad humana, sino la capacidad de observación y validación. Un mejor modelo M induce un mayor espacio de observables O*.
De esta fase se obtiene Kc como el conjunto de KPIs consensuados o contractuales.
Kc no es una lista de métricas; es un contrato. Todo lo que quede fuera de Kc no puede usarse ni para validar ni para justificar el modelo. Si se requiere un determinado KPI y este no pertenece al espacio observable O*, será necesario modificar explícitamente el modelo M y reiniciar el proceso.
Fase 3: Ejecución del modelo: M→E (Generación de Datos)
Se ejecuta el Modelo (M) y se obtiene la Ejecución completa (E):
- E_pc: pasos de programa / eventos.
- E_rutas: trazas de ejecución de pc por entidad.
- E_kpi: check points, métricas y estadísticas.
Fase 4: Verificación estructural: H_c ↔ M ↔ E_rutas
La IA comprueba:
- Cada elemento de la Historia consensuada H_c debe tener:
- un reflejo claro en el Modelo (M), y
- una manifestación observable en las Rutas (E_rutas) de las entidades cuando corresponda.
Esto convierte la traza en una prueba de existencia:
“Si la Historia dice que los vehículos pueden tomar un desvío D, debe existir código que lo permita y rutas que lo muestren (al menos potencialmente o bajo ciertas condiciones)”.
No se valida si el desvío está correctamente tomado, porque eso ya quedó validado al generarse H* sino si realmente se toma el desvío.
Fase 5: Validación de check points: Kc ↔ E_kpi
La IA valida:
- Cada KPI o checkpoint de la Historia (K) se contrasta con las métricas de salida (E_kpi).
- Se decide si, bajo los experimentos realizados, el modelo es coherente con lo pactado en la Historia.
Los KPIs aparecen explícitamente en la Historia consensuada H_c.
La validación deja de ser una comparación “a ver si se parece más o menos” y pasa a ser un checklist de condiciones cuantitativas verificables.
La validación se transforma en una prueba de consistencia empírico-semántica:
K(Hc)⊆Ekpi
Ejemplo, si el número de vehículos que han tomado el desvío es coherente.
El método H-M-E no redefine los procedimientos clásicos de validación de resultados, sino que establece un marco semántico previo que restringe y legitima los KPIs susceptibles de ser utilizados. Los métodos clásicos siguen siendo los mismos lo que cambia es qué está permitido medir y por qué.
De existir un documento H ¿debe intervenir? Debe considerarse que puede llagar a incluir errores conceptuales o irresolubles.
¿Quién y cuándo define las métricas de los KPIs?
¿Quién define la amplitud del estudio (número de recorridos) que valida la virtual ejecución de todas las rutas?
Dado que M puede y debe contener comentarios y otros documentos, éstos pueden formar parte de la inducción de H* tanto de forma positiva como negativa. ¿Deben eliminarse, ponderarse mediante prompt?
¿La amplitud de O* será textual o un conjunto de parámetros?