Un marco metodológico para el desarrollo de aplicaciones para automatización industrial

1 Universidad de Los Andes. Facultad de Ingeniería. Escuela de Ingeniería de Sistemas. Mérida, Venezuela e-mail: oteran@ula.ve

2 Universidad de Los Andes. Facultad de Ciencias. Laboratorio SUMA: Mérida, Venezuela e-mail: hidrobo@ula.ve

En este trabajo se presenta un marco metodológico para el análisis y la evaluación de las tecnologías y metodologías que soportarían el desarrollo, tanto de la plataforma como de las aplicaciones, en el área de Automatización Industrial. Dicho marco es requerido por la fase final de una metodología orientada por el contexto de realizar ejercicios de prospectiva tecnológica propuesta previamente. El producto de esa fase consiste en un plan de implantación que está constituido por una serie de etapas que involucran, entre otros aspectos, el análisis y la evaluación de las tecnologías y metodologías que dan soporte al desarrollo. El análisis y la evaluación derivan en la selección de una plataforma computacional, la arquitectura de la aplicación, y las tecnologías y metodologías requeridas para alcanzar un desarrollo funcionalmente exitoso y plenamente integrado. El marco metodológico es aplicado, para su validación, en el desarrollo de un sistema de Adquisición de Datos y Control Supervisorio (SCADA).

Palabras clave: Desarrollo tecnológico, Prospectiva tecnológica, Ingeniería de software, Automatización industrial, SCADA.

In this work, we present a methodological framework for the analysis and evaluation of technologies and methodologies for the development of applications in the area of Industrial Automation. This methodological framework is required in the final phase of a context oriented methodology to implement of a previous technological prospective proposal. The product of this phase is an implantation plan consisting of steps involving, among other things, the analysis and evaluation of technologies and methodologies that will support the development. Analysis and evaluation are based on the selection of a computational platform, the required application architecture and, the technologies and methodologies to achieve a successful and totally integrated system. In order to validate the methodological framework proposed, we use a SCADA system.

Keywords: Technological development, Technological prospective, Software engineering, Industrial automation, SCADA.

Recibido: junio de 2007 Recibido en forma final revisado: febrero de 2009

A partir del desarrollo de las tecnologías de información y comunicación (TIC), el área de la automatización es, en la actualidad, un campo fundamental para el crecimiento industrial. Por esta razón, resulta primordial la realización de estudios de prospectiva tecnológica para orientar los cambios a realizar en las plataformas que soportan la automatización industrial. Dichos estudios permitirán establecer el estado del arte en los ámbitos científicos y tecnológicos, determinar las expectativas y objetivos a alcanzar, así como el proceso de cambio enmarcado en criterios preestablecidos al inicio de los estudios (por ejemplo, garantizar procesos de transferencias tecnológicas), entre otros aspectos (Godet, 1995).

En lo referente al ámbito tecnológico, el enfoque prospectivo ha dado como resultado un impulso importante a las áreas de robótica, biotecnología, acuacultura, tecnologías de información y comunicación, energías alternas, nuevos materiales y nanotecnología (Futuro, 2000; Friend & Hickling, 2002; de Jouvenel, 2005; Echarri, 2004).

En Fundacite-ULA, 2006, se plantea una metodología para realizar estudios de prospectiva tecnológica en el área de Automatización Industrial. La metodología es amplia y exhaustiva en cuanto a que considera un análisis íntegro de la organización, proponiendo para ello la identificación de dominios de especialización y de variables de dominio, así como también variables transversales a los dominios. Esta descripción de los dominios, en términos de variables, recoge suficientes detalles de la organización, distinguiendo las características específicas de cada uno. A la vez, las variables transversales permiten caracterizar aspectos que simultáneamente afectan a varios dominios. Los cambios sugeridos dentro de la organización incluyen modificaciones para cada uno de estos dominios en términos de las variables de dominio, y para varios dominios simultáneamente en términos de las variables transversales. La metodología considera, además, elementos restrictivos, tales como: factibilidad técnica, factibilidad financiera, desarrollo sustentable, soberanía tecnológica, desarrollo de tecnología nacional, apropiación de tecnología foránea, factibilidad organizacional, entre otros.

El resultado de la aplicación de esta metodología concluye con un plan general de implantación de la tecnología objeto de estudio. En este trabajo, a partir de ese plan general se propone una sub-fase para el desarrollo tecnológico, la cual consiste en el análisis y evaluación de las diferentes tecnologías y metodologías de desarrollo para la creación de los diferentes subsistemas asociados a la aplicación de software a construir. Para la toma de decisiones, en cuanto a la selección de estas tecnologías y metodologías, se consideran criterios fundamentales que forman parte de los lineamientos empresariales y de la nación. Entre estos criterios o requisitos se tienen: licencias de código abierto, implantación de esquemas de seguridad sólidos y confiables, integración con aplicaciones de gestión y gerencia del negocio, alta disponibilidad, redundancia, visualización mediante clientes ligeros (WEB) y visualización basada en roles.

Para su evaluación práctica, este marco metodológico se aplica en una propuesta de desarrollo de un sistema de adquisición de datos y control supervisorio (SCADA), que es una plataforma computacional ampliamente utilizada en los procesos productivos. Esta herramienta permite la supervisión y control de los procesos, en tiempo real, mediante la evaluación de los datos presentes y el comportamiento histórico de los procesos controlados.

Todo proceso de desarrollo tecnológico (o de planificación) tiene como objetivo generar opciones y hacer una selección de las mismas, considerando algunos criterios. Los criterios son aquellos derivados de las restricciones que se imponen de acuerdo a los lineamientos empresariales, las leyes y políticas de estado, acuerdos, estándares y protocolos de estricto cumplimiento. Así, la metodología para analizar y evaluar alternativas en el desarrollo tecnológico de productos informáticos involucra la consideración de variables cualitativas y cuantitativas, a través de un procedimiento sistemático. Particularmente, este proceso fue descrito en Fundacite-ULA, 2006, de la siguiente manera:

Los criterios o restricciones de contexto para la determinación de la plataforma de desarrollo incluyen aspectos a diferentes niveles del entorno organizacional, los cuales están relacionados con la tecnología, con la eficiencia empresarial, con los intereses de la nación (por ejemplo, soberanía tecnológica), con restricciones presupuestarias, entre otros.

Se denomina dominio a cada una de las áreas de especialización de la plataforma tecnológica objeto. La clasificación de dominios debe seguir los estándares en el ámbito tecnológico objeto de estudio. Por otro lado, se denominan variables transversales a aquellas variables que son comunes a dos o más dominios. Estas variables son útiles para describir situaciones globales que no pueden ser descritas por variables de un solo dominio. A los fines de su evaluación, es necesario determinar rango de valores de las variables de cada dominio y las transversales, orientado a los intereses, requisitos e incidencia del entorno empresarial.

El levantamiento de información para el diagnóstico del estado actual de la plataforma tecnológica se apoya fundamentalmente en: visitas, entrevistas, consulta a expertos, revisión bibliográfica y hemerográfica, etc.

El levantamiento de los requisitos es una tarea a realizar conjuntamente con la empresa, a objeto de obtener información de todos los usuarios en los diferentes niveles organizacionales.

Para el estudio y selección de los paradigmas se realizan trabajos orientados a identificar los aspectos y variables claves de cada uno de los dominios, así como las tendencias a nivel internacional para cada una de tales variables.

Sobre la base de las variables externas e internas (por dominio), y de las variables transversales, se determina la brecha entre la situación actual y la situación deseada derivada de las tendencias de los paradigmas. Estos paradigmas determinan el marco sobre el cual se debería edificar la futura arquitectura tecnológica.

Consiste en determinar cuáles variables requieren mayor atención a fin de planificar cambios a cortoplazo, por ejemplo a 2 años, y cuales variables pueden diferirse a fin de planificar su cambio a más largo plazo, por ejemplo a 6 años. La priorización de variables facilita el establecimiento de los lineamientos que deberían orientar los cambios, algunos a considerar en el futuro inmediato y otros a más largo plazo.

Identificadas las brechas entre la situación actual y la situación deseada, se deben describir las diferentes operaciones que conforman el plan de implantación en cierto periodo de tiempo, orientadas a reducir tales brechas. Deben considerarse aspectos tales como la viabilidad y la planificación y lineamientos de negocio.

Estas fases constituyen el insumo fundamental para proponer esquemas definitivos de adquisición, desarrollo e implantación de la arquitectura computacional. A grandes rasgos, la metodología se orienta al diagnóstico del estado del arte y los requisitos de desarrollo según las restricciones. Esas dos visiones se comparan para establecer la brecha tecnológica y sugerir los planes para disminuirla.

La metodología aquí descrita requiere, en la fase de Planificación, de la implantación de una subfase de Análisis y Evaluación de Tecnologías y Metodologías a ser utilizadas durante el desarrollo de las aplicaciones y plataformas. Específicamente, nosotros aquí proponemos cómo se realizaría esa subfase en el área de Automatización Industrial. Este análisis parte de las conclusiones de cada una de las etapas previas a la Planificación de la Implantación, y considera, en el contexto de sistemas informáticos, lo siguiente:

1. Restricciones de contexto. Vanguardia tecnológica, viabilidad, soberanía tecnológica, políticas de estado, diversidad de usuarios, rentabilidad del negocio, viabilidad técnica, económica y organizacional.

2. Dominios tecnológicos. Seguridad, desarrollo de aplicaciones, infraestructura, integración, soporte y mantenimiento, visualización y datos.

3. Variables de dominio. Esquema de licenciamiento, esquema de soporte, disponibilidad del conocimiento, infocultura, integración, alta disponibilidad, redundancia, aplicaciones legadas, requisitos, escalabilidad, disponibilidad de los datos, metodologías y herramientas, eficiencia, impacto, modelado, enfoques de desarrollo de software, etc.

Esta subfase tiene por objeto la definición de la plataforma que soportaría el desarrollo de la arquitectura y de las aplicaciones de softwares. Para esto, en esta subfase se realiza un análisis y evaluación de las tecnologías y metodologías, de las implicaciones económicas, y de los riesgos que impedirían lograr los objetivos de acuerdo a la visión prospectiva.

Para la evaluación de las tecnologías y metodologías se considera pertinente realizar un análisis comparativo, tanto cualitativo como cuantitativo, de las diferentes alternativas identificadas en las siguientes áreas:

• Enfoque global de implantación de la aplicación. Una aplicación de software puede implantarse realizando, por ejemplo, un desarrollo propio o la adquisición de un sistema comercial que cumpla con los requisitos exigidos.

• Arquitectura general de la aplicación. Describe cómo las funcionalidades de una aplicación de software se distribuyen sobre un número de componentes lógicos, y cómo estos componentes se interrelacionan. En definitiva, defina la estrategia de modelado.

• Metodologías para el desarrollo de software. Describen el conjunto de fases, etapas, actividades y tareas asociadas a la producción de software de calidad. La formalización del proceso de desarrollo se conoce como ciclo de desarrollo de un producto o aplicación de software o ciclo de vida del software, el cual se utiliza para estructurar el conjunto de actividades requeridas para desarrollarlo y mantenerlo, e incluso para retirarlo una vez que se considera no útil y/o improductivo.

• Sistemas operativos. Permiten la comunicación del usuario con la computadora y gestionan sus recursos de forma eficiente.

• Lenguajes de programación. Permiten construir las aplicaciones a ser ejecutadas por el hardware de una computadora.

• Componentes principales de la aplicación. Son tareas o bloques de software que permiten llevar a cabo las actividades propias de la aplicación de software. Estos componentes se definen en base a los subsistemas de comunicaciones, monitoreo y supervisión de procesos, interfaz gráfica de usuario y gestión de datos.

• Integración de aplicaciones e integración de los distintos componentes de la aplicación. Es el esquema de operación conjunta que define la forma de interacción entre las aplicaciones externas y la aplicación a desarrollar, así como entre los componentes internos de esta última.

El análisis cualitativo refleja las fortalezas y debilidades de cada alternativa objeto de estudio, mientras que el análisis cuantitativo incorpora algunos aspectos importantes del entorno tecnológico, y se define en términos de dominios y/o entornos de competencia, evaluando, dentro de cada uno de estos atributos claves para cada una de las alternativas. El análisis cuantitativo se realiza mediante el cálculo de promedios ponderados por área, de la siguiente manera:

1. Para el área en estudio se identifican los dominios y/o entornos a considerar. A cada dominio y/o entorno se le asigna una ponderación, según su importancia.

2. Por cada dominio y/o entorno se definen las variables que describen dicho dominio. Se evalúa cada alternativa del área en función del nivel de presencia de la característica que representa la variable: Totalmente (1,00), Mucho (0,75), Medianamente (0,50), Bajo (0,25) y Nada (0,00).

3. Por cada dominio y para cada alternativa se calcula el promedio aritmético considerando los valores cuantitativos asignados a cada variable.

4. Finalmente, para cada alternativa, se calcula el promedio ponderado considerando todos los dominios. Este promedio es utilizado como base para establecer la recomendación respectiva al área.

El resultado de ambos análisis se resume en las recomendaciones de uso de una o varias de las alternativas evaluadas.

Una vez realizados los análisis cualitativo y cuantitativo para cada una de las alternativas de las áreas definidas, se realiza un análisis de las implicaciones económicas de la implantación de la aplicación. En algunos casos, las implicaciones económicas de las diferentes alternativas son muy similares, por lo que es suficiente realizar solamente un análisis cualitativo. En caso de ser necesario realizar un análisis cuantitativo, se sigue un procedimiento similar al descrito anteriormente.

Seguidamente se pasa a realizar un estudio de riesgos, donde se identifican, en primer lugar, los factores de riesgo y sus respectivos impactos, para cada una de las alternativas de cada área. En segundo lugar, para las alternativas seleccionadas de cada área, se presenta un análisis de riesgos, en el cual se incluyen factores de riesgo, probabilidad de ocurrencia, cualificación del impacto y los planes para contrarrestar estos riesgos.

La cuantificación del nivel de impacto se obtiene mediante el siguiente procedimiento:

• Se asigna un valor de probabilidad de ocurrencia a cada riesgo: Alta (0,6), Moderada (0,3) y Baja (0,1).

• Se asigna un peso al impacto del riesgo: Catastrófico (0,6), Serio (0,3), Tolerable (0,1) e Insignificante (0,0).

• Para cada uno, se calcula el nivel de riesgo como el producto de la probabilidad de ocurrencia por el impacto.

• El nivel de impacto se calcula como el promedio de los valores obtenidos en el paso anterior.

Basándose en los valores de cuantificación, se puede determinar un valor límite para el nivel de impacto multiplicando una probabilidad de ocurrencia Alta (0.6) por un impacto

Catastrófico (0.6), resultando un valor de 0.36. Este valor límite permite orientar la selección de una alternativa y/o cuantificar la magnitud del riesgo.

Los planes se diseñan para contrarrestar los efectos que puedan causar los riesgos. Por lo general son planes de contingencia, esto es, planes reactivos para recuperar las actividades de modo normal, con el menor costo de recursos. En algunos casos se describen planes preventivos para alterar la probabilidad del riesgo y/o planes preventivos para minimizar el impacto del riesgo. Luego de realizados el conjunto de análisis descritos, y tomando en consideración los resultados de los mismos, se establece, de manera concluyente, la arquitectura que soportaría el desarrollo de la aplicación de software, la cual se construye a partir del plan de desarrollo. El producto final es toda una herramienta computacional con todas las fortalezas para su escalabilidad, mejoras, reformulaciones, adaptaciones, etc.

Un SCADA debe tener ciertas características fundamentales, entre estas:

• Deben ser sistemas de arquitectura abierta, capaz de crecer y adaptarse, de acuerdo a los cambios y necesidades del negocio.

• Deben permitir la comunicación, con total facilidad y transparencia, del usuario con los equipos de planta y con el resto de los procesos empresariales.

• Deben ser programas simples de instalar, sin excesivas exigencias de hardware, fácil de usar y con interfaces de usuario amigables.

Para realizar las tareas de adquisición, supervisión y control, un SCADA está construido a partir de subsistemas, los cuales, fundamentalmente son:

1. Configuración. Permite al usuario definir el ambiente de trabajo de su SCADA, adaptándolo a la aplicación particular.

2. Interfaz Gráfica de Usuario. Provee al operador de las funciones de control y supervisión de la planta. Las imágenes del proceso, por medio de gráficas sinópticas, se construyen y almacenan a partir de una aplicación del subsistema de configuración. Las funciones de visualización se realizan en tiempo real, proporcionando los resultados dentro de un tiempo específico.

3. Módulo del Proceso. Ejecuta las acciones de control pre-programadas a partir de los valores presentes de las variables leídas y las diferentes consignas de producción.

4. Gestión de Datos. Se encarga del almacenamiento y procesamiento de los datos, de modo que otras aplicaciones o dispositivos puedan tener acceso a ellos. Este subsistema contempla la gestión tanto de bases de datos en tiempo real como de bases de datos históricos.

5. Comunicaciones. Se encarga de la transferencia de información entre la planta y la arquitectura de hardware que soporta el SCADA, y entre éste y el resto de los elementos de cómputo de gerencia de producción.

En definitiva, SCADA es toda una herramienta computacional que permite la operación automatización de plantas industriales. Tienen un amplio uso en los diferentes sectores productivos por lo que constituye un elemento fundamental de desarrollo tecnológico.

El resultado de la aplicación práctica de esta fase se presenta a continuación, resaltando solamente aquellos aspectos que remiten a la formulación de las recomendaciones.

Para determinar el enfoque global de implantación del SCADA Venezolano se evalúan dos alternativas: el desarrollo de un SCADA propio y la adquisición mediante la requisición y compra de un SCADA comercial.

A la luz del análisis cualitativo realizado en base a las fortalezas y debilidades de cada alternativa de implantación, la adquisición vía licitación de un sistema SCADA que cumpla con los lineamientos, políticas y requisitos empresariales y de la nación no es completamente factible debido a que va en contra de la visión comercial de los fabricantes. Por lo tanto, la orientación del desarrollo nacional es una alternativa viable y adecuada, la cual no está exenta de dificultades y requiere de un alto nivel de compromiso y dedicación de parte de los actores involucrados.

Para el análisis cuantitativo de estas alternativas fueron considerados los dominios y variables mostrados en la tabla 1. De acuerdo a los resultados de este análisis, el valor del promedio ponderado, para cada alternativa, se muestran en la tabla 1, donde se observa que la alternativa de implantación más conveniente es la del desarrollo de un SCADA propio.

Para el caso de los modelos basados en componentes y servicios WEB, pueden ser tratados como esquemas integrados a los otros dos modelos.

Los sistemas basados en agentes pueden incluir tanto modelos orientados a objetos como tecnología basada en objetos distribuidos para describir y ejecutar tareas de automatización. Los elementos que ejecutan las acciones son vistos como objetos que tienen toda la información necesaria para su operación. Es natural, por esa percepción de autonomía, considerar dicho componente como un agente ligero, siendo posible realizar una correspondencia directa entre el agente y la instancia física que representa. En este sentido, los agentes deberían ser contemplados en aquellos niveles donde las funcionalidades involucren o requieran, entre otras, cooperación, negociación, adaptabilidad para reducir la complejidad y aumentar la flexibilidad. Sin embargo, en los niveles donde las funcionalidades no involucren tales capacidades se pueden emplear agentes ligeros.

En este contexto, se consideran como alternativas: el Modelo Cascada V, el Modelo Espiral, el Modelo Incremental, las metodologías Rational Unified Process (RUP), Enterprise Unified Process (EUP) y el Modelo de Procesos para la Industria de Software (MoProSoft), las cuales se evalúan cualitativamente en función de sus fortalezas y debilidades. La tabla 3 muestra los dominios y variables considerados para las alternativas en el análisis cuantitativo y los resultados de los valores de promedio ponderado obtenidos para cada una de ellas.

Tabla 3. Dominios, variables y promedios ponderados de las alternativas de las metodologías y modelos para el desarrollo de software.

En general, todas las metodologías y modelos aquí evaluados tienen buenos atributos técnicos, aunque sobresalen las metodologías MoProSoft y EUP. Las diferencias técnicas entre ellas son poco significativas, por lo que podría seleccionarse cualquiera de ellas. Sería conveniente hacer un análisis de otras implicaciones para hacer una selección con mejor criterio, lo que podría tenerse luego de analizar las implicaciones económicas y el estudio de riesgos.

En virtud de que el desarrollo del SCADA venezolano se fundamenta en el paradigma de software libre, se evalúan cualitativamente, en función de sus fortalezas, debilidades y hardware, los siguientes sistemas operativos de libre distribución y de código abierto: Linux general (sin tiempo real), Linux tiempo real y variantes, Fluke y C5. Este análisis arroja como resultado la selección del sistema operativo Linux, recomendándose, además, el estudio de las posibilidades de integración a los PC’s industriales de los micro-kernel C5 y Fluke.

Dado que existen diferentes distribuciones del sistema operativo recomendado, se realiza un análisis cualitativo tomando como alternativas: Debian, Gentoo, Mandriva, Suse, Red Hat, Ubunto, y Fedora, en función de sus fortalezas y debilidades.

De este análisis se concluye que para servidores de muy alto rendimiento o de hardware antiguo lo aconsejable es Gentoo, pues es la distribución que mejor permite optimizar y adaptar el hardware. Para servidores en sí, que no sean críticos se aconseja Debian; y para estaciones de trabajo se recomienda Ubunto, pues es de buenas prestaciones, fácil de instalar y posee un buen ambiente.

La evaluación de los sistemas operativos no se realizó en términos cuantitativos, puesto que, en este caso particular, se consideró como única alternativa la de sistemas operativos de código abierto.

Para la evaluación de los lenguajes de programación se consideraron como alternativas: C/C++, Java (a pesar de que aún no es considerado un lenguaje para el desarrollo de aplicaciones en software libre), ADA, Perl/Python, y PHP. El análisis cualitativo es realizado en función de las fortalezas y debilidades de cada lenguaje, en tanto que para el análisis cuantitativo se tomaron en cuenta los dominios y variables mostrados en la tabla 4.

Tabla 4. Dominios, variables y promedios ponderados de las alternativas de lenguajes de programación.

A partir de los valores de los promedios ponderados mostrados en la tabla 4 se concluye que C/C++ es el lenguaje más apropiado. La razón está dada por la rapidez de ejecución que prima en todos los dominios. Por lo tanto, C/C++ debería ser adoptado como primera opción a la hora de abordar el desarrollo de una aplicación de software que sería ampliamente utilizada y, en la cual, el rendimiento se establezca como un factor primordial. Este es el caso de los subsistemas fundamentales de un SCADA.

En orden descendente del valor de promedio ponderado se encuentran los lenguajes Perl y Python, los cuales, por sus bondades expresivas, y por el hecho de que son interpretados, permiten desarrollar e integrar aplicaciones (o prototipos) muy rápidamente. Esta bondad es bastante apreciable a la hora de integrar aplicaciones entre sí y cuando se requiera desarrollar aplicaciones céleremente. Ambos lenguajes obtuvieron los mismos puntajes; sin embargo, se recomienda la utilización de Python, pues es un lenguaje con un mejor sistema de tipos, lo que permite mejor ayuda del intérprete.

Como resultado de esta evaluación, se plantean las siguientes recomendaciones:

• C/C++ para desarrollo de núcleos críticos (menor complejidad y mayores restricciones de tiempo).

• Python combinado con C/C++para la integración y desarrollo de aplicaciones.

La plataforma de desarrollo del SCADA debe contemplar aspectos que soporten la construcción apropiada de los subsistemas de: comunicaciones, monitoreo y supervisión de procesos, interfaz gráfica de usuario y gestión de datos.

Tabla 5. Dominios, variables y promedios ponderados de las alternativas de protocolos de comunicación.

De acuerdo a los resultados obtenidos en el análisis cuantitativo realizado para las alternativas de implantación, en el que se consideran los dominios y variables que se muestran en la tabla 10, la diferencia entre los dos valores de promedio ponderado resulta significativa (tabla 10). La alternativa de desarrollo toma un valor que es 1,5 veces mayor al de la alternativa de adquisición, por lo tanto, en términos económicos, se recomienda desarrollar el SCADA. Esta recomendación coincide con la realizada para el enfoque global de implantación del SCADA.

Para llevar a cabo el estudio de riesgos, primeramente se identifican los riesgos y sus respectivos impactos para cada alternativa dentro de las áreas consideradas: Enfoque global de implantación, Arquitectura general de la aplicación, Metodologías para el desarrollo de software, Sistemas operativos, Lenguajes de programación, Componentes principales de la aplicación e Integración de aplicaciones e integración de los distintos componentes de la aplicación. Seguidamente, se realiza el análisis de riesgos para las alternativas seleccionadas en cada área. La tabla 11 muestra el nivel de riesgo para cada una de las alternativas recomendadas. En los casos en los cuales el nivel de riesgo esté cerca del límite del nivel riesgo (0.36), puede considerarse que no es una alternativa adecuada.

1. Aguilar, J., Perozo, N., Terán, O. (2008). Proposal for a Multiagent Architecture for Self-Organizing Systems (MA-SOS), Lecture Notes in Computer Science, Springer-Verlag, 5075, 434-439.        [ Links ]

2. Bas, E. (1999). Prospectiva, herramienta para la gestión estratégica del cambio. Ariel.        [ Links ]

3. Bravo, V., Aguilar, J., Rivas, F., Cerrada, M. (2004). Diseño de un Medio de Gestión de Servicios para Sistemas Multiagentes, Actas de la XXX Conferencia Latinoamericana de Informática, 431-439, Arequipa, Perú.        [ Links ]

4. De Jouvenel, H. (2005). Revista FUTURIBLES. Recuperado en febrero de 2007 de http://www.futuribles.fr.        [ Links ]