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

Введение

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