Точек вводы вывода scada - Что такое "точка ввода/вывода"

Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Romer 19 июля в Сам я по специальности автоматчик, занимаюсь разработкой и внедрением систем автоматического управления технологическими процессами АСУТП.

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

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

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

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

Мои проекты и опыт работ в области АСУТП можно посмотреть здесь. Изначально занимался системами автоматизации для диспетчеризации инженерных систем зданий по Москве. Потом, с развитием интернет технологий, появилась возможность разрабатывать проекты для удаленных объектов в других городах.

Заказчик подключал выделенный защищенный канал связи с объектом через интернет, что позволяло напрямую подключаться к объекту и вести наладку и доводку проекта прямо из дома. Продолжал работать на том же ПО, что и ранее, потому как наиболее подходящих альтернатив пока не наблюдалось, да и уже были очень хорошие наработки и опыт предыдущих разработок, который не хотелось просто так оставлять при переходе на новые системы.

В процессе работы над проектами дорабатывал саму СКАДу своими собственными заплатками, которые позволяли подменять штатный функционал пакета в силу его неудовлетворительной работы или неспособности реализовать те или иные требования.

За время такой доработки система стала походить уже на некоторое ядро, которое было обвешано внешними утилитами и сервисами как новогодняя елка игрушками.

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

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

Изобретением велосипеда я решил не заниматься, а уделить внимание его функционалу. Все было бы замечательно, если бы не одно НО — изначально я не программист, а автоматчик. То, что писал свои собственные утилиты для пакета — было что-то вроде стороннего увлечения, хобби так сказать, ради которого начал изучение технологии.

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

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

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

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

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

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

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

Обработка данной базы вычислителем ядра в процессе выполнения проекта на узле операторского АРМа Автоматизированное рабочее место оператора или контроллера выполняется циклически с некоторым заданным циклом пересчета, что позволяет организовать непрерывное выполнение логики в исполнительном модуле.

Алгоритмы — отдельная тема для обсуждения. Исторически сложилось так, что автоматчик изначально не программист и знание языков высокого уровня для него не есть обязательное требование. Кроме того требования по поддержке и читабельности алгоритмов другими разработчиками привели к тому, что в данной области появился международный стандарт IEC Многие производители СКАДА-систем помимо стандарта также поддерживают скрипты — программирование на языках высокого уровня например VB , или им подобные например Ci-code, нечто Си-подобное.

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

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

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

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

Сетевая исполнительная система - российская SCADA

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

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

xn----8sbcilsttikhwjls1o.xn--p1ai :: Просмотр темы - Точки ввода/вывода

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

Многие бренды, кстати, тоже идут именно этим путем, хранят исторические данные и журналы именно в реляционных СУБД. Это, наверное, единственный вариант подсистемы, с которым я в той или иной мере косвенно уже работал, потому как одной из заплаток для СКАДы до этого я делал как раз именно подсистему сбора и архивации данных и журналов событий от СКАДы во внешние реляционные СУБД.

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

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

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

Под Новый Год приступил к графическому редактору. Хвала новогодним каникулам, было время основательно изучить данный вопрос и выбрать правильный путь. К началу весны я уже практически закончил графику и весной доработал математический движок поддержкой алгоритмов на чистом С. А сейчас занимаюсь подсистемой сетевого обмена. Вот некоторая функциональная статистика по проекту: Есть инструментальная система и два рантайма исполнительные модули, под которыми запускается исходный проект автоматизации на объекте: Рантайм под винду поддерживает и графику и математику.

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

Такое во многих СКАДА-пакетах просто невозможно в принципе. Вся архивация и журналы событий полностью в реляционную СУБД — пока MySQL. Поддерживается файл сохранения состояния системы между рестартами рантайма дамп. Формат дампа — XML. Благодаря тому, что сам проект хранится в открытом формате XML, система позволяет с помощью обычных репозиториев вести групповую разработку проекта.

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

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

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

На текущий момент для обмена с внешним и устройствами поддержаны следующие интерфейсы: ModBus TCP поддерживается RTU, но пока не включен ОРС DA Поддержка протолока ICP-CON: Также есть возможность посмотреть демо-ролики, демонстрирующие принципы работы системы. Онлайн редактирование алгоритмов на FBD в процессе отладки проекта: Онлайн редактирование графики в процессе отладки проекта: Демонстрация возможностей движка по обработке типов в реальном времени программах на FBD: Пример проекта с алгоритмом на C — демонстрируется формирование отчета в HTML-формате: Пример работы автоматического корректировщика проекта: Пример разработки простого проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если какое-либо из действий журнала проверки на этапе его выполнения не соответствует заданному мной результату — оно тут же подсвечивается и в списке и в отчете HTML красным цветом.

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

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

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

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

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

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

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

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

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

При выполнении выборки можно задать начальную и или конечную временную метку диапазона выборки. Или задать полностью свое текстовое условие выборки в синтаксисе SQL-языка. При выполнении выборки из архива процесс работы рантайма не прерывается, потому как выборка выполняется в отдельном потоке, что позволяет выполнять обработку очень и очень больших массивов данных не тормозя процесс выполнения основной задачи проекта.

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

Легко и просто работаем с архивной информацией без лишних головоломок и преград по настройке и обработке прямо внутри проекта штатными средствами! На сегодняшний день статистика по исходнику данной системы такова: Сам проект уже разросся до файлов. И когда я только успел столько награфоманить — сам не пойму. Резюмируя вышесказанное Данной статьей хотелось бы открыть небольшой цикл статей по своей разработке, поделиться с народом своим личным опытом изучения основ и принципов программирования, технологии.

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

Open source 1k авторов , 2,4k публикаций. Программирование 3k авторов , 6,7k публикаций. Системное программирование авторов , публикаций. JavaScript 2k авторов , 4,2k публикаций. Алгоритмы 1,3k авторов , 2,4k публикаций. Java 1,1k авторов , 2,2k публикаций. Информационная безопасность 2,4k авторов , 6,5k публикаций. Программирование микроконтроллеров автора , публикации.

Big Data автор , публикации. Анализ и проектирование систем автор , 1,1k публикаций. Передаю привет разработчикам компании Yandex 18k Указан только блог Орфографические ошибки Пунктуационные ошибки Отступы Текст-простыня Короткие предложения Смайлики Много форматирования Картинки Ссылки. Комментарии 61 tampere Огромный респект, я за всю свою жизнь не написал столько кода работающего в продакшене, конечно. И ведь догадывался же, что тема обширна.

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

OPC, да разного рода мелкие утилиты. Как у вас обстоит дело с поддержкой стандартов OPC? Помню, неистово бесило, что каждая скада система реализовывала его не до конца.

Сама скада может выступать в качестве OPC сервера? С ОРС все не просто, сама OPC-foundation в этом плане очень серьезно следит за тем, чтобы за любой чих разработчик отстегивал им немалые деньги. Я много искал нормальные обертки под ОРС, потому как платить ассоциации если не ошибаюсь около евро за членство и доступ к материалам я сейчас не могу. Нашел два более-менее подходящих варианта: Первый сразу встроил, там есть поддержка клиента и вроде даже сервера по OPC DA 2. Грейбоксовский сейчас вот ковыряю по части клиента хотя и серверные интерфейсы там тоже есть , в нем есть: DA, HDA, AE, и все это же также по XML, но все в коммерческой версии за денежку.

Для текущих проектов, где в основном мониторинг и частичное управление через ОРС пока хватает. Если язык реализации не принципиален — взгляните на code. Был источником данных для scada систем, брал данные из хозучета и другой скада системы по OPC, делал расчеты и суммарную инфу складывал уже в общезаводскую систему хозучета.

Серверная часть там сделана на очень хорошем уровне. Чтение тегов же я тестировал на тестовом сервере от dOPC — имхо, лучший тестовый стенд для проверки на совместимость стандартам испробовал штук 20, все фигня.

Вот с документацией да, очень туго. Найти в сети практически нереально, если не платить консорциуму за членство. Я нарыл только спеки на 3 DA и частично на 2 версию, а потом все методом тыка. Спасибо за ссылки, но язык принципиален, я пишу на C , поэтому нужны обертки с поддержкой managed кода.

Материалы по dOPC я уже проходил — брал кое-что для тестов и ознакомления, также у них даже есть обертка для. Net, но вот скачать ее они не дают. Ну как минимум взгляните на код. Довольно добротный, не думаю что возникнут сложности с портированием в шарп. У меня давно было мнение, что если начать писать СКАДу с нуля на основе современных технологий, получится удобная и красивая вещь, в отличии от грузных стандартных систем WinCC,TraceMode и т.

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

Например, последние все наши проекты по фирме выполняются полностью с использованием моей подсистемы архивации в СУБД совместно с брендовой СКАДой. Помимо этого сделал отдельное решение по моделированию объектов управления, которое сейчас потихоньку внедряем на своем полигоне, через который прогоняются все наши проекты и на котором проводим их заводские испытания.

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

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

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

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

Тогда бюджет на создание будет близок к 1 млн. Мне очень интересно что дальше будет с проектом. Сможете ли вы довести его до должного уровня и стать миллионером: Кстати, не предлагали вам еще продать его? Сейчас ведется разработка сайта, через который я планирую начать распространять свое решение уже в массы.

Последнее уже начал делать на базе движка Википедии, очень удобно получается. Насчет продажи — пока никто не предлагал продать, но тут пока еще мало кто вообще знает о том, что я делал. Сейчас вот после Хабра будет побольше уже. Однако в период информационного освещения своего детища через АСУТПшные форумы я уже успел стать официальным конкурентом для одного из производителей отечественного бренда.

Руководство фирмы разработчика СКАДы, увидев мое решение, официально возвело меня в ранг конкурента после моего отказа прекратить разработки, а сотрудничать с ними и работать ТОЛЬКО на их решении…. Мне тоже было удивительно. Чуть больше года с пивом в свободное от работы время. Примерно по строк в день. Только это не мне, а автору: Вот вам реальный пример силы энтузиазма — чел наваял за год с пивом столько, сколько средний наемный программер будет делать 10 лет. Когда спросишь у автора как так получилось — он и сам не знает, сам удивляется.

Люблю задавать каверзные вопросы. А как вы добились фиксированного времени цикла и вообще реального времени в ядре контроллера? Как реализовали обработку исключений? Что будет, например, при делении на ноль в рантайме? Как реализуется обработка отказа датчиков, АЦП, ДЦП и другой периферии?

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

Реализована ли пошаговая отладка кода технологической программы? Или только на уровне доступных вычисленных значений? Реализована ли буферизация событий на случай временного отказа архива или сети? Будут ли события, произошедшие на время отсутствия связи с архивом, потеряны на всегда?

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

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

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

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

Однако я уже сейчас продумываю как их разделить по разным потокам, чтобы не грузить основной вычислительный процесс ядра графикой. Относительно вопроса про контроллер и мнемосхему для него — вы несколько некорректно понимаете архитектуру моей системы, у меня подобное решается так: Таким образом получается проект из двух узлов: Графика мнемосхем делается как раз в АРМе, а данные для нее он по сети или последовательному каналу из контроллера уже поднимает.

Для С этого нет, там процесс выполнения по шагам только на уровне выполнения логики алгоритма на 1 такт с выводом всех входных и выходных его аргументов.

Внутренние как в профф. Более того — в случае, если буфер не удается сбросить в СУБД, а рантайм тормозят — он может скинуть его в файл, и подчитать при рестарте. Так что данные потерять совсем можно только жестко обрубив питание. Сделаем проще — приведите описание задачи, которую надо решить, а я объясню как она решается у меня. А вот насчет кластеризации — немного не понял суть, вы имеете ввиду функцию распределения вычислительной нагрузки по алгоритмам в проекте из одного узла на несколько, если один не справляется?

Однако вопрос резервирования для скады — это серьезный и многоуровневый вопрос, так что его проработка относительно сети также меня ожидает. Если не секрет, как называется САПР, в разработке которого вы принимаете участие? Мне была интересна поддержка реального времени в ядре контроллера. Под этим я понимаю гарантию того, что время выполнения цикла управляющего кода будет зависеть только от самого кода, а так же то, что управляющие сигналы будут посланы на арматуру так же за гарантированное время.

На сколько я понимаю, WinCE ядро работает под. Наконец, управляющий поток может быть просто вытеснен, если, конечно, для него не задан приоритет реального времени. Если кем-то используется неуправляемый менеджер памяти, то опять же время на выделение памяти становится непредсказуемым из-за фрагментации.

А ведь еще сам CPU очень сложное устройство — микрокод, конвейеры, кеши, контроллер памяти. Помнится, в блоге Intel на эту тему была отличная статья. Иными словами, гарантировать реальное время выполнения — труд просто титанический. Для этого как раз и придумывают множество аппаратных реализаций протоколов ввода вывода — чипы ProfiBus, ModBus, CANOpen и т.

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

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

А при кластеризации группа из 3-х и более контроллеров одновременно принимает данные, считает, и посылает управляющее воздействие. Кластеры активно используются в АСУ где любая ошибка недопустима, например, на АЭС, или при управлении газовыми турбинами. Для большинства процессов ее получается достаточно. Относительно исключительны ситуаций — тут штатные методы try-catch позволяют достаточно четко обрабатывать их без выноса основного процесса в даун.

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

Задумано все именно так. Создаем экран, где размещаем две кнопки: Аргумент экрана выходной и привязывается к каналу переменной управления двигателем через УСО. Если необходимо фиксировать команду посредством триггера, то в промежуток между экраном и каналом управления через УСО вставляется алгоритм на FBD, где стоит RS или SR-триггер по стандарту IEC у меня свыше блоков штатно в FBD по разному функционалу. Только в этом случае на экране будет уже два аргумента, а обе кнопки будут посылать 1, каждая в свой аргумент, со сбросом при отжатии.

Это и будут команды на вход триггера для SET и RESET входов. Сейчас по текущим проектам пока требуется горячее резервирование как внизу, так и наверху. Кластеризацию обычно делал на уровне алгоритмов, когда КИП троированный был, на уровне узлов пока еще не приходилось таких задач решать.

КВИНТ — знаю, вернее много слышал, и знаком с людьми, которые на ней очень плотно работали. Например, когда в Ираке Нассирийскую ТЭС пускали, оооочень много наслушался сравнительных характеристик от инженеров ОРГРЭСа был там такой — Бородкин относительно КВИНТа и ТМа. Очень интересно, какие характеристики вы слышали: Но в любом случае, это были характеристики 5й или 6й версии, я тогда в НИИТеплоприборе еще не работал: Вот 7я будет значительно лучше. Да там даже в основном не конкретные характеристики были, а больше эмоциональное сравнение.

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

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

Ну вообще говоря это означает, что к той системе undo прикручивался по ходу дела и возможно, поэтому вы тоже пришли к мысли, что этого делать не стоит. Если бы действия в программе изначально были транзакционными, то undo-redo механизм работал бы как часы. У Undo есть неприятная особенность, что если его не сделать сразу, то потом его доработка становится задачей практически перекапывания всего исходного кода приложения. У меня ушло приличное количество времени и экспериментов, что бы подобрать оптимальный паттерн реализации.

У меня всё запущено, есть СУБД, есть ORM, который за одно является VM в паттерне M-V-VM Model-View-ViewModel: Ну а в качестве Model выступают классы таблиц СУБД. View сделан на WPF. Поясните пожалуйста, у вас SCADA включает в себя и контролер, своего рода софтверная эмуляция апаратного контроллера, так? Нет, не совсем так. Архитектура проекта представляет собой два типа узлов: АРМ оператора и контроллер.

Под контроллером в моем случае понимается узел РС-совместимого устройства, в котором установлена ОС Win из линейки: WinCE, XP embedded, или вообще чистая Win, где может запускаться мой рантайм для узлов контроллеров, в котором грузится и обрабатывается этот компонент проекта.

С точки зрения архитектуры такой узел практически ничем не отличается от АРМа, тоже есть база переменных, алгоритмы, связи между ними, связь с УСО и разного рода внешним оборудованием включая также узлы самого проекта , только в нем нет графики… Нуу — пока нет. Просто отладчик проекта внутри среды разработчика умеет обрабатывать пересчитывать весь проект как единое пространство компонентов, вообще не делая упора на то, что одни узлы — это АРМы, а другие — это контроллеры. Просто в этом нет необходимости.

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

Спасибо за развернутый ответ. Например, для Siemens — это через ОРС сервер их Профибасы — ужасно закрытые стандарты с лицензиями в тридорого, а решения через API среды Step7 — не тривиальное решение, которое так и не заработало, был косвенный опыт , для Schneider — это ModBus RTU или TCP.

Вообще, поддержка в моей системе того же протокола ModBus в качестве Slave-режима дает возможность использовать наоборот — мою скаду как средство программирования Софт-ПЛК, а на верхнем уровне любую HMI из существующих.

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

Имхо, главное не к строк, а то, что потом это будет работать и внедрено на производстве. Антонов написал много хорошего ПО под необычные роутеры Pluris , но продажи железок почему-то не пошли и труд получился впустую. А так неудачный выбор инструментария разработки похоронил проект, никто в трезвом рассудке не станет гонять прокатный стан на Microsoft. НЛО прилетело и опубликовало эту надпись здесь. Очень впечатляет, огромное уважение автору.

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

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

Ну и останется только коммерческая составляющая СУБД для архивов — если для личного пользования брать, то у MySQL вроде лицензия бесплатная на это сам так сейчас разработку веду , но для коммерческого применения — уже потребуется приобретение лицензий, однако это уже вопрос не ко мне, этот вопрос должен будет уже конечный пользователь моей скады решать. Лицензия для рантаймов планируется на количество переменных параметров на 1 узел , сюда просто будут считаться все каналы тэги , которые сделаны в проекте на этот узел как внутренние, так и связанные с внешними параметрами и оборудованием.

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

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

Да, на счет качества трудно не согласится. Особенно в этом плане сдал Siemens со своей SPPA T Step7 штука проверенная временем, это да. Но ПО верхнего уровня реализовано ИМХО отвратно. Могли бы вы для статистики привести размер исходного кода в байтах. Только файлы cs, исключая ресурсы и файлы данных? Если только файлы cs, то статистика на данный момент такова: Инструменталка — объем 9,Мб Рантайм для Windows — объем 3,Мб Рантайм для WinCE — объем 2,Мб.

Всем доброго времени суток. Случайно из Томска никого нет? Сейчас нахожусь под Томском в рабочей командировке по поводу внедрения крупного проекта на точек на базе своей скады. Систему успешно запустил и уже на следующей неделе, примерно в середине, планирую 1 день быть в самом Томске. Если кому интересно — можно было бы встретиться очно, побеседовать, заодно мог бы показать и рассказать о системе вживую. Если что — пишите, о месте и времени договоримся. Можно будет пообщаться с разработчиками и задать свои вопросы, а также попробовать систему в работе.

Сейчас Вчера Неделя Сударь, ваша команда — не команда 27,6k Знайте меньше, молчите чаще: Интересные публикации Хабрахабр Geektimes. Создание языка программирования с использованием LLVM. Держитесь подальше от облачного майнинга, за некоторыми исключениями GT. Найдено самое большое обобщённое число Ферма GT. Concurrency паттерны в Rust из Java.

Ориентация мобильного робота, выбор способа регистрации особых точек изображений. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.