Caso Estudio-RasBus

RasBus es un sistema que ha sido pedido por MetroBUS. El resumen inicial del sistema se da a continuación.

MetroBus quiere un sistema llamado RasBus que rastrea buses. Esta empresa quiere adicionar GPS a todos sus buses para que puedan rastrearlos en cualquier ubicación en un área de 100 metros. Ellos usarán esta información para proveer un tiempo estimado de llegada de los buses a cada una de las paradas principales.

La unidad que se instalará en cada bus consiste de un receptor de Sistema de Posicionamiento Global (GPS), un transmisor de radio, y otros componentes de hardware y software. El receptor GPS puede determinar su posición en un área de 10 metros cada segundo. Y si está calibrado apropiadamente, este puede rastrear confiablemente la posición del bus y la velocidad en a través de la ruta. El GPS transmite la información, junto con el identificador del bus al sistema RasBus regularmente.

Las paradas principales son donde convergen varias rutas de buses. Típicamente 20 o más buses llegan a estas paradas durante las horas pico de viajes. El visor planeado tendrá un receptor GPRS y espacio para mostrar cuatro o cinco números de buses y los tiempos asociados a estos buses.

El visor debe desplazarse repetidamente a través de todos los buses cuyos tiempos de llegada estimados a esa parada se encuentran dentro de la siguiente hora. Una vez el bus está a 1 kilometro (que es a casi 2 paradas) del visor, el tiempo estimado de llegada debe estar entre 2 minutos del tiempo actual, con una probabilidad del 95%. Todos los otros visores deben mostrar un tiempo estimado en “el mejor esfuerzo”.

Arquitectura del Sistema.

Algunos aspectos del sistema se restringen a continuación:

• Existirá un solo receptor de radio (GPRS) para las transmisiones de los buses en la ciudad. Esté se localizará en un lugar que cubra todos los posibles lugares desde donde un bus pueda transmitir.
• MetroBus tiene un número de edificios donde un computador puede ser ubicado y puede recibir la información del receptor de radio, vía Internet.
• El hardware en el bus puede transmitir un mensaje cada segundo conteniendo un ID de bus único, fecha y hora, y ubicación. La fecha y hora y ubicación llega del receptor GPS.
• Se mantendrán datos históricos de los tiempos de viajes por 24 meses.
• El visor tiene un identificador único. Este recibe información desde el sistema central, no desde los buses. No existe comunicación entre el bus y el visor en cualquier dirección. Tampoco hay comunicación entre el visor y el sistema central. El visor solo recibe información desde la central y la muestra.
• El visor debe ser actualizado no más de una vez por minuto.

Notas de los requisitos funcionales.

• La funcionalidad principal es que los clientes de los buses mirarán información acerca de sus buses en una estación de bus dada. Esto puede ser considerado como si el cliente solicita información de llegada de los buses.
• El visor debe informar la hora actual, el número de bus, y el tiempo estimado de llegada de todos los buses que se estiman que lleguen dentro de 1 hora.
• Si un bus está programado para llegar antes del tiempo de solicitud de información, pero se espera que llegue después del tiempo de petición (ej. Está retrasado), debe ser aun listado ya que su tiempo de llegada esperado está dentro de una hora.
• Si un bus está programado para llegar dentro de 50 minutos de la hora de la solicitud, pero este lleva 15 minutos retrasado (por lo que el tiempo estimado de llegada es más de una hora), aún debe aparecer porque está programado para llegar dentro de una hora.
• La funcionalidad importante es mostrar, en una parada de buses con  visores, el tiempo estimado de llegada de los buses que paran en esa parada de buses. Hay otras funcionalidades que pueden ser deseables, tales como:

• Dar el tiempo estimado de llegada para el siguiente bus después del tiempo de solicitud en una ruta dada en una parada especifica (por web).
• Dar el tiempo estimado de llegada de todos los buses que pararan en una parada después de una hora dada.
• Listar todos los buses que paran en una parada de buses.

Detalles y Problemas

Existen algunos problemas que se deben considerar.

• Hay varios requisitos no funcionales que considerar (o consecuencias de los requisitos no funcionales)

• El principal es el desempeño. Existen requerimientos que implican que tan precisa es la información que se muestra en los visores. Para poder lograrlos, se requiere traer información al visor oportunamente. Para hacer esto, se requiere hacer la estimación en una manera oportuna, lo cual tiene implicaciones de procesamiento. Para hacer esto, se requieren las entradas al algoritmo de estimación, lo cual tiene implicaciones de almacenamiento. Las entradas a los algoritmos de estimación incluyen (al menos) la posición actual del bus y su velocidad, de esta manera existen implicaciones de ancho de banda de comunicación y almacenamiento. Entre otras cosas.
• El sitio Web y el acceso telefónico fue mencionado principalmente para dar una indicación de que puede existir desarrollo futuro. Esto tiene implicaciones sobre algunos atributos de calidad.
• Nunca se dijo, pero es casi seguro que se espera que el sistema dure un rato (décadas en vez de años). Esto tiene implicaciones en los atributos de calidad.

• Si la información que un visor recibe toma más de un minuto para desplazarse, entonces se va a pedir menos de una vez por minuto. Si se tarda menos de un minuto, entonces se volverá a mostrar en vez de actualizarla. (Se asume que no habrá tanta información para mostrar para que se cause un problema. Se supone que hay 40 informaciones de buses para mostrar. El visor puede mostrar 5 de ellos al tiempo. Si este desplaza uno hacia arriba cada segundo, se tomará 45 segundos para mostrarlos todos al menos 5 segundo (1 segundo cada fila).
• Asumir que hay 100 paradas principales y 1000 buses en las rutas en cualquier momento.
• “Regularmente” puede ser una definición vaga. En el primer párrafo, se menciona que debe ser capaz de localizar un bus dentro de 100 metros. Si el bus está parado (parada de buses o semáforo), entonces este no necesita transmitir cada segundo. Pero si el bus está viajando a 100 km/h (sea o no sea legal), este puede hacer 30 metros en un segundo, así que tal vez se requiere transmitir más frecuentemente que cuando está parado. Se debe decidir acerca de esto.

Notas Adicionales

Cosas para tener en mente.

• Se supone que se debe definir la arquitectura de software para RasBus. También se debe pensar en el hardware, pero no gastar mucho tiempo en eso – Tomar decisiones razonables y diseñar el software con base en estas. (Una situación no realista – se solicita diseñar software para hardware que ya se compró.
• Hay muchas cosas que se necesitan saber para algunas labores. Ej: Capacidad de procesamiento de los diferentes procesadores, costos en memoria. Para ese caso se debe hacer un supuesto razonable.

Puedes hacernos llegar este Caso de Estudio resuelto y con gusto te daremos retroalimentación, envíalo por favor a info@likecomtic.com

...