Manual Explotación de la Red Vial
& Sistemas Inteligentes de Transporte
Guía para profesionales!

Se encuentra usted aquí

¿Cómo crear una arquitectura ITS ?

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.

Conceptos Operativos / Requisitos Operativos

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)

Describiendo los Servicios

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)

Consulta con los Grupos de Interés

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:

  • Los responsables de la gestión del tráfico y operaciones de la red de carreteras
  • Los que "usan" los servicios de ITS, como los viajeros y las organizaciones que  transportan personas y  bienes como parte de su actividad comercial.
  • Departamentos y agencias del gobierno para quien los servicios de ITS pueden ser un medio de implementación de políticas de gobierno de transporte, sociales (accesibilidad e inclusión) o ambientales.
  • Organizaciones para las cuales la prestación de un nuevo servicio ITS relacionado con los viajes  sea una manera de mejorar y ampliar sus negocios.
  • Fabricantes de  componentes ITS, que desean ampliar su gama de productos y ven una oportunidad de hacerlo a través de proporcionar una nuevo servicio relacionado con los vehículo o con la movilidad.

El proceso de comprometerse con los grupos de  interés consiste en una secuencia de actividades:

  • Alcance inicial: Para dar a conocer el proyecto e identificar a los Grupos de interés
  • Reuniones: Con Grupos de Interés para entender sus necesidades y, siempre que sea posible, alcanzar un consenso sobre las necesidades operativas y el apoyo al despliegue de ITS, produciendo lo que se llama aspiraciones de los Grupos de interés.
  • El diálogo permanente: Para apoyar el desarrollo de la arquitectura y revisar los avances del proyecto.

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:

  • La policía, los servicios de emergencia,  y operadores de  carreteras que están involucrados en las respuestas a los incidentes.
  • Autoridades portuarias, operadores de transporte de mercancías y operadores de carreteras que están involucrados en la gestión de la circulación de mercancías desde y hacia los puertos.
  • Un grupo relevante de  empresas comerciales – por ejemplo los operadores de carreteras de peaje, proveedores de servicios de información o los operadores de Estacionamientos.

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:

  • Reuniones Individuales: - proporciona una oportunidad para el debate franco y abierto, que puede tocar  asuntos de naturaleza sensible.
  • Reuniendo en grupos - es una oportunidad para la interacción entre las partes interesadas y para el desarrollo de un entendimiento común de lo que se trata el despliegue de ITS - para llegar a un acuerdo sobre su alcance y los requisitos esenciales - y las funciones y responsabilidades de cada parte.

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.

Empezar de Cero

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:

  • Basada en la experiencia con otras arquitecturas ITS, se necesitarán recursos considerables, tales como 3 años de horas Hombres,  extendido a lo largo de un período de 2 años.
  • La arquitectura ITS puede no ser compatibles con otras arquitecturas de ITS de la actualidad que están en uso en todo el mundo.
  • Aunque la arquitectura ITS se puede crear con herramientas "estándar", como Microsoft Word, Visio y access, será difícil comprobar correctamente su coherencia, por lo que será necesaria una herramienta especializada con coste adicional.
  • La experiencia de  muchas  arquitecturas ITS ha demostrado que la metodología Orientada a Procesos es más adecuada a las arquitecturas ITS (véase la norma ISO TR26999) – la cual puede requerir algún tipo de formación para aquellos involucrados en familiarizarse con esta forma de trabajo, aunque sus reglas son "evidentes"

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.

Adaptar una Arquitectura Existente

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:

  • EE.UU. Nacional ITS Architecture – Su herramienta Turbo Architecture se puede utilizar para crear variantes de la arquitectura ITS. Hay 300 ejemplos de su uso como punto de partida para adaptar  arquitecturas ITS.
  • Arquitectura MARCO Europea - su herramienta de selección permite que un único conjunto de funcionalidades (llamado un punto de vista funcional) se cree desde el Marco  User Needs Descriptions . A partir de esta selección, se pueden crear uno o más puntos de vista físico que contengan  la misma funcionalidad, pero posiblemente en diferentes lugares físicos.

Consejos a los profesionales

Antes de hacer una elección entre los dos puntos de partida, es importante que se discutan y respondan a las siguientes preguntas:

  • ¿Se ha discutido el alcance de la aplicación ITS con los principales grupos de interés? Como mínimo, los lineamientos de las descripciones de los servicios deben ser creados para aclarar lo que las partes interesadas están esperando que se implemente.
  • ¿Se ha decidido cómo se utilizará la arquitectura ITS? Por ejemplo es para una implementación de sola vez y si es así,  ¿es probable que se amplié en el futuro - ya sea mediante la adición de nuevos servicios o la ampliación de la cobertura geográfica?
  • Va a ser una arquitectura ITS a partir del cual se crearán otras arquitecturas, y si es así, cuánto control se ha de ejercer sobre las adaptaciones de las arquitecturas ITS que se derivan?

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:

  • Arquitectura de Estados Unidos - fácil de usar como una arquitectura de "modelo" que requiere poco o ningún conocimiento de los detalles técnicos detrás del  proceso de creación de la arquitectura ITS; pero adaptarla a incorporar variaciones locales y / o completamente nuevos servicios de ITS no es algo que muchos usuarios pueden hacer fácilmente (Ver  Uso de la Arquitectura de USA)
  • Arquitectura MARCO Europea - requiere un conocimiento más íntimo de los aspectos técnicos de cómo crear una arquitectura ITS, pero es muy flexible y se puede adaptar para incluir las variaciones locales o nuevos servicios si los usuarios siguen la orientación detallada que se proporciona (Ver  Uso de la Arquitectura FRAME (MARCO))

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.

Problemas para economías en Desarrollo

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.

Información Adicional

Un estudio de caso está disponible en el diseño del Abu Dhabi Integrated Transportation Information and Navigation System " i-TINS". (Ver Case study)

Referencia

No reference sources found.