Классификация программных средств систем управления технологическими процессами
Тема 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 элементов, снижающих трудоемкость разработки. Для решения перечисленных выше задач первоначально использовались универсальные языки программирования высокого уровня и команда профессиональных программистов. Однако практика показала крайне низкую эффективность такой разработки. Оказалось, что разработка системы должна выполняться не программистами, а специалистами той предметной области, которая нуждается в автоматизации, т. е. технологами, а также системными интеграторами, которые осуществляют комплексное внедрение системы. Необходимость в разработке средств программирования, предназначенных специально для систем автоматизации и ориентированных на технологов, была вызвана следующими причинами: · требованием надежности программного обеспечения. Система, написанная целиком на алгоритмическом языке для конкретного заказа, содержала слишком много программного кода, на тщательную разработку и тестирование которого не хватало времени; · сжатыми сроками внедрения системы и ограниченной стоимостью работ. Для создания системы в короткий срок при ограниченном бюджете требовалось большое количество готовых универсальных программных компонентов, уже написанных и тщательно оттестированных; · необходимостью модификации системы в процессе ее эксплуатации. Внести изменения в специализированную программу мог только написавший ее программист, который к этому времени обычно работал уже на другом предприятии. Поэтому вместо того, чтобы модифицировать программное обеспечение, его приходилось переписывать заново; · требованиями совместимости с другими системами автоматизации, работающими на том же предприятии. Были необходимы стандартные интерфейсы между программами, созданными разными производителями на разных аппаратно-программных платформах; · высокими требованиями к качеству пользовательского интерфейса. Ограниченный бюджет времени и финансовых ресурсов не позволял разработать достаточно хороший программный интерфейс на универсальных алгоритмических языках.
Популярное: Личность ребенка как объект и субъект в образовательной технологии: В настоящее время в России идет становление новой системы образования, ориентированного на вхождение... Как распознать напряжение: Говоря о мышечном напряжении, мы в первую очередь имеем в виду мускулы, прикрепленные к костям ... ©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (1883)
|
Почему 1285321 студент выбрали МегаОбучалку... Система поиска информации Мобильная версия сайта Удобная навигация Нет шокирующей рекламы |