INGENIERIA EN AREAS COSTERAS

LECCIONES APRENDIDAS DE LA
BARRERA CONTRA TORMENTAS DE
MAESLANT EN LOS PAÍSES BAJOS

Barrera de Maeslant es una de las barreras

contra las tormentas y las presas de cierre
son proyectos de defensa costera de gran
envergadura, capaces de proteger las
entradas de mareas, ríos y estuarios de
fenómenos ocasionales de tormentas
Lecciones aprendidas de la barrera contra
tormentas de Maeslant en los Países Bajos

Josseph Gustavo*,
Palomino Poma
Facultad de ingeniería civil
Universidad continental
Correo electrónico: 47207309@continental.edu.pe
*Autor Correspondiente

Resumen: La barrera contra tormentas Maeslant en los Países Bajos es un caso

interesante en cuanto a la fiabilidad del sistema, en primer lugar por el gran

esfuerzo que se ha puesto en hacer que su funcionamiento sea fiable y en evaluar

su fiabilidad, y en segundo lugar, porque tiene características que hacen que la

evaluación de la fiabilidad sea extremadamente difícil. De su historia se pueden

extraer una serie de conclusiones interesantes, de las cuales la más importante es

que no existe una solución sencilla y definitiva a la fiabilidad, sino que la

fiabilidad se obtiene y se mantiene en un proceso continuo de mejora. Otras

conclusiones son que no se puede excluir a los seres humanos de la operación o

de la toma de decisiones en sistemas como la barrera Maeslant, que todos los

métodos para mejorar la fiabilidad del sistema son más eficaces cuando las

personas implicadas son muy conscientes de las limitaciones de cada método y

que un proceso continuo y abierto de consulta a una variedad de expertos es

crucial para obtener la mejor fiabilidad posible.

Palabras clave: estructuras costeras, riesgo de inundaciones, protección costera,

Storm Surge Barrier; factores humanos; Barrera de Maeslant
1 Introducción

Tras las catastróficas inundaciones en la provincia de Zeeland, en los Países Bajos, en 1953,
Rijkswaterstaat, la organización del gobierno holandés responsable de la principal
infraestructura de protección contra las inundaciones, elaboró y llevó a cabo el plan Delta1
para una protección completa y duradera contra las inundaciones. La esencia del plan era
reducir la probabilidad de que el agua de mar se inundara a una vez cada 10.000 años,
aumentando la altura y la robustez de las construcciones de protección. Se formularon
requisitos algo menos estrictos para la inundación del agua de los ríos.

El requisito de una vez cada 10 000 años puede traducirse en un nivel del agua de mar
de 4,8 m por encima del NAP (la referencia de altura holandesa, que se aproxima al nivel
medio del mar) que las obras de protección contra inundaciones deberían ser capaces de
soportar. Una inundación en los alrededores de Rotterdam pondría en peligro a unos 1,3
millones de personas y destruiría una capacidad de producción económica de unos 50.000
millones de euros al año (aproximadamente el 10% del PNB anual de los Países Bajos).

La pieza final del plan Delta era el llamado Maeslantkering (kering es la palabra
holandesa para barrera), la barrera móvil contra tormentas en la Nieuwe Waterweg, que es
la entrada al puerto de Rotterdam y uno de los estuarios de los principales ríos (Rin y Mosa)
en los Países Bajos. La barrera móvil fue diseñada para resolver el problema de cumplir
con los requisitos del plan Delta, mientras que, en circunstancias normales, mantenía
abierto el puerto de Rotterdam y permitía la salida del agua del río. Los diques actuales de
la zona ofrecen protección a niveles de agua de mar de hasta 3,6 m por encima del NAP.
Se prefirió el Maeslantkering a aumentar la altura de los diques en toda la zona en 1,2 m,
principalmente porque se consideraba menos intrusivo, más barato y tecnológicamente más
atractivo.

La barrera, mostrada en la figura 1, consta de dos puertas, cada una con una altura de
22 m y una longitud de 210 m. Mediante dos brazos horizontales de acero, ambos de tamaño
comparable al de la torre Eiffel, se conectan a dos rótulas, cada una de ellas anclada en 52
000 toneladas de hormigón capaz de soportar una fuerza horizontal de 35 000 toneladas. 2
Cuando no se utilizan, las puertas se almacenan en dos diques secos a orillas de la Nieuwe
Waterweg.

El cierre y la apertura de la barrera son procesos bastante complejos que, con toda razón,
han sido automatizados: estos procesos automatizados pueden probarse y son el único
medio de gestionar los numerosos eventos que tienen que tener lugar a tiempo y en el orden
adecuado. La decisión de cerrar la barrera también está automatizada. El llamado BOS
(siglas holandesas de Beslis en Ondersteunend Systeem, que significa Sistema de Decisión
y Apoyo) toma la decisión, basada en el nivel de agua de mar esperado cerca de la barrera,
y la ejecuta. Los alarmantes niveles de agua sólo pueden ser causados por una combinación
de marea de primavera y una tormenta del noroeste. La altura de cierre se ha determinado
a un nivel de agua esperado de 3,2 m por encima del PNA (recientemente cambiado a 3 m
para proteger una zona que fue primer que se inunde). El BOS es en parte nuevo, pero en
parte también se basa en el llamado Buiten-BOS (BOS externo), un software para la
predicción del tiempo y del nivel de agua que ya existía antes del desarrollo del BOS.
Figura 1 La barrera de oleaje Measlant storm

La barrera está diseñada para evitar la entrada de agua de mar. Si no se cierra, es evidente
que la barrera fracasaría en su propósito, pero si no se vuelve a abrir durante un tiempo
prolongado, se podrían producir inundaciones, debido a la acumulación de agua del río.

El sistema de agua en la zona de Rotterdam es un sistema complejo en el que la Nieuwe

Waterweg no es la única salida al mar. El Maeslantkering está interrelacionado con otras
dos barreras móviles, la barrera de Hartel en el canal de Hartel y la barrera de Haringvliet.
Estas dos últimas barreras pueden permitir la salida del agua del río en caso de que el
Maeslantkering no se abra después de un cierre. Esto significa que la probabilidad de
inundación catastrófica, resultante de un fallo en la apertura de una de las tres barreras, no
puede considerarse por barrera, sino que sólo puede determinarse considerando el sistema
completo. Las tres barreras funcionan de forma independiente, lo que reduce
considerablemente la probabilidad de que se produzcan inundaciones catastróficas por el
agua del río debido a la falta de apertura de una barrera. Este es un buen ejemplo de la
importancia de las opciones de retroceso en la fiabilidad del sistema.

La decisión de construir el Measlantkering se tomó en 1988. Rijkswaterstaat encargó

un contrato de diseño y construcción a un consorcio de empresas constructoras privadas.
Durante la fase de diseño a mediados de la década de 1990, el requisito del Delta de no más
de una inundación en 10.000 años se tradujo en una tasa de no cierre o apertura de una de
cada 1.000 solicitudes. Aunque considerablemente mejor de lo estrictamente necesario, esta
tasa de fracaso se consideró factible en su momento. Más tarde quedó claro que esta
sentencia se basaba en motivos insuficientes (van Akkeren, 2006).

La tasa de fracaso de una de cada 1000 solicitudes de cierre llevó a la conclusión de

que los operadores humanos serían demasiado poco fiables. Por lo tanto, se tomó la
decisión de que la barrera debería funcionar de forma completamente automática. Esta
decisión también resultó estar insuficientemente justificada.
 El subsistema BOS se encargó por separado a un contratista de software. Este
contratista introdujo la norma de Integridad de Seguridad IEC 61508 (IEC, 1996) y por lo
tanto introdujo métodos formales en el diseño y construcción del software, debido a las
recomendaciones de la norma IEC. Sin embargo, como se ha señalado anteriormente, parte
del sistema BOS consistía en sistemas existentes que no se construían mediante métodos
formales y que eran demasiado complejos y especializados para reconstruirlos en el plazo
y el presupuesto dados.

La historia de Maeslantkering demuestra que es un caso interesante en cuanto a la

fiabilidad del sistema. Se han realizado y se siguen realizando grandes esfuerzos para
mejorar y estimar su fiabilidad. También es un caso bastante extremo: es un espécimen
único de un tipo de sistema que es único en el mundo. No puede ser probado en las
condiciones para las que fue diseñado (niveles de agua superiores a 3,6 m), pero su fallo en
tales condiciones sería verdaderamente catastrófico. La diferencia con, por ejemplo, la
industria del automóvil, en la que la fiabilidad también desempeña un papel clave, pero en
la que los sistemas se producen y utilizan en masa, no podría ser mayor.

Estos casos extremos tienen la ventaja de permitirnos poner una lupa sobre ciertos
aspectos del problema de la fiabilidad, lo que nos permite conocer mejor los límites de los
métodos aplicados.

En las siguientes secciones, detallaremos y analizaremos la historia de Maeslantkering.

De este análisis pueden extraerse varias conclusiones sobre la fiabilidad de los sistemas de
software y el factor humano en la fiabilidad. Por último, se darán algunas recomendaciones
para el Maeslantkering.

2 Mejora y evaluación de la fiabilidad del sistema de software

Este artículo se centra en la parte de software de Maeslantkering, porque es la parte que

resulta más problemática en los diversos documentos sobre la evaluación de la fiabilidad
de la barrera (Arcadis, 2005; Brinkman y Schüller, 2003). Además, la parte de software, y
especialmente el sistema BOS, es la parte más estrechamente relacionada con el factor
humano en el sistema. La BOS estaba destinada a sustituir a los seres humanos en el
funcionamiento de la barrera.

En el ciclo de vida del software, se pueden distinguir varias fases, cada una de las cuales
tiene su propio enfoque del problema de la fiabilidad. Distinguimos una fase de diseño, una
fase de construcción, una fase de pruebas y una fase de uso y mantenimiento simultáneos.
La práctica demuestra, una y otra vez, que la fase de mantenimiento está gravemente
subestimada y que el Maeslantkering no es una excepción (van Akkeren, 2006). En el
enfoque evolutivo del desarrollo de software, un sistema pasa por todas las fases
repetidamente y crece de forma incremental, no sólo en funcionalidad sino también en otros
aspectos como la fiabilidad. Sin prácticamente ninguna excepción, este patrón se aplica a
todos los artefactos técnicos, incluso si, originalmente, el proyecto fue concebido como un
enfoque de cascada. Por eso, los artefactos técnicos siempre tienen números de versión. La
única diferencia entre el enfoque en cascada y el enfoque evolutivo es que este último es
conscientemente evolutivo y se presta especial atención al diseño del proceso de desarrollo
más adecuado (cosas como el tamaño del paso, el tamaño de la primera versión, etc.).
2.1 Métodos formales
En la fase de diseño, los métodos formales pueden desempeñar un papel importante. Los
métodos formales para el desarrollo de software son en esencia métodos matemáticos.
Consisten en lenguajes que tienen su significado expresado en matemáticas y que permiten
probar con rigor matemático las afirmaciones sobre las propiedades de las especificaciones,
expresadas en un lenguaje de este tipo. El desarrollo de software en la BOS fue una
combinación de métodos formales e informales. Los métodos formales Z y Promela
(Spivey, 1992; Holzman, 1997) se aplicaron principalmente al diseño técnico. La
codificación, en un subconjunto seguro de C++, y las pruebas de código no eran formales
sino que estaban respaldadas por medios formales (Tretmans et al., 2001).

Los métodos formales no son una excepción a la regla de que un método es más efectivo
cuando se aplica con las expectativas correctas y con plena conciencia de las limitaciones
del método (Bowen y Hinchey, 1995; Hall, 1990). Los métodos formales han demostrado
ser muy eficaces para prevenir un cierto tipo de error, en BOS y en muchos otros proyectos.
Suelen ser un paso intermedio entre una especificación de usuario informal o un documento
de requisitos y la realización de un sistema en un lenguaje de programación. Los métodos
formales pueden reducir considerablemente los errores que pueden ocurrir en la traducción
desde el documento inicial hasta el código fuente ejecutable. Además, existen métodos que
se aplican al código fuente y que permiten comprobar la corrección de aquellas partes cuya
funcionalidad puede ser expresada de forma formal. Lo que los métodos formales no
pueden hacer es asegurarse de que el documento inicial no contenga errores, omisiones
graves o características que más tarde resulten indeseables. La razón es que no tenemos
una especificación formal del mundo real, lo que hace que el documento inicial sea
formalmente inverificable. Además, traducir el resultado de una verificación formal en una
declaración sobre el correcto funcionamiento del software, en realidad, requiere hacer
muchas suposiciones sobre el entorno en el que se ejecuta el software y el comportamiento
del entorno del sistema. Por ejemplo, el comportamiento correcto del software también
depende de la corrección del compilador y de la plataforma en la que se ejecuta el software,
que normalmente no se han verificado formalmente. Más importante aún, el modelo del
entorno del sistema es inevitablemente una simplificación de la realidad: "todos los
modelos están equivocados, algunos son útiles por un tiempo" (Box, 1979). En el caso del
Maeslantkering, por ejemplo, el comportamiento del agua fue al principio simplificado en
exceso, ignorando un efecto importante llamado seiche (de Jong, 2004). Un seiche es una
ola estacionaria en el estuario, que puede tener el efecto de que el nivel del agua en el lado
interior de la barrera se eleva 2 m por encima del nivel del mar, lo que puede provocar que
las puertas de la barrera se salgan de sus rótulas. El problema ya se detectó en la fase de
desarrollo en 1997, pero su solución provocó un año de retraso en la entrega de la barrera
(van Akkeren, 2006). No hay forma de demostrar que no existen otros problemas
desconocidos en el comportamiento del agua.

Otros inconvenientes de los métodos formales son que su aplicación suele requerir
mucho tiempo y depender de la escasez de conocimientos. No hay muchas personas que
tengan experiencia adecuada en la aplicación de métodos formales en la práctica. Además,
tiene poco sentido aplicar métodos formales en el diseño y la construcción inicial, si no se
aplican a lo largo de todo el ciclo de vida de un sistema. El resultado de un período de
mantenimiento informal de un sistema diseñado formalmente sería una falsa impresión de
alta fiabilidad.

También existe un efecto negativo de los métodos formales sobre la flexibilidad de un

sistema, pero en el caso de la barrera, la fiabilidad es mucho más importante que la
flexibilidad, por lo que no es una desventaja real en este caso específico.
 Los métodos formales son indispensables para alcanzar el nivel de fiabilidad requerido,
pero no pueden garantizar el comportamiento correcto del sistema en la realidad, debido al
hecho de que el documento de partida no es necesariamente formal o no verificable
formalmente y debido a las muchas suposiciones que hay que hacer para traducir los
resultados de las verificaciones formales en declaraciones sobre el comportamiento
correcto en la práctica. En realidad, es incluso imposible hacer una lista completa de todos
los supuestos. Esto también requeriría un modelo correcto y completo del entorno del
sistema. En la práctica, muchas suposiciones incluso permanecerán implícitas.

2.2 Pruebas
Las pruebas son indispensables, como confirmará cada ingeniero. La opinión de los
ingenieros de software de que los métodos formales podrían eliminar la necesidad de
realizar pruebas fue abandonada hace mucho tiempo (Bowen y Hinchey, 1995; Hall, 1990).
En realidad, los métodos formales y las pruebas pueden considerarse complementarios.
Una prueba puede variar en el grado en que se aproxima al uso real, pero en general una
prueba se aplica a muchas más cosas que un método formal. Hace muchas menos
suposiciones, pero una prueba es sólo un caso único en un gran espacio de estados
diferentes en el que puede estar un sistema y su entorno. Las pruebas exhaustivas pueden
contribuir considerablemente a la confianza en un sistema, pero sacar conclusiones sobre
la fiabilidad de un sistema en funcionamiento depende también de suposiciones,
especialmente en lo que se refiere al grado en que las circunstancias de las pruebas y las
circunstancias operativas no difieren de manera relevante.

Dadas todas las suposiciones que hay que hacer, tanto en el caso de los métodos
formales como en el de los ensayos, puede concluirse que el uso real es crucial para ganar
confianza en un sistema. Este es el punto en el que el Maeslantkering es obviamente un
caso extremo. Las circunstancias reales para las que fue diseñado son extremadamente
raras, de lo contrario la ciudad de Rotterdam habría sido tragada por las olas hace mucho
tiempo. No es posible probar el comportamiento de la barrera en la vida real a los niveles
del agua y en las condiciones climáticas para las que es realmente necesaria. Cualquier
declaración sobre su correcto funcionamiento en esas circunstancias es una extrapolación
de circunstancias más leves.

2.3 El enfoque probabilístico de la fiabilidad

El enfoque probabilístico de la fiabilidad significa que la fiabilidad deseada se expresa
como una probabilidad numérica ("como máximo un fallo en 1000 ensayos" o"como
máximo una inundación en 10 000 años"). Este es el enfoque aplicado en el caso de
Maeslantkering. La fiabilidad requerida se expresó como probabilidad de fallo y,
posteriormente, la evaluación de la fiabilidad fue, en esencia, un intento de determinar esta
probabilidad de fallo.

Las probabilidades son la forma común de expresar la fiabilidad, por lo que parece que
no hay mejor manera. Sin embargo, uno debería ser muy consciente, una vez más, de las
limitaciones del enfoque probabilístico. Las limitaciones pueden resumirse en una
afirmación: las cosas reales no tienen probabilidades, sólo los modelos. Lo difícil a la hora
de sacar conclusiones sobre cosas reales a partir de afirmaciones probabilísticas, es la
cuestión de hasta qué punto el modelo implicado refleja lo real en todos los aspectos
relevantes. La gran diferencia entre los modelos y las cosas reales es que los modelos no
tienen partes que no se hacen explícitas. Las cosas reales lo hacen. Un modelo es
completamente conocido, las cosas reales no lo son. Los modelos no cambian sin previo
aviso, las cosas reales sí.
 Incluso si las probabilidades se determinan a partir de experimentos con el sistema real,
sigue existiendo un factor llamado "perfil operativo", es decir, "las circunstancias en las
que opera el sistema". Si el perfil operacional cambia durante los experimentos, algo que
puede suceder sin que los experimentadores lo sepan, los resultados probabilísticos se
vuelven discutibles. Pero incluso si el perfil operativo fuera constante durante los
experimentos, podría no serlo en el futuro. En el caso de Maeslantkering, las probabilidades
que podrían determinarse a partir del uso real (lo que aún no se ha hecho hasta la fecha) no
cubrirían el perfil operativo de los niveles de agua por encima de los 3,6 m, debido a la
rareza de esta condición. Tales experimentos serían útiles (si fallan en circunstancias
normales, probablemente no lo harían mejor en circunstancias difíciles), pero ciertamente
no decisivos.
El enfoque probabilístico apunta a un método importante para hacer que los sistemas
sean confiables: las opciones de retroceso. Si existen varios mecanismos para la misma
función, y si estos sistemas funcionan de forma independiente, lo cual debe considerarse
cuidadosamente, las tasas de fallo (expresadas como la probabilidad de fallo por ocasión en
que se necesite la función) pueden multiplicarse. Se trata de un medio muy potente para
obtener una alta fiabilidad: tres mecanismos mediocres para la misma función, cada uno
con una tasa de fallo de 1 en 10, dan como resultado una alta fiabilidad de 1 en 1000.

3 Ocho años de mantenimiento

Poco después de la colocación de la barrera, surgieron una serie de problemas graves,

perfectamente normales en un sistema tan innovador y complejo como el de la barrera, pero
que contrastan claramente con las afirmaciones de fiabilidad realizadas en el momento de su
colocación. Hubo problemas con las rótulas y otras partes mecánicas y electromecánicas,
y también hubo problemas con el software, especialmente con la interfaz entre el BOS y el
BES (el sistema operativo para cerrar y abrir la barrera). Las dos partes son hechas por
partes diferentes, usando métodos y estándares muy diferentes, esto no debería haber sido
una sorpresa.

El BOS fue entregado como un sistema certificado SIL4. Este término fue introducido
en 1996 por una nueva norma para la fiabilidad en sistemas intensivos en software: la
norma IEC 61508 (IEC, 1996). Esta norma distingue cuatro niveles de confiabilidad: los
Niveles de Integridad de Seguridad SIL1 a 4. Los puntos de referencia para la mano de
obra necesaria para construir un sistema con una fiabilidad SIL4 del tamaño de la BOS
indicaban que el contratista habría trabajado casi un milagro para que la reclamación
estuviera justificada (Jones, 2000). Lo que probablemente ocurrió es que el contratista
siguió las recomendaciones para el desarrollo de software que forman parte de cada SIL
del estándar. Cada SIL se expresa como una tasa de fallo (por ejemplo, "SIL4" es
aproximadamente una tasa de fallo de una vez como máximo cada 10 000 años). La
certificación de uno de los SILs sólo significa que se han seguido las recomendaciones, no
que el sistema en cuestión tiene la tasa de fallos prescrita. No existe ninguna justificación
sólida para suponer que el seguimiento de las recomendaciones para cada SIL sea suficiente
para obtener la fiabilidad correspondiente. 3

La fase de mantenimiento reveló otro problema importante: después de la entrega, el

sistema fue entregado a la organización de mantenimiento del comisionado, que
inicialmente no estaba en absoluto adecuadamente capacitada para mantener un sistema
tan novedoso (van Akkeren, 2006). En combinación con los muchos problemas iniciales
del nuevo sistema, se convirtió en
Es evidente que es necesario un replanteamiento fundamental del sistema, en el que, entre
otras cosas, también habría que reconsiderar el papel de los seres humanos. Aparentemente,
el software no era tan fiable como sugería el certificado SIL4.

En el período 2001-2005 se llevaron a cabo varias evaluaciones (Arcadis, 2005;

Brinkman y Schüller, 2003). Las evaluaciones pusieron de manifiesto una serie de defectos
de diversa importancia, la mayoría de los cuales podían ser subsanados. Así pues, las
evaluaciones dieron lugar a una mejora sustancial de la fiabilidad de la barrera. La
evaluación más elaborada (Brinkman y Schüller, 2003) también hizo una valoración de la
tasa de fallos y la cifra resultante fue bastante decepcionante: la tasa de fallos de la barrera
se estimó en 1 de cada 10, mucho peor que el objetivo inicial de 1 de cada 1000. El método
aplicado en la evaluación de la tasa de fallos era cuestionable en bastantes aspectos. Por
ejemplo, las tasas de fallo de los componentes básicos y las probabilidades de diversos tipos
de circunstancias eran poco más que estimaciones aproximadas. Una segunda crítica fue
que la tasa de fallos estaba demasiado relacionada con la especificación funcional original
y no con la prevención de inundaciones catastróficas. Si el cierre de las puertas tardaba 5
minutos más de lo especificado, se consideraba un fracaso, mientras que un evento de este
tipo obviamente no causaría una inundación.

No obstante, el informe dio lugar a un nuevo programa de mejora de la barrera, que

todavía está en marcha. Más notablemente, como resultado del informe, se llegó a la
conclusión de que no eran factibles unos índices de fallos muy bajos y demostrables del
software, por lo que los seres humanos volvieron a participar en el proceso operativo
(Schultz van Haegen, 2006).

4 Factores humanos

Durante el diseño, la construcción y el mantenimiento de la barrera de Maeslant, se prestó

especial atención a las personas en una función específica: la de operario. Los seres
humanos fueron excluidos de este papel debido al requisito inicial de una tasa de fallo
extremadamente baja. Curiosamente, la pregunta de si sería posible cumplir este requisito
sin la presencia de seres humanos se respondió afirmativamente, obviamente por motivos
insuficientes. No se planteó la única pregunta que debería haberse planteado, es decir, cómo
lograr la mejor tasa de fallos posible en la combinación de personas y máquinas, ni se
estudió la cuestión de cómo hacer más fiable el papel de los seres humanos en el proceso
operativo. Como vimos anteriormente, las opciones de retroceso pueden lograr excelentes
tasas de fallo de componentes bastante poco fiables, si se aplican correctamente.

La fase de mantenimiento dejó claro que la barrera no era perfecta: había que
mantenerla. Esto apuntaba a un segundo papel para los seres humanos: el papel de
mantenimiento. A continuación veremos que las dos funciones están relacionadas.

Los seres humanos y las computadoras son en realidad complementarios de varias

maneras. Los humanos son lentos y poco fiables, los ordenadores son rápidos y fiables. Los
humanos pueden manejar lo imprevisto, las computadoras son totalmente incapaces de
hacerlo. Por lo tanto, el papel de los seres humanos viene determinado en gran medida por
el grado en que el sistema y su entorno son conocidos y predecibles. En el caso de
Maeslantkering, el largo período para el que fue diseñado (100 años) garantiza muchos
acontecimientos imprevistos. Además, el medio ambiente, la atmósfera y el sistema hídrico
(Mar del Norte, Nieuwe Waterweg, Haringvliet, el Rin y el Mosa) son sistemas muy
complejos, si no caóticos, cuyo comportamiento (especialmente a largo plazo) sólo se
conoce en parte, como lo demuestra el retraso en la construcción causado por el fenómeno
seiche; razón suficiente para que los seres humanos desempeñen un papel firme en el
funcionamiento de la barrera, a pesar de que los propios seres humanos son una de las
fuentes más importantes de enfermedades imprevistas. Un equipo de mantenimiento tiene
acceso a todas las partes de un sistema. Puede dejar el sistema atrás en cualquier estado
posible. En principio, toda la confianza acumulada durante los años de uso ya no está
justificada después de una revisión de mantenimiento. Sólo los humanos pueden manejar
las situaciones imprevistas causadas por los humanos. Diversos rumores sobre errores de
mantenimiento con la barrera, sean ciertos o no, constituyen una prueba de que esto se
aplica tanto a la barrera como a cualquier otro sistema.

Hay otro papel para los seres humanos en sistemas como el Maeslantkering. Este papel
tiene que ver con los responsables políticos y las autoridades responsables ante la sociedad
del buen funcionamiento del sistema. En esencia, una declaración sobre la fiabilidad es una
declaración sobre el futuro. Esto significa que no puede ser verificado y ni siquiera
falsificado (refutado si no es cierto). Desde el punto de vista de las personas directamente
implicadas en la construcción, el mantenimiento y la explotación de la barrera, hacerla
fiable significa, en esencia, convencerse a sí mismas y convencer a las autoridades
responsables. Este patrón se puede observar en muchas otras situaciones: el futuro no
existe; lo único que importa son los puntos de vista que la gente tiene actualmente sobre el
futuro. Hacer que un sistema sea fiable significa convencer a la gente de su fiabilidad. Esto
se aplica especialmente al enfoque probabilístico de la fiabilidad. Puede parecer absurdo,
pero deberíamos darnos cuenta de que esto es lo que realmente ocurre. Demuestra que estas
autoridades tienen un papel muy importante y difícil. Si no son lo suficientemente exigentes
o si hacen hincapié en los aspectos erróneos, esto pondría seriamente en peligro la fiabilidad
de la barrera. Huelga decir que las autoridades responsables no pueden ser expertos en
todas las disciplinas que intervienen en el diseño, la construcción, la explotación y el
mantenimiento de la barrera. También en este caso, el software, producto de una disciplina
de ingeniería relativamente joven, se destaca como el área más problemática. Entre las
autoridades competentes hay ingenieros civiles y juristas, pero muy pocos, si es que hay
alguno, informáticos o ingenieros de software. Significa que tienen que confiar en el
consejo de los expertos. Aquí es donde todos los problemas conocidos de los expertos
consultores entran en el problema de la fiabilidad: no todas las personas que dicen ser
expertos lo hacen justificadamente; los expertos no siempre están de acuerdo; los expertos
son falibles; los expertos están en un proceso de aprendizaje (lo que dicen hoy no es
necesariamente lo mismo que lo que dirán mañana); y los expertos tienen intereses, como
todos los demás seres humanos. No hay una solución fácil aquí. Las únicas dos cosas que
podemos sugerir para contrarrestar este problema son, en primer lugar, que la organización
que encarga el proyecto, Rijkswaterstaat en este caso, debe asegurarse de que sea lo más
competente posible y, en segundo lugar, que se lleve a cabo un proceso muy abierto de
consulta de expertos de diversos ámbitos, tanto académicos como de empresas privadas,
tanto nacionales como internacionales. El primer punto, la competencia de la organización
comisionista, es actualmente un tema de actualidad en la política nacional. El Raad van
State, el máximo órgano consultivo del gobierno holandés, declaró recientemente que el
nivel de conocimiento especializado está disminuyendo seriamente dentro de las diversas
organizaciones gubernamentales (Raad van State, 2006; Tjeenk Willink, 2006). Sólo
mencionaron un ejemplo por su nombre: Rijkswaterstaat. Cuando la organización que
encarga el proyecto no es lo suficientemente competente, el segundo punto, el proceso de
consulta abierta, no puede ejecutarse adecuadamente.
5 Conclusiones y recomendaciones

El análisis anterior de la historia de la barrera de Maeslant puede resumirse en las siguientes

conclusiones y recomendaciones.

5.1 La fiabilidad es un proceso

Hay una famosa máxima sobre la seguridad: "La seguridad es un proceso, no un producto"
(Schneier, 2000). La principal conclusión de la historia de Maeslantkering es que esta
máxima se aplica igualmente bien a la fiabilidad. La fiabilidad se obtiene en un proceso
interminable de mejora. La distinción más importante entre seguridad y fiabilidad es que
la seguridad también se refiere a la malicia, es decir, a las acciones intencionadas de los
seres humanos para impedir el buen funcionamiento de un sistema. Por lo general, la
fiabilidad sólo se ocupa de los defectos por coincidencia de circunstancias, no por acciones
intencionadas de los seres humanos. Sin embargo, la fiabilidad no es necesariamente más
fácil que la seguridad. Los requisitos de fiabilidad suelen ser mucho más estrictos que los
de seguridad (los requisitos SIL serían ridículamente inviables para los aspectos de
seguridad) y los objetos inanimados pueden ser muy ingeniosos para hacer que un sistema
se desvíe de su comportamiento previsto ("Murphy era un optimista" - O'Toole). 4
Varias causas contribuyen a hacer de la fiabilidad un proceso continuo. No sólo los
sistemas y las circunstancias (o los perfiles operativos) cambian de forma imprevista, sino
que también se puede observar que los requisitos cambian, por ejemplo, por la acumulación
de experiencia con el sistema y, sobre todo, que nuestro conocimiento de la construcción
de sistemas fiables y de la evaluación de la fiabilidad aumenta.

5.2 Todos los métodos tienen limitaciones

Un método será más efectivo si el usuario del método es plenamente consciente de sus
limitaciones. En el caso del Maeslantkering, observamos que todos los tipos de métodos
aplicados (tasas de fallos probabilísticos, métodos formales de desarrollo de software,
pruebas, uso real, análisis sistemático de fallos) tienen limitaciones de origen común:
nuestro conocimiento incompleto de un sistema y de su entorno, lo que da lugar a muchas
suposiciones inconscientes e implícitas. Sin embargo, los métodos aplicados son muy
valiosos o incluso necesarios, de lo contrario el sistema fracasaría sin duda alguna por
causas simples que podrían haber sido fácilmente eliminadas.

5.3 Se necesitan humanos para operar la barrera

Sólo los sistemas que funcionan en circunstancias predecibles y bien conocidas, que han
sido sometidos a pruebas exhaustivas y que han sido utilizados masivamente, que no
necesitan mantenimiento y que no tienen consecuencias catastróficas en caso de fallo
pueden funcionar sin personas. En el caso de la barrera de Maeslant, ninguno de estos
requisitos es válido.
Si un sistema se mantiene regularmente, este hecho por sí solo ya implica que un
sistema debe ser operado, o al menos supervisado, por seres humanos.
5.4 La barrera es un caso extremo desde el punto de vista de la fiabilidad
Las circunstancias operativas para las que se diseñó la barrera son muy raras
(aproximadamente una vez cada 70 años). Por lo tanto, no se prueba ni se utiliza en estas
circunstancias. Este es un problema esencial en cualquier solución a circunstancias
extremas. Las tortilleras tienen el mismo problema.

5.5 Recomendaciones para el mantenimiento de la barrera

Uno de los medios más eficaces para mejorar la fiabilidad de la barrera se encuentra en las
opciones de retroceso para todas las funciones esenciales. Si se puede argumentar que los
diferentes mecanismos para la misma función operan independientemente, entonces sus
tasas de fracaso pueden multiplicarse. Además, el método de añadir opciones de retroceso
puede combinarse con cualquier otro método para mejorar la fiabilidad.

Ahora que los seres humanos están de vuelta en el proceso operativo, se debería
estudiar cómo se pueden hacer más eficaces y cómo se puede reducir la falta de fiabilidad
inherente de los seres humanos. Las opciones de retroceso también parecen ser aplicables
en este caso.

Una vez que se entienda que la fiabilidad de la barrera es un proceso continuo, en el

que los conocimientos especializados desempeñan un papel crucial, debería estudiarse
cómo puede llevarse a cabo este proceso de la manera más eficaz posible. Un proceso de
consulta muy abierto, gestionado por una organización competente y bien informada,
parece ser una parte importante del proceso de mejora continua.

Referencias
Arcadis (2018) Review of dike ring connecting barrier 8, Maeslantkering & Europoortkering I,
Rijkswaterstaat Directorate Zuid-Holland & Directorate of Civil Engineering, 7 de
diciembre.
Bowen, J. y Hinchey, M. (2015) 'Seven more myths of formal methods', IEEE Software, Vol. 12,
No. 4, pp.34-41.
Box, G.E.P. (2017) `Robustez en la estrategia de construcción de modelos científicos', en R.L. Launer and
G.N. Wilkinson (Eds.) Robustness in Statistics, Nueva York: Prensa académica, http://www
.anécdota.com.au/archives/2006/01/all_models_are.html.
Brinkman, J.L. y Schüller, J.C.H. (2003) 'Reliability analysis OKE', Internal report
Rijkswaterstaat, Dutch.
De Jong, M.P.C. (2004) 'Origin and prediction of Seiches in the Rotterdam harbour basins', tesis
doctoral, Delft University of Technology.
Hall, A. (1990) 'Seven myths of formal methods', IEEE Software, septiembre.
Holzman, G. (2017) `The model checker SPIN', IEEE Transactions on Software Engineering,
Vol. 23, No. 5, pp.279-295.
IEC (2016) Safety Related Systems, Norma Internacional IEC 61508, Comisión Electrotécnica
Internacional, Ginebra, Suiza.
Jones, C. (2000) 'Software assessments, benchmarks and best practices', Information Technology
Series, Addison Wesley.
Raad van State (2006) Jaarverslag 2005, www.raadvanstate.nl.
Schneier, B. (2000) 'Crypto-Gram newsletter', 15 de mayo, http://www.schneier.com/crypto
-gram-0005.html.
Schultz van Haegen, M.H. (2006) Secretario de Estado del Ministerio de Obras Públicas: Carta
al Parlamento, 20 de febrero, RWS/SDG/NW 2006/332/23875, www.keringhuis.nl.
Spivey, J. (1992) La Notación Z: A Reference Manual, Nueva York: Prentice Hall.
Tjeenk Willink, H. (2006) 'The government has gone off track', NRC Handelsblad, 29 de abril, p.13.
Tretmans, J., Wijbrans, K. y Chaudron, M. (2001) 'Software engineering with formal methods:
the development of a storm surge barrier control system', Formal Methods in System Design,
Vol. 19, págs. 195-215.
Van Akkeren, K. (2006) Entrevista de Vrancken con Koos van Akkeren el 5 de abril de 2006.

Notas

1 El plan Delta se expresó en una ley, De Delta Wet (la Ley Delta), publicada en De
Staatscourant el 8 de mayo de 1958.

2 Página web de Maeslantkering: http://www.keringhuis.nl/.

3 Bishop, P.G., SILs and Software, http://www.adelard.co.uk/resources/papers/pdf/SCSC

Boletín_Software_SILs.pdf.

4 Comentario de O'Toole sobre la Ley de Murphy: http://userpage.chemie.fu-

berlin.de/diverse/murphy/ murphy2.html.
Ver estadísticas de publicación