Pull to refresh

Comments 44

Проблема была в том, что участники проекта мало обсуждали друг с другом проблемы на стыке областей. Скажем, инженер мог бы вместе со схемотехником подумать об улучшении конструкции датчика, а схемотехник с программистом — о рациональном использовании периферии микроконтроллера.

Получается, что проблема не в самом разделении труда, а в отсутствии конкретного опыта у членов команды, которые, в итоге, прошли тернистый путь в решении определенной задачи и присущих ей проблем. Хотя слабее всего тут выглядит программист, который «рассчитывал, что задержки приведут лишь к равномерному смещению момента». Странно слышать о том, что программист на что-то подобное рассчитывал при работе с устройством, ключевая функция которого зависит от подобных допущений.
Программист рассуждал довольно просто. Микроконтроллер всегда просыпается в равных условиях. Т.е. запускает один и тот же осциллятор, включает одну и ту же периферию, так что и задержка должна быть равномерной. К тому же, просмотрев даташит, программист увидел, что задержка довольно таки небольшая. Он не рассчитывал, что она внесёт столь ощутимый вклад, чтобы обсуждать этот вопрос с метрологом. Всё-таки чтобы понимать что важно с точки зрения метрологии, а на что можно забить, нужно иметь какое-то представление о погрешностях и как их правильно считать.
Да, конечно, особенно если «программист знал, что время пробуждения сравнимо со временем нахождения клапана в открытом состоянии». В таких проектах, где хард и софт должны объединиться в готовое устройство, и эти части не разрабатываются на условном аутсорсе по сухим спецификациям, члены команды с разным профилем обычно проявляют интерес к соседним областям знаний, чтобы поменьше проблем потом вылезло. Да и расширить свой кругозор никогда лишним не бывает.

Спасибо)
Роль человека оркестра, точнее дирижера, в каждом проекте должен играть руководитель. Только его компетентность в целом по проекту даст положительный эффект.
А руководитель по принципу — чтобы было завтра и главное покрасить зеленым — ожидаемо проваливает проект
Это не всегда так. В частности в этом проекте ключевой фигурой был инженер-конструктор. Именно он придумал расходомер и принимал ключевые решения. Программист и схемотехник играли роль помощников, которые должны были добавить к устройству мозги, преобразующие показания клапана в осмысленные числа. Почему так сложилось, что проектом руководит человек, ничего не понимающий в программировании — тема отдельного разговора.
В сложившейся ситуации человек-оркестр не брал руководство на себя, он лишь решил возникшие проблемы в реализации и коммуникации внутри проекта. Проектом продолжал руководить инженер-конструктор.
А когда не так — обращение к сторонним специалистам говорит о некомпетентности руководства, которое либо не способно подобрать для проекта нужных специалистов, либо скоординировать их работы
Описанное в статье счастливое решение проблемы за счет компетентности третьей стороны
Всё верно, увидели, что собственной компетентности не хватает — нашли компетентного спеца на стороне, happy end.
Обращение к экспертам на самом деле как раз очень правильная практика, к сожалению крайне редко используемая в России. Её не мешает практиковать даже если в проекте всё с виду хорошо, а уж если появились большие задержки на «ровном» месте тем более. Сторонний взгляд на проект всегда полезен, правда это совсем не значит что следует отдавать проект в руки приглашённых специалистов. Работа экспертов определить проблемные места и предложить способы решения. Если в команде нет специалистов, способных оценить предложения и в случае их разумности реализовать на практике нужно либо отдавать часть работ на аутсортинг, либо менять состав команды.
Обращение к экспертам применимо не на стадии реализации проекта, а на стадии его обсуждения — задача эксперта (экспертов) определить возможность реализации, условия реализации, способы реализации и примерные результаты реализации
Приглашение экспертов на стадии реализации — это свидетельство провала
Что-то из разряда: как подружить хоббита, эльфа и гнома — нужен Гэндальф. Всегда нужен Гэндальф!
Заглянув в даташит микроконтроллера, мы обнаружили, что время пробуждения микроконтроллера зависит от множества факторов и это существенно сказывалось на точности измерений.

Программист знал, что время пробуждения сравнимо со временем нахождения клапана в открытом состоянии, однако он рассчитывал, что оно приведёт лишь к равномерному смещению момента запуска/останова таймера относительно входного сигнала.

То, что программист некомпетентен (что, в принципе, несложно угадать после слов про sleep mode и interrupt pin), это полбеды. Но вы даже не попробовали провести тривиальные тесты на стыке областей, которых нужно было ровно два:


  • Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.
  • Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.

Это даже не проблема проект-менеджера, это проблема элементарного взаимодействия между работниками.

Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.

Были скачки фронтов, но такое исследование проводилось когда команда была сильно разобщена. Схемотехник говорил, что клапан даёт нестабильный/некачественный сигнал, конструктор говорил, что так-то оно так, но надо бы обрабатывать и такой сигнал тоже. Схемотехник понимал, что для этого будут нужны компараторы, а почему он их не хотел, я уже писал в статье. В общем ему было проще наехать на конструктора и сказать, чтобы он чинил клапан. Потом пришли мы, показали, что компаратор можно и проблема отвалилась.
Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.

В течение получаса в среднем мы в любом случае получим нормальные показания для меандра. А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит. Мы могли запилить свой генератор и провести тестирование, но заказчику больше понравился вариант с человеком-оркестром, который в короткий срок проанализировал проект, показал где косяки и как их исправить.
Кстати упустил момент в статье, программист также считал, что смещение допустимо, даже если вносит погрешность. Когда-нибудь всё равно усреднится и всё будет норм. Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работает
А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит.

Стесняюсь спросить, вы где такие генераторы нашли? У одного из самых дешевых аналоговых генераторов асимметрия меандра менее 2%. У генератора фиксированной частоты, собранного за десять минут на коленке из любой атмеги и кварца, она определяется кварцем и фронтами выходов — это заведомо менее 0,1%.


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

Мало того, что вы себе противоречите, так оказывается программист без задней мысли среднюю температуру по больнице измерял. "Чиновники едят мясо, я — капусту, в среднем мы едим голубцы."

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

Руководству нужно задать себе вопрос: почему люди не хотят работать в команде, не болеют за результат и перекладывают ответственность на другого.
Может стоит для начала собрать коллектив и устроить пикник-тимбилдинг? Или может проблема в низкой оплате труда и мотивации, из-за которой люди ходят на работу, чтобы отсидеть 8 часов и уйти домой?
Все это хорошо, вот только в старом варианте была гальваническая развязка, а в новом она отсуствует. Насколько я понимаю, оптроны были использованы именно для этих целей, иначе можно было бы ограничиться обычными транзисторами. Для промышленных приборов гальваническая развязка требуется практически всегда, чтобы гарантированно избавиться от наводок, которые могут приводить к периодическому ресету процессора или, вообще, к его странному поведению. Причем ловить такие проблемы достаточно тяжело, они будут рандомно проявляться только в каком-нибудь цеху, где технологические процессы достаточно мощные; при этом на столе у разработчика все будет отлично работать.
Нет, развязка была связана с особенностями сигнала (отрицательное напряжение), этот момент обошли оптроном. Во второй схеме этот же момент решается смещением. Девайс прошёл все испытания и используется. Жалоб на наводки и подобные странности пока не поступало.
Отличная история, спасибо!
Склоняюсь к варианту с неправильным управлением группой специалистов. Плюс в данной ситуации руководителю этого проекта просто необходимы знания из всех областей, чтобы продуктивно общаться со всеми спецами (а не просто «на завтра и все зеленое») и видеть нестыковки.
По факту не было адекватной обратной связи / анализа «что не так», как результат — не было адекватного решения «что исправить», как результат — проблема висела и висела…
В этой ситуации очень полезно иметь под рукой человека, разбирающегося во всех областях, связанных с проектом
На сколько понимаю, это должен быть руководитель проекта. Не вдаваясь в детали, видеть общую картину и координировать действия, и, естественно, должен быть компетентным в нужных областях.
Но чаще бывает, что руководители могут только требовать…
Очень часто на практике руководитель проекта является всего лишь администратором и никуда от этого не уйти.

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

Если он не самодур, то он даже будучи совсем не компетентным сумеет нормально руководить.
Совсем некомпетентный вряд ли, он просто не сможет вывести специалистов на дискуссию о проблемных местах, так как они будут в полной уверенности, что проблем нет и каждый знает своё дело (о чём и сообщат), а проблемы вылезут уже после реализации.

Единственное, талантливый руководитель, подозревая это, может пригласить стороннего эксперта для взгляда со стороны, тут да.
Конечно же обрабатывать такой сигнал непосредственно микроконтроллером не представляется возможным

Пока Вы не нанесли на график тарировку шкал по времени и по напряжению, данное утверждение не вполне очевидно.
По осциллограмме схемотехник не мог увидеть, что крутизна ключевых фронтов A и B будет недостаточной, чтобы обеспечить стабильное и своевременное срабатывание оптронов. По факту, для корректной работы схемы преобразования было необходимо использование компараторов
То есть Вы всерьез полагаете, что на заваленных фронтах компаратор предпочтительнее оптрона? Из чего вытекает такая уверенность? Ну и по поводу первой схемы с оптронами — помеху надо ловить в точке возникновения, а не после преобразования.
С компаратором мы можем точно задать на каком уровне напряжения будет запущен таймер. Для оптрона это не так, он откроется когда откроется. Можно сказать, что скорее всего он будет открываться на одном и том же напряжении, но это не совсем так. Компаратор однозначно лучше с точки зрения повторяемости. К тому же, на первой схеме стоял стабилитрон, который задирал уровень открытия. Он там играл страховочную роль, чтобы избежать ошибочного срабатывания, вызывающего переворачивание выходного сигнала со смещением (из-за дополнительных всплесков после открытия/закрытия). Так вот, во второй схеме задирать уровень не обязательно, т.к. микроконтроллер сам управляет выходным сигналом. Был разработан функционал программной самодиагностики, восстанавливающий работоспособность схемы в случае ошибки. Отсутствие стабилитрона очень важно, т.к. чем выше уровень — тем более пологий фронт, тем больше погрешность.
Совершенно не понимаю почему нельзя поставить компаратор после оптрона — это решит все проблемы, в том числе и главную — с гальваноразвязкой.
Оптроны внесут свою погрешность, в таком случае применение компараторов не будет иметь смысла, проще напрямую за оптрон зацепиться тогда
Ну и внешний триггер (для формирования выхода из сна?) это классно, Что Я Не Так Делаю, если обычно обхожусь без него?
Он не для формирования выхода из сна. В статье указано, что он формирует ворота, управляющие таймером. Триггер позволяет остановить/запустить таймер не пробуждая микроконтроллер. Это позволило значительно снизить погрешность измерений.
Инженеров-программистов в институте не зря обучают как курсу метрологии, так и основам цифровой схемотехники. Образование (или опыт работы) иногда бывает полезно.
Спасибо, хорошая статья и очень показательный пример, иллюстрирующий басню «Лебедь, рак и щука». :)
Наблюдал это в жизни множество раз, с «вариациями на тему».

P.S. Кто я — благодаря Вам, я уже понял. Осталось найти, куда бы на гастроли податься. Всем составом оркестра… ;) :)))
Проблема, описанная в статье имеет место быть, но есть один существенный нюанс на который наши «оптимизаторы» не обратили ни малейшего внимания…
В исходной схеме была гальваноразвязка, в итоговой мало того что она исчезла, так ещё и полностью отсутствуют элементы защиты входной цепи. Возможно в данном проекте всё обошлось, но так бывает далеко не всегда и рано или наплевательский подход к цепям защиты приведёт к плачевным результатам. Так работать в серьёзных проектах, которые связаны с промышленной автоматизацией, НЕЛЬЗЯ.
Повторюсь, оптроны ставились не ради гальванической развязки, это был хак. Первичный генератор сигнала устроен так, что гальваническая развязка там не нужна. Втыкать развязку повсеместно «на всякий случай» и в ущерб метрологическим характеристикам не вижу смысла.
В статье делался упор на тот факт, что вообще неизвестно как устроен первичный генератор и что он на самом деле выдаёт без длительных исследований не понять. Соединять в таких случаях микроконтроллер с источником входного сигнала не предусмотрев защитных цепей это чистой воды авантюризм, который в большинстве случаев кончается очень печально. Печально, потому что сюрпризы начинаются уже в серийном изделии, а отзыв партии установленных устройств в ремонт по своим последствиям гораздо серьёзнее, чем затягивание сроков разработки.
Возможно я не точно выразился. Мы знали как устроен источник сигнала, знали, что генератор сигнала изолирован от трубопровода и клапана.
В статье я хотел сказать, что было очень сложно диагностировать дефекты в клапане. Для этого приходилось полностью снимать характеристики в различных условиях, отслеживать изменение характеристик по мере износа клапана и т.д.
Чтобы разобраться с клапаном, мы сначала довели до ума всё остальное.
Хорошо. Вы действительно нашли очень интересное программно-аппаратное решение задачи.
Я тоже уточню. Я не настаиваю на необходимости гальваноразвязки, она нужна далеко не всегда. Но это не отменяет необходимости защиты входных цепей. Вполне вероятно в вашем случае вполне достаточно супрессора — стоит копейки, но вкупе с сопротивлением способен надёжно защитить цепи от коротких выбросов непонятного происхождения и статики. В исходной схеме в качестве этой задачи служили оптроны, у вас никакой защиты просто нет. Это плохо.
Посмотрите на свою схему — у вас высокоомный вход компаратора напрямую для импульсных сигналов подключен к источнику сигнала! Более того, входной делитель явно высокоомный. Если вас не смущает данная ситуация это очень печально и говорит о многом.
Да, все верно, если подать мощный импульсный сигнал, компаратор погибнет вместе с микроконтроллером. Мы вполне понимали это, когда ваяли схему.
Не «мощный импульс», а импульс обусловленный накопившимся статическим электричеством либо обусловленный помехами проникающими извне, как пример по электросетям. Если бы вы это понимали, то добавили бы в схему как минимум одно сопротивление и подходящий по параметрам супрессор.
Скорее всего на финальной версии схемы так все и сделано. Проекту 3 года, я точно не помню. Схемы, приведенные в иллюстрациях, рисовались в Proteus ради симуляции, они специально упрощались, чтобы не нагружать процессор
Ещё генератор сигнала позже усилили, он стал давать более мощный сигнал, излишки забирали стабилитронами и заряжали ими ионистор. Это был дополнительный источник питания, который неплохо так прокачал автономность расходомера
Про подобное «разделение труда» есть хороший анекдот. На фабрике по производству карандашей начальник грифельного цеха обратил внимание на то, что никто не использует грифель до конца, потому что в какой-то момент карандаш становится слишком коротким и его невозможно дальше использовать. Он распорядился делать грифель короче на 4 см, чтобы не тратить зря драгоценный графит. А через какое-то время начальник цеха, где делают деревянные оправы, обратил внимание на то, что грифели стали на 4 см короче, и распорядился делать оправы тоже на 4 см короче, чтобы не тратить зря драгоценную древесину.
А еще через какое то время на эту ситуяцию обратил внимание маркетолог — и запустил рекламу что укороченные на 20% карандаши удобнее лежат в руке и меньше ломаются. Продажи немножко подросли правда никто точно не уверен почему — то ли из за «сообразительности» маркетолога то ли из за первого сентября =)
Так все это к сожалению и происходит в реальности.
Мне показалась что ваше статья написана в стиле детектив. Читателю было бы самому приятно разобраться во всем этом, ещё до ваших обяснений. Для этого на ваших диаграммах не плохо иметь указания единиц измерения и единичные отрезки.
Sign up to leave a comment.