Проектирование системы управления

Размещено на http://www.allbest.ru/

Проектирование системы управления

1. Функциональная модель системы

Для создания эффективной системы управления используются методы кибернетики и информационно-вычислительной техники. С точки зрения ее функционирования выполняет следующие задачи:

а) Сбор информации с объектов управления;

б) Переработка информации;

в) Формирования управляющего воздействия на объект управления.

Под словом «система» понимается совокупность взаимодействующих компонентов и взаимосвязей между ними. Весь мир можно рассматривать как сложную взаимосвязанную совокупность естественных и искусственных систем. Это могут быть достаточно сложные системы, системы средней сложности или сверхсложные системы. Искусственные системы, к которым относится программное обеспечение, по своей сложности занимают среднее положение.

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

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

Существуют два подхода к декомпозиции систем:

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

б) Второй, объектно-ориентированный подход, использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.

В 1970-1980 годах при разработке ПО достаточно широко применялись структурные методы, предоставляющие в распоряжение разработчиков строгие формализованные правила описания проектных решений - спецификаций ПО. Эти методы основаны на использовании наглядных графических моделей: для описания архитектуры ПО с различных точек зрения используются схемы и диаграммы. Наглядность и строгость средств структурного и объектно-ориентированного анализа позволяет разработчика и будущим пользователем системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этих методов и следования их рекомендациям при разработке конкретных систем ПО сдерживалось отсутствием адекватных инструментальных средств, поскольку при неавтоматизированной разработке все их преимущества практически сведены к нулю. Действительно, в ручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима.

Ручная разработка обычно порождала следующие проблемы:

а) Неадекватная спецификация требований;

б) Неспособность обнаружения ошибки в проектных решениях;

в) Низкое качество документации, снижающее эксплуатационные характеристики;

г) Затяжной цикл и неудовлетворительные результаты тестирования.

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

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

Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

а) высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

б) Положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

в) Приемлемый уровень отдачи от инвестиций в CASE-средства.

Для функционального моделирования системы используются следующие наиболее распространенные методологии:

а) DFD - диаграммы потоков данных;

б) Функциональная модель SADT - методология структурного анализа;

в) ERD диаграммы «сущность-связь».

Из спектра представленных методологий наиболее подходящей для построения функциональной модели объекта автоматизации является SADT, так как наиболее четко отображает функциональную структуру объекта.

Методология SADT разработана Дугласом Россом в 1969 году для моделирования искусственных систем средней сложности.

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

а) Графическое представление блочного моделирования. Графика блоков и дуг SADT - диаграммы отображает функцию в виде блока, а интерфейсы входа / выхода предоставляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются;

б) Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничения количества блоков на каждом уровне декомпозиции, связность диаграмм, уникальность меток и наименований, синтаксические правила для графики, разделение входов и управлений;

в) Отделение организации от функции, то есть исключение влияния административной структуры организации на функциональную модель.

Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

Диаграммы - главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты показаны с правой стороны.

Механизм, который осуществляет операцию, представляется дугой, входящей в блок снизу.

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

Функциональный блок и интерфейсные дуги

Выбор инструментального пакета

Построение SADT-модели заключается в выполнении следующих действий:

а) Сбор информации об объекте, определение его границ;

б) Определение цели и точки зрения модели;

в) Построение, обобщение и декомпозиция диаграмм;

г) Критическая оценка, рецензирование и комментирование.

Сбор информации об объекте, определение его границ и определение цели и точки зрения модели были освещены в первых трех главах. Критическая оценка, рецензирование и комментирование не проводится.

Инструментом моделирования выберем CASE-средство BPwin3.2.

BPwin - инструмент визуального моделирования, используется для анализа сложных технологических процессов. Дает возможность наглядно представить структуру функционирования в виде модели, что позволит оптимизировать работу технологического объекта. Таким образом, формируется целостная картина функционирования технологического объекта.

Построение диаграмм начинается с представления всей системы в виде простейшей компоненты - одного блока «Автоматизировать ЦПС-2» и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя «Центральный пункт сбора нефти №2», указанное в блоке, является общим. ТОР-диаграмма представлена на рисунке 4.2.

Блок «Автоматизировать ЦПС-2», который представляет систему в качестве единого модуля, детализируется на CONTEXT диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. CONTEXT-диаграмма представлена на рисунке 4.3. Данные блоки «Собрать данные с датчиков», «Обработать данные», «Формировать управляющее воздействие» представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Детализация CONTEXT - диаграммы представлены на рисунках 4.4 - 4.6. Глоссарий приведен в Приложении Б.

• 2. Реализации системы управления

Системные интеграторы или конечные пользователи, приступая к разработке прикладного программного обеспечения для создания системы управления, оказываются перед выбором: программировать с использованием «традиционных» средств или применить готовые - COTS - инструментальные проблемно - ориентированные средства. Конечно, качественное, хорошо отлаженное ППО, написанное высококвалифицированным программистом специально для того или иного проекта, - решение наиболее оптимальное. Но следующую задачу

Сегодня, в условиях, когда затраты на ППО все более возрастают и соответственно все более ужесточаются требования к интенсификации труда программистов, вариант с непосредственным программированием привлекателен лишь для простых систем или небольших фрагментов большой системы, для которых нет стандартных решений или они не устраивают разработчиков в принципе. В любом случае процесс разработки собственного ППО важно упростить, сократить временные и прямые финансовые затраты на его разработку, минимизировать затраты труда высококлассных программистов, по возможности привлекая к разработке специалистов в области автоматизируемых процессов. Современный бизнес в области разработки ПО заметно дифференцируется и специализируется. Причина проста - ПО становится все более сложным и дорогостоящим. Разработчики операционных систем, инструментальных средств, прикладного ПО и т.д., по существу, «говорят на разных языках». Таким образом сама логика развития современного бизнеса в области разработки ППО для конечных систем управления подталкивает к использованию все более развитых инструментальных средств типа SCADA-систем. Разработка современной SCADA-системы требует больших вложений и выполняется в длительные сроки. Именно поэтому в большинстве случаев разработчикам управляющего ППО, в частности ППО для АСУ ТП, целесообразно осваивать и адаптировать какой-либо готовый, уже апробированный, универсальный инструментарий. Если для вас это очевидно, то возникает вопрос выбора SCADA-системы. Ниже перечислены некоторые популярные SCADA-системы, имеющие поддержку в России:

а) Factory Link;

б) InTouch;

в) Genesis;

г) WinCC;

д) Trace Mode;

е) RSView;

ж) LabVIEW, BridgeVIEW, LabVIEW RT, Lookout.

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

На основе таких пакетов как Trace Mode и RSView рассмотрим некоторые основные возможности и характерные особенности SCADA-систем.

Функциональные возможности

а) Разработка архитектуры всей системы автоматизации;

б) Решение вопросов, связанных с возможной поддержкой распределенной архитектуры, необходимостью введения узлов с горячим резервированием и т.п.;

в) Создание прикладной системы управления для каждого узла, где специалист в области автоматизируемых процессов наполняет узлы архитектуры алгоритмами, совокупность которых позволяет решать задачи автоматизации;

г) Приведение параметров прикладной системы в соответствие с информацией, которой обмениваются устройства нижнего уровня с внешним миром;

д) Отладка созданной прикладной программы в режиме эмуляции и реальном режиме.

Эксплуатационные характеристики

Эксплуатационные характеристики SCADA-системы имеют большое значение, поскольку от них зависит скорость освоения продукта и разработки

прикладных систем. Рассматриваемые SCADA-системы имеют:

а) Удобство использования. Сервис, предоставляемый SCADA-системами на этапе разработки ППО, обычно очень развит. Почти все они имеют Windows-подобный пользовательский интерфейс, что во многом повышает удобство их использования, как в процессе разработки, так и в период эксплуатации прикладной задачи;

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

Технические характеристики

В силу тех требований, которые предъявляются к системам SCADA

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

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

Так, RSView поддерживает все передовые технологии MS Windows-платформах.

Для Trace Mode основной операционной системой для рабочих мест остается MS Windows. Для серверов может использоваться UNIX. В контроллерах используются DOS, Windows CE, Linux, QNX. В локальных операторских панелях будут - Windows CE, Linux.

Структура любой автоматизированной системы управления не возможна без создания технологической базы данных. Поэтому практически во всех SCADA-системах, в частности Trace Mode, RSView, осуществлена поддержка SQL-синтаксис, который не зависит от типа базы данных. Таким образом, приложения виртуально изолированы, что позволяет менять базу данных без серьезного изменения самой прикладной задачи, создавать независимые программы для анализа информации, использовать уже наработанное программное обеспечение, ориентированное на обработку данных.

Большинство SCADA-систем имеют встроенные языки высокого уровня, Visual Basic - подобные языки, позволяющие сгенерировать адекватную реакцию на события, связанные с изменением значения переменной, с выполнением некоторого логического условия, с нажатием комбинации клавиш, а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна.

Для SCADA-системы Trace Mode одной из основных функций является открытость для программирования.

Если разработчику проекта в SCADA-системе RSView не достаточно встроенных возможностей, он может автоматизировать HMI-приложения с помощью мощного встроенного языка программирования Visual Basic for Applications. Среда VBA предназначена для расширения возможностей RSView. Запускать VBA-подпрограммы можно по событию, в макрокоманде или пользователем из командной строки. Фрагменты кодов VBA, реализующие множество типовых задач, можно свободно получить на сайте производителя.

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

Желательно, чтобы она поддерживала работу в стандартных сетевых средах с использованием стандартных протоколов, а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов. Этим требованиям в той или иной степени удовлетворяют рассматриваемые SCADA-системы, с тем только различием, что набор поддерживаемых сетевых интерфейсов, конечно же, разный.

Функционально графические интерфейсы SCADA-систем весьма похожи. Системы SCADA использует современные технологии Windows и предоставляют пользователю интуитивно-понятный интерфейс для создания «экранов» - графических представлений участков технологического процесса. Каждый проект может содержать любое количество экранов, каждый из которых отображает ту или иную детализацию управляемого объекта. Экраны могут содержать как простые графические объекты, так и более сложные объекты, такие как тренды или отчеты по сигналам тревоги.

SCADA-системы предлагают ряд средств и технологий для уменьшения времени разработки и облегчения построения визуализации. Среди них:

а) Объектно-ориентированное проектирование, упрощающее реализацию проектов;

б) Большой набор графических библиотек, состоящий из сотен объектов;

в) Возможность импортировать растровую графику популярных графических форматов, а также чертежи и векторную графику, созданные в CorelDRAW или AutoCAD;

г) Возможность создавать собственные библиотеки графических объектов;

д) Использование графических объектов и элементов управления ActiveX.

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

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

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

Современные SCADA-системы не ограничивают выбора аппаратуры нижнего уровня, так как предоставляют большой набор драйверов или серверов ввода-вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Сами драйверы разрабатываются с использованием стандартных языков программирования. Вопрос, однако, в том, достаточно ли для доступа к ядру системы только спецификаций, поставляемых фирмой-разработчиком в штатном комплекте, или для создания драйверов необходимы специальные пакеты, или же вообще разработку драйвера нужно заказывать у фирмы-разработчика. Для подсоединения драйверов ввода-вывода к SCADA используются два механизма - стандартный DDE и обмен по внутреннему протоколу. Взамен DDE компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами - OLE. Механизм OLE поддерживается в RSView, Fix, InTouch, Factory Link и др. На базе OLE появляется новый стандарт OPC, ориентированный на рынок промышленной автоматизации. Новый стандарт, во-первых, позволяет объединять на уровне объектов различные системы управления и контроля, функционирующие в распределенной гетерогенной среде; во-вторых, OPC устраняет необходимость использования различного нестандартного оборудования и соответствующих коммуникационных программных драйверов.

Многие компании занимаются разработкой драйверов, другого программного обеспечения для SCADA-систем. Этот факт очень важен при выборе SCADA-пакета, поскольку это расширяет область применения системы непрофессиональными программистами.

Стоимость SCADA-систем зависит от следующих факторов:

а) Стоимость программно-аппаратной платформы. Стоимость программно-аппаратной платформы определяется требованиями, которые необходимы для функционирования SCADA-системы. К этим требованиям относятся минимальные характеристики аппаратной платформы, операционная система, на которой будет исполняться выбранная SCADA-система.

б) Стоимость системы. Механизм определения цены у разных фирм-разработчиков различен. Например, стоимость SCADA-системы RSView зависит от количества каналов ввода / вывода, которые должна поддерживать система, а пакет Trace Mode имеет высокую базовую стоимость, но не имеет ограничений по количеству каналов;

в) Стоимость освоения системы. Процедура освоения SCADA-систем достаточна проста с точки зрения программиста и не требует длительного времени, поэтому данные затраты относительно невелики. Основной составляющей стоимости является оплата труда программистов, осуществляющих эту работы;

г) Стоимость сопровождения системы.

Характеристики SCADA-систем

К сожалению, отсутствуют методики определения надежности SCADA-систем, хотя важность этого критерия составляет, по оценкам специалистов, около 70%. Косвенным показателем «Надежности» пока считается количество инсталляций. Как известно, Trace Mode является лидером по количеству внедрений в России.

Критерий «Обмен данными» и критерий «Удобство работы» делят второе и третье место соответственно. Важными подкритериями критерия «Обмен данными» являются поддержка стандартных сетевых протоколов и форматов данных, включая Web-технологии, наличие встроенных драйверов к отечественным и зарубежным контроллерам, а также производительность системы. По количеству встроенных драйверов к отечественным контроллерам и по производительности Trace Mode значительно опережает зарубежные.

Критерий «Удобство работы» вызывает наибольшее число споров. Это универсальность и наличие стандартных языков математического описания данных и процессов, удобство пользовательского интерфейса, качество графики и стандартных изображений, возможность автоматического построения проекта, эмуляция работы. По всем этим подкритериям впереди Trace Mode, за исключением, пожалуй, работы с редактором представления данных.

Четвертое место занимает критерий «Технической поддержки». Как правило, западные пакеты проигрывают по русификации документации и, тем более, программного обеспечения, по «либеральности» технической поддержки, наличию «горячей» линии, а главное, по возможности поддержки от разработчика. Бесспорный лидер здесь - Trace Mode.

Важнейший до недавнего времени российский критерий «Цена» переместился за последние 2 года на последнее 5-е место. Здесь существенным является зависимость цены системы от конфигурации, возможность получения новых версий и бесплатного обновления релизов, наличие бесплатной системы разработки. По всем этим трем показателям позиции Trace Mode намного предпочтительней.

Проведя анализ SCADA-пакеты пришли к выводу, что наиболее подходящим является инструментальный пакет Trace Mode.

Программирование РС-контроллеров производится при помощи редакторов SCADA Trace Mode, либо с использованием специальной системы программирования - Микро Trace Mode. Микро Trace Mode включает в себя Редактор базы каналов и исполнительную систему - Микро МРВ с лицензией на 12 контроллеров.

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

В Микро МРВ встроены драйверы плат ввода-вывода Micro PC, Advantech PCL, MIC2000, ADAM 4000, ADAM 5000, ROBO, KRUIZ, MFC и так далее. Формат драйвера для связи с любыми УСО открыт и документирован. При необходимости, пользователь может написать драйвер самостоятельно, как TSR-программу MS DOS. Связь между РС-контроллером, работающим под управлением Микро МРВ и операторской станцией может осуществляться через последовательный интерфейс RS 232/485, модем по выделенной линии, Ethernet, Arcnet и так далее.

Согласно вышеперечисленным критерия выбора микроконтроллера в п. 3.6, наиболее полно удовлетворяет предъявленным требованиям продукция фирмы Advantech. Серия MIC представляет собой функционально полный набор плат, устройств, аксессуаров и программного обеспечения для построения систем автоматизации любой сложности.

Таким образом, в состав этой серии входит семейство высокопрочных промышленных компьютеров, для которых характерна гибкость IBM PC совместимых вычислительных систем. В основу изделий положена открытая технология пассивной объединительной платы с магистралью ISA, что обеспечило возможность создания модульной конструкции, применение которой позволяет сократить время и затраты на обслуживание системы, а также существенно упростить ее последующую модернизацию. Благодаря высокой механической прочности, применение изделий серии MIC-2000 оптимально в жестких условиях эксплуатации при наличии вибрационных и ударных нагрузок, когда использование обычных офисных персональных ЭВМ невозможно.

Основные характеристики MIC-2000:

а) Возможность монтажа на панель или в 19-дюймовую стойку;

б) 8- или 11-позиционные пассивные объединительные платы с магистралью ISA;

в) Сокращение времени технического обслуживания за счет модульной конструкции;

г) Возможность фронтального подключения каналов ввода-вывода;

д) Порядок проводного монтажа, аналогичный используемому в системах на базе ПЛК;

е) Устойчивость к механическим воздействиям за счет фиксации модулей с 4 сторон;

ж) Удобство установки и извлечения модулей благодаря наличию ручек-экстракторов;

з) Защита от пыли путем создания положительного давления воздуха в пределах конструктива;

и) Наличие сменного воздушного фильтра;

г) Сменный блок питания мощностью 250 Вт.

кибернетика моделирование интерфейсный блок

Размещено на Allbest.ru