Программное обеспечение систем управления [10]

Структура программного обеспечения (ПО). Программное обеспечение является такой же неотъемлемой частью современной системы, как и аппаратное обеспечение.

Часть программного обеспечения - системное ПО, обычно поставляется фирмой и рассчитано на конкретную вычислительную платформу. Функционально близко к системному программному обеспечению находится специальное программное обеспечение, предназначенное не для автоматического управления, а для оперативного наблюдения за ходом процессов в системе, ведения архивов, отчётов, наглядного представления текущих параметров процессов, организации виртуальных измерительных приборов, дисплеев и т.п. Эти системы обычно не работают в жёстком реальном времени. Имеется достаточное количество таких готовых систем (Trace Mode, UltraLogik и др.). В целях обеспечения независимости от производителя, а также в целях повышения надёжности и проблемной ориентированности часто такие системы создают специально.

Другая часть программного обеспечения - драйверы устройств, должна быть результатом согласования фирм-разработчиков устройств и фирм-разработчиков системного ПО. Согласование достигается путём следования стандартам разработки драйверов.

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

Системное программное обеспечение. Возможность работы в реальном времени, обеспечение высокого уровня надежности при работе, поддержка стандартов на все виды интерфейсов - все эти требования позволяют выделить промышленные вычислительные системы в отдельный класс. Основное требование (помимо надёжности), предъявляемое к вычислительным системам данного класса, - это гарантированное время реакции на произошедшее событие. Из данного условия сразу можно выделить отличительные качества промышленных вычислительных систем:

- адаптация вычислительного блока к датчикам и периферийным устройствам;

- использование распространенных и проверенных промышленных стандартов;

- использование операционных систем реального времени (ОСРВ).

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

- обеспечение бесконфликтного взаимодействия параллельных задач с аппаратурой;

- бесконфликтное разделение ресурсов вычислительной системы (память, диски и т.п.);

- обеспечение надежной передачи данных между процессами в адресных пространствах;

- обеспечение стандартных средств доступа к ресурсам;

- обеспечение стандартных телекоммуникаций и сетевой поддержки;

- поддержание службы времени (системных и сетевых таймеров);

- создание вычислительной среды повышенной надёжности;

Но ОСРВ эти функции выполняет за гарантированное и известное время.

Многие современные операционные системы, способные обрабатывать "на лету" поступающие запросы, в какой-то степени можно отнести к операционным системам реального времени. Как правило, такие операционные системы являются клонами ОС UNIX, где основным принципом построения ОС является разделение времени с целью предоставить каждому пользователю свой ресурс.

Главный критерий, по которому операционные системы можно разделить на обычные и операционные системы реального времени, - это детерминированная, строго определенная задержка времени ожидания или прерывания, необходимая процессу, прежде чем он получит управление. В ОСРВ различают два основных элемента - это время отклика и детерминизм. Время отклика определяет, как часто система может "отвечать" в среднем. Детерминизм - это показатель наибольшей задержки системы. Некоторые операционные системы, например DOS, являются недетерминированными и непригодны для использования в реальном масштабе времени.

Системы реального времени также делятся на "soft real-time" и "hard real-time" - мягкое реальное время (МРВ) и жёсткое реальное время (ЖРВ). Для МРВ-систем возможна потеря внешнего события (прерывания) без оказания серьезного влияния на систему в целом. Потерянное прерывание в ситуации с ЖРВ имеет серьезные последствия, как например, "потеря" аварийной ситуации в системе исключения столкновений на авиалиниях. Следует также понимать, что ЖРВ не связано с абсолютными значениями времени реакции ОС, так как есть процессы со временами работы, исчисляющимися сотыми долями секунды (например, в энергетических системах), а есть такие, для которых характерные постоянные времени равны часам (тепловые процессы).

В настоящее время интерес к операционным системам реального времени очень велик и известно множество ОС реального времени. Каждая из ведущих фирм-производителей, выпускающих промышленные компьютеры, обязательно имеет версию своей операционной системы для работы в реальном масштабе времени. Для компании Hewlett-Packard (HP) - это HP RT, для компании SGI - это ОС REACT, а для систем фирмы Motorola - это целое семейство различных ОС РВ.

Прикладное программное обеспечение для САУ можно разбить на следующие группы:

- дополнение к операционной системе (драйверы и т.п.);

- программы управления, передачи данных, обработки данных, планирования и т.п., то есть прикладные вычислительные задачи;

- программное обеспечение локальных регуляторов. Эта часть программного обеспечения часто создаётся для специализированных микроконтроллеров.

Для создания этих разнородных частей прикладного программного обеспечения используются разные методы программирования. Наиболее традиционной частью являются прикладные вычислительные задачи, для которых стараются использовать программирование на языках высокого уровня. Обычно здесь удаётся обойтись программированием на языке С, С++, Pascal, привлекая для этого интегрированные среды типа Visual C, Builder или Delphi.

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

- При разработке проекта стараться обеспечить однородность вычислительной платформы, что позволит в дальнейшем упростить программирование. Реально это означает, что целесообразно в локальных системах использовать не специализированные микроконтроллеры, а PC-совместимые контроллеры. Но в ряде задач наиболее эффективны именно специализированные контроллеры, как, например, специальные DSP-процессоры в задачах цифровой обработки сигналов.

- При разработке микропрограмм для локальных контроллеров необходимо тщательно обосновывать выбор контроллеров, причём, основным аспектом является не экономический, так как стоимость микроконтроллеров постоянно снижается, а системный.

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

Международная Электротехническая Комиссия (МЭК) в 1993 г. утвердила стандарт IEC 1131-3. Этот международный стандарт входит в группу IEC 1131 стандартов, которые охватывают различные аспекты использования программируемых логических контроллеров (ПЛК). Стандарт IEC 1131-3 описывает синтаксис и семантику пяти языков программирования ПЛК.

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

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

- закрытость исходных кодов (и в смысле недоступности, и в том смысле, что пользователь не заинтересован разбираться в чужих кодах);

- неоптимальность кодов именно для той конкретной ситуации, в которой находится данный разработчик системы автоматики ("универсальное - значит не оптимальное").

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

Чтобы добиться абсолютно предсказуемого поведения программного обеспечения с учётом работы в реальном времени разработчик автоматических систем вынужден создавать и собственное программное обеспечение. Наиболее целесообразный подход здесь следующий:

- по мере возможности пользоваться языками высокого уровня;

- лишь в случае нехватки быстродействия или надёжности использовать Ассемблер.

Такой подход позволит инженеру в области автоматики решить сразу две задачи:

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

- добиться существенной экономии времени разработки программного обеспечения. Известно, что наиболее "расточительно" в этом смысле программирование на Ассемблере.

Стандартными средствами во всех случаях являются специальные программные продукты, предназначенные для разработки программного обеспечения: редакторы, трансляторы, компоновщики, отладчики. Наиболее целесообразно использовать специальные интегрированные среды разработки, объединяющие все эти средства. Такие среды разработки имеются практически для всех языков программирования.

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

- обеспечение разработчиком сервисных услуг;

- наличия доступной технической документации, в том числе, открытых кодов программ;

- использование при разработке средств, доступных пользователям;

- минимизация зависимости программного обеспечения от разработчика. Ключевым в этом вопросе является использование промышленных методов создания программного обеспечения.

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

литература

1. Мирошник И.В. Теория автоматического управления. Линейные системы: Учебное пособие для вузов. - СПб.: Питер, 2005. - 336 с.

4. Орлов А.И. Менеджмент: Учебник. – М.: "Изумруд", 2003. URL: http://www.aup.ru/books/m151/

10. Туманов М.П. Технические средства автоматизации и управления: Учебное пособие. – М.: МГИЭМ, 2005, 71 с. URL: http://rs16tl.rapidshare.com/files/21651582/2889232/ Tehnicheskie_sredstva_avtomatizatsii_i_upravleniya.rar

11. Михайлов В.С. Теория управления. – К.: Выща школа, 1988.

Главный сайт автора ~ Лекции по ОТУ

О замеченных опечатках, ошибках и предложениях по дополнению: [e-mail].

Дата добавления: 2015-04-29