Genesis32

  • 23 нояб. 2010 г.
  • 3768 Слова
Оглавление

Введение 3
OPC – стандарт взаимодействия программных средств в промышленной автоматизации 4
Что такое GENESIS32? 5
GraphWorX32 6
Универсальная архитектура OPC 7
Встроенный Microsoft Visual Basic for Applications 5.0 8
Обширный набор мощных средств разработки графических форм отображения 8
Возможность встраивания элементов управления ActiveX и объектов OLE 9Высокопроизводительные средства анимации 10
Библиотека встроенных символов технологической и деловой графики 11
TrendWorX32 12
Представление контролируемых параметров в реальном масштабе времени 13
Конфигурирование трендов во время исполнения 14
Архивирование значений контролируемых параметров 15
Вывод графиков на печатающее устройство 17
AlarmWorX32 17
Настройка параметров аварийных событий 18Персональное планирование оповещения 19
Голосовое оповещение персонала об аварийных ситуациях 19
Отображение информации об аварийных и других событиях 20
Системное администрирование и управление правами доступа 22
Среда редактирования сценарных процедур VBA Scripting 23
Поддержка аппаратуры. Серверы OPC 24
Заключение 26
Список литературы 27

Введение

Курсовой проект содержит общиесведения о GENESIS32 — комплекте инструментальных средств фирмы ICONICS для создания программного обеспечения верхнего уровня АСУ ТП, который основан на новейшем открытом стандарте взаимодействия аппаратуры и программных средств разных производителей OPC (OLE for Process Control).
Обычно системный интегратор или конечный пользователь, приступая к разработке прикладного программного обеспечения(ППО) для создания системы управления, выбирает один из следующих путей:
_ программирование с использованием "традиционных" средств (традиционные языки программирования, стандартные средства отладки и пр.);
_ использование существующих, готовых (COTS Commercial Off The Shelf) инструментальных проблемно-ориентированных средств.
Безусловно, нет ничего лучше качественного, хорошо отлаженного ППО,написанного высококвалифицированным программистом специально для некоторого проекта. Но следующую задачу этот программист вынужден решать опять практически с нуля. Процесс создания ППО для сложных распределенных систем становится недопустимо длительным, а затраты на его разработку очень высокими. Сегодня, в условиях всё более возрастающей доли ППО в затратах на создание конечной системы и, соответственно, всёбольшей интенсификации труда программистов, вариант с непосредственным программированием относительно привлекателен лишь для простых систем или небольших фрагментов большой системы, для которых нет стандартных решений (не написан, например, подходящий драйвер) или они не устраивают по тем или иным причинам в принципе. В любом случае процесс разработки собственного ППО важно упростить, сократитьвременные и прямые финансовые затраты на разработку ППО, минимизировать затраты труда высококлассных программистов, по возможности привлекая к разработке специалистов в области автоматизируемых процессов.
Современный бизнес в области разработки ПО всё более и более сегментируется и специализируется. Причина проста ПО становится всё более сложным и дорогостоящим. Разработчики операционных систем,разработчики инструментальных средств, разработчики прикладного ПО и т.п., по существу, говорят на разных языках . Таким образом, сама логика развития современного бизнеса в части разработки ППО для конечных систем управления требует использования всё более развитых инструментальных средств типа SCADA-систем (от Supervisory Control And Data Acquisition). Разработка современной SCADA-системы требует большихвложений и выполняется в длительные сроки. И именно поэтому в большинстве случаев разработчикам управляющего ППО, в частности ППО для АСУ ТП, представляется целесообразным идти по второму пути, приобретая, осваивая и адаптируя какой-либо готовый, уже испытанный универсальный инструментарий.
Если такой подход для Вас очевиден или Вы его принимаете, то возникает...
tracking img