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

Se encuentra usted aquí

Porque crear una arquitectura ITS?

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.

Beneficios de Crear y Usar una Arquitectura ITS

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.

Operadores de las carreteras de la red.

Los beneficiarios de ITS pueden ser autoridades viales, entidades operativas de la carretera – quienes se  pueden beneficiarse de las arquitecturas ITS de varias maneras:

  • A través de la independencia de la tecnología con una planificación más fácil para la inversión a largo plazo y mejor entendimiento de cómo se pueden hacer las mejoras a futuro.
  • Mediante la creación de un mercado abierto para componentes, sistemas de comunicaciones y de una selección de proveedores basados en el uso de las estándares  de acceso público.
  • Menores costos a través de una competencia más abierta entre proveedores ITS de   equipos y servicios, y los proveedores de comunicaciones.

Proveedores de servicios de transporte

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:

  • Un enfoque planificado para el despliegue de los  servicios ITS (como la planificación del viaje, localización de flotas de vehículos, control de la carga, o Estacionamiento vigilado para camiones)
  • El uso de un equipo compatible con los mismos componentes y las interfaces que se utiliza en otras partes para beneficiarse de la interoperabilidad, reutilización de datos y evitar la inversión redundante.
  • El potencial de integrar un servicio con otro de una manera transparente y lógico.

Proveedores

Los proveedores pueden ser proveedores de componentes, proveedores de comunicaciones o integradores de sistemas - para quienes la arquitectura ITS proporciona los siguientes beneficios:

  • Menor riesgo para las inversiones en sistemas, desarrollo de componentes comunicaciones consistentes con el enfoque común proporcionado por la arquitectura.
  • La posibilidad de ciclos de producción más rentables y  más grandes que surgen del uso de "sistemas abiertos" y estándares disponibles públicamente – los cuales  pueden ampliar el mercado.
  • Mayores oportunidades para las pequeñas y medianas empresas para  participar en la cadena de suministro, proporcionando componentes especializados.

Grupos de interés 

La arquitectura como medio de enfoque puede ayudar a todas las partes interesadas en:

  1. Explorar configuraciones alternativas de sistemas- por ejemplo, para comprender las ventajas y desventajas de procesamiento de datos en ubicaciones físicas particulares.
  2. Información sobre lo que  el ITS tiene que hacer en la práctica - Proporcionando una mejor comprensión de su contribución a las operaciones actuales y planes futuros.
  3. Refinar las especificaciones y requisitos para los componentes y las comunicaciones antes de realizar inversiones importantes.

Riesgo de no Usar una Arquitectura ITS

Los riesgos de no llevar a cabo el proceso de desarrollar una arquitectura ITS pueden incluir:

  • Riesgo de incumplimiento de las expectativas de los grupos de interés cuando se consideró el  despliegue de ITS.
  • Falta de valoración de las oportunidades de integración de los servicios del ITS.
  • Una valoración limitada de oportunidades de diseño - por ejemplo:
  • Dependencia de los sistemas propietarios (a menudo específicos a un proveedor para todos los componentes). Mientras que los sistemas propietarios pueden ofrecer beneficios en términos de condiciones de compra favorables – la expansión posterior, el mantenimiento y la integración con otros servicios pueden llegar a ser difícil.
  • Limitando las opciones para desarrollar aún más los servicios a causa de una elección de un tipo y estilo de las telecomunicaciones en particular.
  • Seleccionar  sistemas técnicos que puedan quedar obsoletos en el tiempo.

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.

Palabra de Aliento

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 una arquitectura ITS en el proceso de implementación ITS

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

Otras metodologías de Arquitectura

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.

Arquitectura Empresarial

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".

 

EL Open Group Architecture Framework (TOGAF)

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#

 

Arquitecturas Orientada a Objetos

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.

Problemas para economías en Desarrollo

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.

 

Referencia

No reference sources found.