<- До підрозділу Коментувати

Аналіз файл експорту проєкту Eplan в форматі AML AR APC: практична частина

Це чернетка

https://www.eplan.help/en-us/Infoportal/Content/Plattform/2025/Content/htm/plcgui_k_amlbusdatenaustausch.htm

Теоретичні відомості

Обмін даними PLC у форматі AutomationML AR APC

Обмін даними PLC можливий для різних виробників PLC у форматі AutomationML (Automation Markup Language). Це незалежний від виробника формат даних на основі XML. У межах AutomationML існують різні варіанти залежно від призначення. Для обміну даними PLC використовується варіант “Application Recommendation Automation Project Configuration” (скорочено AR APC).

Для цього у діалогах експорту та імпорту даних PLC доступні відповідні записи у списку можливих форматів залежно від обраної програми конфігурування PLC. Під час експорту у форматі AutomationML слід враховувати такі аспекти:

• Кожен об’єкт у AutomationML ідентифікується GUID (Globally Unique Identifier), який є унікальним у світовому масштабі. Якщо GUID не задано, він автоматично призначається під час експорту і зазвичай не повинен змінюватися вручну. Тому експорт у форматі AutomationML можливий лише з редагованих проєктів.
• GUID у AutomationML має формат “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”, де “x” означає один із символів “0 1 2 3 4 5 6 7 8 9 a b c d e f A B C D E F”.
• Власні GUID також призначаються точкам з’єднання функцій. Точки з’єднання експортуються як ExternalInterface.
• Додаткові вироби (accessory parts) можуть за потреби виводитися в експортний файл і мають власні GUID. Це, наприклад, потрібно для обміну додатковими виробами з TIA Selection Tool. Додатковими вважаються всі вироби, зазначені на позиціях від 2 до 50 вкладки Parts у діалозі властивостей головної функції. Для експорту таких виробів у керуванні виробами має бути задано позначення типу PLC. GUID для додаткових виробів призначається автоматично під час експорту та зберігається у властивості AutomationML GUID (accessories).
• Якщо додатковий виріб у головній функції видаляється, пов’язаний GUID також видаляється. Якщо додатковий виріб редагується (наприклад, вибір нового виробу або зміна порядку на вкладці Parts), GUID зберігається.
• Функцію стиснення проєкту можна використати для видалення непотрібних AutomationML GUID (наприклад, у копії проєкту). Для цього у діалозі Settings: Compression на рівні Remove project data потрібно активувати прапорець AutomationML GUIDs.
• Під час експорту враховуються всі пристрої, які мають щонайменше один порт шини. Це означає, що, окрім PLC, можуть експортуватися також “чорні ящики”, двигуни та інші пристрої.
• Для шин на базі Ethernet можна вказати, чи слід виводити у файл специфічну для портів міжпортову комутацію. У разі використання гнучкого кабелювання цю опцію можна вимкнути, щоб уникнути доопрацювання.
• Імена модулів у межах однієї стійки мають бути унікальними для експорту у форматі AutomationML AR APC. У цьому випадку як ім’я експортується не опис об’єкта, а властивість PLC card name. Якщо PLC card name порожня, експортується опис об’єкта з додаванням послідовного номера (Description_1, Description_2 тощо). Якщо опис відсутній, генерується унікальна PLC card name. Згенеровані імена зберігаються у властивості PLC card name (ID 20437).
• Окрім текстів функцій точок з’єднання PLC, експортуються та імпортуються також тексти функцій PLC-пристроїв (властивість Function text (automatic)). Тексти передаються всіма наявними мовами. Мова, вибрана у діалозі експорту або імпорту, є основною у файлі обміну та зберігається як значення (Value), інші мови — як додаткові атрибути.
• Під час експорту у форматі AR APC налаштовувані точки з’єднання PLC перетворюються на звичайні точки I/O (залежно від типу сигналу у логіці точки з’єднання). Під час імпорту вони знову перетворюються на налаштовувані точки PLC, якщо знайдено відповідний виріб із шаблоном функції “PLC connection point, multi-function”.
• Під час імпорту AutomationML-файлу порожні або відсутні DT-елементи не перезаписують заповнені DT-елементи в EPLAN.
• Під час імпорту пристрої та точки з’єднання PLC, які є в проєкті, але відсутні у файлі імпорту, позначаються властивістю Marked for deletion. Для точок PLC це відбувається, якщо у файлі імпорту символічна адреса порожня, а у проєкті властивість Symbolic address (automatic) заповнена. Наявна адреса зберігається. Такі об’єкти можна перевірити через перевірку 004029.
• Вільні символічні адреси (не призначені жодній точці PLC) можуть експортуватися та імпортуватися у форматі AR APC. Після імпорту вони доступні в EPLAN і можуть використовуватися зі списку призначень.

Розширення починаючи з версії AR APC 1.1.0

• Завдяки розширенням у форматі AML AR APC можна замінювати довші позначення пристроїв (device tags).
• Покращено обмін вільними символічними адресами через розширення формату AML AR APC щодо списку призначень.
• Змінено механізм призначення PLC-карт до CPU. Це дає змогу під час обміну даними PLC відновити зв’язок PLC-карти з відповідною CPU.
• Шинну систему “PortToPort” можна використовувати, якщо потрібно експортувати не логічну мережу, а лише з’єднання між шинними портами (специфічну для портів комутацію).
• Шинні системи “DRIVE-CLiQ”, “PortToPort” та “ET connection” коректно експортуються зі специфічною для портів комутацією.
• З’єднання між стійками передаються зі специфічною для портів комутацією.
• Передаються адреси безпеки (safety addresses) у шинних системах.
• Можна замінювати назву виробника на пристроях. В EPLAN назва виробника зберігається у довідкових даних виробу.

Розширення починаючи з версії AR APC 1.2.0

• Можливий обмін приводами та їх компонентами. Для експорту приводів і компонентів приводів потрібно активувати прапорець Export drives у діалозі Settings: AutomationML AR APC export.
• Можливий обмін специфічними для пристрою конфігураційними значеннями. Для цього можна задати шаблон у властивостях PLC device: TemplateIdentifier та/або PLC station: TemplateIdentifier, або використовувати користувацькі властивості довідкових даних виробу.

Розширення починаючи з версії AR APC 1.3.0

• Можливий обмін символічними адресами в межах користувацьких типів даних (UDT). Для цього потрібно задати ім’я та відповідний тип даних UDT у властивостях Symbolic address: UDT (name) та Symbolic address: UDT (data type). Фактична структура UDT потрібна лише в програмі конфігурування PLC і означується тільки там.

Розширення починаючи з версії AR APC 1.4.0

• Підтримується керування знімними портами шини на рівні вищого пристрою. Для цього у вкладці PLC structure data доступна властивість Manage bus ports at the superior device (ID 20620).

Налаштування для різних шинних систем

У таблиці наведено властивості, релевантні для обміну даними PLC у форматі AutomationML AR APC. Які з них обов’язкові (x), а які необов’язкові (o), залежить від використаної шинної системи.

Неідентифіковані поля не є обов’язковими для обміну даними PLC. Якщо необов’язкові поля (o) залишаються порожніми, імпорт у програму конфігурування PLC можливий, але потребує додаткового опрацювання.

Налаштування для різних шинних систем

Наведена нижче таблиця містить огляд властивостей, релевантних для обміну даними PLC у форматі AutomationML AR APC. Які властивості на шинних портах є обов’язковими (x), а які необов’язковими (o), залежить від використаної шинної системи.

*1: Потрібно лише у випадку, якщо значення відрізняється від значення відповідного PLC-блока. *2: Може бути заповнене, якщо це ASI dual device. *3: Може бути активоване для ігнорування шинних портів, які не потребують адреси шини під час виконання перевірки помилки 004037.

Неідентифіковані поля не є обов’язковими для обміну даними PLC. Якщо необов’язкові поля (o) залишаються порожніми, імпорт у програму конфігурування PLC можливий, але потребує додаткового доопрацювання.

Клас ролей

AutomationProject

Об’єкт AutomationProject представляє проєкт, з якого походить експорт. Він агрегує всі інші об’єкти нижчого рівня. Стандартними параметрами проєкту є його name (string), виробник проєкту (string), позначення проєкту виробника (string), номер ревізії проєкту (string) та project information (string), що містить коментар до проєкту.

Device

Об’єкт Device представляє колекцію, в якій об’єднуються окремі апаратні об’єкти slave-пристрою або стійки, включно з самим апаратним елементом slave або стійки. Таким чином, Device є контейнером DeviceItem, який слугує колекцією елементів DeviceItem (зокрема апаратних елементів). Device повинен мати унікальне ім’я в межах автоматизаційного проєкту. Пристрій може бути:

• центральна конфігурація з кількома стійками (станція системи автоматизації з центральними та розширювальними стійками);
• фіксована комбінація CPU та кількох модулів I/O (наприклад, C7);
• станція на базі ПК, де ПК представляє пристрій;
• польовий пристрій;
• комутатор.

Стандартні параметри об’єкта Device наведені нижче:

• Name (string): ім’я пристрою;
• Необов’язковий атрибут TypeIdentifier (string): ідентифікатор типу пристрою.
• Необов’язковий додатковий підатрибут TemplateIdentifier посилається на шлях до елемента бібліотеки;
• Необов’язковий атрибут Manufacturer (string): додаткова інформація для опису виробника пристрою;
• Необов’язковий атрибут Comment (string): коментар до пристрою.

Атрибут TypeIdentifier має префікс, який описує семантику подальшого ідентифікатора і відокремлюється символом :. Дозволені такі префікси: OrderNumber, GSD, System, CSP+. У разі відсутності TypeIdentifier інструмент імпорту повинен застосувати стратегію заміщення. Не гарантується, що стратегія заміщення буде успішною в усіх випадках.

Приклади: TypeIdentifier = GSD:SIEM8139.GSD/DAP TypeIdentifier = System:Device.Generic TypeIdentifier = System:Device.S7-1500 TypeIdentifier = System:Device.IQ-R TemplateIdentifier = GlobalLib://TemplateLibrary/Master copies/S7-1500/preconfigured/PLCs/s7-1518F

DeviceItem

DeviceItem агрегується об’єктом Device і представляє узагальнений клас для апаратних модулів і підмодулів (CPU, модуль I/O, стійка тощо). Якщо Device представляє логічну оболонку, то DeviceItem більшою мірою представляє фізичні апаратні об’єкти.

DeviceItem може бути вставлений в інший DeviceItem (наприклад, CPU у стійку, підмодуль у модуль). Відносне положення щодо батьківського об’єкта визначається параметром PositionNumber.

DeviceItem також може бути вбудованим в інший DeviceItem. Такі DeviceItem можуть моделювати фіксовану комбінацію, яка не може бути розділена (наприклад, C7). Стандартні параметри об’єкта DeviceItem наведені нижче:

• Name (string): ім’я DeviceItem;
• TypeName (string): додаткова інформація про тип. Необов’язкова, але корисна для користувача у разі помилки;
• DeviceItemType (string): класифікація DeviceItem (наприклад, CPU). DeviceItemType є додатковою інформацією, яка може бути корисною користувачу у разі помилки;
  • Customized (boolean): підатрибут Customized вказує, чи містить DeviceItemType виробник-специфічну інформацію (Customized = “true”), чи ні (Customized = “false”). Якщо атрибут відсутній або має значення “false”, DeviceItemType містить уже стандартизовану інформацію (наприклад, CPU);
• Manufacturer (string): додаткова інформація для опису виробника DeviceItem;
• CustomAttributes (ListType): додаткова виробник-специфічна інформація для DeviceItem. Визначає імена та значення властивостей, специфічних для виробника;
• PositionNumber (int): номер слота, у який вставлено цей DeviceItem;
• BuiltIn (Boolean): ознака, що вказує на те, що цей модуль є вбудованою частиною іншого модуля. Такий модуль створюється автоматично, оскільки є фіксованою частиною іншого модуля. Якщо параметр відсутній, за замовчуванням має значення false;
• TypeIdentifier (string): ідентифікатор типу елемента пристрою. Необов’язковий додатковий підатрибут TemplateIdentifier посилається на шлях до елемента бібліотеки;
• FirmwareVersion (string): задає версію прошивки, наприклад CPU, і може бути необхідною для коректної ідентифікації модуля (інколи номера замовлення недостатньо);
• Comment (string): необов’язковий коментар до модуля;
• Address (OrderedListType): адресна інформація елемента пристрою в межах пристрою. Більшість модулів мають призначені діапазони адрес. Наприклад, можуть існувати діапазони адрес для входів і виходів, які описуються початковим значенням і довжиною. Address визначає початок, довжину та тип I/O. Він моделюється як впорядкований список адресних параметрів. Порядок необхідний для ідентифікації коректного підпристрою у разі кількох початкових адрес для одного модуля. Підпараметри наведені нижче:
  • StartAddress (int): початок адреси;
  • Length (int): загальна ширина модуля (виробник-специфічна). У більшості випадків відповідає ширині всіх каналів;
  • IoType (string): вхід або вихід;
  • BitOffset (int): початок бітової адреси в межах байта;
  • InstallationDate (dateTime): дата встановлення елемента пристрою.

Примітка: Окрім наведених стандартних документів можуть бути додані атрибути, що дають змогу представляти референтні позначення відповідно до IEC 81346. Нижче наведено три можливі приклади таких атрибутів.

• PlantDesignation IEC (string): позначення установки для цього елемента пристрою. PlantDesignation є референтним позначенням, орієнтованим на продукт, відповідно до IEC 81346-1:2009-07, 5.3 – функціонально орієнтована структура;
• LocationIdentifier IEC (string): позначення розташування для цього елемента пристрою. LocationIdentifier є референтним позначенням, орієнтованим на розташування, відповідно до IEC 81346-1:2009-07, 5.5 – структурa, орієнтована на розташування;
• ProductDesignation IEC (string): позначення продукту для цього елемента пристрою. ProductDesignation є референтним позначенням, орієнтованим на продукт, відповідно до IEC 81346-1:2009-07, 5.4 – структурa, орієнтована на продукт.

Subnet

Об’єкт Subnet відповідає за зберігання та керування властивостями і функціональністю мереж, таких як Ethernet, PROFIBUS, MPI тощо. Підмережа визначається логічною доступністю всіх учасників підмережі. Усі учасники підмережі мають різні, однозначні адреси. Стандартні параметри об’єкта Subnet наведені нижче:

• Name (string): назва підмережі;
• Type (string): тип підмережі (наприклад, PROFIBUS, MPI тощо). Тип має бути визначений у шинно-специфічному описі;
• CustomAttributes (ListType): додаткова виробник-специфічна інформація для підмережі. Містить імена та значення властивостей, специфічних для виробника;
• Subnet має рівно один LogicalEndpoint для з’єднання підмережі з вузлами.

Channel

Channel є частиною модуля I/O і представляє технологічний інтерфейс (наприклад, цифровий або аналоговий вхід чи вихід). Канал є частиною DeviceItem, що представляє модуль I/O, і може використовуватися лише в межах DeviceItem. Канал посилається на теги за допомогою зв’язку. Стандартні параметри об’єкта Channel наведені нижче:

• Type (string): аналоговий або цифровий;
• IoType (string): вхід або вихід;
• Number (int): номер каналу, починаючи з 0;
• Length (int): ширина каналу (наприклад, 1 для біта, 8 для байта, 16 для слова);
• CustomAttributes (ListType): додаткова виробник-специфічна інформація для каналу, що визначає імена та значення властивостей виробника.

Канал за допомогою LinkToTag посилається на відповідні теги, які зберігаються в DeviceItem CPU.

CommunicationInterface

CommunicationInterface є спеціальним типом DeviceItem, який виступає точкою підключення пристрою до мережі (наприклад, мережева карта). Тому CommunicationInterface має LogicalEndpoint. Залежно від типу CommunicationInterface він може містити різні параметри, специфічні для цього типу. Відповідні шинно-специфічні параметри описуються в окремій специфікації шини. Стандартні параметри об’єкта CommunicationInterface наведені нижче:

• Label (string): назва, надрукована на елементі, наприклад унікальний ідентифікатор;
• Type (string): тип CommunicationInterface (наприклад, ExtensionRack);
• CustomAttributes (ListType): додаткова виробник-специфічна інформація для CommunicationInterface, що визначає імена та значення властивостей виробника.

Клас інтерфейсів

logicalEndPoint

Сутність logicalEndPoint представляє комунікаційного партнера в такому відношенні. Властивість logicalEndPointId є GUID у межах системи автоматизації та ідентифікує logicalEndPoint. Властивість logicalEndPointRole має тип даних string і може використовуватися для задання логічної ролі logicalEndPointId у комунікаційному відношенні. Можливими значеннями можуть бути пари типу source – destination, source – sink, publisher – subscriber або master – slave тощо.

Похідними прикладами такої кінцевої точки комунікації можуть бути IP-порт або peer.

Послідовність виконання робіт

1. Підготовчі роботи

• Встановіть на ПК безкоштовну версію редактору XiMpLe XML editor або інший XML редактор
• Завантажте та встановіть безкоштовну версію редактору AutomationML editor
• Завантажте собі на ПК EplanAPCdemo.aml
• Відкрийте EplanAPCdemo.aml в 2-х редакторах - XML editor та AutomationML editor
• Відкрийте PDF версію проєкту, звідки зроблено експорт

2. Визначення основної інформації про проєкт

• Використовуючи атрибути об’єкту AutomationProject визначте його властивості
• Визначте перелік екземплярів з роллю Device в проєкті, для кожної визначте значення атрибутів
• Визначте перелік екземплярів з роллю Subnet в проєкті, для кожної визначте значення атрибутів

Джерела

1. https://www.eplan.help/en-us/Infoportal/Content/Plattform/2025/Content/htm/plcgui_k_amlbusdatenaustausch.htm

Автори

Практичне заняття розробив Олександр Пупена.

Feedback

Якщо Ви хочете залишити коментар у Вас є наступні варіанти:

• Обговорення у WhatsApp
• Обговорення в Телеграм
• Група у Фейсбуці

Про проект і можливість допомогти проекту написано тут