Detalle de tanque
El detalle de tanque (/tanks/[id]) es la vista de un solo tanque: el punto donde el operador
deja de mirar la flota y se concentra en un activo concreto. El rediseño v1.7 (Variante A v2) reúne en
una sola pantalla el instrumento del tanque, los KPIs de inventario, la cadena de factores
custody, la procedencia de cada valor calculado, las alarmas activas y los dispositivos
asignados. Esta página documenta cómo interpretarlo —con énfasis en lo que hace de TankOS un sistema
de grado custody transfer: que los cálculos sean correctos y trazables.

Anatomía de la pantalla
La pantalla se compone de los siguientes bloques, de arriba abajo:
| Bloque | Qué muestra |
|---|---|
| Header + GradePill | Breadcrumb de jerarquía (Sitio › Patio › Tanque TAG), el badge de grado (GradePill) y los CTAs por rol (RBAC). |
| SummaryStrip | Tira de KPIs del tanque — nivel, NSV, masa, temperatura, densidad y ullage — con el toggle SI⇄Imperial. |
| TankInstrument | Instrumento del tanque en SVG (el nivel de llenado / fill) con los setpoints de alarma dibujados sobre la escala. |
| GroupedKpis | Inventario más los factores custody (CTL / CTSh / CPL / CSW) y los warnings MPMS asociados. |
| ProvenanceTable | La procedencia de cada uno de los ~18 campos del cálculo custody (de dónde salió cada valor). |
| RightRail | Alarmas activas del tanque + dispositivos asignados + cross-links. |
| Explorador de tendencia | El historiador de señales, a todo el ancho al fondo de la página — documentado en su propia página. |
El toggle SI⇄Imperial
La SummaryStrip trae un toggle SI⇄Imperial que cambia cómo se presentan los KPIs: el sistema métrico
(metros, m³, kg, °C) o el imperial (pies-pulgadas-octavos, barriles).
Este es un invariante del sistema: TankOS almacena todo en unidades SI (mm, m³, kg, °C, kg/m³,
kPa) y nunca persiste un valor convertido. El toggle Imperial es puramente de presentación — la
utilidad imperial-display convierte al vuelo (p. ej. el nivel se muestra como 37′ 8⅛″, el volumen en
bbl) sin tocar el dato guardado. Cambiar el toggle no altera ningún cálculo ni ningún registro: el
mismo tanque, leído por otro usuario en SI, muestra exactamente el mismo número en metros. Por eso un
ticket custody emitido es reproducible bit a bit, independientemente de qué unidades prefiera quien lo lee.
Factores custody y la cadena MPMS
Esta es la sección medular del detalle de tanque: la cadena de cálculo custody que convierte una
lectura de nivel en un inventario neto y una masa, aplicando los factores de corrección del estándar
MPMS. El bloque GroupedKpis muestra el resultado de cada etapa junto con los factores aplicados.
Los cuatro factores de corrección:
| Factor | Corrige por | Significado |
|---|---|---|
| CTSh | Dilatación térmica de la lámina del tanque (shell) | Ajusta la capacidad del tanque según su temperatura — el acero se dilata, el volumen del recipiente cambia. |
| CTL | Dilatación térmica del líquido | Corrige el volumen del producto de su temperatura observada a la temperatura de referencia. |
| CPL | Compresibilidad por presión del líquido | Ajusta el volumen por el efecto de la presión sobre productos compresibles. |
| CSW | Agua y sedimento en suspensión (sediment & water) | Descuenta la fracción de agua/sedimento para llegar al volumen de producto limpio (NSV). |
La cadena aplica estos factores etapa por etapa, en este orden:
- TOV (Total Observed Volume) — el volumen total leído del nivel contra la tabla de aforo.
- GOV (Gross Observed Volume) — se descuenta el agua libre del fondo y se aplica CTSh (corrección de la lámina).
- GSV (Gross Standard Volume) — se llevan los líquidos a condiciones estándar con CTL y CPL.
- NSV (Net Standard Volume) — se aplica CSW para descontar agua y sedimento: el producto neto.
- Masa — se multiplica el NSV por la densidad estándar para obtener la masa.
El NSV y la masa son las cifras sobre las que se factura una transferencia custody. Si un factor está mal o se aplica en el orden equivocado, el resultado es incorrecto y no es auditable. Por eso la cadena es explícita y cada etapa es inspeccionable: el operador puede ver no solo el resultado, sino cómo se llegó a él.
ProvenanceTable: la procedencia de cada valor
La ProvenanceTable (en es-VE) responde a una pregunta que ningún sistema de inventario ordinario
responde: ¿de dónde salió cada número? Para cada uno de los ~18 campos del cálculo custody, la tabla
declara su origen —si vino de un gauge (medición instrumental), de una muestra de laboratorio, de
la tabla de aforo, o de un valor por defecto— habilitando una auditoría forense completa del
cálculo.
Esta trazabilidad es el diferenciador del producto: ante una disputa de transferencia, no basta con
mostrar un NSV; hay que poder demostrar que ese NSV se construyó con la densidad de tal muestra de lab, la
temperatura de tal sensor, la capacidad de tal versión de la tabla de aforo. La ProvenanceTable deja esa
cadena de evidencia a la vista.
Screenshot pendiente del barrido diferido — ver 61-DEFERRED-SWEEP.md (tank-detail ProvenanceTable en detalle).
RightRail: alarmas y dispositivos del tanque
El RightRail (la columna derecha) concentra el contexto operativo del tanque:
- Alarmas activas de este tanque, renderizadas como filas densas con el acento semántico de 4 px a la izquierda (el mismo contrato visual del panel de alarmas global). La gestión completa —reconocer, silenciar, limpiar— se hace en el panel de alarmas.
- Dispositivos asignados al tanque (los radares y sensores que lo alimentan), con cross-links a su detalle.
Folds de estado
El detalle de tanque adapta su presentación según el estado del cálculo y del override. Hay tres folds:
| Fold | Condición | Qué cambia |
|---|---|---|
| A — pre-v1.2 | El tanque no tiene factores ni procedencia (factors y provenance nulos) — datos previos al motor v1.2. | GroupedKpis se muestra degradado, con un explainer en lugar de la tabla de factores (no hay tarjeta-error central como en el v3). |
| B — override activo | Hay un override manual persistente del radar. | Aparece el OverrideBanner ROJO (ver abajo). |
| C — stale / OBSOLETO | El cálculo está obsoleto (el feed se detuvo). | La SummaryStrip muestra un indicador de advertencia (warn) en lugar del pulse dot LIVE. |
Cuando hay un override activo, el detalle muestra un banner rojo multi-fila que dice
"OVERRIDE ACTIVO · RADAR ENMASCARADO": la lectura automática del radar está siendo sustituida por un
valor manual. El banner es deliberadamente prominente porque el operador debe saber que no está mirando
la telemetría en crudo. Limpiar el override requiere la autoridad manual:void (ver los modales abajo).
Screenshot pendiente del barrido diferido — ver 61-DEFERRED-SWEEP.md (tank-detail Fold A pre-v1.2 degradado,
Fold B override-banner, Fold C stale-calc OBSOLETO).
Acciones y modales por rol
Los CTAs del header son dependientes del rol y, de forma deliberada, son absent-not-disabled: un
usuario sin la autoridad correspondiente no ve el botón (no aparece atenuado). La visibilidad la decide
el servidor mediante un booleano por CTA, según las autoridades manual:submit, manual:approve,
manual:void y engineering:edit. Esto vale para los perfiles operator, engineer y supervisor.
Dos modales relevantes:
SolicitarCambioModal— para el operador que no tieneengineering:edit. En lugar de editar la configuración del tanque directamente, envía una solicitud por correo al ingeniero de sitio. Es el camino correcto para pedir un cambio sin saltarse la separación de funciones.Custody.OverrideReasonModal— para limpiar un override activo (Fold B). Pide la razón de la acción y solo está disponible con la autoridadmanual:void.
Screenshot pendiente del barrido diferido — ver 61-DEFERRED-SWEEP.md (tank-detail SolicitarCambioModal y
OverrideReasonModal).
Páginas relacionadas
- El historial de cada señal se explora en el explorador de tendencia, documentado aparte: vive al fondo de esta misma pantalla.
- Para volver a la vista de flota desde donde se accede a cada tanque, ver el dashboard operacional.
- Para configurar el tanque (geometría, setpoints, dispositivos, tablas de aforo), ver el editor de tanque.