ЖУРНАЛ СТА №3/1999

● пакет управления сетевым оборудова- нием Transcend Management (версия 6.1) фирмы 3COM. Какую SCADA-систему выбрать? АСУ ТП является дальнейшим разви- тием информационно-вычислитель- ной системы (ИВС), успешно прорабо- тавшей на НВГРЭС более 2 лет. ИВС бы- ла реализована на основе промышлен- ных контроллеров с процессором 386 (плата MicroPC 5025А фирмы Octagon Systems). В персональных компьютерах верхнего уровня использовалась опера- ционная система MS-DOS. В контролле- рах нижнего уровня был применен многозадачный монитор реального времени собственной разработки. В 1997 году начались работы по со- зданию полномасштабной АСУ ТП 1 – го блока НВГРЭС. К этому времени произошли определенные конъюнк- турные изменения на рынке покупного программного обеспечения: среди опе- рационных систем ведущие позиции заняла Windows NT, стали реально до- ступными покупные SCADA-системы, как западные, так и отечественные. С учетом того, что АСУ ТП 1-го блока НВГРЭС рассматривается в качестве ба- зовой, она должна быть не только кон- курентоспособной по отношению к су- ществующим западным и отечествен- ным АСУ ТП, но и иметь характеристи- ки, позволяющие ей находиться на со- временном уровне в течение достаточ- но продолжительного времени. Рассма- тривались два направления решения этой задачи: перевод программного комплекса на современные операцион- ные системы и использование для со- здания технологического комплекса со- временной SCADA-системы. Оба на- правления взаимосвязаны, так как обычно приобретаемая SCADA-система задает требования к общесистемному программному обеспечению. С учетом конъюнктуры рынка и собственного опыта наиболее привлекательным было использование в рабочих станциях верхнего уровня Windows NT, а в кон- троллерах нижнего уровня — многоза- дачной операционной системы реаль- ного времени. Конечным результатом должен был быть программный про- дукт, с одной стороны, решающий зада- чи АСУ ТП, а с другой стороны, предо- ставляющий потребителю высокоуров- невые средства проектирования (САПР), позволяющие самостоятельно вносить дополнения и изменения в сис- тему на технологическом уровне. Попытка подыскать подходящую по- купную SCADA-систему не увенчалась успехом. Рассматривались SCADA-сис- темы, подходящие для крупномасштаб- ных управляющих систем с числом сигналов не менее 10000 и доступные на середину 1997 года. Наиболее при- влекательными SCADA-системами бы- ли среди западных Real Flex и Genesis, среди отечественных Trace Mode. При анализе применимости SCADA-систем естественным критерием была воз- можность создания с их помощью уже реализованных на ИВС и отработан- ных со специалистами НВГРЭС техно- логических алгоритмов, систем авто- матизации проектирования, систем уп- равления базами данных (БД), сервис- ных подсистем. Безусловно, от SCADA- системы не требовалось, чтобы с её по- мощью можно было досконально точ- но повторить все формы представле- ния и интерфейсы оператора. При ана- лизе особое внимание уделялось инте- грированности процесса проектирова- ния, наличию средств моделирования, автоматизации установки информаци- онных связей в комплексе, открытости доступа к оперативным и архивным ба- зам данных, возможности гибкой мо- дернизации и поэтапного ввода подси- стем без остановки и перезагрузки контроллеров нижнего уровня. SCADA- система должна была также иметь встроенные средства, обеспечивающие её работу с резервированными струк- турами (дублированными рабочими местами, серверами, контроллерами нижнего уровня, резервированными локальными вычислительными сетя- ми). Как выяснилось, ни одна из проана- лизированных SCADA-систем не предо- ставляла достаточных и адекватных за- даче средств проектирования и обще- системного обеспечения, не говоря уже о готовых технологических подсисте- мах и технологических САПР. Для до- стижения цели можно было бы взять SCADA-систему за основу и дополнить её собственным программным обеспе- чением. Однако в то время эти системы не позволяли встраивать нештатные программные средства пользователя, за исключением драйверов нижнего уров- ня для управления устройствами сопря- жения с объектом. Иными словами, покупные SCADA-си- стемы по состоянию на 1997 год можно было использовать только так, «как они есть». С самого начала создания АСУ ТП для получения положительного эффек- та необходимо, несмотря на рекламные обещания, четко понимать, что универ- сальная покупная SCADA-система явля- ется только инструментом, в большей или меньшей степени автоматизирую- щим процесс создания АСУ ТП, от раз- витости и открытости которого зависит полнота реализации технологических алгоритмов и достижимая степень авто- матизации. Немаловажным фактором при приня- тии решения в пользу того или иного SCADA-пакета являлось наличие приме- ров успешно реализованных с его по- мощью проектов крупномасштабных АСУ ТП в России. Определёнными сдерживающими факторами к применению западных SCADA-систем являются большой объ- ем работ по освоению, апробации и адаптации, опасение остаться с дорого- стоящим пакетом один на один ввиду невозможности получения оператив- ной технической поддержки на этапах освоения и внедрения, а также высокая стоимость, не гарантирующая положи- тельного результата. Пакет Trace Mode как инструмент для разработки детально анализировался по версии 4.20. Кроме перечисленных, были выявлены следующие ограниче- ния в применении пакета: ● неудобная для проектирования ка- нальная организация информацион- ных и управляющих потоков; ● отсутствие реальной интегрирован- ности пакета, ориентированной на распределённые АСУ ТП, требует множества трудоемких ручных опе- раций; ● заложенная идеология не допускает проектирования и добавления новых технологических компонентов и по- этапного ввода подсистем без остано- ва и перезагрузки комплекса; ● отсутствуют САПР для проектирова- ния технологических подсистем (та- ких как защиты, регуляторы и др.), а предоставляемые пакетом средства практически не позволяют пользова- телю самостоятельно разработать их с реализацией требуемого объема функций САПР; ● монитор реального времени, работа- ющий в контроллерах нижнего уров- ня под MS-DOS в незащищённом ре- жиме, не обеспечивает достаточной надежности; ● отсутствуют инструментальные сред- ства для мониторинга и отладки про- граммного обеспечения контролле- ров нижнего уровня; ● наличие большого числа ошибок и недоработок. Таким образом, в результате рассмот- рения возможных вариантов был вы- бран путь дальнейшего развития и со- вершенствования SCADA-системы соб- ственной разработки, получившей на- звание «Венец НВ». При этом в понятие CИСТЕМНАЯ ИНТЕГРАЦИЯ ЭНЕРГЕТИКА 53 3/99