Моя СКАДА

Вот еще одна удобная "фишка" моей системы:

Ссылка на файл: ]http://romer.justudio.ru/Downloads/HMIfastDublicate.avi

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

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

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

Ссылка для скачивания: http://romer.justudio.ru/Downloads/PRGonlineScripting.avi

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/HMIgeMovePath01.avi 

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/HMIgeMovePath02.avi 

Немного о типах данных.

Система поддерживает следующие типы данных:

Float - стандартный 32-х разрядный float

Double - стандартный 64-х разрядный double

Hex8, Hex16, Hex32, Hex64 - от однобайтового целого до 8-байтового целого. Для этих типов всех из перечисленных в реальном времени имеется доступ: к каждому его биту (как на запись, так и на чтение), битовых пар (запись/чтение), полубайтов (запись/чтение) и байтов (запись/чтение). Формат числа может быть десятичным, шестнадцатеричным, со знаком или без. Кроме того поддерживаются для всех этих типов побитовые маски инверсии, а также маски несовместимости для контроля достоверности данных.

DateTime - 8-байтовая метка времени, которая может обрабатывать временные данные с точностью до миллисекунд (или даже тиков), штатный Long, который применяется в большинстве скада-систем тут нервно курит в сторонке. 

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

ArrayList - динамический массив любого их вышеперечисленных типов данных, включая даже самого себя (да да - можно делать динамические многомерные массивы любой размерности и любого типа данных), причем работает штатная обработка даннго типа в алгоритмах. Теперь легко работать с выборками данных, динамическими архивами и прочими интересными вещами в реальном времени. Те, кто знаком с технологией .Net - думаю все поймут без разъяснений, да - это реальная "фкусняшка" для разработчика. 

При межкомпонентных взаимодействиях внутри системы все эти типы легко "раскладываются" на float, double, bool, byte, ushort, short, uint, int, ulong, long, string, char, datetime, timestamp типы, причем на этом же уровне динамический массив arraylist также работает как обычный тип данных.

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

Немного примеров разработки собственных визуальных приборов для графики:

Стрелочный прибор. Ссылка для загрузки: http://romer.justudio.ru/Downloads/HMI_device1.avi 

Блок гистограмм. Ссылка для загрузки: http://romer.justudio.ru/Downloads/HMI_device2.avi 

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

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/HMIgrop_lib_Demo.avi 

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

1) Поддерживать неограниченное количество уровней

2) Этот список уровней должен быть динамическим как для среды разработки, так и для рантаймов - чтобы административный персонал мог в любой момент менять политику прав доступа оперативного персонала на уже работающей системе без помощи разработчика

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

4) Удобный механизм назначения уровней элементам проекта (в основном в графике), набор системных уровней

5) Удобный и гибкий механизм назначения этих уровней пользователям - динамический список их привилегий в системе, редактируемый как в среде разработки проекта, так и в рантайме

6) Динамический список пользователей в рантайме, чтобы процесс добавления новых пользователей и назначение им прав доступа не требовал полной модификации проекта и перезапуска его только разработчиком!

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

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

В общем - в целом получилось несколько навернуто по описанию и функционалу, зато очень просто в разработке... 

Ссылка для загрузки: http://romer.justudio.ru/Downloads/UserRightsDemo.avi 

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/DynamicArrayDemo.avi 

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/ProjectDebugging.avi 

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/AutoCheckerDemo1.avi 

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/AutoCheckerDemo2.avi 

Автоматизация - она ведь не только для производства! 

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

Редактор словарей для журнала событий позволяет удобно редактировать списки сообщений. Предусмотрены следующие удобные функции:

1) Теперь у каждого сообщения есть имя, по которому можно понять, что это за сообщение. Например для дискретных каналов, если первоначальный текст сообщения исправлен, не надо сидеть и вручную отсчитывать по несколько раз сообщения от начала списка, боясь сбиться со счета, чтобы понять а для какого бита этот текст и для какого режима (False или True).  Кто работал со словарями в ТМ6 поймет всю прелесть этой "фишки".

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

3) Редактор умеет групповым образом назначать категорию для сообщений - просто выбираем список сообщений и драг-н-дропим на него нужную категорию из списка категорий.

4) Для маньяков больших систем, или тем, кто реально работает по ТЗ (оказывается бывает и так  ) - есть возможность импорта списка сообщений прямо из Excel (или другого текстового редактора с разбиением списка сообщений на строки). Просто копируем список в буфер обмена и вставляем его в выбранную группу событий словаря, редактор сам разместит тексты по событиям согласно их строковым позициям. Помнится как-то раз мне пришлось заносить в проект около 5000 сообщений из Excel'я в проект ТМ6 - ох и поматерился я тогда, когда по одному сообщению туда-сюда копипастил, работка не для нервных... 

5) Ну и обратная комбинация - экспорт через буфер обмена списка событий словаря во внешнее ПО.

6) Ну и напоследок - немаловажный аспект: длинна сообщения практически неограниченна (конечно есть предел в 2 с лишним миллиарда символов, но тут надо уже сильно маньячить, чтобы его достичь   ).

Ну и демонстрашка этих функций со ссылкой для загрузки: http://romer.justudio.ru/Downloads/AlarmDictionaryEditor.evi

Особо интересным получился размер среды разработки - при всем ее навернутом функционале, что уже тут частично продемонстрирован, инструменталка со всеми библиотеками занимает всего 3.5Мегабайта! 

При таких размерах ее удобно всегда иметь при себе...   

Это без справочной системы... Видимо справка будет все же больше самой СКАДы занимать. 

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

Демонстрируется работа в алгоритмах с динамическим массивом. В проекте есть канал динамического массива, который упаковывает свои аргументы в массив. Этот массив передается в программу, в которой все элементы суммируются и результат возвращается в виде суммы этих значений. Так как массив динамический - изменение количества упаковываемых аргументов в него не влияет на алгоритм обработки этого массива. Аргументы могут быть как свободные значения, так и привязанные к атрибутам каналов проекта. Используя такой механизм работы с данными можно удобно и быстро передавать в алгоритм большие объемы параметров проекта для алгоритмической обработки, при этом не создавая кучу аргументов для каждого параметра, которые имеют фиксированное количество в списке. Один аргумент в программе, способен передавать массив данных от 1 до 2 млрд. элементов ЛЮБОГО типа данных от чисел до строк, даже можно оперировать массивами массивов, с безграничной вложенностью. Вложенные массивы позволяют организовывать многомерные массивы.

Ссылка для загрузки: http://romer.justudio.ru/Downloads/ArrayPRGdemo.avi 

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/OPCconnectionDemo.avi

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

Ссылка для загрузки: http://romer.justudio.ru/Downloads/OPCarrayReading.avi