Analizar un problema, del tipo que sea, desde una perspectiva local o reducida, lógicamente puede ser conveniente en algunos casos, por ejemplo para el caso nuestro (alumnos), estaría justificado temporalmente atendiendo a criterios formativos, pero ¿es correcto?¿puede ser definitivo?¿podemos dar solución a ese problema si no tenemos una visión global?¿podemos dar una solución correcta al problema?.
Desde mi punto de vista, rotundamente no. Comparto la necesidad de llegar al todo, atajando las partes, pero también es necesario tener una "visión" aunque sea superficial, esto ya subjetivo, del "todo" porque si no podemos estar preparando a profesionales para el trabajo particular de cada centro educativo y no para el mundo real, el mundo laboral.He ahí, donde hoy y como consecuencia de la "interminable formación" (¡¡¡que ganas de experiencia laboral!!!) he descubierto un aspecto que en mi formación, considero a título personal, se podría mejorar sustancialmente.¿ A qué me refiero?, me refiero a la automatización de un proceso, teniendo en cuenta aspectos no solo de programación, sino otra serie de aspectos como la normativa en seguridad, ergonomía u otros aspectos.
No es necesario entrar en detalles propios de una ingeniería, pero si nombrarlos, recomendarlos, sugerirlos... para establecer un camino de perfeccionamiento y una guía de preparación para la obtención de soluciones válidas a los problemas de automatización desde diferentes aspectos. Si estás de acuerdo con esto, no está de más que accedas a los siguientes enlaces que en la parte inferior de esta entrada colocaré.
Después de tanto preámbulo, ¿a qué me refiero? en este caso particular. Pues bien, cuando se plantea un problema de automatización de un proceso, aunque a todos nos gustaría ,y muy especialmente a nuestro cliente, éste no se desarrollará sin problemas y por supuesto éstos son necesarios contemplarlos en su diseño.
Se puede tener un conocimiento bastante acertado de casi todos los estados posibles que nos podemos encontrar en su funcionamiento, pero tenemos a nuestro alcance una herramienta que nos permite definir los diferentes modos posibles adaptándolos a la máquina y condiciones del cliente, agrupándolos en cuatro situaciones posibles (sin alimentar, funcionamiento, parada y defecto).
Pero aún es más interesante cuando descubres que se trata de una guía gráfica, que va de forma conjunta y totalmente complementaria asociada al Grafcet,¿te va sonando? Esto significa que podemos detallar de forma mucho más analítica el problema entremanos, no obviando estados, bien por omisión, desconocimiento o falta de planteamiento en el encargo.
No quiero adentrarme en más en este tema pues en el enlace que os dejo de Oriol Boix, profesor titular de la UPC,nos da información concreta y accesible. El segundo enlace pertenece a un pdf pertenciente al profesor Jose A. Rodríguez Mondéjar de la Universidad Pontificia de Comillas, muy clarificante también.
Cambiando un poco de aspecto, aunque relacionado, os dejo este enlace a otro pdf que me ha resultado muy interesante por el aspecto ergonómico que comenta, en el diseño de paneles de control y que enlaza también con el primer tema de la entrada, las etapas de automatización de un proceso. A mí personalmente me ha servido como referencia a la hora de diseñar pantallas de un scada.
Hasta ahora, mis casos se habían reducido a dar una solución al problema planteado, pero quedaba libertad absoluta para determinar la colocación de entradas y salidas en pantalla. En este pdf de Pere Ponsa y
Antoni Granollers de la UPC, nos ayudan a reconocer aspectos muy a tener en cuenta en el diseño y automatización y particularmente para el diseño agrupado de controladores y dispositivos informativos visuales DIV.
Un saludo y a leer.
No hay comentarios:
Publicar un comentario