Создание своей SCADA или системы управления и визуализации
Небольшая предыстория: заканчиваю 4 курс, специальность системный администратор, но отработав год на заводе, оператором, проникнувшись атмосферой, грохотом насосов, турбин и компрессоров, решил рискнуть писать диплом связанный исключительно с автоматизацией промышленных систем, человек я в этом малосведущий, но поверьте желание окупит все пробелы в знаниях, за плечами есть такие языки как Pascal, Delphi, C#,Prolog, Java, совсем чуть чуть SQL. Моя проблема такова: большинство моих преподавателей на факультете(физМАТ), хорошие программисты я бы даже сказал исключительные мастера своего дела, но к сожалению никто, почти никто толком не знает не про SCADA не про программирование контролеров, а если и знают то совсем немного, так сказать слышали, но забыли.
Теперь непосредственно к вопросу: Я прошерстив пару десятков форумов и прочитав несколько статей, понял следующее, что я «примерно» хочу взяться за написание scada системы, допустим для теплообменника или какого нибудь насоса с одним контролером(плк) чтобы все это «существо» работало по канонам OPC сервера с некоторыми сообщениями аварийными/информационными выходящими на экран и записывающимися непосредственно в SQL БД , только не знаю с какой стороны к этому подойти, понимаете я хочу сделать все по уму так сказать хладнокровно не хочу с шашкой на голо. В связи с этим прошу совета с чего начать, что изучить в первую очередь или возможно мне нужно сменить тему, взять что то по проще, или подкорректировать эту тему.
Исключительная просьба не гневиться если я некоторые узко направленные фразы употребил не верно, я высоко поднимаю руку и громко говорю, что в данной теме я слабо говоря глупец. Поэтому я тут и прошу вашего совета. Заранее поклон в пояс.
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Источник
О создании собственной SCADA системы
Начну с того, что с недавнего времени я работаю инженером АСУ на сахарном заводе. Здесь много автоматики и разнообразного ПО, по большей части устаревшего. Одна из основных проблем — Scada-системы. Для нас они являются слишком дорогими, медленными и требовательными. Не стану перечислять конкретные недостатки и проблемы, скажу лишь, что у нас их немало. Исходя из вышеописанного и оценив возможности, мы решили, что стоит попробовать сделать собственную Scada-систему.
В качестве полигона для испытаний мы выбрали станцию фильтрации суспензии (говоря «мы» я имею в виду себя и своего брата — один разрабатывает скаду, другой делает проекты). Этот вариант отлично для нас подходил, поскольку часть древних панелей оператора давно вышла из строя и нужно было найти другое решение, в данном случае — переход на стационарный ПК.
Разработка проекта была скрыта от остальных, поэтому, когда нас спрашивали о том, что мы делаем, мы отвечали что это секрет. В дальнейшем, не долго думая, мы так и назвали систему: Secret-scada. Сама скада является OPC клиентом с обменом по OPC DA версии 3.0 или ниже. В качестве OPC сервера мы используем простой и качественный KEPServerEX. Во-первых, потому что он поддерживает DA 3.0, во-вторых, имеет множество драйверов для различных контроллеров (полный список вы можете увидеть здесь), стоимостью обычно не выше 895$. На нашем объекте используются контроллеры Modicon Momentum, количество используемых тегов: 700 штук. Для наглядности приведу схему передачи данных от датчика в Scada-систему. Все просто:
Сама скада использует OpenGL, либо DirectX в качестве рендера, на усмотрение пользователя. Для этой цели используется кроссплатформенный игровой движок ZenGL. Так получилось, что я с ним хорошо знаком уже много лет и не сомневаюсь в его качестве. Все текстуры и изображения создавались с использованием 3Ds Max и Photoshop. Текстуры труб, сборников и уровней, подготовлены так, чтобы растягивание этих элементов не приводило к потере качества изображения. Пользователь также может добавлять свои изображения в формате png. Многие элементы могут связываться с тегами и меняться в зависимости от значения тега. Создание и редактирование списка аварийных сообщений, также предусмотрено в редакторе проектов. Некоторые базовые возможности демонстрируются на этом видео:
http://youtu.be/epMCQnjXrvc
* к сожалению мне не удалось снять видео так, чтобы оно не тормозило. Все действия пришлось делать медленно, чтобы все было понятно. В действительности, программа работает очень шустро даже на слабых машинах.
Скриншот из редактора проектов:
Скриншот 1
При разработке скады, я хотел сделать её как можно менее громоздкой и простой. Думаю, что отчасти это мне удалось, по крайней мере, для текущего проекта. Система уже успешно отработала один свекловичный сезон и получила высокую оценку. Теперь мы планируем внедрить её на станции вакуум аппаратов. Здесь проект гораздо более глобальный, на
4000 тегов, с большим количеством мнемосхем. Также есть мысли по распространению Scada-системы для широкого круга пользователей. Поэтому сейчас ведется разработка второй версии программы. Она будет сильно отличаться от текущей версии в плане возможностей и минималистичности интерфейса. Вот как выглядит сейчас новая версия Scada-системы:
В ближайших планах создание редактора трендов, добавление возможностей ведения логов и создание встроенного веб-клиента.
Хотелось бы услышать Ваше мнение по поводу программы.
Спасибо за внимание!
Источник
SCADA: в поисках идеала
По моим наблюдениям, большинство толковых специалистов АСУ, работающих со SCADA, проходят несколько стадий «эмоционального роста»: освоение какой-либо SCADA, поиск чего-то лучшего, идеи и попытки написания своего варианта, выработка философского отношения к проблеме и использование одного из существующих продуктов.
Да, бывают исключения. Например, встречаются сильно увлеченные и упорные энтузиасты, которые создают что-то работающее, но картины они не меняют совершенно.
Попробуем разобраться, почему так происходит и может ли быть выход из этого порочного круга.
Примечание: дальнейшие рассуждения будут касаться преимущественно коммерческих продуктов, но во многом справедливы и для проектов с открытым кодом, о которых будет сказано отдельно.
В первом приближении процесс работы со SCADA-системой сводится к нескольким действиям: выбор параметров обмена данными с ПЛК, разработка мнемосхем в специальном редакторе, настройка логирования событий и состояний параметров. Для обеспечения сложного поведения графических элементов мнемосхем и несложных математических расчетов используется написание скриптов или вообще предполагается, что достаточно средств простейшей анимации, настраиваемой в редакторе.
Такой подход во многом себя оправдывает — легко обучиться, можно быстро реализовать несложные проекты. По большому счету, можно даже не иметь минимальных знаний о программировании для начала работы.
Сегодня существует довольно большое количество SCADA-систем, различающихся по своим возможностям, стоимости, удобству разработки и т.д. Казалось бы, выбирай подходящий вариант и начинай творить доброе, светлое, вечное… Но тут-то и выясняется, что все не так просто.
- Как только возникает необходимость в создании большого проекта с большим числом элементов на мнемосхемах или потребность в сколько-нибудь заметных объемах вычислений, сразу бросается в глаза очень низкая скорость работы. Особенно комично выглядит ситуация, когда приходится перекладывать расчеты на ПЛК, хотя его быстродействие несопоставимо ниже современных ПК. Чаще всего и об организации выполнения нескольких потоков также можно забыть.
Попытка сделать что-нибудь, не предусмотренное разработчиками SCADA, легко выливается в очень нетривиальные решения с огромными трудозатратами.
Закрытость внутренних механизмов и неполная документация. Например, попробуйте найти для коммерческих SCADA полноценное описание форматов хранения данных и структуры БД.
Многие авторы статей о современных стратегиях разработки ПО негативно отзываются о распространенном подходе, когда созданию нового функционала уделяется несравнимо большее внимание, чем оптимизации и тестированию кода. К сожалению, это часто наблюдается и в мире SCADA. Порой в процессе разработки приходится больше времени потратить на обхождение недокументированного поведения системы, чем собственно на разработку. А ведь это промышленные системы с повышенными требованиями к надежности.
Пару слов о системах с открытым кодом. При искреннем уважении к разработчикам мне кажется, что идея, несмотря на всю привлекательность, практически не реализуема. Причина — огромные трудозатраты при отсутствии заметного сообщества. Слишком мало людей, заинтересованных в подобном продукте и при этом способных писать качественный код на объектно-ориентированном языке, готовых тратить свое свободное время на такой проект. Собственно, осознание объемов работы для создания чего-то, способного конкурировать с существующими коммерческими продуктами, и заставляет опускать руки.
Теперь, получив представление о трудностях, попробуем сформулировать требования к идеальной SCADA и посмотрим, можно ли решить проблему, если слегка выйти за рамки традиционной парадигмы.
- Необходима высокая скорость работы. Это означает, что не должно быть никаких интерпретаторов, на выходе надо получить исполняемый машинный код.
Возможность легко и без существенных рисков изменять поведение существующих компонентов или добавлять свои.
Прозрачность форматов хранения настроек и исторических данных. К примеру, необходимость сделать специфическую выборку из архивов для построения отчетов не должна выливаться в длительный реверсинжиниринг инструментов, входящих в состав SCADA.
Простота и скорость разработки. Необходимо свести к минимуму написание кода и по максимуму использовать визуальное программирование. Если для работы над проектом по автоматизации будет необходимо затрачивать заметно большие усилия по сравнению с коммерческими SCADA, то кому это все будет надо?
Удобная и современная среда разработки (IDE). Необходимы привычные инструменты любого программиста: автодополнение кода, контроль версий и т.п.
Низкая стоимость стороннего ПО, а в идеале бесплатность и открытость исходного кода.
Отсюда напрашивается решение — надо взять существующую хорошую среду для визуального программирования и создать к ней библиотеку компонентов, заточенных под специфические задачи SCADA-систем. Рассуждая подобным образом я остановил свой выбор на Qt. Тут и масса готовых компонентов, и отличная IDE, и огромное сообщество разработчиков.
Когда я впервые познакомился с Qt, то был просто поражен внутренней логичностью и богатством этой библиотеки. Как только возникает задача сделать что-нибудь, очень часто выясняется, что это уже практически реализовано в Qt и надо просто адаптировать под свои нужды.
Когда задача правильно сформулирована, остается ее просто реализовать, что я и начал делать некоторое время назад. К текущему моменту удалось реализовать минимальный джентльменский набор компонентов.
Созданный набор можно условно поделить на несколько групп.
- Компоненты, предназначенные для обеспечения обмена данными с ПЛК
- Система тегов. Фактически, некоторый буфер между драйверами и другими частями библиотеки, обеспечивающий доступ к данным из различных компонентов программы.
- Драйвер-клиент для OPC DA2. По моему мнению, на данный момент это самый популярный способ обмена данными с ПЛК и довольно сложно найти хоть сколько-нибудь распространенное устройство без OPC-сервера.
- Система аварийных сообщений.
- Журналы технологических параметров.
- Построение графиков и трендов из журналов технологических параметров. Тут все классически — выбор и настройка отображения накопленных данных.
- Работа с аварийными сообщениями — вывод активных сообщений, подтверждение оператором (квитирование), доступ к архивной информации.
- Отображение различных элементов мнемосхем. Как показали опросы, в большинстве компаний используют собственные иконки для показа состояний технологического оборудования. По этой причине был создан компонент, позволяющий выводить графические изображения (в том числе и с эффектом мигания) в зависимости от значений тегов.
- Построение больших анимированных схем трубопроводов. Готовых аналогов мне не доводилось встречать ни в одной SCADA, а ведь потребность очевидна — попробуйте проложить маршрут в разветвленной системе с двумя — тремя сотнями задвижек.
- Набор компонентов для облегчения создания пользовательских элементов.
Конечно, предстоит пройти еще немалый путь, но уже сейчас просматривается несколько возможных направлений для применения, помимо собственно всех видов классических задач промышленной автоматизации:
- Создание утилит для решения побочных задач в уже существующих системах. Так например, мне довелось написать аналог Matrikon OPC Data Manager с более богатым функционалом, потратив на это всего около четырех часов и сэкономив довольно значительные средства.
- Разработка приложений для работы с научными приборами.
- Системы «умный дом».
Как-то незаметно для меня, мое хобби превратилось во что-то большее, вызывающее интерес у других людей. Появилась мысль превратить это творчество в стартап, но пока все упирается в недостаток людей, готовых разделить со мной эту работу. Если у Вас есть желание принять участие в развитии стартапа, встать у истоков новой компании или попробовать себя в роли сооснователя, напишите мне в личку.
Чуть больше информации можно найти на странице в Facebook.
Также буду очень благодарен за конструктивную критику и новые идеи.
Источник