Saltar al contenido principal

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.

Detalle de tanque en estado LIVE

Anatomía de la pantalla

La pantalla se compone de los siguientes bloques, de arriba abajo:

BloqueQué muestra
Header + GradePillBreadcrumb de jerarquía (Sitio › Patio › Tanque TAG), el badge de grado (GradePill) y los CTAs por rol (RBAC).
SummaryStripTira de KPIs del tanque — nivel, NSV, masa, temperatura, densidad y ullage — con el toggle SI⇄Imperial.
TankInstrumentInstrumento del tanque en SVG (el nivel de llenado / fill) con los setpoints de alarma dibujados sobre la escala.
GroupedKpisInventario más los factores custody (CTL / CTSh / CPL / CSW) y los warnings MPMS asociados.
ProvenanceTableLa procedencia de cada uno de los ~18 campos del cálculo custody (de dónde salió cada valor).
RightRailAlarmas activas del tanque + dispositivos asignados + cross-links.
Explorador de tendenciaEl 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).

El almacenamiento es SIEMPRE SI — la conversión ocurre solo al render

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:

FactorCorrige porSignificado
CTShDilatació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.
CTLDilatación térmica del líquidoCorrige el volumen del producto de su temperatura observada a la temperatura de referencia.
CPLCompresibilidad por presión del líquidoAjusta el volumen por el efecto de la presión sobre productos compresibles.
CSWAgua 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.
Por qué importa la cadena

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.

Captura pendiente

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:

FoldCondiciónQué cambia
A — pre-v1.2El 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 activoHay un override manual persistente del radar.Aparece el OverrideBanner ROJO (ver abajo).
C — stale / OBSOLETOEl cálculo está obsoleto (el feed se detuvo).La SummaryStrip muestra un indicador de advertencia (warn) en lugar del pulse dot LIVE.
Fold B — OVERRIDE ACTIVO · RADAR ENMASCARADO

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).

Captura pendiente

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 tiene engineering: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 autoridad manual:void.
Captura pendiente

Screenshot pendiente del barrido diferido — ver 61-DEFERRED-SWEEP.md (tank-detail SolicitarCambioModal y OverrideReasonModal).

Páginas relacionadas