AVISO IMPORTANTE:

(1)

(2)

(3)

Pág 1 de 1

Escuela Universitaria de Ingeniería Técnica Naval

C.A.S.E.M.

Pol. Río San Pedro

11510 Puerto Real (Cádiz) Tel. 956016046. Fax. 956016045 [email protected]

AVISO IMPORTANTE:

El único responsable del contenido de este proyecto es el alumno que lo ha realizado.

La Universidad de Cádiz, La Escuela Universitaria de Ingeniería Técnica Naval, los Departamentos a los que pertenecen el profesor tutor y los miembros del Tribunal de Proyectos Fin de Carrera así como el mismo profesor tutor NO SON RESPONSABLES DEL CONTENIDO DE ESTE PROYECTO.

Los proyectos fin de carrera pueden contener errores detectados por el Tribunal de Proyectos Fin de Carrera y que estos no hayan sido implementados o corregidos en la versión aquí expuesta.

La calificación de los proyectos fin de carrera puede variar desde el aprobado (5) hasta la matrícula de honor (10), por lo que el tipo y número de errores que contienen puede ser muy diferentes de un proyecto a otro.

Este proyecto fin de carrera está redactado y elaborado con una finalidad académica y nunca se deberá hacer uso profesional del mismo, ya que puede contener errores que podrían poner en peligro vidas humanas.

Fdo. La Comisión de Proyectos de Fin de Carrera Escuela Universitaria de Ingeniería Técnica Naval

Universidad de Cádiz

(4)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Tutor: D. Juan José Asencio Rodríguez

Autor: D. Marcos S. Marí Díez Página 3

(5)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ÍNDICE

0. INTRODUCCIÓN ... 7

1. MEMORIA. ... 9

1.1. ALCANCE Y OBJETIVO DEL PROYECTO ... 9

1.1.1. Datos del buque objeto del proyecto... 9

2. ANTECEDENTES ... 11

2.1. NORMATIVA Y REGLAMENTACIÓN APLICABLE ... 11

SECCION 1. REQUISITOS GENERALES ... 11

1.1. GENERAL ... 11

SECCION 2. CARACTERISTICAS BASICAS PARA LOS SISTEMAS DE MANDO, ALARMA Y SEGURIDAD. ... 11

2.3. SISTEMAS DE ALARMA. ... 11

2.9. SISTEMAS ELECTRONICOS PROGRAMABLES- HARDWARE. ... 13

2.10. RED DE AREA LOCAL (LAN’s). ... 15

2.11. SISTEMA ELECTRONICO PROGRAMABLE- SOFTWARE. ... 16

SECCION 4. ESPACIO DE MAQUINAS NO OCUPADAS- ANOTACION “UMS” ... 18

4.1. GENERAL. ... 18

4.2. SISTEMA DE ALARMA DE LA MAQUINARIA. ... 18

7.2. OPERACIONES EN ESPACIO DE MAQUINAS NO OCUPADAS- ANOTACION “UMS”. . 20

2.2. DESCRIPCIÓN DEL PROYECTO Y SUS CARACTERÍSTICAS. ... 20

2.3. JUSTIFICACIÓN DE LA SOLUCIÓN ADOPTADA. ... 21

2.3.1. Comunicación de Alto Nivel Ethernet ... 22

2.3.1.1. Medio Físico... 23

3. MATERIALES Y EQUIPOS INSTALADOS ... 25

3.1. EQUIPO DE CONTROL –AUTÓMATA PROGRAMABLE. ... 25

3.2. SOFTWARE DE PROGRAMACIÓN -UNITYPROXL5.0 ... 27

3.2.1. Lenguaje ST ... 28

3.2.2. Características del Entorno Unity Pro ... 30

3.2.3. Como se trabaja Unity Pro XL para crear una aplicación. ... 34

3.2.4. Configuración del Hardware en Unity Pro XL ... 37

3.2.5. Tipos de variables en Unity Pro XL ... 39

3.2.6. Programar una Aplicación en Unity Pro XL. ... 46

(6)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ÍNDICE

3.3. TERMINALES DE DIALOGO.HMI–XBT1130 ... 59

3.4. SCADA–VIJEO DESIGNER ... 62

3.4.1. Crear una aplicación con Vijeo Designer. ... 63

4. DESCRIPCIÓN DEL FUNCIONAMIENTO DEL SISTEMA. ... 72

4.1. ARQUITECTURA. ... 72

4.2. FUNCIONAMIENTO. ... 72

5. PRESUPUESTO ... 75

6. BIBLIOGRAFÍA ... 77

7. ANEXOS. ... 79

7.1. PROGRAMACIÓN EN UNITY PRO XL. ... 79

7.2. VARIABLES DE UNITY PRO XL ... 90

7.3. VARIABLES DE VIJEO DESIGNER ... 92

7.4. PANTALLAS CREADAS CON VIJEO DESIGNER. ... 94

(7)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

INTRODUCCIÓN

(8)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

INTRODUCCIÓN

0. Introducción

En este proyecto se van a diseñar y calcular las características del sistema de extensión de alarmas que se han de contemplar para que un buque pueda obtener la anotación de cámara de máquinas desatendida (UMS - Unattended Machinery Space) según exigen las sociedades de clasificación, concretamente las reguladas por Lloyd’s Register.

Se diseñará el sistema de extensión de alarmas según lo expuesto anteriormente, para un buque quimiquero de 119 m. de eslora y 12.000 TPM, cuyas características se describirán en el siguiente punto.

Una particularidad importante a destacar en el proyecto es que, el sistema a diseñar, tanto hardware como software, se desarrollarán con equipos comerciales y protocolos estándares.

La simulación del sistema que voy a instalar para la presentación del proyecto la desarrollaré en base a software SCADA comercial y abierto.

(9)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

(10)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

MEMORIA DESCRIPTIVA

1. Memoria.

1.1. Alcance y objetivo del proyecto

El objetivo de este proyecto es dotar al buque, motivo de este proyecto, de un sistema de extensión de alarmas que permita su anotación de máquina desatendida bajo la normativa del Lloyd’s Register.

1.1.1. Datos del buque objeto del proyecto.

Nombre: Dante Amoretti (DANTE A) TIPO DE BUQUE: Quimiquero BANDERA: Italia

PUERTO DE REGISTRO: Catania ESTADO: En servicio

COMPAÑÍA NAVIERA: Amoretti Armatori Group CONSTRUIDO: Astilleros de Huelva – España AÑO: 2007

ESLORA (m): 119 MANGA (m): 22 CALADO (m): 8,3 VELOCIDAD (kn): 14,5 POTENCIA (kW): 7360 Año de construcción: 2007 Eslora x Manga: 119 m x 22m Desplazamiento: 10000 t

Velocidad registrada (Máxima / Media): 15.3 / 14,5 nudos Identificativo de llamada: ICCB

IMO: 9361029 MMSI: 247190400

(11)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

(12)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2. Antecedentes

El buque en cuestión fue construido sin la mencionada anotación del Lloyd’s. Por necesidad manifestada por el Armador, en una reforma posterior, se debería adaptar a la normativa UMS Lloyd’s.

2.1. Normativa y reglamentación aplicable

A continuación se detallan las normativas establecidas por Lloyd’s Register para dotar al buque de la anotación “UMS”.

CAPITULO 1

SISTEMA DE MANDO DE LA MAQUINARIA

SECCION 1. REQUISITOS GENERALES

1.1. GENERAL

1.1.3. La Sección 2 de este Capítulo enuncia los requisitos donde sean instalados los sistemas de alarmas, seguridad y los controles automáticos o remotos.

1.1.5. La Sección 4 de este Capítulo enuncia los requisitos que pueden aplicarse donde el buque está proyectado para funcionar en espacio de máquina no ocupadas. En general, los buques que cumplen con los requisitos de la Sección 4 serán elegidos para la anotación “UMS”

(ver Parte 1, capítulo 2,2)

SECCION 2. CARACTERISTICAS BASICAS PARA LOS SISTEMAS DE MANDO, ALARMA Y SEGURIDAD.

2.3. SISTEMAS DE ALARMA.

2.3.1. Donde deba ser instalado un sistema de alarma en los sistemas de seguridad y mando, el cual incluirá un avisador de fallos en la maquinaria, deben ser satisfechos los requisitos de 2.3.2 a 2.3.16.

(13)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2.3.2. Los fallos en la maquinaria y en los sistemas de seguridad y mando, deben ser indicados en la estación de mando pertinente, para avisar al personal del fallo. La presencia de fallos no rectificados debe ser claramente indicada siempre.

2.3.3. Las alarmas de fallos asociadas a la maquinaria y a los sistemas de seguridad y mando, deben ser claramente distinguibles de otras alarmas (por ejemplo: incendio, general).

2.3.4. Donde las alarmas son indicadas como un grupo de alarmas, deben ser hechas para identificarlas individualmente en la estación de mando principal (si es adecuado) o alternativamente en la estación secundaria de mando.

2.3.5. Todas las alarmas deben ser acústicas y ópticas a la vez. Si la disposición está hecha para silenciar los sistemas de alarmas acústicas, no se apagaran las alarmas ópticas.

2.3.6. El acuse de las alarmas ópticas debe ser claramente indicado.

2.3.7. El acuse de las alarmas situadas fuera de cámara de máquinas no silenciará las alarmas acústicas o no apagará las alarmas ópticas en esa cámara de máquinas.

2.3.8. Si una alarma ha sido acusada y un segundo fallo ocurre anteriormente a la rectificación del primero, las alarmas acústicas y ópticas seguirán funcionando. Cuando las alarmas son indicadas en un panel de un local adyacente a la maquinaria y su disposición está prevista en grupo o en una alarma de fallos comunes en los indicadores de la central de mando principal, la existencia de un segundo fallo anterior a la rectificación de la primera alarma solamente necesita ser indicado en el panel del local, de modo que el grupo de alarmas deba ser reiniciado.

2.3.9. Para la detección de fallos transitorios que son posteriores a su autocorrección, las alarmas son requeridas para bloquearse hasta que sean aceptadas.

2.3.10. El sistema de alarmas debe ser proyectado con cambio automático a una fuente de alimentación de socorro, en caso de avería de la fuente de alimentación principal.

(14)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2.3.11. Las averías de alguna fuente de alimentación del sistema de alarma deben ser indicado por una alarma acústica y óptica.

2.3.12. El sistema de alarma debe estar diseñado con un sistema de autocomprobación. Hasta donde sea factible, algunos fallos en el sistema de alarma pueden causar fallos a la condición de alarma.

2.3.13. El sistema de alarma debe estar capacitado para ser comprobado durante el normal funcionamiento de la maquinaria.

2.3.14. El sistema de alarma debe estar diseñado para funcionar independientemente de los sistemas de mando y seguridad, para que en caso de avería o mal funcionamiento de esos sistemas no impida el funcionamiento del sistema de alarma.

2.3.15. La desconexión o la anulación manual de alguna parte del sistema debe ser claramente indicada.

2.3.16. Cuando los sistemas de alarma están provistos con medidas para su ajuste, las características deben ser tales, que al final de la prueba puedan ser rápidamente identificadas.

2.9. SISTEMAS ELECTRONICOS PROGRAMABLES- HARDWARE.

2.9.1. Donde se coloquen sistemas de mando, alarma o seguridad que incorporen un equipamiento electrónico programable, se deben satisfacer los requisitos del 2.9.2 al 2.9.12.

2.9.2. Los equipos electrónicos programables deben ser Aprobados Tipo, de acuerdo con la Especificación de Pruebas Número 1 dadas en Lloyd´s Register “Sistemas Aprobados Tipo”.

Alternativamente, previa experiencia satisfactoria del servicio en el mar, debe ser aceptada como evidencia de lo adecuado para su uso.

2.9.3. La instalación estará también de acuerdo con los requisitos de “ La Compatibilidad Electromagnética de las instalaciones eléctricas y electrónicas en el buque” (ICE 533).

(15)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2.9.4. La función de parada en los sistemas de mando, alarma y seguridad, deben estar proyectados de tal forma que una simple avería o mal funcionamiento del equipo electrónico, no pueda afectar más que a una de esas funciones. Esto debe ser realizado por equipamiento dedicado para cada una de esas funciones dentro de un sistema simple, o por el suministro del equipo de socorro, o por otras medidas adecuadas. En el caso de sistemas programables, tendrán funciones de seguridad las cuales no serán retenidas por sistemas manuales, como consecuencia debe ser realizado un análisis para demostrar que el sistema programable es al menos tan fiable como un sistema manual.

2.9.5. Donde está provisto un equipo de socorro, el cambio del dispositivo debe ser para prevenir el mal funcionamiento del sistema electrónico de socorro y la maquinaria bajo control.

2.9.6. El sistema debe estar diseñado para auto-supervisarse y algún fallo que cause una avería del sistema llevará su función para iniciar una alarma acústica y óptica. Ambas operaciones y el equipamiento de socorro (si lo lleva), deben estar indicados.

2.9.7. La situación de un fallo del hardware, debe ser indicado por un nivel compatible con el diseño de los equipos de reparación/ sustitución.

2.9.8. El sistema debe estar diseñado para funcionar automáticamente con una fuente de alimentación alternativa, en el caso de que se averíe la fuente de alimentación principal.

2.9.9. La avería de alguna fuente de alimentación del sistema, iniciará una alarma acústica y óptica.

2.9.10. El programa y los datos que hay en el sistema deben estar protegidos de una corrupción por pérdida de potencia.

2.9.11. Donde alguna parte del programa esté guardado en memoria inestable, deben estar provistas las medidas de una copia permanente del programa y para reiniciarlo. El dispositivo de almacenamiento para la copia del programa debe ser tal que la corrupción no ocurra por el medio ambiente.

(16)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2.9.12. El acceso por alteraciones al programa o a los datos tendrá un dispositivo de seguridad. Ver también 1.4.1.

2.10. RED DE AREA LOCAL (LAN’s).

2.10.1. Donde una red de área local sea usada para transferir datos de alarma, mando, seguridad y supervisión entre ordenadores y equipos de almacenamiento de datos, se debe cumplir con los requisitos del 2.10.2 al 2.10.9.

2.10.2. La topología de la red debe ser tal que en el caso de una avería entre nudos, los sistemas de la red continuarán funcionando y la transmisión de datos entre ellos se mantendrá.

2.10.3. El protocolo es para asegurar la integridad de los datos que fluyen en la red. En adición, el software que los ordenadores comparten en la red debe estar diseñado para llevar un límite de chequeo en los valores de los datos.

2.10.4. La red debe ser capaz de transmitir la máxima transferencia de datos, la cual pueda posibilitar que fluya sin incurrir en una inaceptable latencia de datos o colisión de datos. El límite de latencia de datos en los indicadores de seguridad y alarma debe ser de dos segundos.

2.10.5. Deben ser provistas medidas para mantener la red funcionando en el caso de una avería en la red principal.

2.10.6. La disposición para conectar o desconectar nudos desde la red, debe ser tal, que la red continúe funcionando con el mínimo de interrupciones en los otros sistemas que comparten la red.

2.10.7. Deben ser provistas medidas para que en el monitor de la red, se puedan interpretar las averías que ocurran y otros parámetros necesarios. En el caso de que haya un fallo en la red, debe accionarse una alarma acústica y óptica.

2.10.8. Las comunicaciones y señales de vídeo que deben compartir la red, cumplirá con el requisito 2.10.4. Ver también 2.2.2, 2.6.8 y P. 5, C. 1,4.

(17)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2.10.9. La red debe ser instalada de tal forma que provea una adecuada protección de daños mecánicos e interferencias electromagnéticas. La conexión de las comunicaciones debe estar encaminada con la máxima separación como sea posible.

2.11. SISTEMA ELECTRONICO PROGRAMABLE- SOFTWARE.

2.11.1. Donde los sistemas de mando, alarma o seguridad, incorporan equipos electrónicos programables, deben ser satisfechos los requisitos del 2.11.2 al 2.11.9.

2.11.2. El diseño, desarrollo, modificación, repetición e instalación del sistema y aplicación del software deben estar sujetas a Planes de Calidad, los cuales se encontrarán en los requerimientos aceptados de Estándares Nacionales o Internacionales o Códigos de Práctica.

La certificación de los procedimientos de calidad del software lo hará una autoridad reconocida la cual aceptará el cumplimiento del sistema con los requerimientos. En ausencia de la certificación, los Planes de Calidad del software deben ser remitidos, y demostrarán que las características del 2.11.3 al 2.11.7 están incorporadas.

2.11.3. Los Códigos de Práctica en el diseño y prueba del software deben estar especificados y aseguraran que:

a) La especificación de los Requisitos del Sistema satisface todos los requisitos aplicables de la Clasificación y Estatutos.

b) La documentación del diseño, será tal, que los requisitos especificados deben estar trazados a todos los niveles.

c) Todos los módulos del software estarán claramente definidos e independientemente identificados.

d) La capacidad estimada de memoria requerida, la potencia del procesador y la capacidad de comunicación de datos serán presentados para justificar la selección del hardware.

e) Los procedimientos de pruebas y desarrollo, en paralelo con el proceso de diseño y el criterio aceptado, estarán definidos para probarlos a todos los niveles.

(18)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2.11.4. Las Técnicas de Manejo de la Configuración para identificar cada elemento configurado, los informes de los procesos de error, el control de los cambios de cada elemento configurado y el mando de las operaciones de las librerías de software, deben estar especificados y aseguraran que:

a) La configuración para el control del software estará plenamente integrada con el hardware.

b) Los puntos en el proyecto, en los cuales los elementos llevarán bajo el mando de la configuración, estarán claramente identificado.

2.11.5. Los Procedimientos de Control de la Calidad para el diseño revisado, la documentación aprobada, las pruebas y el sistema publicado, deben estar especificados y asegurarán que:

a) Las revisiones del diseño y las pruebas serán realizadas, como está definido en los puntos, en el ciclo del desarrollo por personal no comprometido directamente con el diseño original.

b) La documentación estará sujeta a aprobación.

2.11.6. Los Códigos de Prácticas y los Procedimientos de Control de la Calidad, relativos a subcontratos u otros procedimientos de software y soportes generados para ayudar a alguna fase del desarrollo, y ciclos de pruebas del proyecto, deben estar especificados y aseguraran que el software proporcionado y el soporte estarán también sometidos a un Plan de Calidad.

2.11.7. Deben ser especificados los ordenamientos para la revisión de los procedimientos enunciados en el Plan de Calidad.

2.11.8. Los trabajos de pruebas, requeridos por 1.3.1, son para incluir la verificación de la ejecución del software en relación a la especificación del sistema, y, hasta donde sea posible, demostrar que el funcionamiento bajo condiciones de señal normales y anormales está libre de errores.

(19)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

2.11.9. El soporte post- entrega, para el software, debe estar previsto por el proveedor para dar la completa satisfacción, hasta la primera inspección anual de la clasificación de la instalación de mando.

SECCION 4. ESPACIO DE MAQUINAS NO OCUPADAS- ANOTACION “UMS”

4.1. GENERAL.

4.1.1. Donde está propuesto que funcionen las siguientes máquinas en un espacio no ocupado, no importa que el periodo sea considerado, deben estar provistos los mandos, alarmas y protecciones requeridos en la Sección 3, junto con los dados en 4.2 a 4.7:

a) Compresor de aire;

b) Hélice de paso variable;

c) Planta generadora de electricidad;

d) Generadores de gas inerte;

e) Incineradores;

f) Maquinaria de propulsión principal, incluyendo los auxiliares esenciales;

g) Sistemas de transferencia de combustible y almacenamiento (depuradoras y calentadores de aceite);

h) Planta generadora de vapor (calderas y su equipamiento auxiliar);

i) Recalentadores de fluido térmico;

j) Calderas quemadoras de desperdicios.

4.2. SISTEMA DE ALARMA DE LA MAQUINARIA.

4.2.1. Un sistema de alarma debe ser instalado para prevenir el peligro de fallos en la maquinaria. El sistema debe satisfacer los requisitos de 2.3.

4.2.2. La indicación acústica y óptica de las alarmas de la maquinaria, debe ser transmitida a los camarotes de los maquinistas, para que el personal de la maquinaria sepa que ha ocurrido un fallo.

(20)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

4.2.3. Las alarmas de máquinas requeridas en 2.2.3, deben ser activadas automáticamente en el caso de que una alarma no haya sido acusada en el tiempo predeterminado.

4.2.4. Las indicaciones acústicas y ópticas de las alarmas de máquinas, deben ser señalizadas en el puente, para que el oficial de vigilancia sepa que:

a) ha ocurrido un fallo de la máquina

b) está siendo atendido el fallo de la máquina, y c) el fallo de la máquina ha sido arreglado.

Deben ser consideradas medidas alternativas de comunicación entre el puente, los camarotes para los maquinistas y cámara de máquinas.

4.2.5. Un grupo de alarmas debe ser dispuesto en el puente, para indicar los fallos de la maquinaria, pero deben ser identificados separadamente las alarmas asociadas a fallos de reducción de velocidad o energía, o la parada automática de la maquinaria de propulsión.

(21)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

7.2. OPERACIONES EN ESPACIO DE MAQUINAS NO OCUPADAS- ANOTACION “UMS”.

7.2.1. En adición a las pruebas requeridas en 7.1, debe ser demostrada la conformidad de la instalación para funcionar en modo “no ocupado”, durante las pruebas de mar, a lo largo de un periodo de cuatro a seis horas, observando lo siguiente:

a) Las alarmas que ocurren y la frecuencia de funcionamiento, durante el uso, del servicio de vapor y las condiciones de funcionamiento del puente.

b) Alguna intervención del personal en el funcionamiento de la maquinaria.

2.2. Descripción del proyecto y sus características.

Se entiende por sistema de extensión de alarmas el conjunto de equipos, hardware y software, capaz de transmitir una señal de alarma local a un terminal remoto, bajo los requerimientos que contempla la normativa de la sociedad de clasificación para la anotación correspondiente, principalmente recogida en los apartados 4.1, 4.2 del CAPÍTULO 1 de la NORMATIVA PARA LA APROBACIÓN DEL SISTEMA DE MANDO, ELÉCTRICO Y LA AUTOMATIZACIÓN EN CÁMARA DE MÁQUINAS, SEGÚN LLOY’S REGISTER.

Para el diseño y desarrollo del sistema de extensión de alarmas aplicable en este proyecto, me basaré en una arquitectura de red en anillo tal como la representada en la Ilustración 1 con su respetivo hardware comercial (autómatas programables, software Unity Pro XL, terminales de diálogos XBT, software Magelis, SCADA, Vijeo Designer).

(22)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

Ilustración 1. Topología de red en anillo.

2.3. Justificación de la solución adoptada.

El sistema de extensión de alarmas obedecerá a un diseño que tiene su nodo central en el equipo de control, que determino será un autómata programable de las características que se indicarán en el punto 1.6 de esta memoria.

De este nodo partirá la comunicación central hacia el switch de distribución. Del switch de distribución se extenderán las comunicaciones hacia cada uno de los paneles de alarmas (avisadores), situados en los camarotes de los oficiales de máquinas, así como a los terminales de diálogo situados en sala de control de cámara de máquinas (desde el que se puede actuar sobre el sistema) y en el puente (desde el que solo se puede visualizar).

Al mismo switch se conectará el PC de monitorización, que puede estar ubicado en el camarote del capitán o en cualquiera de los puntos de conexión que se hayan habilitado para ello (PC de configuración estándar, multiuso, pero autorizado para correr la aplicación).

(23)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

Finalmente, partirá del switch de distribución una conexión directa y redundada, hacia la red principal (LAN) que integra la comunicación de todos los servicios recogidos en el apartado 4 de la normativa UMS del Lloyd’s, y en la que estarán conectados los equipos de almacenamiento de datos e impresión de los mismos.

2.3.1. Comunicación de Alto Nivel Ethernet

Ethernet es el nombre de una red diseñada a principios de los setenta por Xeros Corporation. En la década de los ochenta se convirtió en un estándar de facto para los niveles físicos, enlace y red de numerosas redes locales en el campo de la ofimática.

Las prestaciones más relevantes de la red son las siguientes:

 Compatibilidad con el modelo OSI: Esta compatibilidad cubre solamente los niveles físico, enlace y red. No se propone ningún protocolo a nivel de transporte, sesión y aplicación.

 Compatibilidad de los nodos conectables: Esta compatibilidad se refiere solo a los niveles físicos y de enlace. Es decir, cualquier par de terminales

“compatibles” con ETHERNET son capaces de intercambiar datos, pero no necesariamente de interpretarlos.

 Simplicidad: La gestión de la red no debe e aumentar la complejidad de uso por parte del usuario.

 Bajo coste y fácil mantenimiento: Este requisito debe respetarse tanto para el medio físico de conexión como para las interfaces de protocolo de la red que deban incorporarse a cada terminal.

 Agilidad de direccionamiento: La red permite la comunicación punto a punto, los mensajes de un punto a otros varios “Multicast” y los mensajes de difusión, es decir, de un punto a todos los demás “Broadcast”.

 Equidad y fiabilidad: No existe ninguna prioridad entre las distintas estaciones y, además, la avería o desconexión de cualquiera de ellas no interfiere el funcionamiento de la red.

(24)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

ANTECEDENTES

 Alta velocidad: La velocidad prevista en la norma básica es de 10 Mbits/s, la cual posteriormente fue ampliada a 100 Mbits/s y actualmente existen ya aplicaciones basadas en el protocolo Gigabits/s. Además, la red no introduce ningún retardo aparte del estrictamente necesario para la transmisión de datos.

2.3.1.1. Medio Físico

La capa física es el medio en el cual se estableced la comunicación, es decir el cable.

Ethernet es la capa física más popular en la tecnología LAN (Local Área Network) usada actualmente. Ethernet es popular porque permite un buen equilibrio entre velocidad, costo y facilidad de instalación. Estos puntos fuertes, combinados con la amplia aceptación en el mercado y la habilidad de soportar virtualmente todos los protocolos de red populares, hacen a Ethernet la tecnología ideal para la red de la mayoría de los usuarios de la informática actual.

La norma de Ethernet fue definida por el Instituto para los Ingenieros eléctricos y Electrónicos (IEEE) como IEEE Standard 802.3. Adhiriéndose a la norma de IEEE, los equipos y protocolos de red pueden operar entre sí eficazmente. Actualmente, se emplean, básicamente, cuatro tipos de cableados o medios físicos: coaxial grueso, coaxial fino, par trenzado apantallado o sin apantallar (dependerá su uso de la velocidad elegida para la red Ethernet). Esta amplia variedad de medios físicos refleja la evolución de Ethernet y la flexibilidad de la tecnología. Para este caso se utilizara par trenzado, por ser el mas comúnmente empleado, por su reducido coste y por su fácil instalación. El par trenzado es similar al telefónico, por lo que puede estar instalado y disponible para la red en muchos edificios. El estándar que se empleara es 100baseT y las principales características del mismo son:

 100: Caudal de comunicación 100 Mbits/s.

 Base: Banda de comunicación Banda Base.

 T: Par trenzado.

 Conectores: RJ45.

(25)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

(26)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

MATERIALES Y EQUIPOS INSTALADOS

3. Materiales y equipos instalados

Tras realizar un estudio detallado sobre los equipos considerados comerciales y que permiten desarrollar un sistema bajo la condición de “sistema abierto”, consideración esta que cumplen los fabricantes:

 Siemens

 Omron

 ABB

 Allen Bradley (Rockwell Automation)

 Schneider Electric

Me inclino por los equipos de la firma Schneider al considerarlos dentro de las siguientes exigencias:

 Posibilidad de ser programados como sistemas abiertos.

 Equipos comerciales distribuidos a nivel internacional.

 Software de programación homologado por la norma IEC 61131-3.

 Modular en su arquitectura interna y por tanto de fácil ampliación.

 Homologado por el Lloyd’s Register.

 Económico.

3.1. Equipo de control – Autómata programable.

Un Autómata Programable Industrial es un equipo electrónico de control con un cableado interno, denominado Hardware, independientemente del proceso a controlar, que se adapta a dicho proceso mediante un programa específico, Software. Esta secuencia de operaciones se define sobre señales de entrada y salida al proceso, cableadas directamente en los bornes de conexión del autómata.

Las señales de entrada pueden proceder de elementos digitales, como finales de carrera y detectores de proximidad, o analógicos, como sensores de temperatura y dispositivos de salida en tensión o corriente. Mientras que las señales de salida son órdenes

(27)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

digitales todo o nada o señales analógicas en tensión o corriente, que sirvan a los elementos indicadores y actuadores del proceso.

El autómata gobierna las señales de salida según el programa de control previamente almacenado en una memoria, a partir del estado de las señales de entrada. Este programa se introduce en el autómata a través de la unidad de programación, que permite además funciones adicionales como depuración de programas, simulación, monitorización, control del autómata, etc.

Una característica diferenciadora del PLC frente a otros sistemas de control programables está en la estandarización de su hardware, que permite la configuración de sistemas de control “Dedicados”, según las necesidades estimadas de potencia de cálculo y número y tipo de señales de entrada y salida. El autómata se configura alrededor de una unidad central o de control, que, unida por medio de buses internos a las interfaces de entrada y salida y a las memorias, define lo que se conoce como arquitectura interna del autómata.

Utilizaré como equipo de control maestro del sistema, el autómata programable M340 de la firma Schneider con las características y configuración que recojo a continuación.

Ilustración 2. Autómata programable Modicom M340.

(28)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

 Procesador (CPU) BMX M340 2020 v2.1

 Fuente de alimentación BMX CPS 2000

 Rack de 8 slots BMX XBP 0800

 Tarjeta relé de 16 salidas digitales BMX DRA 1605

La configuración real variará en función al número de tarjetas que sean necesarias según los requisitos de los sensores y las comunicaciones. Un posible ejemplo de configuración es el descrito en el punto 3.2.4. de este proyecto.

3.2. Software de programación - UNITY PRO XL 5.0

El software de programación Unity Pro XL es un software de última generación y de reciente implantación en el campo de la automatización industrial. Ante tal eventualidad, he decidido entrar en detalles sobre su modo de operación para que ello suponga un punto de innovación adicional en el desarrollo de este proyecto.

El software para la programación y configuración del autómata es el Unity Pro XL. Con esta herramienta se configura el hardware que forma el PLC y la programación del procesador para que ejecute las instrucciones en función del proyecto. Dentro del software Unity Pro XL podemos generar proyectos en varias familias de autómatas, como son Modicom M340, Premium, Quantum y Atrium. Todos ellos dentro de la marca Schneider Electric. Cumpliendo la norma IEC 61131-3 referente a los lenguajes de programación.

Este software permite la programación de los autómatas en los siguientes lenguajes:

 ST. - Texto Estructurado (Structured Text).

 LD.- Diagrama de Contacto (Ladder).

 IL.- Lista de Instrucciones (Instruction List).

 SFC. - Grafcet (Secuencial Funtion Chart).

Este software industrial presenta las siguientes características:

(29)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

 Está basado en formatos estándares, reduciendo sensiblemente las actividades de familiarización y capacitación.

 Presenta las herramientas necesarias para la creación, depuración y puesta en marcha de las aplicaciones.

 El entorno de ejecución de los programas es Windows 98/2000/NT/XP/7, estando adaptado a su funcionamiento gráfico y orientado a objetos.

 Su utilización es intuitiva y por lo tanto fácil.

3.2.1. Lenguaje ST

En esta guía de programación me voy a centrar en el lenguaje de texto estructurado (ST). La principal característica de este lenguaje es su gran potencia y versatilidad, siendo el más apropiado para funciones complejas y aplicaciones en las cuales sea necesario un programa optimizado. Es un lenguaje parecido al C, por tanto cualquier persona con cocimientos de programación informática es capaz de realizar aplicaciones complejas mediante el software Unity Pro.

El primer paso antes de comenzar a programar en ST es conocer la nomenclatura y funciones propias del lenguaje, siendo esto la parte más compleja de la programación.

 Operador; Define la operación a realizar

 Operando; Objeto sobre el que actúa el operador

 Instrucción de Control; Orden del programa (ej. if then else)

 Instrucción; Finalizado con punto y coma

 Comentario; Información adicional cuya sintaxis es (* …*)

 Etiqueta; Indica un bloque de programa (acabado por dos puntos)

(30)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Ilustración 3. Ejemplo 1 Programación ST

Ilustración 4. Ejemplo 2 Programación ST

La parte más importante de la barra de herramientas son las instrucciones de control.

Gracias a ellas podemos ir creando la aplicación paso a paso. Por tanto a continuación pasaremos a definirlas.

IF La instrucción IF determina que una instrucción o un grupo de instrucciones se ejecuten sólo si la expresión booleana correspondiente tiene el valor 1. Si la

Una o más instrucciones por línea Editor de texto con funciones estándar Con colores para definir

diferentes objetos

Análisis de la entrada (sintaxis y chequeo semántico)

Instrucciones de control (IF, FOR, WHILE, REPEAT, CASE)

Buscar Comentario

Llamada a subrutina

Cambiar el tamaño de la fuente

Asistente de entrada FFB Inspector

Pasar de mayúsculas a minúnculas o viceversa

(31)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

condición es 0, la instrucción o el grupo de instrucciones no se ejecuta.

IF...THEN...END_IF, ELSE y ELSIF...THEN

FOR La instrucción FOR repite una secuencia de instrucciones hasta la instrucción END_FOR. La cantidad de repeticiones se determina mediante el valor inicial, el valor final y la variable de control.

FOR...TO...BY...DO...END_FOR

WHILE La instrucción WHILE provoca la ejecución repetitiva de una secuencia de instrucciones hasta que la expresión booleana correspondiente sea 0. Si la expresión es falsa desde el principio, no se ejecuta el grupo de instrucciones.

WHILE...DO...END_WHILE

REPEAT La instrucción REPEAT provoca la ejecución repetitiva de una secuencia de

instrucciones (al menos una vez) hasta que la condición booleana correspondiente sea 1.

REPEAT...UNTIL...END_REPEAT

CASE

La instrucción CASE está compuesta por una expresión del tipo de datos INT (el

"selector") y una lista de grupos de instrucciones. Cada grupo está provisto de una etiqueta que está compuesta por uno o más números enteros (INT, DINT, UINT, UDINT) o rangos de valores de enteros. Se ejecuta el primer grupo de instrucciones cuya etiqueta contenga el valor calculado del selector. De lo contrario, no se ejecuta ninguna de las instrucciones.

CASE...OF...END_CASE

Ejemplo:

IF value < 7 THEN

WHILE value < 8 DO value := value + 1;

END_WHILE;

END_IF;

Una vez definida las instrucciones de programación, pasaré a programar los comandos necesarios para ejecutar el programa propuesto.

3.2.2. Características del Entorno Unity Pro

Unity Pro es un software común de programación, puesta a punto y explotación de los autómatas Modicom, M340, Premium, Quantum y coprocesadores Atrium. Todos ellos dentro de la marca Schneider Electric. El software Unity Pro cumple con la normativa IEC 61131-3

(32)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

referente a los lenguajes de programación y surge de la experiencia obtenida por el grupo Schneider Electric en sus anteriores softwares de programación PL7 Pro y Concept.

Unity Pro aprovecha al máximo las ventajas de los interfaces gráficos y contextuales de Windows XP y Windows 2000:

 Acceso directo a las herramientas y a los datos.

 Configuración 100% gráfica.

 Barra de herramientas e iconos personalizables.

 Funciones avanzadas de “arrastrar y soltar” y zoom.

 Ventana de diagnóstico integrado.

Ilustración 5. Software de Programación Unity Pro.

(33)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

La principal ventaja de este software de programación es la estandarización de sus códigos gracias al cumplimiento de la norma anteriormente citada IEC 61131-3, con la cual se consigue que Unity Pro proponga un conjunto completo de funcionalidades y de herramientas que permiten calcar la estructura de la aplicación en la estructura del proceso o de la máquina.

El programa se divide en módulos funcionales jerarquizados que agrupan:

 Secciones de programa.

 Tablas de animación.

 Pantallas de los operadores.

 Hipervínculos.

Unity Pro ofrece además una biblioteca de DFB (Bloques de Funciones de Usuario) ya programados como son las funciones de diagnóstico de aplicaciones, los cuales ayudan a reducir los tiempos de paradas de las instalaciones. Dichos bloques se encuentran ya integrados en el programa y, según su función, permiten vigilar las condiciones permanentes de seguridad y la evolución del proceso en el tiempo. Una ventana de visualización muestra, de forma clara y cronológicamente, con marcación de tiempo en origen, todos los fallos del sistema y de la aplicación. Desde esta ventana, se accede mediante un simple clic al editor de programa en el que se ha producido el error (búsqueda en el origen de las condiciones que faltan).

Ilustración 6. Ventana de Inspección de Proyectos.

(34)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Las modificaciones en línea pueden agruparse de manera coherente en modo local en el PC y transferirse directamente al autómata en una sola operación para que se tengan en cuenta en el siguiente ciclo de programa. Una paleta completa de funciones le permite controlar con más detalle la explotación, para reducir los tiempos de parada:

 Histórico de las acciones de los operarios en Unity Pro en un fichero protegido.

 Perfil de usuario y protección mediante contraseña.

 Pantallas gráficas de explotación integradas.

Una nueva novedad dentro del software de programación de Schneider Electric es la integración de un simulador del autómata integrado, el cual reproduce fielmente el comportamiento del programa en el PC. Todas las herramientas de puesta a punto se pueden utilizar en simulación, para aumentar la calidad antes de la instalación. Por tanto gracias a este simulador podemos llevar el código pre-depurado a la instalación, con lo cual reducimos el tiempo de parada del proceso.

 Ejecución del programa paso a paso.

 Punto de parada y de visualización

 Animaciones dinámicas para visualizar el estado de las variables y la lógica que se está ejecutando.

Ilustración 7. Simulador Virtual del PLC.

(35)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

3.2.3. Como se trabaja Unity Pro XL para crear una aplicación.

El primer paso a la hora de empezar a programar con Unity Pro XL es ejecutar el programa el cual se encuentra en el directorio del Menú Inicio:

Ilustración 8. Ruta de Arranque Unity Pro.

Una vez ejecutado el programa nos aparece la ventana principal del software de programación, en donde existen tres zonas claramente diferenciadas.

Ilustración 9. Ventana de Principal Unity Pro.

Menús y barras de herramientas

Zona de trabajo

Ventana de inspección

(36)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Una vez ya nos encontramos en la pantalla principal debemos especificar con qué modelo de autómata, dentro de la gama de Schneider Electric, vamos a trabajar. Para ello se selecciona el icono de Nuevo Proyecto para que nos aparezcan las tres familias de PLC’s que posee Unity Pro. En nuestro caso vamos a seleccionar la familia Premium, ya que es la que ha sido elegida por sus prestaciones y fiabilidad para el desarrollo de este proyecto.

Tras haber decidido que familia es la que va a desarrolla nuestra aplicación llega el momento de establecer que requisitos nos plantea nuestra aplicación. Teniendo en cuenta los siguientes factores:

 Modelo de Autómata

 Puertos necesarios de comunicación

 Memoria de programa

Con estos tres factores elegimos la CPU capaz de satisfacer nuestros requisitos. En nuestro caso hemos elegido la CPU BMX P34 2020 v2.10, ya que necesitamos un autómata modular el cual sea capaz de comunicarse vía Ethernet con los Terminales Gráficos. Además de tener un Puerto USB en el cual nos podemos conectar mediante un PC con un simple cable estándar USB.

Ilustración 10. Ventana de Elección de PLC.

(37)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Tras estos pasos se nos genera automáticamente el entorno de trabajo. Donde su principal característica es la ventana del Explorador de Proyectos. En donde podemos configurar la aplicación y acceder a las distintas ventanas del proyecto.

Ilustración 11. Explorador de Proyectos.

Configuración de hardware

Tipos de bloques función usuario

Estructura del programa Tipos de variables

estructuradas

Secciones del programa

Subrutinas del programa

Tabla de animación Variables elementales

e instancias de bloques de funciones

Configuración de redes

Documentación

(38)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

3.2.4. Configuración del Hardware en Unity Pro XL

Una vez dentro del Explorador de Proyectos el primer paso es definir el Hardware con el que vamos a trabajar. Es decir, necesitamos instalar los diferentes módulos en el Rack donde está ya colocada la CPU que elegimos anteriormente y una Fuente de Alimentación instalada automáticamente por el programa como también colocó un Rack de 8 Slots.

Podemos observar que el Rack está dividido en varios Slots, numerados del 0 al 7 por defecto. La primera posición del Rack estará ocupada por la CPU y a continuación se dispondrán las tarjetas necesarias. Este orden siempre deber de ser seguido en la configuración del hardware, ya que si no lo tenemos en cuenta al compilar la aplicación, obtendremos un error.

Ilustración 12. BUS 0 de 8 Slots.

Puerto de Comunicación ModBus

Slot Bastidor

Puerto de Comunicación Ethernet

Puerto de Comunicación USB Procesador (CPU)

Fuente de alimentación

(39)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Podemos modificar esta configuración en todos los aspectos. Añadiendo un Rack mayor, o un segundo Rack. Módulos Binarios, Analógicos, Conteo, Pesada o de Comunicación.

En el ejemplo se ha añadido un 2º Rack de 4 Slots con una nueva Fuente de Alimentación la cual alimenta todas las tarjetas integradas en el bus del Rack. Ahora pasaremos a enumerar las tarjetas del ejemplo:

 Fuente de alimentación 35W de CA alta potencia BMX CPS 3500

 CPU BMX P34 2020

 16 salidas digitales BMX DRA 1605

 16 entradas digitales de común negativo de 24V CA/ 24 V DC BMX DAI 1602

 8 entradas analógicas U/I con separación de potencial BMX AMI 0810

 8 salidas de corriente analógicas no aisladas BMX AMO0802

 16 entradas digitales 24V común positivo BMX DDI 1602

 4 entradas TC/RTD con separación de potencial BMX ART 0414

 8 entradas TC/RTD con separación de potencial BMX ART 0814

 Contador genérico de 8 canales BMX EHC 0800

 Módulo V3 de comunicación AS-i BMX EIA 0100

Ilustración 13. Configuración Hardware BMX M340.

(40)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

3.2.5. Tipos de variables en Unity Pro XL

Una vez que se tenga configurada la parte hardware del equipo se pasará a la programación del autómata. Para ello es preciso definir las variables tanto de entrada como de salida. Además de definir el tipo de variables que son:

BOOL

Sigla del tipo booleano. Se trata del elemento de datos de base en informática.

Una variable de tipo BOOL posee uno de estos valores: 0 (FALSE) o 1 (TRUE). Un Bit extraído de la palabra es de tipo BOOL, por ejemplo: %MW10.4.

DATE

El tipo DATE codificado en BCD en un formato de 32 bits que contiene esta información:

 El año codificado en un campo de 16 bits

 El mes codificado en un campo de 8 bits

 El día codificado en un campo de 8 bits

El tipo DATE debe introducirse así: D#<Año>-<Mes>-<Día>

DINT

Sigla del formato Double INTeger (entero doble) (codificado en 32 bits). Los límites inferior y superior figuran a continuación: de -(2 elevado a 31) a (2 elevado a 31) - 1.

Ejemplo: -2.147.483.648, 2.147.483.647, 16#FFFFFFFF.

DT

Sigla de Date and Time (fecha y hora).

El tipo DT, codificado en BCD en un formato de 64 bits, contiene esta información:

 El año codificado en un campo de 16 bits

 El mes codificado en un campo de 8 bits

 El día codificado en un campo de 8 bits

 La hora codificada en un campo de 8 bits

 Los minutos codificados en un campo de 8 bits

 Los segundos codificados en un campo de 8 bits

Nota: No se utilizan los 8 bits menos significativos. El tipo DT debe introducirse así:

DT#<Año>-<Mes>-<Día>-<Hora>:<Minutos>:<Segundos>

DWORD Sigla de Double Word (palabra doble). El tipo DWORD se codifica en un formato de 32 bits.

EBOOL

Sigla del tipo Extended BOOLean (booleano extendido). Una variable de tipo EBOOL posee el valor 0 (FALSE) o 1 (TRUE), pero igualmente los flancos ascendentes o descendentes y las funciones de forzado.

Una variable de tipo EBOOL ocupa un byte de memoria.

El byte se compone de los siguientes elementos:

 Un bit del valor

 Un bit del historial (cada vez que cambia el objeto de estado, el valor se copia en el bit del historial)

 Un bit del forzado (igual a 0, si el objeto no se fuerza, igual a 1 si el bit se fuerza)

 El valor predeterminado de cada bit es 0 (FALSE).

(41)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

INT

Sigla del formato single INTeger (entero simple) (codificado en 16 bits). Los límites inferior y superior figuran a continuación: de -(2 elevado a 15) a (2 elevado a 15) - 1.

REAL

El tipo REAL (real) es un tipo codificado en 32 bits.

Los rangos de valores posibles se detallan a continuación:

Cuando un resultado:

 Esta comprendido entre -1,175494e-38 y 1,175494e-38, se le considera como DEN;

 Es inferior a -3,402824e+38, aparece el símbolo -INF (de -infinito);

 Es superior a +3,402824e+38, aparece el símbolo INF (de +infinito);

 Está indefinido (raíz cuadrada de un número negativo), aparece el símbolo NAN

STRING Una variable de tipo STRING es una cadena de caracteres ASCII. La longitud máxima de una cadena de caracteres es de 65.534 caracteres.

TIME

El tipo TIME expresa la duración en milisegundos. Codificado en 32 bits, este tipo permite obtener duraciones de 0 a 2 ³²-1 milisegundos. Las unidades de tipo TIME son las siguientes: días (d), horas (h), minutos (m), segundos (s) y milisegundos (ms). Un valor literal de tipo TIME se representa mediante una combinación de tipos anteriores que preceden a T#, t#, TIME# o time#. Ejemplos: T#25h15m, t#14,7S,

TIME#5d10h23m45s3ms

TOD

Sigla de Time Of Day (hora del día).

El tipo TOD, codificado en BCD en un formato de 32 bits, contiene esta información:

 La hora codificada en un campo de 8 bits

 Los minutos codificados en un campo de 8 bits

 Los segundos codificados en un campo de 8 bits

Nota: No se utilizan los 8 bits menos significativos. El tipo Time Of Day debe introducirse así: TOD#<Hora>:<Minutos>:<Segundos>

UDINT

Sigla del formato Unsigned Double INTeger (entero doble sin signo) (codificado en 32 bits). Los límites inferior y superior figuran a continuación: de 0 a (2 elevado a 32) - 1.

Ejemplo: 0, 4.294.967.295, 2#11111111111111111111111111111111, 8#37777777777, 16#FFFFFFFF.

UINT

Sigla del formato Unsigned INTeger (entero sin signo) (codificado en 16 bits). Los límites inferior y superior figuran a continuación: de 0 a (2 elevado a 16) - 1.

Ejemplo: 0, 65.535, 2#1111111111111111, 8#177777, 16#FFFF.

WORD El tipo WORD se codifica en un formato de 16 bits y se utiliza para realizar tratamientos en las cadenas de bits.

(42)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Para definir las distintas variables hacemos doble clic sobre el icono de la carpeta de Variables e instancias FB. Inmediatamente se nos abrirá una nueva ventana en donde nos aparecerán distintas pestañas las cuales ya nombramos anteriormente y que hacen mención a los tipos de datos y bloques de funciones derivadas, además de a las variables e instancias.

El primer paso a la hora de definir las variables es escribir el nombre, sin dejar espacios, de cada variable y posteriormente ir añadiendo los siguientes parámetros. Sin necesidad de seguir ningún orden en esos parámetros:

 Nombre

 Tipo

 Dirección

 Valor

 Comentario

Ilustración 14. Editor de Datos.

(43)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Es preciso mencionar que no es estrictamente necesario establecer las variables al comienzo del proyecto, del mismo modo que tampoco es necesario definirles las direcciones.

Podemos ir incluyendo variables a la vez que las vamos necesitando en la programación. Al igual que podemos definir las direcciones de las variables al concluir la programación y antes de transmitirla al autómata.

Respecto a las direcciones se debe conocer cuáles son los tipos y características de cada unas de ellas para poder implementar mejor el desarrollo del programa de forma que podamos reducir el tiempo de ciclo y por tanto optimizar el rendimiento de la instalación. Para ello vamos a pasar a definir los tipos de direcciones que existen y que tipo de información son capaces de gestionar y transmitir. Además de describir a qué tipo de elemento está asociada cada dirección.

Lo primero que cabe destacar es la nomenclatura a seguir para definir las direcciones.

Todas empiezan por el símbolo % seguidas de una letra inicial según al tipo de dirección que vayamos a gestionar. Todos los tipos de variables están definidas según la norma IEC 61131–3.

El propósito de dicha norma es estandarizar la programación de PLC’s según el proceso y no el fabricante. Esto quiere decir, que el código creado según esta norma en el software Unity Pro XL de Schneider Electric es totalmente exportable al software de cualquier otro fabricante, el cual también cumpla esta norma como puede ser el caso de Siemens con su software de programación STEP – 7.

Estas son los distintos tipos de direcciones del autómata y su descripción:

%I Indica un objeto de lenguaje de entrada binario.

%W Indica un objeto de lenguaje de entrada analógico.

%KW Indica un objeto de lenguaje de palabra constante.

%M Indica un objeto de lenguaje de bit de memoria.

%MW Indica un objeto de lenguaje de palabra de memoria.

%Q Indica un objeto de lenguaje de salida binaria.

%QW Indica un objeto de lenguaje de salida analógica.

(44)

Diseño, planificación y desarrollo del sistema de extensión de alarmas de un buque tipo quimiquero de 119 m. de eslora y 12000 TPM

Podemos observar que el grupo de tipos de variables se distinguen básicamente en dos según el área de memoria que necesita el autómata para procesarla. Por una parte están las direcciones puramente digitales cuyos valor es binario, solo puede tener dos posiciones 1 o 0. Y por otro lado están las palabras cuya dimensión es de 16 bits, las cuales pueden ser por ejemplo una entrada analógica recibida desde una PT100, la cual nos expresa el valor numérico de la temperatura.

Por último, nos centraremos ahora un unos bits y palabras del sistema antes no mencionados, pero que son de gran utilidad e importancia a la hora tanto de programar como de depurar la programación en busca de errores y estados del autómata. A continuación pasaremos a nombrarlos y definirlos brevemente:

%S0 Arranque en Frió. Normalmente en 0. Este bit se define a 1 durante el primer ciclo completo de restauración del PLC en modalidad RUN o STOP. El sistema lo

restablece a 0 antes del ciclo siguiente.

%S1 Reinicio en caliente. El sistema lo restablece a 0 al final del primer ciclo completo y antes de actualizar las salidas.

%S4 Base de tiempo 10 ms. Un temporizador interno regula el cambio de estado de este bit.

%S5 Base de tiempo 100 ms. Un temporizador interno regula el cambio de estado de este bit.

%S6 Base de tiempo 1 s. Un temporizador interno regula el cambio de estado de este bit.

%S7 Base de tiempo 1 min. Un temporizador interno regula el cambio de estado de este bit.

%S11 Desborde del Watchdog.

%S12 PLC en RUN. El sistema pone este bit a 1 cuando el PLC está en RUN.

%S13 Primer ciclo después de la puesta en RUN.

%S15 Fallo de cadena de caracteres. Se pone a 1 cuando en una transferencia de cadena de caracteres no tiene el tamaño suficiente.

%S17 Salida de desplazamiento o giro.

%S18 Desborde o error aritmético.

%S19 Desborde del periodo de tarea (exploración periódica)

%S20 Desborde de índice. Pasa a 1 cuando la dirección del objeto de índice sea menor que 0 o supere el número de objetos declarados en la configuración.

%S30 Activación / Desactivación de la tarea maestra. Normalmente a 1 con la tarea activada.

%S31 Activación / Desactivación de la tarea rápida. Normalmente a 1 con la tarea activada.