Курсовая: SCADA системы - текст курсовой. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Курсовая

SCADA системы

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Курсовая работа
Язык курсовой: Русский
Дата добавления:   
 
Скачать
Архив Zip, 679 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникальной курсовой работы

Узнайте стоимость написания уникальной работы

42 Министерство Общего и Профессионального Образования Российской Федерации Ивановский Государственный Энергетический Университет Кафедра Электроники и Микропроцессорных систем по курсу : «Системы контроля и визуализации» на тему : « SCADA -системы» Выполнил студент гр . 1-34 M Шмаргун А.Н. Проверил : Анисимов А . А. Иваново 2003 Содержание : Введение 2 АСУ ТП и диспетчерское управление 2 Компоненты систем контроля и управления и их назначение 4 Разработка прикладного программного обеспечения СКУ : выбор пути и инструментария 7 Технические характеристики 8 Открытость систем 9 Стоимостные характеристики 10 Эксплуатационные характеристики 10 Графический интерфейс 11 Графические средства InTouch 11 Окна в InTouch 11 Объекты и их свойства 13 Организация взаимодействия с контроллерами 16 Аппаратная реализация связи с устройствами ввода /вывода 17 Серверы ввода /вывода в InTouch 18 Под держиваемые коммуникационные протоколы 18 Особенности адресации в InT ouch 20 Обмен данными с другими приложениями 21 Определение имени доступа в словаре переменных InTouch 22 Тренды в SCADA - системах 25 Тренды в InTouch 25 Архивирование (регистрация ) значений переменной 26 Отображение трендов 26 Изменение параметров архивных трендов в режиме исполнения 29 Система распределенных архивов 29 Встроенные языки программ ирования 30 Скрипты в InTouch 31 Типы скриптов 31 Встроенные функции 32 Функции Quick Functions 36 Разработка графопостроителя в системе InTouch 37 Разработка DDE -сервера 37 Разработка DDE - клиента 39 Список литературы 41 Введение Современная АСУТП (автоматизированная система управления технологическим процесс ом ) представляет собой многоуровневую человеко-машинную систему управления . Создание АСУ сложными технологическими процессами осуществляется с использованием автоматических информационных систем сбора данных и вычислительных комплексов , которые постоянно с овершенствуются по мере эволюции технических средств и программного обеспечения. АСУ ТП и диспетчерское управление Непрерывную во времени картину развития АСУТП можно разделить на три этапа , обусловленные появлением качественно новы х научных идей и технических средств . В ходе истории меняется характер объектов и методов управления , средств автоматизации и других компонентов , составляющих содержание современной системы управления . · Первый этап отражает внедрение систем автоматическо го регулирования (САР ). Объектами управления на этом этапе являются отдельные параметры , установки , агрегаты ; решение задач стабилизации , программного управления , слежения переходит от человека к САР . У человека появляются функции расчета задания и параме т ры настройки регуляторов . · Второй этап - автоматизация технологических процессов . Объектом управления становится рассредоточенная в пространстве система ; с помощью систем автоматического управления (САУ ) реализуются все более сложные законы управления , р ешаются задачи оптимального и адаптивного управления , проводится идентификация объекта и состояний системы . Характерной особенностью этого этапа является внедрение систем телемеханики в управление технологическими процессами . Человек все больше отдаляется от объекта управления , между объектом и диспетчером выстраивается целый ряд измерительных систем , исполнительных механизмов , средств телемеханики , мнемосхем и других средств отображения информации (СОИ ). · Третий этап - автоматизированные системы управлен ия технологическими процессами - характеризуется внедрением в управление технологическими процессами вычислительной техники . Вначале - применение микропроцессоров , использование на отдельных фазах управления вычислительных систем ; затем активное развитие ч еловеко-машинных систем управления , инженерной психологии , методов и моделей исследования операций и , наконец , диспетчерское управление на основе использования автоматических информационных систем сбора данных и современных вычислительных комплексов . От э тапа к этапу менялись и функции человека (оператора /диспетчера ), призванного обеспечить регламентное функционирование технологического процесса . Расширяется круг задач , решаемых на уровне управления ; ограниченный прямой необходимостью управления технологи ч еским процессом набор задач пополняется качественно новыми задачами , ранее имеющими вспомогательный характер или относящиеся к другому уровню управления . Диспетчер в многоуровневой автоматизированной системе управления технологическими процессами получает информацию с монитора ЭВМ или с электронной системы отображения информации и воздействует на объекты , находящиеся от него на значительном расстоянии с помощью телекоммуникационных систем , контроллеров , интеллектуальных исполнительных механизмов . Основой, необходимым условием эффективной реализации диспетчерского управления , имеющего ярко выраженный динамический характер , становится работа с информацией , т . е . процессы сбора , передачи , обработки , отображения , представления информации . От диспетчера уже тр ебуется не только профессиональное знание технологического процесса , основ управления им , но и опыт работы в информационных системах , умение принимать решение (в диалоге с ЭВМ ) в нештатных и аварийных ситуациях и многое другое . Диспетчер становится главны м действующим лицом в управлении технологическим процессом . Говоря о диспетчерском управлении , нельзя не затронуть проблему технологического риска . Технологические процессы в энергетике , нефтегазовой и ряде других отраслей промышленности являются потенциал ьно опасными и при возникновении аварий приводят к человеческим жертвам , а также к значительному материальному и экологическому ущербу . Статистика говорит , что за тридцать лет число учтенных аварий удваивается примерно каждые десять лет . В основе любой ав арии за исключением стихийных бедствий лежит ошибка человека . В результате анализа большинства аварий и происшествий на всех видах транспорта , в промышленности и энергетике были получены интересные данные . В 60 - х годах ошибка человека была первоначально й причиной аварий лишь в 20% случаев , тогда как к концу 80-х доля "человеческого фактора " стала приближаться к 80 %. Одна из причин этой тенденции - старый традиционный подход к построению сложных систем управления , т . е . ориентация на применение новейших технических и технологических достижений и недооценка необходимости построения эффективного человеко - машинного интерфейса , ориентированного на человека (диспетчера ). Таким образом , требование повышения надежности систем диспетчерского управления являет ся одной из предпосылок появления нового подхода при разработке таких систем : ориентация на оператора /диспетчера и его задачи . Концепция SCА DA (Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных ) предопределена всем ходом ра звития систем управления и результатами научно-технического прогресса . Применение SCADA-технологий позволяет достичь высокого уровня автоматизации в решении задач разработки систем управления , сбора , обработки , передачи , хранения и отображения информации. Дружественность человеко-машинного интерфейса (HMI/MMI), предоставляемого SCADA - системами , полнота и наглядность представляемой на экране информации , доступность "рычагов " управления , удобство пользования подсказками и справочной системой и т . д . - повы шает эффективность взаимодействия диспетчера с системой и сводит к нулю его критические ошибки при управлении . Следует отметить , что концепция SCADA, основу которой составляет автоматизированная разработка систем управления , позволяет решить еще ряд задач , долгое время считавшихся неразрешимыми : сократить сроки разработки проектов по автоматизации и прямые финансовые затраты на их разработку . В настоящее время SCADA является основным и наиболее перспективным методом автоматизированного управления сложными динамическими системами (процессами ). Управление технологическими процессами на основе систем SCADA стало осуществляться в передовых западных странах в 80-е годы . Область применения охватывает сложные объекты электро - и водоснабжения , химические , нефтехи мические и нефтеперерабатывающие производства , железнодорожный транспорт , транспорт нефти и газа и др . В России диспетчерское управление технологическими процессами опиралось , главным образом , на опыт оперативно-диспетчерского персонала . Поэтому переход к управлению на основе SCADA-систем стал осуществляться несколько позднее . К трудностям освоения в России новой информационной технологии , какой являются SCADA-системы , относится как отсутствие эксплуатационного опыта , так и недостаток информации о различн ы х SCADA-системах . В мире насчитывается не один десяток компаний , активно занимающихся разработкой и внедрением SCADA-систем . Каждая SCADA-система - это "know-how" компании и поэтому данные о той или иной системе не столь обширны . Большое значение при внед рении современных систем диспетчерского управления имеет решение следующих задач : · выбора SCADA-системы (исходя из требований и особенностей технологического процесса ); · кадрового сопровождения . Выбор SCADA-системы представляет собой достаточно трудну ю задачу , аналогичную принятию решений в условиях многокритериальности , усложненную невозможностью количественной оценки ряда критериев из-за недостатка информации . Подготовка специалистов по разработке и эксплуатации систем управления на базе программног о обеспечения SCADA осуществляется на специализированных курсах различных фирм , курсах повышения квалификации . В настоящее время в учебные планы ряда технических университетов начали вводиться дисциплины , связанные с изучением SCADA-систем . Однако специал ь ная литература по SCADA-системам отсутствует ; имеются лишь отдельные статьи и рекламные проспекты. Компоненты систем контроля и управления и их назначение Многие проекты автоматизированных систем контроля и управления (СКУ ) для боль -шого спектра областей применения позволяют выделить обобщенную схему их реализации , представленную на рис .1. Рис .1. Обобщенная схема системы контроля и управления. Как правило , это двухуровневые системы , так как именно на этих уровнях реализуется непосредственно е управление технологическими процессами . Специфика каждой конкретной системы управления определяется используемой на каждом уровне программно - аппаратной платформой . · Нижний уровень - уровень объекта (контроллерный ) - включает различные датчики для сбо ра информации о ходе технологического процесса , электроприводы и исполнительные механизмы для реализации регулирующих и управляющих воздействий . Датчики поставляют информацию локальным программируемым логическим контроллерам (PLC - Programming Logical Con t rooller), которые могут выполнять следующие функции : o сбор и обработка информации о параметрах технологического процесса ; o управление электроприводами и другими исполнительными механизмами ; o решение задач автоматического логического управления и др . Так как информация в контроллерах предварительно обрабатывается и частично используется на месте , существенно снижаются требования к пропускной способности каналов связи . В качестве локальных PLC в системах контроля и управления различными технологически ми процессами в настоящее время применяются контроллеры как отечественных производителей , так и зарубежных . На рынке представлены многие десятки и даже сотни типов контроллеров , способных обрабатывать от нескольких переменных до нескольких сот переменных. К аппаратно-программным средствам контроллерного уровня управления предъявляются жесткие требования по надежности , времени реакции на исполнительные устройства , датчики и т.д . Программируемые логические контроллеры должны гарантированно откликаться на вне шние события , поступающие от объекта , за время , определенное для каждого события . Для критичных с этой точки зрения объектов рекомендуется использовать контроллеры с операционными системами реального времени (ОСРВ ). Контроллеры под управлением ОСРВ функци онируют в режиме жесткого реального времени . Разработка , отладка и исполнение про-грамм управления локальными контроллерами осуществляется с помощью специализированного программного обеспечения , широко представленного на рынке . К этому классу инструмента льного ПО относятся пакеты типа ISaGRAF (CJ International France), InConrol (Wonderware, USA), Paradym 31 (Intellution, USA), имеющие открытую архитектуру . · Информация с локальных контроллеров может направляться в сеть диспетчерского пункта непосредствен но , а также через контроллеры верхнего уровня (см . рис .). В зависимости от поставленной задачи контроллеры верхнего уровня (концентраторы , интеллектуальные или коммуникационные контроллеры ) реализуют различные функции . Некоторые из них перечислены ниже : o сбор данных с локальных контроллеров ; o обработка данных , включая масштабирование ; o поддержание единого времени в системе ; o синхронизация работы подсистем ; o организация архивов по выбранным параметрам ; o обмен информацией между локальными контролл ерами и верхним уровнем ; o работа в автономном режиме при нарушениях связи с верхним уровнем ; o резервирование каналов передачи данных и др . · Верхний уровень - диспетчерский пункт (ДП ) - включает , прежде всего , одну или несколько станций управления , пр едставляющих собой автоматизированное рабочее место (АРМ ) диспетчера /оператора . Здесь же может быть размещен сервер базы данных , рабочие места (компьютеры ) для специалистов и т . д . Часто в качестве рабочих станций используются ПЭВМ типа IBM PC различных к о нфигураций . Станции управления предназначены для отображения хода технологического процесса и оперативного управления . Эти задачи и призваны решать SCADA - системы . SCADА - это специализированное программное обеспечение , ориентированное на обеспечение и н терфейса между диспетчером и системой управления , а также коммуникацию с внешним миром . Спектр функциональных возможностей определен самой ролью SCADA в системах управления и реализован практически во всех пакетах : o автоматизированная разработка , дающая возможность создания ПО системы автоматизации без реального программирования ; o средства исполнения прикладных программ ; o сбор первичной информации от устройств нижнего уровня ; o обработка первичной информации ; o регистрация алармов и исторических да нных ; o хранение информации с возможностью ее пост-обработки (как правило , реализуется через интерфейсы к наиболее популярным базам данных ); o визуализация информации в виде мнемосхем , графиков и т.п .; o возможность работы прикладной системы с наборами параметров , рассматриваемых как "единое целое " ("recipe" или "установки "). Рассматривая обобщенную структуру систем управления , следует ввести и еще одно понятие - Micro-SCADA. Micro-SCADA - это системы , реализующие стандартные (базовые ) функции , присущие SCADA - системам верхнего уровня , но ориентированные на решение задач автоматизации в определенной отрасли (узкоспециализированные ). В противоположность им SCADA - системы верхнего уровня являются универсальными . · Все компоненты системы управления объед инены между собой каналами связи . Обеспечение взаимодействия SCADA - систем с локальными контроллерами , контроллерами верхнего уровня , офисными и промышленными сетями возложено на так называемое коммуникационное ПО . Это достаточно широкий класс программно г о обеспечения , выбор которого для конкретной системы управления определяется многими факторами , в том числе и типом применяемых контроллеров , и используемой SCADA - системой . Более подробная информация о коммуникационном ПО приведена в главе 2. · Большой объем информации , непрерывно поступающий с устройств ввода /вывода систем управления , предопределяет наличие в таких системах баз данных (БД ). Основная задача баз данных - своевременно обеспечить пользователя всех уровней управления требуемой информацией . Н о если на верхних уровнях АСУ эта задача решена с помощью традиционных БД , то этого не скажешь об уровне АСУ ТП . До недавнего времени регистрация информации в реальном времени решалась на базе ПО интеллектуальных контроллеров и SCADA - систем . В последнее время появились новые возможности по обеспечению высокоскоростного хранения информации в БД . Более подробная информация по базам данных реального времени приведена в главе 6. · Бурное развитие Интернет не могло не привлечь внимание производителей программ ного продукта SCADA. Возможно ли применение Интернет - технологий в системах управления технологическими процессами ? Если да , то какие решения предлагаются в настоящее время компаниями - разработчиками ? Обсуждению этих вопросов посвящена глава 7. Разработка прикладного программного обеспечения СКУ : выбор пути и инструментария Приступая к разработке специализированного прикладного программного обеспечения (ППО ) для создания системы контроля и управления , системный интегратор или конеч ный пользователь обычно выбирает один из следующих путей : · Программирование с использованием "традиционных " средств (традиционные языки программирования , стандартные средства отладки и пр .) · Использование существующих , готовых - COTS (Commercial Of The Shelf) - инструментальных проблемно-ориентированных средств . Для большинства выбор уже очевиден . Процесс разработки ППО важно упростить , сократить временные и прямые финансовые затраты на разработку ППО , минимизировать затраты т руда высококлассных программистов , по возможности привлекая к разработке специалистов-технологов в области автоматизируемых процессов . При такой постановке задачи второй путь может оказаться более предпочтительным . Для сложных распределенных систем процес с разработки собственного ППО с использованием "традиционных " средств может стать недопустимо длительным , а затраты на его разработку неоправданно высокими . Вариант с непосредственным программированием относительно привлекателен лишь для простых систем ил и небольших фрагментов большой системы , для которых нет стандартных решений (не написан , например , подходящий драйвер ) или они не устраивают по тем или иным причинам в принципе . Итак , выбор пути сделан ! Это очень важно , но тогда следует сделать и второй ша г - "определиться " с инструментальными средствами разработки ППО . Программные продукты класса SCADA широко представлены на мировом рынке . Это несколько десятков SCADA - систем , многие из которых нашли свое применение и в России . Наиболее популярные из ни х приведены ниже : · InTouch (Wonderware) - США ; · Citect (CI Technology) - Австралия ; · FIX (Intellution ) - США ; · Genesis (Iconics Co) - США ; · Factory Link (United States Data Co) - США ; · RealFlex (BJ Software Systems) - США ; · Sitex (Jade Softwa re) - Великобритания ; · TraceMode (AdAstrA) - Россия ; · Cimplicity (GE Fanuc) - США ; · САРГОН (НВТ - Автоматика ) - Россия . При таком многообразии SCADA - продуктов на российском рынке естественно возникает вопрос о выборе . Выбор SCADA-системы представл яет собой достаточно трудную задачу , аналогичную поиску оптимального решения в условиях многокритериальности . Ниже приводится примерный перечень критериев оценки SCADA - систем , которые в первую очередь должны интересовать пользователя . Этот перечень не я вляется авторским и давно уже обсуждается в специальной периодической прессе . В нем можно выделить три большие группы показателей : · технические характеристики ; · стоимостные характеристики ; · эксплуатационные характеристики . Технические ха рактеристики Программно-аппаратные платформы для SCADA-систем . Анализ перечня таких платформ необходим , поскольку от него зависит ответ на вопрос , возможна ли реализация той или иной SCADA-системы на имеющихся вычислительных средствах , а также оценка стоимости эксплуатации системы (будучи разработанной в одной операционной среде , прикладная программа может быть выполнена в любой другой , которую поддерживает выбранный SCADA-пакет ). В различных SCADA-системах этот вопрос решен по разному . Так , F a ctoryLink имеет весьма широкий список поддерживаемых программно-аппаратных платформ : Операционная система Компьютерная платформа DOS/MS Windows IBM PC OS/2 IBM PC SCO UNIX IBM PC VMS VAX AIX RS6000 HP-UX HP 9000 MS Windows/NT Системы с реализованны м Windows/NT, в основном на РС-платформе . В то же время в таких SCADA-системах , как RealFlex и Sitex основу программной платформы принципиально составляет единственная операционная система реального времени QNX. Подавляющее большинство SCADA-систем реа лизовано на MS Windows платформах . Именно такие системы предлагают наиболее полные и легко наращиваемые MMI - средства . Учитывая позиции Microsoft на рынке операционных систем (ОС ), следует отметить , что даже разработчики многоплатформных SCADA-систем , та к ие как United States DATA Co (разработчик FactoryLink), приоритетным считают дальнейшее развитие своих SCADA-систем на платформе Windows NT. Некоторые фирмы , до сих пор поддерживавшие SCADA-системы на базе операционных систем реального времени (ОСРВ ), нач а ли менять ориентацию , выбирая системы на платформе Windows NT. Все более очевидным становится применение ОСРВ , в основном , во встраиваемых системах , где они действительно хороши . Таким образом , основным полем , где сегодня разворачиваются главные события г л обального рынка SCADA--систем , стала MS Windows NT/2000 на фоне всё ускоряющегося сворачивания активности в области MS DOS, MS Windows 3.xx/95. Имеющиеся средства сетевой поддержки . Одной из основных черт современного мира систем автоматизации является и х высокая степень интеграции . В любой из них могут быть задействованы объекты управления , исполнительные механизмы , аппаратура , регистрирующая и обрабатывающая информацию , рабочие места операторов , серверы баз данных и т.д . Очевидно , что для эффективного ф ункционирования в этой разнородной среде SCADA-система должна обеспечивать высокий уровень сетевого сервиса . Желательно , чтобы она поддерживала работу в стандартных сетевых средах (ARCNET, ETHERNET и т.д .) с использованием стандартных протоколов (NETBIOS, TCP/IP и др .), а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов (PROFIBUS, CANBUS, LON, MODBUS и т.д .) Этим требованиям в той или иной степени удовлетворяют практически все рассматриваемые SCADA-сист е мы , с тем только различием , что набор поддерживаемых сетевых интерфейсов , конечно же , разный . Встроенные командные языки . Большинство SCADA-систем имеют встроенные языки высокого уровня , VBasic-подобные языки , позволяющие генерировать адекватную реакцию на события , связанные с изменением значения переменной , с выполнением некоторого логического условия , с нажатием комбинации клавиш , а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна . Поддержив аемые базы данных . Одной из основных задач систем диспетчерского контроля и управления является обработка информации : сбор , оперативный анализ , хранение , сжатие , пересылка и т . д . Таким образом , в рамках создаваемой системы должна функционировать база дан ных . Практически все SCADA-системы , в частности , Genesis, InTouch, Citect, используют ANSI SQL синтаксис , который является независимым от типа базы данных . Таким образом , приложения виртуально изолированы , что позволяет менять базу данных без серьезного и зменения самой прикладной задачи , создавать независимые программы для анализа информации , использовать уже наработанное программное обеспечение , ориентированное на обработку данных . Графические возможности . Для специалиста-разработчика системы автоматиза ции , также как и для специалиста - "технолога ", чье рабочее место создается , очень важен графический пользовательский интерфейс . Функционально графические интерфейсы SCADA-систем весьма похожи . В каждой из них существует графический объектно-ориентированн ы й редактор с определенным набором анимационных функций . Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом , а также быстро обновлять изображение на экране , используя средства анимации . Крайне важен т акже вопрос о поддержке в рассматриваемых системах стандартных функций GUI (Graphic Users Interface). Поскольку большинство рассматриваемых SCADA-систем работают под управлением Windows, это и определяет тип используемого GUI. Открытость систем Система является открытой , если для нее определены и описаны используемые форматы данных и процедурный интерфейс , что позволяет подключить к ней "внешние ", независимо разработанные компоненты . Разработка собственных программных модулей . Пере д фирмами-разработчиками систем автоматизации часто встает вопрос о создании собственных (не предусмотренных в рамках систем SCADA) программных модулей и включение их в создаваемую систему автоматизации . Поэтому вопрос об открытости системы является важно й характеристикой SCADA-систем . Фактически открытость системы означает доступность спецификаций системных (в смысле SCADA) вызовов , реализующих тот или иной системный сервис . Это может быть и доступ к графическим функциям , функциям работы с базами данных и т.д . Драйверы ввода-вывода . Современные SCADA-системы не ограничивают выбора аппаратуры нижнего уровня , так как предоставляют большой набор драйверов или серверов ввода-вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня . Сами драйверы разрабатываются с использованием стандартных языков программирования . Вопрос , однако , в том , достаточно ли только спецификаций доступа к ядру системы , поставляемых фирмой-разработчиком в штатном комп л екте (система Trace Mode), или для создания драйверов необходимы специальные пакеты (системы FactoryLink, InTouch), или же , вообще , разработку драйвера нужно заказывать у фирмы-разработчика . Разработки третьих фирм . Многие компании занимаются разработкой драйверов , ActiveX-объектов и другого программного обеспечения для SCADA-систем . Этот факт очень важно оценивать при выборе SCADA-пакета , поскольку это расширяет область применения системы непрофессиональными программистами (нет необходимости разрабатыва т ь программы с использованием языков С или Basic). Стоимостные характеристики При оценке стоимости SCADA-систем нужно учитывать следующие факторы : · стоимость программно-аппаратной платформы ; · стоимость системы ; · стоимость освоен ия системы ; · стоимость сопровождения. Эксплуатационные характеристики Показатели этой группы критериев наиболее субъективны . Это тот самый случай , когда лучше один раз увидеть , чем семь раз услышать . К этой группе можно отнести : · удобство интерфейса среды разработки - "Windows - подобный интерфейс ", полнота инструментария и функций системы ; · качество документации - ее полнота , уровень русификации ; · поддержка со стороны создателей - количество инсталляций , дилерская сеть , обуч ение , условия обновления версий и т . д . Если предположить , что пользователь справился и с этой задачей - остановил свой выбор на конкретной SCADA - системе , то далее начинается разработка системы контроля и управления , которая включает следующие этапы : · Разработка архитектуры системы автоматизации в целом . На этом этапе определяется функциональное назначение каждого узла системы автоматизации . · Решение вопросов , связанных с возможной поддержкой распределенной архитектуры , необходимостью введения узлов с "горячим резервированием " и т.п . · Создание прикладной системы управления для каждого узла . На этом этапе специалист в области автоматизируемых процессов наполняет узлы архитектуры алгоритмами , совокупность которых позволяет решать задачи автоматизации. · Приведение в соответствие параметров прикладной системы с информацией , которой обмениваются устройства нижнего уровня (например , программируемые логические контроллеры - ПЛК ) с внешним миром (датчики технологических параметров , исполнительные устройств а и др .) · Отладка созданной прикладной программы в режиме эмуляции . В последующих главах на примере двух известных и хорошо зарекомендовавших себя SCADA-систем (InTouch и Citect) рассмотрены основные компоненты , функции и возможности систем диспетчерског о управления и сбора данных . Графический интерфейс Средства визуализации - одно из базовых свойств SCADA - систем . В каждой из них существует графический объектно - ориентированный редактор с определенным набором анимационных функ ций . Используемая векторная графика дает возможность осуществлять широкий круг операций над выбранным объектом . Объекты могут быть простыми (линии , прямоугольники , текстовые объекты и т . д .) и сложные . Возможности агрегирования сложных объектов в разных S C ADA - системах различны . Все SCADA - системы включают библиотеки стандартных графических символов , библиотеки сложных графических объектов , обладают целым рядом других стандартных возможностей. Но , тем не менее , каждая SCADA - система по-своему уникальна и , несмотря на поддержание стандартных функций , обладает присущими только ей особенностями . При рассмотрении графических возможностей SCADA - систем InTouch и Citect предполагается обратить внимание не только на возможности инструментариев по созданию граф и ческих объектов , но и на другие предоставляемые пользователю услуги , облегчающие и ускоряющие процесс разработки приложений (проектов ). Графические средства InTouch Компоненты среды разработки InTouch: · WindowMaker - инструменталь ная среда разработки приложений ; · Application Explorer - представление приложения в иерархическом виде с доступом к любому компоненту приложения и многим часто используемым командам и функциям WindowMaker. Проект , созданный в пакете InTouch, представляе т собой набор окон (Window) с различными графическими и текстовыми объектами. Окна в InTouch Свойства каждого окна (наличие заголовка , цвет фона , размеры и т . д .) определяются при его создании . Создание нового окна производится в ср еде разработки WindowMaker щелчком по иконке панели инструментов General или командой File/New Window. На экране появится диалог Window Properties (Свойства окна , рис . 2). Рис . 2. Диалог Window Properties (Свойства окна ). Каждое ок но должно иметь свое имя для его идентификации в приложении (Name). Цвет фона создаваемого окна выбирается из цветовой палитры , вызываемой на экран щелчком по окошку Window Color. В поле Comment можно ввести комментарий , связанный с этим окном (необязат е льно ). Эта информация нужна только для документирования и не используется приложением . InTouch предлагает три типа окон (Window Туре ): · Replace (заменяющее ) - закрывает все существующие окна , перекрываемые им при появлении на экране , включая окна типа Popup и другие окна типа Replace. · Overlay (перекрывающее ) - появляется поверх всех отображаемых в текущий момент окон . Когда окно типа Overlay закрывается , все скрываемые им окна восстанавливаются . Щелчок мыши по любому видимому участку лежащего ниже о кна приводит к переходу его на передний план . · Popup (всплывающее ) - похоже на окно типа Overlay, только оно всегда остается поверх всех других открытых окон . Окно закрывается после соответствующей команды пользователя . Выбор типа создаваемого окна прои зводится включением соответствующей кнопки в поле Window Туре . В поле Frame Style (стиль обрамления ) выбирается необходимый стиль обрамления окна : · Single - окно с рамкой , допускается заголовок ; · Double - окно с рамкой без заголовка ; · None - окно бе з рамки и заголовка . Чтобы у окна была полоса с заголовком , где выводится имя окна , включают опцию Title Bar. Эта полоса также служит для перемещения окна при захвате ее мышью . При выборе этой опции отключатся опции Double и None для стиля обрамления . Дл я возможности изменения размеров окна , когда оно откроется в WindowMaker, следует выбрать опцию Size Controls (управление размером ). В группе полей Dimentions определяются текущие размеры и положение окна на рабочем поле : · X Location - расстояние в пикс елях между левым краем рабочего поля WindowMaker и левым краем описываемого окна ; · Y Location - расстояние в пикселях между верхним краем рабочего поля WindowMaker и верхним краем описываемого окна ; · Window Width - ширина окна в пикселях ; · Window Hei ght - высота окна в пикселях . По умолчанию при создании нового окна эти параметры примут значения предыдущего (последнего ) созданного окна. Кнопка Scripts (скрипты ) дает возможность войти в диалог Window Script для создания оконного сценария . Для унифика ции внешнего вида окон приложения и сокращения сроков разработки приложений InTouch предлагает несколько приемов . Один из таких приемов - дублирование окон . Создание копий окон выполняется командой File/ Save Window As. Для быстрого доступа к этой команде можно воспользоваться меню правой кнопки мыши (см . ниже ). Второй прием , который также позволяет экономить время разработки приложения - импорт окон . Можно повторно использовать все ранее созданные окна , объекты и скрипты . Чтобы импортировать окна из друг ого InTouch - приложения , необходимо воспользоваться командой File/ Import. Интерфейс WindowMaker с открытым окном представлен на рис . 3. Рис . 3. Интерфейс WindowMaker. Сверху экрана расположена строка меню , включающая опции для работы с окнами , редактирования и выравнивания объектов в окне , настройки инструментариев , текста , толщины и стиля линий и т . д . Слева от рабочего поля видно меню Application Explorer, которое может быть выведено в интерфейс WindowMaker или закрыто нажат ием соответствующей иконки инструментария. Объекты и их свойства Простые объекты . WindowMaker поддерживает четыре базовых типа простых объектов : линии , заполненные контуры , текст и кнопки . Каждый из этих простых объектов имеет свой ства , влияющие на его внешний вид . Такими свойствами являются цвет линии , цвет заполнения , высота , ширина , ориентация и т . д ., и они могут быть статическими или динамическими . · Линия - это объект , представляющий собой один или несколько связанных отрезко в . Толщина линии и ее стиль являются статическими свойствами линии , присваиваемыми ей во время создания , и лишь цвет линии может быть связан с анимационной функцией . · Заполненный контур (прямоугольник , скругленный прямоугольник , круг , эллипс , многоугольн ик ) представляет собой двухмерный объект . К динамическим свойствам такого объекта относятся цвет контурной линии , цвет заполнения , насыщенность цвета заполнения , высота , ширина , расположение , видимость и ориентация . · Текст представляет собой последовател ьность символов . К статическим свойствам текста относятся тип шрифта , его размер , выделение , курсив , подчеркивание , выравнивание . Анимационные свойства шрифта - цвет , видимость и расположение . · Кнопка - часто используемый объект при создании операторских интерфейсов . С кнопками могут быть связаны функции различных типов . Нажатие кнопки может вызвать выполнение скриптов , кнопкой можно производить ввод аналоговых и дискретных величин и т . д . Текст на кнопке редактируется с помощью команды Special/Substitut e Strings... При этом текстовое поле может содержать только одну строку . Один и тот же объект может иметь набор различных динамических свойств . Комбинации этих свойств предоставляют возможность создавать на экране в режиме исполнения (Runtime) практичес к и любые динамические эффекты . Для установки динамических свойств надо прежде всего вызвать на экран диалог их выбора (рис .4). Это достигается командой Special/Animation Link или двойным щелчком левой кнопки мыши на объекте . Рис . 4. Диалог выбора динамических свойств объекта. Все динамические связи можно разделить на две группы : Touch Links (левая колонка ) и Display Links (три колонки справа ). С помощью свойств Touch Links выполняется какой - либо ввод в систему . Свойства Display L inks осуществляют вывод информации на экран дисплея . Нажатие на любую клавишу диалога (рис . 4) вызывает появление нового диалога для определения соответствующего свойства объекта . Количество диалогов соответствует количеству динамических свойств (кнопок ) диалога выбора . Все диалоги различны , но большинство из них имеет общие характеристики : · окно типа объекта ; · одинаковую палитру цветов ; · быстрый вызов словаря переменных ; · быстрый доступ к полям переменных ; · поддержку правой кнопки мыши в полях Tagname (имя переменной ) и Expression (выражение ). На рис .5 приведен диалог для определения свойств объекта (кнопки ), управляющего значением дискретной переменной . Рис .5. Диалог определения свойств кнопки. Завершение работы с д иалогом производится нажатием кнопки Ok. Если переменная поля Tagname была ранее определена в словаре переменных данного приложения , пользователь возвращается в диалог выбора динамических свойств объекта (рис . 4). Можно либо продолжить определение других д инамических свойств для данного объекта , либо , нажав Ok, вернуться на поле разработки окна приложения . Сложные объекты . · Символ - это некоторая комбинация простых объектов , которые обрабатываются как один объект . Любое изменение статических или динамиче ских свойств символа влияет на все составляющие символа . Например , если создать символ "насос " из двух кругов и двух прямоугольников и присвоить ему динамическое свойство Fill Color (цвет заполнения ), то это свойство будет распространяться на все четыре п р остых объекта . Различные объекты символа могут иметь разные значения одного и того же свойства , если они были присвоены этим объектам до объединения в символ . Bitmap - объекты , кнопки , компоненты не могут быть включены в состав символа . · Компонент - это совокупность двух или более объектов , символов или других компонентов , образующих единый элемент . Они создаются путем выбора двух и более объектов , символов или компонентов и последующего запуска команды Arrange/Make Cell. Компоненты реализуют пространст в енную взаимосвязь между составляющими их графическими элементами . Каждая составляющая компонента может иметь свои собственные динамические свойства . Компоненты используются для таких виртуальных устройств , как панель управления контроллером , движковый рег у лятор и т . д . Компонент не может менять свой размер , ему нельзя присваивать динамические свойства (внутри компонента есть объекты и символы со своими динамическими свойствами ). Нельзя изменять и статические свойства (внешний вид ). Для изменения статическ и х и динамических свойств компонента его надо разобрать на составные части командой Arrange/Break Cell. Однако компоненты можно дублировать , копировать , вставлять , выравнивать , перемещать и т . д . Мастер-объект - это предварительно созданный компонент с опр еделенными статическими и динамическими свойствами , находящийся в библиотеке мастер-объектов (Wizards) и доступный для многократного применения . Но , в отличие от компонента , динамические свойства которого настраиваются для каждой составляющей отдельно до о бъединения в компонент , динамические свойства мастер-объекта быстро настраиваются с помощью специализированного диалога . Другими словами , фирма Wonderware провела большую работу и создала огромное количество мастер-объектов (несколько тысяч ), определив дл я каждого из них механизм быстрой настройки статических и динамических свойств . Все эти мастер-объекты разделены на большое количество групп и размещены в соответствующей библиотеке . Доступ к ней осуществляется нажатием иконки Wizard в интерфейсе WindowMak e r, что вызывает появление на экране диалога Wizard Selection (Выбор мастер-объекта . В левой части диалога - список групп мастер-объектов , включающий такие категории , как Buttons (кнопки ), Sliders (ползунковые регуляторы ), Switches (переключатели ) и т . д . В правой части диалога приведены все мастер-объекты выбранной в данный момент группы . Двойной щелчок по требуемому мастер-объекту возвращает пользователя в окно разработки приложения . Курсор принимает форму уголка с символом . Наконец , щелчок мыши на своб о дном месте окна приводит к появлению мастер-объекта в окне приложения . Для его конфигурирования (определения динамических свойств ) следует дважды щелкнуть на мастер-объекте . Например , двойной щелчок по кнопке Momentary Button (кн опка запуска ), предварительно вставленной в окно приложения , выводит на экран диалог конфигурирования этой кнопки (рис .6). Достаточно ввести имя дискретной переменной , желаемый текст на кнопке , отметить несколько опций и нажать Ok. Инструмент Bitmap инст рументальной панели рисования позволяет копировать и встраивать в приложение InTouch растровые объекты (совокупность точек ). С помощью него создается "контейнер " для последующей вставки объекта из папки обмена Windows либо файлов с расширением .BMP, .JPG, .PCX, .TGA. Для WindowMaker растровое изображение является единым объектом . Невозможно ни анимировать его отдельные части , ни вставлять Bitmap - объекты в символы (можно вставлять в компоненты ). Такой объект можно развернуть на рабочем поле на 90, 180, 270 , 360 градусов , а также определить для него цвет "прозрачности ", чтобы через него можно было видеть и другие объекты . · Тренды . InTouch предлагает пользователю два сложных объекта типа тренд : тренд реального времени и исторический (архивный ) тренд . Эти о б ъекты позволяют отображать в виде графиков значения данных реального времени (4 пера ) и архивных данных (8 перьев ). Оба типа трендов создаются при использовании специальных инструментов панели рисования окна WindowMaker с последующим конфигурированием . По д робная информация по созданию и конфигурированию трендов будет приведена в соответствующей главе . Подводя итог описанию графических средств пакета InTouch, следует отметить , что фирма Wonderware в этом плане предлагает потребителю хороший набор возможно с тей : · богатый , традиционный для пользователей Windows инструментарий ; · меню правой кнопки мыши для окон , графических объектов и полей диалогов ; · широкий спектр динамических свойств объектов ; · огромную библиотеку мастеров-объектов (Wizards). Организация взаимодействия с контроллерами Современные SCADA - системы не ограничивают выбора аппаратуры нижнего уровня (контроллеров ), так как предоставляют большой набор драйверов или серверов ввода /вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня . Для подсоединения драйверов ввода /вывода к SCADA - системе в настоящее время используются следующие механизмы : · ставший стандартом de facto динамический обм ен данными (DDE); · собственные протоколы фирм-производителей SCADA - систем , реально обеспечивающие самый скоростной обмен данными ; · новый OPC - протокол , который , с одной стороны , является стандартным и поддерживается большинством SCADA - систем , а с другой стороны , лишен недостатков протоколов DDE. Изначально протокол DDE применялся в первых человеко - машинных интерфейсах в качестве механизма разделения данных между прикладными системами и устройствами типа ПЛК (программируемые логические контроллер ы ). Для преодоления недостатков DDE, прежде всего для повышения надежности и скорости обмена , разработчики предложили свои собственные решения (протоколы ), такие как AdvancedDDE или FastDDE - протоколы , связанные с пакетированием информации при обмене с П Л К и сетевыми контроллерами . Но такие частные решения приводят к ряду проблем : · для каждой SCADA - системы пишется свой драйвер для поставляемого на рынок оборудования ; · в общем случае , два пакета не могут иметь доступ к одному драйверу в одно и то же в ремя , поскольку каждый из них поддерживает обмен именно со своим драйвером . Основная цель OPC стандарта (OLE for Process Control) заключается в определении механизма доступа к данным с любого устройства из приложений . OPC позволяет производителям оборудов ания поставлять программные компоненты , которые стандартным способом обеспечат клиентов данными с ПЛК . При широком распространении OPC - стандарта появятся следующие преимущества : · OPC позволят определять на уровне объектов различные системы управления и контроля , работающие в распределенной гетерогенной среде ; · OPC - устранят необходимость использования различного нестандартного оборудования и соответствующих коммуникационных программных драйверов ; · у потребителя появится больший выбор при разработке приложений . С OPC - решениями интеграция в гетерогенные (неоднородные ) системы становится достаточно простой . Применительно к SCADA-системам OPC серверы , расположенные на всех компьютерах системы управления производственного предприятия , стандартным спос обом могут поставлять данные в программу визуализации , базы данных и т . п ., уничтожая , в некотором смысле , само понятие неоднородной системы. Аппаратная реализация связи с устройствами ввода /вывода Для организации взаимодействия с к онтроллерами могут быть использованы следующие аппаратные средства : · COM - порты . В этом случае контроллер или объединенные сетью контроллеры подключаются по протоколам RS-232, RS-422, RS-485. · Сетевые платы . Использование такой аппаратной поддержки возможно , если соответствующие контроллеры снабжены интерфейсным выходом на Ethernet. · Вставные платы . В этом случае протокол взаимодействия определяется платой и может быть уникальным . В настоящее время предлагаются реализации в стандартах ISA, PCI, Co mpactPCI. Прикладные протоколы , используемые для организации взаимодействия с контроллерами , оставлены за границей этой книги. Серверы ввода /вывода в InTouch При функционировании InTouch - приложения в реальном времени информация о бо всех его переменных хранится в базе данных . К такой информации относятся имя переменной , ее тип , минимальное и максимальное значения , уставки , способ отображения (дисплей , журнал ) и т . д ., а также информация о коммуникационных каналах , по которым проис х одит обмен данными между технологическим процессом и приложением. InTouch - приложение поддерживает взаимодействие с DDE и OPC-серверами . Именно на организации взаимодействия с ними и остановимся ниже. Поддерживаемые коммуникационные протоколы DDE (Dynamic Data Exchange - динамический обмен данными ) представляет собой коммуникационный протокол , разработанный компанией Microsoft для обмена данными между различными Windows - приложениями . Этот протокол реализует взаимосвязи типа клиент - сервер между двумя одновременно исполняющимися программами . В InTouch поддерживается также пакетированный DDE - обмен - FastDDE. Применение последнего заметно повышает эффективность и производительность обмена данными благодаря уменьшению общего колич е ства DDE - пакетов , которыми клиент и сервер обмениваются между собой . Но принципиальные недостатки , связанные с надежностью и зависимостью от количества загруженных в текущий момент приложений Windows, остались . Необходимость в появлении более совершенно г о технологичного протокола созрела ! Но следует отметить , что отказ от DDE-механизма происходит не мгновенно хотя бы потому , что в мире наработано большое количество DDE - серверов . С целью расширения возможностей стандартного протокола DDE на локальную с е ть компания Wonderware предложила NetDDE. Он позволяет приложениям , запущенным на объединенных в локальную сеть компьютерах , вести DDE - обмен . Позднее NetDDE лицензируется компанией Microsoft и поставляется в дистрибутивном пакете Windows. Следует отмети т ь и то , что NetDDE допускает обмен информацией между приложениями на IBM PC и приложениями на машинах другого типа с операционной системой VMS или UNIX. Компания Wonderware предлагает и инструментальные средства для разработки DDE-серверов , в том числе и д ля не -Windows-платформ . Протокол SuiteLink был специально разработан фирмой Wonderware для того , чтобы удовлетворить таким требованиям , как целостность данных , высокая производительность и простота диагностики . В основе протокола SuiteLink лежит протокол TCP/IP. SuiteLink не является заменой протоколам DDE, FastDDE и NetDDE. Новый протокол разработан для поддержания быстродействующих промышленных систем и обладает следующими характеристиками : · Передача данных осуществляется в формате VTQ (Value, Time, Qu ality - значение , время , качество ), в соответствии с которым каждая пересылаемая клиенту единица информации сопровождается метками времени и качества данных . · Благодаря системному монитору операционной системы Windows NT (Performance Monitor) стал возмож ным расширенный анализ производительности по передаче данных , степени загрузки сервера , степени потребления ресурсов компьютера и сети , что особенно важно для проектирования и сопровождения больших распределенных промышленных сетей . · Поддержка обмена дан ными между приложениями происходит независимо от того , исполняются ли эти приложения на одном узле сети или на разных . Для реализации функций OPC - клиента Wonderware предлагает OPCLink - сервер , преобразующий OPC в SuitLink - протокол . В материалах , пре дложенных компанией Wonderware, отмечается , что большинство реализованных OPC-серверов создают для каждого подключаемого к серверу клиента новый канал связи или нить . Для текущей обработки каждого клиента сервер должен переключаться между нитями . Каждая н и ть использует DCOM (Distributed Component Object Model) для организации обмена данными , и DCOM также управляет переключением нитей . В итоге возможна достаточно низкая производительность в сети . Тесты , проведенные фирмой Wonderware, показали , что при обсл у живании OPC-сервером 7 клиентов (при передаче 4 целых чисел в режиме обновления ) сервер на 95% занимал ресурсы CPU. Это означает , что ресурсы компьютера практически целиком были заняты переключением нитей и DCOM- процедурами . Поэтому на текущем этапе пар а метры производительности протокола SuiteLink превосходят параметры DCOM. Поставляемый в комплекте FactorySuite (Wonderware) OPCLink Server обеспечивает прием информации с OPC- сервера и передачу ее по протоколу SuiteLink в SCADA - систему InTouch и наобор о т . Именно OPCLink Server рекомендуется устанавливать на одном узле с OPC- сервером , чтобы для сетевых передач использовался SuiteLink- протокол , а не DCOM (рис .7). Рис . 7. Использование SuiteLink - протокола в SCADA - системах. Все описанные ниже особенности адресации распространяются и на OPC-серверы с одним лишь ограничением . При разработке InTouch - приложения создается канал связи с OPCLink - сервером (как с любым другим SuiteLink - сервером ). Но рекоме ндуется использовать встроенный в InTouch OPC Browser для упрощения выбора параметров конфигурации подключаемого OPC - сервера. Особенности адресации в InTouch В InTouch вышеуказанные механизмы положены в основу обмена данными между приложениями InTouch и DDE и SuiteLink - серверами , которые , в свою очередь , связаны коммуникационными каналами с устройствами нижнего уровня (контроллерами ). Так как InTouch предназначен для разработки и поддержания интерфейса сбора данных и диспетчер с кого управления (рис .8), среда исполнения WindowViewer при взаимодействии с контроллерным уровнем выступает , как правило , в роли приложения - клиента (узел View), запрашивающего данные у приложения - сервера (I/O Server). Рис .8. Обмен данными между InTouch - приложением и технологическим процессом . Через сервер ввода /вывода InTouch - приложение имеет возможность читать данные из контроллера или писать данные в него . Процесс обмена информацией InTouch - при ложения с контроллером можно представить следующей схемой Здесь и встает один из главных вопросов организации обмена с серверами ввода /вывода : каким образом обеспечить клиенту доступ к запрашиваемой им информации ? Для организации обмена с приложением оп р еделяются каналы обмена или каналы доступа , характеризующиеся следующими параметрами : · имя узла (Node Name); · имя приложения ( Application Name ); · имя группы данных или топик (Topic Name ); · имя элемента ( Item Name ). Имя приложения - это имя пр ограммы Windows, которая выполняет функции DDE, FastDDE, SuiteLink - серверов . Имя группы данных (топика ) определяется при конфигурировании сервера на прием или передачу группы данных , которыми сервер будет обмениваться с контроллером или объединенными в с еть контроллерами . Определенные параметры группы (топика ) зависят от конкретного сервера (поэтому рекомендуется изучать документацию и справочную систему выбранного сервера ). Например , при использовании Modbus - сервера , позволяющего обеспечить взаимодейс т вие с контроллером Modicon Micro 984 PLC, в качестве имени приложения (Application Name) должен быть Modbus, в качестве имени группы или топика (Topic Name) вводится любое имя (текстовая строка ), но среди необходимых параметров группы из списка выбирается имя контроллера Modicon 984 PLC. А в качестве имени элемента (Item Name) следует выбирать название конкретного регистра контроллера (например , 40001 для контроллера Modicon Micro 984). Чтобы узнать правильный синтаксис имени элемента , необходимый для конк р етных PLC, нужно обратиться к руководству по соответствующему серверу . Определены все компоненты коммуникационного канала . С учетом введенных понятий схема обмена информацией для рассмотренного выше примера будет выглядеть следующим образом (рис .9). Рис . 9. Обмен информацией на примере Modbus - сервера. Фирма Wonderware предлагает DDE и SuiteLink - серверы , которые поддерживают более 800 типов контроллеров основных производителей и различные протоколы. Ес ли нужного драйвера все-таки нет , можно воспользоваться пакетом разработки драйверов FactorySuite Toolkit. Схемы , приведенные на рис . 9, интерпретируют стандартный обмен информацией между узлом (приложением ) View и контроллером (ПЛК ) в режиме сбора данных и управления . В этом режиме , как уже было сказано выше , приложение View - клиент по определению. Обмен данными с другими приложениями Но приложения InTouch могут взаимодействовать не только между собой , но и с другими Windows - при ложениями . Одним из известных примеров такого приложения является Microsoft Excel. InTouch - приложение может считывать и записывать какие - либо значения в любую клетку открытой в Excel электронной таблицы . Аналогично и программа Excel может читать и зап и сывать информацию в базу данных InTouch - приложения . Данный механизм обеспечивает одновременное обновление данных в одном приложении при изменении их значений в другом . Если клиентом (приложением , запрашивающим информацию ) по - прежнему является узел V i ew, то Excel - это приложение , поставляющее информацию (сервер ). В качестве группы или топика (Topic) тогда будет выступать имя таблицы Excel, а элемент обмена информацией - ячейка в таблице Excel (табл .2.1, вариант 1). Когда клиентом является приложени е Excel, а сервером - приложение View, группой в этом случае всегда является словарь переменных InTouch (база данных ) с именем Tagname. Элементом обмена будет элемент базы данных - имя переменной (табл .2.1, вариант 2). Таблица 2.1. Приложение-клиент Прилож ение-сервер Группа Элемент View Excel Sheet1.XLS R1C1 Excel View Tagname R_Level В случае обмена данными по сети с использованием пакета Wonderware NetDDE необходимо к трехуровневой структуре адреса добавить четвертый уровень - имя удаленного узла се ти (Node Name). Подводя итог вышесказанному , следует подчеркнуть , что информация по доступу к данным устройств ввода /вывода или других приложений должна храниться в приложении (в словаре переменных ). И разработчику в InTouch-приложении важно подключиться к вышеописанному каналу доступа . Для этого в InTouch необходимо определить имя доступа Access Name и связать его с переменной приложения. Определение имени доступа в словаре переменных InTouch В InTouch - приложениях вся информация о переменных приложения хранится в Tagname Dictionary (Словарь переменных ). Это не что иное , как база данных реального времени - один из центральных компонентов InTouch. При определении переменной в базе данных InTouch запрашивает определенную информацию о каждой переменной , например , имя переменной , ее тип , имя доступа и т . д . В пакете InTouch используется два базовых типа переменных - Memory (внутренние ) и I/O (переменные ввода /вывода ). Переменные типа Memory могут быть использованы для создания различ н ых системных констант , моделирования элементов системы управления и в вычисляемых переменных , доступных другим Windows - программам . Все переменные , которые получают или передают свое значение другой Windows - программе , должны иметь тип ввода /вывода (I/ O ). В эту категорию попадают переменные , которые посредством канала доступа (Access Name) принимают или отправляют данные из /в серверов ввода /вывода , других приложений InTouch, других программ Windows. Определение новой переменной в базе данных InTouch, к а к и просмотр , и модификация атрибутов уже существующих переменных , производится в диалоге Tagname Dictionary (рис .10). Доступ к этому диалогу осуществляется командой Speс ial/Tagname Dictionary в окне среды разработки WindowMaker или двойным щелчком по ико н ке Tagname Dictionary в окне Application Explorer. Рис . 10. Диалог Tagname Dictionary (Словарь переменных ). Поля Tagname и Comment предназначены для ввода имени переменной и соответствующего комментария . По умолчанию включена опция Read/Write (чтение /запись ). Можно отметить и опцию Read Only, если в процессе исполнения WindowViewer должен только читать значение переменной . В любое время в режиме проектирования можно открыть список переменных приложения ще лчком по кнопке Select для выбора соответствующей переменной , просмотра списка или модификации атрибутов . Диалог Select Tag (выбор переменной ) представлен на рис .11. Рис . 11. Диалог Select Tag (выбор перем енной ). Для каждой переменной в этом диалоге приведена следующая информация : имя переменной , ее тип , имя доступа , группа аларма и комментарий . Группа алармов (Alarm group, рис .11) для переменной определяется в диалоге , вызываемом нажатием кнопки Group д иалога Tagname Dictionary. Все , что касается алармов , рассматривается в соответствующем разделе ниже . Выбор типа переменной осуществляется в диалоге Tag Types (тип переменной , рис . 12), вызываемом на экран нажатием кнопки Туре диалога Tagname Dictionary. Рис . 12. Диалог Tag Types (тип переменной ). В этом диалоге представлен полный список основных типов переменных InTouch. Выбор завершается отметкой соответствующей опции и щелчком по Ok. После выбора т ипа переменной программа возвращает пользователя в диалог Tagname Dictionary (Словарь переменных ). При этом будет открыт и дополнительный диалог подробного описания переменной , содержание которого зависит от выбранного типа . Кнопка Access Name (имя доступ а ) используется для определения канала обмена (канала доступа ) с сервером , с которым будет связана описываемая переменная . Имя доступа Access Name определяется именем узла , именем приложения и именем группы или топика . Имя топика должно совпадать с соответ с твующим именем , заданным при конфигурировании DDE, SuiteLink-сервера . Имя элемента , как компонента многоуровневого адреса , определяется в поле Item (рис .13). В распределенных системах InTouch имя доступа может быть определено либо как локальный адрес , ли б о как глобальный . Локальные адреса используются в том случае , когда View - узлы имеют свои серверы ввода /вывода . На рис . 13 узлы исполнения (View - узлы ), каждый со своей копией одного и того же приложения , ссылаются на свои собственные источники данных в вода /вывода (серверы ввода /вывода ). Рис . 13. Сеть View – узлов с собственными серверами ввода /вывода. Поэтому при определении канала доступа к информации ввода /вывода достаточно трехуровневого адреса (Application - приложение , Topic - объект , Item - элемент ). Имя узла (Node) в этом случае опускается . Щелчок по кнопке Access Name (рис .2.3.8) вызывает на экран одноименный диалог . Этот диалог предназначен для определения нового канала доступа (кнопка Ad d ), модификации существующего (Modify) или удаления (Delete). Щелчок по кнопке Add вызывает диалог определения нового канала доступа . В качестве имени (канала ) доступа (Access Names) рекомендуется выбирать имя группы или топика (Topic Name). Следует подчер к нуть , что поле Node Name (имя узла ) оставлено пустым . Щелчок по кнопке Ok возвращает пользователя в диалог Access Names (имена доступа ) с определенным именем доступа. Глобальные адреса источников данных ввода /вывода позволяют нескольким View - узлам обращ а ться к одному и тому же серверу ввода /вывода . Такой подход предоставляет возможность отказаться от нескольких серверов ввода /вывода , однако менее защищен от отказов (рис .14). Рис .14. Архитектура с двумя Vie w - узлами и сервером ввода /вывода. Два View - узла исполняют идентичные копии одного и того же приложения и ссылаются на один и тот же источник ввода /вывода (I/O сервер ). Поэтому при определении канала доступа к информации ввода /вывода необходимо исполь зовать четырехуровневый адрес (Node - узел , Application -приложение , Topic - объект , Item - элемент ). При выборе имени доступа действует то же правило , что и при локальной адресации : рекомендуется , чтобы это имя совпадало с именем группы данных или топика (Topic Name). Но поле Node Name (имя узла ) необходимо заполнить . В качестве этого имени при глобальной адресации выбирают имя узла , на котором установлен сервер ввода /вывода , являющийся источником данных для нескольких приложений . Для каждой переменной в вода /вывода задается атрибут Access Name. С одним именем доступа , как правило , связано большое количество переменных . Распределение переменных по группам (топикам ) - произвольное . Но для оптимизации функционирования серверов рекомендуется в одну группу от н осить переменные с одинаковой частотой обновления . В противном случае частота , задаваемая при конфигурировании топика в сервере , должна соответствовать минимальному временному кванту . Желательно на этапе конфигурирования сервера определить группы (топики ) для каждого частотного диапазона и в соответствии с этими группами создать имена доступа (Access Name) в InTouch (лучше даже , чтобы имена групп совпадали с именами доступа ). А далее каждую описываемую в InTouch-приложении переменную типа I/O связывать с п о дходящим именем доступа для обеспечения рационального пакетирования данных. Тренды в SCADA - системах Графическое представление значений технологических параметров во времени способствует лучшему пониманию динамики технологического процесса предприятия . Поэтому подсистема создания трендов и хранения информации о параметрах с целью ее дальнейшего анализа и использования для управления является неотъемлемой частью любой SCADA - системы . Тренды реального времени (Real Time) отображают динамические изменения параметра в текущем времени . При появлении нового значения параметра в окне тренда происходит прокрутка графика справа налево . Таким образом текущее значение параметра выводится всегда в правой части окна . Тренды становятся историче скими (Historical) после того , как данные будут записаны на диск и можно будет использовать режим прокрутки предыдущих значений назад с целью посмотреть прошлые значения . Отображаемые данные тренда в таком режиме будут неподвижны и будут отображаться толь к о за определенный период. Тренды в InTouch InTouch предлагает пользователю оба типа графических объектов , называемых трендами : тренд реального времени и исторический (архивный ) тренд . Тренды реального времени дают возможность создав ать графики изменения во времени четырех переменных (4 пера ), в то время как для исторических трендов можно конфигурировать до восьми перьев в одном объекте . Количество объектов типа "тренд " в приложении , в том числе и в одном окне , не ограничено . Оба тип а трендов создаются c использованием специальных графических объектов инструментальной панели WindowMaker. InTouch также обеспечивает полный контроль над конфигурированием трендов . Для примера , можно определить диапазон времени , область значений , разрешен и е сетки , размещение временных отметок , число перьев и атрибуты цвета и т . д . Допускается переконфигурирование архивного тренда на этапе исполнения приложения (в Runtime). Архивирование (регистрация ) значений переменной При работе си стемы в режиме WindowViewer (среда исполнения ) InTouch может производить запись значений переменных в регистрационный файл . Для того , чтобы архивирование переменной выполнялось , необходимо включить опцию Log Data (регистрация данных ) при определении перем е нной в диалоге Tagname Dictionary. Запись в регистрационный файл производится всякий раз при изменении переменной на величину , превышающую порог для архивирования (Log Deadband), и по умолчанию один раз в час , если значение переменной за это время не изм е нилось . Поле Log Deadband находится в диалоге детального описания целой или вещественной переменной. Чтобы значения переменных , для которых опция Log Data разрешена , записывались в регистрационные файлы , необходимо общее разрешение глобальной функции реги с трации . Его задают в диалоге Historical Logging Properties (параметры архивирования , рис . 15), который вызывается на экран командой Special/Configure/Historical Logging. В этот диалог можно также войти из окна Application Explorer. Рис . 15 . Диалог Historical Logging Properties. Включение опции Enable Historical Logging дает общее разрешение на регистрацию значений переменных . Срок хранения регистрационных файлов на диске (исключая текущий день ) определяется в поле Keep Log Files for в днях . Если в это поле введено значение 0, файлы будут храниться бесконечно долго . Регистрационные файлы могут быть размещены в каталоге приложения (опция по умолчанию Store Log Files in Application Directory). В противном случае след у ет отметить опцию Store Log Files in Specific Directory (хранить файлы в ином каталоге ) и ввести полный путь до каталога , в котором будут храниться регистрационные файлы (при работе с распределенными архивами - полный сетевой путь ). Отображени е трендов Тренды реального времени являются динамическими объектами . Они позволяют выводить изменения значений переменных , как только они происходят для любой конкретной переменной или для выражения , которое содержит одну или несколько переменн ых . Данные будут появляться в окне тренда и двигаться справа налево . Чтобы создать тренд реального времени , необходимо : · выбрать инструмент тренд реального времени в панели инструментов WindowMaker; · щелкнуть в окне , затем переместить мышь по диагонал и и сформировать прямоугольник необходимого размера ; · отпустить кнопку мыши , что вызовет появление тренда реального времени в окне (рис .16). Рис .16. Объект "тренд реального времени ". При создании тренда реального времен и настройки его конфигурации устанавливаются по умолчанию (настройки предыдущего тренда ). Для конфигурирования тренда реального времени следует либо дважды щелкнуть на созданном объекте , либо , предварительно выбрав объект , запустить команду Special/Animat ion Links. На экране появится диалог Real Time Trend Configuration (конфигурирование тренда реального времени ). Среди настроек этого диалога можно отметить диапазон времени , охватываемый трендом (Time Span), частоту вывода значение переменной (Interval), р азрешение сетки по большим и малым делениям горизонтальной и вертикальной осей (Time Division, Value Division), цвета фона и рамки графика (Color). Конфигурирование перьев тренда включает выбор имени переменной или выражения , цвета и толщины линии для каж д ого пера (поле Expression). Для повышения производительности системы следует отметить опцию Only update when in memory (обновлять , когда в памяти ). В этом случае обновление данных тренда будет производиться только в моменты , когда окно с трендом отображае т ся на дисплее (находится в RAM). Есть и другие способы повышения производительности при работе с трендами реального времени (уменьшение толщины линии графика , уменьшение частоты выводы значений переменной ). Например , если установлен диапазон времени (Time Span) в 30 минут , а частота вывода - 2 секунды , то число измерений , которые нужно провести за каждые 30 минут , будет равно 900 (30 * 60/2 = 900). При частоте выводе в 5 секунд число измерений существенно уменьшается : 30 * 60/5 = 360. Исторические (архивны е ) тренды не являются динамическими . Они обеспечивают "снимок " состояния данных за прошедшее время , то есть по архивным данным . В отличие от трендов реального времени исторические тренды обновляются только по команде - при запуске скрипта , изменении значен и я выражения или нажатии оператором соответствующей кнопки . При конфигурировании архивного тренда можно создать "визиры " (ползунки , бегунки ), с помощью которых удобно получить значения всех отображаемых переменных на один и тот же момент времени . Бегунки а р хивного тренда представляют собой позиционные индикаторы на временной оси , положение которых определяет объем извлекаемых данных . Связав объект "движковый регулятор " с полем бегунка , можно осуществлять перемещение вдоль архивного тренда . Кроме того , имеют с я функции вычисления среднего , минимального и максимального значений в определенном бегунком положении . Можно создать правый и левый бегунки и производить обработку данных кривой , расположенной между бегунками . Вычисляются следующие величины : среднее , мин и мальное , максимальное , отношение мин /макс и стандартное отклонение . В зависимости от положения бегунков на оси можно реализовать и другие функции (увеличение и уменьшение заключенной между бегунками области графика ). Благодаря системе распределенных архив ов на один и тот же график можно выводить информацию из нескольких баз данных . Все сказанное выше о механизме создания тренда реального времени инструментом Real Time Trend в среде разработки WindowMaker и о его последующем конфигурировании можно отнести и к архивному тренду , создаваемому инструментом Historical Trend среды разработки . Предлагаемый ниже способ создания и конфигурирования архивного тренда предполагает использование мастер-средств библиотеки Wizard. Нажатие кнопки выбора мастер-средств в па нели инструментов вызывает появление на экране диалога Wizard Selection (выбор мастер-средств ). После выбора из предложенного набора мастер-средств Hist Trend with Scooters (архивный тренд с бегунками ) и щелчка по Ok программа возвращает пользователя в с р еду разработки . Курсор мыши при этом примет форму вставки . Последующий щелчок мыши на предполагаемом месте нахождения создаваемого объекта выводит на экран архивный тренд (рис .17). Объекты этого типа ведут себя аналогично любым другим объектам , то есть и х можно перемещать , масштабировать и т . д . Рис .17. Объект "архивный тренд ". Двойной щелчок на объекте приводит к появлению на экране диалога конфигурирования архивного тренда (Historical Trend Char Window). Рис .18. Диалог конфигурирования архивного тренда. Для конфигурирования тренда с параметрами по умолчанию следует нажать кнопку Suggest (вариант ). Нажатие кнопок Times и Values выводит на экран окна конфигурирования разрешения сетки п о большим и малым делениям горизонтальной и вертикальной осей , цвета фона и рамки графика , временного диапазона и т . д . Кнопка Pens (перья ) предназначена для настройки перьев архивного тренда . Чтобы добавить в тренд функции масштабирования и перемещения и ли элементы управления перьями , следует использовать панели Zoom/Pan и Trend Pen Legend (рис .16), соответственно . Для того , чтобы эти компоненты работали совместно , они должны иметь одинаковые имена (Hist Trend). Изменение параметров архивных т рендов в режиме исполнения При управлении в режиме реального времени оператор анализирует архивную информацию . Объем информации , ее временные диапазоны , объем статистических данных , необходимые для принятия решения по управлению технологическим процессом , заранее не известны . Поэтому оператор должен иметь возможность менять настройки архивных трендов , не выходя из режима Runtime. В InTouch такая возможность существует . Для этого следует включить опцию Allow runtime changes (разрешить изменения во время исполнения ) в диалоге конфигурирования архивного тренда (в книге не показан ). Теперь в режиме WindowViewer щелчок на архивном тренде будет вызывать на экран диалог изменения параметров архивного тренда (Historical Trend Setup). В этом диалоге мо ж но определить дату и время начала архивного тренда (поле Chart Start), его временной диапазон (Chart Length), присвоить перьям цвет и имена переменных , выбирая их из словаря . Архивный тренд может выводиться в одном из трех возможных режимах : · Min/Max - график изменения значений переменной в виде вертикальных линий в процентах от всего диапазона , позволяющий оценить скорость изменения переменной ; · Average/Scatter - график среднего значения переменной ; · Average/Bar Chart - график среднего значения пере менной в виде гистограммы . Выбор режима производится в поле Display Mode. Система распределенных архивов В InTouch имеется система распределенных архивов , обеспечивающая поиск архивных данных в любом InTouch - приложении . Данная си стема расширяет возможности стандартных архивов InTouch, позволяя одновременно получать информацию из нескольких удаленных баз данных , которые в этом случае называются провайдерами архивов . Одновременно можно обращаться к восьми провайдерам (по одному на каждое перо ). Каждый узел , выполняющий функцию регистрации , может писать только в один архив . Система , приведенная на рис .19, имеет два провайдера архивов . Левый провайдер регистрирует информацию только из узла , расположенного слева внизу . Правый провайд е р регистрирует информацию из узла , расположенного справа вверху . Остальные три узла (вверху слева ) лишь используют архивные данные . Читать информацию из архивных файлов может каждый из узлов системы . Создание такой системы предполагает следующие действия : · создание списка провайдеров архивов ; · создание и определение параметров объекта "архивный тренд "; · конфигурирование приложения на удаленное архивирование данных ; · копирование приложения на все узлы. Рис . 19. Ра спределенная система архивов. Встроенные языки программирования Встроенные языки программирования - мощное средство SCADA - систем , предоставляющее разработчику гибкий инструмент для разработки сложных приложений . Первые версии SCA DA - систем либо не имели подобных языков , либо эти языки реализовывали небогатый набор функций . В современных версиях SCADA - систем функциональные возможности языков становятся существенно богаче . Явно выделяются два подхода : · Ориентация встроенных язы ков программирования на технологов . Функции в таких языках являются высокоуровневыми , не требующими профессиональных навыков программирования при их использовании . Количество таких функций в базовых поставках не исчисляется сотнями , хотя существуют свобод н о распространяемые библиотеки дополнительных функций . · Ориентация на системного интегратора . В этом случае в качестве языков чаще всего используются VBasic - подобные языки . В каждом языке допускается расширение набора функций . В языках , ориентированных на технологов , это расширение достигается с помощью дополнительных инструментальных средств (Toolkits). Разработка дополнительных функций выполняется обычно программистами - профессионалами . Разработка новых функций при втором подходе выполняется обычно разработчиками приложений (как и в традиционных языках программирования ). Полнота использования возможностей встроенных языков (особенно при втором подходе ) требует соответствующего уровня квалификации разработчика , если , конечно , в этом есть необходимост ь . Требования задачи могут быть не столь высокими , чтобы применять всю "мощь " встроенного языка . Во всех языках функции разделяются на группы , часть из которых присутствует практически во всех языках : математические функции , функции работы со строками , об мен по SQL , DDE - обмен и т . д . В разрабатываемом приложении создаются программные фрагменты , состоящие из операторов и функций языка , которые выполняют некоторую последовательность действий . Эти программные фрагменты связываются с разнообразными события ми в приложении , такими как нажатие кнопки , открытие окна , выполнение логического условия (a +b > c). Каждое из событий ассоциируется с графическим объектом , окном , таймером , открытием / закрытием приложения . Когда приложение содержит сотни окон , тысячи ра з личных графических объектов , а с каждым из них связано несколько событий , в приложении может "работать " огромное количество отдельных программных фрагментов . Велика вероятность их "одновременной " активизации . Каждая из функций во встроенном языке выполняе тся в синхронном или асинхронном режиме . В синхронном режиме выполнение следующей функции не начинается до тех пор , пока не завершилось исполнение предыдущей . При запуске асинхронной функции управление переходит следующей , не дожидаясь завершения исполнен и я предыдущей функции . В связи с этим возникает несколько вопросов . С каким приоритетом исполняется каждый из фрагментов , допускается ли рекурсия при обработке событий и если да , то каков уровень вложенности ? В SCADA - системах уровень вложенности пока не стандартизован , но оговаривается особо в рамках каждой из них. Скрипты в InTouch Скрипты в InTouch - это программные фрагменты , активизируемые по событиям (по нажатию клавиши , кнопки , открытию окна , изменению значения переменной и т . д .). Типы скриптов В InTouch различают несколько типов скриптов : · Application Scripts (скрипты уровня приложения ) относятся ко всему приложению и используются для запуска других приложений , имитации технологических процессов , выч исления значений переменных и т.д. · Window Scripts (скрипты уровня окна ) связываются с конкретным окном. · Key Scripts (клавишные скрипты ) привязываются к какой-либо клавише или комбинации клавиш клавиатуры . Это может быть полезным при создании каких-либо глобальных для всего приложения функций (возврат в главное окно , окончание сеанса работы с приложением и т . д .). · Touch Pushbutton Action Scripts (скрипты , запускаемые кнопками ) очень похожи на клавишные скрипты и связываются с объектами , которые будут использоваться в качестве исполнительных кнопок . Эти скрипты запускаются при каждом нажатии на объект-кнопку. · Condition Scripts (скрипты по изменению логического выражения ) связываются с логической переменной или выражением , которое будет принимать значе ния либо "истина ", либо "ложь ". Логические скрипты могут содержать в себе и аналоговые переменные . · Data Change Scripts (скрипты по изменению данных ) связываются либо с переменной , либо с полем переменной . Эти скрипты исполняются только один раз , когда з начение переменной либо поля меняется на величину , превышающую значение допуска , заданного в словаре переменных. · ActiveX Event (скрипты событий ActiveX) предназначены для поддержки механизма реакции на события в ActiveX - объектах . С каждым событием може т быть связан один скрипт типа ActiveX Event, запускающийся в WindowViewer во время исполнения приложения. · Quick Function - скрипты , которые могут вызываться из других скриптов и использоваться в выражениях при определении динамических свойств объектов. Диалоги редактора , открываемые при создании скриптов различных типов , имеют небольшие отличия . Вызов диалога редактора скриптов в окне WindowMaker осуществляется командой Special/Scripts с последующим выбором типа создаваемого или редактируемого скрипта . Д ля этого можно также воспользоваться окном Application Explorer, выбрав папку Scripts. На рис . 5.1.1 приведен диалог Application Scripts (скрипты уровня приложения ). Редактор скриптов InTouch поддерживает два типа скриптов : простые и сложные . Простые скри пты - это скрипты , содержащие операторы присваивания , сравнения , простые математические функции и т . д . Сложные скрипты позволяют выполнять различные логические операции типа IF - THEN - ELSE, а также могут включать циклы типа FOR - NEXT. Справа , в поле F unctions, размещены клавиши вызова списков различных групп встроенных функций . Доступ к спискам встроенных функций возможен также командой Insert/Functions с последующим выбором группы функций (см . рис . 5.1.1). Встроенные функции В пакете InTouch имеется набор встроенных функций , которые могут быть связаны с командами или использованы в скриптах для выполнения самых различных задач . Все встроенные функции разбиты на четыре группы : - String... - для обработки различных символьных с трок и переменных ; - Math... - математические функции ; - System... - системные функции ; - Misc... - функции для работы с алармами распределенных систем , трендами , печатью и др . · Вызов списка функций группы осуществляется нажатием соответствующей клав и ши . Например , щелчок по клавише String... редактора скриптов вызывает появление диалога Choose function (выбор функции ) со списком строковых функций . Описание некоторых функций этого списка приведено в табл . 5.1. Функция Описание StringFromIntg() Возвращ ает символьное представление целого аргумента в указанной системе счисления StringFromReal() Возвращает символьное представление вещественной величины либо в формате с плавающей запятой , либо в экспоненциальном формате StringLen() Возвращает длину указан ной строки StringToIntg() Преобразует символьное представление целого числа во внутренний формат StringUpper() Преобразует все символы исходной строки в нижнем регистре в верхний регистр Text() Осуществляет форматированный вывод указанной целой или веще ственной переменной в соответствии со строкой форматирования Таблица 5.1. Каждая строковая функция имеет один или несколько аргументов (до 6). Например , синтаксис функции StringFromReal выглядит следующим образом : StringFromReal(Number,Precision,Type); - Number - конвертируемая вещественная величина ; - Precision - количество десятичных знаков ; - Type - тип формата ( "f", "e", "E"). Например , функция StringFromReal(263.365, 2, "f") возвращает "263.36"; функция StringFromReal(263.365, 2, "e") возвращает "2.63e2"; функция StringFromReal(263.55, 3, "E") возвращает "2.636E2". Функция Text имеет два аргумента : Text(Analog_Tag, "Format_Text"); - Analog_Tag - вещественное или целое число ; - Format_Text - формат пре образования . Если указанный формат функции Text - "#0.00", то : - при Analog_Tag = 66 функция возвращает 66.00; - при Analog_Tag =22.269 функция возвращает 22.27; - при Analog_Tag =9.999 функция возвращает 10.00. · Щелчок по клавише Math... вызывает по явление диалога Choose function (выбор функции ) со списком математических функций . Математические функции работают с целыми и вещественными аргументами , выдавая целый или вещественный результат . В левой части оператора присваивания допускается указывать и целые переменные . Однако необходимо иметь ввиду , что преобразование вещественного значения в целое может привести к усечению результата. · Системные функции делятся на две категории : файловые (File) и для работы с Windows - приложениями (Info). Файловые функции предназначены для считывания и записи информации в файлы . У всех файловых функций есть два общих аргумента - Filename и FillOffset. Аргумент Filename (имя файла ) хранит имя файла , из которого должна быть считана или в который должна быть записана и нформация (имя также должно включать и путь к файлу ). Аргумент FillOffset (смещение в файле ) задает относительную позицию в файле , начиная с которой будут читаться или записываться данные . Смещение задается в байтах от начала файла . Первый байт файла имее т смещение 0. После завершения каждая функция возвращает следующее доступное смещение в файле . Например , если функция читает 5 байтов данных , начиная с 10-го байта , то после завершения функция возвратит 15. Некоторые встроенные функции группы System привед е ны в табл . 5.2. Функция Описание FileCopy() Копирует исходный файл в файл-приемник FileReadFields() Возвращает очередную запись данных из CSV - файла FileReadMessage() Возвращает указанное количество байтов (или всю строку ) из указанного файла FileWrit eFields() Сохраняет в CSV - файле запись данных , состоящую из разделенных запятыми величин InfoDisk() Возвращает информацию об указанном локальном или сетевом диске InfoFile() Возвращает информацию об указанном файле или подкаталоге компьютера или сетево го устройства InfoTouchAppDir() Возвращает имя текущего каталога InTouch - приложения Таблица 5.1. Остальные аргументы файловых функций не поддаются типизации и различны для каждой функции . Например , функция FileReadFields имеет четыре аргумента и с ледующий синтаксис : FileReadFields(Filename,FileOffset,StartTag,NumberOfFields); - StartTag - идентифицирует первый элемент в имени InTouch-переменной ; - NumberOfFields - идентифицирует число полей для чтения . · Группа функций Miscellaneous (клавиша Mis c...) включает функции для работы с алармами распределенных систем , трендами , печатью и др . В этой широкой (с точки зрения назначения функций ) группе можно выделить несколько более узко специализированных подгрупп . Функции , название которых начинается с a lm, используются только в распределенных системах алармов . Некоторые из них приведены в табл .5.3.1. Функция Описание almAckDisplay() Подтверждает только те алармы , которые в текущий момент видны в окне отображения алармов almAckSelect() Подтверждает алар мы , отмеченные оператором в окне отображения алармов almShowStats() Выводит панель статистики объекта отображения алармов Таблица 5.3.1. Первым аргументом всех встроенных функций алармов является ObjectName (имя объекта алармов ). Часто в роли одного и з аргументов выступает Comment (комментарий ). Например , функция almAckSelect имеет следующий синтаксис : almAckDisplay(ObjectName,Comment); . Функции , название которых начинается с HT, используются только с архивными трендами . Примеры таких встроенных фу н кций - в табл .5.3.2. Функция Описание HTGetPenName() Возвращает имя переменной , связанной в текущий момент с указанным пером указанного тренда HTGetValue() Возвращает значение указанного типа , вычисляемого для указанного пера в пределах всего тренда HT ScrollLeft() Устанавливает в качестве начала графика более раннее время . Визуально происходит прокрутка тренда влево HTSetPenName() Связывает перо тренда с указанной переменной HTZoomIn() Масштабирует существующий тренд путем задания новых времени начала и охватываемого интервала времени Таблица 5.3.2. Встроенные функции для работы с архивными трендами также могут иметь несколько аргументов (до четырех ). Функции , приведенные в табл . 5.3.2, имеют следующий синтаксис : - HTGetPenName(Hist_Tag, UpdateCou nt, PenNum); - HTGetValue(Hist_Tag,UpdateCount,PenNum,ValType_Text); - HTScrollLeft(Hist_Tag,Percent); - HTSetPenName(Hist_Tag,PenNum,Tagname); - HTZoomIn (Hist_Tag,LockString). Первый аргумент всех встроенных функций для работы с трендами - Hist_Tag (имя тренда ). Из других аргументов следует отметить PenNum (номер пера тренда ), ValType_Text (строка , указывающая тип возвращаемого значения ), Tagname (новое имя пера ). Функции , название которых начинается с wc (табл .5.3.3), используются с управляющими о бъектами окна (простые списки , текстовые окна , ниспадающие списки и т . д .) Функция Описание wcDeleteItem() Уничтожает элемент с заданным порядковым номером как в простом , так и в ниспадающем списке wcInsertItem() Вставляет указанное сообщение в список wcLoadText() Заменяет содержимое текстового окна на новую информацию Таблица 5.3.3. Функции этой подгруппы также могут иметь до четырех аргументов : - wcDeleteItem("ControlName", ItemIndex); - wcInsertItem("ControlName", ItemIndex, "MessageTag"); - w cLoadText("ControlName", "Filrename");. Первый аргумент всех встроенных функций этой подгруппы - ControlName (имя управляемого окна ). Часто в качестве аргумента используются ItemIndex (номер , соответствующий позиции элемента ), MessageTag (строковое сообще ние ), Filrename (имя файла в формате ASCII). В рассматриваемой группе функций Miscellaneous следует отметить функцию PrintWindow, i?aaiacia?aiioю для печати окна . Ее синтаксис выглядит следующим образом : PrintWindow("Window",Left,Top,Width,Height,Options );, где : - Window - имя окна ; - Left - число дюймов от левого края ; - Top - число дюймов от верхнего края ; - Width - ширина распечатываемого окна ; - Height - высота распечатываемого окна ; - Options - дискретные значения 0 или 1. Вставка встроенных функций в скрипт производится щелчком по выбранной функции в списке функций . Она вместе со своими аргументами будет автоматически вставлена в текст скрипта в точку , указанную курсором . После этого можно отредактировать список аргументов . По окончании ред а ктирования скрипта следует нажать кнопку Ok. При обнаружении в скрипте каких-либо ошибок на экран будет выведено соответствующее сообщение . В большинстве случаев курсор установится в ту позицию , которая привела к появлению ошибки . Прежде чем скрипт будет с охранен , все ошибки должны быть исправлены. Функции Quick Functions Quick Functions - это скрипты , которые могут вызываться из других скриптов и использоваться в выражениях при определении динамических свойств объектов . Скрипты Quic k Functions хранятся внутри того приложения , в котором они были созданы , и могут многократно использоваться в других скриптах InTouch. Наиболее часто эти функции используют в выражениях при определении динамических свойств объектов . Чем это вызвано ? Дело в том , что длина выражения в поле Expression диалогов определения динамических свойств объектов должна быть не более 256 символов . Это относится к таким динамическим свойствам , как цвет линии , цвет заполнения , изменение высоты и ширины , вертикальное и гор и зонтальное перемещение , вертикальное и горизонтальное заполнение , видимость , мерцание , ориентация , блокировка . Для ввода более длинных выражений можно воспользоваться функциями Quick Functions. При этом выражение в поле Expression должно содержать опера т оры CALL вызова функций Quick Functions, каждая из которых , в свою очередь , должна иметь в качестве последнего оператора RETURN для возврата результата в вызывающее выражение . Организованное таким образом выражение может содержать многие тысячи символов и быть сколь угодно сложным . Сохраненная функция Quick Functions может быть использована в любом другом скрипте или выражении . Quick Functions могут быть синхронными и асинхронными скриптами . Синхронные скрипты выполняются последовательно , в то время , как после запуска одного асинхронного скрипта может быть запущен другой (синхронный или асинхронный ) скрипт . Это позволяет отделять исполняющиеся довольно долго операции (типа обращений к базам данных ) от основной программы . Асинхронные скрипты не могут возвр а щать результаты . Поэтому в качестве скриптов Quick Functions, используемых в выражениях (Expression) для определения динамических свойств объектов , следует применять только синхронные скрипты . Создание скриптов Quick Functions осуществляется в диалоговом окне редактора Quick Functions. Вызов этого диалога на экран в окне WindowMaker производится в командой Special/Scripts с последующим нажатием на строке Quick Functions. Список Name содержит имена всех определенных к данному моменту скриптов Quick Functio ns. Щелчок по имени скрипта выводит его текст в рабочее поле диалога . Команда Scripts/New предназначена для создания нового скрипта и вызывает на экран диалог для ввода его имени . После щелчка по Ok новое имя будет включено в список имен Name. Следующий этап - определение аргументов нового скрипта в таблице Arguments диалога Quick Function. В левую колонку таблицы вводят имя аргумента (до 31 символа ), в правую - его тип (Integer, Real, Discrete, Message). В одном скрипте допускается до 16 аргументов . Пос ле определения типов аргументов можно приступать к написанию текста скрипта Quick Function в рабочем поле (под таблицей Arguments). Разработка графопостроителя в системе InTouch Данный раздел посвящен разработке четырехканального графопостроителя визуализирующего данные , поступающие по DDE каналу с DDE сервера . В программе предусмотрена возможность масштабирования по каждому из каналов. Разработка DDE -сервера Приложение , получающее данные из другого приложе ния по DDE и /или управляющее другим приложением с помощью команд через DDE является DDE-клиентом . В этом случае второе приложение является DDE-сервером . Рассмотрим проект DDE -сервера , выполненного на языке программирования Borland Delphi 6. На рис .20 пред ставлено окно DDE-сервера во время дизайна в среде Delphi Рис . 20. Окно DDE -сервера на стадии проектирования в Delphi Для построении DDE-сервера в Delphi имеются два объекта , расположен ные на странице System Палитры Компонент - TDdeServerConv и TDdeServerItem. Обычно в проекте используется один объект TDdeServerConv и один или более TDdeServerItem. Для получения доступа к сервису DDE-сервера , клиенту потребуется знать несколько параметр о в : имя сервиса (Service Name) - это имя приложения (обычно - имя выполняемого файла без расширения EXE, возможно с полным путем ); Topic Name - в Delphi это имя компоненты TDdeServerConv; Item Name - в Delphi это имя нужной компоненты TDdeServerItem. Назн а чение объекта TDdeServerConv - общее управление DDE и обработка запросов от клиентов на выполнение макроса. Объект TDdeServerItem связывается с TDdeServerConv и определяет , что , собственно , будет пересылаться по DDE. Для этого у него есть свойства Text и L ines. (Text имеет то же значение , что и Lines[0].) При изменении значения этих свойств автоматически происходит пересылка обновленных данных во все приложения-клиенты , установившие связь с сервером. При запуске приложения происходит выполнение процедуры TD DEServe.FormActivate: procedure TDDEServe.FormActivate(Sender: TObject); var nidata : TNotifyIconData; begin Application.ShowMainForm := False; ShowWindow(Application.Handle, SW_HIDE); ShowWindow(Application.MainForm.Handle, SW_HIDE); with nidata do begin cbSize := SizeOf(TNotifyIconData); Wnd := Self.Handle; uID := 1; uFlags := NIF_ICON or NIF_MESSAGE or NIF_TIP; uCallBackMessage := WM_MYICONNOTIFY; hIcon := Application.Icon.Handle; StrPCopy(szTip,Application.Ti tle); end; Shell_NotifyIcon(NIM_ADD, @nidata); ru :=10; end ; В этой процедуре приложение сворачивается в системный Tray , а форма становится невидимой . Окончание работы DDE -сервера вызывается путём нажатия левой или правой кнопкой мыши на иконке прило жения в области системного Tray . Обработка этого события выполняется в процедуре TDDEServe.WMICON : procedure TDDEServe.WMICON(var msg: TMessage); begin case msg.LParam of WM_RBUTTONDOWN,WM_LBUTTONDOWN: close; end; end; При этом , при закрытии окна при ложения вызывается процедура TDDEServe . FormDestroy , в которой происходит удаление иконки из системного Tray : procedure TDDEServe.FormDestroy(Sender: TObject); var nidata : TNotifyIconData; begin with nidata do begin cbSize := SizeOf(TNotifyIconData); Wnd := Self.Handle; uID := 1; end; Shell_NotifyIcon(NIM_DELETE, @nidata); end; Работа приложения в целом строится посредством вызова процедуры TDDEServe . Timer 1 Timer по прерыванию таймера. implementation $R *.DFM uses ComObj, activex, ShellApi, shlobj, registry; var xsin: integer; ru:real; boolka:boolean; procedure TDDEServe.Timer1Timer(Sender: TObject); var LPTbyte: byte; begin xsin:=xsin+1; if xsin>1000 then xsin:=xsin-1000; DDEItem100.Text:=inttostr(5*(xsin-20*trunc(xsin/20))); // пилообразный сигнал asm mov dx,379h in al,dx and al,80h mov LPTbyte,al end; DDEItem200.Text:=inttostr(LPTbyte*100); // состояние лин ии LPT- порта DDEItem300.Text:=inttostr(round(50+50*sin(xsin/20))); if (xsin/5)=trunc(xsin/5) then if (ru
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Лабораторная по химии. Все дети греют колбы спиртовками, Вовочка - горящей бумажкой. Марьиванна:
- Вовочка, куда делся спирт из спиртовки?
Вовочка, заплетающимся языком:
- Куууда? Куууда? Прроолился.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, курсовая по программированию "SCADA системы", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru