PISTA

TRAK es un marco de arquitectura empresarial general dirigido a ingenieros de sistemas. Se basa en MODAF 1.2.

TRAK fue encargado originalmente por London Underground Limited. ^{[1] [2]} El desarrollo comenzó en 2009 y se basó en las visiones vigentes en ese momento de la descripción arquitectónica dentro del metro de Londres, que se basaban en la norma ISO/IEC 42010 y estaban vinculadas al ciclo de vida de la ingeniería de sistemas definido en la norma ISO/IEC 15288 .

Aunque la intención original era desarrollar un marco de arquitectura específico para ferrocarriles, al adaptar MODAF para satisfacer las necesidades locales se eliminó todo contenido específico de dominio o de defensa. El resultado fue un metamodelo sin dominio con puntos de vista que solo se basaban en la representación de sistemas complejos .

TRAK se lanzó bajo licencias de código abierto en febrero de 2010.

Ha sido adoptado formalmente por el Departamento de Transporte del Reino Unido, que preside el Grupo Directivo de TRAK, que gestiona la dirección general, la estrategia y los lanzamientos formales de TRAK.

El equipo de desarrollo de TRAK recibió un premio del Grupo de Trabajo. ^[3] (foto en la página del Grupo de Trabajo de Transporte de INCOSE ^[4] ). TRAK fue finalista de los Premios a la Innovación IET 2011. ^[5]

Elemento de descripción de la arquitectura

Un objeto de descripción de arquitectura individual que se utiliza para describir o representar un elemento de arquitectura del mundo real. Un elemento de descripción de arquitectura puede aparecer en una descripción de arquitectura. ^[6] Solo los elementos de descripción de arquitectura se utilizan para formar vistas de arquitectura de TRAK. Un elemento de descripción de arquitectura puede ser un elemento de nodo o un elemento conector. Un elemento conector y dos elementos de nodo se utilizan para formar una tupla de descripción de arquitectura.

Descripción de la arquitectura Tupla

Un elemento de descripción de arquitectura con nombre conectado por una relación con nombre a un elemento de descripción de arquitectura con nombre, es decir, sujeto - predicado objeto - la base de una oración. ^[6] p. ej., la Organización A 'tiene parte' del Trabajo B. Sigue la construcción de lenguaje natural de Sujeto - Predicado - Objeto - también utilizado en RDF . Véase Tupla . TRAK requiere que cada tupla sea explícita. Las Tuplas de Descripción de Arquitectura están definidas por el Metamodelo TRAK. Hay al menos 750 Triples de Descripción de Arquitectura o aserciones proporcionadas por el metamodelo TRAK. ^[7]

Vista de la arquitectura maestra

Cada nodo del metamodelo TRAK tiene una vista de arquitectura maestra. Dentro de una descripción o modelo de arquitectura, cada elemento (individual) debe declararse o mostrarse en su vista de arquitectura maestra antes de que pueda usarse en cualquier otra vista de arquitectura. Por ejemplo, antes de describir funciones utilizando, por ejemplo, "El sistema realiza una función" en una vista de función de solución SV-04, el elemento del sistema se crearía primero y se presentaría en una vista de estructura de solución TRAK SV-01.

Perspectiva

La norma ISO/IEC 42010 :2007 se refiere a una perspectiva arquitectónica como 'Compartir modelos arquitectónicos también facilita un estilo "orientado a aspectos" de descripción arquitectónica' ^[8] Una agrupación de vistas arquitectónicas relacionadas y superpuestas. ^[6]

(Arquitectura) Vista

La norma ISO/IEC 42010 hace referencia a una vista de arquitectura como "un producto de trabajo que expresa la arquitectura de un sistema desde la perspectiva de las preocupaciones específicas del sistema". Una vista TRAK se define como un producto de arquitectura en el metamodelo TRAK. Una vista TRAK presenta un conjunto de tuplas de descripción de arquitectura de acuerdo con su punto de vista rector.

(Arquitectura) Punto de vista

ISO/IEC 42010 :2007 - Un punto de vista define un conjunto de convenciones (notaciones, lenguajes y tipos de modelos) para construir un determinado tipo de vista. ^[6] En TRAK, un punto de vista es una especificación para una única vista de TRAK. Cada punto de vista de TRAK define tanto el contenido permitido como el contenido de vista mínimo aceptable como conjuntos de tuplas de descripción de arquitectura.

TRAK se define de forma lógica, es decir, libre de cualquier noción de cómo se implementa TRAK en cualquier herramienta o lenguaje de descripción de arquitectura.

TRAK tiene 24 puntos de vista de arquitectura que se agrupan en 5 perspectivas. Cada punto de vista pertenece a una única perspectiva y especifica una única vista (tipo). Cada punto de vista especifica qué conjuntos de tipos de elementos de descripción arquitectónica y relaciones (tuplas) pueden aparecer. Los tipos de elementos de descripción arquitectónica y las relaciones se especifican mediante el metamodelo TRAK.

La definición lógica de TRAK consta de 3 documentos, cada uno de los cuales es un proyecto de código abierto en SourceForge :

• Documento del marco de arquitectura empresarial de TRAK. ^[9] Este documento controla TRAK en su totalidad. Define las perspectivas de arquitectura de TRAK, los colores, los estatutos (reglas que afectan el diseño de TRAK), las vistas y descripciones de la arquitectura y el proceso de modelado mínimo.
• Documento de puntos de vista del marco de arquitectura empresarial TRAK. ^[10] Aquí se definen los puntos de vista de la arquitectura TRAK.
• Documento de metamodelo del marco de arquitectura empresarial TRAK. ^[6] Define los elementos de descripción de la arquitectura que pueden aparecer en una definición de punto de vista.

TRAK tiene cinco perspectivas de arquitectura, ^[9] cada una de las cuales agrupa puntos de vista de la arquitectura y puntos de vista de un área temática superpuesta:

• Perspectiva empresarial
• Perspectiva conceptual
• Perspectiva de adquisiciones
• Perspectiva de la solución
• Perspectiva de la gerencia

Esta perspectiva abarca las capacidades duraderas que se necesitan como parte de la empresa en su conjunto. Se trata de necesidades de alto nivel a las que todo lo demás contribuye y que forman parte de los objetivos estratégicos a largo plazo que deben gestionarse.

La perspectiva conceptual abarca la visión lógica de lo que se necesita en respuesta a las capacidades requeridas por la empresa en la perspectiva empresarial. Abarca la conexión lógica de nodos, por ejemplo un centro de control de servicios, con otros nodos sin reconocer cómo esto podría realizarse ya sea por la organización o la tecnología. Tampoco implica ninguna parte particular de un ciclo de vida: abarca todo desde el concepto hasta la eliminación ("¡de la codicia al polvo"!).

La perspectiva de adquisiciones ofrece una visión de alto nivel de la solución a las necesidades de capacidad de la empresa descritas en la perspectiva de la empresa y desarrolladas en la perspectiva del concepto. Proporciona una manera de mostrar cómo los proyectos ofrecen las soluciones descritas en la perspectiva de la solución para proporcionar capacidad. Proporciona una manera de mostrar la dependencia temporal entre proyectos y es esencial para investigar las brechas de capacidad.

La perspectiva de la solución ofrece puntos de vista sobre la solución, ya sea propuesta o realizada. Abarca las partes de los "sistemas", ya sean humanos o mecánicos, sus intercambios y protocolos. La perspectiva de la solución describe cómo se organizan y gobiernan las organizaciones y los equipos. La perspectiva de la solución describe cómo se materializan los requisitos lógicos delineados en la perspectiva del concepto y muestra cómo las soluciones materializan la capacidad que necesita la empresa y que se describe en la perspectiva empresarial.

La perspectiva de gestión ofrece puntos de vista que describen la tarea arquitectónica y las relaciones que son comunes a otras perspectivas. Ofrece formas de definir el alcance y los hallazgos de la tarea arquitectónica, estructurando el enfoque y el modelado.

La perspectiva de gestión ofrece formas de describir los estándares normativos que se aplican. Contiene puntos de vista que brindan información complementaria para facilitar la portabilidad y la comprensión de los modelos.

Cada vista de arquitectura en TRAK se especifica mediante un punto de vista de arquitectura correspondiente . El punto de vista se designa utilizando una "p" en la numeración, por ejemplo, CVp-01 es el punto de vista de arquitectura que especifica una vista de arquitectura CV-01.

En general, si existe riesgo de confusión con una vista numerada de manera similar en otro marco, como DODAF o MODAF, se utiliza un prefijo de espacio de nombres, por ejemplo, TRAK::SV-01.

TRAK define 24 puntos de vista de arquitectura ^[10] (en comparación, DODAF 2.0 tiene 52 vistas/modelos, MODAF 1.2.004 tiene 47 vistas y NAF 3.1 tiene 49 subvistas ^[11] )

• Perspectiva empresarial
  • Objetivos empresariales EVp-01
  • Jerarquía de capacidades EVp-02
  • Fase de capacidad EVp-03
• Perspectiva conceptual
  • CVp-01 Necesidad de concepto
  • CVp-03 Intercambio de elementos conceptuales
  • CVp-04 Actividad conceptual para mapeo de capacidades
  • Actividad conceptual CVp-05
  • Secuencia conceptual CVp-06
• Perspectiva de adquisiciones
  • PrVp-01 Estructura de Adquisiciones
  • Cronograma de adquisiciones PrVp-02
  • PrVp-03 Responsabilidad de adquisiciones
• Perspectiva de la solución
  • Estructura de la solución SVp-01
  • Solución SVp-02 Interacción de recursos
  • Solución SVp-03 Interacción de recursos con mapeo de funciones
  • Función de solución SVp-04
  • SVp-05 Solución Función a Concepto Actividad Mapeada
  • SVp-06 Competencia en soluciones
  • Secuencia de solución SVp-07
  • Causas del evento de solución SVp-11
  • Solución de riesgo SVP-13
• Perspectiva de la gerencia
  • Diccionario de descripción de arquitectura MVp-01
  • MVp-02 Registro de diseño de descripción de arquitectura
  • Requisitos y estándares del MVp-03
  • MVp-04 Aseguramiento

Estos se definen en la especificación de puntos de vista de TRAK. Se proporciona información adicional en una wiki de la comunidad. ^[12]

El metamodelo TRAK ^[6] simplifica y amplía los conceptos básicos del metamodelo MODAF 1.2. Ha eliminado y redefinido los estereotipos y ha eliminado todos los constructos específicos de defensa. La especificación del metamodelo TRAK contiene una comparación del metamodelo TRAK en su versión inicial con MODAF 1.2.003. Esto también se describe por separado. ^[13]

El metamodelo TRAK se muestra a continuación. Tenga en cuenta que no se trata de una copia controlada .

Hay una descripción ontológica de los elementos del metamodelo TRAK usando RDF en ^[14] . Esto también se presenta como HTML. ^[15]

Los cambios significativos frente al MODAF incluyen:

• El metamodelo TRAK está dirigido a los usuarios (el MODAF M3 es un perfil UML abstracto pensado como especificación para que los proveedores de herramientas implementen MODAF; no existe un metamodelo para los usuarios, solo fragmentos de un "metamodelo simplificado" que apuntan a representar el M3 más complicado). En TRAK, el metamodelo que se muestra es el maestro.
• El sistema es fundamental para TRAK y puede representar sistemas duros y sistemas blandos (en MODAF 1.2.003, el sistema es un artefacto ^[16] y parte de la arquitectura física y no puede incluir partes no físicas ^[17] ).
• TRAK puede representar cualquier tipo de intercambio/flujo de interfaz: información, energía o recursos.
• TRAK puede representar características de intercambio asociadas a los recursos humanos: organizaciones, trabajos y roles
• TRAK incluye medios para representar requisitos a través de los elementos del metamodelo Estándar (documento/colección) y Requisito (atómico) y aplicados por Contrato.
• TRAK incluye los medios para planificar y describir la tarea de arquitectura y la descripción de la arquitectura y su organización como una vista (MV-02 Registro de diseño de descripción de arquitectura)
• Se pueden representar otros tipos de dependencia y asociaciones: físicas, de membresía, de grado de responsabilidad.
• TRAK incluye los medios para describir casos de garantía (incluida la verificación del diseño) utilizando el constructo Reclamo-Argumento-Evidencia
• TRAK incluye los medios para describir la seguridad: amenazas/peligros, vulnerabilidades, mitigaciones y riesgos y causas/impactos.
• Adición de conceptos ISO/IEC 42010 para representar la tarea arquitectónica, la descripción de la arquitectura y las vistas de la arquitectura, para permitir una descripción del alcance de la tarea, el propósito y los hallazgos.
• Adición de reglas de coherencia para el contenido que se aplican a toda la colección de vistas y el contexto para mejorar la navegación y la visibilidad del contenido.
• reglas que limitan cómo y en qué orden se pueden establecer relaciones para mejorar la consistencia del conjunto de vistas que forman la descripción de la arquitectura

Estructuralmente hay otros cambios:

• TRAK tiene 24 puntos de vista (frente a los 47 puntos de vista de MODAF)
• el contenido de cada punto de vista se define en términos de tuplas (una construcción de elemento nodo-relación-nodo, es decir, un triple o una tupla 1 ) y tiene reglas de contenido y correspondencia mínimas aceptables permitidas con respecto a otras vistas dentro de la descripción de la arquitectura porque esto es necesario para especificar una ruta direccionable de forma única en un metamodelo (especificar un elemento de metamodelo de bloque no es suficiente por sí solo cuando hay varias relaciones que involucran al elemento).
• Dado que ISO/IEC/IEEE 42010:2011 define la arquitectura en términos de la relación de un sistema con su entorno, la unidad más pequeña de descripción de la arquitectura que puede aparecer en una vista de arquitectura de TRAK es la tupla de descripción de la arquitectura, es decir, nodo - relación - nodo.

La forma en que TRAK se gestiona y se publica a través de un conjunto de proyectos de código abierto también es bastante diferente de otros marcos de arquitectura empresarial. Todas las solicitudes de cambio y las solicitudes de características y su sentencia son completamente visibles para cualquier persona, no restringidas a quienes especifican o desarrollan el marco. ^{[18] [19] [20]} Las versiones están bajo control de cambios y todo el historial se mantiene mediante un software de control de versiones ( Subversion (SVN) ).

TRAK no especifica una notación o lenguaje de presentación ( lenguaje de descripción de arquitectura en la terminología ISO/IEC 42010) en el que presentar las vistas de arquitectura. Por lo tanto, las descripciones de arquitectura de TRAK no son modelos UML , SysML o BPMN, aunque cualquiera de estas notaciones se puede utilizar para preparar al menos algunas de las vistas (un ADL podría no contener los conceptos/estereotipos necesarios o podría no permitir que se los conecte de la manera necesaria para representar una vista de arquitectura de TRAK).

TRAK requiere que el nombre del elemento del metamodelo de cada elemento de descripción de la arquitectura en una vista de arquitectura de TRAK se muestre explícitamente para que cada vista de TRAK pueda leerse como un conjunto de declaraciones, por ejemplo

• ' El sistema A está configurado con el software B
• ' Reclamación . El sistema A cumple con el requisito de... -acerca de-> Norma . Especificación ambiental climática.'
• ' Físico . Construcción de escudos -tiene-> Vulnerabilidad . Debilidad estructural <-explota- Amenaza . Impacto deliberado de aeronaves'

Las tuplas se pueden presentar utilizando nodos y relaciones con direcciones (un gráfico dirigido ).

TRAK también permite construir una vista a partir de declaraciones textuales. Dado que una vista TRAK es un conjunto de tuplas/triples, es posible utilizar un gráfico o un conjunto de triples RDF para presentar una vista TRAK. Se está desarrollando una descripción de ontología RDF de los elementos del metamodelo TRAK. ^[21] Esto toma las definiciones de los elementos de la salida de especificación del metamodelo TRAK de un modelo gráfico de TRAK dentro de una base de datos gráfica Neo4J . ^[7] Una vista de arquitectura TRAK que consta de triples RDF se puede vincular a la ontología del metamodelo TRAK RDF para formar un gráfico de conocimiento . Cada triple representa un hecho o una afirmación.

TRAK también requiere que cada bloque y cada conector tengan un nombre y que estos sean visibles (explícitos). La intención de esto es asegurar que una vista de arquitectura TRAK se lea como el autor de la vista lo quiso decir y mejorar la coherencia semántica. Las reglas de presentación que se aplican a todas las vistas de arquitectura TRAK se especifican en la especificación general de TRAK ^{[9] [22]} (como 'Reglas').

TRAK es una definición lógica: especifica lo que se debe mostrar y el contenido mínimo aceptable, pero no obliga a lograrlo. TRAK simplemente define los elementos de nodo y conector y las combinaciones permitidas (triples) que deben/pueden aparecer en cada vista. No especifica ni obliga a ninguna notación o lenguaje en particular. Por ejemplo, un diagrama de bloques y conectores simple (como el anterior) es aceptable, al igual que un conjunto de declaraciones de texto sin formato, un diagrama que utiliza UML , un gráfico o un conjunto de triples RDF. Por la misma razón, el contenido de la vista TRAK se especifica utilizando una notación abstracta y diferente de cualquier notación que pueda usarse para implementar una vista de arquitectura TRAK para evitar un error común que surja de un error en una sola notación que afecte tanto a la definición del contenido del punto de vista TRAK como a la "respuesta de diseño": el contenido de una vista TRAK en particular.

TRAK aplica la norma ISO/IEC 42010 de las siguientes maneras:

• Una descripción de la arquitectura es una respuesta a una tarea que aborda las inquietudes de una parte interesada (esto se aborda utilizando el punto de vista del registro de diseño de descripción de la arquitectura TRAK::MVp-02 con el que se puede generar una vista para definir la tarea, las inquietudes abordadas y los hallazgos)
• Cada vista de la arquitectura TRAK se especifica mediante un punto de vista dentro del marco de la arquitectura TRAK. Por ejemplo, el punto de vista de garantía MVp-04 especifica el contenido de cualquier vista de garantía MV-04.
• Cada punto de vista de TRAK identifica las partes interesadas, las preocupaciones abordadas, las anti-preocupaciones (cosas para las que no se debe usar el punto de vista), las tuplas de metamodelo necesarias, las tuplas de metamodelo permitidas, la buena formación (contenido mínimo aceptable) y las reglas de consistencia con otras vistas dentro de la descripción de la arquitectura, por ejemplo, en una Vista de Garantía MV-04 antes de que se pueda afirmar "La evidencia prueba la afirmación", debe existir "La evidencia respalda el argumento respalda la (misma) afirmación".
• Las reglas de correspondencia se definen por puntos de vista y para una descripción de la arquitectura utilizando el metamodelo TRAK. Las reglas se definen utilizando triples del metamodelo TRAK.

En el documento TRAK Enterprise Architecture Framework se realiza una comparación general entre TRAK e ISO/IEC 42010. Se realiza una comparación más detallada con la versión 2011 de la norma por separado ^[23] y se puede ver como un conjunto de páginas web ^[24] . Estas, junto con una matriz de cumplimiento ^[25] , comparan:

1. TRAK como marco de arquitectura frente a los requisitos de la sección 6.1 (Marcos de arquitectura) de ISO/IEC/IEEE 42010:2011 y;
2. una descripción de arquitectura conforme a TRAK según la sección 5 (Descripciones de arquitectura) de ISO/IEC/IEEE 42010:2011.

TRAK en sí no exige un proceso. Sin embargo, se introduce un elemento de proceso porque TRAK se adhiere a la norma ISO/IEC 42010, que establece que se produce una descripción de la arquitectura en respuesta a una tarea y a las preocupaciones de las partes interesadas en la tarea, y también porque TRAK tiene vistas de arquitectura maestras que crean dependencias entre vistas y dan como resultado conjuntos de vistas de arquitectura mínimos permitidos.

Esto da lugar a un proceso mínimo que es:

• Identificar a las partes interesadas en la tarea y sus preocupaciones
• Utilizando los puntos de vista de TRAK, seleccione los puntos de vista necesarios para abordar las preocupaciones de las partes interesadas.
• Desarrollar puntos de vista que se ajusten a estos puntos de vista que aborden estas preocupaciones.
• Estos a su vez pueden requerir que se preparen vistas adicionales para formar un conjunto de vistas permitidas legítimas.
• Documentar el propósito, las preocupaciones, los hallazgos y la descripción de la arquitectura utilizando una Vista de registro de diseño de arquitectura MV-02 complementada con una Vista de diccionario de arquitectura MV-01

TRAK se publica bajo dos formas de licencia de código abierto:

• Licencia de Documentación Libre de GNU ( GFDL ) para la definición lógica de TRAK en general, el metamodelo de TRAK y los documentos de puntos de vista de TRAK
• Licencia Pública General de GNU ( GPL ) para implementaciones de TRAK - Perfil UML para TRAK para herramientas de modelado UML general y TRAK MDG Technology para la herramienta de modelado Sparx Systems Enterprise Architect .

TRAK admite herramientas de modelado a través de los siguientes mecanismos:

• un perfil UML y un perfil SysML para TRAK: para usar con cualquier herramienta de modelado UML que pueda importar un perfil UML
• Un complemento para Sparx Systems Enterprise Architect basado en los perfiles UML y SysML para TRAK. Publicado como código abierto en Sourceforge ^[26]
• Una plantilla para la plataforma de software MooD 2010 de MooD International (desarrollada por Vega Consulting Services Ltd, parte de Leonardo ). Publicada como código abierto en Sourceforge. ^[27]
• una plantilla para OmniGraffle ( Mac OS X , iPad ). Publicada como código abierto en Sourceforge. ^[28]
• Una plantilla para Microsoft Visio . Publicada como código abierto en Sourceforge. ^[29]

Una comparación del estereotipo (conceptos) en el UML con aquellos en el Metamodelo TRAK ^[30] proporciona un análisis, para el Perfil UML para TRAK, lo que los Puntos de Vista TRAK y, por lo tanto, las Vistas TRAK UML son capaces de representar de forma completa, parcial o en absoluto. Esto es una consecuencia de los constructos disponibles en UML y la implementación particular en el Perfil UML para TRAK y surge porque los diferentes lenguajes de descripción de arquitectura ( ADL ) a menudo se diseñan para diferentes propósitos y, a veces, para diferentes dominios; es decir, en ISO/IEC 42010 las preocupaciones que abordan son diferentes de las que aborda el marco de arquitectura, en este caso TRAK.

Como las herramientas representan una implementación de la definición lógica de TRAK, pueden contener limitaciones o errores debido al lenguaje de notación (lenguaje de descripción de la arquitectura) utilizado y las capacidades específicas de la herramienta.

• Programa de modernización del subsuelo (SSUP). Modernización de la señalización y el material rodante de las líneas Circle, Hammersmith, Metropolitan y District del metro de Londres. Citado en Rail Value for Money Study. Whole System Programme Management Report. 25 de mayo de 2011. ^[2]
• Grupo de liderazgo de estrategia técnica (TSLG). Arquitectura funcional ferroviaria ^[31]
• Rail Safety & Standards Board (RSSB). Arquitectura funcional ferroviaria del Reino Unido. Investigación en curso - Boletín electrónico de investigación y desarrollo de RSSB. Número 66. Octubre de 2010. ^[32] La justificación de la selección/uso de TRAK se proporciona en el informe resumido de la tarea. ^[33] El proyecto de arquitectura funcional ferroviaria T912 se describe por separado. ^[34] La arquitectura funcional ferroviaria se pone a disposición como un conjunto de páginas HTML. ^[35]
• Universidad de Birmingham. InfraGuidER (Infrastructure Guidelines for Environmental Railway Performance), entregables 9 y 18, ^[36] minutos: D22: 2º taller para los polos de excelencia de EURNEX (European Rail Research Network of Excellence) ^[37]
• EA integrada 2011. Gestión de riesgos y costes con un enfoque de EA. Mike Brownsword (Atego) y Joe Silmon (Centro de investigación y educación ferroviaria)., ^[38]
• Descripción de la arquitectura ^[24] que describe las afirmaciones de cumplimiento de TRAK como marco de arquitectura y una descripción de la arquitectura conforme a TRAK con respecto a los requisitos de ISO/IEC/IEEE 42010:2011. Incluye ejemplos de las siguientes vistas: MV-02 Registro de diseño de descripción de arquitectura, MV-03 Requisitos y estándares y MV-04 Garantía. El modelo subyacente se utilizó luego para producir la matriz de cumplimiento ^[25] como un ejemplo de ingeniería de sistemas basada en modelos .

• Sitio del proyecto TRAK Enterprise Architecture Framework
• Marco de arquitectura empresarial TRAK. Sitio del proyecto Metamodel
• Marco de arquitectura empresarial TRAK. Sitio del proyecto Viewpoints
• Perfil UML para TRAK
• TRAK MDG para el sitio del proyecto Enterprise Architect de Sparx Systems
• Plantilla OmniGraffle para el sitio del proyecto TRAK
• Plantilla Visio para el sitio del proyecto TRAK
• Sitio de soporte de la comunidad TRAK