ORGANIGRAMA DE UN PROYECTO INDUSTRIAL

Nota: El objetivo de este artículo es que el lector, descubra que puesto de trabajo le gustaría desempeñar, (o lo que es más importante, que puesto de trabajo no le gustaría desempeñar) durante las fase de diseño y construcción de una planta industrial.

Este texto, complementa al artículo “organigrama de una ingeniería industrial” (Pulsar aquí para acceder a dicho enlace).

En el artículo “organigrama de una ingeniería industrial”,  se expuso las distintas funciones y roles, que puede ejercer un ingeniero dentro de una empresa de ingeniería. Sin embargo este trabajo “Organigrama de un proyecto”, explica las funciones que desempeña cada trabajador dentro de un proyecto.

Ambos artículos se complementan.

Es imprescindible entender, la posición que ocupa cada trabajador en estos dos organigramas: “Desde el punto de vista empresa” y “desde el punto de vista del proyecto”.

1. INTRODUCCIÓN

2. DIRECCIÓN
  2.1. Director del proyecto
  2.2. Responsable de planificación
  2.3. Responsable de costes
  2 3. Responsable de compras
  2.4. Responsable de ingeniería
  2.5. Ingenieros de proyecto
  2.6. Responsable de seguridad
  2.7. Responsable de construcción
  2.8. Responsable de calidad

3. ORGANIGRAMA DE LA INGENIERÍA EN UN PROYECTO

4. ORGANIGRAMA DE OBRA EN UN PROYECTO
  4.1 Oficina técnica en obra
  4.2. Equipo de construcción
     4.2.1. “El Constructor Manager”
     4.2.2. “Site Manager”
     4.2.3. “Responsable de de prevención y responsable de calidad”
     4.2.4. “Responsables de planificación en obra”
     4.2.5. “Responsables de costes en obra”
     4.2.6. “Responsable del almacén”
     4.2.7. “Superintendente”
     4.2.8. “Supervisores”
  4.3. Equipo de comsionado y puesta en marcha

-------------

1. INTRODUCCIÓN

Antes de comenzar una obra industrial se debe de realizar, “el organigrama del proyecto”. En este esquema, se establecen las competencias y jerarquía de todo el equipo humano que intervendrá en el proyecto.

Los organigramas de los proyectos suelen tener elementos comunes, pero lo habitual es que cada organigrama esté adaptado a las peculiaridades de cada proyecto. Según cada caso, pueden desaparecer o surgir nuevas figuras dentro del organigrama, o cambiarse las responsabilidades de algunas posiciones.

Algunas consideraciones a tener en cuenta a la hora de definir el organigrama de un proyecto industrial, serán: Organigrama de las empresas que intervienen, tipo de proyecto, planificación, alcances, recursos disponibles, país donde se ejecuta la obra, requisitos del cliente, etc…

Un proyecto industrial, es el resultado de la ejecución en obra del trabajo realizado por la ingeniería bajo la supervisión y gestión de la dirección del proyecto.

Inicialmente se va a dividir el organigrama de un proyecto en tres partes: DIRECCIÓN, INGENIERÍA Y OBRA.

Nota: A continuación, mostraremos un ejemplo de un organigrama, en un hipotético proyecto industrial, pero se debe tener en cuenta que, “es solo un ejemplo”. En la práctica cada caso será diferente.

2. DIRECCIÓN

Jerárquicamente, dirección de proyecto, se sitúa en la parte superior de la pirámide.

Las funciones principales de la dirección son: organizar y gestionar los recursos para que el proyecto se ejecute en el plazo y con el coste previsto.

2.1. Director del proyecto

En cabeza de este grupo, está el cargo del “director del proyecto”, esta figura ocupará la posición más alta del organigrama.

El director del proyecto podrá tomar en última instancia parte, en cualquier decisión que afecte al proyecto, cuando lo considere necesario.

Debajo del director del proyecto, nos encontraremos el resto del personal que forma dirección de proyecto.

2.2. Responsable de planificación

El responsable de planificación debe vigilar el bien más preciado que tenemos: “EL TIEMPO”.

Está cargo puede ser desempeñada por una o varias personas.

Su función es asegurarse que el proyecto cumple los plazos establecidos, revisando la planificación según los imprevistos que vayan surgiendo.

2.3. Responsable de costes

El responsable de costes, vigilarán el segundo bien más preciado en un proyecto: “EL DINERO”.

Deben hacer un seguimiento continuo de los gastos analizando y alertando en las desviaciones, y revisando las  previsiones.

2.3. Responsable de compras

El responsable de comprar, debe de gestionar la compra de los equipos.

Una gestión adecuada de esta actividad, tendrá un impacto muy significativo en los costes totales.

Uno de los requisitos para este puesto, es una gran capacidad de negociación.

Del responsable de compras suele depender, el equipo de compras. Que puede estar formado por, los encargados de logística, activación, inspección y compradores.

2.4. Responsable de ingeniería

Se encarga de coordinar el trabajo realizado por la ingeniería, principalmente debe asegurarse que los departamentos se coordinen correctamente y que el trabajo cumple con los requisitos del cliente.

2.5. Ingenieros de proyecto

Cuando un proyecto es muy grande, el director de proyecto no puede intervenir diariamente en todas los asuntos, por lo que se suele dividir el proyecto en áreas y delegará sus funciones en los ingenieros de proyectos.

A medida que el proyecto avance, los ingenieros de proyecto, empezarán a estar menos tiempo en la oficina y más en la obra.

2.6. Responsable de seguridad

Por parte de la dirección,habrá un responsable de la seguridad del personal, que se encargará de coordinar y controlar, todas las actividades relacionadas, con la seguridad, tanto de la oficina, como en la obra.

2.7. Responsable de construcción

La adecuada gestión, para llevar a cabo las distintas fases de la construcción, es sin duda uno de los puntos clave, para el cumplimiento de la planificación y del presupuesto inicial.

Este cargo requiere de tener un contacto continuo con el personal desplazado en obra, concretamente con la figura del “Constructor Manager” (máximo responsable de la construcción en obra).

2.8. Responsable de calidad

Está figura se encarga de vigilar que se siguen los requisitos de calidad en el proyecto, tanto en la oficina como en obra, ordenando  las acciones correctores oportunas.

3. ORGANIGRAMA DE LA INGENIERÍA EN UN PROYECTO

En los grandes proyectos industriales, lo habitual es que el personal de ingeniería se ubique inicialmente en el “Task-force” del proyecto.

Nota: Un “task-force” es un emplazamiento, delimitada para uso exclusivo del personal involucrado en un determinado proyecto.

A medida que el proyecto avanza  y comienzan la actividad en obra, parte del personal tanto de dirección como de ingeniería, irán poco a poco desmovilizándose a un emplazamiento a pie de obra, desarrollándose así una “oficina técnica en obra”.

Como se ha mostrado en el punto anterior, ingeniería dependerá principalmente de: El director de proyecto, de los ingenieros de proyecto y del responsable de ingeniería.

Todas las actividades a realizar en ingeniería, se repartirán por departamentos. En cada departamento habrá un líder encargado de dirigir al resto.

A su vez en cada departamento puede haber un grupo de proyectistas y diseñadores asignados al departamento, este equipo suele estar a su vez coordinado por un líder de diseño.

4. ORGANIGRAMA DE OBRA EN UN PROYECTO

Hay tres equipos desplazados en obra:

1º- La oficina técnica en obra.

2º- Equipo de construcción.

3º- Equipo de puesta en marcha.

Nota: El choque de interese entre estos tres grupos hace que la relación entre todos sea normalmente delicada.

4.1. Oficina técnica en obra

Como se expuso en con al el punto anterior, son los representante de la ingeniería en obra.

Normalmente, es personal que ha empezado el proyecto en la oficina y a medida que ha ido transcurriendo el proyecto se han ido movilizando a obra.

Su papel principal es asegurarse de que en la obra se esté trabajando con la últimas revisiones de los documentos elaborados por la ingeniería.

Deben ser capaces de resolver eficientemente, todas las dudas que surjan durante la ejecución del proyecto.

Este equipo puede estar constituido por personal de todos los departamentos (ingenieros o proyectistas).

Nota: Si usted está trabajando en una ingeniería y le han propuesto desplazarse a obra, le recomiendo que lea antes el siguiente enlace. "Pulsar aquí"

4.2. Equipo de construcción

El equipo de construcción está formado por todo el equipo humano involucrado en la fase de construcción.

Las dos figuras situadas en la parte superior de la pirámide son: “El Constructor Manager” y “El Site Manager”

4.2.1. “El Constructor Manager”

Es el principal responsable (en obra) de la fase de construcción.

Este trabajo suele de requerir de unas características particulares, entre las que se destaca: una gran capacidad de trabajo, un fuerte carácter y mucha experiencia. 

Su función principal es dirigir la obra apoyándose en el trabajo desarrollado por la ingeniería.

Sus decisiones están condicionadas por las directrices que le marcan desde dirección general, concretamente desde el responsable de construcción o el director del proyecto.

4.2.2. “Site Manager”

A lado del constructor manager está la figura del Site Manager. 

Su función es encargarse de todos los asuntos que surjan, para que el constructor manager pueda centrarse en los aspectos puramente constructivos.

Su principal característica, es tener la mano izquierda que le puede faltar al constructor manager.

Estudiará los contratos, tratará con el cliente, con la ingeniería y demás partes implicadas.

4.2.3. “Responsable de de prevención y responsable de calidad”

-“El Responsable de Calidad”, supervisa los certificados exigidos y el cumplimiento de los procedimientos requeridos por el cliente en el contrato. Suele disponer de un equipo de técnicos especializados en cada materia que comprobarán equipo por equipo que la documentación es acorde a lo que está finalmente instalado.

-“El Responsable de Prevención”, debe perseguir el cumplimiento de las normas establecidas de seguridad para proteger a todos los trabajadores involucrados.

4.2.4. “Responsables de planificación en obra”

Esta figura supervisa el cumplimiento de la planificación en obra.

Reportará las desviaciones al “Constructor Manager”, al “Site Manager” y al responsable de la planificación en la dirección.

4.2.5. “Responsables de costes en obra”

El responsable de costes, vigilarán que los gastos se mantengan dentro de los margenes previstos en el presupuesto.

4.2.6. “Responsable del almacén”

Se encargará de recepcionar los equipos en obra, comprobando que el equipo ha llegado en perfecto estado y con todos los elementos esperados.

Una vez recepcionado, lo registrará y lo guardará de forma accesible para poder ubicarlo rápidamente, cuando sea necesario.

Una gestión adecuada del almacén evitará muchos problemas durante la fase de construcción.

4.2.7. “Superintendente”

Los superintendentes son los brazos ejecutores del “Constructor Manager”.

Normalmente habrá un superintedente por disciplina (mecánica, electricidad, tuberías, instrumentación & control, civil) y se encargarán de los trabajos asociados a su departamento, se ejecuten adecuadamente.

4.2.8. “Supervisores”

A las órdenes de cada superintendente habrá varios supervisores.

Los supervisores siguen las indicaciones de los superintendentes y se las transmitirán a los subcontratistas.

Los subcontratistas, son las empresas contratadas para ejecutar las tareas de construcción. 

Cada subcontrata, tiene un encargado que se encarga de dirigir a su personal.

4.3. Equipo de comisionado y puesta en marcha

Una vez que el equipo de construcción termina un sistema, es recepcionado por el equipo de comisionado y puesta en marcha, que se encargarán de poner el equipo en servicio  .

"Pulsar aquí" Para ver otros artículos publicados

Elaborado por: Julio César Fernández Losa 28/02/2016

Si tiene algo que corregir o añadir agradecería que me mandara sus comentarios a:

InstrumentacionHoy@gmail.com

DOCUMENTOS NECESARIOS PARA DESARROLLAR LA LÓGICA DE CONTROL (2ª parte)

Nota: Este artículo, es la continuación de “INICIACIÓN AL DISEÑO DE LA LÓGICA DE CONTROL EN PLANTAS INDUSTRIALES (1ª parte)” si aún no ha leído la primera parte, le aconsejamos ir primero al siguiente enlace “Pulsar aquí”

Al final de cada artículo, se han incluido los enlaces, que llevan a los siguientes niveles. 

Tras finalizar cada parte, se recomienda a los lectores, aposentar y reflexionar sobre los conceptos tratados, antes de pasar al siguiente nivel.

2. DOCUMENTOS NECESARIOS PARA DESARROLLAR LA LÓGICA DE CONTROL

2.1. Lista de documentos

2.2. Lista de equipos

2.3. Típicos lógicos (macros o bloques de función)

2.4. Lista de señales

2.5. Descripción de la Lógica de Control

2.6. Diagramas Lógicos de Control

2.7. Lista de señales lógicas, enclavamientos, señales del SCADA, alarmas y disparos

-------------------------------------------- 

2. DOCUMENTOS NECESARIOS PARA DESARROLLAR LA LÓGICA DE CONTROL (2ª parte)

2.1. Lista de documentos

Para desarrollar la lógica de control de una planta industrial, proponemos elaborar los siguientes documentos, en el siguiente orden: 

- Lista de equipos

- Típicos lógicos

- Lista de señales cableadas

- Lista de señales para bus de campo

- Lista de señales comunicadas

- Descripción de la lógica de control

- Lógica de control

- Lista de enclavamientos y disparos

- Lista de alarmas 

Nota: Esto es solo un ejemplo, no tienen por qué elaborarse exactamente estos documentos, ni en este orden.

2.2. Lista de equipos 

El primer paso, para desarrollar la lógica de control, es conocer los equipos que tenemos que controlar. Para ello, se puede empezar por, elaborar una lista, y así poder contabilizarlos.

2.3. Típicos lógicos (macros o bloques de función)

Los típicos lógicos (también llamados macros o bloques de función), cumplen un papel crucial en el desarrollo de la lógica de cualquier proyecto industrial. 

Su objetivo es, estandarizar y simplificar el control. 

Un típico lógico es la programación que se realizará a un grupo de equipos, que tengan unas características similares. 

De esta forma, cada vez que se tenga que configurar un nuevo equipo, no hay que perder el tiempo en discutir sobre que señales debe tener y como configurarlo, porque gran parte de este trabajo, ya estará definido en los típicos que se han diseñado y aprobado previamente.

A partir del desarrollo de los “lógicos de control”, los equipos serán representados en la lógica como una cajita en la que por la izquierda le entrarán unas señales y por la derecha enviará unas respuestas.

Nota: Al igual que el resto de la lógica de control, los típicos lógicos es algo programado en un controlador, este documento representa un concepto virtual.

2.4. Lista de señales

Si sabemos los equipos que tenemos, y hemos asociado un típico lógico a cada equipo, se podrán saber cuántas señales se necesitarán.

Por ejemplo, si hay 10 motores de baja tensión, y en el “típico de control”, se ha definido, que en cada motor de baja se tendrán dos entradas y dos salidas digitales, entonces: para los motores de baja se necesitará: “10 x 2 = 20 Entradas Digitales” y “10 x 2 = 20 Salidas Digitales”. 

En base a esta información, se desarrolla la lista de señales. En la lista de señales, cada señal se nombrará con un código, siguiendo el criterio de codificación establecido para el proyecto. 

Nota: No tiene por qué haber una sola lista, se podrían desarrollar varias listas de señales. Por ejemplo se podría elaborar, primero “las señales cableadas”, segundo “las señales de buses de campo” y tercer “las señales comunicadas”. Lo importante es, que en algún documento, debe estar cada señal de la planta (analógicas y digitales, entradas y salidas o comunicadas y cableadas).

Todos estos listados, engloban los inputs y outputs de nuestra "lógica de control".

2.5. Descripción de la Lógica de Control

Este, es el documento explicativo de la lógica que se desea programar. 

En este documento, se intenta explicar, cómo se pretende que funcionen y respondan los equipos, ante las distintas situaciones posibles. 

No todos los proyectos se rigen por las mismas directrices, en muchos proyectos no existe un documento de descripción de lógica, y en otras ocasiones, podría existir este documento, pero no desarrollar los diagramas lógicos de control.

En caso de no disponer de diagramas de control, será el programador el que directamente, lo desarrolla y lo integre en el sistema de control. 

Hay distintas formas de desarrollar la descripción de la lógica de control, por ejemplo, mediante una tabla (matriz causa-efecto), o mediante una descripción detallada (estrategia de control)… etc. 

Siga el formato que sea, en última instancia, se indicaría para cada equipo del proyecto, algo parecido al siguiente ejemplo: 

El motor “X”: 

-Tendrá permisivo de arranque cuando, … la presión de la línea, sea superior a… y …

-Se provocará un disparo por protección, cuando… 

-Arrancará en automático cuando, … y si se cumple, que… 

-Y además….

Nota: ¿Quién? y ¿cómo? se desarrolla este documento, depende de lo que se haya establecido para cada proyecto.

Por ejemplo, podría ser desarrollado por el departamento de instrumentación, en base a los comentarios indicados por procesos.

El problema es, que es difícil formalizar por escrito, todo lo establecido y acordado en dichas reuniones. Porque tras intentar prever todas las posibilidades del proceso, se llegan a conclusiones, que más tarde puede que ninguno recuerde. 

Se debe tener en cuenta, que modificar la lógica de control, puede suponer uno de los mayores gastos en horas de ingeniería para el departamento de instrumentación y control.

Como se ha mencionado en el anterior punto, no en todos los proyectos se desarrolla la “descripción de la lógica de control” y/o los “diagramas lógicos de control”. Depende de las necesidades de cada caso.

Por ejemplo, en mucho de los lazos de control de los proyectos de Oil&Gas, son lazos relativamente sencillos, y se pueden definir en una matriz causa efecto o en un documento descriptivo.

Sin embargo, en muchos de los proyectos de plantas de energía, la lógica de los lazos de control, es mucho más enrevesada, interviniendo un lazo con otro, por lo que un documento descriptivo, quizás no sea suficiente para especificarla correctamente. En estos casos, se podría requerir que se desarrolle, unos diagramas lógicos de control, elaborados por la ingeniería. 

Las empresas de programación ofertarán más caro realizar la programación de los controladores, si las ingenierías no han desarrollado los lógicos de control. Por otro lado, desarrollar la lógica de control, supone para las ingenierías, un consumo muy alto de horas, debido principalmente, a la falta de formación y organización.

2.6. Diagramas Lógicos de Control

Una vez tenemos claro, que tenemos que controlar, y como lo vamos a hacer. Podemos proceder al desarrollo de los “diagramas lógicos de control”. 

A través de este documento, la ingeniería especificará, de forma detallada, como se debe programar, la lógica en el sistema de control de la planta. 

Los diagramas lógicos, se elaboran usando unos gráficos sencillos, que representa a las distintas puertas lógicas y funciones (que veremos más adelante en detalle).

En función del alcance del proyecto, este documento podría ser realmente extenso. Para hacerlo más amigable, se suele dividir en varios sistemas (por ejemplo: sistemas mecánicos y sistemas eléctricos).

Cada uno de estos documentos, tendrán una portada, un índice, plano de simbología general y los diagramas de lógica.

Ejemplo de diagrama lógico:

En la izquierda del dibujo, se pueden ver las señales de entrada al lógico de control. A la derecha veremos las salidas. Y en el medio la lógica de control.

En este ejemplo, se ha marcado con un redondel gris, las señales que corresponden a señales eléctricas de entrada o salida de las tarjetas. El resto de señales, son señales programadas en la lógica (señales puramente virtuales: enclavamientos, alarmas…).

En las señales generadas en la lógica, es común indicar, en que página de la lógica, se han generado o a donde van.

Nota: En este artículo, se está representando las líneas en rojo, cuando el valor de la variable que representa dicha línea es “0”. En verde, cuando el valor de la variable es “1”. Y en azul, cuando es un valor analógico. Aunque, en los diagramas lógicos esto no se representaría, en este artículo se está mostrando así, para intentar facilitar al lector, un mejor entendimiento de los conceptos aquí expuestos.

2.7. Lista de señales lógicas, enclavamientos, señales del SCADA, alarmas y disparos

Durante el desarrollo de la lógica, se suelen generar unas señales, que no tienen por qué materializarse, en señales de salida eléctricas. Estas señales, son solamente señales virtuales, que se utilizarán en distintos puntos de la lógica, y permitirá optimizar y simplificar, los diagramas lógicos.

- Señales lógicas: También denominadas por los programadores como “flags” o “banderas”, se programan en alguna página de la lógica, y se usarán, todas las veces que se necesiten.

Un tipo de señal lógica especial, son los “enclavamientos”, se programan en alguna página de la lógica, y se usarán todas las veces que se necesiten. Este tipo de señal, una vez activada, no se desactivará hasta que otra señal específica la rearme (para la programación de los enclavamientos, se usarán biestables tipo “Set-Reset”, que se detallarán en el siguiente artículo)

En este ejemplo, el enclavamiento, es rearmado por una señal generada por el SCADA, desde una de las pantallas de operación. Representaremos las señales generadas desde el SCADA, con un redondel dentro de un cuadrado gris.

-Señales del SCADA: El“SCADA”, es una aplicación (software) instalada en los ordenadores (llamados puestos de operación), ubicados en la sala de control (donde se sientan los operadores de la planta), y a través de dicha aplicación, se puede llegar a supervisar y controlar, prácticamente toda la planta industrial. Estos puestos de operación, intercambian información con los servidores, que a su vez intercambia información con los controladores.

Las señales generadas desde el SCADA, son señales virtuales, pero no son generadas en los controladores del DCS, estas señales, son generadas desde la aplicación SCADA, instalada en los ordenadores de los puestos de operación, desde aquí, son enviadas a los servidores, y de los servidores son enviadas a los controladores.

En su mayoría, estas señales, las genera el software del SCADA cuando el operador, pulsa algún botón virtual representado en su pantalla de operación.

Las señales generadas desde el SCADA, suelen configurarse como pulsos. Pero podrían configurarse, como señales que se mantengan activadas. En este artículo, para representar la configuración de una señal tipo pulso, usamos el siguiente gráfico.

En el SCADA, se representan los equipos y los valores, recogidos por la instrumentación de campo.

Es muy común, ver en cada pantalla del SCADA, botones con funciones especiales que intervendrán en el proceso.

Además de estos botones, cuando se pulse con el cursor del ratón sobre un equipo, como por ejemplo, un motor, suele surgir un pequeño “faceplate”, que permitirá al operador, actuar directamente sobre el control de dicho equipo. 

Nota: No se debe perder la perspectiva, de que en el SCADA no está la lógica de control, el SCADA es solo un interfaz gráfico. La lógica de control, está configurada en “los controladores”, instalados en los armarios de control.

-Alarmas: Cuando ocurran una serie de circunstancias especificadas, se activarán las alarmas.

Las alarmas, generan vía software un aviso directo al operador de planta. Estas alarmas, han sido establecidas previamente en las descripciones funcionales.

Tres consejos, sobre las alarmas: 

1º Si la alarma no es necesaria, eliminarla de la programación. El exceso de alarmas, repercutirá negativamente en la seguridad y control de la planta. Si un operador recibe continuamente muchas alarmas, le resultará más difícil poder discernir entre las que son importantes y las que no. (Como la fábula de que viene el lobo) 

2º Establecer niveles e indicar la prioridad de cada alarma. Aunque fueran pocas el número de alarmas activadas, es aconsejable que estén establecidos unos niveles de prioridad a cada una, de forma que el operador, pueda discernir rápidamente, que alarmas son prioritarias frente a otras. 

3º Describir correctamente las alarmas desde el principio del proyecto, bien sea con la ayuda de un operador, o siguiendo las recomendaciones de gente con más experiencia. Revisar minuciosamente las descripciones de cada una de las alarmas, evitará consumir un tiempo vital, durante el cierre del proyecto (punch-list).

-Permisivos: Estas señales, indican si se dispone de todas las condiciones que permiten realizar una determinada acción sobre el control.

Por ejemplo “Permisivo de marcha manual” (del motor “A”):

Cuando el operador, pulse el botón de “MARCHA” de un motor (desde el face-plate del SCADA), el motor no se pondrá en marcha, si no tiene activada, la señal de “Permisivo de marcha manual”.

Para que dicha señal estuviera activada, por ejemplo podría requerir:

1º-Que esté activada, el modo manual del motor.

2º-Que la alimentación eléctrica del motor, esté correcta.

3º-Que no esté activado, el disparo por protección del motor.

Hasta que no se cumplan, estas tres condiciones, por mucho que pulse el operador encima del botón (del faceplate), la lógica de control no permitirá arrancar el motor.

Nota: En este ejemplo, al no tener permiso de marcha manual, en el “faceplate” se podría representar el botón de color más claro, indicando que está deshabilitado.

-Disparos: Los disparos, son señales lógicas un poco especiales, provocan paros, o fuerzan a los equipos a quedar enclavados, en posición de seguridad.

Los disparos, son causados por anomalías no esperadas, y en caso de activarse, suelen activar una alarma, y dejar enclavados en situación de seguridad, los equipos, al margen de que estén en modo manual o automático.

“Pulsar aquí, para ir a: FUNCIONES LÓGICAS PARA DISEÑAR EL CONTROL (3ª parte)

-----------------

Resumen de los enlaces de artículo relaccionados:

INICIACIÓN LÓGICA DE CONTROL EN PLANTAS INDUSTRIALES (1ª parte)
DOCUMENTOS PARA LA LÓGICA DE CONTROL (2ª parte)
FUNCIONES LÓGICAS (3ª parte)
DESARROLLO Y APLICACIÓN DE LOS TÍPICOS LÓGICOS (4ª parte)
EJEMPLOS DE LÓGICA DE CONTROL EN PLANTAS INDUSTRIALES (5ª)

Elaborado por: Julio César Fernández Losa 02/02/2016 

Si tiene algo que corregir o añadir agradecería que me mandara sus comentarios a: 

InstrumentacionHoy@gmail.com