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

Введение

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

Ну. И что?
Реклама
Комментарии 61
  • +2
    Огромный респект, я за всю свою жизнь не написал столько кода (работающего в продакшене, конечно).
    • 0
      Вот подстава то. И ведь догадывался же, что тема обширна. Аж браузер завис.
      А автору респект
      • +2
        Вы — настоящий профессионал. Теперь есть к чему стремится :)
        • +1
          Автору респект, в одиночку не побояться начать и главное довести до какого-то логического момента такой обширный проект.
          • +1
            Судя по всему вы проделали огромный труд, респект. Тоже заканчивал институт по этой специальности и даже поработал на производстве. Правда, со скада системами работал в основном на прикладном уровне. OPC, да разного рода мелкие утилиты. Как у вас обстоит дело с поддержкой стандартов OPC? Помню, неистово бесило, что каждая скада система реализовывала его не до конца. 3.0 то держит? XML DA? Сама скада может выступать в качестве OPC сервера?
            • +2
              С ОРС все не просто, сама OPC-foundation в этом плане очень серьезно следит за тем, чтобы за любой чих разработчик отстегивал им немалые деньги. Я много искал нормальные обертки под ОРС, потому как платить ассоциации (если не ошибаюсь около 1500 евро) за членство и доступ к материалам я сейчас не могу. Нашел два более-менее подходящих варианта: один бесплатный (писали энтузиасты и выложили результаты в свободный доступ, дальше сами дорабатывайте), платный — от GrayBox. Первый сразу встроил, там есть поддержка клиента и вроде даже сервера по OPC DA 2.0, но серверную часть я пока еще не осилю — сложновато. Грейбоксовский сейчас вот ковыряю по части клиента (хотя и серверные интерфейсы там тоже есть), в нем есть: DA, HDA, AE, и все это же также по XML, но все в коммерческой версии за денежку. Для текущих проектов, где в основном мониторинг и частичное управление через ОРС пока хватает.
              • +1
                Если язык реализации не принципиален — взгляните на code.google.com/p/libopcd/
                Я в свое время на основе этой библиотеки делал OPC-шлюз, который выступал одновременно в роли OPC сервера и OPC клиента. Был источником данных для scada систем, брал данные из хозучета и другой скада системы по OPC, делал расчеты и суммарную инфу складывал уже в общезаводскую систему хозучета.
                Серверная часть там сделана на очень хорошем уровне. Чтение тегов же я тестировал на тестовом сервере от dOPC — имхо, лучший тестовый стенд для проверки на совместимость стандартам (испробовал штук 20, все фигня).

                Вот с документацией да, очень туго. Найти в сети практически нереально, если не платить консорциуму за членство. Я нарыл только спеки на 3 DA и частично на 2 версию, а потом все методом тыка
                • 0
                  Спасибо за ссылки, но язык принципиален, я пишу на C#, поэтому нужны обертки с поддержкой managed кода. Материалы по dOPC я уже проходил — брал кое-что для тестов и ознакомления, также у них даже есть обертка для .Net, но вот скачать ее они не дают.
                  • 0
                    Ну как минимум взгляните на код. Довольно добротный, не думаю что возникнут сложности с портированием в шарп.
                • 0
                  code.google.com/p/frl/ — после правки напильником оно даже работает.
              • 0
                Интересная статья, спасибо!
                У меня давно было мнение, что если начать писать СКАДу с нуля на основе современных технологий, получится удобная и красивая вещь, в отличии от грузных стандартных систем (WinCC,TraceMode и т.д.) вынужденных из-за совместимости тащить за собой ворох старых технологий и алгоритмов.

                По статья — особый интерес вызывает вопрос связи с нижнем уровнем — ждем продолжения!
                • –1
                  На фразе «а зачем нам кузнец?» подумал что речь пойдёт о том, что было принято решение не работать в штате, а предлагать профессиональные услуги заказчикам (включая бывших работодателей) от себя лично. Но так тоже ничего получилось 8)
                  • 0
                    Такой вопрос. Вы написали, что делали систему в «свободное от работы время». Ваши успехи по основному месту работы настолько же значительны? Или акцент сместился на эту разработку?

                    P.S.
                    Спрашиваю, чтобы больше узнать о пределах человеческих возможностей.
                    • +3
                      Ну, если изменение должности с «ведущего инженера АСУТП» на должность «руководитель отдела прикладного ПО» можно отнести к такому успеху, то да. За время разработки по основной работе часть своих наработок я внедрил непосредственно в наше производство. Например, последние все наши проекты по фирме выполняются полностью с использованием моей подсистемы архивации в СУБД совместно с брендовой СКАДой. Помимо этого сделал отдельное решение по моделированию объектов управления, которое сейчас потихоньку внедряем на своем полигоне, через который прогоняются все наши проекты и на котором проводим их заводские испытания. Кстати, это решение у меня как раз в математический аппарат заложено в скаде. Параллельно с этим я лично веду 2 проекта АСУТП для АСУ Энергоснабжения газоперекачивающих станций (достаточно крупные — каждый по 2000-3000 точек ввода/вывода), один из них в конце этого года выходит на МВИ (межведомственные испытания), чтобы быть принятым как рекомендуемое решение в отрасли. Плюс к этому эти же проекты сам делаю еще и в своей системе (некоторые скриншоты в статье и даже видеоролики сделаны на этих проектах), чтобы к осени на заводских испытаниях одну из них показать не только в штатном исполнении на брендовой СКАДе, но и на базе своей разработки, для наглядности. А весной вообще было весело — намечалась покупка жилья, так что пришлось параллельно совмещать три работы: утром до основной делал АСДУ одного бизнес-центра, потом мчался на основную, а вечером после основной — на другой объект. После уже дома часиков до 2-3 ночи копался в своей системе. Помнится, после двух месяцев такого режима, вымотан был капитально, пришлось неделю отпуска брать. И первые двое суток я спал вообще не просыпаясь… Долго так сложно выдержать, поэтому — по личному опыту могу сказать, что возможности большие, но не безграничные.
                    • 0
                      Ваш проект показывает насколько велика разница между наемным работником и созидателем, заинтересованным в своем проекте.

                      Просто прикиньте (хотя бы с точностью до порядка) во сколько бы обошлась разработка подобного проекта силой наемных работников? Для грубой оценки берут величину 100 строк отлаженного кода в день. Тогда ваш проект среднему наемному работнику нажно было бы делать 10 лет, а бюджет был бы (для России) минимум 200 тыс. у.е. Но т.к. 10 лет — слишком долго, нужно распараллелить между многими работниками, а с увеличением людей повышаются затраты. Тогда бюджет на создание будет близок к 1 млн.

                      Мне очень интересно что дальше будет с проектом. Сможете ли вы довести его до должного уровня и стать миллионером :) Кстати, не предлагали вам еще продать его?
                      • +3
                        Сейчас ведется разработка сайта, через который я планирую начать распространять свое решение уже в массы. Там будет форум, информация по продукту, а также онлайн справочная система + онлайн курсы по работе в ней. Последнее уже начал делать на базе движка Википедии, очень удобно получается.
                        Насчет продажи — пока никто не предлагал продать, но тут пока еще мало кто вообще знает о том, что я делал. Сейчас вот после Хабра будет побольше уже. Однако в период информационного освещения своего детища через АСУТПшные форумы я уже успел стать официальным конкурентом для одного из производителей отечественного бренда. Руководство фирмы разработчика СКАДы, увидев мое решение, официально возвело меня в ранг конкурента после моего отказа прекратить разработки, а сотрудничать с ними и работать ТОЛЬКО на их решении…
                      • 0
                        возможно читал невнимательно, сколько по времени заняла разработка?
                        • 0
                          Мне тоже было удивительно. Чуть больше года с пивом (в свободное от работы время). Примерно по 900 строк в день.
                          • 0
                            круто, желаю вам иметь процент от каждого внедрения ;)
                            • 0
                              Только это не мне, а автору :)

                              Вот вам реальный пример силы энтузиазма — чел наваял за год с пивом столько, сколько средний наемный программер будет делать 10 лет. Когда спросишь у автора как так получилось — он и сам не знает, сам удивляется.
                        • –3
                          Опять под винду…
                          • +1
                            Сделай под Linux, QNX или под то, что тебе нравится.
                        • +2
                          Люблю задавать каверзные вопросы.
                          А как вы добились фиксированного времени цикла и вообще реального времени в ядре контроллера?
                          Поддерживаете многопоточность?
                          Как реализовали обработку исключений? Что будет, например, при делении на ноль в рантайме?
                          Поддерживаете диапазоны, уставки?
                          Как реализуется обработка отказа датчиков, АЦП, ДЦП и другой периферии?
                          Не совсем понятно, графическое ядро работает в одном процессе с вычислительным? Т.е. если сделать программу для контроллера, то как для неё увидеть мнемосхему? По какому паттерну реализовано (если реализовано) получение процессом, отображающим мнемосхему, оперативных данных от контроллера — постоянный опрос, или уведомление об изменениях со стороны контроллера?
                          Реализована ли пошаговая отладка кода технологической программы? Или только на уровне доступных вычисленных значений?
                          Реализована ли буферизация событий на случай временного отказа архива или сети? Будут ли события, произошедшие на время отсутствия связи с архивом, потеряны на всегда?
                          Как реализован механизм квитирования (подтверждения получения и обработки) команд (нажатий на кнопки, ввод значений) от мнемосхемы к контроллеру?
                          Поддерживается ли дублирование и кластеризация контроллеров?
                          Поддерживается ли дублирование сети?
                          Ну и самый каверзный :) А есть UNDO/REDO?

                          Это только мелочь, которая первым делом пришла на ум. В действительности объём таких мелких каверзных вопросов при разработке САПР АСУ ТП — просто огромен, и решения некоторых вопросов наслаиваются друг на друга, увеличивая сложность их одновременного решения до астрономических величин. Это я к тому, что миллион долларов на разработку качественного САПР АСУ ТП — не так уж и много.

                          Однако, хочу выразить уважение, по поводу объёма проделанной работы. Впечатляет.

                          Самому мне эта тема очень близка, я уже лет 5 работаю разработчиком как раз таки САПР УСУ ТП, пишу векторный графический редактор визуального языка программирования для микроконтроллеров, на подобии FBD.
                          • +3
                            Пойдем последовательно и в ответах и в разработке:
                            1) Фиксированное время цикла определяется разработчиком проекта для конкретного узла проекта (АРМа или контроллера), однако реальное время, которое затрачивается на пересчет всей математики, что он навертел внутри этого узла, может и не хватить, тогда цикл реального пересчета будет превышать установленный. Таким образом разработчик при отладке должен учитывать, что в случае превышения установленного цикла реальным ему придется установленный цикл повышать до размеров реального — ведь сказать системе работать быстрее невозможно. Это все легко диагностируется на этапе отладки системы. Все ресурсоемкие процессы, такие как: архивация, журналирование событий, работа с дампом, внутренние архивы в памяти, сброс их в файлы, обмен по внешним интерфейсам — это все отдельные потоки, работа которых идет параллельно основному процессу пересчета базы и математики узла. Технология одинакова как для контроллеров, так и для АРМов операторов.
                            2) Как я уже говорил — в системе я реализовал собственный вычислительный движок, который не работает с понятиями типа данных, для него любой тип — это в первую очередь «объект», и приведение его к нужному типу выполняется в зависимости от реализуемой функции или контекста использования. Поэтому в моей системе делить на ноль можно вообще без возникновения исключительных ситуаций — получите бесконечность как результат, хотите контролировать тип, делайте это в логике алгоритма. Хотя сам движок не мешает сделать это внутри него штатно. Тут практика уже покажет — как будет удобнее, так и доработаю.
                            3) Диапазоны и уставки — не совсем понятно при чем тут скада как таковая — это вопросы реализации конечных проектов АСУТП на ее базе, ведь это переменные техпроцесса. По аналоговым переменным у меня есть диапазоны границ сигнала и контроль достоверности и номера интервала, где он сейчас находится.
                            4) Опять таки вопрос не к скаде, не ее задача контролировать отказы датчиков и АЦП, ДЦП — это должно реализовываться на другом уровне. В системе по переменным есть признак Достоверности (аппаратная, программная, достоверность типа), их можно менять программно, из драйвера устройства, или вручную с операторской мнемосхемы.
                            5) Да, на текущий момент графическое ядро работает в одном процессе с вычислительным, вернее сказать они последовательно выполняются в процессе пересчета базы и математики. Однако я уже сейчас продумываю как их разделить по разным потокам, чтобы не грузить основной вычислительный процесс ядра графикой.
                            Относительно вопроса про контроллер и мнемосхему для него — вы несколько некорректно понимаете архитектуру моей системы, у меня подобное решается так: в проекте создается два узла (контроллер и АРМ), в каждом своя база переменных, алгоритмов, а между их переменными уже устанавливаются связи через сеть или последовательный интерфейс. Таким образом получается проект из двух узлов: контроллер, который работает внизу и АРМ наверху. Графика мнемосхем делается как раз в АРМе, а данные для нее он по сети или последовательному каналу из контроллера уже поднимает.
                            6) Пошаговая отладка с выводом всех внутренних переменных есть только для визуального языка FBD. Для С# этого нет, там процесс выполнения по шагам только на уровне выполнения логики алгоритма на 1 такт с выводом всех входных и выходных его аргументов. Внутренние как в профф. студиях программирования типа окна Watch я не могу сделать… пока не могу…
                            7) Все процессы по архивации в СУБД у меня буферизированы. Более того — в случае, если буфер не удается сбросить в СУБД, а рантайм тормозят — он может скинуть его в файл, и подчитать при рестарте. Так что данные потерять совсем можно только жестко обрубив питание.
                            8) Про механизм квитирования от мнемосхемы к контроллеру — снова немного некорректная постановка вопроса относительно архитектуры моей скады. Сделаем проще — приведите описание задачи, которую надо решить, а я объясню как она решается у меня.
                            9) Дублирование с поддержкой горячего резервирования я пока только планирую, на данный момент пока ничего этого нет. А вот насчет кластеризации — немного не понял суть, вы имеете ввиду функцию распределения вычислительной нагрузки по алгоритмам в проекте из одного узла на несколько, если один не справляется?
                            10) Дублирование сети — как уже сказал, что подсистему сетевого обмена я пока только еще делаю, так что тут пока рано говорить об этом. Однако вопрос резервирования для скады — это серьезный и многоуровневый вопрос, так что его проработка относительно сети также меня ожидает.

                            Если не секрет, как называется САПР, в разработке которого вы принимаете участие?
                            • 0
                              1)Ну то что время цикла фиксируется, это понятно. Мне была интересна поддержка реального времени в ядре контроллера. Под этим я понимаю гарантию того, что время выполнения цикла управляющего кода будет зависеть только от самого кода, а так же то, что управляющие сигналы будут посланы на арматуру так же за гарантированное время. На сколько я понимаю, WinCE ядро работает под .NET Compact Framework? Т.е. например, управляющий поток может быть в любой момент остановлен сборщиком мусора на неопределенный промежуток времени. Может произойти прерывание. Наконец, управляющий поток может быть просто вытеснен, если, конечно, для него не задан приоритет реального времени. К тому же, свой отпечаток накладывают подсистемы ввода вывода — стек TCP/IP, реализации прикладных протоколов. Если кем-то используется неуправляемый менеджер памяти, то опять же время на выделение памяти становится непредсказуемым из-за фрагментации. А ведь еще сам CPU очень сложное устройство — микрокод, конвейеры, кеши, контроллер памяти. (Помнится, в блоге Intel на эту тему была отличная статья.) Т.е. время цикла в системе без поддержки реального времени становится прыгающим в неопределенные моменты времени на неопределенную величину.
                              Иными словами, гарантировать реальное время выполнения — труд просто титанический. Для этого как раз и придумывают множество аппаратных реализаций протоколов ввода вывода — чипы ProfiBus, ModBus, CANOpen и т.д. и т.п.

                              2) Т.е. если целый 0 разделить на целый 0, то получим NaN с плавающей точкой?
                              Ну деление на ноль, это ладно, можно обойти. А что если обратиться к массиву по неверном индексу? Если вызвать метод по нулевой ссылке? Как-то исключения обрабатываться должны? Или в таком случае ядро будет аварийно завершено? :)

                              3, 4) Ну у меня как раз вопрос заключался в том, поддерживается ли достоверность, или нет. Понял, поддерживается. У нас это называется качество сигнала.

                              5) Ну для мелких АСУ такой подход еще туда-сюда — но для больших… Это ж надо во первых создать программу для контроллеров, во вторых — создать программу для операторских станций, в третьих нужно в ручную организовать передачу данных от контроллеров к операторским. Получается двойная работа. А когда счет сигналам идет на десятки тысяч…

                              7) Защита от потери данных при прекращении питания или перезапуске штука полезная, называется безударный перезапуск. А что будет при потере питания со всевозможными интегрирующими алгоритмами, ПИД-регуляторами, которые накапливают данные и на основе интеграции формируют управляющее воздействие? Если потерять накопленные данные, то при запуске контроллера «с нуля» могут быть сформированы очень сильные управляющие воздействия, способные повредить арматуру.

                              8) Допустим есть двигатель, который можно включить или выключить. И нужно сделать мнемосхему с двумя кнопками — вкл. и выкл. для этого двигателя. Как это будет реализовано? В программе будет алгоритм с одним логическим входом? С одним входом другого типа? С несколькими входами? Или у вас поддерживаются FBD-шные логические триггеры по IEC 1131-3?

                              9) Дублирование, это когда из нескольких контроллеров, объединенных в группу, один управляет, а остальные ничего не делают, находятся в резерве и, при выходе текущего управляющего контроллера из строя, управление на себя берет резервный. А при кластеризации группа из 3-х и более контроллеров одновременно принимает данные, считает, и посылает управляющее воздействие. А на выходе стоит стоит специальное устройство — арбитр — которое сравнивает все управляющие воздействия, и, если вдруг значения расходятся, то по принципу мажорирования выбирает верное по его мнению значение, а разошедшийся контроллер считает «паршивой овцой». Кластеры активно используются в АСУ где любая ошибка недопустима, например, на АЭС, или при управлении газовыми турбинами.

                              10) Да, нормально сделать резервирование — задача не слабая.

                              САПР называется КВИНТ.
                              • 0
                                1) Все верно — поэтому у себя оговариваюсь, что у меня не строго реальное время выполнения, а квази-реальное. Настолько детально прорабатывать ядро, я к сожалению не могу (и пока не умею), поэтому не позиционирую свою систему как систему для очень быстрых процессов с жесткими требованиями по времени реакции и выполнения логики и процедур ввода/вывода. Для большинства процессов ее получается достаточно.
                                2) Да, получим NaN. Относительно исключительны ситуаций — тут штатные методы try-catch позволяют достаточно четко обрабатывать их без выноса основного процесса в даун. Все результаты обработки выводятся оператору в текстовом виде в специальные комментарии, то есть всегда можно грамотно разобраться, а в чем собственно возникла проблема и почему. Кстати, у меня по этому механизму внутри выислителя 3-й тип Достоверности по переменным выставляется в работающей системе (достоверность типа данных).
                                5) Вот тут снова немного недопонимание архитектуры — весь проект представляет собой единое адресное пространство, не надо дублировать данные из одного узла (например контроллера) в другом (например АРМе) — если для алгоритма АРМа требуется значение датчика температуры из контролла №n, то берете и линкуете его в проекте напрямую как переменную из узла контроллера в алгоритм узла АРМа, система сама выполнит привязки и последующую обработку обмена этими данными между этими узлами по выбранному интерфейсу при работе в рантайме. Задумано все именно так.
                                7) Мой файл сохранения состояния ведется не только по свойствам переменных базы узла, но и по внутренним переменным алгоритмов. поэтому алгоритмы с внутренними счетчиками или состояниями (например ПИД, или триггер) при рестарте продолжают работу с того места, где их остановили, то есть — процесс работает безударно.
                                8) Самая простейшая реализация: создаем 1 канал (переменную), связанную с точкой ввода/вывода УСО, через которое идет управление двигателем (1 — включить, 0 — выключить). Переменная типа Output. Создаем экран, где размещаем две кнопки: одна выполняет прямую посылку значения 1 в выходной аргумент экрана, другая — 0. Аргумент экрана выходной и привязывается к каналу (переменной) управления двигателем через УСО. Вот и все. Если необходимо фиксировать команду посредством триггера, то в промежуток между экраном и каналом управления через УСО вставляется алгоритм на FBD, где стоит RS или SR-триггер по стандарту IEC 1131-3 (у меня свыше 120 блоков штатно в FBD по разному функционалу). Только в этом случае на экране будет уже два аргумента, а обе кнопки будут посылать 1, каждая в свой аргумент, со сбросом при отжатии. Это и будут команды на вход триггера для SET и RESET входов.
                                9) Да, как уже сказал, все это еще только мне предстоит. Сейчас по текущим проектам пока требуется горячее резервирование как внизу, так и наверху. Кластеризацию обычно делал на уровне алгоритмов, когда КИП троированный был, на уровне узлов пока еще не приходилось таких задач решать.

                                КВИНТ — знаю, вернее много слышал, и знаком с людьми, которые на ней очень плотно работали. Например, когда в Ираке Нассирийскую ТЭС пускали, оооочень много наслушался сравнительных характеристик от инженеров ОРГРЭСа (был там такой — Бородкин) относительно КВИНТа и ТМа. :)
                                • 0
                                  Очень интересно, какие характеристики вы слышали :) Но в любом случае, это были характеристики 5й или 6й версии, я тогда в НИИТеплоприборе еще не работал :) Вот 7я будет значительно лучше.
                                  • 0
                                    Да там даже в основном не конкретные характеристики были, а больше эмоциональное сравнение. Ну — сами понимаете, серьезный объект, большой проект, любой огрех или проблема вызывают кучу негатива и попыток поддернуть «а вот в наше время...».
                            • 0
                              Относительно UNDO/REDO — действительно каверзный, потому как в моей системе такого вообще нет. Пытался делать, но изначально не хватило мозгов чтобы понять как это вообще делается в ПО, потом уже малость поздно получилось. Но и еще один фактор был сдерживающим — в СКАДе, в которой работал(ю) Undo/Redo — является самым конкретным рассадником багов, из-за этого механизма часты свалы системы. Хотя, периодически начал ловить себя на мысли, что не имея данного механизма в своей среде разработки я стал более детально продумывать свои действия как разработчик, и сейчас все реже и реже даже думаю о том, что сейчас бы UNDO не помешал…
                              • 0
                                Ну вообще говоря это означает, что к той системе undo прикручивался по ходу дела (и возможно, поэтому вы тоже пришли к мысли, что этого делать не стоит). Если бы действия в программе изначально были транзакционными, то undo-redo механизм работал бы как часы.
                                • 0
                                  У Undo есть неприятная особенность, что если его не сделать сразу, то потом его доработка становится задачей практически перекапывания всего исходного кода приложения. У меня ушло приличное количество времени и экспериментов, что бы подобрать оптимальный паттерн реализации. У меня всё запущено, есть СУБД, есть ORM, который за одно является VM в паттерне M-V-VM (Model-View-ViewModel) :) Ну а в качестве Model выступают классы таблиц СУБД. View сделан на WPF.
                              • 0
                                Поясните пожалуйста, у вас SCADA включает в себя и контролер, своего рода софтверная эмуляция апаратного контроллера, так?
                                • 0
                                  Нет, не совсем так. Архитектура проекта представляет собой два типа узлов: АРМ оператора и контроллер. Под контроллером в моем случае понимается узел РС-совместимого устройства, в котором установлена ОС Win из линейки: WinCE, XP embedded, или вообще чистая Win, где может запускаться мой рантайм для узлов контроллеров, в котором грузится и обрабатывается этот компонент проекта. С точки зрения архитектуры такой узел практически ничем не отличается от АРМа, тоже есть база переменных, алгоритмы, связи между ними, связь с УСО и разного рода внешним оборудованием (включая также узлы самого проекта), только в нем нет графики… Нуу — пока нет. Просто отладчик проекта внутри среды разработчика умеет обрабатывать (пересчитывать) весь проект как единое пространство компонентов, вообще не делая упора на то, что одни узлы — это АРМы, а другие — это контроллеры. Просто в этом нет необходимости. Зато получается возможность отладки единого многоузлового проекта на одном ПК разработчика прямо в среде разработки, с отслеживанием всех каналов движения данных внутри логической структуры проекта, с одновременными возможностями редактирования компонентов графики и алгоритмов без останова выполнения, что называется — в реальном времени. При запуске проекта на объекте — конечно каждый узел проекта уже запускается каждый в своем устройстве под индивидуальным рантаймом.
                                  • 0
                                    Спасибо за развернутый ответ. Т.е. ваш проект представляет собой комплексное решение SCADA+ПЛК, тогда возможно ли использование (или планируется) вашей SCADA именно как HMI приложения с существующим контроллером Siemens (допустим, не люблю я WinCC) или Schneider (не люблю Citect :) ) или любого другого крупного производителя?
                                    • 0
                                      Совершенно точно, комплексное решение SCADA+ПЛК(Softlogic). Как решение HMI+ПЛК с закрытой архитектурой (именно ПЛК в чистом понимании) можно использовать через подключение устройства по стандартному протоколу или интерфейсу. Например, для Siemens — это через ОРС сервер (их Профибасы — ужасно закрытые стандарты с лицензиями в тридорого, а решения через API среды Step7 — не тривиальное решение, которое так и не заработало, был косвенный опыт), для Schneider — это ModBus RTU или TCP. Вообще, поддержка в моей системе того же протокола ModBus в качестве Slave-режима дает возможность использовать наоборот — мою скаду как средство программирования Софт-ПЛК, а на верхнем уровне любую HMI из существующих. В общем, хотите — только верх, а хотите — только низ, или и все вместе, тут уже разработчик проекта решает…
                                • 0
                                  Скажите, а при реальном создании вы пользуетесь методологиями IDEF? А то нас учат этому как раз при создании АСУ ТП.
                                  • 0
                                    Нет, это из области АСУП — управление производством, а не технологическим процессом (АСУТП).
                                  • 0
                                    Вы молодец, а я оказывается унылое говно.
                                    • +1
                                      Почто так самокритично-то?
                                      • 0
                                        Вы скаду на 300к строк написали, а я ничего не написал. Тоже инженер асутп.
                                        • 0
                                          А вдруг Вы в ней проект на 300к точек ввода/вывода сделаете? ;)
                                          • 0
                                            В моей жизни пока было 2 проекта: на 5000 тегов и на 500 тегов. Первый внедрили уже без меня на севере, на втором работаю до сих пор.
                                          • 0
                                            Имхо, главное не 300к строк, а то, что потом это будет работать и внедрено на производстве.
                                            Программист В. Антонов написал много хорошего ПО под необычные роутеры (Pluris), но продажи железок почему-то не пошли и труд получился впустую.
                                      • 0
                                        Ещё бы избавится от C# в пользу C++ и была бы вообще замечательная система, быстрая, маленькая, способная запускаться на встроенных контроллерах, например, ICP DAS (там MiniOS 7 т.е. MS DOS) и под QNX. А так неудачный выбор инструментария разработки похоронил проект, никто в трезвом рассудке не станет гонять прокатный стан на Microsoft .Net.
                                        • +1
                                          Прокатный стан не будет, но SCADA к стану я бы погонял)
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            Очень впечатляет, огромное уважение автору.

                                            И пара вопросов:
                                            Есть ли планы по распространению или продаже вашей скады?
                                            на основе каких лицензий?
                                            а то очень хотелось бы потрогать посмотреть?

                                            также работал и работаю с разными скадами, и ни одна из них не является идеалом удовлетворяющим все потребности ;(
                                            В одной это криво реализовано, в другой свои грабли… и как уже правильно отметил Fortums — это действительно голубая мечта каждого разработчика, написать своё и «как надо делать скады правильно».
                                            • 0
                                              Тут для себя решил так — инструментальная система (среда разработки + полнофункциональный рантайм с ограничением по времени непрерывной работы) будут совершенно бесплатные. Бери и разрабатывай, запускай, отлаживай без каких-либо функциональных ограничений. Платными будут только сами рантаймы, и то думаю, что цена будет чисто символической, я понимаю, что мой продукт не именитый бренд, и я пока не в силах в одиночку обеспечить ему то качество, которое могут обеспечить крупные компании (хотя, зачастую последние и приемлемого уровня обеспечить не могут).
                                              Насчет политики форматов проекта (например как у того же ТМ) — опять же не будет делений на Демо и Проф варианты, потому как сам файл проекта в моей системе в чистом XML (для особо интересующихся программистов, с целью сопряжения с другими системами я могу этот формат даже описать).
                                              Ну и останется только коммерческая составляющая СУБД для архивов — если для личного пользования брать, то у MySQL вроде лицензия бесплатная на это (сам так сейчас разработку веду), но для коммерческого применения — уже потребуется приобретение лицензий, однако это уже вопрос не ко мне, этот вопрос должен будет уже конечный пользователь моей скады решать.

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

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

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

                                              Контакт почтового адреса можно найти на моем сайте (по тексту статьи ссылки на материалы идут как раз с моего сайта).

                                              У меня тут один пользователь взял систему пощупать и пропал на неделю, ни слуху, ни духу. Пишу ему с вопросом, что и как, как дела, какие результаты, а он оказывается уже потихоньку свой реальный проект делает в моей системе и она даже показывает стабильную работу (у него железо по ОРС подключается). Вот так глядишь, еще и быстрее меня проект в ней сделают. :)
                                              • 0
                                                Да, на счет качества трудно не согласится. Особенно в этом плане сдал Siemens со своей SPPA T3000. Step7 штука проверенная временем, это да. Но ПО верхнего уровня реализовано ИМХО отвратно.
                                            • 0
                                              большой труд, очень интересно
                                              • 0
                                                Уважение автору, за энтузиазм
                                                • 0
                                                  Вопрос к автору.

                                                  Могли бы вы для статистики привести размер исходного кода в байтах. Только файлы cs, исключая ресурсы и файлы данных? Спасибо.
                                                  • 0
                                                    Если только файлы cs, то статистика на данный момент такова:
                                                    Инструменталка — объем 9,082Мб
                                                    Рантайм для Windows — объем 3,784Мб
                                                    Рантайм для WinCE — объем 2,145Мб
                                                  • 0
                                                    Всем доброго времени суток. Случайно из Томска никого нет?
                                                    Сейчас нахожусь под Томском в рабочей командировке по поводу внедрения крупного проекта на 3000 точек на базе своей скады. Систему успешно запустил и уже на следующей неделе, примерно в середине, планирую 1 день быть в самом Томске. Если кому интересно — можно было бы встретиться очно, побеседовать, заодно мог бы показать и рассказать о системе вживую. :)
                                                    Если что — пишите, о месте и времени договоримся.
                                                    • 0
                                                      Приглашаю всех на стенд нашей компании на предстоящей выставке «ПТА-2014», которая состоится с 7 по 9 октября 2014 года в Москве по адресу: ЦВК «Экспоцентр», павильон 5.
                                                      На стенде будет демонстрироваться система SCADA+. Можно будет пообщаться с разработчиками и задать свои вопросы, а также попробовать систему в работе.
                                                      www.pta-expo.ru/news/020914.htm

                                                      Это будет первый выход моей скады на рынок автоматизации как коммерческого продукта и компании, которая будет заниматься ее разработкой, сопровождением и выполнением проектов на ней.
                                                      • 0
                                                        Ура!!! Наконец-то прошли все согласования в ПАО «Газпром» по маркетинговым материалом для презентации системы нашего системного интегратора, который успешно провел в 2015 году испытания и внедрил в эксплуатацию систему линейной телемеханики газопровода на базе моей SCADA+!
                                                        Теперь информацию по этому решению, а также отзывы компании о системе SCADA+ можно прочитать на сайте скады в разделе внедрений: система линейной телемеханики «ЭЛТА-ТМ.2»

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое