Manual Explotación de la Red Vial
& Sistemas Inteligentes de Transporte
Guía para profesionales!
Hay dos maneras de crear una arquitectura ITS, ya sea a partiendo de cero, o modificando una arquitectura ITS existente. Ambos enfoques están directamente relacionados con el tipo de arquitectura que sirve de base par el proceso (que podría ser o bien una arquitectura de "modelo" como la Arquitectura ITS Nacional de Estados Unidos o de una arquitectura Marco como la Arquitectura Marco europea).
Ha habido mucha experiencia con la investigación de ITS, el desarrollo y despliegue - que es capturado en dos arquitecturas ampliamente usadas que existen en la actualidad. La arquitectura Modelo Estadounidense y la arquitectura Marco han evolucionado con ITS en los últimos 20 años. Ambos se han refinado para mantener el ritmo del desarrollo de ITS y el despliegue de las dos regiones - y con base en ellas se han desarrollado estándares nacionales e internacionales. En estas condiciones, sería muy costoso un desarrollo de una nueva arquitectura "de la nada". Adaptar o adoptar una definición funcional de ITS de las arquitecturas existentes ofrece un enfoque rentable para una nueva definición de la arquitectura siempre que el usuario local necesita abordar la estructura institucional y el contexto de transporte (como el paquete de servicios al usuario, las opciones modales y la composición del tránsito). Estos pueden variar considerablemente de las suposiciones inherentes en las arquitecturas de EE.UU. o Arquitectura Marco.
Las dos formas de crear una arquitectura (comienzo de la nada o adaptar una arquitectura existente) comparten un punto de partida común, la descripción de los servicios que el despliegue de ITS va a proporcionar - que tiene que reflejarse en la arquitectura ITS. El proceso se puede resumir como sigue:
Las descripciones de servicios -> Necesidades de usuario -> Definición Funcional -> Particiones físicas -> Comunicaciones -> Vínculos con los estándares.
En el proceso que se muestra arriba, cualquier concepto detallados acerca de cómo los servicios se van a entregar serán parte de las "necesidades de los usuarios". Estos se refieren a menudo como "conceptos operativos" y "requisitos operativos" y son limitaciones que deben aplicarse en el proceso de implementación de ITS tras la creación de la arquitectura ITS. Ejemplos de ello son un servicio que "debe estar disponible durante todo el día todos los días (es decir 24/7)", o un servicio que "debe estar disponible en la misma manera en todas partes". Para resaltar la importancia de estos conceptos, los mismos se expresan mejor en un Concepto de Operaciones (CONOPS), documento que contiene la descripción de cómo los servicios van a funcionar. Para ello, el documento requiere la colaboración de algunos de los puntos de vista de arquitectura creados más adelante en el proceso de creación de la arquitectura ITS. Así, pese a la creación del documento ConOps puede iniciarse desde el principio en este proceso, no se puede completar hasta que esté cerca de su fin. (Ver Usando la arquitectura ITS)
Describir los servicios que la implementación ITS va a proporcionar es el primero y más importante de los paso en la creación de la arquitectura ITS . Es la base para todas las actividades posteriores de desarrollo de la arquitectura (Ver Recursos)
Para generar la descripción de cada servicio es mejor empezar por tener un diálogo entre el equipo de arquitectura y los que quieren que el servicio sea prestado - normalmente se conoce como grupos de interés y que puede ser cualquiera de los siguientes:
El proceso de comprometerse con los grupos de interés consiste en una secuencia de actividades:
El equipo de desarrollo tendrá que conocer los Grupos de interés principales, ya sea individualmente o como grupo, como "usuarios de la carretera", o un "círculo de calidad". (Ver Planificación e Informes)
Otro grupo que se debe consultar son los legisladores para que los servicios que la arquitectura ITS ofrece apoyen las políticas nacionales y regionales. (Ver Por qué Crearla?) Si una declaración de "visión" para la Implementación ITS ha sido producida - los que la desarrollaron tendrán que ser consultados. Otra alternativa es seleccionar grupos de interés por lo que hacen (su función) - tal como:
En estas reuniones, sólo pidiendo a los asistentes que servicios de ITS que les gustaría ver puede no producir ningún detalle real de los servicios que los grupos de interés realmente quieren, evitando de esta manera conocer las aspiraciones reales de las partes interesadas. A menudo, se logrará más al discutir lo que hace cada grupo de interés, los problemas que tienen actualmente (por ejemplo, resultado de la política de entrega o el desarrollo de servicios de usuario) y la forma en que sus actividades se desarrollarán en el futuro. Una pregunta útil para hacer es "¿cuáles serán las principales actividades de la organización en 3-5 años?" Este tipo de pregunta centrará la discusión sobre cuáles son las características o instalaciones ITS que son deseables en el futuro.
El equipo de arquitectura tendrá que ser representado por al menos 2 personas - uno para liderar la discusión y el otro para tomar notas. Cada reunión debe ser planeada para durar el tiempo suficiente para explorar los temas en profundidad (a menudo entre medio día y un día entero en función del número de asistentes). Cuántas reuniones será necesario depende del número de grupos de interés y si el equipo se reune con ellas de forma individual o en grupos. Las ventajas de cualquiera de las opciones son:
Cuando se hayan completado todas las reuniones, el equipo de arquitectura necesita producir un informe que describe cada uno de los servicios que los grupos de interés quieren (las descripciones de servicio) incluidos en la implementación ITS. El resultado final debe ser un conjunto acordado de descripciones de servicios que los Grupos de interés están dispuestos a apoyar a través de su compromiso con el apoyo a la implementación ITS.
Este enfoque crea la arquitectura ITS como algo nuevo, a partir sólo de las descripciones de los servicios producidos en conjunto con los grupos de interés. Este enfoque no es recomendable por las siguientes razones:
Hay algunas herramientas de software especializadas disponibles para la creación de arquitecturas ITS. Los dos más utilizados son probablemente System Architect de IBM y la herramienta Mega Process business modelling de Mega Internacional.
Partir de una arquitectura ITS existente es normalmente la mejor manera de crear una nueva arquitectura ITS. Se basa en la experiencia adquirida en la creación de la actual arquitectura ITS - con el beneficio de ayuda disponible de una o más fuentes, si es necesario. Hay dos opciones ampliamente utilizados para la elaboración de arquitecturas ITS de esta manera:
Una arquitectura ITS que ha sido desarrollado por un conjunto de circunstancias puede ser adaptado y utilizado como un punto de partida para otras arquitecturas ITS otra parte, si las circunstancias son similares. Por ejemplo, una Arquitectura ITS creado por cada región podría ser adaptada con éxito a otra región con modificaciones adecuadas. En general, el proceso de desarrollo de la arquitectura ITS sigue la secuencia:
Las descripciones de servicios -> Necesidades de usuario -> Definición Funcional -> Particiones físicas -> Comunicaciones -> Vínculos con los estándares.
Los "conceptos operativos" y "requisitos operativos", explicados más arriba deben incluirse en las necesidades del usuario y serán importantes en las etapas posteriores en el proceso de implementación ITS. También deben ser cubiertos por el documento de Operaciones. (Ver Usando la arquitectura ITS)
El proceso anterior se aplica a cualquier creación de cualquier arquitectura ITS. Tanto la Arquitectura Marco europea y como la Arquitectura Modelo de Estados Unidos, ambas proporcionan entradas a cada una de estas etapas del proceso en diferentes maneras. Donde el punto de partida es:
Antes de hacer una elección entre los dos puntos de partida, es importante que se discutan y respondan a las siguientes preguntas:
Las respuestas a estas preguntas le ayudarán a decidir cuál es el método que se utilizará para crear la arquitectura ITS. Cualesquiera que sean las respuestas, tenga cuidado si se utiliza el enfoque de "empezar de cero", ya que requerirá un fuerte compromiso de recursos durante un largo periodo de tiempo sin el beneficio proporcionado por una comunidad ITS ya existente.
Elegir entre las dos opciones para "adaptar una arquitectura ITS existente" es un equilibrio entre las siguientes cuestiones:
Si los servicios descritos por los Grupos de interés tienen un "sabor de EE.UU.", entonces la Arquitectura Nacionales ITS de Estados Unidos es el punto de partida obvio - sobre todo si se utiliza para una implementación sola. En este caso, es sólo el contenido de los servicios lo que es el factor decisivo.
Si no hay una buena correspondencia entre los servicios seleccionados por los Grupos de interés y los servicios de usuarios de los Estados Unidos o paquetes de servicios, entonces la Arquitectura MARCO es un punto de partida mejor, ya que será más fácil de adaptar.
Las economías en desarrollo pueden tener poco o nada de los componentes o de las comunicaciones que ITS requiere. Esto significa que la arquitectura ITS estará describiendo lo que puede ser visto como una implementación ITS "terreno virgen". Es tentador pensar que la mejor manera de avanzar es adoptar el enfoque "de la nada". Esto no es necesariamente cierto por razones de costo, complejidad y la falta de soporte de una comunidad ITS a la arquitectura.
Un estudio de caso está disponible en el diseño del Abu Dhabi Integrated Transportation Information and Navigation System " i-TINS". (Ver Case study)