Capítulo 16 — Ingeniería de sistemas
Mapa de la lección
Lección 16 publicada. Mapa, ejemplo, EX046.
flowchart TD
N0["Resultados de aprendizaje"]
N1["16.1 Requisitos comprobables"]
N2["16.2 Trazabilidad"]
N3["16.3 Interfaces"]
N4["Nota práctica"]
N5["16.1b Glosario y retirada"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX046"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["16.1 Requisitos comprobables"]
N2["16.2 Trazabilidad"]
N3["16.3 Interfaces"]
N4["Nota práctica"]
N5["16.1b Glosario y retirada"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX046"]
[Resultados de aprendizaje]
|
v
[16.1 Requisitos comprobables]
|
v
[16.2 Trazabilidad]
|
v
[16.3 Interfaces]
|
v
[Nota práctica]
|
v
[16.1b Glosario y retirada]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX046]
Resultados de aprendizaje
Usted podrá (1) redactar requisitos de seguridad de TO comprobables; (2) trazar un requisito hasta una regla de conducto y un laboratorio; (3) gestionar las interfaces entre el PLC, el SIS, el historiador y los monitores de seguridad.
16.1 Requisitos comprobables
«La planta debe ser segura» no es un requisito. «Ningún equipo fuera de L1/L2 deberá iniciar escrituras en los registros de retención del PLC-A; se verifica mediante análisis de alcanzabilidad y pruebas de la lista de permitidos con datos de prueba sintéticos» sí lo es. Cada requisito necesita un identificador, un enunciado con «deberá», un método de verificación y un responsable. Lena asigna a cada requisito del CNHP un identificador como R-12 y un responsable antes de que empiece cualquier trabajo de diseño. Un requisito sin método de verificación se devuelve a su autor. Lena también comprueba que cada uno pueda probarse con datos de prueba sintéticos, porque un requisito que solo puede verificarse escribiendo en un controlador en servicio no puede aceptarse.
16.2 Trazabilidad
Matriz: del requisito al elemento de diseño, al caso de prueba y a la evidencia de planta. Cuando un hallazgo muestra un conducto hacia el SIS, se sabe qué requisito y qué prueba fallaron. Sin la matriz, los análisis posteriores se convierten en búsqueda de culpables. Lena mantiene la matriz como un archivo en el repositorio del CNHP, actualizado en la misma solicitud de incorporación de cambios que la política que describe. Cada fila vincula un requisito como R-12 con la lista de aristas por zonas, la prueba de alcanzabilidad y el hash de la última exportación del cortafuegos. Cuando una prueba falla, la matriz muestra qué requisito está en riesgo y quién es su responsable.
16.3 Interfaces
El PLC-A publica valores de proceso; el SIS-B consume sensores dedicados; el historiador consume etiquetas del PLC; el monitor serie consume una derivación de solo escucha. Acuerde las listas de etiquetas y las frecuencias de actualización. Un cambio de interfaz es una solicitud de cambio, no una edición silenciosa durante un lote.
Caso sintético — Ashford Batch Plant. El requisito R-12, «SIS no alcanzable desde L4», se traza hasta la lista de aristas por zonas, lab_reach.py y el hash trimestral de la exportación del cortafuegos en el expediente.
Lena mantiene en el repositorio la lista de etiquetas de cada interfaz, con su responsable y su frecuencia de actualización.
16.4 Errores y límites
Las matrices de trazabilidad se pudren si no se actualizan en la misma solicitud de incorporación de cambios que la política. Manténgalas junto al código. La integración continua de Lena hace fallar una solicitud de incorporación de cambios que modifica un archivo de política sin tocar la matriz, lo que mantiene ambos sincronizados. Cada fila lleva además la fecha de su última verificación. Las filas que no se han comprobado en un trimestre se señalan en la reunión de revisión, porque un vínculo antiguo suele estar roto. Los responsables confirman cada fila una vez al año.
Nota práctica
Ponga los identificadores de los requisitos en los nombres de los objetos del cortafuegos y en los comentarios de configuración de los detectores (req=R-12). Poder buscarlos durante un incidente vale más que una diapositiva que alguna vez relacionó requisitos con módulos.
16.1b Glosario y retirada
Mantenga un glosario de una página: permiso de trabajo, ConduitSet, lista de permitidos, técnica planificada, evidencia sellada. Las partes interesadas usan mal «cobertura» y «riesgo» constantemente; el glosario es un artefacto de requisitos. La trazabilidad también cubre la retirada: cuando se retira un requisito, márquelo como sustituido con una referencia en lugar de borrar la fila. Los hallazgos históricos siguen citando identificadores antiguos. Los acuerdos de nivel de servicio internos entre servicios importan: el monitor puede necesitar que el almacén de hallazgos acepte un evento en N segundos durante una condición de parada. Escríbalo como requisito con una prueba de carga sintética. Sin él, los avisos de condición de parada llegan después de que la persona ya haya llamado a seguridad de procesos.
Ejercicios — capítulo 16
- EX046 — Deberá. Reescriba «impedir que la oficina toque SCADA» como dos requisitos con «deberá». Rúbrica: 3 = dos enunciados comprobables con método de verificación; 2 = uno bueno; 1 = sigue siendo vago; 0 = nada.
- EX047 — Traza. Para R-12, nombre el artefacto y la señal de la prueba que falla. Rúbrica: 3 = aristas por zonas + L1-SIS en reach(L4); 2 = uno; 1 = vago; 0 = nada.
- EX048 — Interfaz. Enumere tres campos de un contrato de interfaz de lista de etiquetas. Rúbrica: 3 = nombre de la etiqueta, tipo/unidades de ingeniería, frecuencia de actualización (o equivalente); 2 = dos; 1 = uno; 0 = nada.
Síntesis del capítulo
Requisitos que se pueden probar, vínculos que se pueden seguir, interfaces con versión.
Siga estudiando — capítulo 16 de 50
← Capítulo 15 (borrador) · Índice de capítulos del curso · Capítulo 17 (borrador) →