|
|
|
Arquitectura del Sistema Sirena (1/2)
|
|
|
|
|
| 1.1. Software |
|
|
SIRENA ha sido implementado usando VisualBasic V 6.0. y Visual C++. La parte de cálculo está (por razones de eficiencia) implementada en FORTRAN 77 en ambiente unix (RedHat LINUX 7.3) pero podría entregarse en ambiente Windows de ser requerido e implementado en C.
El hardware utilizado es estándar, para el caso de TV se ha utilizado al presente una tarjeta marca Genius Wonder Pro II. Las tarjetas de sonido han sido SoundBlaster Compatible. Las pruebas preliminares han sido satisfactorias con dos tarjetas de sonido por máquina capturando simultáneamente, y se espera que se pueda operar con hasta tres tarjetas por máquina es decir hasta un máximo de 6 señales por máquina. |
|
|
|
|
|
1.2. Base de datos
|
|
|
|
El sistema es compatible con cualquier DBMS (Manejador de base de datos) que cumpla con el estándar de ANSI SQL. La base de datos utilizada y probada es MySQL. El sistema se comunica vía OLEDB para drivers ODBC. Este driver se comunica directamente con el DBMS vía TCP/IP. Es decir que todo sistema que cumpla con el estándar podrá ser utilizado como DBMS, simplemente hay que instalar en la máquina cliente el driver específico para ese DBMS.
|
|
|
|
|
|
1.3. Aspectos de Seguridad
|
|
|
Si bien no se espera que SIRENA sea un sistema expuesto a ataques, se han tomado algunas precauciones para controlar el acceso a sectores críticos. Existe el rol de ADMINISTRADOR, quien está habilitado a ciertas tareas como:
- Dar altas/bajas/modificaciones a usuarios de tipo operador
- Crear, modificar o eliminar grupos de usuarios
- Manipular indirectamente el archivo maestro de anuncios, incluyendo
- Dar de baja un anuncio
- Modificar alguno de sus datos
- Actualizar el sonido/video de un clip utilizando una instancia diferente
- Forzar la reapertura de una hora ya trabajada
- Actualizar lista de emisoras, horarios a grabar, etc.
- Revisar el estado de las horas ya trabajadas.
|
Es posible definir múltiples usuarios con privilegios de ADMINISTRADOR, así como se hace con los OPERADORES. Los operadores tendrán que identificarse para ingresar al SIRENA.
Estarán habilitados a operar con las horas disponibles para ello, y tendrán control sobre las mismas hasta dar el cierre. También es posible que cierto grupo de operadores se concentren en determinado tipo de emisoras. Esto implicaría que un operador a la hora de buscar una hora disponible para trabajarla solo podrá ver las horas disponibles de la(s) emisora(s) que tiene asignadas.
Se generará un log de sus accesos al sistema, y además otro local que se conservará sólo durante la sesión. La necesidad de identificarse permitirá eventualmente hacer un seguimiento sobre su desempeño, productividad, niveles de error, etc. aspectos útiles a otros fines pero no implementados en el software actualmente.
|
|
|
|
|
|
1.4. Aspectos de Confiabilidad
|
|
|
Como se verá en lo que sigue, el núcleo del sistema es una máquina que opera con el nombre de SERVER y es la que administra el flujo de información entre los otros equipos. No necesita ser una máquina excepcionalmente poderosa, ya que las tareas de cálculo, operación, DBMS, etc. pueden residir en otros equipos. El sistema es tolerante a fallas del SERVER mediante un procedimiento de recuperación automático en el que otras máquinas previamente designadas van asumiendo ese rol. La eventual falla del resto de los equipos tiene distintos efectos:
- la falla de un equipo RECORDER es la más grave ya que podría perderse la señal en vivo. La experiencia sugerirá si es necesario en la práctica recurrir a una grabación duplicada
- la falla de un equipo STORAGE dependerá del estado de avance del procesamiento: si ya ha sido procesado, sólo complicará algún proceso de auditoria. En otro caso, y dado que la versión comprimida del archivo se guarda en una máquina diferente será posible reconstruirla a partir del .wav original, o será posible procesarla pero no revisarla por parte de los operadores en otro caso.
- la falla de un equipo PROCESS es indiferente; la tarea quedará pendiente de culminación y el SERVER tendrá incorporados timeouts para cancelar las que no se cumplan en un lapso prudencial
- la falla de un equipo OPERATOR es en algún aspecto similar a la anterior. El trabajo del personal que está en el equipo se guarda en archivos locales mientras no se hace el cierre de la hora en procesamiento. En caso que haya necesidad de reiniciar el SIRENA éste recupera automáticamente su estado previo. En caso que la falla sea tal que el equipo no puede reiniciarse o recuperarse, la pérdida es a lo sumo en el trabajo de edición; los anuncios dados de alta ya fueron actualizados en el SGBD y no se pierden.
- la falla del equipo con el DBMS es siempre un problema, el que puede manejarse con procedimientos estándar mediante espejado, redundancia, etc.
|
Para los interesados en más detalles, seleccione aquí
|
|
