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

Se encuentra usted aquí

Programa De Ingeniería De Sistemas

El desarrollo de los ITS en la red de carreteras de Operaciones (RNO) se remonta a los sistemas simples que se usaban para controlar el tránsito por carretera hace unos 50 años. El sistema de control recoge datos sobre el flujo de tránsito, lo procesa y de los resultados de este procesamiento – envía comandos de salida a los conductores de vehículos, como se ilustra en el siguiente diagrama. Los datos fueron recogidos de sensores que detectan el paso de vehículos de carretera, y los comandos de salida eran las indicaciones "rojo-amarillo-verde" de los semáforos.

Figura 1: Una muy sencilla  aplicación de ITS

Desde aquellos días lejanos, ITS ha evolucionado para  convertirse en mucho más grande (compatible con una amplia selección de servicios) y mucho más complejo (que necesita más y diferentes componentes). ITS ahora puede:

  • Involucrar a varios tipos diferentes de recolección y procesamiento de datos
  • Cubrir áreas geográficas distintas, y a menudo diferentes
  • Involucrar a varios modos de transporte por carretera que incluye enlaces a otros modos distintos de la carretera (Ver  Tecnologías de Monitoreo)

El advenimiento de los sistemas cooperativos (por lo general en expresado como Cooperative-ITS (o C-ITS) y los llamados "vehículos conectados" en los EE.UU.) aporta una mayor complejidad que implica tener que compartir  los datos recogidos y los resultados del procesamiento de datos, en el que los vehículos cumplen una papel más activo. El sistema que se muestra en el diagrama anterior se ha expandido para convertirse en algo similar a lo mostrado a continuación.

Figura 2: Una implementación de ITS moderna y compleja

Este es un ejemplo  típico de muchos de los que están siendo desplegados en muchos lugares alrededor del mundo. A medida que la demanda de ITS crece, la complejidad de cada aplicación se incrementará - tanto en el número de servicios que presta  como  en las áreas geográficas que cubre.

La Ingeniería del sistema proporciona mecanismos que ayudan a asegurar que los proyectos ITS de esta complejidad se pueden implementar con éxito. Esto significa que van a entregar las funciones que los Grupos de Interés esperan, y hacerlo dentro de los plazos y el presupuesto establecidos.

Uno de los principales mecanismos es la capacidad de gestionar los programas de proyectos. Si el programa puede ser gestionado adecuadamente, entonces puede ser completado a tiempo y dentro del presupuesto.

Los programas de ingeniería de sistemas muestran los pasos técnicos o de ingeniería que tienen que ser tomadas desde el inicio del trabajo hasta  cuando se haya completado. En términos muy sencillos, el programa constará de los siguientes cuatro pasos:

  • Capturar los requisitos de los usuarios: describir los servicios que se entregarán
  • Diseñar el sistema: diseñar, desarrollar, crear y producir todo lo que se necesita para entregar los servicios.
  • Probar el sistema: comprobar que se entrega los servicios de acuerdo con sus descripciones.
  • Aceptar y utilizar el sistema: las Grupos de interés están de acuerdo a adoptarlo y empezar a usarlo.

Estos cuatro pasos simples se pueden aplicar a casi todos los proyectos que implementa ITS, independientemente de su complejidad, o no, de cada proyecto

Componentes y  Comunicaciones del sistema

Aunque muchos términos se utilizan en la ingeniería de sistemas, dos se utilizan con más frecuencia que la mayoría de los otros. Ellos son "componente" y “Comunicaciones” del sistema, y es importante  entender la forma en que se utilizan en este contexto.

Componente

Un "componente" de sistema es el nombre dado a cualquier parte constituyente de una implementación ITS  creada a partir de una o más "bits" de hardware - o una combinación de hardware y software - que se puede proporcionar como un elemento individual. Por lo general, un componente ITS proporciona una función particular, por lo que en muchos aspectos es un "bloque de construcción" de la que se ensamblan las implementaciones ITS. A veces, un conjunto combinado de los componentes se llama un "subsistema", pero dependiendo de lo que es, este nombre también se podría aplicar a un solo componente.

Comunicaciones

El término "comunicaciones" o, a veces "enlace de comunicaciones" es el nombre dado al mecanismo por el cual los datos y las instrucciones se transfieren entre los componentes del sistema, o entre un componente y otro sistema que está fuera de la su aplicación. Puede ser uno o más medios de transmisión de datos tales como cables físicos, y/o otras formas menos tangibles de enlaces tales como inalámbricos, microondas o infrarrojos. En este contexto, "comunicaciones" no incluyen los medios de comunicación con las personas que son los operadores de sistemas y usuarios finales (viajeros, conductores y gestores de envío de la carga). Estos serán proporcionados por  componentes especializados del sistema, tales como interfaces de operador o carteles de mensaje variable que proporcionan información a los viajeros y/o conductores. (Ver Compromiso con ITS)

El modelo "V" de Ingeniería de Sistemas

En el mundo moderno, aunque la mayoría de los proyectos para implementar ITS siguen, los cuatro pasos señalados anteriormente, cada paso se ha vuelto más complejo. Esta es una tendencia creciente en la medida de ITS evoluciona, sobre todo ahora que los nuevos servicios  que dependen de los datos que comparten entre ellos (Cooperative-ITS) están pasando de la competencia exclusiva de los esfuerzos de investigación y desarrollo a proyectos reales de aplicación. Los pasos de los programas para estos proyectos deben ser ampliados a partir de los cuatro se destacó anteriormente. El uso se hace a menudo de lo que se llama el modelo de ingeniería de sistemas "V". Varias descripciones de este se pueden encontrar en los recursos, tales como los libros de texto de ingeniería de sistemas. La simplificación de algunos de los términos que se encuentra en estos recursos produce el programa se ilustra a continuación.

Figura 3. Diagrama de Ingeniería de sistemas

Los dos primeros pasos - "descripciones de servicios" y " arquitectura ITS" - que se muestran en el lado izquierdo de la "V" se detallaron aquí. (Ver Qué significa Arquitectura ITS?)

Aquí se proporciona más información acerca de las dos etapas restantes de este lado y "Diseño de componentes". (Ver Desarrollo Técnico)

Todos los pasos en el lado derecho de la "V", que son acerca de las pruebas y la integración, se discuten aquí. (Ver Integración y Prueba)

Algunas versiones del modelo de "V" incluyen un paso llamado un concepto de operaciones, o ConOps. Aparece generalmente en  la Descripción del Servicio o en los pasos de la Arquitectura ITS en la parte superior izquierda de la figura anterior. El trabajo en estos dos pasos  puede dar información a los ConOps, y más detalles acerca de este trabajo se detalla aquí. (Ver Qué significa Arquitectura ITS?)

Además del modelo de ingeniería de sistemas "V", otras metodologías también están disponibles para gestionar  implementaciones de ITS. Estos incluyen "Arquitectura Empresarial" y el Open Group Architecture Framework (TOGAF) que se discuten en el contexto de  la arquitectura ITS. (Ver Qué significa Arquitectura ITS?)

Verificación y validación

Así como la progresión lógica de una etapa a la siguiente, es importante incluir "Verificación" y "validación" como enlaces entre algunos de los pasos.

Verificación: este es un proceso para probar si el componente del sistema cumple con todos los requisitos de diseño y las especificaciones técnicas en cada etapa. Lo que se hace en un paso debe ser compatible con los resultados de los pasos anteriores. Así, por ejemplo, el paso  "diseño de subsistema  y adquisición de comunicaciones" puede mostrar que algunas de las decisiones tomadas en el paso prevo "especificaciones de los componentes y requisitos de las comunicaciones" son difíciles o imposibles de lograr. En este caso, la Arquitectura ITS tendría que ser revisada para ver si  es necesario introducir cambios para resolver el problema. Si lo son, dará lugar a una revisión de las especificaciones de los componentes o los requisitos de comunicación y algunos de los otros resultados obtenidos de ella. (Ver Usando la arquitectura ITS)

Validación: este es el proceso de comprobar si lo que se ha producido como resultado de cada paso en el lado izquierdo del modelo de "V" logra el resultado deseado, y requiere que se produzcan especificaciones de prueba. La Creación de una especificación de prueba debería ser una parte de cada paso en el lado izquierdo del modelo de "V". Si no es posible poner a prueba el resultado, ¿cómo puede alguien saber si lo que se ha producido está haciendo lo que se supone que debe hacer? En esta situación, puede ser mejor  revisar el diseño para ver lo que hay que modificar para hacer las pruebas posibles

El progreso de una etapa a la siguiente por el lado izquierdo de la "V" no debe realizarse a menos que la verificación se ha completado y la especificación de la prueba ha sido elaborada y acordada.

"Visión" de ITS

A veces, y sobre todo si la implementación ITS implica varios grupos de interés, o hay que  proporcionar varios servicios, es muy útil crear una declaración de la "visión" que los Grupos de interés  tienen de lo que quieren lograr. Se genera en estrecha relación con los grupos de interés (tal vez con uno de ellos liderando el proceso) y proporciona una visión global de la implementación de ITS, resaltando lo siguiente:

  • Los servicios que van a ser proporcionados, con no más de una breve descripción de un sola frase  cada uno
  • ¿Quién se beneficiará de la introducción de los servicios, con un breve resumen de lo que se espera que sean  los beneficios.
  • La fecha (s) cuando  propuesta para la presentación de los servicios
  • ¿Cuáles son los grupos de interés y por qué promueven  la implementación de ITS

La "visión" debe ser menor a una página de longitud, y diseñada para ser leída en no más de 5 minutos. Si es necesario, viñetas y esquemas deben ser utilizados con preferencia a la utilización de gran cantidad de texto. En muchos sentidos, es un documento de "venta" para ser leído por los tomadores de decisiones de alto nivel, tales como los que  asignan presupuestos financieros. Pero también se puede utilizar para fomentar la participación de otros grupos de interés. El otro uso que tiene es como el precursor de las descripciones más detalladas de los servicios que los grupos de interés tendrán que presentar en el inicio de los pasos en el modelo de "V", donde se creará la arquitectura ITS.

Problemas para Economías en Desarrollo

(Ver Planificación de un Programa ITS)

Muchos países en desarrollo pueden tener poco o nada de los componentes de ITS o de los enlaces de comunicaciones. Por esto, los usuarios, los viajeros, los transportistas (usuarios finales) y los administradores de carreteras tendrán una experiencia limitada en el uso de muchos de los servicios que  ITS pueden presentar, ya que los que prestan los servicios tendrán poca o ninguna experiencia de la gestión de lo que se requiere para su prestación. Este es un factor importante para decidir el alcance de al menos la implementación inicial de ITS con en el fin de construir la experiencia de los ITS y manejar las expectativas.

La creación de la "visión" que se describe en la sección anterior, puede, y debe, generar mucho entusiasmo acerca de los servicios que  ITS puede presentar, y de los beneficios que van a entregar a los viajeros y a los transportistas. Será tentador  incluir todos los servicios posibles en la primera implementación ITS. Sin embargo, esto será un error,  y cuya consecuencia probable sea que la implementación de por lo menos alguno de ellos falle y/o que los que se implementen no funcionen como se espera,  y por lo tanto,  no entreguen los beneficios esperados. El ITS puede obtener una "mala prensa" y hacer que sea difícil obtener el apoyo de los Grupos de interés para implementar servicios adicionales - o en el peor de los casos – arreglar las que ya están implementadas y que no están funcionando como se esperaba. También puede resultar en el desarrollo de las malas relaciones con los proveedores y/o integradores de sistemas, quien  probablemente será culpado por el bajo rendimiento de los servicios.

A pesar de lo que se puede decir en la"visión", se debe establecer un contexto realista para la  implementación inicial de ITS. Por ejemplo:

El servicio que proporciona prioridades para los autobuses no funcionará hasta que el sistema de gestión de tráfico  que necesita para operar ha sido implementado primero y ha sido probado para administrar efectivamente el tráfico mediante la red de carreteras de la manera que se esperaba.

Un servicio de planificación de viajes no funcionan muy bien a menos que el servicio que reune y compara los datos de tráfico ha estado funcionando durante un período de tiempo suficiente para realizar predicciones fiables para los tiempos de viaje, algo para lo que es casi seguro que se requieran varios meses de funcionamiento.

El punto importante es establecer un escenario realista para el punto de partida de la implementación ITS en términos de la cantidad de servicios que va a proporcionar. Esto podría incluirse en la "visión", pero  quizás es mejor  en un documento separado " estrategia de ejecución de ITS". Este documento también debe incluir detalles de un programa progresivo para la introducción de nuevos servicios en un período de tiempo - que tal vez se extienda años en lugar de semanas o meses. (Ver Planificación Estratégica y el caso de estudio de Finnish ITS Strategy y Seattle ITS Strategic Plan 2010-2020 )

Un "programa progresivo" (o "plan progresivo") produce una implementación gradual de los servicios de ITS en etapas en lugar de la aplicación de todos los servicios a la vez. Cada etapa se inicia después de la anterior se ha completado y está operando con éxito. Por ejemplo, antes de que se desarrollen las medidas prioritarias para los autobuses, el servicio de gestión de tráfico de la que dependen debe estar en funcionamiento y  reportando  beneficios. Un programa progresivo puede ser implementado durante meses o incluso años, dependiendo de la cantidad de servicios y sus complejidades. La formación y gestión del personal que participa en la implementación de ITS  se puede gestionar mejor de esta manera. El uso de un equipo básico de  personas que manejan la implementación de servicios sucesivos proporciona continuidad de los conocimientos y la experiencia.

El plan progresivo no debe ser dependiente del tiempo, pero impulsado por la probada aplicación con éxito de la anterior serie de servicios. Así ITS será implementado en una serie de pasos lógicos en vez de un solo "big bang". Otra buena razón para tener un plan progresivo es que va a ayudar a crear un buen nivel de interés por parte de los posibles contratistas porque existe la posibilidad de seguir trabajando cuando los servicios adicionales se añadan en el futuro.

Medios de Comunicación Y Publicidad

Los medios de comunicación y la publicidad pueden ser muy importantes para el éxito de cualquier implementación de ITS. La información proporcionada a los medios de comunicación (radio, televisión, periódicos, medios de comunicación social, las revistas técnicas y otras plataformas) debe ser manejada adecuadamente. Si la aplicación está llevando a cabo de acuerdo al plan y los servicios que se ofrecen brindan los beneficios que los  viajeros,  transportistas públicos y transportistas de carga quieren - no debería haber ningún problema. Si cualquiera de estos no es el caso - por ejemplo, un esquema de ITS que es muy costoso o impopulares - entonces los medios de comunicación puede llegar a ser hostiles. La publicidad negativa es más probable cuando la implementación está retrasada, está por encima del presupuesto o los servicios no funcionan como se espera.

Puede ser útil emplear un consultor de medios o publicista con experiencia en asegurar que la información sobre la implementación de ITS sea oportuna y correcta, y que no está abierta a interpretaciones erróneas.

Video:Professor Brian Collins on Systems Engineering

Información Adicional

El USDOT ITS ePrimer Módulo 2: incluye una lista muy útil de las fuentes de referencia de información para ayudar a un mayor estudio de todo este tema. El módulo está escrito por Bruce Eisenhart, vicepresidente de operaciones, el consenso Systems Technologies (ConSysTec), Centreville, VA, EE.UU. y está disponible en línea en:

http://www.pcb.its.dot.gov/eprimer/module2.aspx

Referencia

No reference sources found.