El término "arquitectura ITS" significa, literalmente, "Arquitectura del Sistema inteligente de transporte". Como una arquitectura de sistema, ofrece una visión de cómo será un Sistema Inteligente de Transporte (ITS) desde una perspectiva de diseño del sistema. La arquitectura ITS es principalmente sobre el intercambio de datos y las instrucciones de control que pasan entre los diferentes componentes del ITS y las interfaces externas (operadores, Grupos de interés y otros sistemas). Necesita reflejar las limitaciones del mundo real que operan sobre las agencias de transporte y los requisitos que éstos imponen en su aplicación. Ejemplos de ello son la interoperabilidad entre los organismos participantes y la retención información controlada por los organismos respectivos.
Una arquitectura ITS puede mostrar dónde estructuras organizativas existentes necesitan ser modificadas y cambiadas - quizá bastante radical - con el fin de ofrecer los servicios de ITS deseados. Un ejemplo es un centro de control de tránsito (TCC) que puede necesitar intercambiar datos con otro TCC o un centro de información al viajero (TIC), posiblemente a través de fronteras nacionales o lingüísticas. Definir el contenido y las especificaciones de prestaciones mínimas para este intercambio, tiene una gran importancia. La arquitectura ITS permite definir la especificación de rendimiento para alcanzar el nivel requerido de interconexión y la interoperabilidad. La elección de qué tecnologías específicas son mejores para usar, es una cuestión para el diseñador del sistema.
No es posible presentar un sistema complejo en una forma que puede transmitir toda la información sobre el sistema de una manera comprensible. Esto se refleja en una arquitectura ITS, donde se utilizan múltiples puntos de vista, que representan diferentes niveles de detalle y diferentes tipos de información. Estos puntos de vista podrían incluir:
Junto con el desarrollo de una arquitectura para ITS, existen otros análisis de requerimientos a tener en cuenta - entre ellos:
Las arquitecturas ITS se pueden dividir en dos niveles: arquitecturas de alto nivel y arquitecturas de bajo nivel. Esto no es algo que es particular de ITS - la distinción está relacionada con el uso de arquitecturas de sistemas en general.
En el contexto de sistemas Inteligentes de transporte, una arquitectura de alto nivel es el diseño conceptual que define la estructura y / o el comportamiento del sistema. En él se especifica la funcionalidad necesaria que debe proporcionar a los usuarios de servicio del ITS. Las especificaciones son independientes de la tecnología y la selección de los componentes individuales, las comunicaciones se dejan abiertas. Esta independencia de la tecnología significa que los proveedores tienen la libertad de elegir una solución técnica que sea más adecuada para el cliente, mientras cumple con la arquitectura general.
Arquitecturas de bajo nivel (o componentes), por el contrario, contienen los diseños reales de hardware, software, intercambio de datos y comunicaciones. Ellos definen más estrechamente las tecnologías necesarias, haciendo uso de los estándares ITS (Ver Estándares ITS). Una arquitectura de bajo nivel podría ser desarrollada por el departamento de puesta en servicio, si tienen la experiencia, pero es más común que las especificaciones de diseño sean desarrolladas a partir de una arquitectura de alto nivel por el integrador de sistemas o proveedor del sistema (Ver Ingeniería De Sistemas)
Las arquitecturas ITS de alto nivel son desarrolladas para asegurar que los componentes del sistema se pueden integrar con éxito y que el despliegue del ITS cumple ciertos objetivos, a saber:
Tienen las siguientes características:
La creación de una Arquitectura ITS de alto nivel con una configuración óptima del sistema, requiere el análisis de un número de diferentes - pero cruciales - aspectos del despliegue propuesto, como sigue:
La relación entre los diferentes puntos de vista del sistema y otros aspectos importantes de la implementación del ITS se ilustran con el siguiente diagrama.
Las relaciones entre los diferentes puntos de vista de la arquitectura ITS y los otros aspectos de su implementación.
Las relaciones que se muestran en el diagrama son bidireccionales para ilustrar cómo los resultados de los aspectos uno a uno, pueden influir en otra. Por ejemplo, como resultado de la creación del punto de vista de las comunicaciones y / o punto de vista de la organización, puede ser en algún momento necesario modificar el punto de vista físico.
Para obtener el máximo beneficio de una arquitectura de alto nivel, se debe desarrollar antes de realizar cualquier trabajo para adquirir los componentes y las comunicaciones necesarias para el despliegue del ITS.
La arquitectura ITS de bajo nivel (o componente), contienen los diseños reales y especificaciones de hardware, software, intercambio de datos y comunicaciones. Ellos definen más estrechamente las tecnologías necesarias requeridas, haciendo uso de los estándares de ITS relacionados, que se van a utilizar en particular para las interfaces y las comunicaciones (VerEstándares ITS) A). Una arquitectura de bajo nivel podría ser desarrollada por el departamento de puesta en servicio, si tienen la experiencia, pero es más común que las especificaciones de diseño sean desarrolladas a partir de una arquitectura de alto nivel por el integrador de sistemas o proveedor del sistema (Ver Ingeniería De Sistemas) y no siempre pueden ser de dominio público.
Existe una analogía entre los diferentes niveles de la arquitectura ITS y la arquitectura de una casa. En ambos casos, la arquitectura puede tener que ser expresada en varias formas para adaptarse a diferentes audiencias. Para el comprador de la casa, la arquitectura se utiliza inicialmente para mostrar cómo aparecerá la casa terminada y el plano de la misma, por ejemplo, tamaño de las habitaciones y donde se encuentran los baños. Una vez que el dueño está satisfecho, se añade más detalle para que los trabajadores de la construcción esten provistos de dibujos de las paredes, vigas y columnas incluidas sus dimensiones precisas. Del mismo modo, la arquitectura del sistema para un despliegue ITS, puede expresarse en diversas formas que son coherentes entre sí. La arquitectura ITS de alto nivel ofrece a los interesados vistas de cómo les aparecerá la puesta en implementación del ITS. La arquitectura ITS de bajo nivel amplia esto con los detalles técnicos que permiten a los proveedores de equipos e integradores de sistemas para implementar los servicios. La selección de una forma arquitectónica particular depende de hasta qué punto el concepto del ITS se ha desarrollado y las necesidades de la audiencia. La idea de múltiples formas arquitectónicas es consistente con los múltiples puntos de vista en el estándar IEEE 1471-2000, "Práctica recomendada para la descripción arquitectónica de sistemas de software intensivo."
Hay dos tipos de arquitectura ITS de alto nivel de uso común en todo el mundo. Las 2 ofrecen dos enfoques básicos pero diferentes. Una arquitectura marco y una arquitectura de modelo. Ambas proporcionan una base para el desarrollo de arquitecturas ITS que puede ser adaptadas para ajustarse a implementaciones ITS particulares. Algunas de estas arquitecturas ITS puede ser específicas para una clase de aplicaciones de ITS. Esto se debe a que apoyan la implementación de un servicio específico, como los centros de control de tránsito, la gestión de Estacionamiento, o la gestión de flotas de transporte público.
Un arquitectura ITS de Marco, utilizará un conjunto de especificaciones de servicio conducido por el usuario para diferentes aplicaciones ITS que proporcionan una base flexible para un mayor refinamiento y desarrollo. Un enfoque de marco es particularmente adecuada para los casos en que un enfoque universal "de arriba abajo" no es factible. Una arquitectura ITS Marco proporciona lo básico para planes maestros ITS autónomos para ser desarrollado en el nivel apropiado (nacional, regional o local). También puede facilitar la integración transfronteriza y un mercado abierto para equipos y servicios ITS interoperables. El ejemplo más conocido de una arquitectura ITS Marco es la arquitectura marco ITS Europea (the FRAME Architecture - Ver http://www.frame-online.net/). Muchos de países están utilizando la arquitectura Marco como el punto de partida para sus propios desarrollos nacionales de arquitectura ITS - estos incluyen Australia, Austria, República Checa, Francia, Hungría, Italia y Polonia.
Las arquitecturas ITS Marco tienen las siguientes ventajas
Muchas regiones del mundo han desarrollado arquitecturas ITS "Modelo" que están adaptadas a las necesidades y requerimientos de su región y las organizaciones institucionales. Cuando se compara con una arquitectura ITS Marco, por lo general son más prescriptivo en la forma las implementaciones ITS deben ser realizadas. A menudo contienen un punto de vista físico que definirá los componentes utilizados para entregar los servicios que la arquitectura es capaz de soportar. Por ejemplo la USA’s National ITS Architecture (www.iteris.com/itsarch/) es fija y su uso es obligatorio si se solicita apoyo financiero federal para su despliegue. Define:
Otras regiones que tienen, o están, teniendo en cuenta el desarrollo de una arquitectura "Modelo" nacional incluyen Canadá, Chile, Japón, Corea y México. Hay más información disponible en la revisión de las arquitecturas ITS actuales en uso y/o en proceso de planificación alrededor del mundo, las cuales están disponibles en la página"Library/Other Architecture Reports" de la página web MARCO en: http://ww.frame-online.net.
Ambas,la arquitectura ITS Marco y la arquitectura ITS Modelo, proporcionan una estructura (o plantilla) a partir de la cual se pueden adaptar arquitecturas ITS para una generar una implementación particular. Esto permite al usuario la flexibilidad de adaptar la arquitectura para implementaciones específicas sin perder el beneficio de sus características comunes - tales como las interfaces para los componentes y las comunicaciones del sistema. Las interfaces estándar son muy importantes para la integración consistente de sistemas y tendrán mayor importancia en el futuro con el advenimiento de los sistemas cooperativos ("C-ITS" para abreviar, y conocido como "vehículos conectados" en los EE.UU.). Esto es debido a la necesidad de que los servicios se entreguen de la misma forma, en todas partes dentro de una región, por ejemplo los EE.UU., Europa, Australia y Japón. Ellos hacen el intercambio de información posible a un nivel asequible y eficaz.
Las arquitecturas ITS que están adaptadas y personalizadas desde una arquitectura ITS Marco, tiene las siguientes características:
LA ARQUITECTURA MARCO (Ver http://www.frame-online.net) es el mejor ejemplo conocido de una arquitectura ITS Marco siendo utilizados como el Maestro para las implementaciones ITS regionales y urbanas en Europa y otros países, así como proyectos de investigación europeos.
Las arquitecturas ITS que son personalizadas a partir de una arquitectura ITS “Modelo”, tienen las siguientes características:
La Arquitectura Nacional ITS de EE. UU. (http://www.iteris.com/itsarch/) es probablemente, el ejemplo más conocido de arquitectura ITS “Modelo” siendo utilizada como el "maestro" para las implementaciones ITS regionales y urbanas en los EE.UU., Canadá, Chile, Israel y otros países.
La elección de cual enfoque de desarrollo para la arquitectura ITS utilizar, depende del objetivo último de la autoridad u organización responsable - y dependerá de cómo la arquitectura ITS se va a utilizar y cual será el punto de partida para su creación. En algunos casos el uso de una arquitectura ITS "modelo" es obligatorio. Por ejemplo, en los EE.UU., la financiación federal para el despliegue de ITS está condicionada al uso de la Arquitectura Nacional.
Una arquitectura ITS Marco, es generalmente más flexible que una arquitectura ITS "modelo"- aunque ambos se puede ampliar para incluir servicios adicionales y / o alternativos. La arquitectura ITS Marco no es prescriptiva, por lo tanto, puede facilitar la búsqueda de una solución óptima de componentes / comunicaciones a una implementación ITS. El uso de una arquitectura ITS Marco requiere algún tipo de formación de los expertos, ya que sus usuarios necesitan entender el proceso de creación de la arquitectura ITS y cómo utilizarla. (Ver Recursos) Una arquitectura ITS “Modelo” es menos flexible, ya que contiene restricciones para la configuración de componentes y especificaciones de comunicaciones. Pero si no se necesitan cambios en los servicios soportados, a menudo son más fáciles de usar y no requieren que sus usuarios a sean expertos en la creación de una arquitectura ITS.
Para las economías en transición, es importante volver a lo básico para comprender el alcance de la función ITS para mejorar los problemas de transporte local y responder a las necesidades del usuario. Estos deben reflejarse plenamente en el diseño y las especificaciones de la arquitectura ITS. Esto es necesario para que las implementaciones de ITS sean planificadas y bien adaptados al contexto local. (Ver Estrategias de Implementación de ITS)Debe observarse que una arquitectura ITS "modelo" de una región puede requerir modificaciones considerables para adaptarla para que pueda ser usada en otros lugares de otras implementaciones de ITS.
Los profesionales de arquitecturas ITS utilizan muchos términos - unos pocos se usan con más frecuencia que otros. Estos incluyen "componente", "datos", "información" y "comunicaciones". Es necesario asegurarse de que todo el mundo tiene la misma comprensión de la forma en que se utilizan. Además, los profesionales deben entender la diferencia entre "arquitectura funcional o lógica" y "arquitectura física".
Al considerar una Arquitectura ITS, un "componente" es un término generalizado usado para cualquier parte constituyente de cualquier implementación ITS que se puede proporcionar como un elemento individual. Puede ser considerado como un "bloque de construcción" de la cual se ensamblan las implementaciones ITS. Puede ser creado a partir de uno o más "bits" or hardware o una combinación de hardware y software. A veces, un conjunto combinado de los componentes se llama un "subsistema" de los cuales puede haber varias en una misma implementación ITS.
Los datos acerca de lo que está sucediendo en el mundo exterior que es relevante para la aplicación del ITS, llega de muchas fuentes. (Ver Infoestructura Básica y Datos e Información) que puede representar la presencia de un vehículo, datos sobre un viaje que un viajero quiere hacer, o los detalles de los bienes y el origen y destino de sus movimientos. Los datos también pueden ser proporcionados por otros sistemas - como datos sobre el clima o los detalles de los servicios prestados por los medios de transporte distintos de la carretera.
La información es el resultado de los datos que han sido procesados por uno o más componentes dentro de la aplicación ITS. Puede ser tasas de flujo de tránsito, las condiciones del tránsito, un plan de viaje, o los detalles de un movimiento de mercancías. También puede ser el contenido de un Cartel de mensajes variables y las luces "rojo/amarillo/verde" de las señales de tránsito.
El término "comunicaciones de datos" o a veces "enlace de comunicaciones de datos" es el término dado al mecanismo a través del cual se transfieren los datos o información de un componente a otro - o entre un componente y algo fuera de la aplicación ITS. Puede consistir en uno o más medios de transmisión tales como cable físico, inalámbrico, microondas o infrarrojos - aunque su uso específico puede no estar definido en la arquitectura ITS. Las comunicaciones entre las personas están habilitadas a través de una interfaz proporcionada por un componente especial. Por ejemplo una interfaz de operador puede proporcionar acceso a varios servicios ITS o información al viajero puede ser proporcionada por un cartel de mensaje variable.
La arquitectura lógica o punto de vista funcional representa las funciones del ITS y los flujos de datos asociados que tienen lugar entre los componentes internos y las que vinculan externamente a la gente, fuentes de datos y otros sistemas. La arquitectura se define en la descripción formal de los servicios. Su desarrollo se utiliza para identificar áreas comunes de funcionalidad - de modo que los datos pueden ser compartidos a través de tantos servicios como sea posible. Se aplica el principio de "recoger los datos una vez, compartir y utilizar muchas veces". La arquitectura lógica es independiente de cualquier enfoque de hardware o software.
Mientras que todas las arquitecturas ITS tienen una arquitectura lógica, la necesidad de hacerla visible depende del tipo de arquitectura ITS que se está creando y cómo se va a utilizar. En términos generales, las Arquitecturas ITS Marco las necesitan, pero arquitectura ITS personalizadas no lo hacen. Como la arquitectura lógica - o punto de vista funcional - aparece y se accede, dependerá de qué tipo de arquitectura ITS se utiliza como punto de partida para su creación.
En el contexto de la ingeniería de sistemas, la arquitectura o punto de vista física, muestra cómo se va a distribuir la funcionalidad definida por la arquitectura lógica (o punto de vista funcional) entre los componentes del sistema en diferentes organizaciones y lugares. No es un diseño de detalle, ni incluye detalles sobre los números específicos de los sistemas o equipos a determinadas ubicaciones geográficas. La responsabilidad de la propiedad, operación y mantenimiento de los componentes del sistema también puede dividirse entre diferentes organizaciones.
Una de las ventajas de utilizar una arquitectura ITS Marco (tales como la Europea arquitectura Marco) es la opción de explorar las arquitecturas físicas alternativas mientras se mantiene la misma arquitectura lógica. Esto hace que sea posible llegar a una distribución óptima de funcionalidad en respuesta a los requisitos locales.
La arquitectura o punto de vista de comunicaciones se crean a partir de la arquitectura física y proporciona una especificación más detallada de los flujos de datos. Es en este punto que las características de flujo de datos se definen, por ejemplo cuánto tiempo la transferencia de datos puede tomar, con qué frecuencia, que seguridad será necesaria y cuantos datos es probable tener. La necesidad de interoperabilidad se puede evaluar - por ejemplo, permitiendo a la misma forma de pago electrónico que se utilizará para todos los servicios. Estas especificaciones detalladas permiten una búsqueda de estándares adecuados de comunicación local, nacional o internacional. Las normas existentes se deben utilizar siempre que sea posible ya que esto evita el proceso de creación de estándares (a veces largos) y pueden hacer que sea posible el uso de las infraestructuras de telecomunicaciones existentes. Esto significa que las implementaciones de ITS pueden tomar ventaja de los rápidos cambios que tienen lugar en la industria de las telecomunicaciones. La elección de comunicaciones dependerá de lo que está disponible a nivel local y las tarifas que pueden ser negociados con los proveedores de servicios. Estas cuestiones han de ser explorados con los proveedores de comunicaciones.
La arquitectura o punto de vista organizativa, también se crean a partir de la arquitectura física y muestra quién será el responsable de la operación, mantenimiento y gestión de los componentes y enlaces de comunicaciones. También destacará la estructura organizativa que será necesaria para apoyar la aplicación ITS de manera que se puede comparar con lo que existe actualmente. Esto permite detectar cualquier cambio que será necesario en la estructura organizativa, las funciones y responsabilidades, y luego acordarlos con los distintos Grupos de interés antes de iniciar su implementación
Este es un concepto importante pero que a veces se pasa por alto, dicho concepto define los límites exteriores de la aplicación ITS, - y dónde y en qué forma, son necesarias las interfaces entre los subsistemas y los usuarios finales. Así como la descripción de las interfaces también es necesario describir cómo los subsistemas esperan que lo que está fuera de la aplicación ITS debe comportarse. Un ejemplo de este tipo de interfaz es la conexión a una base de datos de registro de vehículos en poder de la autoridad policial o registro de licencias, que un subsistema ITS puede necesitar acceder a los efectos de recoger los pagos electrónicos de peaje. Para la arquitectura ITS la descripción de la base de datos sólo tiene que decir lo que se espera que haga, por ejemplo, proporcionar información de contacto para un vehículo específico.
Un punto importante a destacar es que los usuarios finales que son los seres humanos, por ejemplo, los viajeros, operadores de sistemas de transporte, planificadores y gestores de flotas, están siempre fuera de los límites del sistema. Son las interfaces de entrada y salida que se les proporcionan las que están dentro de los límites del sistema.
Copias de la Arquitectura ITS Marco Europea, además de su documentación y herramientas se pueden obtener en http://www.frame-online.net/. La Arquitectura MARCO incluye soporte para la Sistemas Cooperativos/vehículos conectados.
Las copias de la Arquitectura Nacional ITS de Estados Unidos además de su documentación y herramientas se pueden obtener en http://www.iteris.com/itsarch/. Las copias de la US Connected Vehicle Reference Implementation Architecture (CVRIA – for Cooperative Systems/Connected Vehicles) , además de su documentación y herramientas se pueden obtener en http://www.iteris.com/cvria/.
Dentro de cualquier país o región, es probable tener grandes diferencias entre el conjunto de servicios ITS útiles para las grandes ciudades y las zonas rurales. Muchas aplicaciones ITS (como los servicios basados en localización y navegación) son impulsadas por el mercado. En las operaciones de la red de carreteras hay siempre Grupos de interés principales, autoridades públicas y organizaciones del sector privado con un papel que desempeñar (por ejemplo - en la gestión de la red de autopistas, control de tránsito y operaciones peajes). Cada uno tiene diferentes áreas de competencia o responsabilidad (como la seguridad vial, el transporte público, la logística de la flota, la policía y la seguridad pública). Cada uno tiene sus propios objetivos políticos. Junto con esto, existen los objetivos comunitarios más amplios de mejorar la seguridad vial, la eficiencia del transporte y la calidad del medio ambiente. El proceso de consulta de los Grupos de interés se hace para tener en cuenta el panorama general - para identificar cuáles servicios ITS son viables y cómo deben ser implementadas. Esto se describe en el siguiente diagrama, que muestra que el primer paso es definir los objetivos de la política, y luego identificar los servicios que apoyen estos objetivos. Los Grupos de interés designan los servicios ITS que se ejecutará total o parcialmente dentro de sus propios dominios. Estos se fusionaron para proporcionar un conjunto de servicios que han sido seleccionados conjuntamente por todas las partes interesadas.
Figura 21: Expresión de objetivos la política dentro de la Selección de servicios ITS
El proceso de involucrar a los Grupos de interés debe comenzar por pedir que describan con sus propias palabras los servicios que desean que la implementación del ITS incluya. En la discusión de estas descripciones, las mismas pueden ser modificadas para que puedan apoyar los objetivos de la política. (Ver sección posterior más detallada sobre "Describiendo los Servicios") ( Ver Cómo se Crea?) Puede ser muy beneficioso si esto se hace a través de una "conferencia de las tares interesadas" para que los diversos grupos pueden encontrarse, discutir las opciones y entender los requerimientos de cada uno. A menudo, esto dará lugar a la constatación de que algunos de los servicios se pueden mejorar mediante el intercambio de datos o información entre los diferentes grupos de interés.
Por ejemplo, los operadores de redes de carreteras pueden estar planeando desplegar ITS para peaje electrónico y la detección automática de incidentes. Esta funcionalidad puede ser adaptada para dar información de alta confiabilidad de tránsito y de información al viajero, con los tiempos de viaje de punto a punto. Se necesita una alianza entre los operadores de autopistas, empresas de peaje y los proveedores de servicios de información para hacer que esto ocurra. El consorcio tendrá que acordar la utilización conjunta de su infraestructura, protocolos de intercambio de información, y los datos y la información que van a utilizar. Todos ellos pueden ser incluidos en una arquitectura ITS común que sirve a las necesidades de todos los socios.
Otro ejemplo podría involucrar a los operadores de la red de autopistas que consideren el uso de la medición de rampas de acceso para mantener la fluidez del tráfico. Un efecto secundario no deseado puede ser largas filas de vehículos que se derivan hacia las calles adyacentes que causan parálisis de tránsito. Se necesitan medidas para garantizar que esto no suceda. También puede haber presión para dar prioridad a los autobuses y otros vehículos de alta ocupación que esperan en la rampa. Los dos operadores de red - para las autopistas y las carreteras adyacentes - necesitan diseñar sus políticas de gestión del tráfico y el despliegue de ITS para minimizar el conflicto. Esto podría implicar algún tipo de gestión de la demanda con medidas para disparar los cambios.
Estos ejemplos enfatizan el valor de tomar una visión amplia del desarrollo de los ITS en lugar de que cada organismo u organización trabaje en forma aislada. El trabajo Colaborativo en las primeras - para definir el alcance completo del ITS - significa que se pueden realizar cambios a costos relativamente bajos antes de los sistemas están diseñados y los equipos hayan sido comprados.
Los beneficios de crear y utilizar arquitecturas ITS dependen de las diferentes perspectivas que tienen las partes interesadas: los operadores de redes de carreteras, proveedores de servicios, proveedores de transporte.
Los beneficiarios de ITS pueden ser autoridades viales, entidades operativas de la carretera – quienes se pueden beneficiarse de las arquitecturas ITS de varias maneras:
Las organizaciones que se ocupan de la movilidad de las personas y el movimiento de la carga, incluyen a las autoridades nacionales y locales y los operadores de flotas involucrados en el transporte intermodal - para quienes las arquitecturas ITS proporcionan los siguientes beneficios:
Los proveedores pueden ser proveedores de componentes, proveedores de comunicaciones o integradores de sistemas - para quienes la arquitectura ITS proporciona los siguientes beneficios:
La arquitectura como medio de enfoque puede ayudar a todas las partes interesadas en:
Los riesgos de no llevar a cabo el proceso de desarrollar una arquitectura ITS pueden incluir:
Si cualquiera de los riesgos se concreta en la práctica, los costos involucrados en la mitigación o corrección será considerable. En algunos casos, la única manera de avanzar es "empezar de nuevo", y esta vez utilizando una arquitectura ITS.
A pesar de todos los beneficios que se acaban de describir para el desarrollo de una Arquitectura ITS, convencer a la gente adecuada de que la creación y el uso de una arquitectura ITS es de beneficio para su aplicación, no siempre es fácil. Hay varias razones para esto, la más destacada de las cuales es que las arquitecturas ITS son vistas como una limitación a los proveedores comerciales e integradores de sistemas. De hecho, pueden ser más liberador que una limitación, ya que permiten a los interesados apreciar cómo la aplicación del ITS se verá y lo que va a hacer por ellos. Las arquitecturas ITS también permiten a las partes interesadas considerar todas las opciones para la implementación del ITS, incluyendo la elección de utilizar las tecnologías más ajustadas a las necesidades, o si no existen, incentivan una investigación para encontrarlas.
El proceso de crear y utilizar arquitecturas ITS permite a los Grupos de interés ser mucho más claros acerca de los servicios que quieren de la propuesta de desarrollo de l ITS - lo que va a hacer y como se verá. Como resultado, habrá menos "sorpresas" cuando se inicie la aplicación ITS. Esto ayudará a evitar los comentarios negativos tales como "Yo no sabía que haría eso", o "Me gustaría que no lo hiciera", o "Me gustaría que pudiera....".
Los beneficios de crear y utilizar una arquitecturas ITS necesitan ser "vendido" a las personas adecuadas, que a menudo se hace referencia como "tomadores de decisiones", es decir, las personas que deciden que el ITS se pondrá en práctica y que se tendrá la financiación para hacerlo. En algunos casos, algunas de las partes interesadas también pueden necesitar ser convencidas. Por lo tanto, es necesario tener una buen "argumento de venta" que se pueda adaptar a cada tipo de audiencia.
El uso de arquitecturas ITS en el proceso de implementación del ITS se hace antes que cualquiera de los componentes o las comunicaciones han sido compradas o diseñadas. Esto se debe a que no contienen ninguna referencia a las tecnologías. De hecho, las especificaciones de los componentes y requisitos de las comunicaciones producidas gracias a la arquitectura ITS se pueden utilizar como entrada para el proceso de adquisición. Esto se ilustra con el siguiente diagrama.
El uso de la Arquitectura ITS en el proceso de implementación de ITS
Las organizaciones utilizan diversos términos para el proceso de adquisición - tales como "Solicitudes de Propuestas", "anuncio de licitación" o "Requerimiento de Solicitudes". Lo que es importante es que la arquitectura está incluida en el pliego de condiciones y sea utilizado por los proveedores, los proveedores de comunicaciones e integradores de sistemas en el desarrollo de sus propuestas. Esto asegura que las especificaciones para los componentes y comunicaciones entregarán los servicios ITS descritos por las partes interesadas.
Como parte de sus respuestas a las licitaciones - proveedores, los proveedores de comunicaciones e integradores de sistemas pueden ser invitados a ilustrar sus propuestas con sus propios sistemas, software, hardware, datos y arquitecturas de comunicaciones, todos como arquitecturas de bajo nivel o de componentes. Cada uno se puede comparar con la arquitectura ITS para asegurarse de que se ajusten a los requisitos y muestran una buena comprensión de lo que los Grupos de interés quieren.
Las arquitecturas ITS también se incluyen en el modelo de ingeniería de sistemas de "V", como se ilustra en el siguiente diagrama. (Ver Ingeniería De Sistemas)
Figura 2: arquitectura ITS en la Ingeniería de Sistemas
Hay algunas otras metodologías de arquitectura que están en uso en todo el mundo, que se mencionan aquí para completar. Probablemente las más comunes son Arquitectura Empresarial, EL Open Group Architecture Framework (TOGAF)y el Object Orientated/UML Architecture. Los tres enfoques cubren más que la arquitectura y entran en la implementación y mantenimiento del sistema.
Una Arquitectura Empresarial es una práctica bien definida que puede ser utilizada por las organizaciones para guiar el desarrollo de sus negocios. Considera al negocio como una "empresa" y es quizás el sucesor de "arquitecturas de negocio" que utilizan técnicas de modelado de procesos de negocio. El concepto de una arquitectura empresarial se atribuye a John Zachmann cuando trabajaba para IBM en la década de 1980 y fue responsable del " Diagrama de Zachmann". Se ha desarrollado y actualizado varias veces desde entonces por organizaciones tales como Enterprise Architecture Centre of Excellence (EACOE en http://www.eacoe.org). Hasta donde se sabe, las arquitecturas empresariales nunca se han utilizado para las implantaciones de ITS. La creación y uso de las arquitecturas ITS encaja bien con el Diagrama Zachmann y es parte "modelo de negocio" y "Modelo del sistema", con la preparación de las descripciones de los servicios formando parte de su fase de "Alcance".
Otra metodología que puede utilizarse para su aplicación es TOGAF (The Open Group Architecture Framework - Ver http://www.togaf.org/). Es robusta y se utiliza en muchas partes del mundo, apoyados por una comunidad de usuarios que ofrece certificaciones profesionales para aquellos que lo utilizan (practicantes TOGAF). La Metodología de Desarrollo de Arquitectura TOGAF (ADM) divide la creación y el uso de la arquitectura en varias fases, como se muestra en la figura siguiente. Las fases son similares a los pasos que se muestran en la figura de arquitectura ITS en el Modelo de Ingeniería de Sistemas "V". (Ver Ingeniería De Sistemas)
Figura 20: Relación entre la metodología Arquitectura Desarrollo TOGAF (ADM) y Arquitecturas típicas de ITS
Algunas fases de TOGAF no están cubiertas ni por arquitecturas ITS de alto nivel o por arquitecturas ITS de componentes de bajo nivel. Estas fases adicionales pueden cubrir etapas posteriores del proceso de implementación ITS, como la adquisición, instalación y operación. La inclusión de estos pasos dentro de la arquitectura tiene la ventaja de proporcionar tanto la solución actual, así como su realimentación y actualización de la arquitectura ITS.
Más información sobre el uso de TOGAF en el proyecto nacional de Arquitectura ITS de Australia se puede encontrar en: http://www.austroads.com.au/road-operations/network-operations/national-its-architecture#
La metodología orientada a Objetos ha sido establecida desde hace mucho tiempo para el diseño de software y sistemas, y casi siempre se ilustra mediante el Lenguaje Unificado de Modelado (UML). Hasta donde se conoce sólo dos arquitecturas ITS lo han adoptado: la arquitectura ITS desarrollada por la ISO TC204 en 1998 y la arquitectura ITS Australiana, que fue desarrollado unos años más tarde. basada en ISO.
La arquitectura ITS ISO se ha mantenido prácticamente intacto desde que se produjo y ahora puede ser carente de apoyo a muchos de los servicios de ITS utilizados en la actualidad. La Arquitectura ITS australiana también fue utilizada poco. En los últimos años, Australia ha comenzado el desarrollo de una nueva Arquitectura Nacional ITS australiana. Está siguiendo el camino tomado por la mayoría de las arquitecturas de alto nivel (Ver Qué significa Arquitectura ITS?) que se han desarrollado en todo el mundo y usando la metodología descrita en este módulo.
Es probablemente cierto decir que la metodología orientada a objetos es inapropiada para su uso por personas fuera de la industria de IT, ya que requiere de práctica para familiarizarse con él. Esta metodología es más apropiada para arquitecturas ITS de bajo nivel (o nivel de componente) que son utilizados por los desarrolladores de software y de sistema.
Muchas economías en desarrollo tendrán poca o ninguna experiencia en los ITS. Esto significa que habrá muy pocas implementaciones de ITS existentes, y cuando existen, a menudo se trata de sistemas aislados sin tener ningún vínculo con cualquier otro sistema. Por lo tanto, cualquier nueva implementación ITS será a partir de lo que es prácticamente un "terreno virgen". En esta situación, la creación y uso de una arquitectura ITS es prácticamente una Obligación, ya que ofrece la mayor oportunidad para evaluar todas las opciones de configuración de componentes y de las comunicaciones. Esto debe hacerse sin las influencias de los proveedores de componentes o sistemas, que inevitablemente estarán intentando vender sus propios productos, pero debe tener en cuenta los estándares disponibles, en particular para las comunicaciones.
La creación y uso de arquitecturas ITS proporcionará la oportunidad de especificar los componentes y las comunicaciones que permitan una aplicación ITS que sea "abierta" - una que utiliza estándares abiertos, o disposición del público, a los que cualquiera pueda ajustarse. Esto a su vez puede ampliar el potencial de base de proveedores, en otras palabras, hacen que sea más fácil para una gama más amplia de empresas poder licitar para el suministro de componentes y la provisión de comunicaciones. Esto se aplicará no sólo a la etapa inicial de la implementación ITS, sino también para futuras ampliaciones y mejoras, evitando así la trampa de estar "atrapados" a una tecnología particular de componentes y comunicaciones.
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)
Uno de los dos puntos de partida principales para la creación de una nueva arquitectura ITS partiendo de una arquitectura ITS existente, es la arquitectura ITS nacional de EE.UU.
La herramienta de la Arquitectura de los Estados Unidos Turbo Architecture ofrece facilidades que permiten a los usuarios adaptar y ampliar el contenido de la arquitectura para satisfacer las necesidades de su implementación ITS particular. El proceso de adaptación se describe en las partes “ayuda” de la herramienta Turbo Architecture, pero los usuarios pueden encontrar útil obtener asistencia especializada y asesoramiento antes de comenzar.
El uso de la Arquitectura ITS de los EE.UU. para crear la arquitectura ITS que soportará los servicios acordados con los Grupos de Interés significa tomar los siguientes pasos:
Paso 1. En el sitio web Arquitectura de Estados Unidos (http://www.iteris.com/itsarch/) seleccione la pestaña "Servicios del usuario". Esto abrirá una nueva ventana que muestra una lista de paquetes de servicios del usuario y de servicios del usuario, como se muestra en la gráfica a continuación. Paquetes servicios del usuario, son grupos de servicios del usuario para actividades ITS compatibles similares, tales como viajes y gestión del tránsito que se muestran en la gráfica a continuación. (Haga clic + para mostrar )
Figura 6: Pantalla del Website de la Arquitectura ITS USA
Paso 2. Al hacer clic en un servicio de usuario se abrirá otra ventana que contiene la descripción general del Servicio de usuario y descripciones de cada uno de los servicios que lo componen, además de dónde se utilizan, como se muestra en la gráfica a continuación. La última pieza de información puede ser ignorada ya que estará a cargo de la herramienta Turbo Architecture, se ilustra a continuación. (Haga clic en + para mostrar)
Figura 7: página web de servicios de usuario de la Arquitectura ITS USA.
Paso 3. Crear una hoja de cálculo, luego copia y numera las descripciones de los servicios de usuario aprobados por los Grupos de Interés (Ver Cómo se Crea?)en las dos columnas de la izquierda. Marca las columnas de la derecha con títulos para los números de los servicios al usuario y descripciones que coinciden con la descripción de cada servicio, más (opcionalmente) una columna adicional para los supuestos, referencias cruzadas a otras coincidencias, o comentarios.
Paso 4. Ir a través de las descripciones de los servicios y encontrar los servicios de usuarios adecuados. Copiar en la hoja de cálculo el número y el texto del Servicio (s) del usuario en la fila (s) adecuada frente a la descripción del servicio que coincide con la descripción del servicio dada por los Grupos de interés, duplica filas si se necesita más de un servicio de usuario para coincidir completamente con una descripción de servicio de los Grupos de interés. La tabla que se produce debe ser algo como esto:
|
Servicios de los Grupos de Interés |
Coincidencia de servicio de usuario |
Comentario |
||
|
Número |
Description |
Número |
Descripción |
|
|
2.1 |
La expansión de la ciudad esperada de 10-15k nuevas viviendas e instalaciones comerciales adicionales debe ser compatible con la gestión del tránsito adecuada y los servicios de transporte público. |
2.1.0 |
ITS incluirá una función de gestión de transporte público (PTM). |
|
|
2.1 |
La expansión de la ciudad esperada de 10-15k nuevas viviendas e instalaciones comerciales adicionales debe ser compatible con la gestión del tránsito adecuada y los servicios de transporte público. |
1.6.0 |
ITS incluirá una función de control de tránsito (TC). Control de Tránsito proporciona la capacidad de gestionar de manera eficiente el movimiento del tránsito en las calles y carreteras. Cuatro funciones están previstas, que son, (1) la optimización del flujo de tránsito, (2) la vigilancia del tránsito, (3) de control, y (4) proporcionar información. Esto también incluirá el control de los sistemas de señalización de la red con la eventual integración del control de la autopista. |
|
|
2.2 |
Existe una necesidad general para optimizar el uso de la infraestructura vial existente, mejorar los servicios de transporte público, y mejorar las instalaciones para ciclistas y peatones. |
1.6.1 |
TC deberá incluir una función de optimización de los flujos de tránsito para permitir la capacidad de optimizar el flujo. |
|
Paso 5. La experiencia muestra que es una buena idea para el equipo de arquitectura llevar a cabo este trabajo de forma individual y luego comparar sus resultados al final. Los puntos de acuerdo pueden ser aceptadas y los puntos de desacuerdo debatidos. Al final, se genera una tabla mostrando el emparejamiento entre las descripciones de servicio de los Grupos de interés y las descripciones de servicio de usuario.
Paso 6. Un método alternativo para los Pasos 1-4 se plantea en el paso 1, En este punto seleccionar los "paquetes de servicios", se abrirá una nueva ventana que muestra una lista de los paquetes de servicios de ITS que la arquitectura soporta. (Haga clic en + para mostrar)
Figura 7.1: página web de Arquitectura ITS de E.E.U.U, página de paquetes de Servicio
Paso 7. Al hacer clic en el paquete de mantenimiento se abrirá otra ventana que contiene su descripción y un diagrama de las partes que las conforman. Hay pestañas separadas que dan acceso a una variedad de otra información sobre el paquete seleccionado. (Haga clic en + para mostrar)
Figura 7.2: Pagina web de la arquitectura ITS de los Estados Unidos ITS, Pagina de descripción de paquetes de servicio.
La hoja de cálculo creada en los pasos 3 y 4 se debe tener "Servicios de Paquete emparejados", como el título de las columnas 3 y 4, el cual debe contener la identidad de los paquetes seleccionados.
Paso 8. No tenga miedo de decidir que no todas las partes de una o más de las descripciones de servicios de los Grupos de interés pueden coincidir con uno o más servicios de usuario o paquetes de servicios. Ambos se basan en la forma en que se espera que ITS sea implementado en los EE.UU.
Paso 9. Si no está satisfecho con la forma en que las descripciones de servicio de los Grupos de Interés se han aparejado a las descripciones de servicio de usuario o paquetes de servicios, entonces la Arquitectura ITS Nacional de Estados Unidos tiene que ser modificada para acomodar el servicio (s) que desea proporcionar. Si necesita hacer esto, entonces hay que continuar con el paso 9 y utilizar el servicio de ayuda de la herramienta Turbo Architecture para encontrar la orientación de cómo modificar la arquitectura para incluir paquetes de servicios adicionales y sus elementos asociados.
Paso 10. El siguiente paso es descargar la herramienta Turbo Architecture desde su página en el sitio web de la arquitectura ITS de los Estados Unidos. El enlace está en la pestaña "TURBO ARCHITECTURE " en la parte superior de cada página web y se recomienda que lea esta página antes de comenzar a descargar la herramienta. La descarga de la herramienta también incluirá una copia de la base de datos que utiliza y que contiene los detalles de la arquitectura Nacional ITS de los Estados Unidos.
Paso 11. Si bien la herramienta Turbo Architecture es bastante fácil de usar, antes de hacer es muy aconsejable completar uno de sus cursos de formación, algunos están disponibles en línea. Los detalles de lo que contienen y de cómo participar también están disponibles a través del sitio web de la arquitectura Nacional ITS de los Estados Unidos junto con otros recursos de formación en la parte superior de cada página web en la pestaña “TRAINING/WORKSHOPS ".
La herramienta Turbo Architecture ofrece un paso a paso para el desarrollo de las necesidades de los Grupos de interés en cuanto a los servicios ITS que se quieren prestar. Estos desglosan en subsistemas físicos y requisitos funcionales. También es posible adaptar los flujos de información para satisfacer requisitos particulares del usuario, establecer vínculos con los estándares, e identificar los grupos de interés. Todo esto está contenido en una sola herramienta y los productos están interrelacionados, generando diagramas, tablas y - para la documentación final - páginas web y documentos que colocan la arquitectura a disposición de todos los Grupos de interés. Un ejemplo de un diagrama que muestra los subsistemas y sus interconexiones para una implementación típica de ITS se muestra a continuación (Haga clic en + para mostrar).
Figura 8: Ejemplo de un diagrama de interconexión producido por la herramienta Turbo Architecture
En el diagrama anterior los artículos en "gris" son subsistemas en la arquitectura Nacional ITS de los Estados Unidos que no están siendo utilizados en este ejemplo.
La herramienta Turbo Architecture puede ser utilizado para producir más detalles. Éstas incluyen:
Todo lo anterior se genera usando plantillas preparadas, que contendrán la información seleccionada. Cada tabla e informe se pueden editar para cambiar el diseño o el formato para adaptarse a las necesidades de organizaciones individuales. Ejemplos de estos documentos se puede ver al abrir el ejemplo "marinara", que se incluye en los archivos del programa Turbo Architecture.
Un caso de estudio sobre el desarrollo de una arquitectura nacional ITS para Chile está disponible. (Ver Case Study)
Más información sobre Arquitectura Nacional de Estados Unidos y los detalles de los cursos de formación se puede encontrar en el sitio web de arquitectura Nacional ITS de los Estados Unidos en: http://www.iteris.com/itsarch/. Esta página también proporciona un vínculo de "Contáctenos" en la parte superior de cada página web para aquellos con preguntas específicas.
Una guía completa para la elaboración de arquitecturas ITS partiendo de la Arquitectura Nacional de Estados Unidos se puede encontrar en la publicación US DoT, "Regional ITS Architecture Guidance , Developing, Using and Maintaining an ITS Architecture for your region", disponible para descargarse como un archivo PDF de forma gratuita desde la web del Departamento de Transporte de Estados Unidos en: http://www.ops.fhwa.dot.gov/publications/regitsarchguide/raguide.pdf
Uno de los dos puntos de partida principales para la creación de una nueva arquitectura ITS partiendo de una arquitectura ITS existente, es la arquitectura ITS Marco Europea, comúnmente conocida como la Arquitectura MARCO. Este ejemplo se basa en el trabajo realizado para crear una arquitectura de ITS para una autoridad de carreteras locales en el Reino Unido (el condado de Kent), que ha dado permiso para su uso en este recurso en la web.
Para utilizar la Arquitectura MARCO para crear una arquitectura ITS que soportará los servicios acordados con los grupos de interés implicará tomar los siguientes pasos:
Paso 1. Visita el sitio web de la Arquitectura MARCO (http://www.frame-online.net/) seleccione la pestaña " Library" y hacer clic en " FRAME Architecture", como se muestra a continuación. (Haga clic en + para mostrar)
Figura 9: Pagina web Frame. Principal
Paso 2. En la siguiente página Web que se muestra, descarga las necesidades de los usuarios (archivo doc 1,4 M), además de la versión pictórica de la estructura de las necesidades de los usuarios (archivo PDF 350KB), como se muestra a continuación, y guardar ambos archivos. (Haga clic en + para mostrar)
Figura 10: Seleccionar Necesidades de usuario Marco para descargar.
Paso 3. Crear una hoja de cálculo, a continuación, copia y numera las descripciones de servicio generadas por el equipo de arquitectura (y aprobados por las partes interesadas ( Ver Cómo se Crea?),en las dos columnas de la izquierda. Etiqueta de las columnas a la derecha con encabezado para el Números de necesidades de los usuarios MARCO y Descripciones de las necesidades del usuario que elaboran cada Servicio de aspiración, más (opcionalmente) una columna adicional para los Supuestos, referencias cruzadas a otros resultados, o comentarios.
Paso 4. Ir a través de las descripciones de servicios y encontrar la correspondiente descripción de necesidades de usuario MARCO en el archivo "1.4M doc file" descargado en el Paso 2. El estudio de la tabla de necesidades de usuario ayudará a identificar los grupos de usuario correctos que se deben tener en cuenta. Por el momento, al menos, ignorar el Grupo 1 descripción de necesidades de usuario debido a que éstas son "generales" y se pueden utilizar más tarde en el proceso de adquisición. Estos se refieren a cuestiones como la adaptabilidad, la continuidad, la calidad de los datos, la privacidad, la robustez, la seguridad, la facilidad de uso - todo lo cual tendrá que ser abordado de una forma u otra por varias partes de la aplicación ITS.
Copiar en la hoja de cálculo el Número y el Texto de la descripción de necesidades de usuario MARCO en la fila correspondiente(s) frente a la aspiración de servicio al que son relevantes, duplicar filas si más de una descripción de necesidad de usuario es necesaria para completar el aparejamiento. La tabla que se produjo debería tener este aspecto:
|
Servicios de los Grupos de interés |
aparejamiento de Necesidad de usuario (FRAME) |
Comentario | ||
|
Número de servicio |
Descripción del servicio |
Número de MARCO |
Descripción de necesidad de usuario |
|
|
2.1 |
La expansión de la ciudad esperada de 10-15k nuevas viviendas e instalaciones comerciales adicionales debe ser compatible con la gestión del tránsito adecuada y los servicios de transporte público |
10.1.0.1 |
El sistema proporcionará PT eficaz y atractivo. |
|
|
2.1 |
La expansión de la ciudad esperada de 10-15k nuevas viviendas e instalaciones comerciales adicionales debe ser compatible con la gestión del tránsito adecuada y los servicios de transporte público |
10.1.0.3 |
El sistema deberá ser capaz de ayudar a los operadores de PT en la planificación para el uso óptimo de los recursos existentes para satisfacer la demanda |
Esta necesidad de usuario también es llamado por el servicio 2.2. |
|
2.2 |
Existe una necesidad general para optimizar el uso de la infraestructura vial existente, mejorar los servicios de transporte público, y mejorar las instalaciones para ciclistas y peatones. |
10.1.0.3 |
El sistema deberá ser capaz de ayudar a los operadores de PT en la planificación para el uso óptimo de los recursos existentes para satisfacer la demanda |
Esta necesidad de usuario también es llamado por el servicio 2.1. |
Paso 5. Partiendo de la experiencia, es una buena idea para el equipo de arquitectura realizar este trabajo de forma individual y luego comparar sus resultados cuando todas las Aspiraciones de Servicios han sido resueltas. El resultado final será expresado en una tabla que muestra la lista acordada de Descripciones de Necesidades de Usuario que coinciden con las Aspiraciones de Servicio de los Grupos de interés.
Paso 6. No tenga miedo de decidir que no todas las partes de una o más de las descripciones de servicios pueden ser aparejada a uno o más Descripciones de Necesidades de Usuario. Si esto sucede, la arquitectura del MARCO puede extenderse de modo que proporcione el soporte para estos servicios. La forma de hacerlo se describe en la Parte 3 del Manual de la herramientas FRAME Selection, que está disponible en la misma página web de la herramienta - consulte el Paso 10 y el Paso 7 que sigue.
Paso 7. Si como resultado del trabajo en los pasos 5 y 6 se decide que es necesario extender la Arquitectura MARCO, es esencial ver lo que hay en ella. Para hacer esto en el sitio web, Haga clic en la pestaña " FRAME Architecture " y seleccione la opción " The Browsing Tool", que mostrará la página web desde la cual se puede descargar la herramienta. (Haga clic en + para mostrar)
Figura 11: página de descarga de herramientas FRAME Browsing Tool
Paso 8. La herramienta de exploración tendrá que ser puesta en marcha siguiendo las instrucciones de la página web, que también se explica cómo ejecutar la herramienta. Cuando se ejecuta, la herramienta inicialmente mostrar su página inicial, desde la que se pueden ver los contenidos de la Arquitectura FRAME. Una muestra de su pantalla para parte de la funcionalidad se muestra a continuación (click + para mostrar) las páginas de navegación de la herramienta para los flujos de datos y almacenamiento de datos serán similares en apariencia. También es posible visualizar los diagramas de flujo de datos (DFD's).
Paso 9. La navegación a través de la arquitectura se puede hacer usando el Area de Navegación a la izquierda o a través de los enlaces proporcionados por el texto en color "azul" en la parte principal de una página. También se proporciona orientación sobre cómo navegar a través de la arquitectura MARCO con la Browsing Tool en la página principal y en la página web de MARCO que se hace referencia en el Paso 7.
Figura 12. Pantalla de la página de Browsing Tool
Paso 10. Una vez que esté satisfecho con la forma en que todas las descripciones de los servicios se han aparejado con las necesidades del usuario, descargar la herramienta FRAME Selection. Para ello, haga clic en la pestaña " FRAME Architecture " en la parte superior de la página y en " The Selection Tool " en la lista desplegable que aparece. La página web que aparece se muestra en el siguiente diagrama y proporciona instrucciones para descargar la herramienta, la base de datos que utiliza, su Manual de Usuario (necesario para los pasos 1-13) y el Manual de Referencia (necesarios para el Paso 6). (Haga clic en + para mostrar)
Figura 13. Página de descarga de la herramienta FRAME Selection
Paso 11. Una vez que la herramienta de selección se ha configurado, el Manual del usuario proporcionará orientación sobre su uso para crear la arquitectura ITS. Esto implica la Descripción de Necesidades de Usuario MARCO identificadas en los Pasos 4 y 5 y el uso de la herramienta para incluir la funcionalidad necesaria para soportarlos (punto de vista funcional), el punto de vista físico y - si es necesario - el punto de vista organizativo.
La herramienta de selección realizará comprobaciones de la consistencia lógica de la funcionalidad que se incluye desde las necesidades de usuario que haya identificado en los Pasos 4 y 5. El programa espera que usted resuelva cualquier inconsistencia mediante la adición/eliminación de funciones, flujos de datos, almacenamiento de datos y terminadores. Si aún no lo ha descargado la herramienta Browsing Tool en los Pasos 7 y 8, siga las instrucciones anteriores. Es fundamental el uso de esta herramienta para el estudio de la Arquitectura MARCO y ver lo que está causando las inconsistencias lógicas.
Paso 12. La herramienta de selección permite crear varios puntos de vista físicos y de organización para un punto de vista funcional, lo que es parte del proceso para encontrar la configuración óptima (Ver Usando la arquitectura ITS).
Paso 13. Para crear un subconjunto de arquitectura ITS, se crea un nuevo punto de vista físico que incluye tanto del punto de vista funcional como es requerido por la sub-conjunto. Se pueden crear varios sub-conjuntos de arquitecturas ITS desde un punto de vista funcional utilizando la Herramienta FRAME Selection. Es posible experimentar mediante la selección de diferentes partes del punto de vista funcional - o crear diferentes puntos de vista físicos para la misma selección.
La herramienta FRAME Selection produce un conjunto de archivos que contienen tablas con todos los detalles de los contenidos de los puntos de vista funcionales, físicos y de organización. También es posible exportar el contenido de los puntos de vista como una base de datos para su uso con herramientas tales como el ACCESS.
Debido a la naturaleza flexible de la Arquitectura MARCO, ya que está pensado para ser adaptado fácilmente a implementaciones ITS individuales, no ha sido posible crear una función de creación automática de diagramas. Pero éstas se pueden crear fácilmente usando las tablas y una herramienta de dibujo como Visio.
Las siguientes figuras ilustran algunos de los materiales que se pueden producir como consecuencia de la creación de una arquitectura ITS desde la Arquitectura MARCO, utilizando la documentación de la herramienta FRAME Selection. Se relacionan con la arquitectura ITS desarrollada por el Consejo del Condado de Kent, en el Reino Unido y se muestran con el permiso de ese Consejo.
Los diagramas y tablas que se muestran a continuación se han creado a partir de las tablas producidas por la herramienta de FRAME Selection.. El uso de estas tablas, diagramas y otras tablas pueden ser creadas son importantes para especificar y visualizar la arquitectura.
Este diagrama muestra una página de muestra de la lista de descripciones de servicio que se crearon a partir de las "aspiraciones de los Grupos de interés" resultantes de las reuniones de consulta realizadas por el Consejo del Condado de Kent (Kent CC) antes de que la arquitectura ITS fuera creada.
Figura: Ejemplo de descripción de servicios para la Arquitectura ITS de Kent CC
El "diagrama contextual" muestra los enlaces de comunicaciones con todas las entidades fuera de la arquitectura ITS Kent CC. El límite del sistema se muestra por la línea discontinua de color rojo. Algunos de los enlaces de comunicaciones que cruzan la frontera del sistema será electrónica, tales como enlace de la organización de mantenimiento, mientras que otros serán a través de interfaces hombre-máquina (HMI), como enlaces a "operadores" y viajeros. En el ejemplo mostrado, el término "operador" hace referencia una persona responsable de la gestión de un sistema informático. Otros enlaces de comunicaciones serán de diferentes maneras. Por ejemplo, los enlaces de "tránsito" serán a través de una variedad de mecanismos.
Figura: El diagrama de contexto Arquitectura ITS Kent CC con los límites del sistema
En el ejemplo de la Arquitectura ITS Kent CC a continuación, todos los componentes se han agrupado en tres "subsistemas". Otras arquitecturas ITS podrían tener más o menos de estos subsistemas.
Figura. Arquitectura ITS Kent CC Diagrama punto de vista físico de alto nivel
Los componentes dentro de este subsistema se han agrupado para formar varios "módulos", cada uno de los cuales suministra la totalidad o parte de un servicio. Para cada "módulo" se muestran sus enlaces de comunicaciones con el mundo exterior de la Arquitectura ITS Kent y son los mismos que los enlaces que se muestran en el diagrama de contexto. Diagramas similares a esta se produjeron para mostrar los módulos en los otros dos subsistemas.
Figura. Diagrama de Subsistemas de la arquitectura ITS Kent CC
Esta parte de la tabla en el punto de vista de las comunicaciones, muestra los requisitos para algunos de los enlaces de comunicación identificados en el punto de vista físico. En este caso particular, el enlace es entre dos módulos en diferentes sub-sistemas. Otras tablas similares fueron producidos para otros enlaces electrónicos entre los módulos, subsistemas y para el intercambio de datos con el mundo exterior. La información contenida en estas tablas se utiliza para definir los tipos de enlaces necesarios y ayudar a especificar los estándares con los que deben cumplir.
Figura. Una pagina del punto de vista de comunicaciones del la arquitectura ITS Kent CC
Esto es parte de la tabla que muestra los vínculos entre las "aspiraciones" creadas por los Grupos de interés y los "módulos" en el punto de vista físico. Esta tabla es más útil si los servicios se llevarán a cabo durante un período de tiempo, ya que muestra lo que "módulos" serán necesarios por cada servicio. En algunos casos, pueden ser proporcionados servicios adicionales "gratis" porque los componentes especificados en el punto de vista físico tienen la capacidad de ser compartidos.
Figura. Una página de la arquitectura ITS Kent CC, tabla de componentes requeridos por los servicios
Se pueden crear Diagramas y tablas adicionales para otros puntos de vista, los cuales proporcionan una visión más detallada de una arquitectura ITS (Ver Qué significa Arquitectura ITS?). Los ejemplos podrían incluir:
Información gratuita acerca del uso de la Arquitectura MARCO - incluyendo su extensión - está disponible en el sitio web de Arquitectura MARCO en: http://www.frame-online.net/. Para encontrar alguna de esta información, desplazarse por la página de inicio hasta encontrar enlaces para temas específicos. Las sección "FAQ" de la página web (en el "FRAME ARCHITECTURE" del menú desplegable) y las páginas del menú desplegable "LIBRARY", por ejemplo " Articles and Papers ", proporcionar más información. Cualquier pregunta (y comentarios) que no son respondidas por cualquiera de estos recursos se pueden enviar a info@frame-online.net.