Программное обеспечение промышленных систем

Как показала практика, стоимость создания систем промышленной автоматизации определяется в основном затратами на разработку ПО, доля которого может доходить до 60%.

Чем располагает разработчик промышленной системы? В первую очередь это операционные системы, поддерживающие функционирование разрабатываемого приложения. В сфере промышленной автоматизации свой мир операционных систем - ОС реального времени (ОС РВ). Для VME-процессоров, например, существует 17 ОС (OS-9/OS-9000, VRTX/Spectra, VxWorks, PDOS, pSOS+, LynxOS, VMEexec, iRMX, C-Exec, QNX и т. д.), самая распространенная из которых - OS-9. Поскольку крупные компании-производители обеспечивают для своих процессоров и устройств ввода/вывода полную поддержку сразу нескольких ОС РВ, можно найти версии систем из приведенного списка для многих платформ: 68000, PowerPC, ix86, Pentium.

ОС РВ характеризуется прежде всего малым временем реакции на внешние события. Так, гарантированное время реакции системы на процессоре MC68040/25 МГц под управлением операционной системы OS-9 v3.0/Atomic составляет 3 мкс. Как правило, это многопользовательские многозадачные ОС, выполненные по технологии микроядра. Последние версии ОС имеют прерываемое микроядро, что гарантирует быструю реакцию на внешнее событие при любом состоянии системы. Особенность большинства ОС - возможность стопроцентного размещения в памяти ядра, сетевого и графического обеспечения, драйверов и прикладных программ. Для встроенных бездисковых систем это чрезвычайно важно.

Традиционно ОС РВ делятся на "жесткие" и "мягкие". Система "жесткого" РВ должна без сбоев отвечать на внешние события в рамках заранее определенного интервала времени. Время ответа должно быть предсказуемым и не зависеть от текущего состояния системы. "Мягкая" ОС РВ тоже должна отвечать очень быстро, но гарантированное время ответа в ней не обеспечивается. Здесь нужно отметить, что временные характеристики последних версий промышленных ОС практически стерли ранее существовавшую грань между двумя этими разновидностями. Сейчас OS-9, ранее считавшаяся "мягкой" ОС, практически не уступает классическим "жестким" ОС - pSOS+ и VxWorks.

Все большее распространение в сфере промышленной автоматизации получают ОС общего назначения: Unix в разных реализациях, NT, OS/2, VMS. Для этого есть несколько причин. В различные реализации Unix стали включаться ядра реального времени, и это движение поддержано открытыми стандартами. В POSIX стандартизованы, например, диспетчеризация и синхронизация процессов, нити, тайм-ауты, управление прерываниями. Во-вторых, трудно устоять перед мощной экспансией ПК, особенно после выхода Windows NT [5], и рабочих станций. Третья причина состоит в наличии на платформах общего назначения широкого разнообразия инструментальных средств.

Действительно, кроме базовой поддержки, предоставляемой ОС РВ, для создания приложений разработчику требуется развитый инструментарий, которого, конечно, больше в общецелевых системах. Нельзя сказать, что ОС РВ в этом отношении бедны - в них обычно поддерживаются сетевые протоколы, X Window, Motif, но конкурировать на равных им все же тяжело, особенно с новейшими инструментальными технологиями. С другой стороны, все ОС РВ имеют собственные среды разработки (FasTrack, Microtec, MasterWorks), чьи возможности в определенных аспектах превосходят аналогичные общецелевые средства, которые, например, не могут помочь разработчику систем РВ на финальных стадиях отладки, когда нужно измерять время выполнения программ и время реакции системы. Поэтому можно выбрать подход, при котором ОС общего назначения используются в качестве среды для разработки ПО целевого приложения реального времени, а в качестве среды исполнения применяется та или иная ОС РВ. В этом варианте загрузка и отладка целевого ПО производится с инструментального компьютера по сети.

Конечно, можно создать ПО системы автоматизации, опираясь только на общецелевые средства, однако цена такой разработки будет очень высока. Системы автоматизации - это такая же прикладная область, как, например, графика или САПР, и кроме универсального здесь нужен специализированный инструментарий.

Реакцией на неблагополучное состояние дел в этой сфере явилось то, что в мае 1995 года VITA инициировала проектирование стандарта на унифицированную программную среду встраиваемых систем (ESSE). Необходимость в таком стандарте назрела давно, поскольку его отсутствие привело к кризису в разработке встраиваемых систем: и пользователи и производители много времени тратят на инсталляцию драйверов, переписывание программ и разработку новых инструментальных интерфейсов для каждой встраиваемой системы. Первоначально исследования намечались по трем направлениям: инструментальные средства, прикладные пользовательские интерфейсы ОС (OSAPI) и драйверы В/В. В апреле 1996 года была образована еще и новая группа по двоичному интерфейсу встраиваемых приложений (EABI). Что же имеется на сегодняшний день кроме проектов?

Использование даже простых, но полномасштабных компьютерных конфигураций на нижних уровнях промышленных систем для непосредственного управления оборудованием невыгодно как по экономическим соображениям, так и по причине избыточной сложности. В системах автоматизации для этого традиционно применяются более простые и дешевые устройства - программируемые логические контроллеры. В первом поколении ПЛК представляли собой релейные схемы, вырабатывающие сигналы для оборудования по правилам булевой логики. Сегодня они стали более интеллектуальными: например, устройства типа Smart I/O имеют конфигурацию, в которой центральный процессор на базе дешевого микропроцессора MC68302, последовательные порты и DC/DC-преобразователь собраны в одном компактном промышленном кожухе. Модульная структура Smart I/O позволяет гибко изменять конфигурацию, сокращать и наращивать число каналов ввода/вывода за счет широкой номенклатуры производимых модулей.

Программирование ПЛК может осуществляться двумя способами. В качестве инструментальной системы можно использовать мощные системы разработки типа Dev Pak для OS-9 или кросс-системы, имеющиеся практически на любых современных компьютерных платформах: Unibridge (Unix), PCbridge (PC), FasTrack (Unix, DOS, Windows). В составе этих систем поставляется большое количество драйверов ввода/вывода, и прикладное ПО для ПЛК становится мобильным. Все вроде бы хорошо, однако, во-первых, мобильность ограничена рамками одной инструментальной системы, и, во-вторых, программирование ПЛК таким способом нетрадиционно и в общем неадекватно: требуется знание ОС и языков программирования.

Радикально изменить ситуацию мог стандарт на языки программирования ПЛК, процесс разработки которого начался в 1979 году, и только к 1992 году он был утвержден как IEC 1131-3. При его разработке было обнаружено так много вариаций языков контроллеров, что оказалось невозможно выбрать какой-то один как базовый. Поэтому был предложен совершенно новый язык с применением современных принципов структурного программирования, абстрактных типов данных, выделения данных и процедур в блок. Однако был сохранен и графический стиль классических языков для программируемых контроллеров. В обоих вариантах стандарта введена абстракция управления, и это можно считать главным достижением. Разработчик имеет дело с переменными состояния и не зависящими от типа контроллера способами их обработки, а реальный В/В вынесен на уровень драйверов.

Стандарт IEC 1131-3 [6] описывает два графических языка, "Диаграмма цепей" (LD) и "Диаграмма функциональных блоков" (FBD). В этих языках стандартные символы обеспечивают прямое соответствие между графическим представлением задачи и способом ее решения. В LD используется стандартизированный набор символов для ступенчатого программирования. По существу, здесь разработчик просто составляет релейные схемы. FBD - это тоже графический язык, но его элементами являются функциональные блоки, соединяемые проводами в электрическую цепь, а сами функциональные блоки - это программные объекты, реализующие функции управления.

В дополнение к графическим языкам LD и FBD стандарт IEC 1131-3 определяет язык "Схем последовательных функций" (SFC). Этот язык уже ближе к традиционному программированию и предназначен для записи алгоритмов последовательного управления. Элементы этого языка - шаги, переходы и блоки - используются для определения порядка операций, написанных на любом языке стандарта.

В IEC 1131-3 определяются также два текстовых языка: "Список команд" (IL) и "Структурированный текст" (ST). IL - это язык низкого уровня, в то время как ST поддерживает структурное программирование.

В стандарте специфицированы механизмы, посредством которых производители и пользователи могут определять новые типы данных, функции и функциональные блоки. Таким образом, данный стандарт является саморасширяющимся, и можно надеяться, что он будет в состоянии обслуживать много поколений новых технологий управления. В IEC 1131-3 тщательно описываются механизмы инкапсуляции данных и операций. Например, если пользователь хочет многократно применять одну и ту же последовательность функций управления, он может выделить ее в функциональный блок, поместить его в библиотеку, а затем устанавливать копии этого блока там, где он требуется.

Все языки, включенные в стандарт IEC 1131-3, можно комбинировать , а также включать в программу фрагменты на традиционных языках. Полная реализация IEC 1131-3 доступна как коммерческий продукт: например, это ISaGRAF для Windows производства фирмы CJ International. При использовании в сочетании с OS-9 ядро ISaGRAF выполняется как пользовательская задача и принимает управление загруженным в ПЛК приложением. Среди последних продуктов - пакет IOWorks (VMIC), получивший самую высокую оценку на Национальной выставке промышленной автоматизации (Чикаго) в 1997 году.

Будущее стандарта IEC 1131-3 связывается со стандартизацией форматов программных файлов, что обеспечит возможность обмена пакетами функциональных блоков между различными платформами и позволит реально перейти к модульному программированию - созданию больших систем из готовых пакетов. Второе направление развития - использование в распределенных управляющих системах функциональных блоков за пределами программируемых контроллеров. С этой целью был создан стандарт IEC TC65/WG6, в котором концепции IEC 1131-3 применены к стандарту Fieldbus и который определяет, каким образом средства связи могут объединяться с прикладным ПО.

На уровне ПО мониторинга и управления (SCADA) существенное место занимает интерфейс человек - компьютер (MMI). Процесс разработки приложений SCADA обычно делится на две части. Первая включает проектирование и реализацию аппаратуры и ее логики, обычно генерируемой с помощью языка программирования ПЛК. Вторая часть - создание пользовательского интерфейса. Очень часто эти два этапа выполняются последовательно разными специалистами, имеющими соответствующую подготовку. Поскольку решаемые ими задачи перекрываются, трудоемкость разработки возрастает многократно.

Между тем абстракции управления, которые вводит стандарт IEC 1131, позволяют скомбинировать обе части в единый процесс, если переменные из программ логического управления сделать доступными из ПО SCADA и наоборот. Примерами интеграции редакторов программ ПЛК в стандарте IEC 1131 с ПО разработки интерфейса пользователя могут служить система WizPLC (PC Soft Int. + Smart Software Solutions) и надстройка компании Ci Technologies над пакетом логического программирования IEC 1131-3 ISaGRAF.

Рассмотрим более подробно пакет InTouch (Wonderware, США) [7], который был признан лучшим инструментальным средством для разработки SCADA-систем на выставке-ярмарке в Ганновере. InTouch реализован для среды Windows 95 и NT: управление окнами, работа со шрифтами, механизм межзадачного интерфейса (DDE) - все это базируется на штатных средствах API Windows, что создает привычную для пользователей ПК обстановку.

Основная задача, которую решает InTouch, - разработка графического интерфейса к переменным (текстовым, дискретным, действительным и целым). Переменные определяет разработчик, и они могут быть двух категорий: DDE (для связи с внешними объектами) либо Memory (внутренние). Кроме значения, переменная имеет набор атрибутов: наличие предупредительного сообщения, вызванного выходом значения за границы установок, признак квитированности этого сообщения, групповая принадлежность переменной, комментарий и т. д. Переменную типа DDE можно связать с данными, поступающими от внешних устройств, либо с объектами других пакетов, например ячейкой Excel.

При создании интерфейса переменной ставится в соответствие графический образ, который размещается в рабочем окне и визуализирует значение переменной, ее атрибуты, например предупредительное сообщение. Графический образ может быть составным, и в него могут входить элементы для изменения значений переменной. В этом плане графический образ соответствует диалоговым панелям Windows. Между переменной и графическим образом устанавливаются анимационные связи, изменяющие внешний вид образа в зависимости от значения переменной. Может происходить изменение размера, цвета, положения на экране, мигание, вращение. В составе InTouch поставляется постоянно расширяемая библиотека графических образов: панели, лампочки, тренды, измерительные линейки, часы, переключатели, клавиши. Благодаря разнообразию типов графических образов визуализация данных возможна либо в числовой форме, либо в виде графика (тренда), изменяющегося в реальном времени.

Поскольку InTouch - инструментальная система, все вводимые разработчиком переменные заносятся в базу данных, которая в целевой системе начинает работать как БД РВ. Установив связи через DDE-интерфейс между переменной InTouch и переменной любого программного пакета, можно сохранять и обрабатывать данные InTouch в стандартной БД или электронной таблице.

Фирмой Wonderware разработан специальный протокол (NetDDE) для сетевого расширения DDE, который позволяет взаимодействовать любым прикладным программам (не обязательно InTouch) в разных узлах сети. Использовать этот механизм в InTouch очень просто: к собственному имени DDE-переменной добавляется имя узла, в котором она определена.

Контроль за состоянием внешней среды формализуется в InTouch понятием предупредительного сообщения. Они могут генерироваться различными способами: поступать от внешних источников (например контроллеров), возникать при выходе значений за установки или при изменении значения дискретной переменной. InTouch поддерживает многоуровневую структуру приоритетов предупредительных сообщений. Для их обработки можно воспользоваться стандартной функцией квитирования либо написать собственную программу.

Кроме того, InTouch содержит много полезных вспомогательных функций: систему контроля доступа пользователей, генератор отчетов, драйверы для ПЛК и промышленных сетей, статистическую обработку информации, поддержку SQL-доступа, загрузку в устройства нижнего уровня.

 

Управление производством

Верхний уровень в комплексе FactorySuite занимает пакет InTrack - инструментарий для разработки систем управления производством. Продолжая линию, заложенную в пакете InTouch, он поддерживает объектно-ориентированный стиль разработки и имеет архитектуру клиент/сервер. Назначение InTrack - создание интерактивных приложений, способных контролировать и управлять всеми стадиями производственных процессов - от загрузки сырья до выпуска готовой продукции.

Основные принципы в InTrack такие же, как и в InTouch, - работа с переменными, графическими образами и обработка предупредительных сообщений. Добавлено понятие схемы производственных процессов как некоторой последовательности операций. Схемы создаются в специальном графическом редакторе из графических образов, поставляемых в библиотеке InTrack. Среди них производственные цепочки и операции, материальные ресурсы, продукты. В результате приложение, разработанное в InTrack, способно автоматизировать сбор данных и выдавать управляющие воздействия на производственные процессы в масштабах целого предприятия.

 

Лекция №13

 Использование средства NT в качестве Web -сервера для IIS ( Internet Information Server )

 

План лекции:

Введение

1. Microsoft и intranet

2. Общие черты intranet-систем

3. Система управления доступом

4. Прикладное программирование в intranet

 

Введение

 

В 1995 году компания Sun Microsystems ввела в оборот термин "intranet", обозначив им корпоративную информационную систему, построенную на основе Web-технологии. Главным в этом шаге было не построение новой информационной системы предприятия с детализацией существующих информационных потоков, присущих современным компаниям, а встраивание элементов новой технологии, разработанной в рамках так называемого "Зеленого проекта". Ресурсов на этот проект было потрачено много, но конечная цель - разработка универсального интерфейса для бытовых приборов достигнута не была. Находясь в состоянии глубокого уныния, и от избытка свободного времени, разработчики проекта реализовали на языке OAK, который был одним из стержней новой системы, Web-браузер HotJava. Это положило начало мощной рекламной компании по продвижению на рынок разработки мобильных приложений для World Wide Web нового языка, получившего название Java. Надо отдать должное компании Sun в усилиях и успехах по продвижению нового языка.

Сначала Java называли средством "оживления" Web. Однако скоро выяснилось, что заставить Дюка - маленького стилизованного человечка из демонстрационных программ браузера HotJava - махать ручкой можно гораздо проще. Современные браузеры позволяют реализовать просмотр многокадровых GIF, "оживлять" страницы при помощи программ на JavaScript. Другим способом встраивания интерактивной динамической графики может быть использование plug-ins, что, конечно, не проще чем Java, но гораздо эффективнее.

Следующим шагом в продвижении Java стали мобильные вычисления. Действительно, очень удобно иметь программу, которая работает на любой платформе и при этом свободно передается по сети. Следует заметить, что идея мобильного кода в Internet существовала довольно давно, не было только подходящей среды для ее реализации. Всерьез на эту роль претендовала только среда X Window, но у нее не было универсального интерфейса, такого как браузер WWW. У мобильных кодов имеется один существенный недостаток - никто не может дать гарантии, что по сети не будут передаваться программы с серьезными ошибками, программные "закладки" и "вирусы".

Дабы избавиться от неприятностей, вызванных ошибками в программных кодах, из Java удалили всю адресную арифметику и ввели особый режим работы с памятью. При этом главной задачей была борьба с наиболее распространенными ошибками: переполнением строковых констант фиксированной длины, переполнением стека при вызове подпрограмм, захватом и освобождением памяти во время работы программы. Естественно, что все эти решения отразились на эффективности кода. При этом не следует слишком полагаться на обещания создать эффективные компиляторы с Java, не говоря уже об интерпретаторах. Для языка Lisp задача так и не была решена, а с точки зрения механизма управления памятью эти системы во многом похожи.

Очевидно, что на стороне сервера устанавливать Java-программы нецелесообразно. Если сервер перегружен, то Java только ухудшит его способность реагировать на запросы пользователей. Другое дело администрирование самого сервера. Здесь реактивность не нужна. Отсюда и реализация программ администрирования серверов IIS (Internet Information Server) или Netscape через Java-программы. Но если в среде NT это оправдано, то, скажем, для Unix это выглядит явным излишеством. Следует обратить внимание на то, что реализация приложений на Java для многопользовательских систем, где идет борьба за эффективность распределения вычислительных ресурсов, также не целесообразна. Речь идет не о системах, которые позволяют разделять свои ресурсы в сети и поддерживать несколько account-ов, а о системах, на которых одновременно работают несколько пользователей. С этой точки зрения, язык Java ориентирован на разработку программ для клиентской части информационных сервисов, которая исполняется на ПК. При этом язык подходит для использования именно в многопотоковых системах. Самое лучшее в этом контексте, если в системе вообще ничего не выполняется, кроме Java. Вот вам и логический вывод в пользу сетевого компьютера от Sun.

Если вернуться к безопасности, но не безопасности кода, а безопасности в смысле защиты от несанкционированного доступа, то здесь при использовании мобильного кода сразу встает огромное количество вопросов. Не останавливаясь на них подробно (для этого существуют бюллетени CERT), следует заметить, что в спецификацию Java-машины были введены ограничения на использование кода в сети. Касается это прежде всего разработки компонентов распределенных информационных систем. Нельзя получать/передавать данные на хосты, отличные от того, с которого получен апплет. Как результат, стало необходимым использовать серверы-посредники (proxy), чтобы все эти компоненты увязать друг с другом.

Потеря качества при ограничении сетевого взаимодействия может быть компенсирована только одним - применением Java в корпоративных информационных сетях. При этом учитывается, что жесткие ограничения апплетов не действуют для приложений Java. Кроме того, в корпоративной сети можно нарушать многие ограничения безопасности - авторы программ и алгоритмы хорошо контролируются, а в корпоративной сети не может появиться программа со стороны. Если, конечно, кто-то из сотрудников их туда не запустит. Но это можно проконтролировать через систему межсетевых фильтров и proxy-серверов.

Таким образом, применение Java в качестве основного инструмента разработки информационных корпоративных сетей является естественным развитием этой технологии. И именно это, в терминологии компании Sun, и называется intranet.

 

 

Microsoft и intranet

Несколько иной взгляд на intranet-систему имеется у Microsoft. Используя так же, как и Sun, в качестве отправной точки корпоративную информационную систему, Microsoft опирается только на те средства, которыми в данный момент располагает. Фактически, это набор компонентов BackOffice и ОС WindowsNT.

Если компания Sun строит intranet, опираясь на инструмент разработки, то Microsoft предлагает решения, основанные на уже существующих компонентах. В этом случае в качестве связки вовсе не обязательно использовать Java. На самом деле подход Microsoft во многом оправдан не только в плане продвижения собственной продукции компании, но и с практической точки зрения. По версии Microsoft intranet-система - это прежде всего система управления информационными потоками корпорации. Все существующие программные продукты Microsoft, такие, например, как Exchange, Word, Access, SQL Server и т. п., есть результат анализа типовых информационных потребностей компаний и, следовательно, готовые кирпичики для создания корпоративной информационной системы. В этом смысле IIS - это еще один компонент информационного обслуживания сотрудников корпорации. При этом IIS - не только Web-сервер, но и Gopher-сервер, и FTP-сервер в том числе.

В таком свете поддержка Microsoft Java выглядит шагом, направленным на получение некоторого преимущества перед конкурентами. Но здесь кроется и одна из главных проблем. Фактически, в Microsoft проглядели Internet вообще и WWW в частности, и только с конца 1995 года компания стала нагонять ушедших далеко вперед конкурентов. Широко разрекламированная точка зрения, что Microsoft вторглась в новую для себя нишу глобальных коммуникаций, глубоко ошибочна и навязывается не от хорошей жизни. Наоборот, глобальные коммуникации вторглись в сферу интересов компании, и ей не оставалось ничего другого, как заняться разработкой программного обеспечения для Internet. Весьма наглядным примером может служить электронная почта. Сначала появилась InternetMail, а уже потом интерфейс к SMTP в Exchange, что, конечно же, свидетельствует отнюдь не о прозорливости аналитиков компании. То же можно сказать и о инкапсуляции NBF в TCP/IP. Если бы все делалось честно, то завернутые в оболочку IP-пакеты должны были бы свободно проходить через любые шлюзы. Но достаточно установить Unix-систему в качестве шлюза, как организовать распределенный домен (речь в данном случае идет не о DNS), работающий с почтой, упакованной в недрах продукции Microsoft, становится довольно трудно. Да и вообще сети, построенные на широковещательных протоколах, не очень подходят для глобального информационного обмена.

Если обратиться к системе NT, как к основе среды функционирования корпоративной информационной системы, то пока именно в сетевом компоненте, связанном с TCP/IP, находят большое количество ошибок. Кроме того, замечено, что непрерывное круглосуточное функционирование системы приводит к ее постепенной деградации, выраженной в замедлении работы. Связано это скорее всего с фрагментацией оперативной памяти. Сообщения о нехватке виртуальной памяти для функционирования приложений становятся постоянной головной болью системного администратора. Если конфигурация функционирует в качестве сервера небольшой рабочей группы, который время от времени выключается, то "торможение" не проявляется. Понятно, что разработчики NT когда-нибудь, возможно, устранят этот недостаток, но ясно, что с самого начала данная ОС не была ориентирована на работу в качестве сервера глобального информационного сервиса, каким является Internet или корпоративные сети. К этому стоит еще добавить и требования к ресурсам, которые предъявляются Windows NT к аппаратуре. Там, где многие Unix-системы разворачиваются и функционируют вполне свободно, NT работает с большим трудом. Это, в частности, заставляет скептически относиться к использованию NT в качестве Web-сервера для узлов с большим числом обращений. Но для небольшого корпоративного сервера, учитывая простоту настройки IIS, данная система вполне сгодится.

 

 

⇐ Предыдущая9101112131415161718Следующая ⇒

Поделиться: