Кто впервые читает - я разрабатываю полный стек платформы для промышленных контроллеров на микроконтроллерах и FPGA. Сюда входит:
Собственная графическая среда разработки: для языков LD, FBD (ST - только для описания функциональных блоков). То есть, тут нет каких либо открытых библиотек или фреймворков. Благодаря многолетнему опыту создания с нуля всевозможных графических приложений в промышленности;
Собственный компилятор так же с нуля (не LLVM, clang и прочие конструкторы) , специально для ПЛК.
Виртуальная машина, или интерпретатор байткода на микроконтроллере или FPGA (смотря какая производительность нужна).
Проект рассчитан на работу с железом от 5кб ОЗУ и 32Кб флэш.
Учился у Allen Bradley. То есть среда поддерживает сложные цепи с бесконечными вложениями, и автоматической отрисовкой цепей ( а не ручной перестановкой каждого блока как у OpenPLC\Beremiz,)
В отличии от упомянутых OpenPLC\Beremiz которые состоят из разных открытых проектов и не имеют своего компилятора(плк программы переводят в СИ текст): у нас тут единый полный стек: скачал среду - и у тебя ПЛК из микроконтроллера(если есть плата соответствующая), без всяких танцев с поиском компиляторов, настройками через консольные строки, возня с прописыванием каких то путей и прочим.
С публикацией несколько задержался. Проект уже открытый - пока для теста нескольким фирмам по железу. Сам я железом заниматься не планирую (адекватно расцениваю свое время), смотрю в сторону сотрудничества с существующими командами которых в мире много. Но как только получу рекомендации - проект станет открытым под лицензией Apache 2.0.
Приветствую, камрады. Возникла у меня необходимость осваивать контроллеры от Weintek, в связи с чем вопрос: нет ли у кого ссылок на материалы по этим железу от этого производителя вообще и Codesys 3.5 в частности?
Я инженер АСУ ТП. Много лет искал Modbus Tester, о котором мечтал — удобный, бесплатный, работающий везде. Не находил. В итоге мы вместе с ИИ-ассистентом сделали его сами — за один день.
Что не устраивало в существующих
Настольные программы глючат и зависают в самый неподходящий момент.
Бесплатные версии режут функционал: то тегов мало, то экспорт только в Pro.
Только Windows — а у меня Linux, у коллеги macOS.
На чужом ноутбуке ничего не поставить — политика безопасности, и ты сидишь без тестера.
Нужные функции разбросаны по пяти разным утилитам.
Что получилось
Веб-тестер, который работает прямо в браузере. Chrome, Edge, Opera. Ничего не устанавливать. Windows, Linux, macOS — одинаково. И главное — не глючит и не зависает. Открыл, подключил USB-RS485, работаешь. Хоть час, хоть сутки. Настройки сохраняются, соединение не отваливается, ничего не надо перезапускать.
Что умеет
Чтение и запись — все функции Modbus: 01, 02, 03, 04, 05, 06, 15, 16. До 125 регистров одной командой. Перед отправкой видно HEX-кадр запроса.
Сканирование Slave ID — находит устройства в линии 1–247 за пару минут. Не надо перебирать вручную.
Brute-force адресов регистров — перебирает диапазон и показывает рабочие адреса. Спасение, когда нет документации.
График в реальном времени — до 100 000 точек на линию, несколько параметров одновременно, свои имена и цвета тегов, автошкала или ручная шкала.
Математика на графике — считает формулы прямо по регистрам: #0 - #1, avg(#0..#4), if(#3 > 100, 1, 0). Перепад давления, среднее по датчикам, пороговые сигналы — без Excel.
Визир с прилипанием — навёл мышь на график, видишь точные значения всех линий в этот момент времени.
Звуковая сигнализация — пищит при обрыве связи. Порог, повтор, тип сигнала — настраивается. Фон страницы меняет цвет: зелёный — связь есть, жёлтый — ошибки, красный — обрыв. Видно издалека.
Мониторинг с HEX-логом — каждый запрос и ответ в HEX, с метками TX/RX и временными штампами.
Экспорт в CSV — скачать или дозаписывать в тот же файл каждые 500 опросов. Данные не потеряются.
Статистика связи — счётчики отправленных, полученных, ошибок. Сразу видно качество линии.
Плюс мелочи: тёмная тема, сохранение тегов и цветов в браузере, автоопрос, калькулятор глубины записи, скрытие линий кликом по легенде.
Честно о минусах
Работает только в Chrome, Edge и Opera — Safari и Firefox пока не поддерживают Web Serial API. Только RTU и ASCII — Modbus TCP в планах.
Но все минусы временные. Плюсы — фундаментальные.
Как сделали
Я не программист. Писал задачу по-русски, ИИ генерировал код, я тестировал на реальном железе и говорил «не работает — вот ошибка». Через пару итераций — работало.
Утро — первое чтение регистра. День — таблица, запись, мониторинг, лог. Вечер — график, имена тегов, звук. Ночь — тесты на датчиках и ПЛК. Основа была готова за один день.
Предысторию разработки собственного рантайма, IDE, поддержка 61131-3 смотрите в моем блоге - ссылка в конце статьи.
В целом была идея, разработать отечественный рантайм для ПЛК и IDE к нему, которые были бы шустры, легки и производительны. Пока, как мне кажется, это удается. Скомпилированный бинарник IDE сейчас занимает около 1 мб. Запущенный рантайм, в текущей реализации, занимает около 5 мб ОЗУ и несколько процентов цпу ( до 5%) на Распберри 4, на нескольких одновременно работающих конфигурациях. В общем, понемногу движемся в правильном направлении, товарищи. Сегодня, хотел бы показать дальнейшую эволюцию этой идеи.
Немного про стек разработки. Напомню, что IDE и рантайм для ПЛК у меня разработаны под Линукс. Пишу на C++, собираю под Cmake как под x86-64, так и под ARM. В качестве внутренней коммуникации реализовал свой бинарный протокол, на базе ZeroMQ и FlatBuffers. Транслятор с промышленного языка — ANTLR. Из промышленных протоколов коммуникации, пока поддержка - Modbus. Планирую добавить в дальнейшем OPCUA. IDE — написан на чистом C++ и Qt Рантайм — чистый C++ IDE с рантаймом общаются по собственному бинарному асинхронному протоколу, о котором писал выше.
IDE поддерживает два типа логики IL и ST. Зачем IL спросите вы? Исторически, случилось так, что рантайм начался с этого языка. И это не совсем IL — это полный аналог языка устройства Tesys T. Сами разработчики писали о нем как об structural text языке. Короче, я собирался реализовать рантайм, и чтобы он полностью поддерживал программы, которые были написаны для Tesys. Также мне понравилась как он был реализован. Вот так с тех пор он и остался, и благополучно работает.
Дерево элементов конфигураций ПЛК.
Фокус на элементе логики на IL
Фокус на элементе логики ST
Один элемент конфигурации — это 1 логика своего типа (IL или ST). Он же, отдельный выделенный поток для исполнения данной логики. Каждый поток, работает независимо и в параллель. Сколько элементов — столько и параллельно работающих потоков, исполнителей логики.
Компиляция. Для компиляции ST 61131-3 я написал свой транслятор на базе ANTLR. Перед загрузкой, логика компилируется в IDE и проверяется на ошибки. Успешно или нет логика скомпилирована, информация выводится в панель снизу.
Ошибочная компиляция программы на ST
Компиляция успешна!
Сохранение и открытие. Теперь конфигурации можно открыть и сохранить из IDE. И да, это банальный элемент, но без этого никуда. Что кстати требует довольно приличного времени на проектирование, разработку итд.
Настройки подключения и проверка связи.
Подключаем к ПЛК очень просто. Нужно на вкладке настроек подключения вбить настройки IP адреса и кнопку «Подключиться».
Настройки подключения
Если подключение успешно, в статус панели значок подключения сменит цвет на зеленый. Если связи нет, или был обрыв — иконка сменит цвет на красный.
Есть связь с ПЛК! Кнопка подключения сверху - как кнопка питания.
Связи нет.
Завел кнопку для запроса у работающего ПЛК перечень конфигураций в работе.
Перечень конфигураций в работе на ПЛК.
На ПЛК летит команда, с запросом. Список конфигураций высвечивается в нижней панели.
Три конфигурации - логики активны, и работают в параллель на ПЛК
Набор кнопок, с разным функционалом.
Кнопка отправить все конфигурации на ПЛК
Спокойно, загружаем и выгружаем через IDE с ПЛК конфигурации.
Автозапуск. Загрузив через IDE в рантайм 1 раз конфигурации, которые он благополучно сохранит и при его перезагрузке стартует снова с ними же.
В одной из прошлых статей, писал про разработку программного осциллографа, чтобы писать аварийные события в формате COMTRADE. Это больше для устройств РЗА, конечно, но скажем в устройстве Tesys T осциллографа сильно не хватало. Короче он также может запускаться в составе рантайма, хотя его можно и отключать. В той прошлой статье, я писал про него подробно. У него крутая возможность — с его помощью можно генерировать самые разные осциллограммы, причем можно создавать различные аварийные режимы.
Отладка.
Код на ST 61131-3 у меня в IDE можно отлаживать на «живом» рантайме ПЛК. Завел кнопку Отладка.
Кнопка с жуком - это отладка.
Когда у нас фокус на какой либо конфигурации и мы на связи с ПЛК, после нажатия на Отладку, на ПЛК летит команда — перезапустить поток в специальном отладочном режиме. Это в принципе такой же рабочий режим, все сигналы всё то же самое, что у нормального, но у него имеют некоторые существенные отличия от нормального режима. В общем, поток с логикой перезапускается в отладочный режим и мы можем ставить точки останова.
Отладка переменных - пока всё по нулям
Ставим точку останова, там где программа заходит в участки кода на ST. Может и не зайти, если там есть условия итд. Наблюдаем в окне имена и значения переменных в зоне видимости участка кода программы.
Тут логика активирована сигналом - переменные со значениями.
— Рекомендуется временно воздержаться от дальнейшего вмешательства.
Особенно если рука уже тянется к Download.
PROLEGOMENA CODEX NЁH EXTERMINATUS
О том, зачем Искоренителю правила, если он и так знает, что делает
Кодекс появился не потому, что Искоренители не знают, что делать. Как правило, знают.
Именно поэтому у них есть: доступ; инструмент; пароли; право менять параметры; возможность остановить агрегат; возможность его запустить; и иногда возможность одним нажатием превратить локальную НЁХ в мероприятие с участием руководства. При особо удачном нажатии — ещё и с отдельным пунктом в протоколе совещания.
Неопытный специалист опасен незнанием. Опытный иногда опаснее. Потому что способен ошибиться: быстро; уверенно; технически грамотно; с правами администратора; и с абсолютно убедительным объяснением того, почему сейчас необходимо нажать именно эту кнопку.
Иногда объяснение настолько хорошее, что кнопку хочется нажать даже тем, кто до этого вообще не знал, где она находится.
Поэтому однажды стало понятно: Искоренителю нужны правила не вместо квалификации. Ему нужны правила именно потому, что квалификация у него уже есть.
Кодекс не должен связывать ему руки.
Искоренитель, который боится любого вмешательства, бесполезен примерно так же, как Искоренитель, который вмешивается раньше, чем успевает подумать.
Первый будет долго смотреть на неисправность. Второй довольно быстро обеспечит ей компанию.
Поэтому положение Искоренителя должно быть несколько неудобным.
Он обязан быть: ДОСТАТОЧНО УВЕРЕН, ЧТОБЫ ДЕЙСТВОВАТЬ. ДОСТАТОЧНО КОМПЕТЕНТЕН, ЧТОБЫ ДЕЙСТВОВАТЬ ОСМЫСЛЕННО. И ДОСТАТОЧНО ОПЫТЕН, ЧТОБЫ ПЕРЕД ДЕЙСТВИЕМ ПРОВЕРИТЬ, НЕ ОХУЕЛ ЛИ ОН. Последнее не отменяет первые два. Именно оно позволяет ими пользоваться.
Кодекс не делает Искоренителя непогрешимым. Таких положений в него не включено за отсутствием экспериментальных подтверждений. Опытная эксплуатация гипотезы также дала неудовлетворительные результаты.
Он не запрещает ошибаться. Не требует сомневаться в каждом собственном движении. И тем более не предписывает стоять возле шкафа в ожидании, что проблема: — Может, сама рассосётся.
Иногда, конечно, рассасывается. Обычно вместе со сменой, производственным планом и надеждой лечь сегодня спать.
Кодекс нужен в другом месте.
В тот короткий момент между: — Я понял. и: — Сейчас сделаем.
Именно туда Кодекс пытается успеть вставить ещё один вопрос: — А я действительно понял? Не: — Мне кажется, я понял? Не: — Я уже всем сказал, что понял? Не: — Я эту хуйню сто раз видел?
А именно:
— Я действительно понял?
Если да — делай. Если нет — сначала установи, чего именно тебе не хватает. Факта? Измерения? Схемы? Состояния? Понимания последствий?
Или пяти минут, чтобы перестать быть самым опасным человеком возле шкафа?
LATINA CAMPALIS
COGITA. DEINDE AGE.
Доктринальный перевод:
Действие Искоренителя должно следовать за достаточным пониманием цели и ожидаемого результата вмешательства.
В прошлом году я начал публиковать первые тесты своего компилятора WIA32 и среды разработки 3o|||sheet на различных микроконтроллерах и FPGA (STM32, CH32, Altera Cyclone 4). Был и российский АМУР MIK32.
На одном известном ресурсе, по поводу подобных МК были возражения типа - 16 КБ ОЗУ, что из этого можно сделать в современном мире?
Рантайм (регистровая ВМ) моей разработки выполняющая байткод на стороне железа, требует всего 5 КБ RAM, поэтому в подобный МК как АМУР MIK32 с 16 КБ влезает достаточно много(в сотни LD\FBD блоков, или несколько сотен ST строк ) программы причем с изолированным выполнением. То есть, речь идет не о зависшей задаче, это - самый легкий сценарий ,так как планировщик все равно задачи меняет. Речь об устойчивости к тотальному краху данных.
Таким образом 3o|||sheet является первой(?) средой где АМУР MIK32 успел побывать полноценным промышленным контроллером хоть и в тестовом режиме, а не игровой консолью, умным домом или мигалкой светодиода.
ПЛК на АМУР MIK32 как аналог Schneider Zelio Logic
Своему софт-процессору и набору команд дал название - WIA32 (переводится как - широкий непосредственный адрес) который и отображается на графике синим. Тут данные по скорости выполнения программ лестничных диаграмм или функциональных блоков (ST - не тестирую, так как в документации брендов ПЛК нет данных производительности алгоритмов на ST чтоб сравнивать).
Не путать тест с бенчмарками, производительностью машинных инструкций и программ написанных на СИ.
Тестирование производительности ПЛК на базе MIK32 Амур в сравнении с ПЛК разных брендов с рынка.
Если б я делал ПЛК на АМУР MIK32 то получил бы аналог программного реле Schneider Zelio Logic. Это с точки зрения производительности, хотя в данный момент моя ВМ - трансформируется, и не оптимизирована под конкретную архитектуру. Я не производитель ПЛК и не занимаюсь глубокими оптимизациями своей ВМ под отдельный чип для максимума.
Но в отличии от среды Schneider , у меня более продвинутые функции, так как мой компилятор WIA32 поддерживает:
Сложные данные (структуры в структурах, многомерные массивы и прочее).
Такой вид данных поддерживается моим компилятором:
Гибкость. Использование сложных структур и многомерных массивов данных в программе Промышленного Контроллера.
Сложные структуры любого уровня можно использовать в лестницах и блоках.
Менеджер адресов который точно расставляет данные\инструкции в памяти, расставляет адреса и не промахнется ни на один байт среди миллиарда - отдельный шедевр мысли.
Так как у нас свой компилятор и собственный софт процессор - есть возможность безопасно добавлять структуры данных и менять код на лету не перезагружая ПЛК вообще. Добавлять новые программы которые тут же заработают как в смартфоне установленное только что приложение с маркета.
Schneider , китайские, российские и многие другие страны создающие ПЛК (те которые на собственной среде, а не на Codesys) не поддерживают работу с многомерными массивами, вытесняющими задачами, заменой кода на лету и другими возможностями для которых нужен собственный компилятор. Практика перевода языков МЭК 61131-3 (IEC 61131-3) в язык СИ а потом прошивка в ПЛК обычным компилятором, как это делают в Beremiz и 95% разработчиков ПЛК - дает легкий и быстрый эффект в разработке, но такие ПЛК очень деревянные/неповоротливые, и подвержены трудно уловимым ошибкам с тяжелой (или невозможной) отладкой.
Сама среда, графический движок от Schneider - сильно уступает моим наработкам тоже. У Schneider можно создавать “строки” из 5 элементов и одной катушки, в то время как мой движок (без каких либо фреймворков - рисует примитивами) - может отображать любые разветвленные ветки и связи любой сложности, создавать собственные блоки любых размеров с любым количеством переменных и структур и описывать их программно.
Промышленный процессор на базе микроконтроллеров с 4-6 КБ ОЗУ как MIK32 Амур или STM32G030 можно использовать не только как ПЛК, но и - Конструктор кастомного пульта - рабочее место оператора.
То есть не пульт с вылитым корпусом на фабрике, или корпуса в которых надо что то сверлить или отвертками крутить . Имеет смысл - дизайн модулей с разным набором кнопок, ползунков и т.д с использованием настройки экосистемы и среды для ПЛК.
Когда процессор от ПЛК может стать процессором пульта и обратно, подключая нужные наборы кнопок, джойстиков или модулей ввода/вывода.
Но идея не только в дизайне, но и подходе к надежности. В чем лично моя идея это - разработка самого надежного отказоустойчивого пульта в промышленности, работающий по принципу Zero Protocol.
Обычно в АСУ ТП между модулями идет общение по CAN и подобных протоколах. Я разработал гибрид с конфигурацией на подобии идеи конфигурации FPGA:
Шина,например CAN/RS485 - тоже есть, для конфигурации,и низкоприоритетных задач.
Шина Zero Protocol - прямые линии- провода(в зависимости от количества входов у процессора CPU).
Визуально это выглядит вот так:
Подключение к процессору - модулей с кнопками (на подобии модулей ввода вывода)
с нужными комбинациями энкодеров, кнопок , ползунков и т.п. С двумя шинами: протокольная (CAN\RS485) и прямая Zero Protocol.
Преимущества дизайна:
Единая среда разработки программ для ПЛК и пультов с автоматической детекцией подключаемых, типов кнопок/ползунков/энкодеров,в единый дизайн.
Кнопки можно покупать конечно отдельно и подключать их к ПЛК, но это годится только для закрытых шкафов. Для пульта внутри машины/или управлять светом на дискотеке со сцены - не практично и не красиво. Я не просто инженер, по второму диплому (и со стажем) - преподаватель живописи и графики. Дизайн - неотъемлемая часть моего мышления, нахожу это - красивым.
Преимущества технические:
Реакция на нажатие кнопки, энкодера и т.д - нулевая задержка. Прямой провод, никакого зависания коллизий линии и прочее.
Подтверждение (прошел сигнал/не прошел) - как второстепенная информация. Если подтверждение придет через 0.5 -1 секунд - неважно, главное реакция на нажатие оператором - сработает 100% без зависаний.
Если оператор видит машины или механизмы своими глазами - все подтверждения по проводам - избыточны.
Если оператор не видит глазами - происходящее (задвижка какая нибудь), то задержка подтверждения в 0.5 - 1 секунду роли никакой не сыграет для реакции человека, зато может сыграть для критического сигнала (например кнопки STOP) 0.5 сек - это много, и есть смысл убрать протоколы замедляющие сигнал идущий в -> сторону машин и механизмов.
Мы имеем программируемые модули кнопок, с автоматическим отображением переменных в среде, при том сохраняя всю скорость реакции как у прямого примитивного железа.
Таким образом у нас машинный контроллер имеет три приоритета на реакции:
1) Высокий приоритет, например кнопка STOP и подобное, работает в обход процессора (к процессору подключен но только для регистрации времени события например или для сообщений в SCADA).
2) Средний приоритет - так же работает без протокола, по прямому проводу, но есть задержка в размер цикла (программируемая реакция, может быть добавлен алгоритм обработчик).
Это как будто бы вы подключили просто кнопку/рубильник к входу обычного ПЛК как упоминалось ранее, но естественно эта кнопка не отобразится в обычных ПЛК и средах, все нужно прописывать руками. В нашей Среде она - отобразится автоматически (тип, название) по протокольной шине.
3) Самый низкий приоритет - те кнопки и элементы которые полностью на линии CAN/TCP и др., там время реакции большое:
Сигнал должен пройти все рукопожатия, контрольные суммы, побороть коллизии + быть обработан в цикле ПЛК.
Как раз на этом уровне и работают всякие модули в ПЛК мировых вендоров, И они это называют - надежным модулем. В моем представлении это считается самым медленным и ненадежным в сравнении с Zero Protocol.
Перефразируя коротко мою идею - это так: обеспечить прохождение сигнала в ту сторону (до машины) без помех и риска, а обратно (от машины) - как у всех, через шину с протоколом типа CAN/RS485.
Я больше склоняюсь к RS485 (и с ним экспериментирую ) так как такой модуль кнопок можно обеспечить на совсем примитивных и дешевых микроконтроллерах с UART и 1-2 кб ОЗУ и получить надежность превышающую дорогие пульты называющие себя - отказоустойчивыми.
Коротко: ищу работу начинающего разработчика/пнр асу тп, вахта или удаленка для старта приветствуется.
Длинно: 39 лет, отработал 15 лет фулстек разработчиком в небольшой продуктовой компании, основной стек (.net, js, python, c++, win/linux, docker), всегда тянуло в «автоматизацию», поэтому помимо программирования выстраивал инфраструктуру (git + ci/cd, авто тестирование, резервирование и авто восстановление). Этим летом закрыл свои задачи, передал дела и ушел, отдохнул, поработал физически, разгрузив голову и теперь думаю что дальше.
Сейчас изучаю специфику АСУ ТП - с программированием ПЛК нет непреодолимой проблемы, понимание рабочего цикла контроллера в рамках окружающего оборудования формируется. С схемами сложнее, дочитаю про ПЛК, буду шерстить эту тему. Далее видимо документация, оборудование, основы проектирования. Не уверен, что именно в таком порядке надо, как-то само сложилось по ходу дела.
Попутно изучаю рынок труда - везде слышу о нехватке специалистов, есть вакансии, без опыта отказ сразу - понимаю, зона ответственности высокая, цена ошибки велика. Особо остро стоит проблема локации - глубинка Иркутской области, местные предприятия набор не ведут, переезд я рассматриваю, но сильно зависит от дохода - я не против просесть на старте, но аренду/еду нужно оплачивать, поэтому около бесплатная стажировка не вариант.
Не жду, что сейчас посыпятся офферы со всех сторон:) Но советы хотелось бы увидеть как и что, особенно от людей в этой сфере.
В настоящем трактате используется ненормативная лексика. Не для эпатажа. Не вместо технических терминов. И не потому, что автору не хватило литературного словаря. Иногда выражение «неведомая ёбаная хуйня» точнее описывает диагностическое состояние системы, чем три абзаца производственно-технической дипломатии. Там, где достаточно нормального инженерного языка, используется нормальный инженерный язык. Там, где без мата теряется смысл происходящего, мат остаётся.
САМО ОНО, БЛЯДЬ, НЕ МОГЛО
Итак.
После семи глав, нескольких притч, полевых наблюдений и объёма ненормативной лексики, достаточного для признания работы межотраслевой, Институт прикладного НЁХоведения готов представить главный результат исследований.
Просьба приготовиться. Результат фундаментальный. Возможно, человечество уже никогда не будет прежним.
ЕСЛИ ТЕХНИЧЕСКАЯ СИСТЕМА ДЕЛАЕТ КАКУЮ-ТО ХУЙНЮ — ЕСТЬ ПРИЧИНА, ПО КОТОРОЙ ОНА ДЕЛАЕТ ИМЕННО ЭТУ ХУЙНЮ.
Да. Вот так. Семь глав. Ради причинности.
Нормальный электрик возле шкафа сформулировал бы это за пять секунд:
— Само оно, блядь, не могло.
После чего закурил бы и занялся делом.
Научному сообществу потребовалось несколько больше текста.
Но зато теперь это теория.
За время исследований не удалось обнаружить ни одного устройства, которое официально призналось бы: — Да просто захотелось. Не найдено контакторов, сознательно саботирующих производственный план. Не зарегистрировано ПЛК с выраженной неприязнью к ночной смене. Не подтверждено влияние ретроградного Меркурия на промышленный Ethernet. Не обнаружено статистически значимой связи между фазой Луны и перестановкой слов в FLOAT. Хотя по последнему пункту Modbus продолжает находиться под наблюдением. Также не подтверждено существование маленького долбоёба внутри шкафа, который по ночам переставляет биты.
Это несколько разочаровывает. Потому что многое бы объяснило. Но нет. Остаётся физика.
Физика вообще оказалась крайне неудобным участником исследования.
Она: не ходит на совещания; не читает протоколы; не знает оргструктуру; не признаёт авторитет должности; и совершенно не понимает формулировку: «ВОПРОС ВЗЯТ НА КОНТРОЛЬ». Можно написать: «ПО РЕЗУЛЬТАТАМ ОБСУЖДЕНИЯ ПРИНЯТО СЧИТАТЬ ОБОРУДОВАНИЕ ИСПРАВНЫМ».
Оборудование: — Нет.
Можно назначить ответственного за температуру подшипника. Подшипник: — Очень рад. И продолжает греться.
Можно утвердить план корректирующих мероприятий. Плохой контакт ознакомится с ним в рабочем порядке. И продолжит быть плохим контактом.
Физика обладает крайне слабой корпоративной культурой.
ЕЙ АБСОЛЮТНО ПОХУЙ, ЗНАЕМ МЫ О НЕЙ ИЛИ НЕТ.
Очень неудобная наука.
Особенно оскорбительно, что причина не обязана соответствовать масштабу расследования.
Ты имеешь право потратить: восемь часов; три службы; четыре ноутбука; одного подрядчика; полтора гигабайта логов; двадцать семь чашек кофе; и существенную часть психического здоровья.
После чего причина имеет полное право оказаться: ПРОВОДОМ. — Каким? — Вот этим. — А что с ним? — Болтался. — И всё? — И всё.
Вот это настоящее профессиональное унижение.
Потому что после восьми часов расследования причина уже должна соблюдать приличия. Хотя бы редкий дефект прошивки. Хотя бы температурно-зависимый отказ. Хотя бы какая-нибудь ебанутая гонка состояний, которую потом можно достойно рассказывать коллегам.
Но нет. ПРОВОД.
А рядом лежит итоговый отчёт на двенадцать страниц. С диаграммой.
Физике похуй на драматургию.
Отдельную область фундаментальной метрологии пришлось открыть для измерения инженерной уверенности.
Основные единицы: «мне кажется»; «похоже»; «скорее всего»; «сто пудов»; и предельное: «Я ТЕБЕ ГОВОРЮ».
Последняя единица особенно интересна тем, что численно может стремиться к бесконечности при полном отсутствии измерений.
Средство поверки пока не разработано.
Государственный первичный эталон предположительно находится у самого уверенного человека в смене.
В ходе исследований обнаружен ещё один парадокс.
Фраза: «Я НЕ ЗНАЮ» звучит значительно менее профессионально, чем: «ПРОБЛЕМА, СКОРЕЕ ВСЕГО, В КОНТРОЛЛЕРЕ».
Хотя первая содержит ровно один факт. И факт этот достоверен.
Молодой специалист иногда произносит «не знаю» так, будто после этого у него автоматически аннулируется диплом. Не аннулируется. Проверено. Группа по электробезопасности тоже остаётся.
Максимум выясняется страшное: инженер пока не знает причины.
Бывает.
Самой крупной методологической проблемой НЁХоведения стала попытка формализовать выражение: «НУ ОНО ЖЕ ЗАРАБОТАЛО».
В ходе испытаний выяснилось, что эта формулировка отвечает только на один вопрос: «РАБОТАЕТ ЛИ ОНО В ДАННУЮ СЕКУНДУ?»
На вопрос: «ПОЧЕМУ?» она отвечает: «НЕ ДОЁБЫВАЙСЯ».
Методологически слабовато. Поэтому старое положение остаётся в силе:
ЗАРАБОТАЛО — НЕ ДИАГНОЗ.
Хотя как настроение — очень даже.
Был также исследован термин: «НЕИСПРАВНОСТЬ УСТРАНЕНА».
Фраза прекрасная. Уверенная. Документальная. Особенно когда на вопрос: — Какая была неисправность? следует: — Ну… что-то было.
Получается безупречная конструкция:
НЕИСПРАВНОСТЬ: НЕ УСТАНОВЛЕНА. УСТРАНЕНИЕ: ВЫПОЛНЕНО.
НЁХоведение признаёт данный результат выдающимся. Устранено неизвестно что. Неизвестно каким образом. Но подпись есть.
Инженерная алхимия достигла промышленного масштаба.
И вот здесь Трактат действительно обязан закончиться.
Не потому, что про НЁХ больше нечего сказать. Этой хуйне можно посвятить кафедру. А через пару лет кафедра начнёт выпускать методические рекомендации по правильному оформлению НЁХ.
Закончиться надо потому, что следующий объект исследования значительно сложнее.
Он способен менять поведение после получения новой информации. Игнорировать инструкцию. Защищать любимую гипотезу вопреки измерениям. Говорить: — Я ничего не трогал. После чего выясняется, что под словом «трогал» он понимает несколько иной набор действий. Имеет административный доступ. Иногда отвёртку.
ЧЕЛОВЕК.
Именно поэтому дальше начинается: КОДЕКС ИСКОРЕНИТЕЛЯ НЁХ
Трактат был посвящён вопросу: «ЧТО ЗА ХУЙНЯ?»
Кодекс будет посвящён вопросу: «КАК, ИЩА ЭТУ ХУЙНЮ, НЕ СОЗДАТЬ НОВУЮ?»
Задача, как показывает практика, значительно сложнее. Потому что техническая система хотя бы вынуждена подчиняться законам природы. Искоренитель обладает свободой воли. Это серьёзный недостаток архитектуры.
Поэтому понадобились: Клятва. Заповеди. Полевой устав. Великие ереси. Запретные искусства. Литании.
То есть пришлось создать целый Кодекс только потому, что фраза: «ДУМАЙ, БЛЯДЬ, ПЕРЕД ТЕМ КАК ТРОГАТЬ» оказалась совершенно исчерпывающей — но плохо проходила нормоконтроль.
Искоренитель НЁХ — не человек, который всегда знает причину.
Человек, который всегда знает причину, называется иначе. ПОДОЗРЕВАЕМЫЙ.
Искоренитель может ошибиться. Может выдвинуть хуёвую гипотезу. Может проверить её. Получить: — Не оно. И обладать редчайшей профессиональной способностью ответить: — Значит, хуёвая была гипотеза. Ищем дальше. Не объясняя после этого сорок минут, почему гипотеза вообще-то была правильная, просто объект повёл себя некорректно.
Это и отличает инженерную деятельность от религиозного культа собственного мнения.
На этом фундаментальная часть НЁХоведения завершена.
За семь глав так и не удалось экспериментально подтвердить единственный механизм, который действительно всё бы упростил: «САМО КАК-ТО».
Очень жаль. Пришлось оставить причинность. Поэтому какой бы ебанутой ни выглядела происходящая хуйня, в конце остаётся один вопрос: ПОЧЕМУ ИМЕННО ТАК?
Пока ответа нет — НЁХ остаётся НЁХ.
Институт прикладного НЁХоведения считает теоретическую часть завершённой.
