Photo by Peyton Duncan on Unsplash
Fundamentos de lenguaje de marcado XML
XML (eXtensible Markup Language) es un lenguaje estructurado que organiza información mediante etiquetas jerárquicas, permitiendo representar formalmente redes, vehículos, rutas y parámetros de simulación.
Un simulador no “ve” intersecciones.
No “entiende” carriles.
No “interpreta” una red dibujada.
Solo procesa datos estructurados.
XML es una forma formal de decirle a la computadora:
qué es un nodo
qué es un enlace
qué atributos tiene
cómo se relaciona todo
Desde el punto de vista matemático, XML es una forma de representar un grafo con atributos en formato jerárquico.

Ejemplo:

<network> <node id="A"/> <node id="B"/> <edge from="A" to="B" length="200" speed="40"/> </network>
Aquí hay:
Elementos: <node>, <edge>
Atributos: id, from, to, length, speed
Estructura jerárquica
Es simplemente una representación formal del grafo ( G = (V,E) ).
La microsimulación moderna depende de esta estructuración.
SUMO, MATSim, Vissim (exportaciones), usan estructuras similares.

Estructuración de datos

XML organiza datos en forma de árbol jerárquico.
Un árbol es un tipo especial de grafo sin ciclos, con un nodo raíz.
En XML:
Todo parte de una etiqueta raíz.
Dentro hay elementos hijos.
Cada elemento puede tener subelementos.
Ejemplo:
<simulation> <network> ... </network> <vehicles> ... </vehicles> </simulation>
Si el grafo vial representa la infraestructura,
XML representa la descripción computacional de esa infraestructura.
Es decir:
Infraestructura física → Grafo matemático → Representación XML → Simulación.
En un archivo de MATSim o VISSIM por ejemplo, la red vial completa está en XML.
Cada nodo tiene coordenadas.
Cada enlace tiene capacidad y velocidad.
El simulador reconstruye el grafo leyendo el archivo.
Atributos y etiquetas
Una etiqueta define un elemento.
Un atributo define una propiedad del elemento.
Ejemplo:
<link id="L1" from="A" to="B" length="200" capacity="1800"/>
<link> = tipo de objeto
id = identificador
from y to = conectividad
length, capacity = atributos físicos
En simulación, cada atributo es una variable del modelo. Si falta un atributo crítico, el modelo puede quedar mal definido.

Declaraciones de atributos

Se puede imponer que ciertos atributos sean obligatorios.
Ejemplo:
Un enlace debe tener velocidad máxima.
Sin eso, el modelo de movimiento no puede operar.

Declaraciones de entidades

Permiten reutilizar estructuras o valores.
Ejemplo conceptual:
<!ENTITY velocidadUrbana "50">
Y luego usarla múltiples veces.
Ejercicio numérico (Planteamiento)
Imagina que se define el siguiente enlace en XML:
<link id="L1" from="A" to="B" length="500" speed="50"/>
1.
Conviertir la velocidad a m/s.
2.
Determinar el tiempo de recorrido teórico sin congestión.
3.
Si la capacidad es 1800 veh/h y el flujo real es 1500 veh/h, ¿está el enlace cerca de saturación?
Aquí, para efectos del ejercicio, interpretamos:
length="500" → longitud del enlace = $500\ \text{m}$
speed="50" → velocidad = $50\ \text{km/h}$

1. Convertir la velocidad a m/s

La conversión básica es:
1\ \text{km/h} = \frac{1000}{3600}\ \text{m/s} = 0.27778\ \text{m/s}
Entonces:
50\ \text{km/h} \times \frac{1000\ \text{m}}{3600\ \text{s}}
= \frac{50000}{3600}
= 13.8889\ \text{m/s}
Resultado:
\boxed{50\ \text{km/h} = 13.89\ \text{m/s}}

2. Determinar el tiempo de recorrido teórico sin congestión

La fórmula física básica es:
t=\frac{L}{v}
donde:
(t) = tiempo de recorrido
(L) = longitud
(v) = velocidad
t=\frac{500}{13.89}
t \approx 36.0\ \text{s}
Resultado:
\boxed{t \approx 36\ \text{s}}

3. Revisar si el enlace está cerca de saturación

Te dan:
Capacidad:
C = 1800\ \text{veh/h}
Flujo real:
q = 1500\ \text{veh/h}
La forma más simple de revisar qué tan cargado está el enlace es con la relación flujo-capacidad:
\frac{q}{C}
Sustituyendo:
\frac{1500}{1800}=0.8333
\frac{q}{C}\approx 0.83
Eso significa que el enlace está usando aproximadamente el 83.3% de su capacidad.
Resultado:
\boxed{\frac{q}{C}=0.83}

Interpretación

Un valor de:
\frac{q}{C}=0.83
no implica todavía saturación total, pero sí indica que el enlace ya está bastante cargado.
En términos prácticos:
si $q/C \ll 1$, el enlace opera holgadamente
si $q/C \to 1$, el enlace se acerca a saturación
si $q/C > 1$, la demanda excede la capacidad y se esperan colas crecientes
En este caso, el enlace está cerca de la saturación:
0.83 \approx 83%
Para microsimulación
Este cálculo es la base de todo el modelo.
En XML tú declaras atributos como:
longitud
velocidad
capacidad
conectividad
y el simulador reconstruye la red a partir de esos datos estructurados, tal como se hace en la construcción de redes y simulación en Vissim . Además, Vissim se define como una herramienta microscópica, basada en comportamiento y orientada a pasos de tiempo, que modela operación vehicular y multimodal .
XML no es sólo texto.
Es la forma en que el modelo computacional sabe cuánto mide un enlace, qué velocidad tiene y cómo se comportará el flujo sobre él.
Modelos avanzados
En modelos más avanzados se usan tiempos dependientes del estado del sistema, por ejemplo:
t = f(q, k, C, \text{control}, \text{interacciones})
Es decir, el tiempo ya no será fijo, sino función de:
flujo
densidad
capacidad
control semafórico
maniobras
comportamiento vehicular
Eso es exactamente la transición entre una representación estática en XML y una microsimulación dinámica.
Caso específico PTV VISSIM
PTV Vissim utiliza XML como formato base para almacenar y estructurar sus modelos.
Los archivos principales de Vissim (por ejemplo, .inpx) están basados en XML. Esto significa que toda la red, demanda, control semafórico, rutas, etc., se guardan como estructuras jerárquicas de datos (nodos, atributos, relaciones), típicas de XML.
Esto tiene varias implicaciones técnicas:
Permite interoperabilidad con otros sistemas.
Facilita la edición automática (scripts, Python, APIs).
Hace posible la inspección estructurada del modelo (aunque no está pensado para editarse manualmente directamente).
Por ejemplo, cuando en Vissim defines elementos como:
Vehicle Inputs (veh/hr)
Routing decisions con proporciones
Signal controllers y matrices de entreverde
todos esos elementos se almacenan internamente como nodos XML con atributos específicos, aunque el usuario los manipula gráficamente .
En escenarios avanzados, puedes generar redes completas de Vissim automáticamente desde datos (por ejemplo, OpenStreetMap) y modificar parámetros masivamente mediante scripts, lo que es clave para simulación a gran escala y calibración automatizada.
Análisis de un XML
Por el momento lo más útil no es usar todo el .inpx real, porque ese archivo trae cientos o miles de líneas de configuración base. Lo mejor es aislar un “núcleo mínimo” que represente exactamente los objetos que quieres explicar: red, links, conectores, entrada de vehículos, rutas y área de conflicto.
En Vissim, el flujo lógico básico también sigue esa secuencia: crear links y conectores, después entradas de vehículos, después decisiones de ruteo, y para una intersección no semaforizada usar áreas de conflicto.

Ejemplo:

Este es un ejemplo deliberadamente pequeño, para una vía primaria con un cruce secundario, sin semáforos y con pocos vehículos. No pretende sustituir un .inpx completo exportado por Vissim; su objetivo es que se entienda qué representa cada bloque del XML a partir del ejemplo donde aparecen justamente bloques como <network>, <vehicleInputs>, <vehicleRoutingDecisionsStatic> y <conflictAreas> .
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <network version="1403" vissimVersion="2026.00-03 [301061]"> <!-- 1) Parámetros generales de simulación --> <simulation simPeriod="600" simRes="10" randSeed="42" numRuns="1" simMode="MICRO" useAllCores="true"/> <!-- 2) Tipos de vehículo mínimos --> <vehicleTypes> <vehicleType name="Car" no="100" category="CAR"/> </vehicleTypes> <!-- 3) Composición vehicular: aquí se define qué tipo de vehículo entra a la red --> <vehicleCompositions> <vehicleComposition name="Solo autos" no="1"> <vehCompRelFlows> <vehicleCompositionRelativeFlow vehType="100" relFlow="1"/> </vehCompRelFlows> </vehicleComposition> </vehicleCompositions> <!-- 4) Links: representan tramos de vía. En este ejemplo: - Link 1 = vía primaria de oeste a este - Link 2 = continuación de la primaria después del cruce - Link 3 = vía secundaria de sur a norte - Link 4 = continuación de la secundaria después del cruce --> <links> <link no="1" name="Primaria_O-E_entrada" length="120.0" numLanes="1"/> <link no="2" name="Primaria_O-E_salida" length="120.0" numLanes="1"/> <link no="3" name="Secundaria_S-N_entrada" length="80.0" numLanes="1"/> <link no="4" name="Secundaria_S-N_salida" length="80.0" numLanes="1"/> </links> <!-- 5) Conectores: unen links y permiten que el vehículo siga su trayectoria. Aquí hacemos dos movimientos rectos: primaria: 1 -> 2 secundaria: 3 -> 4 --> <connectors> <connector no="1000" fromLink="1" toLink="2"/> <connector no="1001" fromLink="3" toLink="4"/> </connectors> <!-- 6) Entradas de vehículos: indican en qué link se generan vehículos y con qué volumen --> <vehicleInputs> <vehicleInput no="1" name="Entrada_Primaria" link="1"> <timeIntVehVols> <timeIntervalVehVolume timeInt="1 0" volume="300" vehComp="1" volType="STOCHASTIC" cont="false"/> </timeIntVehVols> </vehicleInput> <vehicleInput no="2" name="Entrada_Secundaria" link="3"> <timeIntVehVols> <timeIntervalVehVolume timeInt="1 0" volume="80" vehComp="1" volType="STOCHASTIC" cont="false"/> </timeIntVehVols> </vehicleInput> </vehicleInputs> <!-- 7) Decisiones de ruteo estático: dicen hacia dónde va el vehículo una vez que entra. Como sólo hay un movimiento posible por acceso, la ruta es única --> <vehicleRoutingDecisionsStatic> <vehicleRoutingDecisionStatic no="1" link="1" pos="10" routeChoiceMeth="STATIC" allVehTypes="true"> <vehRoutSta> <vehicleRouteStatic no="1" destLink="2" destPos="100" relFlow="1"> <linkSeq> <intObjectRef key="1000"/> </linkSeq> </vehicleRouteStatic> </vehRoutSta> </vehicleRoutingDecisionStatic> <vehicleRoutingDecisionStatic no="2" link="3" pos="10" routeChoiceMeth="STATIC" allVehTypes="true"> <vehRoutSta> <vehicleRouteStatic no="1" destLink="4" destPos="60" relFlow="1"> <linkSeq> <intObjectRef key="1001"/> </linkSeq> </vehicleRouteStatic> </vehRoutSta> </vehicleRoutingDecisionStatic> </vehicleRoutingDecisionsStatic> <!-- 8) Área de conflicto: define el punto donde se cruzan los movimientos. En este ejemplo la vía primaria tiene prioridad. --> <conflictAreas> <conflictArea no="1" linkA="1" linkB="3" conflTypMan="CROSSING" status="AHASRIGHTOFWAY" frontGapDef="0.5" rearGapDef="0.5" safDistFactDef="1.5" visibLinkA="80" visibLinkB="80" avoidBlockMajor="true" avoidBlockMinor="1"/> </conflictAreas> </network>

Leamos bloque por bloque.

La línea <?xml version="1.0" ... ?> solo declara que el archivo está escrito en XML. No modela tránsito; le dice al software cómo interpretar el archivo.
La etiqueta raíz <network ...> es el contenedor total del modelo. Todo lo que exista en la simulación debe quedar dentro de esa etiqueta. En tu ejemplo real también aparece así, con version="1403" y la versión de Vissim 2026 .
<simulation .../> define el experimento. simPeriod="600" significa que la corrida dura 600 s. simRes="10" implica 10 pasos por segundo. randSeed="42" fija la semilla aleatoria. Esto es importante porque, si la cambias, cambian los patrones estocásticos de llegada y comportamiento.
<vehicleTypes> y <vehicleType .../> definen qué clase física de vehículo existe. Aquí sólo dejé Car. En un modelo grande podrías agregar Bus, HGV, etc. En el archivo que compartiste aparecen muchos más tipos, pero para enseñar estructura XML basta con uno.
<vehicleCompositions> no genera autos todavía. Sólo dice qué mezcla vehicular estará disponible para las entradas. Si quieres que entren 100% autos, dejas una sola línea con relFlow="1".
<links> son los tramos de vía. Conceptualmente, un link es una arista del grafo de tránsito. Eso conecta perfecto con la parte del temario donde se pide teoría de grafos y su relación con la simulación, junto con XML y estructuración de datos . Cada link tiene un identificador no, un nombre, una longitud y un número de carriles.
<connectors> son enlaces entre links. Un link por sí mismo no garantiza continuidad del movimiento. El conector le dice a Vissim cómo se pasa de un tramo al siguiente. En Vissim, la construcción de red se basa precisamente en links y connectors como base geométrica de la red .
/<vehicleInputs> ya mete demanda al modelo. Cada <vehicleInput> se coloca sobre un link de entrada. Dentro aparece <timeIntervalVehVolume>, que define volumen, composición y tipo de llegada. volType="STOCHASTIC" significa que las llegadas no son uniformes exactas, sino estocásticas; esto coincide con el tutorial paso a paso, donde las entradas se definen como demanda y el volumen se expresa en veh/h .
<vehicleRoutingDecisionsStatic> resuelve la pregunta “una vez que el vehículo entra, ¿hacia dónde va?”. En este modelo mínimo hay una sola ruta posible por acceso, así que cada decisión tiene una sola vehicleRouteStatic. En tu archivo grande se ve la misma lógica, solo que con más rutas, más intObjectRef y varios relFlow para repartir proporciones .
<linkSeq> contiene la secuencia de objetos intermedios que el vehículo debe recorrer. Aquí usamos intObjectRef key="1000" o 1001, que hacen referencia a los conectores. Es, en esencia, la lista ordenada del camino.
<conflictAreas> es la pieza clave en una intersección sin semáforo. En Vissim, para intersecciones no semaforizadas, el control básico se resuelve con áreas de conflicto o reglas de prioridad; el quick start del manual lo marca explícitamente para nodos sin controlador semafórico . En el ejemplo puse status="AHASRIGHTOFWAY", que significa que el flujo A tiene prioridad sobre el flujo B. Si linkA="1" es la primaria y linkB="3" es la secundaria, entonces la secundaria cede.

No olvidar!!!

Desde primeros principios, eso significa esto: la geometría sola no basta. Una intersección necesita también lógica de interacción. En un semáforo, la lógica la define el controlador; en un cruce no semaforizado, la lógica la definen prioridad, gaps y conflicto. El bloque XML no “dibuja” solo la intersección; también codifica la regla operativa del cruce.
Para clase, yo te sugiero presentarlo en este orden:
primero network, luego simulation, luego vehicleType, luego vehicleComposition, después links, connectors, vehicleInputs, vehicleRoutingDecisionsStatic y al final conflictAreas. Ese orden sigue bastante bien la lógica pedagógica del curso y también la lógica de construcción de red en Vissim .
Una observación técnica importante: este XML es didáctico, no una exportación completa de Vissim. Un .inpx real suele incluir muchas tablas base adicionales: distribuciones de velocidad, clases vehiculares, defaults, coordenadas geométricas, atributos gráficos, etc., como se aprecia en tu archivo pegado, que arranca con bloques extensos de defaults y distribuciones antes de llegar a entradas y conflictos . Por eso este ejemplo sirve para explicar, pero no necesariamente para abrirse directamente en Vissim sin completar esos bloques.
Esta forma de enseñar XML no es sólo “ver código”. Cuando tus estudiantes entienden que un cruce puede representarse como estructura de datos, después pueden generar redes automáticamente, modificar demanda con scripts, hacer experimentos paramétricos y conectar Vissim con Python o con flujos de calibración basados en datos. Ese salto es exactamente el que vuelve útil la microsimulación en la era de automatización y análisis masivo.