Классификация программных средств систем управления технологическими процессами

Тема 1. Развитие программных средств автоматизации

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

· автоматизация управления технологическими процессами (АСУ ТП);

· взаимодействие системы с диспетчером (оператором);

· автоматизированный контроль и измерения (мониторинг);

· обеспечение безопасности;

· дистанционное управление, измерение, сигнализация (задачи телемеханики).

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

· OPC сервер;

· средства МЭК-программирования контроллеров;

· SCADA-пакеты.

Классификация программных средств систем управления технологическими процессами

Различают базовое и прикладное программное обеспечение (рис.1).

Рис. 1. Классификация программных средств системы управления

Ø Базовое ПО включает в себя различные компоненты, но основным из них является операционная система (ОС) программно-технических средств АСУТП. Каждый уровень АСУТП представлен «своими» программно-техническими средствами: на нижнем уровне речь идет о контроллерах, тогда как основным техническим средством верхнего уровня является компьютер. В соответствии с этим в кругу специалистов появилась и такая классификация: встраиваемоеинастольное программное обеспечение.

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

С точки зрения разработки системы управления предпочтительна такая программная архитектура, в ко­торой ПО всех уровней управления реализовано в единой операционной системе. В этом случае «автоматически» снимаются все вопросы, связанные с вертикальным взаимодействием различных программных компонент системы управления. Но на практике это далеко не так. Достаточно часто в разрабатываемых системах контроля и управления нижний и верхний уровни реализуются в разных ОС. И наиболее характерна ситуация, когда на уровне контроллера используется ОС реального времени, а на уровне оператора/диспетчера SCADA-система функционирует под Windows NT. Без специализированных решений по организации взаимодействия между подсистемами здесь не обойтись.

Ø Для функционирования системы управления необходим и еще один тип ПО - прикладное программное обеспечение(ППО).

Известны два пути разработки прикладного программного обеспечения систем управления:

- создание собственного прикладного ПО с использованием средств традиционного программирования (стандартные языки программирования, средства отладки и т.д.);

- использование для разработки прикладного ПО существующих (готовых) инструментальных средств.

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

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

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

-средства, ориентирован­ные на разработку программ управления внешними устройствами, контрол­лерами - CASE-системы (Computer Aided Software Engineering);

-средства, ориентированные на обеспечение интерфейса оператора/ диспетчера с системой управления – SCADA-системы(Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных).

Для систем автоматизации, не связанных с АСУ ТП, используются программы LabVIEW, MatLab, HP-VEE и др., ориентированные на автоматизацию эксперимента, измерений или математическую обработку их результатов. Для простых задач или широко тиражируемых приложений бывает экономически эффективно использовать заказное программирование на С++ или Visual Basic с применением покупных ActiveX элементов, снижающих трудоемкость разработки.

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

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

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

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

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

· требованиями совместимости с другими системами автоматизации, работающими на том же предприятии. Были необходимы стандартные интерфейсы между программами, созданными разными производителями на разных аппаратно-программных платформах;

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