Снова всем вечер добрый.
Продолжаю цикл своих статей, предыдущая находится здесь.
Чем дальше в лес, тем толще партизаны, а времени в сутках все меньше и меньше. Но не смотря на своеобразный перегруз я все же упорно продолжаю совершенствоваться и прилагать свою неуемную фантазию с инженерными помыслами к своему детищу, на которое уже основательно подсел. На текущий момент на моей системе уже сделаны и внедрены 5 реальных объектов, три из которых сделали любопытные сторонние разработчики, которым было интересно пощупать систему в деле. Хоть объем их не так и велик, но все же это уже что-то, референс растет. Сам я, не размениваясь по мелочам, как тот, которому больше всех надо, лезу в самое пекло — итогом которого уже стали две крупные разработки на моей скаде: на 3000 точек ввода/вывода (система работает уже почти полгода и сейчас перешла в промышленную эксплуатацию) и вот недавняя на 5500. Но обо всех новшествах чуть ниже и по тексту...
Начнем с прогресса, который как известно не стоит на месте. Очередным толчком к мысли «а есть ли жизнь на Марсе» стала как раз система на 3000 точек, где в диспетчерской стоят аж 3 АРМа на базе моей скады. А где диспетчер — там всегда картинки.
Вдоволь наигравшись с возможностями GDI+ по части графики, я таки дал им то, чего они хотели увидеть, и запустив систему на объекте в промышленную эксплуатацию, я подошел к моменту, что заказчику, как эксплуатирующему лицу — стала позарез необходима документация в виде «руководства пользователя». Заказчик попался дотошный и попросил предоставить ему совсем подробную версию такого руководства, где были бы все возможные формы экранных мнемосхем этой системы. «Ага, сказали мужики» и начали скриншотить их… Ха, не все так просто, где-то на 50-м скрине мне стало тошно от такой рутины, а их постоянные «вот тут давай подправим» все время видоизменяли эти формы и их приходилось скриншотить по-новой, модифицируя предварительный документ для утверждения в верхах. Пришлось ваять специализированную функцию рантайма, по которой он сам на автомате генерирует ВСЕ экранные формы в виде файлов изображений (кстати, потом хочу воспользоваться удобным форматом офисного MS Word, чтобы также автоматом собирать само руководство в нужном СНИПе). И вот когда на выходе системы рантайм задумался и выдал 390 экранных форм, мне малость поплохело от мысли, что ЦПУ не резиновый, и GDI+ конечно просто и удобно, но надо бы уже задуматься о современных бонусах цифровой техники и возможностях аппаратного ускорения для видеосистемы, а то глядишь, непомерные аппетиты красивостей могут вскоре на таких решениях полностью сожрать производительность современных процессоров. Дополнительным пинком для этого также стали замечания сторонних наблюдателей: «эээ, а чего это загрузка ЦПУ на АРМе почти всегда процентов 60-80?». Объяснять, что процессор для того и создан, чтобы работать — можно, но все же он не только на графику должен ориентироваться, пусть это и АРМ оператора.
Итак — вооружившись мыслями о том, что я подсел на .Net основательно, я стал копать информацию, а что же мне могут предложить современные технологии. И началось: жалкие потуги проб DirectX, OpenGL и некоторых платных движков на их базе для упрощения процесса конечному разработчику. В итоге все не то — или лыжи у меня не ехали, или я — … Ну не гуру я в программировании на таких уровнях, обидно стало.
В общем — решил, что рано или поздно, но технологию WPF и работу в формате XAML мне все же придется пощупать. Пощупал… Ужас какой-то, я первую книгу по WPF и XAML в 1000 страниц «заглотил» аж за неделю в электричке, я так художку не читал никогда в жизни. А под впечатлениями от изученного за 3 дня умудрился накидать прототип своего нового редактора FBD-алгоритмов. Честно говоря, первые три дня меня аж малость распирало от того, что я раньше этим не занялся. Уж больно сильно меня впечатлили возможности и технологии, наверное как школьника от впервые в жизни прочитанного фантастического произведения мирового классика. Но больше всего меня поразило то, насколько я близко подошел к данной технологии, когда «изобретал» свой собственный графический движок для своей скады на DGI+ и формате XML. Многие моменты у нас с мелкомягкими оказались чуть ли не один в один прототипами с одного чертежа. Аж, даже некоторая инженерная гордость обуяла.
Не долго думая я начал изучать возможности создания рантайма под текущую версию своей скады, но уже с аппаратным ускорение графики и дополнительными возможностями XAML и WPF. Сейчас получился некоторый прототип вьювера, который позволяет без проблем открывать в приближенном виде экраны моего текущего формата скады и портировать их на лету в XAML, а отсюда открываются возможности по разделению разработки графического интерфейса не автоматчиком, а настоящим дизайнером и в настоящих профессиональных системах для того предназначенных. Я сейчас активно пробую работать в этом направлении с Microsoft Expression Blend (в нижеприведенных роликах используется именно он).
Попутно решил создать уже третью версию своей системы моделирования технологических объектов «Моделист» (из которой кстати и вырос мой текущий FBD-редактор алгоритмов в скаде), она используется мной активно для отработки проекта и его алгоритмической части на полигоне перед отправкой на объект. Еще будучи в предыдущих версиях помогала мне настраивать системы вообще без посещения объекта, а потом запускаться на объекте с минимумом доработок и дерганий самой технологии. Если интересно, могу привести реальные примеры, где экономия времени была воистину колоссальной, а сам объект просто бы не позволил экспериментов над собой вживую ввиду его опасности.
Сейчас новая система Моделиста будет доработана как штатный внешний отладчик для моей текущей версии скады, он позволит подключаться по сети к работающему проекту под отладочными исполнительными модулями и в реальном времени подменять текущие параметры системы моделью, которую сам разработчик также в режиме исполнения сможет создавать и отлаживать не нарушая самого проекта и не останавливая его. Этот метод сейчас очень активно используется нами на полигоне, чтобы прогонять все наши решения перед отправкой на объект.
Выглядит примерно так (кликабельно):
По графике некоторые из экспериментов со вьювером и блендом:
А здесь немного по новому Моделисту:
Правда тут совсем ранняя версия 3-х дневная, сейчас он уже малость заматерел и умеет побольше, чем на видеоролике.
Примечательно, что размер приложения, что на ролике всего 100КБайт, как-то даже не солидно для современных скада-систем.
Особо интересующимся — даже выложил на пробу эту версию на одном из асутпшных форумов, особо порадовал единственный из комментариев: «Теперь я понял почему немцы войну проиграли.». Кстати он же был и единственным, народу почему-то или было лень смотреть, или просто уже нечего после этого сказать.
Но графика графикой — а о сервисах тоже стараюсь не забывать. В начале июня возникла еще одна интересная ситуация, которая подтолкнула меня включить в свою скаду более расширенную работу с таблицами сигналов проекта, вернее выполнить сервис разработки проекта по исходным данным ТЗ.
Немного предыстории: приходят ко мне 31-го мая с ТЗ на одну систему, в которой 5500 точек ввода-вывода, благо система без графики, НО — исходные узлы системы являются шлюзовыми для очень крупного проекта на другой скаде, которая не умеет работать с железом, которое представлено внизу, а моя — умеет. И надо работать с низовым оборудованием через встроенные драйвера, а вот с верхней скадой работать уже по ModBus TCP/IP обмениваться по сети, то есть полноценная поддержка ModBus TCP/IP Slave режима.
Отлично, экраны рисовать не надо, надо все это только сконфигурировать в проекте и подготовить документацию на адресные пространства по ModBus TCP/IP протоколу для разработчиков верхнего уровня.
Вроде посильная и простая задача, но, снова это самое НО:
1) По срокам дотянули до того, что система должна быть отгружена на объект уже 10-го июня!!! И не просто отгружена но и готовая, то есть — работающая!
2) В ТЗ все материалы включая таблицы сигналов представлены в формате PDF, который к тому же еще и закрыт паролем. НЕНАВИЖУ проектировщиков, работающих в PDF (сколько не работаю, все время данный формат вызывает только торможение в процессе разработки)! Хоть раз заставить бы их самих делать системы по документации, представленной в таком формате.
3) Так как система шлюзовая, то разработчики верхнего уровня сидят без работы, ведь им нужна документация по шлюзам с регистровкой каждого параметра по ModBus, без нее верхний уровень не доделать и не запустить.
В общем, условия забавные… На мой вопрос «а где вы были раньше и что так затянули проект?» только развели руками и стали заводить старые песни о главном…
Ладно. Сел я подумал и понял, что первым делом надо всю эту информацию утянуть в проект. Однако 5500 сигналов бить ручками по визуальной документации в PDF — мартышкин труд и таких мартышек нужно будет много, а их нет, как и времени. Попытка пройтись файнридером по PDF выдала прикольный документ, где названия вроде те, а местами и не те, например обозначение тока «I» где-то превращалось в символ «1». И все эти мелочи сильно портили общую структуру полученного текста, а править его — опять нет времени. Про лом пароля утилитой тоже идея не прижилась. И тут мне пришла идея все же допилить механизм работы с таблицами сигналов, который я уже в некотором виде заложил в среде разработчика. Ну что, как там говорится «Валера, настало твое время!» (с)
Впереди было 10 дней и совсем немного свободного времени, а также главное правило из всем известного мультика: «Лучше день потерять, зато потом за два часа долететь!». А «летать» по подобному маршруту по типовым решениям впереди маячило очень сильно.
Исходя из текущих требований я малость расширил диапазоны и «навернул» чуть больше, чем это понадобилось для этого случая, но тут уж просто в раж вошел.
Идея получилась следующей: разработчик в скада-системе постоянно получает ТЗ, где основными начальными данными для формирования базы параметров проекта является таблица сигналов. Сами таблицы сигналов в основном представляются в структурированных форматах (csv,excel,word, таблицы СУБД), конечно же велик соблазн перекинуть все это структурированное многообразие через обычный буфер обмена методом copy-paste, что и было мной сделано. Теперь для быстрого формирования набора сигналов проекта можно просто копировать столбцы сигналов из ТЗ прямо в проект скады через буфер обмена. Так как некоторые объекты оборудования с их перечнями параметров часто повторяются, или есть вероятность их многократного использования в будущем — добавлена возможность импорта-экспорта самих готовых таблиц сигналов из скады в файлы формата XML. Формат получился несложный, так что может даже использоваться для автоматизированной обработки сторонними средствами. В самой таблице сигналов сделан сервис по групповому редактированию параметров, перетаскиванию сигналов между разделами и некоторый сопутствующий мелкий сервис.
Учитывая, что обработка дискретных сигналов ведется в скаде в упакованном виде в форматах: байт, слово, двойное слово, длинное целое, для каждого дискретного сигнала можно заранее определить группу и его номер входа по УСО, который определят его номер бита в этой группе.
Кроме того, для удобства разбора полетов по работе проекта, когда от проверяющих приходят замечания, таблица сигналов получила интерактивность: каждый сигнал в таблице после проведения автоматического построения базы параметров проекта по ним получил реальную привязку к компоненту проекта и даже к источнику этого сигнала в проекте к его аппаратному описателю. Это дает возможность разработчику открыть таблицу сигналов, выбрать «проблемный» сигнал и по контекстному меню быстро позиционироваться в проекте на компонент, который его обрабатывает. А уже далее можно от этого компонента разворачивать штатными функциями перехода по зависимостям всю цепочку обработки этого компонента в алгоритмах, экранах и межкомпонентных связях, анализируя где и что сделано не так и почему не работает.
В итоге, потратив где-то неделю перерывов свободного времени на разработку такого сервиса и его отладку, настал апогей и торжество технологий: исходный проект в СКАДА-системе был собран абсолютно с нуля по имеющемуся ТЗ, с генерацией выходных форм документации, в которой указана регистровка параметров системы с точностью до бита с полноценными комментариями, названиями и прочим, всего за 1 час работы в скаде! Только карты адресов параметров по проекту в формате HTML на обе области (HEX и FLOAT) весят почти по мегабайту. Все это было тут же передано разработчикам верхнего уровня, включая сам проект, а на следующий день получен результат об успешном предварительном испытании.
Работа на этом конечно не закончена 100%, однако сделан серьезный задел для проектирования и формирования типовых наработок на будущее по типовым решениям.
Буквально на прошлой недел вернулся с этого объекта, где за 1.5 дня я причеса текущий вариант проекта и запустил его в работу! Вуаля, перепрыгнуть через голову оказывается можно.
Сейчас по результатам я дополняю скаду сервисом быстрого тиражирования текстовых составляющих из таблиц сигналов на журналы словарей, графику, ведь текст сигнала — это некий информационный параметр, который так или иначе используется в проекте, так зачем его каждый раз набивать ручками, если он уже есть в проекте как ресурс?
Как пример — тоже набросал небольшой ролик по данной технологии:
Ладно, буду закругляться, а то хотел маленько, а получилось как всегда — какой-то информационный понос, который ни мозгам ни рукам в процессе кодинга мне покоя не дает.
Спасибо за внимание и тем, кто дочитал до конца. Но, уверяю — это еще не конец, все больше убеждаюсь, что это все только начало… Читаю литературу, пишу, внедряю и уже многие разработчики систем АСУТП начали работать и щупать мою систему применительно к своим задачам, что идет ей только на пользу! До скорых встречь на хабре и не только!
Автор: Romer
