## 4. Estructura XML Detallada para Topología de Red en Exportaciones AML de TIA Portal Basándose en los estándares AML/CAEX y la información disponible sobre las exportaciones de TIA Portal, se puede inferir la estructura XML probable utilizada para representar la topología de red. ### 4.1. Mapeo de Conceptos de TIA Portal a Elementos CAEX - **Estructura del Proyecto (Carpetas):** Se representan mediante elementos `InternalElement` anidados dentro de la `InstanceHierarchy` raíz, reflejando la estructura del árbol del proyecto en TIA Portal. Estos IEs "carpeta" podrían tener un `RefBaseRoleClassPath` o `RefBaseSystemUnitPath` que indique su naturaleza organizativa. - **Redes/Subredes (Ej. Profinet_1):** Probablemente representadas como instancias `InternalElement` de nivel superior dentro de la `InstanceHierarchy`, o anidadas directamente bajo la raíz. Estos IEs de red harían referencia a una `SystemUnitClass` o `RoleClass` que indique el tipo de red (por ejemplo, algo como "ProfinetSystem", "ProfibusMasterSystem", posiblemente de bibliotecas Siemens) a través de `RefBaseSystemUnitPath` o `RefBaseRoleClassPath`. - **Dispositivos/Nodos (PLCs, Dispositivos IO, Switches):** Representados como instancias `InternalElement` anidadas _dentro_ de su respectivo `InternalElement` de red/subred (o quizás bajo una carpeta de dispositivos). Cada IE de dispositivo tendrá atributos `Name` (el nombre en TIA Portal) y `ID` (un identificador único global, GUID).1 - Referenciarán su tipo de hardware específico a través de `RefBaseSystemUnitPath`, apuntando a una `SystemUnitClass` (por ejemplo, `PLCSystemUnitClassLib/Siemens S7-1200`, o más probablemente, a una clase dentro de bibliotecas específicas de Siemens cargadas en el archivo AML). - Podrían referenciar un rol funcional a través de `RefBaseRoleClassPath` (ej. `AutomationMLBaseRoleClassLib/ControllerDevice`, `AutomationMLBaseRoleClassLib/IODevice`, `NetworkComponentsRoleClassLib/Switch`). - Propiedades específicas de Siemens, como el número de pedido ("PLC type designation"), probablemente se almacenen como elementos `Attribute` dentro del IE del dispositivo.3 - **Interfaces/Puertos de Dispositivo (Puertos Ethernet, Conectores Profibus):** Representados como elementos `ExternalInterface` anidados dentro de su `InternalElement` padre (el dispositivo). Cada EI tendrá atributos `Name` (ej. "X1", "PROFINET interface_1", "P1 R" 3) y `ID` (GUID único).1 - Referenciarán su tipo de interfaz a través de `RefBaseClassPath`, apuntando a una `InterfaceClass` (ej. `CommunicationInterfaceClassLib/CommunicationPhysicalSocket`). - Los parámetros de red (IP, MAC, etc.) se almacenan como elementos `Attribute` anidados dentro del `ExternalInterface`.1 - **Conexiones (Cables):** Representadas por elementos `InternalLink`, típicamente definidos como hijos del `InternalElement` que representa la red o subred, o potencialmente a un nivel superior dentro de la `InstanceHierarchy`.1 - Cada `InternalLink` conecta dos elementos `ExternalInterface` utilizando los atributos `RefPartnerSideA` y `RefPartnerSideB`, que contienen los `ID`s de las EIs conectadas, definiendo así explícitamente el enlace físico o lógico. La combinación de `InternalElement` anidados, `ExternalInterface`, `Attribute` y `InternalLink` proporciona una estructura bien definida y analizable para representar la topología de la red dentro del marco AML/CAEX, apoyando directamente la generación de un árbol de nodos.1 ### 4.2. Ejemplo de Estructura Jerárquica (Conceptual) A continuación se muestra un fragmento XML conceptual que ilustra la estructura probable: XML ``` 6ES7... 192.168.0.1 00-1C-06-... 255.255.255.0 plc_1 6ES7... 192.168.0.10 08-00-06-... 255.255.255.0 io_device_1 ``` ### 4.3. Representación de Tipos de Red (Profinet/Profibus) La distinción entre diferentes tipos de redes (Profinet, Profibus, ASi, etc.) se realiza probablemente a través de la referencia a clases específicas en las bibliotecas: - El `InternalElement` que representa la red o subred utilizará un `RefBaseRoleClassPath` o `RefBaseSystemUnitPath` que identifique semánticamente el tipo de red (por ejemplo, conteniendo "Profinet", "ProfibusDP" en la ruta). - Los dispositivos (`InternalElement`) y sus interfaces (`ExternalInterface`) dentro de esa red contendrán `Attribute`s específicos para ese protocolo. Por ejemplo, un dispositivo en una red Profinet tendrá atributos para su "DeviceName" (nombre Profinet) y dirección IP/MAC, mientras que un dispositivo en una red Profibus tendrá un atributo para su dirección Profibus.3 ### 4.4. Representación de Dispositivos/Nodos Cada dispositivo físico o lógico (PLC, módulo IO, switch, etc.) se representa como un `InternalElement`. Los identificadores clave son: - `Name`: El nombre asignado en TIA Portal. - `ID`: Un GUID único para esa instancia de dispositivo en el archivo AML. - `RefBaseSystemUnitPath`: Enlace al tipo de hardware específico definido en una `SystemUnitClassLib` (probablemente una biblioteca de Siemens). - `RefBaseRoleClassPath`: Enlace opcional a un rol funcional definido en una `RoleClassLib`. - `Attribute`s: Propiedades específicas como el número de pedido de Siemens (`SiemensOrderNumber` o similar basado en "PLC type designation" 3), `StationID` 3, etc. ### 4.5. Representación de Interfaces/Puertos de Dispositivo Cada punto de conexión de red en un dispositivo se representa como un `ExternalInterface` anidado dentro del `InternalElement` del dispositivo. Identificadores clave: - `Name`: Nombre del puerto (ej. "X1", "P1"). - `ID`: GUID único para esa instancia de interfaz. - `RefBaseClassPath`: Enlace al tipo de interfaz definido en una `InterfaceClassLib` (probablemente `CommunicationInterfaceClassLib` o una específica de Siemens). Los parámetros de red cruciales se almacenan como elementos `Attribute` hijos del `ExternalInterface`. La siguiente tabla resume los atributos más probables basados en la evidencia: **Tabla 1: Atributos Clave para Interfaces de Red en AML (Basado en Estándares y Ejemplos)** | | | | | | |---|---|---|---|---| |**Nombre del Atributo (Probable)**|**Descripción**|**Tipo de Dato (Probable)**|**Ubicación Típica**|**Fuentes de Evidencia**| |`ip` / `IPAddress` / `Address`|Dirección IP|`xs:string`|Hijo de ``|| |`mac` / `MACAddress`|Dirección MAC|`xs:string`|Hijo de ``|| |`netmask` / `SubnetMask`|Máscara de subred|`xs:string`|Hijo de ``|| |`DeviceName` / `ProfinetDeviceName`|Nombre del dispositivo Profinet|`xs:string`|Hijo de ``|Inferido de| |`ProfibusAddress`|Dirección Profibus|`xs:integer`/`xs:string`|Hijo de ``|Inferido de| |`StationID`|Identificador de estación (específico del contexto)|`xs:integer`/`xs:string`|Hijo de ``|3| |`MasterSystemID`|ID del sistema maestro (Controlador IO / Maestro DP)|`xs:integer`|Hijo de ``|3| |`SiemensOrderNumber` / `PLCTypeDesignation`|Número de pedido de Siemens para el dispositivo/módulo|`xs:string`|Hijo de ``|3| |`PlugDesignation`|Designación del conector físico (ej. "P1 R")|`xs:string`|Hijo de ``|3| |`BusInterfaceName`|Nombre de la interfaz de bus (ej. "PROFINET interface_1")|`xs:string`|Hijo de ``|3| _Nota: La ubicación exacta (en `InternalElement` vs. `ExternalInterface`) y los nombres de algunos atributos pueden variar ligeramente según la implementación específica de Siemens y la versión de TIA Portal._ Los identificadores únicos (`ID`) asignados a cada `InternalElement` y `ExternalInterface` son absolutamente críticos. Permiten establecer las conexiones de forma inequívoca mediante los elementos `InternalLink`. El análisis del archivo AML dependerá en gran medida de la capacidad de resolver estas referencias de ID para reconstruir la topología. ### 4.6. Representación de Conexiones Las conexiones físicas o lógicas entre puertos se definen explícitamente mediante elementos `InternalLink`. - Cada `InternalLink` tiene un `Name` y un `ID` únicos. - La conexión se define mediante los atributos `RefPartnerSideA` y `RefPartnerSideB`. Cada uno de estos atributos contiene el `ID` (GUID) de uno de los elementos `ExternalInterface` que participan en la conexión. - Al analizar el archivo, encontrar un `InternalLink` permite identificar directamente qué dos puertos (y por lo tanto, qué dos dispositivos) están conectados. - Estos elementos `InternalLink` suelen encontrarse como hijos del `InternalElement` que representa la red o subred a la que pertenecen las interfaces conectadas. Aunque la estructura central (IE, EI, IL, Attribute) es estándar CAEX, los valores específicos de `RefBase...Path` que apuntan a las bibliotecas y los nombres exactos de algunos atributos (más allá de los básicos como `ip`, `mac`) dependerán de las bibliotecas AML utilizadas por TIA Portal (bibliotecas AML estándar como `CommunicationInterfaceClassLib` o bibliotecas específicas de Siemens).3 Un análisis exitoso requiere identificar qué bibliotecas y atributos utiliza realmente TIA Portal en su exportación, lo que puede requerir examinar archivos exportados reales. ## 5. Análisis (Parsing) de AML para Generación de Árbol de Red ### 5.1. Estrategia General El análisis de los archivos AML exportados por TIA Portal para extraer la topología de red se puede abordar utilizando bibliotecas estándar de procesamiento XML disponibles en la mayoría de los lenguajes de programación (como Python, C#, Java). La estrategia general implica: 1. Cargar el archivo `.aml` exportado por TIA Portal. 2. Navegar por el Modelo de Objetos del Documento (DOM) XML siguiendo la estructura CAEX descrita anteriormente. 3. Identificar y extraer la información relevante sobre redes, dispositivos, interfaces, parámetros y conexiones. 4. Construir una representación interna (por ejemplo, objetos o estructuras de datos) de la topología de red. La naturaleza estructurada de CAEX, con identificadores únicos y enlaces explícitos, hace que este proceso sea factible y relativamente directo con las herramientas XML estándar. ### 5.2. Identificación de Elementos Clave El proceso de análisis debe centrarse en localizar y procesar los siguientes elementos dentro del archivo AML: 1. **Raíz de Instancias:** Localizar el elemento ``. Este es el contenedor principal de la configuración específica del proyecto. El análisis debe centrarse principalmente en este elemento y sus descendientes. Las secciones de bibliotecas (``, etc.) definen los _tipos_, pero la `InstanceHierarchy` contiene las _instancias_ reales y sus conexiones. 2. **Redes/Subredes:** Iterar a través de los `InternalElement` hijos directos de `` (o anidados según la estructura del proyecto). Identificar aquellos que representan redes basándose en su `Name` o, de forma más robusta, en su `RefBaseRoleClassPath` o `RefBaseSystemUnitPath` (buscando identificadores como "ProfinetSystem", "ProfibusMasterSystem"). 3. **Dispositivos:** Dentro de cada `InternalElement` de red (o en la jerarquía de carpetas correspondiente), buscar recursivamente los `InternalElement` que representan dispositivos. Para cada uno, extraer su `Name`, `ID`, `RefBaseSystemUnitPath` (para tipo de hardware) y los `Attribute`s relevantes (ej. `SiemensOrderNumber`, `StationID`). 4. **Interfaces:** Dentro de cada `InternalElement` de dispositivo, encontrar todos los elementos `ExternalInterface`. Extraer su `Name`, `ID`, `RefBaseClassPath` (para tipo de interfaz) y, crucialmente, iterar sobre sus `Attribute`s hijos para extraer los parámetros de red (IP, MAC, Netmask, Nombre Profinet, etc., consultando la Tabla 1). 5. **Conexiones:** Localizar todos los elementos `InternalLink` (probablemente hijos del IE de red o en un nivel superior). Para cada uno, extraer los valores de los atributos `RefPartnerSideA` y `RefPartnerSideB`. Estos son los `ID`s de las dos `ExternalInterface` que están conectadas. ### 5.3. Construcción del Árbol de Nodos Una vez extraída la información del XML, el siguiente paso es construir la representación de la topología deseada: 1. **Definir Estructuras de Datos:** Es fundamental diseñar clases u otras estructuras de datos en el lenguaje de programación elegido para representar los conceptos de Red (`Network`), Dispositivo (`Device`), Interfaz (`Interface`) y Conexión (`Connection`). La clase `Interface` debe poder almacenar los atributos de parámetros de red extraídos (IP, MAC, etc.). La clase `Connection` debe enlazar dos objetos `Interface`. 2. **Crear Mapas de ID:** Durante el análisis de dispositivos e interfaces (pasos 3 y 4 anteriores), poblar diccionarios o mapas hash que permitan una búsqueda rápida de objetos `Device` e `Interface` a partir de su `ID` (GUID). Esto es esencial para resolver las referencias en los `InternalLink`s. 3. **Procesar Dispositivos e Interfaces:** Iterar sobre los elementos XML correspondientes, crear instancias de los objetos `Device` e `Interface` definidos en el paso 1, almacenar sus atributos y poblar los mapas de ID. 4. **Procesar Conexiones:** Iterar sobre los elementos `InternalLink`. Para cada uno, usar los `ID`s de `RefPartnerSideA` y `RefPartnerSideB` para buscar los objetos `Interface` correspondientes en los mapas creados en el paso 2. Crear un objeto `Connection` que enlace estos dos objetos `Interface`. 5. **Ensamblar la Estructura:** Organizar los objetos `Device` bajo sus respectivos objetos `Network` (identificados en el paso 2 del análisis). Las conexiones establecidas en el paso 4 forman las aristas del grafo o árbol de red. El resultado es una representación en memoria de la topología de red que puede ser consultada o visualizada según sea necesario. ### 5.4. Manejo de Posibles Desafíos - **Archivos Grandes:** Proyectos de TIA Portal muy extensos pueden generar archivos AML de gran tamaño. El análisis basado en DOM puede consumir mucha memoria. En tales casos, considerar el uso de analizadores SAX (Simple API for XML), aunque esto puede complicar la resolución de referencias de ID, ya que requiere mantener el estado manualmente. - **Espacios de Nombres (Namespaces):** El archivo AML utilizará al menos el espacio de nombres CAEX (`http://www.dke.de/CAEX/3.0`). Asegurarse de que el analizador XML esté configurado para manejar correctamente los espacios de nombres al buscar elementos. - **Referencias a Bibliotecas:** Si bien el análisis de la `InstanceHierarchy` es suficiente para la topología, comprender las clases referenciadas (`RefBase...Path`) puede añadir contexto semántico valioso. Si es necesario, se pueden analizar también las secciones de bibliotecas (``, etc.) para obtener detalles sobre los tipos de dispositivos e interfaces. - **Diferencias entre Versiones:** La estructura exacta o los atributos utilizados por TIA Portal podrían tener ligeras variaciones entre diferentes versiones (V15, V16, V17, V18, V19, etc.). Es recomendable probar el analizador con exportaciones de las versiones específicas de TIA Portal que se necesiten soportar. Basar el análisis en elementos y atributos estandarizados (como `ip`, `mac` de) en lugar de depender excesivamente de detalles observados en un solo ejemplo proporcionará mayor robustez frente a futuras actualizaciones, siempre que Siemens mantenga la conformidad con los estándares AML. ## 6. Conclusión y Recursos Adicionales ### 6.1. Resumen de Hallazgos El análisis confirma que Siemens TIA Portal utiliza el formato estándar AutomationML (AML), basado en CAEX (IEC 62424), para su funcionalidad de exportación CAx. Esta exportación incluye la información necesaria para reconstruir la topología de red de un proyecto, abarcando la configuración de hardware, la estructura de red (Profinet, Profibus), las asociaciones de dispositivos a subredes, las direcciones de los dispositivos (IP, MAC, Profibus, etc.) y las interconexiones. La estructura XML se basa en elementos CAEX clave: `InstanceHierarchy` para la configuración del proyecto, `InternalElement` para representar redes, carpetas y dispositivos, `ExternalInterface` para los puertos de los dispositivos (conteniendo atributos para parámetros como la dirección IP), y `InternalLink` para definir explícitamente las conexiones entre interfaces mediante referencias a sus `ID`s únicos. Esta estructura bien definida, respaldada por los estándares IEC 62714 (especialmente la Parte 5 para comunicación) e IEC 62424, es adecuada para el análisis programático mediante herramientas XML estándar, permitiendo la extracción de datos y la generación del árbol de nodos conectados por red deseado. Si bien la estructura central es estándar, los detalles semánticos específicos (nombres de clases en bibliotecas, nombres de atributos específicos de Siemens) pueden requerir la consulta de documentación de Siemens o el análisis de archivos de exportación reales. En general, existe una alta confianza en que la exportación AML de TIA Portal contiene la información necesaria en un formato analizable. ### 6.2. Recomendaciones Para desarrollar una herramienta o script que analice los archivos AML de TIA Portal y genere un árbol de topología de red, se recomienda: 1. **Utilizar Bibliotecas XML Estándar:** Aprovechar las capacidades de análisis DOM o SAX disponibles en el lenguaje de programación elegido. 2. **Enfocarse en `InstanceHierarchy`:** Centrar el análisis en esta sección del archivo AML, ya que contiene la configuración específica del proyecto. 3. **Gestionar IDs Únicos:** Implementar un mecanismo (como mapas hash) para almacenar y buscar eficientemente `InternalElement`s y `ExternalInterface`s por su atributo `ID`, ya que esto es crucial para resolver las conexiones definidas en los `InternalLink`s. 4. **Extraer Atributos Relevantes:** Identificar y extraer los `Attribute`s que contienen los parámetros de red necesarios (IP, MAC, Netmask, Nombre Profinet, Dirección Profibus, etc.), prestando atención a los nombres de atributo probablemente utilizados (ver Tabla 1). 5. **Validar con Exportaciones Reales:** Probar y validar el analizador con archivos `.aml` generados por las versiones específicas de TIA Portal de interés para asegurar la compatibilidad y manejar posibles variaciones. 6. **Diseñar Estructuras de Datos:** Crear un modelo de datos interno claro (clases/structs) para representar Redes, Dispositivos, Interfaces y Conexiones, facilitando la reconstrucción y el uso posterior de la topología extraída. ### 6.3. Recursos Adicionales Para una comprensión más profunda y detalles definitivos, se recomienda consultar las siguientes fuentes: - **AutomationML e.V.:** El sitio web oficial (www.automationml.org) ofrece acceso a las especificaciones de AML (incluyendo whitepapers y recomendaciones de aplicación como las de Comunicación y Configuración de Proyectos), bibliotecas de clases estándar, herramientas (como el Editor AML) y otra documentación. - **Normas IEC:** Adquirir las normas oficiales IEC 62714 (especialmente Parte 1: Arquitectura y Requisitos Generales, y Parte 5: Comunicación) e IEC 62424 (CAEX) proporciona la especificación formal y definitiva. - **Siemens Industry Online Support (SIOS):** El portal de soporte de Siemens (support.industry.siemens.com) contiene documentación específica de TIA Portal sobre la funcionalidad de exportación/importación CAx, TIA Portal Openness, ejemplos de aplicación y notas técnicas. - **GitHub:** Pueden existir repositorios relevantes, como los del propio consorcio AutomationML (para motores de análisis como AMLEngine o ejemplos) u otros desarrolladores que trabajen con TIA Portal Openness y AML.4 Consultar estas fuentes permitirá obtener tanto la base teórica de los estándares como los detalles prácticos de la implementación específica de Siemens en TIA Portal.