CM-500

О чем продукт?

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

Контекст

Это первый проект в Siemens, где я был полностью один и работал с другим департаментом: Siemens Energy, то есть от первой встречи с клиентом и юзерами до утверждения 1-ой концепции и формирования бэклога MVP. Было сложно, поскольку эта предметная область была в новинку для всех, поэтому помощи от моего департамента (Siemens AG) не было. Это было также забавно потому, что мне как ребенку объясняли про повреждения турбин на основе вибро-диагностического анализа. Это было трудно, особенно на начальном этапе. После релиза MVP наняли бизнес-аналитика Евгения, благодаря которому я с командой начали идти в сторону релизов значительно быстрее.

Стоп, это разве не ELVis 2.0?

Продукт может показаться очень похожим на ELVis и это так потому, что когда я был на встречах с клиентом и юзерами у меня маячило перед глазами “так это же ELVis”. Более того, мы пытались им продать наш продукт, но ELVis не решает проблемы вибро-диагностики, так как он для мониторинга. Помимо этого, клиент сказал что из-за юридических (Siemens Energy - другой департамент) и финансовых (платить Siemens AG) причин не хочет покупать ELVis, т.е. проще сделать своё. Поэтому я подумал так:

• ELVis’у нужна была экспертиза в вибро-диагностике, потому что это было бы отличным конкурентным преимуществом и расширением функциональности продукта.
• Siemens Energy (CM-500) же хотели запустить в кратчайшие сроки MVP.
• Я взял за основу структуру и компоненты из UI-кита ELVis.
• Это помогло мне быстро предложить концепцию первого MVP в кратчайшие сроки, а в будущем для ELVis’а уже по сути были бы готовы новые сценарии и макеты.
• Это также позволило мне удачно протестировать гибкость UI-кита под другой проект.

Какие проблемы и задачи решал?

• Погрузился в полностью в не знакомую предметную область, где у меня было очень много вопросов, которые решались регулярными обсуждениями.
• Соответственно, работал с клиентом и юзерами, выявляя все бизнес-требования на первых парах, а после работал с бизнес-аналитиком, обсуждая очередной сценарий.
• Спроектировал всё приложение обхитрив систему, т.е взяв за основу ELVis ui-kit.
• Формировал задачи в формате user story для frontend команды. Общался с backend разработчиками тоже, поскольку получение данных было сложным из-за сложности получения этой информации.
• Делал дизайн-ревью между релизами, но без упора на пиксель-перфект.
• Презентовал и защищал свои решения перед стейкхолдерами.
• Если возниколо “не бывает так, что работа начинается вообще без менеджера”, то ответ прост, прям по шагам:
  • Приходит письмо от менеджера
  • Смысл письма: “я в отпуск на весь спринт, дальше сам, старт проекта тогда-то”.
  • Это может показать проблемой, но это нормально. Мне было это интересно, поэтому далее я пошел общаться с клиентом, юзерами и затем, сделав первый концепт, передал знания менеджеру.
• Реальной же проблемой было то, когда менеджер предложил свое видение, которое тупо копировало “хотелки” клиента и полностью проигнорировал уже защищенную концепцию, перейдя к новой. Эту ситуацию пришлось решать через новые встречи и обсуждения с клиентом и всеми заинтересованными сторонами.
• В итоге пришлось откатывать с “новой идеи” до изначально утвержденной концепции. Так бывает, решения принимаются сверху, но надо такие ситуации контролировать и объяснять людям иногда заново, чтобы всем было хорого. Была ли частично работа из-за менеджера “в стол”? Конечно! Хорошо, что у Siemens много денег, на ошибки. 😁

Какой был процесс?

К интервью надо было готовиться, потому что ни у кого в команде не было знаний. Информацию я искал и находил по крупицам с ютуба и гугла. На удивление попадались как видео, так и статьи и документация о вибро-диагностике.

Во время интервью я просил рассказать о проекте и контекстно прояснял непонятные мне моменты. Таким образом, задавая тупые вопросы, удавалось выявить паттерны, сценарии, а также инсайты в предметной области.

🤩 Лайфках: заранее читать про нишу и подготавливать вопросы от общего к частному и углубляться. Можно даже поделить вопросы для анализа на функциональность и эмоциональные сигналы.

🤩 Лайфках: можно вовремя интервью узнать как инженеры вообще “живут” и работаю, чтобы попасть в представление инженера о будущем продукте. Например, можно спросить о проблемах, которые юзер испытывает в процессе не только связанном с интерфейсом.

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

YT

🤔 Линейный график - это обычный график, на котором линия или несколько линий, показывают то, как одна или несколько переменных изменяются со временем.

‼️ Сенсор - это не 1 параметр, например температура, как было в ELVis. Это сигнал.

‼️ Сенсор = гармоники (1x, 2x, …) = компонент исходного сигнала в системе.

‼️ Чтобы получить гармоники, используется преобразование Фурье для преобразования сигнала. Например, гармоника 1x соответствует компоненте сигнала равной частоте вращения вала и аналитикам важно видеть первые гармоники, отдельно или в комбинации, потому что это показывает неисправность.

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

☝️ Поясняю на пальцах: луч проходит через призму и делится на спектры. Луч проходит постоянно через призму, т.е. у нас есть время. Затем луч дробится на спектры - это цвета. У цветов есть частота и амплитуда колебаний в зависимости от частоты. Преобразованиефурье может показать сигнал, который меняется со временем в виде зависимостичастоты и амплитуды + дает информацию офазе.

‼️ Сигнал - какая-то информация, которая меняется со временем в системе. Например частота вращения.

‼️ Амплитуда - высота кривой. ‼️Фаза - начальная точка синусоиды. ‼️Частота - это скорость, с которой что-либо в системе повторяется. Например, скорость вращения вала.

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

🤔 У графика было два вида визуализации: точками и линией. Потому что это математика и это сложно. Линия - это условность, аппроксимация - это когда нужно заменять что-то сложное на что-то более простое и понятное, которое приближённо равно исходной фигне. Такой фигней являются математические функции, поэтому если точек (значений) нет по середине, то используется аппроксимация, чтобы достроить приближенные значения, а точки это исходные данные как есть.

🤔 Помимо этого у графика есть Operational mode - визуальное отображение показателя скорости оборудования.

😳 Интересный факт: Наши глаза кстати видят волны спектра. В глазах есть клетки: колбочки - различают цвета, но нужна высокая яркость, а такжепалочки светочувствительны и видят интенсивность цвета. Колбочек есть 3 типа, которые отвечают за длину волны спектра, которые мы ловим и видим цвета: RGB. Смешно здесь то, что мы улавливаем, но видим лишь отражения цветов виде спектра волны, но не сам цвет. Такие дела.

Scatter

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

🤔Корреляция - связь 2 величин, где смена одной из них сопутствует систематическому изменению другой. При этом связь может как быть, так и не быть причинно-следственной. Например, две величины зависят от третьей, но не зависят друг от друга.

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

🤔 Всегда надо очень четко различать корреляцию и причинно-следственную связь. Если между переменными есть причинно-следственная связь, то между ними точно будет корреляция.

🤔 Но если между переменными наблюдается корреляция, то причинно-следственной связи может не существовать. Единственный способ доказать наличие причинно-следственной связи – провести эксперимент, поэтому это важно для инженеров, ведь речь идет о безопасности людей и эксплуатации дорогого оборудования.

Stacked

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

stShiftPos

🤔 График помогает аналитику понять положение вала в подшибнике. Это нужно, чтобы инженеры могли понять, как вал плавает в масле в турбине. Важно видеть положение вала при изменении скорости, разгоне и остановке. Именно в этот момент его начнет качать в подшипнике.

Polar

🤔 График показывает то, как меняются фазы и амплитуды компонентов вибраций. Например, для первой гармоники может увеличиваться амплитуда или поменяться фаза (градус) и тогда можно сделать вывод что с оборудованием что-то не так.

Orbit

🤔 Это 2д график построенный из вибраций сенсоров физически расположенных под 90 градусов по отношению друг другу. Нужен для анализа для видимости объемного движения вала.

🤔 Также, если аналитик способен исследовать траекторию, по которой движется, например ротор, когда он вибрирует в своих подшипниках, аналитик может лучше понять, что вызывает вибрацию. Это именно то, что дает график: карта пути, по которому движется Ротор во время вибрации.

🤔 Тоже самое, только если хочется сравнить два сенсора.

Time wave function

🤔 Суть как в графике выше (orbit), но когда нужно анализировать один сенсор. Вообще основная суть в том, что это сырые и не агрегированные данные.

Nyquist

🤔 График Найквиста показывает то, как меняются компоненты вибрации при увеличении или уменьшении вращения турбины. У каждого оборудования есть критические обороты, которые надо быстро пройти при разгоне, например от 0 до 3000, где от 1800 до 2800 наступают критические обороты. Если посмотреть, то каждая точка как раз таки отмечаются обороты.

Выводы

🐺 Я может и не может, но хотя бы не я

Попробовал себя в роли “мини-менеджера” и хорошо себя зарекомендовал. После cm500 я уже смог выполнять проекты самостоятельно, не нагружая менеджера: общался с клиентом от и до релизов, проектируя приложения и ведя задачи сам.

✅ Контроль за ситуацией на уровне смысла, а не пикселей

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

✅ Новая предметная область

На момент старта cm-500 я уже был в Siemens 2 года, что помогало мне на этом проекте, но приходилось понимать уже новые сценарии инженеров.