El Modelo de Sistema Viable para el software

Charles Herring y Kaplan Simon

Departamento de Ciencias de la Computación e Ingeniería Eléctrica
Universidad de Queensland
Brisbane, Queensland QLD 4072
{herring kaplan}@dstc.edu.au

Resumen

Estamos investigando la aplicación del modelo del sistema viable de Beer para el desarrollo de
software para aplicaciones "complejas" . Usamos este modelo como base para una arquitectura de
componentes del sistema, la Arquitectura del Sistema Viable. Una clave de la construcción de la
arquitectura es la estructura de un componente y su conjunto de interfaces especiales, un
"componente viable". Tras la presentación del Modelo de Sistemas Viables y la Arquitectura del
sistema viable, se esboza una metodología de diseño para el desarrollo de componentes de software
en este enfoque.

1. Introducción
Stafford Beer ha desarrollado el Modelo de Sistemas Viables (MSV) [1] con el fin de comprender,
predecir y controlar las las organizaciones humanas o "empresas". El MSV se basa en el estudio y la
observación de muchas organizaciones durante un período de treinta años. El objetivo de Beer fue
descubrir las estructuras invariantes y los comportamientos y los describen sobre la base de la
cibernética. Tomamos este modelo como punto de partida para el modelado de "complejos "
sistemas a fin de construir un mejor software.
Ejemplos de sistemas de software complejos incluyen entornos inteligentes, Informática Ambiental,
Sistemas Multi-Agente, Interfaces de Usuario adaptables / Inteligentes y Business-to-Business e-
Commerce. Estos sistemas se caracterizan por un gran número de componentes heterogéneos con
un alto grado de interconexiones, relaciones y dependencias. Ellos existen en un entorno de cambio
dinámico que exige un comportamiento de respuestas dinámicas. En otras palabras, estos sistemas
deben adaptarse a su entorno.

Figura 1 Control de velocidad del automóvil

A modo de introducción y motivación para el enfoque considere el sistema de control del automóvil
crucero de la Figura 1. Se trata de un típico sistema de control de lazo cerrado en el controlador de
monitorea y mantiene una variable del sistema, la velocidad, dentro de ciertos límites deseados. El
sistema en general está sujeto a perturbaciones ambientales (tales como una colina empinada) y el
controlador, basado en la retroalimentación, ajusta el acelerador cuando sea necesario.
El control del automóvil crucero es uno de los problemas de diseño orientado a objetos "canónicos".
Shaw analiza este problema y desarrolla un paradigma de control para software [2]. Su idea es que
se trata de un sistema de control y hay un cuerpo de conocimientos de ingeniería asociadas a estos
sistemas. Ella sostiene que el paradigma orientado a objetos no puede ser el enfoque más adecuado
en este caso. Se desarrolla una arquitectura de software basada en la teoría clásica de control de
realimentación en lugar de una arquitectura basada exclusivamente en la identificación de objetos y
sus relaciones.
Señala el paradigma de control separado de la planta (el motor en este caso) del proceso principal
de la compensación por las perturbaciones externas, el control. Esta separación de interés produce
abstracciones apropiadas que conducen a resultados de diseño que de otra manera se puede perder
en el enfoque (de dominio neutro) orientado a objetos. En particular, el rendimiento y las
limitaciones de la corrección se identifican temprano en el proceso de diseño.
Shaw ofrece la siguiente regla de oro para el uso de la arquitectura del paradigma de control:
Cuando la ejecución de un sistema de software se ve afectada por perturbaciones externas, fuerzas,
o eventos que no son directamente visibles, o controlables, el paradigma de control debe ser
considerado para la arquitectura de software.
Al analizar el problema de control de crucero Shaw reconoció que la teoría de control fue el
contexto más apropiado para el problema. Reivindicamos la regla de oro es el caso general de los
sistemas "complejos" de software. Sostenemos que este tipo de sistemas de software debe ser
diseñado para adaptarse a las perturbaciones externas. La teoría del control en general y la
Cibernética en particular, ofrecen un enfoque para hacer esto. Si la teoría subyacente y principios de
la Cibernética son general de hecho, entonces no hay otra opción - que no se puede evitar en
cualquier sistema de procesamiento de información no trivial. Por ejemplo, hemos demostrado que
el patrón de diseño de mayor éxito, Modelo-Vista-controlador, es un sistema de control de lazo
cerrado [3].
Por lo tanto, después de una búsqueda y evaluación considerable, se optó por el MSV como base
para el desarrollo de la Arquitectura de Sistema Viable (ASV) [4]. Desde el punto de vista de
software, el MSV se puede considerar como el lenguaje de patrones de los sistemas complejos. El
ASV es el arquitectura de alto nivel basado en el MSV. La arquitectura ASV define una estructura
de componente único, el "componente viable" y un conjunto de interfaces de componentes que en
términos define el marco en sí.
En este artículo nos centramos en la estructura, diseño e implementación del componente
fundamental. Comenzamos con una breve introducción al MSV. A continuación, la ASV se presenta
como el marco de componente. Las cualidades deseadas del software desarrollado sobre la base de
este enfoque son presentados. Los principios que conducen a estas cualidades se describen. La
estructura interna del componente y sus interfaces se da en detalle. Por último, una metodología o
secuencia de pasos para el diseño de los componentes viables se describe.

2. El Modelo de Sistema Viable

La siguiente es una breve introducción a las características y estructura del MSV. Un diagrama
simplificado de una sistema viable se muestra en la Figura 2. Compare esto con el sistema de
control estándar se muestra en la Figura 1. Tenga en cuenta la separación fundamental del control y
objetivo del control o de la planta. La diferencia de la figura 1 es la estructura interna del
controlador y la estructura interna de la planta es mostrada. Los roles particulares y sus relaciones
son fundamentales para el MSV.
Las cajas y círculos enumerados tienen la siguiente función o rol en el modelo de sistema viable:
5: Ejecutivo. Dirección política; interfaz externa.
4: Planificación: Anticipación de cambios causados por perturbaciones externas del medio
ambiente.
3: Operaciones: Preocupado con la operación directa de la planta
2: Regulación: Programación de la producción, la prevención de oscilaciones, auditoría y control.
1A-C: los controladores en el siguiente nivel de recursividad.
A-C: Las plantas.
Las aspectos principales del MSV ahora se describen. En primer lugar, la estructura interna del
controlador es relacionada con la terminología del sistema de control . Un controlador con sólo la
función 3 (Operaciones) presente es un controlador estándar (como se muestra en la Figura 1.) La
adición de la función 4 (Planificación), que es acoplada a la función 3, se llama controlador de
adaptación. Es decir, la función 4 actúa como un "sintonizador" o meta-regulador de la función 3.
La adición de la función 5 (Ejecutivo), que es acoplado con la pareja 4-3, se llama controlador de
supervisión y actúa como meta-regulador para el par controlador 4-3. La siguiente característica al
observar es la naturaleza recursiva de MSV. Dentro de los controladores 1A-C el mismo patrón 5-4-
3 se repite.

Figura 2 Diagrama simplificado del MSV

Sin embargo, están especializados en la tarea particular de control en ese nivel o recursión. Del
mismo modo, todo el sistema es una recursión del sistema viable de nivel superior. En términos de
la teoría de control el MSV se puede clasificar como un sistema de control jerárquico, autónomo,
inteligente, de supervisión adaptativo [5]. La autonomía es el grado de libertad de los controladores
de nivel 1A-C que tienen en términos de la toma de decisiones y la adaptación. La inteligencia es
una cuestión de sofisticación de los algoritmos de control del sistema 5-4-3.

3. Cualidades y principios de los Sistemas de Software viables

Viabilidad es la cualidad general que deben tener los sistemas de software basados en el ASV. En el
nivel más alto de abstracción viabilidad significa el sistema que puede "mantener su identidad."
¿Qué significa esto en términos de sistemas de software?
En un nivel, la respuesta es un sistema de software viable que puede mantener la estabilidad.
Obviamente esto se relaciona con el enfoque de la teoría de control. La adaptación es un mecanismo
utilizado para lograr este objetivo. Ahora, los sistemas complejos viven en un entorno complejo, es
decir que son al mismo tiempo integrado en muchos otros sistemas. Así que el mantenimiento de la
estabilidad es un problema multidimensional que requiere muchas estrategias relacionadas entre sí.
Desde la perspectiva de la ingeniería de software creemos que el concepto de viabilidad subsume
una serie de "ilidades": fiabilidad, escalabilidad, comprensibilidad, mantenibilidad, y así
sucesivamente. Estas son las facetas del sistema viable. ¿Cómo puede la arquitectura ayudar a hacer
viables los sistemas a nivel del marco de componentes? Nuestro modelo, el MSV, dice que la
viabilidad se consigue mediante la interacción de una serie de principios: autonomía y adaptación;
recursividad y jerarquía, y invarianza y autorreferencia.
La autonomía se relaciona con el grado de libertad para la toma de decisiones locales. Es siempre
listado como un atributo de las arquitecturas de como agente. En nuestra arquitectura es
fundamental para la flexibilidad en los marcos de componentes. También es esencial para los
sistemas distribuidos. La autonomía es especificado por marcos del subsistema superior y los
límites de la naturaleza y el grado de comportamiento adaptativo. Por ejemplo, la autonomía puede
ser especificado a través de la política que concede permisos para ciertos tipos de actividades.
La adaptación es un principio clave y clasifica las capacidades de adaptación de un sistema de
software viable de la siguiente manera: homeostático, morfoestático y morfogenético. Estos
corresponden a las funciones 3, 4-3 y 5-4-3 de la última sección. La homeostasis es el
mantenimiento de las variables críticas dentro de ciertos límites para garantizar la estabilidad de un
sistema en respuesta a los cambios en el entorno. Este es un comportamiento normal del sistema de
control. La adaptación morfoestática y morfogenética se refieren a la adaptación estructural. El
comportamiento Morfoestático es "adaptación simple" como el cambio de algoritmos de control
interno. Esto corresponde a la función de 4-3. Los sistemas morfogenéticos mantienen las
metapropiedades del sistema ("identidad") a través de la evolución de la estructura y / o
componentes que constituyen el propio sistema. Es decir, la capacidad de adquirir nuevos
componentes y desechar otros. Esta es la función completa 5-4-3 del controlador. En resumen, un
controlador "supervisor adaptativo" de un sistema homeostático implementa políticas
morfoestáticas y morfogenéticas de gestión (mantener la estabilidad de) la planta. La viabilidad de
un sistema es una medida de qué tan bien estas políticas se realizan en un entorno particular.
En la breve introducción a MSV de la última sección hemos señalado que el modelo es
inherentemente recursivo. Cada capa del subsistema contiene todas las capas debajo de ella. Del
mismo modo, cada subsistema que también se encuentra por los niveles por encima de él. El MSV
es un sistema de control jerárquico. La recursividad y la jerarquía son las estrategias utilizadas por
los sistemas para gestionar la complejidad. La funcionalidad debe separarse de los niveles más
bajos de lo contrario el sistema es superado por el detalle y la gestión es imposible - la toma de
decisiones no se puede escalar. Cada nivel lleva a cabo un conjunto exclusivo de funciones. Aunque
existen patrones similares en todos los niveles, no son equivalentes. La recursividad y la jerarquía
también se relacionan con la autonomía discutida arriba. Estos principios son fundamentales para el
objetivo de nuestra arquitectura, a saber, el desarrollo de sistemas basados en subsistemas o
jerarquías de marco. Ellos también están relacionados con los principios descritos a continuación.

Figure 3 Viable System Model Diagram

Hay ciertas invariantes estructurales y de comportamiento claves en el MSV que se realizan sobre la
ASV. La separación fundamental de control y objeto de control (planta) es uno. La organización
interna del controlador es otro, las funciones 5-4-3-2-1 descritas en la última sección. El requisito
de autonomía en cada nivel es otro. La recursividad y la jerarquía son también invariantes en el
sistema viable. Estas invariantes dan lugar a la estructura auto-similar (fractal) del sistema. Una vez
que comprendidos estos, cualquier nivel de subsistema se puede entender. En gran medida el
concepto de auto-referencia abarca muchos de los principios de la arquitectura deseada. La auto-
referencia es la característica de un sistema de tal manera que cada parte tiene sentido en términos
de las otras partes. El sistema define o se produce sobre la base de las partes y su disposición. Esta
propiedad también se conoce como cierre lógico y está relacionado con la identidad, la conciencia
de sí mismo, auto-reparación y la recursividad misma.
La presentación de hasta el momento puede parecer muy abstracto, pero alegan que es la base
teórica necesaria para alcanzar el tipo de marco de componentes de software necesarios para apoyar
la diseño de sistemas complejos. La tarea de la siguiente sección de es hacer estas abstracciones
concretas.

4. La arquitectura del sistema viable

Las secciones anteriores han presentado con suerte un panorama general del MSV y presentado las
cualidades y principios de la ASV. Aquí entramos en más detalles sobre la estructura del modelo
arquitectónico. El objetivo es llegar a una descripción de componentes de alto nivel.
La Figura 3 es una representación más precisa de la estructura del MSV. Tenga en cuenta que es
básicamente la figura 2 girada en 90 º y con algún detalle añadido. El funciones del controlador
principal 3-4-5 son las mismas como se describe anteriormente. Las elipses enfatizan el entorno
externo en el que se incluye el sistema. Hay dos sub-sistemas en el diagrama. Los círculos en el
centro de la imagen (A y B) representan dos plantas - componentes de software que hacen el trabajo
del sistema - y sus controladores (1 A y 1 B). También tenga en cuenta que en este diagrama se
muestra la relación entre las plantas. Es decir, la salida de una planta puede ser la entrada de otra. El
rectángulo (1 ') representa el controlador. El controlador está conectado a las plantas, que supervisa
y realiza la dirección, la planificación y las funciones de operación (5-4-3) . Ampliamos en el
circuito anti-oscilatorio que se muestra en líneas punteadas: Regulador (2) y Auditoría (3 *). Estas
funciones proporcionan retroalimentación necesaria para asegurar el buen funcionamiento del
sistema en general. El regulador es responsable del mantenimiento de los programas de producción
y de la coordinación con otros controladores. (Estos programas o planes vienen desde el controlador
a través de las funciones de operación.) La función de Auditoría supervisa el comportamiento de la
planta y pasa esa información a las operaciones para el procesamiento. Esto puede tomar la forma
de inspeccionar la planta de forma aleatoria o esporádica. Esto se suma a la comunicación normal o
de rutina que se produce entre las operaciones y la planta. Es un mecanismo de detección de errores
adicionales. Por último, una señal "algedonica" (placer y dolor) se muestra al pasar de los
controladores del nivel inferior directamente a la función de dirección en el siguiente nivel. Esto
puede ser pensado como una alerta de "anulación de pánico" que no pasa todos los filtros en las
funciones 3-4 .
Ahora estamos en condiciones de determinar la especificación de interfaz de componente de ASV.
Partimos de la siguiente manera. En la figura 3 se dibuja una curva cerrada en torno a uno de los
componentes, 1 A + A, por ejemplo. Si ahora examinamos cada una de las líneas que cruzan la
curva, se ha identificado el conjunto de interfaces de un componente viable. La Figura 4 muestra el
resultado. Por lo tanto, un componente viable tiene, como máximo, nueve tipos de interfaces. Este
conjunto de interfaces es el "contrato" en el marco entre el productor y el consumidor o cliente y el
servidor. Una breve descripción de las interfaces genéricas se da a continuación:
0. Directo a la planta para el acoplamiento del Medio Ambiente. Proporciona información del
entorno directamente a la planta y la planta proporciona información al medio ambiente.
1. Planificación de la "visión del futuro" del entorno. Esto puede ser a partir de datos
históricos, de proyecciones de datos o las simulaciones basadas en el entorno actual.
2. Provee para la transmisión de los planes y programas del sistema de programación del
controlador de nivel superior para el componente. También para la coordinación en el
 mismo nivel de recursión (2 ').
3. Los comandos y recursos se derivan de la función de operaciones del controlador de nivel
superior para el componente. La rutina de informe de situación y las peticiones de los flujos
de recursos del componente de controlador de nivel superior.
4. Esto establece la "relación de modelado" entre los componentes. El componente transmite
un modelo de sí mismo para su inclusión en el controlador de nivel superior el auto-modelo
para el uso de su función de planificación.
5. Las políticas y normas de control se transmiten al directivo del componente a través de esta
interfaz.
6. Esta interfaz se utiliza el componente de la señal directamente al controlador de nivel
superior directivo (desviando Operaciones y Planificación) cuando sea necesario, por
ejemplo, pánico.
7. La interfaz de auditoría esporádica permite el controlador de nivel superior de Operaciones
para monitorear y verificar el estado del componente.
8. Esta es la conexión directa de planta a planta. Las plantas pueden ser encadenadas juntas en
las líneas de producción.

Figura 4 Interfases de componentes viables

Este conjunto de nueve tipos de interfaz es la clave de la construcción de la arquitectura. Ellos son
el mecanismo por el cual los principios descritos anteriormente se logran. Dada la naturaleza
recursiva y autorreferencial del modelo, la especificación de interfaz de componente viable define el
marco en sí. Este acuerdo preveía un sistema auto-similar de arquitectura de componentes de sub-
sistemas en los que puede ser cualquier nivel tratado como un componente o un marco de
componentes. Desde una perspectiva de interfaz ellos son equivalentes.
Una interfaz define la especificación de entrada y salida entre dos elementos del sistema. Algunos
ejemplos son las interfaces entre las operaciones en un nivel y operaciones en el nivel
inmediatamente inferior, entre la planta y su entorno y entre dos plantas. En el ASV todas las
interfaces son circuitos de retroalimentación (véase la leyenda en la figura 3). Estas interfaces
tienen una estructura particular que se muestra en la Figura 5
Tradicionalmente, los componentes de software se desarrollan en forma aislada. Se distribuyen con
una especificación de interfaz y es el trabajo del usuario (programador) para embalar, pegar o de
otra manera integrar el componente en el sistema previsto. La plataforma de componentes de la
ASV define un modelo estándar de las interfaces de un componente. Esto permite el diseño con el
conocimiento de los componentes en ambos lados de la interfaz. El objetivo es lograr un equilibrio
dinámico - homeostasis - para cada conjunto de componentes acoplados.

Figura 5 Estructura de Interfaz

El diseño de interfaz comienza por establecer "criterios de estabilidad" para la interfaz entre los dos
sistemas. Por ejemplo, si un componente está transmitiendo a 2,4 GHz, el receptor debe ser capaz
de recibir a esa velocidad. De lo contrario, los búferes internos del receptor puede desbordarse,
provocando retransmisiones, etc En otras palabras, será el sistema impulsado fuera de equilibrio y
puede fallar lo que afecta a otras partes del sistema. Con base en los criterios de diseño para la
interfaz, "los acuerdos" de entrada y salida son diseñados e implementados.
La forma general de dicho acuerdo es un canal con transductores en cada extremo. El canal es el
medio para la comunicación. Los transductores pueden ser necesarios para que coincida con "los
acuerdos" de entrada / salida. Por ejemplo, la información se codifica en un formato (XML), la
transmisión (HTTP) y se descifra en otro formato (XSL a HTML). Puede haber múltiples acuerdos
involucrados en una interfaz. Los criterios de diseño deben ser desarrollados para acomodar a todos.
Por último, cabe señalar que las interfaces no están diseñadas de forma aislada. Por ejemplo,
supongamos que las tres plantas se van a conectar el uno al otro. En este caso las prescripciones de
estabilidad se deben desarrollar con todas las interfaces en mente, o el diseño rehecho, como los
nuevos requerimientos de interfaz descubiertos.

5. Diseño de Componentes viables

En esta sección se describe una metodología, una secuencia de pasos para el diseño de sistemas de
software basados en la ASV. Estos pasos son una síntesis de los enfoques que figuran en Beer [1], el
control tradicionalboth [6] y los aspectos de control difuso [5]. El objetivo es describir un método
de diseño de un componente a un nivel en una jerarquía recursiva de sub-sistemas. En primer lugar,
es necesario elegir un nivel en el que se inicia. Esta elección estará determinada por los
requerimientos de la aplicación. Por ejemplo, nuestra tarea puede ser ensamblar un conjunto de
componentes viables en un nuevo sistema de software viable para algunos fines declarados. En ese
caso, habría, en cambio, los componentes de software construidos según las especificaciones del
marco de ASV. Es decir, un componente de software con un conjunto de interfaces como se describe
anteriormente y se muestra en las figuras 4 y 5. Estos pueden ser tratados como componentes de
"caja negra". En este caso, el conjunto de especificaciones de la interfaz y una descripción del
comportamiento de los componentes proporcionar toda la información necesaria para diseñar en el
siguiente nivel de la jerarquía. Por otro lado, puede ser iniciado al "nivel base." Aquí se nos da una
planta, por ejemplo, una cámara digital o un servidor de archivos, y la tarea es diseñar un
controlador de conforme al marco de ASV para que pueda convertirse en un sub-sistema viable
dentro de nuestra arquitectura general del sistema. Presentamos este caso el diseño seguidamente.
El primer paso es identificar el "sistemafoco". Es decir, definir con claridad y dar un nombre al
sistema por el que se construye el controlador. El meta-sistema o tipo de meta-sistema al que se
integrará el "Sistema-foco", es generalmente conocido. (El sistema foco suele ser incorporado en
muchos meta-sistemas.) También, definir claramente los sistemas que incorpora el sistema foco, si
los hay. Es útil usar una técnica de diagramación como en la Figura 3. Al referirse a esa figura,
elegimos "1 A + A "como el sistema foco para el resto de esta sección. Nuestro objetivo ahora es
crear el controlador, "1A", para la planta "A". Nosotros nombramos el sistema foco como sistema
A. both
Una vez identificado el sistema foco, el sistema A, se lleva a cabo un análisis detallado. El propósito
de este análisis es determinar los requisitos de rendimiento del sistema A en relación con su meta-
sistema y el medio ambiente. El análisis describe las principales subdivisiones del sistema: Planta,
Control y Medio Ambiente. Los requisitos de rendimiento global del sistema A se especifican como
flujos de información entre sus principales subdivisiones. Esto incluye la identificación de los
sensores y actuadores. El resultado de este paso debe ser un modelo y una simulación del sistema.
Las técnicas de modelado elegidas dependerán de la naturaleza de la planta. Estos van enfocados
desde sistemas "duros " o "suaves" . Los sistemas duros se puede describir explícitamente por
ecuaciones mientras que los sistemas blandos se describen mediante heurísticas (por ejemplo,
basado en reglas). Por lo general, una mezcla de los dos es necesario.
Con la comprensión de un sistema, sus requerimientos funcionales y su simulación, un diseño
detallado de su controlador se puede lograr. Este diseño está necesariamente limitada por la planta y
el meta-sistema en el que deben operar. Es decir, los dos pasos siguientes, el diseño del controlador
y el diseño de la interfaz del meta-sistema están relacionados entre sí. Se describe el diseño de
interfaz seguidamente.
Las interfaces del sistema A con su meta-sistema donde se empotra se determinan (si existe) o
diseñados según sea necesario. Estas son exactamente las nueve interfaces descritas anteriormente y
se muestra en la Figura 4. Tenga en cuenta que hay tres grupos de interfaces para tener en cuenta:
sistema A al meta-sistema (enumerados del 2 al 7), el sistema A con el medio ambiente (0 y 1), y _el
sistema A con otros sistemas en el mismo nivel (2 ' y 6). La naturaleza de estas interfaces se
describe en detalle en la sección anterior. Tenga en cuenta que cada una de estas interfaces entre los
elementos dentro del sistema A, un controlador del sistema y la planta y los elementos del sistema
de otro sistema como se indica en la Figura 5.
El controlador consta de la elementos 2-5 como se muestra en la Figura 3. El problema es ahora
para el diseño. El orden en que fueron concebidos depende de las siguientes consideraciones. Si hay
componentes existentes en el nivel inmediatamente superior, que puede tener una fuerte influencia
sobre la representación de las construcciones fundamentales como las políticas, planes, etc En este
caso, el examen de las interfaces como se describe arriba primero puede indicar un enfoque de
arriba abajo. Es decir, puede ser más fácil empezar con la función ejecutiva (5) . Además, si hay
sistemas en el mismo nivel con la participación directa y conexiones a cabo, el diseño del regulador
(2) para la programación y la coordinación estará parcialmente determinada.
En ausencia de restricciones conocidas, comenzar el diseño del controlador con la triada de
Operaciones-Regulador-Auditor , ya que está más estrechamente asociado con la planta. Esto
corresponde a un "controlador estándar" en la mayoría de los enfoques de diseño del controlador.
En la ASV, el Regulador y el Auditor se distinguen por la naturaleza jerárquica de la estructura.
Tienen vínculos explícitos con los elementos similares con otros controladores en los niveles
superiores y en el mismo nivel. Por tanto, es conveniente para ellos representar como objetos
separados. Ahora, es preciso señalar que sólo en la medida se puede dar en el diseño de un
controlador. El diseño exacto es intrínsecamente dependiente de la planta específica. Las referencias
generales sobre el control se dan al principio de esta sección. Ha sido nuestra experiencia en
dominios tales como entornos inteligentes y de empresa a empresa, de que los elementos de los
enfoques de la teoría de control estándar, la teoría de control difusa y enfoques, basado en reglas
(AI) generalmente se combinan para lograr una solución. Teniendo esto en mente, la orientación
general se imparte.
La función de las Operaciones ejerce un control inmediato de la planta. Lo hace a través de los
sensores y actuadores identificadas en la fase de modelado. En la fase de diseño, la simulación es lo
más importante. La simulación especifica qué variables de control están disponibles para la
manipulación y se utiliza para el prototipo del módulo de Operaciones. Una serie de comandos
básicos se implementa normalmente como Start, Stop, Pause, Reset, etc. En términos de supervición
de la planta, si es posible, una capa de software o en la parte superior de la planta proporciona
informes de estado de rutina en un formato apropiado para las Operaciones y las funciones de
control. Estos informes de estado (sobre las variables internas de la planta) son la principal fuente
de información en la cual el algoritmo de operaciones de control estan diseñadas. Hemos
encontrado un enfoque basado en reglas que ofrece una considerable flexibilidad en la aplicación de
estos algoritmos.
Las operaciones dirigen tanto el regulador y como al Auditor. La principal función del regulador es
la implementación de un Plan. Un plan es un programa de actividades para la planta. El regulador
también coordina el plan con los componentes en el siguiente nivel superior y en el mismo nivel. Es
necesario determinar una representación del plan y sus actividades en relación con las posibles
acciones de la Planta. Una plantilla para representar las actividades que hemos encontrado útil es:
Actividad #: <Acción> <Objeto> [Antes de <Condición>] | [Después de <Condición>] | [Satisfacer
<Condición>] [, si <Condición>] [Donde <Condición>] [, de lo contrario la actividad <#> ].

La regulación es dinámica como los planes pueden ser modificados con frecuencia. Una vez más, la
aplicación del regulador utilizando un enfoque basado en reglas puede ayudar o un planificador
personalizado se puede escribir. En algunos sistemas, un regulador puede estar ya presente de
alguna forma y se puede utilizar directamente. Por ejemplo, la mayoría de bases de datos
proporcionan para el modelado de flujo de trabajo. También puede darse el caso de que la propia
planta contenga un planificador y su uso puede basarse en el enfoque más simple.
El auditor lleva a cabo inspecciones y controles para proporcionar verificación y garantía de las
operaciones que la planta está funcionando correctamente. Esto es además y con independencia del
estado normal o el estado de rutina reportado por la planta. El controlador en un nivel superior en la
jerarquía también pueden imponer condiciones para las variables de la auditoría de planta. Un
beneficio clave del Auditor es que se puede configurar para inspeccionar las variables de control en
momentos esporádicos o al azar. La información obtenida se utiliza para informar las operaciones
en el medio del ciclo de informes del estado de rutina de las plantas. En la implementación de la
función de auditoría que hemos considerado útil para proporcionan también una función separada
Contable de la Planta, si no tiene ya uno. El auditor puede estar directamente conectado con este
contador.
Planificación realiza dos funciones principales: "sintonía" de operaciones y comandos de la
transmisión del Ejecutivo de Operaciones. Mientras que las operaciones se ocupa de control interno
de la planta; Planificación anticipa las condiciones futuras a fin de informar las operaciones.
Planificación hace esto mediante la modificación de los algoritmos de las operaciones de control,
por ejemplo, cambiando las reglas en su base de reglas. Esto se refleja en cambios en las actividades
programadas por el Regulador.
Planificación debe tener un modelo con el fin de cumplir su función. Esto puede tomar la forma de
conjuntos de datos basados en ejecuciones anteriores de la planta. Este enfoque permite la
aplicación de métodos estadísticos para detectar las tendencias que se pueden utilizar para mejorar
los algoritmos de las operaciones de control. Planificación también puede hacer uso de la
simulación de planta desarrollada anteriormente. La simulación puede tomar ventaja de los datos en
tiempo real desde la planta de ejecución, así como los datos obtenidos del Entorno para ayudar a las
operaciones. La segunda función importante de la planificación es la de mediar entre el Ejecutivo y
las funciones de operaciones. Órdenes emitidas por el Ejecutivo se filtran, traducido y,
posiblemente, reordenado basado en el modelo actual de Planificación de la Planta.
Por último podemos diseñar la función Ejecutiva para el controlador del sistema "A". El Ejecutivo
sirve para proporcionar la supervisión general de las funciones de Planificación - Operaciones. Es
decir, se limita el número posible de acciones de los niveles más bajos de control. Elegimos para
expresar estas condiciones que rigen como las políticas. Por ejemplo, un lenguaje para especificar la
política como un conjunto de reglas es [7]:
Regla #: <role> [es] (obligados | Prohibida | Autorizada) [a] [hacer] (<Acción> [Antes de
<condición>] | Satisfacer <condición>) [, si <condición>] [, condición en la que <>] [, de lo
contrario ver Regla <#>].
La política es una síntesis de la política de transmisión de mando de nivel superior y la política
local. El Ejecutivo debe trasladar las normas sintetizadas en las instrucciones y los planes para la
implementación de Planificación y las operaciones. Tenga en cuenta que los términos obligados,
prohibido, y permitido hacen el lenguaje de la política por encima de una especificación declarativa.
Esta forma de regla puede ser usado para probar las afirmaciones sobre el comportamiento del
sistema. Además, las reglas declarativas pueden ser asignadas en los planes (imprescindible) y las
actividades como se describe anteriormente. Una vez más, los enfoques de programación basados
en reglas son apropiados para la aplicación de estos tipos de representaciones del conocimiento.
Esto completa la descripción del desarrollo de un componente viable a partir de una planta
existente. Ahora volvemos al problema de diseño mencionado al principio de esta sección, la de
montaje de componentes existentes en un sistema viable. Hay dos posibilidades: el diseño de un
nuevo componente (en el siguiente nivel superior) para controlar los componentes existentes y la
integración de los componentes de la salida en un sistema existente. En el primer caso el enfoque es
similar a los pasos descritos anteriormente. Es decir, un nuevo controlador está diseñado sobre la
base de los componentes existentes que proporcionan especificaciones de la interfaz de
componentes viables. En este último caso, los componentes viables existentes son ensamblados en
un marco existente. Esto puede requerir extender los componentes en ambos niveles: la dificultad
de esta tarea depende de la flexibilidad de como los componentes se implementan. Puede ser
posible introducir los transductores adecuados (como se muestra en la Figura 5) para permitir el
montaje de los componentes sin cambios. Por último, es factible desarrollar un protocolo para el
ensamblado dinámico de los componentes en los sistemas. El desarrollo de dicho protocolo se ve
facilitada por la estructura de interfaz única de los componentes. Sin embargo, los protocolos de
esta naturaleza son de dominio específico y requiere considerar la experiencia en el desarrollo de
una gama de componentes y marcos de referencia basados en estos componentes.

6. Conclusión
En este artículo hemos mostrado cómo el modelo de sistemas viables de Stafford Beer puede servir
como modelo de referencia para el desarrollo de la arquitectura de un sistema de componentes de
software para atender las necesidades de los sistemas complejos. A esto le llamamos arquitectura de
software de la arquitectura del sistema viable. El aporte clave de la arquitectura es la estructura
única de un componente y su conjunto de interfaces especiales, el "componente viable". Esta
estructura de componentes única recursivamente define el marco en sí. Hemos esbozado una
metodología de diseño para el desarrollo de esta clase de componentes. La metodología se basa en
nuestra experiencia en el desarrollo de entornos inteligentes [8] y los sistemas de negocio a negocio
(b2b) [9]. Actualmente estamos desarrollando una implementación de referencia de la arquitectura
de la plataforma de comercio electrónico en un comercio negocio a negocio (b2b).

Referencias
1. Beer, S., Diagnosing the system for organizations. 1985, Great Britain: John Wiley and Sons
Ltd.
2. Shaw, M., Beyond objects: A software design paradigm based on process control. ACM
Software Engineering Notes, 1995. 20(1).
3. Herring, C. and S. Kaplan. Cybernetic Components: A Theoretical Basis for Component
Software Systems. In Component Oriented Software Engineering Workshop (COSE'98).
1998. Adelaide, Australia: (http://www.dstc.edu.au/TU/staff/herring/cose98-ref.pdf).
4. Herring, C. and S. Kaplan. Viable Systems: The Control Paradigm for Software Architecture
Revisited. In Australian Software Engineering Conference. 2000. Canberra.
5. Passino, K.M. and S. Yurkovish, Fuzzy Control. 1998, Reading, Massachusetts: Addison-
Wesley.
6. Franklin, G.E., J.D. Powell, and A. Emami-Naeini, Feedback control of dynamic systems. 2
ed. Control Engineering, ed. T. Robbins. 1991, Reading, Massachusetts: Addison-Wesley.
7. Steen, M. and J. Derrick. Formalizing ODP Enterprise Policies. in Proceedings of Enterprise
Distributed Object Computing Conference (EDOC'99). 1999.
8. Herring, C. and S. Kaplan, Component-based software systems for smart environments, in
IEEE Personal Communications. 2000.
9. Herring, C. and Z. Milosevic. Implementing B2B Contracts Using BizTalk. in Thirty-Fourth
Hawaii International Conference on System Sciences (HICSS-34). 2000. Maui, Hawaii:
submitted.