Interfaces para Clientes CSAT

[Jorge Ibsen]

Hola,

Estuve mirando la pagina y tengo algunas preguntas:

00)Como una regla general, seria bueno agrupar toda la terminologia 
usada en las paginas en un glosario en el Twiki y agregar referencias al 
glosario cuando sea pertinente.

0)https://csrg.inf.utfsm.cl/twiki4/bin/view/ACS/ControlAmateurTelescope 
muesta un diagrama de componentes. Son esto ACS components, o se 
refieren a otra definicion de componentes? Seria bueno que definieran 
cuales son todos los elementos considerados en este software de 
observacion y expresar claramente cuales son las responsabilidades 
asociadas a cada uno de ellos. En particular ese diagrama debiera 
mostrar claramente cual es el rol del CSAT y que intereacciones tiene 
con los otros elementos.

1)Porque estan acoplando el telescopio con la adquisicion de imagenes de 
la camara? Esto asocia responsabilidades que no debieran estar en el 
control del telescopio. El control de la camara debiera ser un 
componente independiente y esta fuera del scope del CSAT. La 
coordinacion entre el telescopio y la camara sedebe hacer desde un 
componente de mas alto nivel, parte del observing software, pero fuera 
del CSAT (ver punto 0)

2)Cual es la interaccion entre los dos componentes propuestos: 
CSATControl y CSATStatus? Es posible clarificar esto a traves de un 
diagrama?

3)Una pequena introduccion y ejemplos acerca de las transformaciones de 
coordenadas que se usan en un TCS se puede encontrar aca: 
http://www.ing.iac.es/~docs/external/starlink/sun67/node195.html. En 
particular seria bueno que se consiguieran algunos de las referencias 
que se mencionan en la pagina. La siguiente pagina 
http://www.ing.iac.es/~docs/external/starlink/sun67/node200.html#SECTION00053000000000000000 
da una idea acerca de los sistemas de coordenadas celestiales (en 
particular miren el diagrama). En particular noten que la posicion de 
los objetos estelares se especifican de maneras diferentes dependiendo 
del catalogo usado, y que esto tiene impacto en los tipos de data a definir.

4)Calibrating sounds more like a transition than a state. Por regla 
general me gustan mas los nombre SHUTDOWN, STANDBY, ONLINE. A modo de 
ilustracion en el VLT se usaba: OFF, INIT, STANDBY, ONLINE. La 
transicion entre OFF e INIT era inicializacion de HW, y entre INIT y 
STANDBY una inicializacion de SW (threads, resources, etc), pero el 
sistema no es operable. STANDBY to ONLINE deja el sistema listo para 
hacer operaciones sobre el HW. A lo mejor era esto lo que se tenia en 
mente con "calibrating" y la eleccion de nombres no fue muy buena. No 
entiendo el sentido de AUTOMATIC.

5) Seria bueno considerar en el disenno la posibilidad de tener un nivel 
de simulacion para los devices de HW. Frecuentemente es necesario que 
algunas funciones de HW se puedan simular en run time para hacer un 
bypass en caso de algunos tipos de falla. No tengo muy claro como se 
puede hacer esto, pero conviene tenerlo en mente.

6)Seria bueno agregar una explicacion a los metodos propuestos para los 
IDLs (y mejor escribir los IDLs!). En particular, cual es que proposito 
de set/getTrackingStatus, initialize, getSafety, setMode? Emergency 
stops se implementan normalmente en HW, no en SW.

7)Acuerdense que el objetivo de este ejercicio es tambien iterar un 
diseno de interfaces suficientemente genericas para el gTCS, asi que por 
favor no olviden que la interfaz del LEGO model tiene que ajustarse para 
caer como especializacion de la interfaz generica. Tengan siempre al 
LEGO como el segundo telescope type.

8)Porque tantas tipos de GUI para el CSAT? Seria interesante considerar 
tambien el uso de un web browser para comandar el sistema. :)

Eso es todo por el momento.

Saludos,

Jorge

Mauricio � wrote:
> Hola a todos,
>
> Para darle fuerza a esta lista (de ahi pasamos la discusion a la lista
> en ingles), queria que comentaramos las interfaces para los clientes
>   
> de CSAT (Control System for Amateur Telescope). El otro dia con Rodrigo
>   
> Tobar y los chicos del proyecto Hevelius (cascara grafica en java para el
> Am-TCS) definimos dos interfaces ofrecidas por el Am-TCS hacia los 
> clientes,
> como una GUI o una consola. Tambien Norman Saez, que hara toda la 
> parte del
> scheduler estaba presente.
>
> https://csrg.inf.utfsm.cl/twiki4/bin/view/ACS/PublicInterfacesDiscussion20070725
>
> Aun no estan IDLizadas, pero ahora luego estaran.
>
> Comentarios?
>
> Saludos!
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ACS-es mailing list
> ACS-es en listas.inf.utfsm.cl
> http://listas.inf.utfsm.cl/mailman/listinfo/acs-es
>