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

Se encuentra usted aquí

Inicio // Sistemas y Estándares // Arquitectura ITS // Usando la arquitectura ITS

Usando  la arquitectura ITS

Lo que sucede después de que la arquitectura ITS ha sido creada depende del tipo de la arquitectura y el punto de partida utilizado para su creación. Las posibilidades pueden reducirse a:

  • Desarrollar un análisis más detallado para la su aplicación (algunos son llamados puntos de vista)
  • Utilizar la arquitectura como el punto de partida para la creación de sub-conjunto de arquitecturas ITS.

Arquitecturas  modelos que han sido modificadas se pueden utilizar para desarrollar otros puntos de vista (como el punto de vista organizativo), pero pueden ser más difíciles de usar como punto de partida para el desarrollo de un nuevo sub-conjunto de arquitecturas. Las arquitecturas MARCO puede ser más fácil de usar para explorar diferentes puntos de vista físicos y / o de comunicaciones;   crear nuevos sub-conjuntos para soportar nuevos servicios separados, o combinaciones de servicios.

Explorando diferentes arquitecturas ITS

A veces puede ser muy útil  estudiar el impacto de diferentes puntos de vista físicos y de comunicación en la  aplicación ITS (Ver Qué significa Arquitectura ITS?). Puede ser útil para crear diferentes puntos de vista físicos con configuraciones de componentes alternativos y examinar los efectos que las alternativas tienen sobre las comunicaciones y puntos de vista de organización,  y otros aspectos importantes de la colocación, como el costo / beneficio. Este proceso puede ayudar a identificar la configuración óptima del sistema que:

  • Pone los componentes en las ubicaciones físicas que los hacen más fáciles de desplegar.
  • Utiliza las redes de comunicación más adecuadas.
  • Tiene un coso aceptable de despliegue y / o  operación mientras que todavía produce los servicios deseados

La configuración de cada implementación se analiza utilizando las herramientas de la arquitectura  ITS de los EE.UU. o la  Arquitectura ITS  MARCO (según sea el caso) y los resultados de la creación de la arquitectura ITS de las siguientes maneras:

  • Punto de vista físico - Este muestra dónde se encuentra físicamente cada componente y la funcionalidad que va a contener. Esta es una de las salidas proporcionadas por la herramienta  Turbo Architecture  de la arquitectura de los Estados Unidos y la herramienta FRAME Selection,  y puede ser útil para estudiar formas alternativas de distribuir la funcionalidad entre los componentes. La desventaja de este estudio es que puede obstaculizar el desarrollo de componentes "estándar".
  • Punto de vista de las comunicaciones - Contiene los requisitos para cada enlace que permite a los componentes para intercambiar datos entre sí y con el mundo exterior. Se crea desde el punto de vista físico utilizando las estimaciones de los datos en cada enlace y cualquier otra característica de rendimiento - como la latencia de la comunicación (retardo). Un ejemplo de los detalles necesarios se muestra en el Punto de Vista de comunicaciones para el Consejo del Condado de Kent (Ver Uso de la Arquitectura FRAME (MARCO)).
  • Estándar - como se crea la tabla del punto de vista de comunicaciones para cada enlace, también se puede utilizar  para determinar los estándares de cada uno. La Arquitectura ITS nacional de EE.UU. ha sido desarrollada para proporcionar los enlaces de los flujos de información de ITS específicas o estándares de la industria (Ver Estándares ITS). En el ejemplo de Kent (Ver Uso de la Arquitectura FRAME (MARCO)), tendrán que ser identificados las opciones de comunicación de estándares de línea fija y seleccionar el  más apropiado. Otros enlaces de comunicación pueden implicar estándares tales como las que existen entre los objetos en movimiento (comunicaciones vehículo a vehículo) o entre objetos móviles y fijos (Comunicaciones de vehículos a infraestructura). En algunos casos,  los  estándares también pueden tener que ser aplicado a los componentes para cubrir una diversidad de cosas tales como la apariencia, la ubicación, la interfaz de uso, la tolerancia de las condiciones ambientales, el mantenimiento, la fuente de potencia y durabilidad.
  • Punto de vista organizativo - Este se utiliza para mostrar la estructura organizativa que será necesaria para gestionar y controlar los componentes y enlaces de comunicaciones. Si se utiliza la arquitectura MARCO como el punto de partida, este punto de vista se puede crear utilizando la Herramienta FRAME Selection. Se utiliza para identificar los impactos y cambios necesarios para la estructura organizacional existente.
  • Frontera del sistema - Este se utiliza para definir lo que es parte de la  implementación ITS  y lo que está fuera de ella. La gente está fuera y se comunican a través de un componente que proporciona una interfaz hombre-máquina (HMI). Otros sistemas NO-ITS, como los de las transacciones financieras están fuera. El límite del sistema se puede mostrar en lo que se llama un "diagrama de contexto". Se proporciona un ejemplo de Kent.
  • Plan de despliegue - Este se produce a partir de los puntos de vista física y de comunicación para mostrar el orden en el que los componentes y enlaces de comunicaciones se pueden implementar y cómo los ya existentes pueden ser reutilizados o reemplazado. Puede requerir una encuesta para averiguar si algún equipo ITS relacionado está actualmente en uso para hacer una  evaluación de su valor para la implementación descrita por la arquitectura ITS.
  • Análisis de costos - una estimación aproximada de los costos de capital y de ingresos (a menudo basadas en la experiencia anterior) se puede producir usando las descripciones de componentes y requisitos de las comunicaciones. Utilizando el plan de despliegue se puede producir un perfil  de costos para mostrar cuando los costos se incurren al tiempo que avanza la implementación de ITS.
  • Análisis de costo / beneficio - este análisis puede ser más difícil de realizar ya que la estimación de los beneficios no siempre es fácil (Ver Ponderación de Costos y Beneficios). Se  Puede buscar ayuda de organizaciones como la de International Benefit, Evaluation and Costs (IBEC) Grupo de Trabajo (https://sites.google.com/site/ibecits/home). Las relaciones costo / beneficio que se producen necesitarán ser confrontada con otros  implementaciones ITS similares. La página web IBEC puede ayudar con esto.
  • Análisis de riesgos - identificar las zonas de riesgo que pueden asociarse a la implementación de los componentes y enlaces de comunicaciones es muy útil, así como buscar en otras cuestiones tales como los impactos en las organizaciones existentes, la disponibilidad de tecnologías adecuadas, problemas con la aceptación del usuario. Se debe incluir la consideración de la organización (s) responsable de la mitigación de cualquier riesgo identificado.
  • Descripciones de servicio / relaciones de los componentes - el desarrollo de éstos puede ser muy útil cuando se avanza desde el desarrollo de la arquitectura a la  implementación, ya que muestra los componentes que están involucrados en la prestación de cada servicio. Con la Arquitectura de Estados Unidos y los servicios y los componentes o subsistemas asociados a cada servicio son accesibles y se pueden editar utilizando la herramienta Turbo Architecture (www.iteris.com/itsarch/html/turbo/turbomain.htm). Para la arquitectura MARCO las relaciones de servicio se pueden crear directamente desde la base de datos utilizada por la herramienta FRAME Selection, como se muestra en la tabla para sus subsistemas en el ejemplo Kent (Ver Uso de la Arquitectura FRAME (MARCO)).

Hay relaciones entre cada uno de los anteriores, así como entre cada uno de ellos y el contenido de la propia arquitectura ITS y con las descripciones de los servicios. Estos se muestran en el siguiente diagrama.

Las relaciones entre los diferentes puntos de vista de la arquitectura ITS y los otros aspectos de su implementación.

Como puede verse en el diagrama, algunas de las relaciones son de dos vías y  la arquitectura puede necesitar revisión para crear la configuración óptima del sistema como resultado del análisis de diferentes aspectos de la implementación prevista. Uno de los beneficios de la creación de una arquitectura ITS es ser capaz de hacer esto en una etapa temprana antes de que los contratos se firmaran para los equipos y las comunicaciones que se  hayan diseñado y / o comprado.

Concepto de Documento de Operación

Para algunos practicantes  de  arquitecturas ITS,  la creación de un Concepto documento de operación (CONOPS) es una parte clave del proceso de creación de la arquitectura ITS. Su utilidad depende de cómo se va a utilizar la  arquitectura ITS y el contenido de los  puntos de vista funcional y punto de vista físicos.

El documento ConOps se puede utilizar para proporcionar respuestas a las preguntas a los Grupos de interés acerca de  lo que se necesita, cómo funciona, quien está involucrado y cuando es necesario. Para producir este documento, el punto de partida debe ser las descripciones de los servicios producidos en el inicio del proceso de creación del ITS. Y es por esta razón que algunos profesionales de la arquitectura ITS creen que debería producirse antes de que se creen los puntos de vista. De hecho, se puede utilizar como un mecanismo para la creación de la vista inicial de la funcionalidad antes de que se plasme en el punto de vista funcional. Sin embargo, si se hace esto, el documento ConOps sólo debe considerarse como "trabajo en curso" y no se considera "final" hasta que los otros puntos de vista se han producido.

Una vez que las descripciones de los servicios se han producido e incluido en el documento ConOps,  puede ser utilizado para proporcionar respuestas a las siguientes preguntas:

  • Qué: datos/Información va a  entrar/salir y cómo se obtiene/Produce
  • Cómo: la forma en que las entradas se procesan para producir las salidas
  • Quién: los diferentes niveles y áreas de responsabilidad de todos los implicados en la prestación de los servicios
  • Cuándo: que recibirán los usuarios finales, dónde y cuándo

La información utilizada para responder a estas preguntas será incluida en los puntos de vista  funcionales, físicos, comunicaciones y  organizacional. Como ya se ha señalado, esta información puede  estar escrita en el documento ConOps a medida que se producen estos puntos de vista, con tal de que se actualiza después de que se han finalizado. Alternativamente, el documento ConOps puede ser producido hacia el final del proceso de creación de la arquitectura ITS.

El documento ConOps puede proporcionar una vista común de cómo los servicios funcionarán y que no se proporciona directamente por los demás resultados de la creación de la arquitectura ITS. También puede incluir un diagrama para ilustrar a un alto nivel la forma en que los principales componentes y entidades externas a la arquitectura ITS van a interactuar. En la práctica este diagrama será una combinación del diagrama de contexto que muestra los límites del sistema y el diagrama de punto de vista físico de nivel superior y podría ser como se muestra a continuación.

AUn bosquejo arquitectónico típico de alto nivel típico para las operaciones de la Red de Carreteras

Al igual que la arquitectura ITS en sí, el documento ConOps no debe incluir referencias a ninguna tecnología que podría ser utilizada, o que tendrá que ser desarrollada para la implementación del servicio (s) que describe. Esto se debe a que uno de los usuarios del documento serán los grupos de interés para los que puede proporcionar una visión de cómo las personas que crean la arquitectura ITS creen que el servicio va a funcionar. Por lo tanto, será importante que los Grupos de interés aprueben  el contenido del documento ConOps antes de proceder a la etapa de "Contratación".

Una vez que los Grupos de interés están contentos con el documento ConOps, sus otros grupos de usuarios los desarrolladores de componentes y los proveedores de comunicaciones. Para ellos se ofrece una vista conjunta  de cómo los servicios deben ser proporcionados. Por lo tanto y la inclusión en el documento ConOps de cualquier sugerencia acerca de las tecnologías que se utilizará será como una restricción de su trabajo de diseño.

Legado/Obsolescencia/Actualización

Un asunto que suele plantearse en la planificación de la  implementación ITS, es cómo hacer frente a la inversión preexistente en  componentes y  comunicaciones ITS. El  plan de despliegue producido a partir de la arquitectura ITS tendrá que demostrar cómo se incorporan estos sistemas heredados.

La arquitectura informará  un análisis de la idoneidad de cualquier de los componentes y de las comunicaciones ITS existentes en las tres secciones siguientes:

  • retener - esto se aplica a cualquier red de  componentes y / o de comunicaciones ITS  existentes que se encuentran en la fase de "legado" de su existencia, pero pueden ser retenidos para formar parte de la aplicación ITS
  • reemplazar - esto se aplica a cualquier red de  componentes y / o de comunicaciones ITS existentes que han alcanzado la "obsolescencia" (en otras palabras, no se pueden integrar con cualquier cosa nueva, modificadas o mantenidas) por lo que será reemplazado con algo nuevo en el la implementación  de ITS.
  • modificar - esto se aplica a cualquier de los componentes existentes y / o redes de comunicaciones ITS que son adecuados para una "actualización" y significa que cuando las modificaciones necesarias se  completen, formarán parte de la implementación ITS.

Para que estas categorías se puedan aplicar, se debe completar  un examen de auditoría (inventario y evaluación de la actuación) de  los componentes existentes y las comunicaciones ITS. Este es un ejercicio útil en sí mismo, ya que puede revelar equipos/instalaciones de las cuales las personas no eran conscientes o que están en lugares imprevistos. Una auditoría de este tipo no es parte del proceso de creación de la arquitectura ITS, pero es una parte importante de nuevas e importantes implementaciones ITS - y se puede llevar a cabo por personas ajenas al equipo de creación de la arquitectura (ver Recursos).

Mantenimiento de la Arquitectura

ITS evoluciona continuamente a medida que las necesidades de desplazamiento de las personas, las organizaciones que  mueven mercancías y otras organizaciones relacionadas con los viajes continúan desarrollándose. El mantenimiento es importante para que  la arquitectura ITS siga siendo relevante - pero a menudo se pasa por alto ya que hay poco entusiasmo para asignar los fondos para hacerlo. Alguna forma de un plan de mantenimiento debe ser implementado con un presupuesto adecuado. El tamaño de este presupuesto dependerá en cierta medida de la cantidad, el alcance y la complejidad de los servicios de ITS que incluye la arquitectura. Sin embargo, una guía a mano alzada para la previsión de presupuesto propuesto es que debe ser del 10% del coste total de desarrollo.

El Plan de Mantenimiento

El plan de mantenimiento no tiene por qué ser oneroso, pero se debería permitir una revisión de la arquitectura ITS aproximadamente una vez cada 12-18 meses - o con menos frecuencia si la arquitectura ya se ha adaptado para reflejar cambios significativos en los servicios de ITS. El propósito de la revisión es para ver si se debe añadir  nuevos servicios a la arquitectura ITS y los planes de implementación. Esto requiere una discusión acerca de los servicios prestados actualmente y si los interesados quieren que sean revisados, actualizados, o que se añadan nuevos servicios (teniendo en cuenta las características y el rendimiento de los servicios prestados en otras partes).

Si es necesario hacer cambios en la arquitectura ITS, el plan de mantenimiento deberá prever su actualización, siguiendo la misma secuencia de pasos que cuando se creó una nueva arquitectura (Ver  Cómo se Crea?).

Consejos Para los Profesionales

Cuando se actualiza una arquitectura ITS, el principio de "compatibilidad hacia atrás" se debe seguir en relación con cualquier nuevo  despliegue ITS. La intención es que cualquier cambio no invalide cualquier desarrollo de arquitectura ITS existente. Esto significa que los identificadores de los enlaces de comunicaciones y componentes sólo deben ser reutilizadas en la arquitectura ITS actualizada si sus características y funcionalidades se mantienen sin cambios. Así por ejemplo, si como parte del proceso de actualización, la funcionalidad en un componente se modifica, se le debe dar una nueva identidad (número y nombre) al igual que las funciones revisadas. Del mismo modo, si se cambia la fuente externa o el destino de cualquier enlace de comunicaciones, o los datos Transfiere, el enlace debe dar un nuevo nombre.

Esta disciplina es más importante para las  arquitecturas ITS MARCO y es una característica de cada nueva versión de la Arquitectura MARCO. Así que en algunas partes del punto de vista funcional, los números de las funciones comienzan a partir de un valor distinto que 1. Por ejemplo, en el área funcional 5 el primer número de la función es 5.11; en otros lugares hay un número en la secuencia aparentemente falta - por ejemplo en el área funcional 2, los números de función son 2.1.2, 2.1.5, 2.1.7, 2.1.8 y 2.1.9.

 

Referencia

No reference sources found.

Envíanos tus comentarios