История про то, как молодому специалисту дали карт-бланш в реализации автоматики сложной установки, и вроде бы у него даже что-то получилось.
Как я там оказался
На самом деле официально никто никакого карт-бланша, конечно же, не давал. Просто не ограничивали.
Шёл 2011 год, я только-только закончил универ по программистской специальности в небольшом городе. В группе я более-менее проявлял интерес к технологиям и кодингу, и поэтому вскоре на меня вышел один из начальников местного предприятия. Мы сидя в машине поболтали о моих увлечениях всяким там программированием, я заверил, что отличаю вольты от амперов и джаву от джаваскрипта, и на этом собеседование было успешно пройдено. Зарплата планировалась в районе 20 тысяч рублей.
Ещё на собеседовании меня испугали терминами SCADA и ПЛК, о которых я практически ничего не слышал. Особенно страшно было ещё и потому, что по цифровой части этой установки всё лежало на мне, вчерашнем студенте. Может, кое-кто на этом предприятии и подхватил бы меня если что-то пошло не так, но я быстро набирался опыта и знаний.
Легаси
Всё это не было проектом с нуля. Уже эксплуатировалась подобная старая установка с ручным управлением. Кроме того, автоматизацию уже начинала делать какая-то другая контора. Мне передали некоторые файлы, в которых я не нашёл ничего похожего на автоматику, о чём и сообщил руководству. С этой точки мне позволили игнорировать то, что сейчас назвали бы "легаси", и переписать проект.
Слово "легаси" хорошо подходило и к физическому состоянию предприятия, особенно той части, где предстояло обитать мне. Замшелые цеха и конструкторские помещения, кульманы (!), ящики советской электронной комплектухи, какие-то древние осциллографы, банки с просроченной паяльной химией. Увлекательный хлам, короче. Картина показалась бы мрачнее тому, кто в детстве не копался в советской аудиотехнике и не приделывал поворотники к своему велосипеду. Но я копался и приделывал. Однако вернёмся к проекту.
Итак, нужно очень-очень хорошо откачать воздух из печки и потом много часов греть что-то внутри неё. Вручную этим управлять муторно, процесс хорошо автоматизируется. Предлагается взять контроллер, написать на него управляющую программу, поставить комп, на него поставить SCADA-систему, набросать в ней мнемосхему и всё это связать. Традиционно контроллерная часть называется нижним уровнем, а всякие штуки на компе - верхним. Оба уровня - за мной. Дедлайн через пару лет.
Что бы сделал профессионал? Он бы сделал буквально всё, что написано в предыдущем абзаце, и был таков. И ещё был бы прав. Что в итоге сделал вчерашний студент с амбициями разраба и дизайнера? Конечно же пошёл гуглить передовой мировой опыт чтобы сделать покруче. Придумывать фичи и так далее.
Верхний уровень
Итак, я сел гуглить как делают другие. Смотрите, у меня даже папка с рефами осталась из 2011-го:
Тут не нужно крупно разглядывать, да и я покажу парочку ниже. Просто прочувствуйте вайб (кроме АСУТПшников, они давно пропахли этим вайбом). Дальше в течение двух месяцев произошёл дизайнерский спидран.
Level 1. Я запилю так же с градиентиками.
Level 2. Я запилю круче всех в 3D по чертежам чтоб вообще отвал башки (на первом курсе баловался 3d max).
Level 3. Я запилю по книге.
Level 4. Я запилю как сам считаю нужным.
Level 5 (до которого я не дошёл из-за недостатка мудрости и надзора): запилить как нужно компании и чтобы это можно было поддерживать.
Да-да, при зарплате 20 тысяч рублей я заказал книгу с Амазона за 5 косарей, ибо в пиратском виде её нигде не было. Это сейчас её можно найти и даже прочитать суть на одной странице. Я вам даже короче одной страницы её перескажу: нужно использовать сдержанные цвета, простейшую графику, ярко подсвечивать нештатные ситуации, и показывать не только текущее состояние но и тренд во времени. Название этой передовой на тот момент мысли (по крайней мере среди изготовителей вакуумных печек) - "situational awareness". Вся книга пляшет вокруг этого термина. Ещё там есть забавная мудрость про киношные интерфейсы, от которых отмахиваются труъ-айтишники: эти интерфейсы очень хорошо коммуницируют ситуацию, и в этом нет ничего плохого, это можно и нужно брать на вооружение в реальном мире.
Просветлённый книгами (ок, одной книгой) и разочарованный тогдашними "скадами", я взялся делать свой UI вообще с нуля. "С нуля" не только в том смысле, что поставил Visual Studio и пошёл кодить на C# (WPF) кастомное приложение, но и в том, что отбросил почти все каноны. Нет, это не было каким-то озарением, где я такой типа "все каноны фуфло и я точно знаю как надо делать". Во многом я нашёл оправдание своим идеям уже постфактум.
Как обычно строятся "промышленные" интерфейсы? Берём обзорную конструкторскую схему, убираем лишнее и делаем её цветастой в тех местах, где состояние может меняться. Зелёненький, красненький, жёлтенький. И непременно поярче, а то вдруг зелёный от красного не отличат.
Ок, можно и на более сдержанную картинку глянуть, там та же совокупность приёмов.
Автор той книги немало рассуждает о том, что включенное/выключенное конфликтует по визуализации с исправным/неисправным если тупо всё выделять зелёным или красным. Мне этого показалось мало, и я пришёл к ещё одному выводу: статичные бумажные обозначения не должны диктовать динамические. В книге есть кое-что о формах, но почему-то не распространяется на обозначения.
Ведь если мы берём статичную схему и всего лишь её раскрашиваем, то мы никак не задействуем возможность экранных элементов менять форму. Можно поспорить, что форму на схемах менять вообще антинаучно, но ведь нужно учитывать подготовку пользователя, а он у нас весьма подготовленный (лично нами сразу после пусконаладки). Можно хоть кошечек и собачек вместо открытых и закрытых клапанов показывать. Оператору важнее текущее и предыдущее состояние, а не корректность символов по чертёжным стандартам.
У меня даже как-то спросили почему клапан на моём экране не клапан. Кроме "все так делают" и "по ГОСТам надо вот так" аргументов с той стороны не было. ГОСТы, естественно, не про экраны были. Просто почему-то некоторые люди очень расширительно их толкуют. Вот бы им в машины вместо спидометра и check engine схему ДВС зарисовать! В то же время я понимаю, что много где строгая схема весьма уместна как доступный дублёр документации, но это не мой случай.
Попутно с формами можно порассуждать и о пропорциях. На интерактивных схемах трубопроводы/провода и прочие соединения продолжают рисовать тонкими линиями как на отдельных видах конструкторских схем. Это ведь тоже не обязательно правильно. Цвет тонкой линии плохо читается.
И что же я сделал? Смотрите:
Шутка. Это тоже нарисовал я, но более-менее традиционными обозначениями для панели ручного управления. Точно так же схема могла бы выглядеть и на экране. Жаль с огоньками не сфоткал.
Итак, мы хотим лучше задействовать форму, цвет и пропорции (ну ок, за 20к/мес никто этого не просил кроме как я у себя). Выкидываем сложное статичное обозначение клапана...
... и начинаем искать форму. "Трубы" потолще чтобы потом раскрасить по состоянию, клапаны очень условно изобразим, но чтобы "работали".
Хрень какая-то. И форма не сильно изменилась при смене состояния. И уродливо ппц. Угол только поменялся. Круг он повернул, дизайнер блин)) Попробуем смелее:
О! Вот так чётко. Чё там на схеме будет?
Опять хрень какая-то. Сливается всё. Может, даже хуже чем по канонам было бы. Но мы ещё не задействовали "трубы". А как их задействовать? Цветом/штриховкой. А по каким соображениям раскрашивать? По закрытым и открытым клапанам, конечно же. Звучит просто, но на самом деле нифига не просто.
Если представить, что есть некоторая магистраль с четырьмя клапанами подряд,
-------><------><------><------><------
V1 V2 V3 V4то какой смысл раскрашивать участок V2-V3 по состоянию этих клапанов при закрытых V1 и V4? Тут маячит какое-то "И" или даже какое-то "ИЛИ". Но если взять систему труб с перемычками, то всяких И/ЛИ там будет просто не счесть. Или счесть? "А что если это граф" - вспомнил универ я и набросал такое:
Рёбра - клапаны, вершины - трубы (кстати это контринтуитивно с чисто визуальной т.з.). Вот с этим уже можно работать. Достижимость атмосферы в вакуумной системе это уже реальный бизнес-кейс, заказчик будет рад. Смотрим что получается если подкрашивать участки по графу. Штриховка - достижимость атмосферы, заливка - вакуумирование, без заливки - по умолчанию.
О! Чётко. С клапанами можно было вообще не заморачиваться, но пускай будут, ибо красивше. Да и не врисовать традиционные клапаны на толстую трубу.
Графовую модель системы трубопроводов и клапанов можно использоват ещё и для защиты от "дурака". Тут нужно заметить, что в установке мы предусмотрели три режима:
Полный автомат. Как стиральная машинка.
Ручное "логическое" управление (с компа через контроллер).
Ручное электромеханическое управление (кнопками на шкафе). Так называемая "наладка".
И если по автомату и электромеханике либо дурак ничего не сделает, либо мы не сможем ничего с ним сделать, то при ручном управлении с компа можно проверить команду прежде чем отдать её на выполнение. Например, можно сымитировать открытие/закрытие клапана на отдельном инстансе графа, и если действие ведёт к потере вакуума или перегрузке насоса, то можно запросить у оператора подтверждение.
Даже окантовку диалоговых окон я сделал не просто так. Без неё окна немного терялись. Опять же никто не просил, сам придумал проблему и решил её.
Графики
Визуализировать текущее состояние это одно. Показывать как ситуация развивалась это уже другое. Книга про HMI очень рекомендует графики. Большие, маленькие. Я согласился с рекомендациями и запилил регистрацию всех параметров с отображением в реальном времени и периодическим сохранением на диск (вдруг компьютер отключится). Можно было закрыть и открыть обратно приложение, потеряв не более 10 сек данных.
Я пытался сделать даже круче - чтобы текущий сеанс регистрировался ещё и на самом контроллере. Но чем ближе к пусконаладке, тем больше я понимал, что делаю то, чего никто не требует. Фичеризм. О том, что обычно делают гораздо проще, я узнал уже потом.
На скриншоте выше видно, что я заморочился с тем, чтобы у графика слева была логарифмическая шкала. Благо компонент позволял переопределить очень многое. Фиксация параметров происходила где-то раз в секунду. Если затолкать столько точек в несколько графиков на протяжении многих часов, то всё висло. Если реже фиксировать, то пропадало чувство реалтайма. В итоге я сделал промежуточный data source для этих графиков, который учитывая выбранный масштаб делал reduce до близкого к пиксельной ширине графика значения, и работало это очень быстро.
Была там и печать графиков. Кастомная, качественная, векторная. При печати на принтер или в PDF выглядело отлично. Я доволен этой разработкой технически, но с точки зрения требований это, конечно же, был сильный оверкилл.
Нижний уровень
Легаси-проект ориентировался на ПЛК (программируемый логический контроллер) DirectLogic. Я потыкался в среду их программирования DirectSOFT, и мне она показалась какой-то недоразвитой. Возможно, я слишком программист и недостаточно инженер. Как бы ни было, коллега показал мне CoDeSys 2.x, и это уже походило на нормальную IDE, которая застряла хотя бы в 2000-м году, а не в 1995-м. Контроллеры взяли Овен.
Как оказалось, программирование таких штук это отдельный жанр. В нём есть что-то от обычного десктопного программирования, что-то от микроконтроллеров, что-то даже от геймдева (в плане состояний и т.п., не графики конечно же). Твой заказчик это технолог, который документирует, в каком порядке что должно работать и на что реагировать.
Когда кто-то видит фотку с виндовым компом на промышленном объекте и шутит, что вот сейчас оно уйдёт в BSOD и прихватит с собой ближайшие населённые пункты, то знайте, что технологическим процессом почти наверняка руководит другой комп, более предсказуемый, а ПК с виндой это так, фронтенд.
Трудно визуализировать скриншотами чего я там накодил в ПЛК. В первую очередь это, конечно, программа автоматического режима. Включили один насос, подождали, открыли клапан, подождали, и так далее. Верхний уровень тем временем постоянно (много раз в секунду) считывает по эзернету небольшую область памяти контроллера, которая представляет состояние процесса и отдельных элементов. В эту же область записываются команды с верхнего уровня, и контроллер при допустимости их исполняет (например, недопустимо реагировать на команды ручного управления клапанами в автоматическом режиме).
Ещё прикольно было, что программу ПЛК требовалось сделать задолго до того, как все железяки были собраны вместе. Поэтому вместо реальной печки ты, например, собираешь в железный ящик три лампы накаливания (по одной на фазу) и подключаешь это к тиристорному регулятору куда потом подключат печку. В этот же ящик суешь термопару, и вот с подкрученными в программе константами ты уже можешь отлаживать процедуру нагрева. Интеграционное тестирование. Препродакшен-окружение.
К счастью, программа в ПЛК получилась практически без излишеств. Её смог бы поддерживать человек, который не горит кастомной реализацией как тогда горел я.
Спустя три года и ещё пару подобных проектов я осознал, что мои навыки больше пригодятся там, где ПО это не просто бесплатное приложение к железу, подтянулся до необходимого минимума в веб-разработке и ушёл перекладывать json слева направо за более вменяемые деньги.
