Environment

Influencia de la Arquitectura en los Sistemas de Control Inteligente

Description
Influencia de la Arquitectura en los Sistemas de Control Inteligente
Categories
Published
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
    Inteligencia Artificial. Revista Iberoamericanade Inteligencia ArtificialISSN: 1137-3601revista@aepia.orgAsociación Española para la InteligenciaArtificialEspaña   Segarra Martínez, Miguel J.; de Antonio Bermejo, Angel; Clavijo Blazquez, Jose A.; Sanz Bravo,RicardoInfluencia de la Arquitectura en los Sistemas de Control InteligenteInteligencia Artificial. Revista Iberoamericana de Inteligencia Artificial, vol. 4, núm. 10, verano, 2000,pp. 76-81Asociación Española para la Inteligencia ArtificialValencia, España Disponible en: http://www.redalyc.org/articulo.oa?id=92541008  Cómo citar el artículo Número completo Más información del artículo Página de la revista en redalyc.org Sistema de Información CientíficaRed de Revistas Científicas de América Latina, el Caribe, España y PortugalProyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto  Influencia de la Arquitectura en los Sistemas de Control Inteligente Miguel J. Segarra Martínez ✝ , Angel de Antonio Bermejo * , Jose A. Clavijo Blazquez * , RicardoSanz Bravo ✝✝ Universidad Politécnica de Madrid * SCILabs Ingenieros{msegarra, aantonio, jac, sanz}@disam.upm.es Resumen Los sistemas de control inteligente son básicamente sistemas software. Esto hace que tengan un ciclo devida propio compuesto por una serie de fases o etapas: especificación, desarrollo, validación operación,evolución y obsolescencia. La manera en que cada una de estas fases se desarrollará a lo largo de la vidadel sistema depende exclusivamente de las decisiones que se tomaron cuando éste todavía no existía.Estas decisiones críticas, adoptadas en las primeras etapas del diseño, son las que dan carácter a muchasde las propiedades importantes de las que goza el sistema de control: rendimiento, eficiencia, atributosde calidad, capacidad de modificación, capacidad de evolución, facilidad de mantenimiento, integracióncon su entorno, reusabilidad, funcionalidad, dependibilidad, etc. En este artículo se trata de mostrar dequé forma la arquitectura global elegida afecta al sistema de control durante el tiempo que éstepermanece en servicio. Palabras Clave: Ingeniería del software, arquitectura software, estilos arquitectónicos, línea de producto,estructura, diseño, control inteligente, control de procesos industriales, sistemas distribuidos de control. 1-INTRODUCCIÓN Los sistemas inteligentes de control poseencaracterísticas que obligan a que su desarrollo sebase en la experiencia previa del equipo encargadodel proyecto. La más importante de esascaracterísticas es habitualmente la carencia de unaespecificación clara de los requisitos orequerimientos que el sistema a diseñar debe poseer.Esto ocurre bien por la falta de una comprensiónclara del problema por parte de los diseñadores obien por una definición pobre del mismo por parte  del cliente. Naturalmente, no todas las personasinvolucradas en el desarrollo disponen de la mismaexperiencia. Exitos y fracasos anteriores influyen enlas decisiones futuras. A su vez, no parece aceptableque una disciplina que se tilda de “ingeniería” utiliceun método tan rudimentario de proceder como es lamera utilización de la experiencia individualadquirida sin disponer de mecanismos deformalización de la misma. Como veremos acontinuación, el sistema de control se ve afectadopor factores que deben ser tratados dentro de unmarco de trabajo adecuado si se desean conseguirlos resultados deseados. 1.1-LOS ACTORES En la construcción de un sistema de control apareceninnumerables actores cuyos efectos se encuentranacoplados y que son de difícil manejo. A losproblemas puramente técnicos, cabe añadir lacomplejidad de la organización global que seenfrenta al desarrollo. Se pueden distinguir variosactores que afectan a la evolución del sistema entrelos que destacan los siguientes:1.    La organización desarrolladora:  Su principalinterés es realizar los trabajos dentro delpresupuesto y planificación calculados. Paraello debe establecer los procesos internosnecesarios que optimicen de una maneracontinua todos los recursos a su alcance.Necesita básicamente poder financiar susproyectos a largo plazo que permiten a su vezgenerar sistemas en los que se reutiliza código,componentes o incluso sistemas completos.2.    La organización cliente:  Habitualmente lostrabajos encargados por la organización clienteresponden a líneas directrices o a estrategias(reducción de costes, aumento de la produccióno calidad, planes a más largo plazo, etc.) que laorganización se plantea para competir dentro desu nicho de mercado. Necesitan un sistema desencillo mantenimiento, modificable, con unciclo de vida largo 1 , etc. y que además respondaperfectamente a sus especificaciones de diseño.3.    Los usuarios finales:  Los usuarios finalesnecesitan un sistema fácilmente configurable,cómodo de utilizar y que, en definitiva,simplifique sus tareas diarias. Por supuesto,también desean un sistema robusto, fiable,seguro, íntegro, etc.  1  No es extraño encontrar sistemas industriales decontrol todavía en servicio y con una antigüedad de15 años o más.4.    El sistema físico:  Los sistemas en la industriapresentan peculiaridades que no aparecen enotros tipos de instalaciones. Puede ser necesariauna instalación de los sistemas en “caliente”, sinparar la planta o puede ser necesario diseñarsistemas redundantes que entren enfuncionamiento al fallar el principal. Todo estoademás se ve complicado por la complejidad detrabajar en un entorno heterogéneo conmúltiples plataformas y sistemas operativosdiferentes.Existen otros actores que intervienen en laconstrucción del sistema, puede existir unaorganización intermediaria, encargada de lanzar elproducto al mercado, que desee un sistema de bajocoste, finalizado a tiempo y con la calidad necesaria.También son de gran importancia las cualidadespersonales de los desarrolladores del sistema, etc.Tampoco se tratarán en este ámbito situacionesespeciales como aquellas en que la organizacióndesarrolladora y la cliente son la misma (casos en losque la venta del resultado final de los trabajos serealiza a miembros de la propia organización).Es fácil comprobar que las diferentes partesinteresadas en el sistema de control a menudo tienenintereses contrapuestos. Por ejemplo, parece difícilconseguir un sistema tolerante a fallos conredundancia activa o estática (interesante para laorganización cliente) a un coste moderado (unapesadilla para la organización desarrolladora).A la gran dificultad que conlleva tomar lasdecisiones acertadas dentro de este marco deintereses dispares y a la vez variantes en el tiempo,se une la complicación de la elección de lasherramientas adecuadas para el correcto avance ygestión de los trabajos.Existe un número inmenso de alternativas con lasque atacar un problema determinado. Partiendo demodelos de organización desarrolladora (CMM,SPICE, PSP, IDEAL, SEMA), mejora de susprocesos y gestión de riesgos, modelos de gestióndel cambio tecnológico en la empresa cliente y/odesarrolladora (IDEAL), pasando por las prácticasde ingeniería (análisis de requisitos, especificacióndel sistema, diseño del software, verificación,validación, etc.), lenguajes de modelado de sistemas(UML), sistemas de estimación del coste deproyectos software (COCOMO, SLIM) yterminando finalmente con las técnicas yherramientas de más bajo nivel para la construccióndel sistema se puede comprender la cantidad deesfuerzo que la simple elección de las herramientaspuede suponer a la hora de encarar un proyecto decontrol.  Por dar un ejemplo, suponga el lector un proyectoque le resulte familiar y piense que alternativaelegiría para estimar su coste:1.   El modelo COCOMO propuesto por Boehm[3] basado en dos ecuaciones de difícilestimación al comienzo del proyecto perode un funcionamiento claro.2.   El modelo SLIM [6] en el que elfuncionamiento interno del modelo no estan evidente como en COCOMO.En realidad, para llegar a tomar una decisión esnecesario realizar un análisis sólo al alcance de losexpertos. Esta dificultad hace que los diseñadores seenfrenten siempre de la misma forma a problemasdiferentes, lo que antes o después acaba terminandoen proyectos cancelados tras una gran inversiónglobal de todas las partes.La concepción del sistema de control desde el puntode vista de su arquitectura (líneas de producto,desarrollo basado en COTS, desarrollo basado enarquitectura, procesos software) permite construirsistemas en los que se llega a un compromiso entrelos intereses de todos los actores existentes. La razónde esta afirmación no es otra que la arquitectura delsistema basa su germinación en los requisitos detodas las partes involucradas. Por tanto, laarquitectura viene influenciada por las partes enconflicto y a su vez la arquitectura influencia a laspartes.Evidentemente, la generación de una arquitectura esun proceso costoso en tiempo y dinero.Afortunadamente, existen mecanismos que permitenla reutilización y/o particularización de instanciasgenéricas de arquitecturas. 2.-ARQUITECTURA DEL SISTEMA Se podría pensar por lo dicho hasta ahora que laarquitectura del sistema debería considerar loselementos que afectan a los intereses de los actores.Si bien ese conocimiento no puede ser obviadodentro del contexto del sistema, porque afecta a sudesarrollo, no es completamente cierto que sea partede la arquitectura del sistema. El sistema de controltiene naturaleza propia y, dada una métricaespecífica, responde a una arquitectura que debe serdescubierta 2 .Una vez descubierta la arquitectura del sistema esesencial desglosar esa arquitectura de manera que  2  Una vez dada una métrica, la cuestión sobre laexistencia de una arquitectura óptima y de si esaarquitectura es descubierta o es inventada es un grantema de discusión sobre el que existen variadasopiniones.encaje dentro de las necesidades y capacidades detodos los miembros involucrados.Asumiendo las puntualizaciones anteriores, unadefinición comúnmente aceptada de “ArquitecturaSoftware” es la siguiente: “La arquitectura software de un programa o sistemade cómputo es la estructura o estructuras delsistema, que comprende a sus componentessoftware, las propiedades de esos componentesvisibles de forma externa, y las relaciones entreellos” [1]Desde nuestro punto de vista, esta definición debetomarse en un sentido amplio. La “estructura oestructuras del sistema” son muy variadas y afectanno sólo al software sino a los procesos que ligan atodos los miembros involucrados en el desarrollo(organización desarrolladora, cliente, intermediarios,etc.).No todas las estructuras tienen el mismo peso. Lamás importante es aquella que representa al sistemade control aislado de los actores que intervienen ensu construcción (que muchos entienden comoarquitectura del sistema) y que sintetiza la esenciadel sistema final. Las demás estructuras se srcinan apartir de ésta y su único objetivo es realizar unatransformación de la estructura del sistema a laestructura real de las organizaciones de losmiembros del desarrollo. 3.-EL ARQUITECTO Sin duda alguna la figura del arquitecto es de unaimportancia singular cuando el desarrollo parte deldesgrane de la arquitectura del sistema.Sus tareas son de gran complejidad y, aparentementeen gran medida, no pueden ser aprendidas en uncentro de educación. Necesitan un profundoconocimiento técnico de su dominio deconocimiento, lo que contribuye a consolidar lacapacidad de liderazgo que debe poseer, además deuna gran habilidad social que permita negociar contodas las partes. Para realizar esta tarea debe conocera la mayor rapidez cuáles son las necesidades detodas las partes con el fin de poder negociarcontrapartidas desde un punto de vista ventajoso.Adicionalmente, debe conocer todas lasherramientas necesarias en cada momento de laejecución de los trabajos y la mejor forma deseleccionar entre ellas. Este conocimiento no setransmite fácilmente y, desde nuestra experiencia, seadquiere con el tiempo. Un buen arquitecto, a faltade métodos formales, debe desarrollar sus propiosmétodos de selección de herramientas.  Desgraciadamente, existe una tendencia clara ahacer de un arquitecto un simple gestor ó unnegociador que aparece de forma puntual en algunosestadíos del proyecto. De esta forma el arquitectopierde toda la perspectiva del proyecto y es incapazde resolver los verdaderos problemas queindudablemente terminan apareciendo. Además deesto, se gasta su experiencia de una forma inútil y ala vez su cualificación profesional se deprecia comoconsecuencia de la pérdida de la nueva experienciaque el proyecto podría haberle proporcionado.Puede parecer una definición simple pero es clara, “un arquitecto no es un gestor, es un técnico condon de gentes” . 4.-CONSTRUCCION DE SISTEMAS DECONTROL INTELIGENTE   Una vez conocidos algunos de los actores queintervienen en la construcción de sistemas softwarede control cabría preguntarse cuáles son las tareasque se deben realizar para llevar a cabo un desarrollocon garantías de éxito.Si comparamos diferentes sistemas de controlinteligente veremos que son bastante heterogéneos.En general, no están constituidos por componentesde características similares. A pesar de ello sí esposible encontrar similitudes que permitanestablecer pautas de comportamiento.Se entiende que inicialmente deben aparecer en elsistema comportamientos que lo clasifiquen dentrode lo que se conoce como control inteligente. Estamos pensando en proporcionar en algunamedida funcionalidad al sistema mediante técnicasderivadas de la Inteligencia Artificial: lógicaborrosa, algoritmos genéticos, redes neuronales,sistemas expertos, razonamiento basado en modelos,etc. Sin embargo, decidir si las técnicas de controlinteligente son de aplicación a un cierto sistemarequiere cierto estudio del mismo como se indica acontinuación.En un primer acercamiento a la arquitectura delsistema deben clasificarse qué problemas son los quese quieren resolver. La colaboración con el personalde planta es vital en este punto. Son ellos los queverdaderamente conocen el proceso y debe exigirseen este punto una colaboración total de las personasque más conocen los problemas a resolver.Frecuentemente estas personas tienen gran valorpara la compañía y tienden a estar sobrecargadas detrabajo, haciéndose su participación en laespecificación de los problemas muy difícil. Sinembargo, una mala identificación de las necesidadesdel sistema dará lugar, a lo largo del tiempo, a unapérdida económica mucho mayor que el valor de lashoras que un experto o expertos dediquen a laidentificación del problema de control.Una vez identificados los problemas a resolver, esrecomendable evaluar la conveniencia del uso detécnicas de Inteligencia Artificial para la resoluciónde los mismos. Hemos visto situaciones en las que,por ejemplo, problemas de control en sistemas quese comportaban de una manera lineal se resolvíanmediante complejos reguladores  fuzzy , dándoseademás la circunstancia de encontrarse la partecliente verdaderamente entusiasmada con la soluciónadoptada. El motivo no era otro más que la imagentecnológicamente avanzada que la introducción deun controlador de este tipo proporciona al cliente. Debe comprenderse que desde el punto de vista dela ingeniería esta solución, sin dejar de ser válida, noes la más elegante, eficaz o siquiera económica,aunque sí es posible que fuera rentable desde elpunto de vista de la imagen de empresa.Ante la evidencia de situaciones de control en lasque las técnicas clásicas no fueran eficaces paracumplir los objetivos propuestos es necesariorealizar una selección de tecnologías [9] adecuadas acada problema. Esta técnica clasifica de una formatabular los siguientes parámetros: dominio, tarea y tecnología . De esta manera, y de una formaextraordinariamente sencilla, es posible decidir latecnología y pasos a seguir para resolver unproblema una vez que éste ha sido identificado.En casos simples mediante la selección realizadaanteriormente es posible llegar a una soluciónsatisfactoria. Desafortunadamente, esto solamenteocurre en contadas ocasiones.En situaciones más complejas se requiere lacolaboración de diferentes técnicas de control,aumentando en gran medida la complejidad delsistema. En algunas ocasiones y ante problemaspequeños, el sistema puede ser construido desdecero. Cuando el sistema crece de tamaño no esposible considerar esta aproximación. El sistemadebe ser entonces compuesto a partir decomponentes preconstruidos que se combinan paraobtener el efecto deseado.Actualmente se pueden componer sistemas basadosen COTS  3  con relativa sencillez. Además, presentanla ventaja de que el coste del desarrollo o compra delcomponente se reparte entre los diferentes sistemasimplantados. La contrapartida del uso de este tipo decomponentes es la falta de control sobre su calidad ylas posibles faltas en su funcionamiento. Esteproblema se conoce como el síndrome del “nohecho aquí” . El coste de desarrollar componentes  3  Commercial-off-the-shelf components
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks