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

⇐ ПредыдущаяСтр 6 из 12Следующая ⇒

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

Чем располагает разработчик промышленной системы? В первую очередь это операционные системы, поддерживающие функционирование разрабатываемого приложения. В сфере промышленной автоматизации свой мир операционных систем – ОС реального времени (ОС РВ). Для VME-процессоров, например, существует 17 ОС (OS-9/OS-9000, VRTX/Spectra, VxWorks, PDOS, pSOS+, LynxOS, VMEexec, iRMX, C-Exec, QNX и т. д.). Поскольку крупные компании-производители обеспечивают для своих процессоров и устройств ввода/вывода полную поддержку сразу нескольких ОС РВ, можно найти версии систем из приведенного списка для многих платформ: 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 [13], и рабочих станций. Третья причина состоит в наличии на платформах общего назначения широкого разнообразия инструментальных средств.

Действительно, кроме базовой поддержки, предоставляемой ОС РВ, для создания приложений разработчику требуется развитый инструментарий, которого, конечно, больше в общецелевых системах. Нельзя сказать, что ОС РВ в этом отношении бедны – в них обычно поддерживаются сетевые протоколы, 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 [10] описывает два графических языка, " Диаграмма цепей" (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).

Будущее стандарта 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, США) [2], который был признан лучшим инструментальным средством для разработки SCADA-систем на выставке-ярмарке в Ганновере. InTouch реализован для среды Windows 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, способно автоматизировать сбор данных и выдавать управляющие воздействия на производственные процессы в масштабах целого предприятия.

21. UML ПРОЕКТИРОВАНИЕ СИСТЕМ РЕАЛЬНОГО

ВРЕМЕНИ

Значительное понижение цен на микропроцессоры и полупроводниковые микросхемы и столь же существенное увеличение производительности микропроцессоров, наблюдаемые на протяжении нескольких лет, сделали рентабельными распределенные системы и системы реального времени на базе микрокомпьютеров. Сегодня большинство коммерческих, промышленных, военных, медицинских и потребительских продуктов снабжаются микропроцессорами и целиком либо в значительной части управляются программами. Такие системы встречаются в микроволновых печах и видеомагнитофонах, в телефонах и телевизорах, в автомобилях и самолетах, в подводных лодках и космических кораблях, в автоматах по продаже газированных напитков и банкоматах, в системах диагностики пациентов и системах управления производством, в контроллерах роботов и системах управления лифтами, в системах управления городским и воздушным транспортом, в электронной почте и коммерции, в «интеллектуальных» транспортных и информационных магистралях… Список можно продолжать до бесконечности. Все это параллельные системы, а многие из них являются к тому же распределенными или системами реального времени.

Объектно-ориентированные концепции особенно важны для анализа и проектирования программного обеспечения, поскольку они касаются фундаментальных вопросов адаптируемости и развития. Сравнительно недавно появившийся унифицированный язык моделирования (UML) предлагает стандартизованную нотацию для описания объектно-ориентированных моделей [3, 5, 6, 8]. Объе-динение концепций объектно-ориентированного проектирования с концепциями параллельного выполнения необходимо для успешного создания распределенных приложений, работающих в реальном масштабе времени. Поскольку UML содержит стандартную нотацию для описания объектно-ориентированных моделей, будем использовать именно этот язык. Особое внимание уделим моделированию динамики системы, представляющему интерес для приложений реального времени и распределенных приложений.

22. Объектно-ориентированные методы и UML

Объектно-ориентированные методы основаны на концепциях сокрытия информации, классов и наследования [14]. Сокрытие информации [10] позволяет получить замкнутые, а оттого в большей степени поддающиеся модификации и сопровождению системы. Наследование [14] – это систематический способ адаптации классов.

Язык UML, пришедший на смену многочисленным системам нотации и методикам проектирования, предложил нотацию для описания объектно-ориентированных моделей, которая стала промышленным стандартом [1]. Однако для эффективного применения нотации UML необходимо сочетать ее с каким-либо методом объектно-ориентированного анализа и проектирования.

В методе COMET сочетаются прецеденты использования, статическое моделирование, диаграммы состояний и диаграммы последовательности событий, которые встречаются в нескольких методах. Применяемая нотация основана на UML [3, 5]. В ходе моделирования прецедентов использования определяются функциональные требования к системе в терминах актеров и прецедентов. Статическая модель предлагает статический взгляд на информационные аспекты системы. Класс определяется в терминах своих атрибутов и взаимоотношений с другими классами. Результатом динамического моделирования является динамический взгляд на систему. Уточняются сформулированные ранее прецеденты с целью показать взаимодействие объектов, участвующих в каждом из них. Разрабатываются диаграммы кооперации и последовательности, отражающие кооперацию объектов в каждом прецеденте. Зависящие от состояния аспекты системы описываются с помощью диаграмм состояний, причем для каждого объекта составляется своя диаграмма.

В аналитической модели основное внимание уделяется пониманию проблемы: выявлению объектов предметной области и передаваемой между ними информации. Объекты и классы предметной области группируются на основе критериев выделения объектов. Рассмотрение вопросов, активен объект или пассивен, синхронно или асинхронно посылаемое сообщение и какая вызывается операция у объекта-получателя, откладывается до стадии проектирования.

На этапе проектирования среди объектов выявляются активные (их называют задачами) и пассивные (их называют объектами). Для определения задач применяются критерии разбиения на задачи. Разрабатываются также интерфейсы задач и описываются операции каждого пассивного класса.

Метод и нотация

Метод проектирования и нотация проектирования – это разные вещи. Нотация проектирования ПО предназначена для описания самого проекта. Хотя она и предполагает наличие определенного подхода к проектированию, сам подход остается за ее рамками. Метод проектирования ПО представляет собой систематическое описание этапов создания проекта.

Нотация проектирования ПО описывает проект программы в графическом или текстовом виде. В частности, диаграммы классов – это графическая нотация, а псевдокод – текстовая.

Концепция проектирования ПО – это фундаментальная идея, применимая к проектированию всей системы, например сокрытие информации.

Стратегия проектирования ПО – общий план и методика выполнения проекта. Одной из стратегий является объектно-ориентированная декомпозиция.

Критерии структурирования ПО – это эвристические или формальные правила, помогающие проектировщику разбить систему на отдельные компоненты. Так, критерии разбиения на объекты - это правила декомпозиции системы на объекты.

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

В методе COMET для описания проекта применяется нотация UML. Метод основан на следующих концепциях: сокрытие информации, наследование и параллельные задачи. Стратегия проектирования параллельно работающих объектов состоит в разбиении системы на активные и пассивные объекты и определении интерфейсов между ними. Метод COMET также содержит критерии разбиения, помогающие выделить объекты в системе на этапе анализа, а затем на этапе проектирования выявить отдельные подсистемы и параллельно выполняемые задачи.

⇐ Предыдущая 1 2 3 4 567 8 9 10 Следующая ⇒