Capítulo 5 — Comunicación en ingeniería
Mapa de la lección
Lección 05 publicada. Mapa, ejemplo, EX010.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["5.1 Escribir para decidir"]
N2["5.2 Requisitos que pueden verificarse"]
N3["5.3 Números, incertidumbre y figuras"]
N4["5.4 Comunicar el riesgo a distintos lectores"]
N5["5.5 Información sensible"]
N6["5.7 Actividad práctica"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX010"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["5.1 Escribir para decidir"]
N2["5.2 Requisitos que pueden verificarse"]
N3["5.3 Números, incertidumbre y figuras"]
N4["5.4 Comunicar el riesgo a distintos lectores"]
N5["5.5 Información sensible"]
N6["5.7 Actividad práctica"]
N7["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]
[Resultados de aprendizaje y conexión]
|
v
[5.1 Escribir para decidir]
|
v
[5.2 Requisitos que pueden verificarse]
|
v
[5.3 Números, incertidumbre y figuras]
|
v
[5.4 Comunicar el riesgo a distintos lectores]
|
v
[5.5 Información sensible]
|
v
[5.7 Actividad práctica]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX010]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) escribir un requisito que pueda verificarse; (2) producir una nota de diseño de una página, un registro de decisión y un informe de pruebas que otro ingeniero pueda comprobar; (3) presentar el riesgo y la incertidumbre a operadores, directivos y reguladores sin exagerarlos ni ocultarlos; y (4) tratar adecuadamente en los documentos los detalles sensibles de la infraestructura. Se apoya en los capítulos 1–4, cuyos números ahora tiene que comunicar, y prepara los talleres de diseño (capítulos 25 y 35).
5.1 Escribir para decidir
Los documentos de ingeniería existen para que alguien pueda tomar o comprobar una decisión. Empiece por la decisión y su fundamento; ponga las derivaciones después. Una buena nota de diseño responde, en este orden: qué se decide, qué opciones se consideraron, la recomendación, la evidencia y los supuestos en que se basa, qué cambiaría la recomendación y quién debe aprobarla. Los registros de decisiones de arquitectura (notas breves, fechadas y numeradas que registran una decisión, su contexto y sus consecuencias) mantienen visibles las razones de un diseño años después, cuando el equipo original ya se ha ido.
5.2 Requisitos que pueden verificarse
Un requisito es un enunciado que el sistema debe cumplir, redactado de modo que una prueba, un análisis, una inspección o una demostración puedan mostrar si lo cumple. El NASA Systems Engineering Handbook recomienda requisitos necesarios, inequívocos, verificables, factibles y trazables. Compare «La telemetría deberá ser segura» (no verificable) con «Cada mensaje de telemetría de una RTU de campo al centro de control deberá llevar un código de autenticación de mensajes sobre su contenido y un contador monótono; el receptor deberá rechazar los mensajes que fallen cualquiera de las dos comprobaciones y generar una alarma en menos de 60 s» (verificable mediante prueba). Use «deberá» para los requisitos, mantenga un requisito por frase y dé a cada uno un identificador.
5.3 Números, incertidumbre y figuras
Informe los números con unidades, el método que los produjo y su incertidumbre o sus supuestos: «autonomía de 14,6 h (modelo de demanda integrada, inicio a las 06:00, nivel inicial del 85 %; 17,3 h si se supone la demanda media)». Prefiera tablas para los valores exactos, gráficos de líneas para las series temporales y nunca un gráfico sin ejes rotulados y unidades. Evite la falsa precisión: una autonomía de batería calculada con cargas estimadas es «unas 19 h», no «18,83 h». Haga que las figuras se lean en escala de grises y por personas con deficiencias en la visión del color.
En LRWA, la cifra de autonomía del expediente del TMRP lleva su hora de inicio y su nivel inicial, para que nadie la cite en otro escenario.
5.4 Comunicar el riesgo a distintos lectores
Los operadores necesitan saber qué hacer y cuándo; los directivos, la consecuencia, el costo y las opciones; los reguladores, evidencia de cumplimiento y de razonamiento. El mismo hallazgo («las consignas remotas se aceptan sin autenticación») se convierte, para un operador, en «hasta que se corrija, confirme por teléfono con la sala de control cualquier cambio de consigna inesperado»; para un directivo, en «una orden falsificada podría arrancar o detener bombas; costo de la corrección 120 k, tres meses»; para un regulador, en una brecha de control mapeada con un plan fechado. Ninguna de estas versiones puede contradecir a otra.
5.5 Información sensible
Los documentos de infraestructura contienen a menudo direcciones de red, modelos de dispositivos, vulnerabilidades y límites de capacidad. Marque los documentos según su sensibilidad, compártalos según la necesidad de saber y elimine detalles de las versiones destinadas a públicos amplios. Los informes públicos y los trabajos de los estudiantes deben describir los sistemas al nivel de la guía de seguridad de TO del NIST (SP 800-82 Rev. 3), es decir, patrones de arquitectura, y no las debilidades concretas de un operador identificado.
En este libro todas las cifras de LRWA son sintéticas, pero practique el hábito de todos modos: marque las notas de diseño para uso interno, mantenga las direcciones de red fuera de las diapositivas y produzca una versión reducida para públicos ajenos al equipo de ingeniería.
5.6 Ejemplo resuelto: un registro de decisión del TMRP (sintético)
ADR-007 — Autenticar la telemetría de campo en la capa de aplicación. Fecha: 2026-03-04. Estado: aceptada. Contexto: el tráfico RTU–SCADA atraviesa una red LTE privada operada por un tercero; el cifrado LTE termina en el operador. Opciones: (a) confiar en el cifrado del operador; (b) túneles IPsec por RTU; (c) HMAC en la capa de aplicación con contadores. Decisión: (c), con (b) donde las RTU lo admitan. Consecuencias: +22 bytes por mensaje (Lab 8); se requiere gestión de claves (capítulo 19); las RTU heredadas de PS1 y PS2 necesitan una pasarela. Revisar si: cambia el contrato con el operador o el firmware de las RTU incorpora protocolos seguros nativos.
5.7 Actividad práctica
Reescriba en forma verificable tres requisitos vagos de un encargo sintético («el sistema deberá ser resiliente», «las alarmas deberán ser oportunas», «los registros deberán estar protegidos»), cada uno con un método de verificación. Para cada reescritura, nombre la evidencia que mostraría que el requisito se cumple: una prueba con un criterio de aprobación, un análisis con supuestos enunciados, una inspección o una demostración. Use el contexto de LRWA cuando ayude. Un sistema resiliente podría convertirse en una autonomía enunciada durante un corte de la red eléctrica, las alarmas oportunas en una meta de latencia para una proporción enunciada de eventos, y los registros protegidos en una protección de integridad con anclas guardadas fuera de la zona de control, como exige más adelante R8. Mantenga cada enunciado en un solo requisito.
5.8 Errores comunes y límites
- Enterrar la recomendación; escribir una cronología en lugar de un argumento.
- Requisitos que contienen «y/o», «según corresponda», «fácil de usar», «seguro».
- Números sin unidades, método ni incertidumbre.
- Historias distintas para públicos distintos.
- Compartir en exceso detalles sensibles, o compartir tan poco que los revisores no pueden comprobar el trabajo.
La mayoría de estos errores aparece primero en los conjuntos de requisitos. Un requisito que contiene «seguro» no puede probarse, así que o se abandona discretamente o se da por cumplido sin evidencia. Las historias distintas para públicos distintos son igual de dañinas: si la nota al operador, el resumen al directivo y la declaración al regulador del EX010 discrepan sobre la batería de PS4, quien lea dos de ellas no confiará en ninguna.
Ejercicios — capítulo 5
EX009 — Hágalo verificable. Objetivo: escribir requisitos que puedan probarse. Entradas: los tres requisitos vagos de §5.7. Pasos: reescriba cada uno como uno o más enunciados con «deberá», con un identificador y un método de verificación (prueba, análisis, inspección, demostración). Evidencia esperada: tabla. Rúbrica: 3 = cada uno medible, único y factible, con un método adecuado; 2 = uno sigue siendo vago; 1 = solo cambio de redacción; 0 = nada.
EX010 — Tres públicos. Objetivo: comunicar un hallazgo de forma coherente. Entradas: «La batería de telemetría de PS4 dura 6 h al fin de vida; el requisito R5 es de 24 h». Pasos: escriba una nota de dos frases para el operador, un resumen de 100 palabras con opciones para el directivo y una declaración de brecha dirigida al regulador. Evidencia esperada: tres textos. Rúbrica: 3 = hechos coherentes, acciones adecuadas a cada público, sin exceso de detalles sensibles; 2 = una incoherencia; 1 = el mismo texto tres veces; 0 = nada.
Síntesis del capítulo
Escriba para permitir decisiones: primero la recomendación, después la evidencia y los supuestos y, al final, las condiciones de cambio. Haga que cada requisito sea verificable y trazable; informe los números con unidades, métodos e incertidumbre; adapte el mensaje, no los hechos, al lector; y trate los detalles de la infraestructura como información sensible con un público definido.
Siga estudiando — capítulo 05 de 50
← Capítulo 04 · Índice de capítulos del curso · Capítulo 06 →
Continúe con la siguiente lección escrita.