La ingeniería de sistemas es un enfoque interdisciplinario para el diseño y gestión de proyectos grandes y/o complejos de ingeniería en todas las etapas de su ciclo de vida, desde su inicio hasta el final. Por lo general, el proyecto comienza con una "visión" que describe en términos generales lo que se espera lograr con el proyecto y termina cuando todas las tareas de ingeniería en el proyecto se han completado y se ha logrado la aceptación del cliente. A veces un proyecto se completa con un equipo interno, en cuyo caso el final será cuando lo que se ha proporcionado, ha sobrevivido a su utilidad y ha desmantelado. Puede ser bastante difícil de resolver cuando un proyecto grande y/o complejo de ingeniería está completado. El uso de mecanismos de ingeniería de sistemas permite identificar y abordar todos los problemas de forma lógica - y por lo general de manera oportuna.
Aunque existe cierta controversia acerca de la fiabilidad de las estadísticas publicadas sobre las tasas de éxito y fracaso de los proyectos de TI, hay mucha evidencia para sugerir que un número significativo no tienen éxito - con algunos que son fracasos, a menudo conduciendo a su cancelación. La definición de fracaso por lo general significa que son:
Una manera de definir ITS es decir que se trata de la aplicación de la Tecnología de la Información y las Comunicaciones (TIC) al transporte y - en el contexto de Operaciones de la Red de Carreteras - sobre todo al transporte por carretera. Es razonable suponer que las tasas de éxito de los grandes proyectos implementan ITS son probablemente similares a la de los proyectos de TI si no se toman las medidas adecuadas para reducir al mínimo el riesgo de fracaso.
Uno de los elementos clave en la aplicación de la metodología de ingeniería de sistemas es la participación de todos los interesados para que puedan sentirse parte de la implementación ITS. Esto puede lograrse mediante la participación en actividades tales como la definición de la visión de los servicios que proporcionará ITS - y la comprensión de cómo la provisión de estos servicios puede traducirse en algo que puede ser implementado, que es creado y desplegado.
La ingeniería de sistemas proporciona mecanismos habilitan a los proyectos para las implementaciones ITS que se entregaran de las siguiente forma:
El cumplimiento de cada uno de estos objetivos de entrega ayudará a cada proyecto ITS particular para llegar a una conclusión exitosa. Un resultado importante es que el éxito va a animar a los grupos de interés existentes y nuevos:
Como con cualquier metodología, el uso de la ingeniería de sistemas no proporciona una solución total. Otros factores son la experiencia y la creatividad del personal clave, el conocimiento y la conciencia de la situación de los grupos de interés y la competencia de las que realmente hace la implementación ITS.
El siguiente enlace a una conferencia a cargo del Prof. Brian Collins, que es una autoridad de clase mundial en la ingeniería de sistemas, ofrece una introducción general y una visión general del tema y muestra cómo un enfoque de sistemas se ha utilizado para resolver algunos problemas bien conocidos en transporte. El clip de vídeo tiene una duración de unos 50 minutos y si se ve en su totalidad proporcionará algunas ideas útiles sobre diversos aspectos de la implementación que deben tenerse en cuenta en la aplicación de los ITS. Al responder a las preguntas Profesor Collins subraya la importancia de incluir tanto los políticos como los medios de comunicación como partes interesadas en la implementación ITS
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:
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:
Estos cuatro pasos simples se pueden aplicar a casi todos los proyectos que implementa ITS, independientemente de su complejidad, o no, de cada proyecto
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.
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.
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)
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?)
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.
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:
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.
(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.
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.
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:
El caso de estudio del sistema de navegación e Información de transporte integrado de Abu Dhabi (I-TINS) proporciona un ejemplo de cómo se aplica un enfoque de sistemas en la práctica. (Ver Case Study: System Integration (Abu Dhabi)) Hay dos aspectos diferentes en la gestión de la ejecución de un proyecto ITS, los cuales son importantes.
La primera se lleva a cabo por el Project Manager (PM) y cubre todo el trabajo, pero con un fuerte énfasis en los aspectos financieros y contractuales. También implica tratar con los usuarios de servicio del ITS y los clientes, algunos de los cuales pueden no estar representados por cualquiera de los Grupos de Interés.
Un segundo aspecto es la parte técnica o ingeniería de la obra y se lleva a cabo por una persona a menudo llamado el "técnico" y/o el "Gerente de programa de ingeniería" Esta persona se concentrará en el programa de trabajo técnico implicado en la implementación ITS.
La gestión de proyectos incluye la gestión de todo lo que es necesario para completar la implementación de ITS con la satisfacción de todos los grupos de interés. Al principio, la gestión del proyecto debe asegurarse de que hay un plan de proyecto acordado y que el plan es seguido durante la ejecución. El nivel de detalle debe ser suficiente para todos los participantes sepan lo que tienen que hacer, el marco temporal en el que tiene que ser completado, cualquier actividad anexa relacionadas con el proyecto y la disponibilidad de los recursos externos que se requieren.
Como parte de la implementación del plan del proyecto, la gestión de proyectos implicará:
Actuar como "intermediario" con los Grupos de interés es un proceso bidireccional. Significa que representa al proyecto ante los grupos de Interés a fin de informarles acerca de lo que está ocurriendo y las razones para ello. También significa que representa a los grupos de interés en el equipo de proyecto para asegurarse de que se aborde cualquier preocupación - y para hacer frente a los cambios que a los Grupos de interés les gustaría ver. Estos cambios pueden ser cualquier cosa, desde eventos planificados hasta requerimientos de servicios - los cuales pueden cambiar a medida que avanza la implementación del proyecto.
Los cambios en los requerimientos de servicios son a veces conocidos colectivamente como "requisitos de arrastre" y pueden ser el resultado natural de los cambios en las actitudes de los usuarios hacia los desarrollos en la tecnología de ITS y que hacen posible servicios adicionales y/o revisados. (Ver Cómo se Crea?)
La magnitud de la actividad de gestión de proyectos dependerá del tamaño y el alcance de la implementación de ITS. Aparte de los factores habituales tales como el número y el alcance de los servicios, modos de transporte y la cobertura geográfica, otros factores que afectan en la actividad incluyen el número de los Grupos de interés, los proveedores y las empresas de comunicaciones. Se puede necesitar algunas obras de construcción, tales como un centro de control, además de otros trabajos como la instalación de equipos en diferentes lugares (por ejemplo, el borde de la carretera) y, a veces, la retirada y eliminación adecuada de componentes existentes. Ninguna de estas tareas y actividades debe ser subestimadas y algunos tienen sus propias complejidades particulares, tales como la instalación de un cartel de mensajes variables en una parte ocupada de la red vial que requiere restricciones temporales de tráfico. Todos ellos tendrán que aparecer como items en el plan del proyecto.
Si la mayoría de las actividades tienen lugar en las formas y en los tiempos indicados en el plan del proyecto, entonces la actividad de gestión de proyectos no es demasiado dispendiosa. Es cuando hay desviaciones del plan de proyecto o cuando surgen dificultades contractuales que las aumentan significativamente la actividad de la gestión del proyecto, en escala, complejidad y contenido. Habrá momentos en los que (por desgracia) será necesaria cierta diplomacia si se quiere que todas las actividades relacionadas con la implementación del ITS puedan completarse con cierto grado de satisfacción para todos los que están involucrados.
Las actividades de gestión de proyectos se llevan a cabo por un director de proyecto (PM) que debe ser nombrado antes de cualquier trabajo comience. Quién puede ser dependerá de una serie de factores. De acuerdo a la circunstancia de la PM puede provenir de:
No importa de dónde se seleccione, la persona que es PM tiene que gestionar todo el trabajo para implementar el ITS en representación de todos los participantes, independiente de los grupos de interés o de los proveedores, y no deben favorecer los intereses de una sola entidad o grupo a expensas de los otros.
Para las implementaciones de ITS grandes, que son a menudo complejas y tienen una gran cantidad de contenido de ingeniería, será beneficioso si una persona es designada para administrar el programa de ingeniería de sistemas. Este trabajo puede ser visto como un "gestor de proyecto técnico" o "gerente de ingeniería", debido a que la persona que realiza el trabajo no puede participar directamente en los aspectos contractuales o financieras.
La persona designada para ser el director técnico del proyecto puede provenir de
Sea cual sea el origen de la persona que administra el programa de ingeniería de sistemas, tienen que ser capaces de gestionar todos los pasos que se muestran en el modelo de ingeniería de sistemas de "V" (Ver Programa de Ingeniería de Sistemas) de acuerdo con el plan del proyecto.
Obviamente, es importante contar con la cantidad de personal correcto en la gestión de la implementación de ITS. Para la parte de gestión de proyectos de este trabajo, no hay nada mejor que un director de proyecto con experiencia (PM), de preferencia con algunos títulos profesionales reconocidos en la gestión de proyectos. La experiencia de trabajar en ITS no es necesaria, ya que el PM se refiere principalmente a cuestiones contractuales y financieras, pero el conocimiento de las leyes y costumbres locales será ventajoso. Lo ideal sería que el PM debe ser nombrado antes de que se inicie la etapa de "adquisición" del ITS. Esto les permite estar involucrado en las negociaciones finales del contrato y se apropie de los términos y condiciones acordados. También significa que pueden producir o validar el plan de proyecto en una etapa temprana, lo que le permitirá tener el mayor impacto beneficioso sobre el proyecto. El PM también debe participar en las negociaciones para cualquier sub-contratos que cubra actividades especiales, tales como la construcción de obras y la instalación de componentes al borde de la carretera.
Como se ha señalado anteriormente, el PM puede provenir de un proveedor líder, o el integrador de sistemas (si se ha contratado alguno), o un grupo de interés dominante, o ser un completo extraño. Una vez que la implementación de ITS se ha completado pueden pasar a otro trabajo. Pero si la implementación del ITS requiere alguna actualización o mejora de trabajo, entonces será beneficioso el empleo del mismo PM para tomar ventaja de su experiencia previa y las relaciones que ha construido con cualquiera de los que estarán involucrados.
Comentarios similares se aplican a la persona que administra el programa de ingeniería de sistemas, el "jefe de proyecto técnico" o "gerente de ingeniería", con la excepción de que será una gran ventaja si tienen alguna experiencia previa de trabajo en ITS. Ellos deben ser nombrados como parte de la etapa de "adquisición" de la implementación del ITS, tal vez como parte del contrato con un proveedor, proveedor de comunicaciones, o integrador de sistemas.
La ventaja de tener un administrador de sistemas del programa de ingeniería que sea empleado de uno de los principales grupos de interés, es que esa persona también podría ser retenida para el trabajo en cualquier actualización o mejora que la implementación del ITS requiera en el futuro, para aprovechar el conocimiento y las complejidades que han sido obtenidos de los trabajos anteriores. La dotación de recursos de personal para los componentes de desarrollo de comunicaciones y pruebas, será una cuestión de los proveedores implicados, pero se debe esperar que la persona o personas involucradas tendrán alguna experiencia relevante.
Para las economías en desarrollo, encontrar las personas adecuadas para las funciones de PM y sistemas de gestión de proyectos de ingeniería puede ser difícil. Si la experiencia en cualquiera de estas funciones está disponible a nivel local, es más probable que sea de gestión de proyectos. El empleo de una persona con conocimiento de las leyes y costumbres locales será una ventaja definitiva.
Encontrar a una persona adecuada a nivel local para la función de gestión de programas de ingeniería, probablemente será más difícil. Y será más difícil si no hay experiencia local en tecnologías de ITS y las comunicaciones relacionadas.
Hay varias empresas de consultoría especializadas en la implementación de ITS que serán capaces de proporcionar a los administradores de programas de ingeniería con la experiencia adecuada. Estas empresas varían en tamaño desde grandes organizaciones internacionales con oficinas en varias partes del mundo, a las organizaciones pequeñas de una sola persona. Los primeros con tendencia a tener una experiencia más amplia en la implementación de los servicios de ITS que las organizaciones unipersonales, pero esto no significa necesariamente que sean mejores. Lo mejor es hacer una investigación para averiguar que implementación ITS realmente están trabajando en la actualidad y han trabajado en el pasado para evaluar su experiencia. También comunicarse directamente con sus clientes reales casi siempre proporcionará una idea mucho mejor de lo buenos que son.
Idealmente, lo que se necesita es una organización que está preparado para establecer una oficina local y contratar y formar a la población local en la gestión de programas de ingeniería. Esto tendrá ventajas claras en que el conocimiento obtenido a partir de una implementación ITS particular, se puede retener localmente y utilizar en cualquier trabajo futuro de ITS relacionado.
La gestión de proyectos es ahora una disciplina por derecho propio. Por lo tanto, debería ser posible encontrar a alguien, o una organización con el conocimiento y la experiencia para llevar a cabo todas las actividades de la manera correcta. Hay organizaciones que promueven activamente el profesionalismo de gestión de proyectos y ofrecen acceso a las titulaciones para los administradores de proyectos. El mayor de ellos es el Project Management Institute (http://www.pmi.org/) que tiene ramas (llamadas capítulos) en la mayoría de las partes del mundo. Se ha publicado un libro titulado "Guía para la Dirección de Proyectos del Conocimiento", que está ahora en su 5ª edición.
Este es el sub-sistema y el diseño de componentes, además de piezas de desarrollo de componentes del modelo de ingeniería de sistemas de "V". (Ver Programa de Ingeniería de Sistemas) Son las piezas que atraen a la mayoría de los involucrados en el desarrollo de tecnología ITS y generan la mayor "emoción". Esto se debe a que el trabajo de desarrollo es donde se inventaron los sistemas, se desarrollan, prueba e implementan - y donde la gente puede tocar el hardware y/o son capaces de crear el software. También es donde las cosas pueden ir muy mal, lo que puede tener un impacto muy significativo en las escalas de tiempo y/o costes para la implementación de ITS en su conjunto.
La motivación para la creación de nuevas tecnologías es que ninguna de las tecnologías existentes permite brindar un servicio que está previsto. También, la creación de nuevas tecnologías para reemplazar las existentes puede hacer que la implementación de un servicio sea más fácil y/o económica, por lo que la mejora de la relación beneficio costo.
Un ejemplo concreto es el servicio para detectar el número de ocupantes en un vehículo. Hasta hace poco, la única manera de hacerlo era tener una persona ubicada en el borde de la carretera para que pudieran comprobar visualmente cada vehículo que pasaba. Ahora las tecnologías de cámaras infrarrojas y de vídeo han avanzado hasta el punto en el que una cámara puede hacer por lo menos algunos de los chequeos
La creación de nueva tecnología está lleno de riesgos y no debe llevarse a cabo sin una justificación adecuada y robusta. Esta justificación puede ser difícil de lograr, sobre todo porque la mayoría de las implementaciones ITS suelen estar limitadas por el tiempo, por ejemplo, los grupos de interés quieren que los servicios estén disponibles ahora, o tal vez en unos pocos meses, pero no dentro de unos años. Lo que los a Grupos de interés no quieren es una escala de tiempo abierta en la que nadie sabe realmente cuánto tiempo se tardará en desarrollar la nueva tecnología requerida. Hay demasiadas historias de la vida real de implementaciones de ITS - y de otras tecnologías- que han fracasado, ya sea porque la nueva tecnología no se ha podido crear y/o desarrollar, o porque el producto resultante era demasiado difícil o costoso de producir.
Utilizando la tecnología existente
Utilizando la tecnología que ya se ha desarrollado, pero nunca se ha aplicado en la práctica, tiene menos riesgo que el uso de nuevas tecnologías. Todavía requiere de una evaluación cuidadosa y una buena justificación, ya que hay muchos riesgos en pasar de la fase de prototipo (o de desarrollo) a la fase de producción, en el desarrollo tecnológico o de ingeniería.
El uso de tecnologías existentes que han demostrado un historial exitoso en otras implementaciones ITS proporciona la menor cantidad de riesgo. También pueden ser mucho más económico, y es muy posible tener una mayor variedad de proveedores que para tecnologías nuevas o en prototipo.
El Diseño y Desarrollo comienza con las especificaciones de componentes y los requisitos de las comunicaciones que se crearon cuando se creó la Arquitectura ITS. (Ver Cómo se Crea?)Si cualquiera de los componentes de los equipos y de las comunicaciones disponibles en la actualidad se va a utilizar (a veces llamada "listos para usar”) entonces no hay mucho que hacer, aparte de integrarlos entre sí. (Ver Integración y Prueba)
Si se requiere algo nuevo, entonces la forma en que los proveedores de componentes y proveedores de comunicaciones van a producirlos se mantienen en secreto, en gran parte por razones comerciales. Pero hay algunas cosas sobre las que los directores de proyectos, integradores de sistemas y otros que supervisan la aplicación ITS pueden hacer preguntas. La naturaleza de las preguntas depende de lo que está siendo desarrollado y puede ser dividido en tres áreas: hardware, software y comunicaciones.
Para muchas implementaciones ITS, no será necesario ningún nuevo hardware, por lo que debería ser posible ver los componentes físicos reales que se producen y pedir evidencia de las pruebas anteriores, sobre todo en los temas relacionados con el cumplimiento de las regulaciones. Si se necesita un nuevo hardware, entonces es razonable solicitar muestras de prototipos y/o pedir demostraciones de los mismos. También puede ser necesario asegurar que se han obtenido todas las regulaciones locales exigidas para localizar y operar equipos en el borde de la carretera.
Software
La mayoría de las implantaciones ITS necesitarán crear un nuevo software, aunque puede que no sea totalmente nuevo y que implique la personalización o la modificación de lo que ya existe. La creación de un nuevo software es difícil de controlar porque no hay nada "físico" para ver. Sin embargo, será posible examinar el diseño de alto nivel del software y luego monitorear los progresos realizados con la creación de módulos dentro de él, incluso si son modificaciones de productos existentes. Obtención de cifras sobre el número de líneas de código producido no siempre significa una gran medida, tiene que ser acoplado con el porcentaje del total que representa.
El proveedor de software debe tener un proceso de comprobación de código robusto y fiable, de modo que lo que se ha producido, se controla (a veces llamado un "código paso a paso") antes de ser probado. Esto es especialmente válido para el software creado por los servicios que requieren acceso a/desde Internet, si la probabilidad de que el acceso no autorizado se reduzca a casi nada. En este caso, debería ser posible llevar a cabo pruebas de intrusión para demostrar que los datos son a prueba de manipulaciones y no es accesible a terceros no vinculados con la implementación ITS.
Si los datos sobre los movimientos y planes de los viajeros se están siendo procesados, se debe revisar cuidadosamente que se esté en cumplimiento de las leyes y las normas de privacidad locales y/o regionales. De nuevo, esto puede requerir pruebas, o pruebas de que el testeo se ha completado con éxito.
Si se están produciendo nuevas interfaces de usuario final, entonces se deben hacer disponibles prototipos para su revisión y pruebas, preferiblemente por representantes de los usuarios, antes que cualquier otro grupo.
Anteriormente los proveedores debían proporcionar una copia del software que desarrollaron para el proyecto como parte de sus obligaciones contractuales. Esto era, o bien para el uso de los grupos de interés en algún momento en el futuro, o para ser mantenidos en depósito en caso de que el proveedor no pudiera realizar los cambios deseados en el futuro. El Software de ahora es a menudo tan complejo y afecta a un gran número de proveedores, que esto ya no es una opción realista. También se requiere que uno o más de los grupos de interés tengan los conocimientos necesarios para utilizar el software, que a excepción de organizaciones muy grandes, no suele ser el caso.
La mayoría de las implementaciones ITS utilizarán enlaces de comunicaciones físicas que ya existen. En algunos casos, ITS puede tener que compartir estos enlaces con otros servicios no relacionados. Hay preguntas importantes que hacerse:
La privacidad de datos será especialmente importante cuando los datos sobre los movimientos de viajeros y de mercancías (planificados o en desarrollo) está siendo recogidos y transmitidos a través de enlaces de comunicaciones. Esto será particularmente importante si la aplicación ITS incluye servicios que son proporcionados por ITS Cooperativos (vehículos conectados). En cualquiera de estos casos, es muy importante comprobar que se están siguiendo todos los estatutos y normas de privacidad locales y/o regionales. (Ver Propiedad & Intercambio de Datos)
En general, los estándares de comunicaciones utilizados en las implementaciones ITS deben haber sido generados por las organizaciones de normalización, tales como ISO, IEEE, CEN, ETSI y SAE. (Ver Estándares ITS) no utilizar estos estándares puede tener los siguientes efectos:
Un ejemplo del segundo punto es que si un mecanismo de comunicación a medida se utiliza para el enlace entre el vehículo y la carretera. Esto significa que todos los vehículos deben tener equipos de comunicaciones específicas equipados, que pueden ser incompatibles con los necesarios en otros lugares, tales como en áreas geográficas adyacentes. En algunos casos esto no importa, por ejemplo, porque los vehículos no son llevados a zonas geográficas adyacentes, pero dentro de los continentes como Europa, Asia, África, además de Norte, Centro y Sudamérica, la circulación de vehículos a través de las fronteras nacionales es cada vez más común.
Las actividades de diseño y desarrollo son probablemente las partes más importantes del proceso de implementación ITS, pero también son los más difíciles de controlar. Información sobre el progreso a veces se puede obtener con sólo hacer las preguntas correctas a los proveedores que realizan el trabajo. Pero al final, puede ser una cuestión de confiar en que los proveedores harán lo que han dicho en sus contratos. Una manera de empezar a construir esta confianza es preguntar a otras organizaciones que han utilizado los mismos proveedores cómo funcionaron sus implementaciones de ITS, ¿hubo problemas que sin resolver, o que se podrían haber evitado con mejores prácticas de trabajo?
La integración es el proceso por el cual se reunen y se prueban en conjunto todos los componentes y enlaces de comunicaciones necesarios para proporcionar los servicios de la implementación de ITS. A menudo es un proceso gradual, con grupos de componentes que se prueban primero antes del conjunto. Cuando se ve desde el "exterior", estos componentes parecen funcionar como uno - y sus identidades y funciones individuales pueden estar ocultos. Cuando se ve desde el "interior", los componentes están trabajando juntos y compartiendo datos.
Antes de que la integración se pueda iniciar, cada uno de los componentes debe ser probado de forma individual. Esto casi siempre tendrá hacerse en un entorno especial que permite simular las entradas y salidas desde el mundo exterior. Una ventaja de la simulación de las entradas es que permite probar el espectro completo de posibles valores y/o condiciones a ensayar - incluyendo los que son de baja probabilidad o inesperado. Para las salidas, la ventaja de la simulación es que los resultados que son inesperadas no deberían causar problemas para otros componentes, o para los usuarios finales. Una vez que las pruebas de los componentes individuales se han completado con éxito, pueden ser probados en conjunto, que el objetivo final de la integración.
Una forma similar de trabajo también debe aplicarse a los enlaces de comunicaciones, que pueden pasar a través de varias ubicaciones físicas y/o uso de varios medios físicos para transferir datos desde un componente a otro. Por lo tanto, es mejor para probar cada parte del enlace individualmente antes de probar todo el enlace como una sola entidad.
La prueba de los componentes y las comunicaciones que se lleva a cabo por lo general tiene las siguientes etapas:
Las etapas (1) a (3) se llevan a cabo por lo general en las instalaciones del proveedor. Si los Grupos de interés han empleado un integrador de sistemas, los pasos (2) y (3) se puede hacer en las instalaciones del integrador, o en un lugar de su elección. Los pasos (4) y (5) se llevan a cabo usualmente en el lugar donde algunos de los componentes van a operar, tal como un centro de control. Puede ser posible aumentar la representación de las interfaces externas para incluir algunas de los usuarios finales como los de estacionamiento para autos y el transporte público. Por estos dos pasos, además de una muestra representativa de las interfaces externas, los enlaces de comunicaciones deben incluirse o simularse.
El Paso (6) es un período de prueba de funcionamiento para la su ejecución. Durante este tiempo todos sus componentes y los enlaces de comunicación deben estar disponibles y ser utilizado para proporcionar todos los servicios que los grupos de interés esperan ver en base a lo que escribieron en las descripciones de los servicios. El período de prueba debe ser lo suficientemente largo para que las situaciones particulares a la que los servicios deben estar disponibles ocurran - por ejemplo, los principales eventos deportivos, determinados tipos de incidentes, los períodos de vacaciones, además de los principales festivales o celebraciones de Año Nuevo.
Casi todos los pasos de prueba identificadas anteriormente deben ser descritos. La posible excepción es el paso (6), que es esencialmente el funcionamiento normal y puede requerir una forma diferente de descripción. Las descripciones de las pruebas en los otros pasos se proporcionan a través de especificaciones de las pruebas que se describen detalladamente los a continuación:
Las especificaciones para cada una de las pruebas deben ser escritas en la etapa correspondiente en el proceso de ingeniería de sistemas. Por ejemplo, el pliego de condiciones de las pruebas de aceptación final debe ser escrito cuando se han creado y acordado las descripciones de los servicios por los Grupos de interés. Lo ideal sería que los Grupos de interés los escriban, pero en la práctica se escriben conjuntamente por los grupos de interés y el principal proveedor o integrador de sistemas. Del mismo modo, las pruebas de aceptación en fábrica y campo deben escribirse cuando se han producido las especificaciones de los componentes y requisitos de las comunicaciones. Aunque los Grupos de interés deben participar, el principal proveedor o integrador de sistemas hará la mayor parte de la obra.
Para el paso (6) una especificación de prueba mucho más simple debería ser suficiente. Puede que sea necesario indicar cómo se llevarán a cabo las pruebas de aceptación en caso de cualquier situación crítica, tales como eventos deportivos, incidentes particulares, vacaciones y fiestas.
Consejos para profesionales
La creación de buenas especificaciones de prueba es un "debe" si los componentes y enlaces de comunicación van a funcionar como se espera. No hay atajos para este requisito. La otra cosa que hacer es mantener un registro de las pruebas que se han hecho, por quién y con qué resultados. Si es posible, conseguir que todas las pruebas sean presenciadas por alguien de la organización que se encarga de hacer las pruebas, o la organización (s) que proporcionó lo que se está probando. Esto será particularmente útil cuando se necesitan repeticiones de pruebas fallidas.
Un requisito previo necesario para la recepción definitiva de que una implementación ITS ha sido terminada con éxito, es la aceptación oficial de las actas de las pruebas realizadas. Esto debería mostrar que todas las pruebas se han completado con éxito y que cualquier repetición requerida de una prueba también se ha realizado con éxito.
Donde hay poca o ninguna experiencia local del uso de ITS entre los grupos de interés, es importante tomar una(o ambas) de las siguientes acciones:
Si es posible, ir por la segunda acción en lugar de la primera, esto es debido a que proporcionará un beneficio duradero una vez que la implementación ITS ha terminado las pruebas de aceptación final. También ayudará a finalizar con éxito los primeros meses de prestación de servicios ITS.
Cuestiones organizativas
Es aconsejable para obtener el mayor número posible - si no todos - de los Grupos de interés involucrados en las pruebas de aceptación final antes de que inicie el período de prueba de operación. Esto les ayudará a familiarizarse con lo que hará la implementación ITS y ayudar a prevenir que el período de prueba de operación tenga demasiadas "sorpresas". También porque la gente de los proveedores, los proveedores de comunicaciones y / o integrador de sistemas estarán presentes en las pruebas de aceptación, cualquier pregunta de los Grupos de interés se pueden responder mucho más rápidamente y con más autoridad.
Una buena manera de conseguir que los Grupos de interés estén involucrados en las pruebas de aceptación final, es pedirles que aporten a la gente que participará en las pruebas. Así, por ejemplo, si la implementación ITS incluye un centro de control desde el que se gestionará la red de carreteras, se tendrán los operadores que eventualmente estarán en el centro para poner a prueba los servicios que se prestan. Si algunas de las interfaces del sistema en el centro de control son para los operadores de transporte público o los servicios de emergencia, se obtiene personal de esas organizaciones para proporcionar las pruebas de los servicios pertinentes. Por ejemplo, si los conductores de vehículos de emergencia puede ser testigo de la operación de "ondas verdes" podrán entender los beneficios que ITS pueden proporcionar.
Una vez que la implementación ITS se ha completado, los componentes del sistema y los enlaces de comunicación tienen que ser operados y mantenidos. Esto permitirá que los servicios se suministren como fueron requeridos por los grupos de Interés y los trabajos de mantenimiento se lleven cabo para asegurar que los servicios puedan continuar. La operación y mantenimiento no sólo sucede - los planes deben ser puestos en su lugar de modo que lo que hay que hacer es comprendido por todos y están disponibles los recursos apropiados para hacerlo. (Ver Mantenimiento de Sistemas)
El breve vídeo sobre el trabajo de la Administración de Transporte de Suecia ofrece algunos puntos útiles para justificar el uso de los ITS, de uno de los ejecutores más importantes de Europa. No es tanto las soluciones técnicas que se destacan como la filosofía y la inclusión de tareas tales como mantenimiento, que se destaca por una buena razón.
Debido a que las implementaciones ITS son diversas, no es posible describir una solución que se ajuste a todas, pero hay problemas comunes que deben tenerse en cuenta de manera para que se puedan encontrar soluciones a las circunstancias individuales. El establecimiento de las áreas de responsabilidad operativa se realiza mejor al considerarlos en 3 secciones: de gestión, geográfica y técnica.
La determinación de la cantidad de gestión que será necesaria para entregar los servicios que la implementación ITS está proporcionando es mejor hacerlo teniendo en cuenta algunos de los siguientes temas:
La necesidad de considerar todos o algunos de estos problemas depende del alcance de los servicios que se suministran, pero los anteriores son ejemplos de algunos de los problemas más comunes que pueden surgir.
La asignación de responsabilidades dentro de la organización de gestión depende de su estructura, que variarán de una implementación ITS a otra pero debe ser acordado antes de su implementación para evitar posibles situaciones embarazosas después. A veces la organización se habrá creado específicamente para la implementación ITS, pero en otras ocasiones las responsabilidades ITS se suman a otras ya existentes.
Algunas implementaciones ITS serán lo suficientemente grande como para cubrir varias áreas geográficas, como los estados o provincias dentro de una nación, regiones dentro de un estado, o distritos de una ciudad. La cuestión es si la gestión de los servicios será centralizada a nivel nacional, estado o ciudad, o distribuida a las unidades geográficas menores, dentro del estado, región o distrito de la ciudad.
Si la responsabilidad de la gestión del servicio se distribuye entonces las relaciones entre estas organizaciones serán importantes y deben tener en cuenta las diferencias locales que pueden tener un impacto en sus operaciones, tales como:
Como temas detallados previamente se acomodan, depende del alcance y contenido de los servicios del ITS y de las estructuras de organización, tanto dentro de cada área geográfica como en el nivel superior (nacional, estatal o de la ciudad). Es importante que puedan ser discutidos los procedimientos/acciones para acordarlos entre todos los que van a participar antes de que se haya completado la implementación ITS
La asignación de responsabilidades técnicas será ligeramente diferente que para los componentes y las comunicaciones del sistema. Si todo funciona correctamente, entonces no importa demasiado. Sólo será importante cuando un componente o un enlace de comunicaciones fallen o funcionen de una manera inesperada. Inevitablemente, esto ocurrirá en algún momento en el ciclo de vida de cualquier implementación ITS y es importante tener en cuenta su impacto de antemano.
La cuestión de quién tiene la responsabilidad técnica de cualquier mala ejecución consiste en determinar quién tiene la "responsabilidad de diseño". Esto se puede hacer mirando donde se define la metodología y/o la tecnología que se utilizará en un enlace de componente o comunicaciones y la asignación de la responsabilidad de quien creó esa definición los ejemplos más comunes son:
Lo mejor es garantizar que la "responsabilidad diseño" recaiga en la organización más adecuado para hacerlo - el que tiene más probabilidades de tener la capacidad de resolver los problemas a medida que vayan surgiendo.
Para los componentes del sistema la responsabilidad diseño debe ser de los proveedores. Por ejemplo, si los terminales del centro de control tienen que dar a los usuarios acceso a las aplicaciones y que también puedan realizar tareas de oficina (por ejemplo, procesadores de texto y contestar correos electrónicos), la especificación de componentes debe establecer estos requisitos y decir que esto debe ser incluido en el diseño de los terminales. La especificación no debe definir el sistema operativo, el procesador, la memoria y otras funciones, ya que esto definiría el diseño de la terminal cambiando la responsabilidad por cualquier problema a los que escribieron la especificación.
Se necesita un enfoque similar para los requisitos de comunicaciones. No deberían decir que una red funcione a una velocidad en particular. En su lugar, debería definir parámetros tales como la cantidad de datos a transmitir, con qué frecuencia, la fiabilidad, duración esperada de la transmisión, qué partes de los enlaces están en los dispositivos móviles, el nivel de seguridad que se requiere y la resistencia necesaria contra accesos no autorizados. Una especificación de este tipo también será mucho más fácil para poner a prueba, ya que estos son parámetros controlables.
Además del alcance y contenido de los servicios prestados por la implementación ITS, la necesidad de relaciones con otras organizaciones dependerá del entorno en el que funcionarán los servicios. El entorno se define por la cobertura geográfica y por el número de organizaciones participantes. (Ver Estrategias de Gestión del Tránsito)
Algunas implementaciones ITS proporcionarán servicios en varias áreas geográficas. Si los servicios en cada área van ser operados y administrados por organizaciones diferentes, entonces, a menos que las áreas están completamente separados (lo que significa que las condiciones del tránsito por carretera en un área no tienen efecto sobre los de otras áreas), es necesario establece relaciones - tales como acuerdos de operación- entre ellos. El alcance de estas relaciones se basará en factores tales como si la necesidad de cooperar es una ocurrencia regular o sólo en circunstancias particulares. (Ver Planificación e Informes)
También es posible que algunos de los servicios que se proporcionan en la misma área geográfica sean operados y administrados por organizaciones diferentes. Por ejemplo, los servicios relacionados con el transporte público y el peaje a menudo serán provistos por sus propias organizaciones. En estos casos tiene que ser definida la forma en que las operaciones van interactuar entre sí y con otros proveedores de servicios, estas definiciones se constituyen como la base para las relaciones. Puede ser necesario el desarrollo de acuerdos de operación detallados entre las diferentes organizaciones. Así, por ejemplo, cómo debe el operador de la red de carreteras responder a las solicitudes de prioridad de vehículo de la organización de transporte público? Otro ejemplo clásico de la necesidad de las relaciones entre las organizaciones es donde la red de carreteras utiliza un puente de elevación para cruzar una vía de agua que está gestionado por una autoridad portuaria - ¿Cómo se gestiona la necesidad de que el puente se abra para los buques y se cierre para los vehículos?
Por último se tendrá que abordar la participación de la Policía y/o de otras fuerzas de seguridad en las operaciones de la red de carreteras. En algunos países, los dos son distintos, mientras que en otros es la fuerza de policía (o algunas veces una parte dedicada de la misma) que opera y gestiona la red de carreteras. Si la operación de la red de carreteras y la Policía son organizaciones separadas, entonces la relación tiene que definir cómo será la cooperación entre ellas. Por ejemplo, pueden los operadores de la red de carreteras informar infracciones de tráfico? o en qué medida pueden algunos de los datos del centro de control de tráfico (por ejemplo, imágenes de CCTV) utilizarce como base para el enjuiciamiento de los delincuentes? (Ver Políticas / Fiscalización)
En los países con muy poca experiencia en la implementación de ITS, podría ser difícil de configurar el "ambiente" para operar y entregar los servicios. El " ambiente" se definirá por las organizaciones que participan y cómo se asignan las responsabilidades entre ellos. En cierta medida, esto depende de la estructura de las organizaciones existentes y las relaciones que tienen entre sí. Puede ser necesaria la creación de una o varias nuevas organizaciones, estructuras y relaciones para la implementación ITS. El punto importante es la creación de una estructura organizativa que evite conflictos no-necesarios entre las organizaciones, garantizando al mismo tiempo una gestión adecuada de sus actividades.
Por ejemplo, en algunas áreas geográficas, es la Policía que proporcionan todo lo que necesita la gestión del tránsito por carretera. La cuestión a resolver es, debe continuar haciendo esto en la implementación ITS? y si no, cuándo y cómo deben interactuar con la organización que será responsable del servicio (s) de gestión del tránsito? No hay un solo mecanismo universalmente aplicable para resolver este problema, pero todo lo que se implemente, se debe registrar para que una vez aceptado no se tengan más dudas sobre el papel de cada organización, saber claramente quién es responsable de qué, cuándo y dónde.
El camino probable para lograr lo que se ha descrito anteriormente, es comprar en la experiencia externa ya sea directamente o a través de consultores. Si se sigue esta ruta será ventajoso visitar las implementaciones ITS en que han trabajado para analizar cómo funcionan las relaciones de organización. También vale la pena recordar que a veces lo que funciona para un país o cultura no va a funcionar para otro.
El nivel de la nómina es el número de personas necesarias para operar y administrar la implementación ITS, de manera que se puedan prestar los servicios. Tiene que ser calculado de dos maneras:
Cómo se calculan estos dos totales dependerá de una combinación de los nueve factores siguientes:
No todos estos factores serán pertinentes para cada implementación ITS - pero los que sí lo son, determinarán los requisitos máximos de personal necesarios.
El alcance y contenido de los servicios prestados por la implementación ITS determinarán las habilidades que el personal requiere poseer con el fin de operar y gestionarlo. También el nivel de responsabilidad que se asigna a cada miembro del personal será otro factor que determina el nivel de habilidad. El miembro ideal de personal tendrá que reunir los siguientes requisitos:
Si la organización que lleva a cabo la implementación de ITS decide llevar a cabo las actividades de mantenimiento, se necesitará un nuevo conjunto de habilidades. Estas serán más técnicas y pueden cubrir cosas tales como la sustitución de componentes, reparación de componentes y mantenimiento de software. Los candidatos a estos puestos o bien necesitan haber tenido una formación especializada, o deberán realizarla cuando empiezan a trabajar. Dicha formación estará casi siempre disponible con los proveedores de componentes de hardware y software, pero en el caso del software también puede estar disponible en otras organizaciones.
El mantenimiento de las redes de comunicaciones es a menudo proporcionado por el proveedor (s) red de comunicaciones. En ocasiones será necesario el acceso a sus locales y/o equipos, algunos de los cuales pueden ser utilizados por otros clientes de la red. A menudo es útil contar con personal capaz de diagnosticar problemas de comunicación, para poder contactar al proveedor de red correcta y dar alguna información vital acerca de la posible naturaleza del problema.
Conseguir que las personas con los conocimientos adecuados en ITS como se describe anteriormente puede ser difícil. Puede haber varias opciones para resolver este problema, pero dos de los más evidentes son:
De los dos, el primero es la solución a corto plazo y puede ser inicialmente más económico. A más largo plazo, la formación de personal local es la respuesta, incluso si es más caro al principio. Hay muchas organizaciones que ofrecen una formación adecuada, ya veces puede ser incluida en los contratos de los proveedores y / o integradores de sistemas. Muchos de ellos le proporcionará la formación, ya sea en sus propias instalaciones, o en el lugar donde se esté implementando el ITS. La adquisición de experiencia en comunicaciones es mejor dejar como un problema a resolver por los proveedores de comunicaciones.
Las organizaciones que operan y administran los sistemas y servicios ITS. Pueden decidir hacer todo el mantenimiento del sistema, o subcontratar a otras organizaciones. La creciente complejidad de las implementaciones ITS y los servicios que prestan tiende a promover la idea de utilizar subcontratistas.
Los avances en las tecnologías que se encuentran en los componentes del sistema y las redes de comunicación utilizados en las implementaciones ITS, han reducido la necesidad de un mantenimiento regular. Los días de actividades de mantenimiento periódicas frecuentes de hardware y equipos van siendo rápidamente reemplazados por un espíritu que se explica por la expresión, "si no está roto, no lo arregles".
Los equipos de carretera modernos normalmente sólo necesitar un reemplazo ocasional de fuentes de luz y sensores. Incluso esto está disminuyendo con el uso de fuentes de luz que operan a bajos voltajes. En otros aspectos, la tendencia es que las actividades de mantenimiento sólo sean necesarias tras los efectos de condiciones climáticas extremas, como inundaciones de temperatura extremas y/o vientos fuertes. Hay algunas excepciones a esta tendencia, como las barreras mecánicas a estacionamientos o puentes, y los equipos de túneles que necesitarán controles de seguridad adicionales que deberán llevarse a cabo sobre una base regular.
Los centro de control y los equipos de comunicaciones está siguiendo la tendencia hacia las actividades de mantenimiento muy bajas o virtualmente ninguna. Cuando algo sale mal la tendencia es sustituir en lugar de reparar.
La única excepción al "si no está roto, no lo arregles" es el software, que a menudo se actualiza periódicamente, ya sea porque se han encontrado problemas o para incluir nuevas mejoras. Esto es particularmente importante para los componentes que se van a conectar a Internet, ya que deben ser protegidos por cortafuegos y software sofisticados para evitar el acceso no autorizado. Siempre que se hagan cambios en el software, debe ser empleado personal de la Gestión de la Configuración (CM) para asegurar que los cambios se gestionan y que es posible volver a la versión sin cambios si surgen problemas.
A excepción de las grandes organizaciones que a menudo gestionan implementaciones ITS en las ciudades ya lo largo de estados, provincias o naciones, es habitual emplear subcontratistas para llevar a cabo las actividades de mantenimiento. Estos subcontratistas pueden ser organizaciones especializadas en mantenimiento, o los proveedores de componentes, en particular para los componentes de carretera.
Cualquiera sea la forma de subcontratista se utiliza, el alcance y el contenido de sus actividades deben estar definidas en un contrato, a veces llamado un Acuerdo de Nivel de Servicio (SLA). El SLA debe definir que debe ser mantenido, las horas y los días que el subcontratista deberá asistir a una falla reportada, el tiempo de respuesta para una falla reportada, el tiempo que una reparación puede tomar, en qué momento se debe reemplazar un componente, almacenamiento de repuestos, además de la competencia y la disponibilidad del personal de la subcontratista. También se debe incluir una estructura de costos ya sea a un precio fijo para cada actividad, o fijar un precio global para todas las actividades de mantenimiento. El SLA por lo general por un período fijo de tiempo (2-5 años) y tendrá que ser renovado cuando ha transcurrido el mismo, a menudo a través de un proceso de licitación.
Las posibles excepciones a la utilización de subcontratistas para actividades de mantenimiento son grandes ciudades, u otras áreas geográficas para las cuales la escala de la implementación ITS es grande, sobre todo en términos de la cantidad de hardware utilizado. En estos casos, la cantidad de trabajos de mantenimiento necesarios hará que la contratación y formación de personal de mantenimiento de hardware especializado, un stock de repuestos y un taller de reparación, sea un beneficio para la organización y funcionamiento de la gestión de la implementación ITS. A veces las organizaciones en las zonas adyacentes pueden combinar sus actividades de mantenimiento de beneficiarse de no usar subcontratistas.
El mantenimiento del software es usualmente diferente porque incluso en un gran implementación ITS no es la misma cantidad de tareas que hay para el hardware, y la comprensión, modificación y sustitución es más compleja. Por ejemplo, el software para un sistema de control de tráfico urbano típico puede tener entre 250.000 y 500.000 líneas de código, que un ingeniero de software tendrá varios meses para comprender plenamente antes de poder hacer cualquier cambio. Por lo tanto, es mejor conseguir el proveedor (s) de software para mantener lo que han suministrado.
Es probable que en la mayoría de los países se necesite suministrar el mantenimiento de hardware y enlaces de comunicación, ya que el mantenimiento del software es casi siempre mejor dejarlo a sus proveedores.
Una forma para que un país en desarrollo pueda proceder, es realizar el mantenimiento a través de los proveedores de componentes y proveedores de comunicaciones. Muy a menudo, el período de mantenimiento se puede incluir como parte de sus contratos de suministro. Todas las salvedades sobre diversos factores tales como Acuerdo de Nivel de Servicio (SLA), mencionado anteriormente, necesitan ser incluidos. Los artículos tales como equipos de mantenimiento y piezas de repuesto deben ser almacenados localmente. Como se proporcionan las piezas de repuesto es algo que tiene que ser negociado como parte del contrato (s) de mantenimiento. Si los proveedores de servicios tienen la responsabilidad de asegurar suficientes piezas de repuesto para que esten disponibles, a veces puede ser una cuestión de equilibrio económico para una posible reducción en el costo de mantenimiento en contra de la libertad de cambiar de contratistas al final del período de mantenimiento.
Otros factores a tener en cuenta cuando se negocian contratos de mantenimiento es incluir que presencia local del contratista (s) de mantenimiento se tendrá, y en qué medida el contratista (s) dará empleo a la población local. Este último puede ser muy importante. Para el futuro a largo plazo de la implementación ITS será ventajoso si los empleados locales adquieren la formación en las habilidades técnicas necesarias para llevar a cabo las actividades de mantenimiento.