Как написать scada

Как я СКАДу писал

Введение

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

В свободное от основной работы время я помогал людям и знакомым из этой сферы по их проектам в качестве факультатива. Благо за долгие годы работы в этой сфере у меня накопилось много хороших контактов, да и репутация моя как инженера хорошо окрепла. Иногда меня даже официально выкупали у компании на конкретные проекты как разработчика-консультанта. Мои проекты и опыт работ в области АСУТП можно посмотреть здесь.
Изначально занимался системами автоматизации для диспетчеризации инженерных систем зданий по Москве. Потом, с развитием интернет технологий, появилась возможность разрабатывать проекты для удаленных объектов в других городах. Заказчик подключал выделенный защищенный канал связи с объектом через интернет, что позволяло напрямую подключаться к объекту и вести наладку и доводку проекта прямо из дома. Продолжал работать на том же ПО, что и ранее, потому как наиболее подходящих альтернатив пока не наблюдалось, да и уже были очень хорошие наработки и опыт предыдущих разработок, который не хотелось просто так оставлять при переходе на новые системы.
В процессе работы над проектами дорабатывал саму СКАДу своими собственными заплатками, которые позволяли подменять штатный функционал пакета в силу его неудовлетворительной работы или неспособности реализовать те или иные требования. За время такой доработки система стала походить уже на некоторое ядро, которое было обвешано внешними утилитами и сервисами как новогодняя елка игрушками. И вот, посмотрев на результат таких издевательств над пакетом, стала закрадываться крамольная мысль: а собственно говоря, зачем нам кузнец? Кроме того сильным стимулом стало еще то, что компания-разработчик СКАДы так и продолжает свой путь накопления багов и глюков, выпуская все новые релизы, не занимаясь нормальны тестированием и проработкой архитектуры продукта. А так как я занимался некоторыми разработками в свободное время, мне стало сильно жаль убитого своего свободного времени на разборки по багам чужой системы, которые зачастую длились по полночи и так по несколько ночей подряд. Да и заказчики стали возмущаться: за что такие деньги уплачены, то куча ошибок вылезает при пуско-наладке по базовому функционалу, то этот самый функционал реально-то не дотягивает до заявленного и надо что-то стороннее подключать или разрабатывать, хотя маркетинговые напевы продажными менеджерами про мега-мощь пакета для заказчика были напеты про совершенно обратное. В итоге перелив эмоций через край усадил меня за баранку пылесоса (читай ПК), и я решил написать свою собственную СКАДу.
Так как это в первую очередь инструмент для себя, то и делать я его решил не как того требуют рекламные лозунги, а так как этот инструмент вижу я как разработчик проектов АСУТП. В качестве основной архитектуры системы была выбрана архитектура уже известного мне за долгие годы работы СКАДа-пакета. Изобретением велосипеда я решил не заниматься, а уделить внимание его функционалу.
Все было бы замечательно, если бы не одно НО – изначально я не программист, а автоматчик. То, что писал свои собственные утилиты для пакета – было что-то вроде стороннего увлечения, хобби так сказать, ради которого начал изучение технологии .Net и языка программирования С#. До того ничего подобного серьезного я не делал и многие мои познания в области программирования и некоторых технологий были на уровне – где-то слышал, или уже видел как это работает у кого-то. Однако – глаза боятся, а руки делают.
Многие мои знакомые и сослуживцы, узнав про мою идею, реагировали на это как один — вращая указательным пальцем у виска. Конечно, все бренды в этой области делаются командами разработчиков годами, и годами же вылизываются, чтобы хоть немного приблизиться к совершенству. Но, не смотря на такую реакцию, я все же начал выполнять задуманное. А тут еще и фраза Чингисхана где-то услышанная стала просто моим девизом: «Если боишься – не делай, а если делаешь – не бойся!». Взяв в руки клавиатуру, я засел за проектирование своей первой серьезной системы. Оглядев получившийся фронт работ, начал обкладываться книгами по программированию на С#, а также ссылками на тематические форумы, где черпал всю необходимую информацию по принципам реализации тех или иных функций в пакете. Но об этом чуть ниже и по порядку.

Архитектура

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

В центре – математическое ядро, которое выполняет пересчет структуры проекта, состоящей из некоторой базы переменных, связанных между собой логическими связями. Кроме базы в проекте присутствуют алгоритмы, с которыми также связаны переменные проекта. Эти алгоритмы создает разработчик проекта, они выполняют функции управления и мониторинга технологического объекта через базу переменных, которые связаны с самим объектом управления (датчиками и исполнительными механизмами) через подсистему ввода/вывода посредством аппаратуры (контроллеры, платы ввода/вывода, устройства распределенного сбора данных и управления). Для того, чтобы оператору (если таковой в системе подразумевается) все это красочно и интуитивно понятно продемонстрировать, а также предоставить ему возможность управлять ходом технологического процесса предусматривается подсистема графического ввода/вывода, которая в виде мнемосхем отображает заранее разработанные экраны технологических элементов системы (графические примитивы, изображения, индикаторы, тренды, наборы графических объектов, состоящих из штатных примитивов) и разного рода элементов управления (кнопки, ползунки, области реакции на клик мышкой и прочее). Так как система подразумевает функцию ведения истории по ходу технологического процесса – параметры базы переменных обязательно должны иметь возможность сохраняться в некоторые архивы, чтобы их затем можно было поднимать на тренды или отчеты с целью анализа ситуаций технологами и оперативным персоналом. Также в эти же архивы должны сохраняться журналы по событиям в системе – это некие текстовые сообщения с определенными категориями (сообщение, предупреждение, авария, ошибка, действие оператора), метками времени возникновения, квитирования их оперативным персоналом и текстом, описывающим суть события. Всем этим должна будет заниматься подсистема архивирования данных и журналирования событий. Так как проект АСУТП зачастую представляет собой многоузловую систему, состоящую из нескольких операторских мест, серверных узлов, узлов контроллеров на нижнем уровне, шлюзовых машин, все это объединяется сетью по технологии Ethernet и требует оперативного взаимодействия в квази-реальном режиме времени. Осуществлять такое взаимодействие должна подсистема сетевого обмена. Вот вкратце общая архитектура комплекса. Теперь перейдем конкретно к технологиям, которые потребуются для реализации этих подсистем:

Математическое ядро

– здесь основной упор должен быть сделан на разработку объектно-ориентированной модели внутренней структуры самого проекта, состоящего из неких компонентов (переменные проекта), которые представляют собой потомков от базового класса с определенным набором свойств, интерфейсов и методов, реализующих алгоритмы обработки данных по переменной в режиме квази-реального времени (фильтрация сигнала, масштабирование, произвольный алгоритм обработки пользователя на основе разработанной программы, или это фиксированный функционал в зависимости от типа переменной). Обработка данной базы вычислителем ядра в процессе выполнения проекта на узле операторского АРМа (Автоматизированное рабочее место оператора) или контроллера выполняется циклически с некоторым заданным циклом пересчета, что позволяет организовать непрерывное выполнение логики в исполнительном модуле.

Алгоритмы

– отдельная тема для обсуждения. Исторически сложилось так, что автоматчик изначально не программист и знание языков высокого уровня для него не есть обязательное требование. Кроме того требования по поддержке и читабельности алгоритмов другими разработчиками привели к тому, что в данной области появился международный стандарт (IEC61131.3) на 5 языков программирования – три из них визуальные, два текстовые. Многие производители СКАДА-систем помимо стандарта также поддерживают скрипты — программирование на языках высокого уровня (например VB), или им подобные (например Ci-code, нечто Си-подобное). Моя система тоже не стала исключением в этом смысле, но об этом я расскажу в отдельной статье, которую планирую посвятить своему редактору алгоритмов. Технологии, которые рисовались в этом направлении меня отнюдь не радовали, ведь для реализации подобной задачи необходимо: написать свой собственный редактор (особенно интересным была задача создания редактора для визуального языка программирования), компилятор, а также вычислитель для исполнительных модулей, который бы выполнял и просчитывал алгоритмы в проекте при запуске проекта в режиме непрерывного выполнения на объекте. Перспектива рисовалась та еще, начал даже запасаться тоннами литературы по этой тематике и готовиться к штудированию принципов построения компиляторов, чтобы осилить сей труд. Но о деталях чуть позже.

Графическое ядро

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

1. Красивым (очень часто на красивость интерфейса клюет конечный заказчик, много рюшечек и анимашек ошибочно воспринимается им как прямое доказательство крутости системы, а для начальства так вообще первый признак оценки системы для принятия решения о ее закупки).
2. Функциональным
3. Удобным в разработке

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

Подсистема архивирования и журналирования

– данный раздел был серьезным камнем преткновения в той СКАДА-системе, в которой я до этого работал. Там разработчик пошел по пути изобретения велосипеда и закрытости архивов для внешних средств, что автоматически делало систему неудобоваримой во многих проектах, так как требовалось иметь доступ к архивным данным также и сторонним средствам. А баги в реализации делали ее просто нефункциональной при серьезном применении в больших проектах. Кстати, все это заставило многих пользователей вообще отказаться от штатной системы архивации. Основными требованиями к данной подсистеме в первую очередь стояли: ее открытость и удобный доступ в информации для анализа и генерирования отчетных форм оперативным персоналом системы управления технологическим объектом. Самое удобное решение этого вопроса – применение реляционной СУБД. Многие бренды, кстати, тоже идут именно этим путем, хранят исторические данные и журналы именно в реляционных СУБД. Это, наверное, единственный вариант подсистемы, с которым я в той или иной мере косвенно уже работал, потому как одной из заплаток для СКАДы до этого я делал как раз именно подсистему сбора и архивации данных и журналов событий от СКАДы во внешние реляционные СУБД. Следуя своим текущим решениям, я выбрал в качестве основы СУБД MySQL, а в качестве провайдера связи современную технологию ADO.Net.

Подсистема ввода/вывода для обмена с оборудованием

– в данной подсистеме основной вопрос заключается в поддержке достаточно распространенных открытых международных стандартов от производителей железа для автоматизации (примером может служить протокол ModBus во всех его реализациях), а также программных интерфейсов для обмена с внешним ПО (здесь первоочередную роль играет интерфейс ОРС – OLE for Process Contol). По данной тематике также панирую отдельную статью, где опишу свое видение реализации поддержки оборудования в своем программном комплексе, особенности реализации и что из этого получилось.

Подсистема сетевого обмена между узлами проекта

– в силу того, что не все проекты по автоматизации ограничиваются одним единственным АРМом оператора, а состоят из множества узлов, между ними требуется механизм обмена данными. Причем данными как реального времени (оперативными), так и архивными (вектора данных с метками времени, выборки, массивы). Данный раздел системы пока находится в процессе разработки, поэтому более подробную информацию подготовлю и опубликую чуть позже, как только будет выполнена основная работа по разработке.

Что из этого всего получилось на текущий момент

Начал я свои работы в данном проекте с нуля в прямом и переносном смысле где-то в апреле 2010-го года. Работал в свободное время в основном по вечерам. Практически получился гараж-стартап, потому как для работы оккупировал в однокомнатной квартире кухню, где засиживался порой до утра, набивая код и штудируя литературу. Вся разработка основных компонентов заняла чуть меньше года: осенью сделал ядро, визуальный редактор алгоритмов, редактор структуры проекта, разработал модель проекта и структуру файла-хранилища проекта (все на базе формата XML). Тогда же прописал подсистему архивации, ее основной движок в ядре рантаймов исполнительной системы. Под Новый Год приступил к графическому редактору. Хвала новогодним каникулам, было время основательно изучить данный вопрос и выбрать правильный путь. К началу весны я уже практически закончил графику и весной доработал математический движок поддержкой алгоритмов на чистом С#. В начале лета доработал немного подсистему ввода/вывода по части поддержки интерфейса ОРС. А сейчас занимаюсь подсистемой сетевого обмена.

Вот некоторая функциональная статистика по проекту:

1. Есть инструментальная система и два рантайма (исполнительные модули, под которыми запускается исходный проект автоматизации на объекте): один для MS Windows (для АРМов), другой под WinCE (для контроллеров).
2. Рантайм под винду поддерживает и графику и математику. Под WinCE — только математику, потому как в контроллере пока графика не особо требуется.
3. Сама система поддерживает два языка программирования: FBD и чистый С#
4. В самой системе на уровне ядра разработал собственную модель работы с данными — система работает не с типами данных, а с понятием «объект». Отсюда получилось много интересного в области приведения типов на уровне функционала системы: например единый арифметический FBD-блок сложения, благодаря этой технологии, может складывать не только числа, но и строки, или вообще разные типы данных между собой
5. Реализовал возможность работы и обработки в системе динамических массивов, а с помощью своей модели обработки данных они могу быть смешанного типа и разного функционала: здравствуйте локальные архивы и буферы для систем ПАЗ и РАС! Возможность алгоритмической обработки динамических массивов любого типа данных. Такое во многих СКАДА-пакетах просто невозможно в принципе.
6. Вся архивация и журналы событий полностью в реляционную СУБД — пока MySQL.
7. Поддерживается файл сохранения состояния системы между рестартами рантайма (дамп). Формат дампа — XML.
8. Благодаря тому, что сам проект хранится в открытом формате XML, система позволяет с помощью обычных репозиториев вести групповую разработку проекта.
9. Весь импорт-экспорт (экраны, программы, сам проект), даже графических библиотек построен на формате XML, полностью открыт и может быть использован разработчиком по своему усмотрению для работы с ним своими или сторонними средствами.
10. По графике постарался максимально приблизиться к качеству современных систем, но при этом не ориентироваться на очень мудреные технологии ускорения графики, которые по большей части зачастую не ускоряют ее, а только утяжеляют и тормозят ее на практике, но это не помешало сделать ее красивой. Для примера – несколько примеров графических экранов:

    Скриншот №1
    Скриншот №2
    Скриншот №3
    Скриншот №4
    Скриншот №5
    Скриншот №6
    Скриншот №7
    Скриншот №8

    А здесь примеры сравнения экранов для одинаковых проектов в моей системе (слева) и одного из брендов (справа):

    Скриншот №1
    Скриншот №2

Очень большой упор сделан в инструментарии на отладочные функции по проекту, поэтому инструменталка поддерживает:

1. Онлайн редактирование алгоритмов прямо в процессе выполнения проекта в отладчике.
2. Онлайн редактирование графических экранов — также прямо в процессе выполнения проекта в отладчике.
3. Онлайн редактирование структуры проекта — тоже в процессе его выполнения в отладчике (вообще, сама скада получилась как единая среда для онлайн разработки).
4. Встроенный корректор проекта — умеет отслеживать логические ошибки, который мог допустить разработчик и указывать на них с автопозиционированием на компонент проекта, где эта ошибка найден.
5. Встроенный автоматический тестировщик проекта — позволяет создавать сценарии автопрогонки проекта, вплоть до прокликиваний экранов графики, с целью проверки его корректности.
6. Встроенный механизм разработки математических моделей на основе штатных алгоритмов на FBD или C#, которые подключаются к описателям аппаратуры и проект может быть переведен на отладку на модели вместо реального железа и обратно практически в один клик.
7. Встроенный отладчик в среду разработчика позволяет отлаживать проекты с распределенной архитектурой как единого целого в рамках одного ПК, с имитацией межузловых связей и возможностью добраться, отследить и поменять руками любой параметр системы в процессе отладки.

На текущий момент для обмена с внешним и устройствами поддержаны следующие интерфейсы:

1. ModBus TCP (поддерживается RTU, но пока не включен)
2. ОРС DA
3. Поддержка протолока ICP-CON: УСО серии I-7000

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

Также есть возможность посмотреть демо-ролики, демонстрирующие принципы работы системы.

Онлайн редактирование алгоритмов на FBD в процессе отладки проекта:

Онлайн редактирование графики в процессе отладки проекта:

Демонстрация возможностей движка по обработке типов в реальном времени (программах на FBD):

Пример проекта с алгоритмом на C# — демонстрируется формирование отчета в HTML-формате:

Пример работы автоматического корректировщика проекта:

Пример разработки простого проекта. Сюжет такой: разрабатывается простейший проект, в котором контроллер связан с модулем УСО I7017 от ICP-DAS, первый вход модуля подключен к датчику.
Значение этого датчика из контроллера поднимается в АРМ-оператора. Демонстрируется отладка проекта:

1. Сначала в отладчике просто вручную проверяется работа проекта, значение входа датчика задается вручную, потом через панель УСО отладчика
2. Затем внутри проекта штатными средствами создается математическая модель имитатора на FBD и подключается к УСО
3. Проверяется работа проекта с этим имитатором в отладчике. В реальном времени имитатор можно отключать или подключать одним кликом мыши
4. Не останавливая процесс отладки редактируется математическая модель имитатора, который мы подключили к УСО
5. Не останавливая процесс отладки проекта редактируем параметры проекта — первичную обработку сигнала в виде множителя в канале

Ну и так далее вплоть до графики… Весь проект, любой распределенной архитектуры, даже без наличия железа, просто создавая модели имитаторов прямо в проекте и линкуя их на УСО создаем, редактируем и отлаживаем весь проект на одном ПК.

Быстрое дублирование наработок в графике с удобной перепривязкой динамизированных свойств в копируемой группе графических элементов. То есть — разработчику не надо вручную перебирать все свойства в новой скопированной группе, чтобы привязать ее к новым аргументам для динамизации нового экземпляра — система сама автоматически сканирует группу и составляет список привязок, где уже операцией DnD разработчик быстро переназначает привязки.
Ссылка для загрузки

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

Функции Drag-n-Drop при перемещении элементов графики между группами, перемещении заготовок в библиотеку. Импорт-экспорт библиотек во внешние файлы в открытом формате XML для обмена с другими разработчиками или сохранения наработок для будущего использования.

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

Пример симбиоза двух языков в рамках единого алгоритма программы: FBD + код на C#.

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

Векторная анимация в графике: перемещение по узловым точкам. Числовой параметр.

Строковый параметр.

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

Блок гистограмм.

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

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

Ниже пример как легко и быстро в проекте штатными средствами можно создавать математические модели объекта для отладки проекта. Модель может быть разработана как алгоритм проекта, данный алгоритм привязывается к устройству ввода-вывода в проекте, подменяя своей логикой реальный ввод-вывод, если установлен флаг имитации по данному устройству. Помимо точек ввода-вывода в алгоритм имитатора также можно линковать любой из параметров проекта как на чтение, так и на запись. Таким образом можно создавать достаточно комплексные и интеллектуальные модели имитации, которыми можно будет управлять даже с операторского интерфейса. Смена режима работы в проекте УСО через модель или через реальную железку (интерфейс) осуществляется в один клик. Проект с имитаторами, будучи загруженный в исполнительный рантайм, может работать на этих имитаторах вообще без реального железа, полностью имитируя работу системы на алгоритмах разработчика. Кроме того — даже внутри самой среды разработки в Отладчике проекта есть поддержка имитаторов проекта, управлять которой можно вообще в режиме онлайн выполнения проекта в Отладчике: ставить флаг имитации по УСО и видеть как отлаживаемый проект работает на модели, снять флаг имитации и работать с любой из точек ввода-вывода проекта в ручном режиме задания в Отладчике.

В системе предусмотрена возможность работы с динамическими массивами любого типа данных. Причем допускается их передача и прием в программы для алгоритмической обработки. С помощью каналов динамических массивов можно создавать локальные архивы в АРМах и контроллерах, сами массивы можно сохранять в любой момент в отдельные файлы формата CSV, XML или DAT. Кроме того их можно передавать по сетке и сохранять в архивы. Достаточно широкие возможности по применению. Одним из режимов работы массива может быть упаковка или распаковка аргументов: например, данные с аргументов этого канала упаковываются в массив и передаются в программу, там обрабатываются, а результат снова передается одним массивом через один аргумент программы обратно в канал динамического массива, который снова распаковывает его в аргументы. Если у аргументов есть привязки — то данные собираются или распределяюся по атрибутам каналов узла, где создан этот канал. Все это выполняется за 1 такт. То есть, теперь работать с группой данных по проекту можно легко и без лишних телодвижений.

В инструментарий разработчика входит встроенный автоматический тестировщик проекта. Данный сервис позволяет разработчику создавать журналы проверок, которые содержат списки действий, которые необходимо выполнить. Каждое действие — это по сути посылка некоторого определенного значения в компонент системы, затем разработчик проверяет результат этого действия как некоторое значение в определенном компоненте системы. Как обычно в других скада-системах этот процесс выполняется всегда вручную, разработчик раз за разом прогоняет вручную значения по компонентам системы и проверяет по результатам работу логики, прохождение канала обработки значения и прочие вещи. Данный сервис позволяет именно автоматизировать этот процесс, чтобы прогон такой операции в отладчике выполнялся автоматом с фиксацией результата в виде отчета. Каждый журнал проверок, создаваемый в проекте, хранится внутри самого проекта, и если я как разработчик некоторого участка проекта, передаю проект другому разработчику в группе (или процесс разработки ведется параллельно, при командной работе над проектом), то я заинтересован в том, чтобы мои логические наработки внутри проекта не были повреждены в результате модификаций проекта. С помощью журналов проекта, я в любой момент могу запустить автопроверку и в считанные секунды убедится в том, что созданная логическая цепочка работоспособна и не содержит логических ошибок. Если какое-либо из действий журнала проверки на этапе его выполнения не соответствует заданному мной результату — оно тут же подсвечивается и в списке и в отчете HTML красным цветом. И по нему я могу уже конкретно заняться разбором ситуации, а почему возникает это несоответствие в проекте.

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

Подключение к ОРС-серверу. При подключении можно выбрать ОРС-сервер из списка, считать его структуру в виде дерева групп, а затем выполнить привязку к ОРС-тэгам этого дерева. Поддерживается работа с любым типом данных, даже строковые типы.

Кроме того — многие ОРС-сервера позволяют передавать не скалярные значения типов, а вектора, не путать с HDA-режимом (похоже, но не то). При таком обмене ОРС-сервер выдает или принимает массив данных определенного типа (float, int и т.д.). Так как в моей СКАДе динамический массив является родным типом, то он может напрямую работать с такими данными — принимать ОРС-сервера вектора данных, далее их можно обрабатывать в алгоритмах или распаковывать на отдельные элементы массива. Ниже пример такого подключения — создаем подключение к ОРС-серверу, выбираем тэг, который является массивом Float’ов, линкуем его на канал динамического массива, задаем ему режим распаковки, и в рантайме в реальном времени по аргументам этого канала получаем результат в виде распакованных значений получаемого вектора от ОРС.

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

Чтение выборок данных из архивов. В качестве архивов может выступать любая таблица архивных данных СУБД, в которую производится сохранение архивной информации — это могут быть как числовые данные, так и журналы событий с текстовой информацией.
В примере демонстрируется создание и запуск проекта, в котором один канал синусоидального сигнала сохраняется в архив. В проекте создан канал динамического массива в режиме взятия выборки из архива из той таблицы, в которую сохраняется синусоидальный сигнал. Для анализа выборки — выполняется распаковка принятой выборки на отдельные значения в аргументы, которые потом отображаются на экране в виде гистограмм. В конце разработки проект запускается в исполнительной модуле для отладки, где демонстрируется возможность отдельной работы экранов, списка каналов загруженного узла и атрибутов любого из каналов.
Также обращаю ваше внимание на функционал разработки графического экрана: быстрое тиражирование элементов и их быстрая привязка к динамизируемым параметрам.
Работа с выборкой возможна по отдельному каналу или вообще всем данным в архивной таблице. При выполнении выборки можно задать начальную и(или) конечную временную метку диапазона выборки. Или задать полностью свое текстовое условие выборки в синтаксисе SQL-языка.
При выполнении выборки из архива процесс работы рантайма не прерывается, потому как выборка выполняется в отдельном потоке, что позволяет выполнять обработку очень и очень больших массивов данных не тормозя процесс выполнения основной задачи проекта. По завершении выборки в атрибутах канала выводится статистика по ней: время выборки в микросекундах, а также количество записей в ней.
Каждая выборка — это не просто массив значений, а это 4 массива: значения, метки времени, атрибут, маска флагов. Эта информация ведется по каждой записи в архиве, и также возвращается при выполнении выборки в одном канале динамического массива.
Кроме графической обработки данных массива, его можно передавать в алгоритмы и производить с ним вычислительные операции.
Легко и просто работаем с архивной информацией без лишних головоломок и преград по настройке и обработке прямо внутри проекта штатными средствами!

На сегодняшний день статистика по исходнику данной системы такова: уже 344932 строки исходного кода, объектная модель системы состоит из 690 классов, в которых 8659 методов и 8652 свойств. Сам проект уже разросся до 939 файлов. И когда я только успел столько награфоманить – сам не пойму.

Резюмируя вышесказанное

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

Как я СКАДу писал. Часть восьмая… +36

Программирование, C++, .NET, C#, SCADA

---

Рекомендация: подборка платных и бесплатных курсов системной аналитики — https://katalog-kursov.ru/

Единая среда разработки с поддержкой MDI.

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

Новый графический движок

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

Я, как инженер практик, считаю уже давно, что творческая составляющая не подлежит обучению и тренировке, талант он не рождается в ходе упорных кропотливых разработок. Так может рождаться и совершенствоваться мастерство, не более. Хоть ковыряйте меня вилкой, но никто никогда не убедит меня, что талант можно привить и улучшить. Не верю я в грамотного инженера, который нарисует красивый, и главное удобный интерфейс! На практике мне такое не встречалось. Придумать идею его удобности — да! Нарисовать — НЕТ! Категорично! Это талант! А он — штука редкая в сочетании с инженерной мыслью. Поэтому, всегда стремился к тому, чтобы труд по разработке графических интерфейсов был всегда разделен на два направления: дизайн, реализация. Как говорится: Кесарю – кесарево, а слесарю -… И только так можно сделать это удобным, красивым и функциональным. И обе эти составляющие должны делать два разных по профессии человека: дизайнер (дизайн) и инженер (реализация). В новой системе графики я решил максимально упростить поддержку переходов от макета дизайна к его реализации и обратно, сделать его сквозным. То есть, то, что делает эскизами инженер — может быть передано как есть (в векторе, а не рисунками) дизайнеру, а затем от дизайнера вернуть как есть (в векторе, а не рисунками) обратно в скаду, и продолжить редактировать графику средствами скады дальше, не ломая того, что сделал дизайнер. На сегодняшний день, везде, где доходит дело до подобных методов разработки интерфейса — обмен с дизайнером и обратно ведется только на уровне графических картинок, которые используются максимум как подложка, или как фон, не более. Хочу чтобы инженеры перестали быть художниками, и делали свои задачи, а художники могли наиболее адекватно принимать и возвращать макеты инженерам. Это одна из целей будущей системы.

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

Новые редакторы алгоритмов

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

Совместимость с предыдущей версией.

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

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

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

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

В дополнение к совместимости — было принято решение, что на уровне сетевого протокола новая версия будет полностью соответствовать спецификации 1-й версии. Это даст возможность, имея готовую наработку в 1-й версии, открыть ее в новой версии 2.0 и конвертировать, например узлы АРМов, или добавить новые с новой графикой и запустить их уже в рамках реально работающей системы. Благодаря поддержке одной и той же спецификации — эта процедура должна предоставить плавный переход на новую версию системы без ломания всего, что есть, и глобального перелопачивания и переделывания всего подряд. Посмотрим, оправдает ли себя моя задумка. Практика покажет, а также обратная связь от разработчиков и пользователей тоже.

Текущие дела. Что нового в моей профессиональной деятельности

Теперь несколько слов про те новые дела, которые произошли за 2016-й год. В начале прошлого года ко мне обратился представитель одной немецкой компании. Как оказалось — он и его инженеры достаточно пристально следили за моей разработкой, моими публикациями и внедрениями моей системы. Их компания — это российское представительство очень крупного немецкого разработчика систем для автоматизации, разрабатывающего решения не только для диспетчеризации, но и логистики, транспорта, энергетики и многих других задач аж с 1969 года. Это очень именитый и серьезный европейский бренд, программное обеспечение которого управляет очень серьезными и крупными системами практически по всему миру. В силу политики импортозамещения в их компании начал назревать вопрос о переносе процесса разработки программных решений, ориентированных на российский рынок, в Россию. А под это дело им понадобился человек, который мог бы стать неким тим-лидом такой команды разработчиков и постепенно бы стал архитектором этих решений. Поразмыслив, они пришли к такому выводу: зачем мы будем нанимать со стороны человека, которого мы не знаем заранее не понимаем, сможет ли он осилить поставленную задачу, если сейчас перед ними есть такой человек, который уже самостоятельно прошел все эти этапы и что называется «собаку съел» на этих задачах при разработке своей скада-системы.

В итоге — они решили предложить мне поучаствовать в их предприятии, и почти всю первую половину 2016-го года я провел в процессе обсуждения моего участия и моей роли в их задачах. Были согласованы условия, мои позиции, и мою кандидатуру утвердил их совет директоров. И вот в августе 2016 мы сошлись на том, что я начну работать у них на позиции руководителя проектов и до конца 2016-го года буду заниматься пока изучением их основной системы на практике, чтобы через полгода, когда придет пора запускать разработку – я, хотя бы буду иметь уже опыт и знания по их комплексу, а не приду с нуля и рвану сразу в бой с нулевыми базовыми знаниями их системы.

И да, предвижу ваши вопросы — стоп, а как же моя скада и моя разработка!??
Когда мы вели переговоры, мне сразу была озвучена их позиция: да, они понимают, кого они приглашают к себе, и они понимают, что просто так взять и бросить свою разработку я не смогу. Поэтому предлагая мне участие и плотную занятость в их проекте, они официально готовы к тому, что моя разработка так и остается моей вторым направлением деятельности, и я буду ей уделять свое время и силы при условии, что это не будет влиять на наши совместные дела, а также не будет возникать конфликтов интересов. С их стороны они будут давать мне возможности для выделения времени под свои задачи и у нас не будет совсем строгой муштры в рабочем процессе. За последние чуть больше полугода — мы вполне хорошо соблюдаем эти условия с обеих сторон. Если же конфликты интересов будут возникать — то мы будем стараться их решать в совместном диалоге и поиске решений и компромиссов. Однако, учитывая масштабы и задачи, решаемые моей и их системами – такое вряд ли случится, а скорее, наоборот — на общих отраслевых секторах наши системы смогут предоставить хорошо вертикально-интегрированные единые решения.

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

Вот так я теперь работаю на два направления: одно сейчас стало моей основной работой, а второе продолжает развиваться и расти все также с моим участием и под моим руководством.

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

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

Мое рабочее расписание на этот год теперь расписано на два основных офиса: Москва-Берлин. И вот сейчас я нахожусь как раз в Берлине и составляю документ этой технической спецификации, работая в центральном берлинском офисе с ведущими немецкими разработчиками и архитектором той части системы, которую я буду вести в России. Еще ровно год назад, и даже меньше — я бы вообще вряд ли смог себе представить то, чем я сейчас занимаюсь, и где я буду находиться, какие двери будут открыты для меня. Сейчас я перенимаю серьезный опыт и начинаю достаточно интересное направление, основой для которого стал мой энтузиазм, мои разработки и идеи, которые я не побоялся воплотить в жизнь и довести до практических реализаций, которые увидели профессионалы мирового уровня и высоко оценили эти результаты и проделанную мной работу, и даже предложили стать членом их команды, о чем можно было только мечтать.

Жизнь — она интересная штука, она действительно становится непредсказуемо-интересной, если ты живешь и стараешься жить ей, а не плыть по течению и повиноваться общим законам бытия и каким-то меркам и мнениям, которые пытаются доказать тебе, что то, что ты задумал — невозможно. Я сейчас все больше убеждаюсь, что все, что невозможно — так потому, что никто никогда не пытается это сделать, потому что так считают все и все смиренно принимают эту позицию. Но если что-то делать и гореть чем-то, стараться изучать что-то новое — то впереди ждут открытия и события, которые немногим раньше казались именно тем невозможным, что недостижимо!

Народ! Дерзайте и идите вперед. Несмотря на любой скептицизм и завистников! За горизонтами — новые еще более увлекательные горизонты, главное — не останавливаться и не бросать то, что начали! Труд — он всегда окупается. Возможно, мой пример — станет наглядным интересным примером для многих других. И я буду искренне рад, если он станет практическим примером для кого-то начать что-то менять в своей жизни. Надеюсь, впереди я еще не раз смогу порадовать вас новыми увлекательными публикациями, тем более, что сейчас появилось еще больше интересных тем для этого! До скорых встреч!

P.S. Приятно, что благодаря моим статьям и моей разработке — меня стали узнавать. Получается забавно, когда человек, общаясь со мной некоторое время по другим темам, в какой-то момент вдруг неожиданно узнает, что да, я тот самый Роман, который скаду написал, а он следил за моими публикациями и разработкой. Привет Роману Поваляеву! Роман, готовься, то, что сейчас происходит и над чем я сейчас работаю – похоже, будет проходить частичные испытания и на ваших объектах, так что, еще надеюсь не раз пересечемся!

А еще хочу попинать Анпилова Леонида за его издевательство над админами. А админам сказать — не таскайте ему больше мои статьи с Хабра, мы с Леонидием давние друзья и он, собака такая, над вами издевается, скрывая этот факт каждый раз как вы ему мои статьи показываете Леонидий, готовься — теперь тебя будут бить! Возможно ногами (с) Я тебя сдал! )

1

06.09.2015, 15:44. Показов 4080. Ответов 2

---

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

0

РадиоКот >Схемы >Цифровые устройства >Автоматика >

Сказ о том, как построить SCADA дом

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

      Само словосочетание «умный дом» далеко не новое. В Интернете эта тема затерта до дыр. Поисковик предлагает огромное количество вариантов на любой вкус и кошелек. Однако если копнуть глубже, то всё не так уж и радужно. Как правило, эти системы ориентированы именно на дом, а не на квартиру. В них присутствуют такие компоненты как управление котлом, открытие/закрытие въездных ворот и прочие плюшки, преимущества которых сложно оценить простому обывателю панельной пятиэтажки. К тому же все они подразумевают капитальную переделку всей проводки. А ценники и вовсе достигают заоблачных высот.
      Если же говорить о любительском подходе к реализации подобной задачи, то все найденные проекты, это как правило рассуждения о том как это должно быть. Примеров конкретных реализаций доступных для повторения практически нет. Очень многое так и остается в виде обсуждений на форумах. Многие делают управляемые через Bluetooth реле на Arduino или подобных платформах. Неделю играются с ними и потом, как правило, убирают в дальний ящик. Это всё не то.
      Не найдя того что бы меня устроило, я решил создать такую систему сам. На производстве это называется SCADA.

Часть вторая. Практическая.

      Если говорить простыми словами, то SCADA (от англ. supervisory control and data acquisition, диспетчерское управление и сбор данных) предоставляет вам возможность через Интернет браузер и WEB интерфейс управлять любыми исполнительными механизмами и наблюдать за их работой. Чтобы было понятно о чем идет речь — привожу пример реальной системы автоматизации котельной:

 

Обобщив свои требования, я составил для себя техническое задание:

Разработать систему позволяющую:
— Дистанционно управлять включением и выключением освещения в квартире с любого устройства, на котором можно запустить web браузер;
— Отображать текущее состояния выключателей;
— Включать и выключать освещение в комнатах вручную;
— С выключателя в прихожей выключать всё освещение в квартире (кнопка «выключить всё»);
— Измерять и отображать температуру в каждой комнате;
— Измерять и отображать влажность в каждой комнате.
Система должна работать в режиме 24/7, иметь дружественный интерфейс, быть максимально бюджетной не в ущерб качеству и работоспособности.

Осталось всё это реализовать!

Решение этой задачи я видел так:

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

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

      Не сочтите за рекламу, но найти подобные выключатели по приемлемой цене действительно проблема. Сайт производителя: https://www.lk60.ru/lk-45-button-b-one.html

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

   Правда, пришлось их немного доработать, а именно выкусить перегородки:

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

   Всё подошло просто идеально. По одному реле на каждый выключатель:

      На плате присутствует микроконтроллер ATMega8, драйвер шины RS485 MAX485, 2 реле, датчик температуры и влажности DHT22 и обвязка по питанию. Схема:

      Изначально я планировал применить микроконтроллер STM32F030, но драйвер RS485 с питанием от 3,3В довольно дорогой и его сложно купить. А MAX485 не может работать от 3,3 вольта. Поэтому чтобы сэкономить место на плате и не делать два преобразователя на 3,3В и на 5В выбор пал на связку AVR + Max485. Выбирая между симистором и реле, я отдал предпочтение последнему. Никакого нагрева, всё просто, надежно. Да и мерцать не будет при включении, например, болгарки.
      Данный модуль представляет собой законченную автономную конструкцию. И даже если сервер зависнет, то светом в комнате можно будет управлять вручную.

      Далее. Нам надо как-то общаться с этим модулем, читать данные или передавать ему команды. Для этого нужен протокол. Поскольку я одно время довольно долго занимался протоколами диагностики автомобильных блоков управления двигателями, то чтобы не изобретать велосипед и не применять Modbus я взял за основу один из этих протоколов и разработал свой. Запрос всегда отправляет только сервер. Модули лишь отвечают.

KC – двоичное дополнение до 1 (суммируем все байты, инвертируем полученное число, прибавляем 1, берем младший байт от полученного)

      Казалось бы просто: читаем данные с датчика DHT22 и отправляем их в USART, но в ходе написания прошивки выяснились детали, над которыми по началу не задумываешься. Во-первых, согласно даташиту, датчик надо опрашивать не чаще 1 раза в 2 секунды. Опрос же самих модулей по RS485 происходит гораздо быстрее. Поэтому если сервер 10 раз запросит параметры за эти 2 секунды, то модуль ответит ему 10 раз одинаковым значением. Во-вторых, процедуру приема запросов от сервера пришлось немного усложнить. Поскольку все устройства сидят на одной шине и слушают эфир, то ответ какого либо модуля на запрос от сервера слышат все. Это копится у всех в приемном буфере. Поэтому пришлось ввести процедуру определения начала запроса (преамбула AB CD). Чтобы в этом огромном потоке информации на шине выделять запросы от сервера к конкретному устройству. Чтение данных с датчика DHT22 производится таймером в режиме захвата.

На стене модуль выглядит так:

Витая пара к каждому выключателю была заложена ещё на этапе ремонта:

      Обращаю ваше внимание на то, что штробы в стене необходимо делать только ВЕРТИКАЛЬНЫЕ!!! Если вы делаете горизонтальную штробу, то тем самым вы уменьшаете несущую способность стены! Она может просто сломаться пополам. Маленький горизонтальный кусок я сделал лишь от безысходности. Нарисовал поясняющую картинку того, что происходит когда вы делаете горизонтальную штробу:

   Поэтому если вы планируете установить боковые светильники у себя над диваном, то только так:

   Чтобы проверить собранный модуль, не включая его в общую систему, я написал на Delphi вот такую программу:

      Т.е. используя простой переходник USB-COM или USB-RS485, можно посмотреть текущие параметры модуля и поуправлять состоянием реле. Адрес модуля на шине RS485 задается в прошивке. Это не удобно, но места на плате под переключатель выбора адреса не было. Адрес может быть от 1 до 16. Для подключения модуля потребуется 4 провода (2 витые пары). Первая пара это питание, вторая это шина RS485. Подключаются модули к шине так:

      С исполнительными устройствами разобрались. Теперь дело за сервером. Изначально я хотел применить в качестве сервера перепрошитый Wi-Fi роутер. Для этого был приобретен роутер TP-Link MR 3020. Воодушевившись описаниями того как люди лихо подключают к нему свои ардуины, чтобы пощелкать реле из браузера, я начал активно его ковырять. Но тут же всплыла масса трудностей. Во-первых, чтобы достучаться до USART роутера необходимо задействовать php скрипт. Этот скрипт при каждом запросе открывает USART порт, отправляет данные и закрывает порт. Это всё прекрасно работает когда вам нужно включить одно реле или лампочку. Но когда нужно 10 раз в секунду отправлять запрос, проверять ответ и считать контрольную сумму этот вариант не подходит ну никак! Много вопросов есть на форумах где люди слезно спрашивают, как сделать, чтобы порт не закрывался после каждого запроса. Но в ответ идут сплошные костыли. Нормального решения нет т.к. php исполняется на сервере и если сервер будет держать порт открытым он просто будет висеть. И не будет обрабатывать другие запросы.
      Советовался с людьми на форумах, но ничего хорошего такая затея не представляла. Многие вообще не понимали о чем я говорю и упорно ссылались на то, что вот, дескать, у них всё работает и реле щелкает. Те, кто понимал, говорили, что нужно писать своё приложение для роутера (под Linux) которое будет выполнять задачу управления модулями. Что для меня было непреодолимой преградой.
      В общем, вдоволь наигравшись с этим роутером, я перепрошил его на родную прошивку и отложил в сторону. В голове кружила только одна мысль – никаких роутеров, никаких линуксов и прочих SOFTWARE. Мне нужно только HARDWARE.
      Я заказал на Aliexpress модуль Ethernet на базе чипа Wiznet W5500. Это продвинутая версия известного чипа W5100. Достал из закромов микроконтроллер STM32F103VET6 с 512 кБ флеша, прикупил часы на базе чипа DS3231 и стал думать, как увязать всё это дело вместе.

 

И придумал:

И даже уместил в корпусе:

Убогий web интерфейс который приходится часто видеть на просторах Интернета, меня категорически не устраивал, поэтому я сделал свой:

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

     Работает всё следующим образом: сервер подключается LAN кабелем к домашнему роутеру. Далее на любом устройстве (телефон, планшет, ноутбук) нужно перейти в браузере по адресу 192.168.1.25 и мы попадаем на страницу web интерфейса. Где можем наблюдать текущие параметры и управлять освещением. Страница раз в секунду делает AJAX запрос на сервер, который отвечает на запрос и передает параметры в формате JSON. Обновление параметров происходит без перезагрузки страницы.

Видео на этапе отладки:

      Вэб страница автоматически масштабируется под размер экрана любого мобильного устройства благодаря мета тэгу viewport в HTML коде страницы:
<meta name=»viewport» content=»width=device-width»>

Как это выглядит на экране планшета видно на видео. А на экране ноутбука это выглядит так:

     Для проверки сервера после сборки я написал ещё одну программу, эмулирующую настенный выключатель. Т.е можно подключиться к серверу при помощи обычного USB-COM преобразователя до MAX485 и, меняя значения температуры или влажности, наблюдать за их изменением в вэб интерфейсе:

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

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

     В системах, построенных на промышленных ПЛК (программируемый логический контроллер) Siemens, Beckhoff концепция иная. Там ставится огромный шкаф автоматики с кучей реле и уже от них тянутся провода к каждому светильнику и к каждому выключателю. При этом требуется капитальная переделка всей проводки.

       По поводу витой пары к каждому выключателю: она должна быть. Построить умный дом и вообще ничего не переделывать не получится. Приступать к строительству подобной системы желательно во время ремонта. Беспроводную связь между модулями я не рассматривал в принципе. Всё должно быть надежно. К тому же даже в беспроводном случае надо как-то обеспечивать питание для модуля. А менять батарейки я не хочу.

     Система запитывается через понижающий трансформатор 220В/9В. Это обеспечивает гальваническую развязку. И в первичной и во вторичной обмотке трансформатора установлены предохранители.

Всю конструкцию я собрал на отдельном листе ДСП и интегрировал в шкаф-купе в прихожей т.к. другого места не нашлось.

Что я не успел ещё реализовать:
— модуль для управления RGB светодиодной лентой;
— модуль для измерения напряжения в сети 220В.

      Подводя итог, хочу сказать, что поставленной цели я достиг. Система работает. Конструкция доступна для повторения. Любой желающий может её собрать, сделать это очень бюджетно и гордо именовать эту систему «умный дом». В исходниках доступен шаблон сервера на основе которого можно сконфигурировать свои «комнаты».
       Разработка потребовала не малых знаний во многих областях: схемотехника, программирование, интерфейсы взаимодействия между устройствами и протоколы по которым происходит это взаимодействие, знание вэб технологий, AJAX, языка HTML, JavaScript и PHP. Ну и, конечно же, рук, растущих из нужного места.

      На этом позвольте откланяться. И помните, что главное не позволять вашему дому стать умнее вас.

Файлы:
Эмуляторы
Печатные платы
Сервер
Настенный модуль

Все вопросы в
Форум.

---

Как вам эта статья?	Заработало ли это устройство у вас?

Разработка
SCADA-системы,
как и разработка любой автоматизированной
системы, ведется в общем случае в
следующей последовательности:

1. формируются
   требования к SCADA-системе;

2. разрабатывается
   концепция SCADA-системы;

3. разрабатывается
   технический проект АСУ ТП верхнего
   уровня;

4. разрабатывается
   программная документация;

5. разрабатывается
   руководство пользователя АСУ ТП.

2.1. Формирование требований к scada-системе

На этапе формирования
проводят:

• сбор данных об
  объекте автоматизации и функциях,
  подлежащих автоматизации (описание
  объекта и технологического процесса);

• оценку качества
  функционирования объекта и выявление
  проблем, решение которых возможно
  SCADA-системой;

• формирование
  требований к SCADA-системе.

2.2. Разработка концепции scada-системы

На этом этапе
проводится выбор варианта SCADA-системы,
удовлетворяющего требованиям пользователя.
В общем случае проводят:

• разработку
  альтернативных вариантов концепции
  создаваемой SCADA-системы
  и планов их реализации;

• оценку необходимых
  ресурсов на их реализацию;

• оценку преимуществ
  и недостатков каждого варианта;

• сопоставление
  требований пользователей и характеристик
  предлагаемой системы и выбор оптимального
  варианта.

Для создания
системы управления пользователи,
приступая к разработке прикладного
программного обеспечения (ППО), оказываются
перед выбором: программировать с
использованием «традиционных» средств
(традиционные языки программирования,
стандартные средства отладки и пр.) или
применить готовые – COST
(Commercial Of The Shelf) – инструментальные
проблемно-ориентированные средства.
Конечно, качественное, хорошо отлаженное
ППО, написанное высококвалифицированным
программистом специально для того или
иного проекта, решение наиболее
оптимальное. Но следующую задачу
программисту придется решать опять-таки
практически с нуля. Таки образом, процесс
создания сложных распределительных
систем становится недопустимо длительным,
а затраты на их разработку – высокими.
Сегодня, в условиях, когда затраты на
ППО все более возрастают и соответственно
все более ожесточаются требования к
интенсификации труда программистов,
вариант с непосредственным программированием
привлекателен лишь для простых систем
или небольших фрагментов большой
системы, для которых нет стандартных
решений (не написан, например, подходящий
драйвер) или они не устраивают разработчиков
в принципе. В любом случае процесс
разработки собственного ППО важно
упростить, сократить временные и
финансовые затраты на его разработку,
минимизировать затраты труда высококлассных
программистов, по возможности привлекая
к разработке специалистов в области
автоматизированных процессов. Логика
развития современного бизнеса в области
разработки ППО для конечных систем
управления подталкивает к использованию
все более развитых инструментальных
средств типа SCADA-систем
(Supervisory
Control
And
Data
Acquisition).
Разработка современной SCADA-системы
требует больших вложений и выполняется
в длительные сроки. Именно поэтому в
большинстве случаев разработчикам
управляющего ППО, в частности ППО для
АСУ ТП, целесообразно осваивать и
адаптировать какой-либо готовый, уже
апробированный, универсальный
инструментарий. Возникает вопрос выбора
SCADA-системы.
В табл. 1. перечислены некоторые популярные
SCADA-системы,
имеющие поддержку в России. На основе
этих пакетов предлагается рассмотреть
некоторые основные возможности и
характерные особенности SCADA-систем.
На основе этих пакетов предлагается
рассмотреть некоторые основные
возможности и характерные особенности
SCADA-систем.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #