В якості експертів круглого столу були запрошені керівники та провідні фахівці ВАТ «ФСК ЄЕС», ВАТ «НТЦ ФСК ЄЕС», а також проектних та інжинірингових організацій:
У першій частині круглого столу інженер проектного відділу компанії «Прософт-Системи» Ільяс Хусяінов представив учасникам доповідь на тему «Роль виробника ПТК в проектуванні АСУ ТП підстанцій», в рамках якого вперше була презентована система автоматизованого проектування ProJ, розроблена компанією «Прософт-Системи» .
Свій виступ Ільяс почав з розгляду загальних тенденцій сучасного ринку, зазначивши два найбільш значущих моменту. По-перше, поряд з традиційними проектними інститутами з'являються невеликі організації, а на підприємствах замовника створюються спеціалізовані проектні підрозділи, які не володіють достатнім досвідом і необхідною кваліфікацією. Це тягне за собою не тільки зниження вартості проектів і скорочення термінів їх виконання, а й погіршення якості. По-друге, безперервно збільшуються функціональні можливості проектованої системи, і зростає обсяг робіт.
У цих умовах використання систем автоматизованого проектування набуває особливого значення. Сьогодні відомий ряд великих САПР, таких як E-Plan, AutoCad Electrical та ін. Однак з огляду на їх високу вартість і тривалих термінів впровадження багато компаній змушені відмовлятися від застосування даних продуктів і шукати альтернативні рішення. Саме тому фахівцями «Прософт-Системи» був розроблений власний програмний комплекс - САПР ProJ.
У своїй презентації Ільяс Хусяінов акцентував увагу слухачів на наступних характеристиках САПР ProJ:
- САПР адаптований тільки для обладнання компанії «Прософт-Системи»;
- САПР повністю автоматизує всю рутинну роботу в частині проектування, дозволяючи проектувальнику займатися інтелектуальною працею;
- дані електронної моделі об'єкта вивантажуються в форматі Exсel і Autocad;
- в майбутніх версіях ПО буде передбачений модуль для генерації файлів конфігурації пристроїв відповідно до МЕК 61850.
Серед переваг нового програмного продукту були відзначені такі особливості, як скорочення термінів розробки проектів, виключення помилок, можливість використання при монтажі та налагодження для поновлення схем.
Найбільш повно висновок даного виступу, на наш погляд, відбився в наступному вислові доповідача: «Роль виробника в проектуванні - забезпечити проектувальника необхідною підтримкою на кожному етапі роботи».
По закінченню презентації пішли питання із залу. Перший з них поставив фахівець ЗАТ «РАДИУС Автоматика» Віктор Редін: «Чи є механізми, які дозволяють генерувати відмінності між версіями проектів?». Виявилося, зміни можливо відстежити в самій програмі, але не можна роздрукувати окремо.
У експертів також виник ряд питань. Сергій Лук'янов поцікавився можливістю продукту працювати з пристроями інших компаній-виробників. Однак, як зазначили розробники, на даний момент розвитку САПР в цьому напрямку не планується.
Головний, на наш погляд, питання прозвучало від Ігоря Архипова. Його зацікавило думку компанії щодо форматів представлення інформації при вивантаженні з САПР: «Варто вивантажувати в загальнозрозумілих форматах, таких як Excel, або ж пора дотримуватися стандартів МЕК?». Фахівці «Прософт-Системи» позначили позицію, згідно з якою для проектування систем відповідно до МЕК потрібно використовувати формати, описані в цих стандартах, так як уявлення в простих форматі не інформативно.
Друга частина круглого столу була присвячена проблемам проектування цифрових підстанцій. Для обговорення були запропоновані наступні питання:
- Наскільки актуально включення до нормативних документів вимоги щодо доповнення проектної та робочої документації файлами електронної конфігурації SCL відповідно до МЕК 61850 (SSD, SCD)?
- Які вимоги повинні пред'являтися до проектування локальних обчислювальних мереж (ЛВС) енергооб'єктів? Яка взаємозв'язок етапу розробки ЛВС з розробкою рішень з інформаційного обміну по протоколам стандарту МЕК 61850?
- Чи готові проектні організації до формування документації в новому форматі з точки зору своєї компетенції?
- Обмін досвідом використання систем автоматизованого проектування з можливістю формування файлів електронної конфігурації відповідно до стандарту МЕК 61850-6.
В кінці презентації на загальне обговорення було висунуто кілька питань:
- Чи варто відображати в проектній документації локально обчислювальну мережу, зокрема такий розділ, як параметрування Ethernet комутаторів?
- Як повинні описуватися комунікації? Чи потрібна використання мови SCL?
- Що повинно бути в проекті в паперовому вигляді, а що в електронному?
- Як домогтися типізації проектних рішень без прив'язки до конкретних виробникам?
Протягом усього круглого столу було відчуття, що ні експерти, ні учасники не могли вирішити, хто і в якому обсязі повинен знати стандарт МЕК 61850. Павло Горожанкин, як представник проектного інституту, вказав на проблему недостатнього розуміння самого процесу проектування. Повторивши основні етапи та обов'язки фахівців на кожному етапі, він висловив своє ставлення до стандарту: «Що стосується МЕК 61850, то я обома руками« за », але вчити мови SCL релейник, на мій погляд, неправильно, він повинен займатися своєю справою».
Наступним своїми уявленнями про проектувальника поділився Ігор Архипов: «Проектувальник як такої перетворився в інтегратора». З цим важко не погодитися, адже хороший проект вийде за умови наявності знань у проектувальника про використовуване обладнання, а при нинішньому темпі зміни техніки і відстає оновленні документації все повинно лежати на одних плечах.
Відповідаючи на питання про проектування ЛВС, Ігор Архипов зазначив: «На мій погляд, проект по ЛВС робити треба. При цьому потрібно запозичувати досвід з області телекому. Потрібно створити підпроект деякої універсальної ЛВС, а далі в кожному окремому проекті модифікувати його під конкретного виробника. Як наслідок, ми зможемо наблизитися до типізації проектів в їх основної частини, а далі буде досить наповнювати його пристроями від конкретних виробників. При цьому можуть бути виявлені і виправлені всі основні помилки. Так було б відразу видно, кому треба вчити SCL ». В кінці експерт звернув особливу увагу на уявлення документації: «Найбільш базове питання: що повинно бути - паперовий формат або електронний вигляд? Очевидно, варто використовувати і те і інше вже найближчим часом. Схеми - на паперовому носії, модель підстанції відповідно до МЕК 61850 - в якості файлів SCL. У кожного документа буде свій споживач ».
Перераховані вище питання зацікавили не тільки проектувальників, але і вендорів. Представник компанії «РАДИУС Автоматика» Дмитро Антонов висловив свою точку зору, вказавши на те, що раніше проект накопичував в собі певну базу знань, а зараз цього не відбувається.
- Розробку проектної документації у вигляді файлів SCL не варто розглядати як необхідність вивчення синтаксису SCL проектувальниками. Мова SCL повинен лише бути засобом відображення проектної документації, роботу з перетворення з / в цей формат повинні виконувати спеціалізовані програмні комплекси - САПРи.
- Навіть використання САПР не скасовує необхідності вивчення стандарту і його базових - абстрактних - моделей фахівцями різного рівня. Знання саме абстрактних засобів опису моделей буде необхідною умовою для успішної розробки проектів.
- В сучасних умовах розробити типові проекти неможливо, зважаючи на високу динаміки розвитку технологій, однак у проектувальників повинна з'явитися можливість робити свої проекти доступними (зокрема, на комерційній основі) для використання іншими проектними організаціями, з часом це буде сприяти розвитку ринку «кращих практик» в проектуванні.
Підводячи підсумок відбувся круглого столу, можна відзначити наступне: питань багато, і, здається, на все можна відповісти так. МЕК 61850? - Так! Вчимо SCL? - Так! Проектуємо цифрові підстанції - Так! Однак попри всі «так», на наш погляд, у фахівців все-таки залишається відчуття, що чогось не вистачає або щось забули.
- Чи доводилося Вам чути про стандарт МЕК 61850?
- На Ваш погляд, застаріли чи підходи до проектування вторинних систем?
- Чи згодні Ви з твердженням, що якість реалізації комплексів РЗА і АСУ ТП сьогодні багато в чому залежить від компетенції наладчиків, ніж від проектувальників?
- Чи чули Ви що-небудь про мову SCL і його використанні при проектуванні комплексів РЗА і АСУ ТП відповідно до МЕК 61850?
- Чи вважаєте Ви за доцільне створення файлів формату SSD і SCD на етапах створення проектної та робочої документації?
- Чи повинен проект РЗА і АСУ ТП включати в себе параметри налаштування обладнання локальної обчислювальної мережі енергооб'єкта?
Як нам здається, результати опитування - найкращий висновок проведеного круглого столу. Представляємо їх Вашій увазі:
З приводу питання про необхідність файлів SSD і SCD на стадіях ПД і РД: у кожного постачальника АСУ ТП своє програмне забезпечення для параметрування системи, яке часто вимагає виконання всіх налаштувань всередині власного інтерфейсу, а сторонні файли конфігурації сприймає некоректно. Тому, думаю, на стадіях ПД і РД повинні розроблятися розділи з необхідними даними для цих файлів, а самі файли повинні створюватися вже на стадії налагодження системи.
Згоден з вами, що на перехідному етапі це, ймовірно, повинно бути так. Але, тим не менш, саме перехід до формування такого файлу проектувальником, з подальшою "безшовної" завантаженням цього файлу в АСУ ТП дозволить отримати вигоду від використання Мека. в іншому випадку спроба вручну описати ці параметри, і вручну задати їх буде приводити до необхідності робити купу роботи, а також до купи помилок.
Все-таки те, про що Ви пишете це завдання наладчиків.
Вся проблема в тому, що після випуску РД ще дуже багато що може змінитися (виробники обладнання, типи, версії ПО). Проектувальники працюють з якимсь кулястим обладнанням в вакуумі, а не з конкретними залізяччям. Ніхто не може гарантувати, що постачальник устаткування щось не оновить і тоді яка використовувалася файли конфігурації вже будуть не актуальними.
Коли вже все обладнання коштує на ПС, все змонтовано, тоді вже можна і займатися конфигурированием системи.
Звичайно, згоден, що коли з'явиться стандартне для галузі ПЗ, де можна і креслення малювати, і задавати параметри системи, де можна буде працювати з будь-яким обладнанням, це буде дуже зручно. Але поки що не бачу на горизонті такого софта.
повинні розроблятися розділи з необхідними даними для цих файлів
Що ви маєте на увазі під цим?
"Нізкокогерентний світло, тобто світло з довжиною когерентності" - це маячня з точки зору фізики. Відразу ріже око. Виправте будь ласка.
Ось приклад реального проекту (пристрої і сигнали навмисно перейменовані), праворуч показаний набір даних.
Програмно-технічний комплекс (ПТК) SMART-SPRECON виробництва АТ «Ртсофт» успішно пройшов атестаційні іспити.
«E-F @ ctory - технологічна основа стратегії« Товариства 5.0 », інструмент підвищення конкурентоспроможності російської.