Temas
¿Qué es ALMA?
El proyecto Atacama Large Millimeter Array (ALMA) tiene su origen el año 1999, a partir de tres proyectos independientes, el Europearn Large Southern Array (Europa), The Millimeter Array (USA) y Large Millimeter and Submillimeter Array (Japón). El objetivo principal consiste en contribuir a la radioastronomía, a través de un arreglo móvil de 64 antenas de 12 metros de diámetro (Foto 2) operando en el orden milimétrico y submilimétrico de longitudes de onda. Dada la alta resolución que puede alcanzar este arreglo (comparable a una sola antena de un solo plato), se podrá observar componentes como el carbono, lo que ayudaría a estudiar como se dió origen a la vida.
Foto 1: Localidad de Chajnantor en el desierto de
Atacama, Chile
|
Se ubicará en el desierto de Atacama, Chile, a una altura de 5000 mt de altura, en la planicie de Chajnator (Foto 1), lugar considerado único en el mundo por sus condiciones ambientales y climáticas que favorecen la radioastronomía.
Foto 2: Proyecto ALMA
|
La subsistencia a 5000 mt de altura es tanto difícil para humanos como para los equipos e instrumentos, por lo que este arreglo de antenas estará completamente automatizado y será maniobrado desde un centro de control ubicado a sólo 2900 mt de altura cerca de la localidad de San Pedro de Atacama. Dadas estas condiciones se entiende la importancia de contar con un software que permita efectuar un control estable y confiable sobre las instalaciones. ACS es el nombre del software desarrollado para tal efecto.
1.- ACS
Plataforma Común
Debido a la naturaleza del proyecto ALMA, desde sus origenes se ha caraterizado por la complejidad de la extensa distribución geográfica (disperso a lo largo de todo el mundo FOTO 3) de su grupo desarrollador y sus diversas culturas para desarrollar. Se espera que la cantidad de aplicaciones y desarrolladores siga creciendo a números mucho mayores con el paso del tiempo.
Foto 3: Distribución Geográfica Grupo Desarrolladores
|
2.-Arquitectura de ACS
La arquitectura de ACS está basada sobre un
modelo Componente/Container, el cual es independiente del lenguaje y la
plataforma. Los containers se encargan de administrar el ciclo de vida de los componentes y permiten una
manera muy simple de acceder a los servicios centralizados nativos
(administrados por el Manager), como lo
son el logging, alarmas, manejo de errores, canal de comunicaciones, archivos y otros, ocultando al
mismo tiempo la mayor parte de CORBA.
Un cliente, que bien puede ser un
componente de otro container, accede a los servicios de otros componentes, a
través de los servicios registrados en el container por el componente. Cada componente debe registra
en el Container sus interfaces en un archivo IDL. En
estos casos el container hace las funciones de mediador y se le llama un
contanier "tight" (de enlace). Por ejemplo en la figura 1 un cliente intenta acceder a
los servicios de los componentes 1 y 2, estos han publicado en el container
su lista de servicios, y es asi como el contanier recibe la petición del
cliente y se comporta como enlace entre el cliente y el comnponente que esta
brindando algun servicio. Existe otra manera de acceder a los servicios de
una componente, y que es la señalada por el componente 3 de la figura 1. Si
bien el cliente necesita del container en un comienzo para que indique cual
es el componente adecuado, el cliente establece una conexión directa con el
componente. En esta caso se le denomina al container "porous" (poroso).
Estos dos modos reflejan el uso esperado de este modelo en data flow y areas de control
respectivamente. Explicado de manera simple, en modo "tight" un requerimiento solicitado por un cliente
se ejecuta en el Container, el cual a su vez ejecuta el Componente. Por otro lado en modo "porous"
el cliente se comunica directamente con el componente y se ejecuta por sí solo.
Figura 1: Modos de acceder a los servicos del modelo Componente/Container
|
ACS posee un único Manager, implementado en JAVA por razones de mantención y portabilidad, el cual se preocupa de coordinar el manejo de los containers. Si un componente desea acceder a un servicio se lo comunica a su container, y este a su le comunica la solicitud al Manager el cual provee el servicio. El Manager administra TODOS los servicios nativos, lo cual le da un caracter centralizado al modelo.Resulta muy cómodo entonces el desarrollo de componentes para los desarrolladores, ya que estos no se deben preocupar de ningun aspecto de comunicación de redes, ni de sistemas distribuidos, ni de canales de comunicación de datos, tan sólo deben solicitarlo al container y de esta manera ocupar los servicios que el framework provee.
2.1-Modelo Componente Container
El Componente es por así decirlo el "átomo" de ACS, representa la unidad de desarrollo y en conjunto con otros componentes conforman (sub)sistemas. Cada componente tiene Propiedades y Características, además éstos se ejecutan dentro de los Containers y tienen definido un "ciclo de vida" (ver figura 2). Las Propiedades de un componente son por así decirlo las "variables" de interés y las características sus atributos. Por ejemplo si una componente representa una fuente de poder, se podría decir que sus propiedades podrían ser el voltaje y la corriente (o la potencia, étc.), a su vez las caraterísticas serían el modelo de esa fuente, por ejemplo Vmáx, Vmin, Imáx, Imin, étc. Toda esta información se modela en un archivo XML y se almacena en la CDB.
Figura 2: Modelo de un Componente
|
Un Container puede contener muchos Componentes y es responsable de administrar el ciclo de vida de ellos (ejecutar, detener, cargar, configurar, étc.). Además un Container debe proporcionar la comunicacion de los Componentes con el Manager y debe manejar los aspectos técnicos como: selección y configuración de varios ORB´s, seleccionar servicios de CORBA e integralos con ACS, acceder a otros Componentes o Recursos, entre otros, ocultando de esta manera una gran dificultad a los desarrolladores.
Figura 3: Interfases de un Componente
|
Un Container posee ciertas interfaces de servicio para sus componentes (logging, sistema de alarma, étc.). Los Containers son elementos que no se pueden distribuir en varias máquinas.
ACS tiene gran parte de estructura implementada con el modelo Componente-Container.
2.2-El Manager
El Manager se comporta como un "agente" (broker) de componentes, ofreciendo los servicios que estas proveen a otras componentes, aplicaciones o subsistemas. Actualmente debe existir un sólo Manager en el Sistema,lo cual en algún momento podría transformarse en un "cuello de botella" si es que se hicieran muchas peticiones de componentes por unidad de tiempo. Por esta razón se trabaja hoy en dia en desarrollar un sistema Multi-Manager.
El Manager debe tener concimiento sobre todo los componentes y con esto mantener una lista de ellos, la cual debe ser almacenada en una "in-memory" Database.
Las aplicaciones CORBA, que no son soportadas por ACS, pueden tener acceso a las componentes de igual manera, ya que el Manager se integra estrechamente con CORBA Naming Service.
2.3-Interacción Componente-Container-Manager
A continuación se detalla paso por paso como se produce la interacción entre Componentes-Container-Manager:
Se ejecuta el Manager y la CDB
Los Containers se registran con sus nombres en el Manager
Se asume que un Componente se está ejecutando en este momento...
El componente solicita una referencia a otro Componente, desde su Container
El Container consulta al Manager por ese Componente Solicitado
El Manager consulta a la CDB, ¿Que container puede ejecutar ese Componente?
El Manager le dice al Container que cargue el nuevo Componente
El Container retorna una referencia de este nuevo Componente al Manager
El Manager retorna la referencia del nuevo Componente al primer Container
Finalmente el Container le entrega a su Componente la referencia del nuevo Componente
Se puede establecer una conexión directa entre los Componentes, o puede ser a través del Manager
Figura 4: Interacción entre Componente-Container-Manager
|
2.4-Paquetes de ACS
ACS tiene una clásica estructura de "layers" (capas), en la cual los paquetes pueden ocupar servicios brindados por otros paquetes de la misma capa o inferiores, pero no de capas superiores. La figura 5 muestra los principales paquetes en los cuales está dividido.
|
| Figura 5: Principales Paquetes en los que ACS está Subdividido |
ACS Componente:2.4.1 Capa 1 "Base Tools"
La
capa inferior de ACS, provee de
herramientas de desarrollo y del
Runtime Enviroment que corre sobre el Sistema Operativo. Está
compuesto por Herramientas de Desarrollo (compiladores, debuggers,
generadores de documentación), CORBA Middleware (ORB´s y servicios de CORBA)
y por ACE (Adaptative Communication Enviroment), el cual es un entorno de
comunicaciones con otras plataformas e implemeta patornes de diseño
específicos de sistemas distribuidos.
2.4.2 Capa 2 "Paquetes del Núcleo"
La
segunda capa asegura un modelo estándar de interfaces e implementa los
servicios esenciales para el desarrollo de cualquier aplicación. Estos
servicios son:
Soporte para Componentes.
Configuration Database (CDB):
Este paquete se encarga de solucionar los problemas que genera definir, accesar y mantener la configuarción de un sistema en tiempo de ejecución (runtime). Cada Componente del sistema tiene ciertos parámetros de configuración que deben ser configurados con un método persistente de almacenaje y lectura (store and read), cada vez que se invoca o se re-inicializa la Componente.
Data Channel:
Provee un mecanismo genérico de comunicación asincrónica entre proveedores de información y consumidores de información.
Error System:
La información de un error se propaga de servidor (que genera error) a cliente y puede informar exactamente donde se produjo.
Logging System:
Mecanismo General para registrar estados, eventos y condiciones anómalas.
Time System:
Implementa los servicios básicos de tiempo como sincronización, conversiones, información, étc.
ACS Container:2.4.3 Capa 3 "Servicios"
Esta
capa contiene los siguientes servicios:
Soporte para Containers.
Serialización:
Se preocupa de hacer el transporte de entidades.
Sampling:
paquete que sirve para monitorear variables en le tiempo.
Archiving System:
Herramientas API y servicios para monitorear Propiedades de Componentes (200 Hz) y Data Channel
Sistema de Alarma:
Para hacer uso de este sistema, las aplicaciones se deben registrar en el servicio de alarma. Las alarmas hacen notificación asincrónicas de condiciones anómalas en el sistema y poseen un mecanismo de histéresis. Por ejemplo una aplicación que controla el voltaje de una fuente de poder posee una alarma seteada en 10[V], si la fuente sube su voltaje a este valor entonces se activa la alarma. Esto provoca una reacción. Luego para desahabilitar la alarma el valor del voltaje debe bajar a 8[V].
2.4.4 Capa 4
"API´s y Herramientas de Alto Nivel"
El
objetivo principal de esta capa es ofrecer un entorno claro para el
desarrollo de aplicaciones. Implementa entornos gráficos y aplicaciones de alto nivel.