Comments 44
Проблема была в том, что участники проекта мало обсуждали друг с другом проблемы на стыке областей. Скажем, инженер мог бы вместе со схемотехником подумать об улучшении конструкции датчика, а схемотехник с программистом — о рациональном использовании периферии микроконтроллера.
Спасибо)
А руководитель по принципу — чтобы было завтра и главное покрасить зеленым — ожидаемо проваливает проект
В сложившейся ситуации человек-оркестр не брал руководство на себя, он лишь решил возникшие проблемы в реализации и коммуникации внутри проекта. Проектом продолжал руководить инженер-конструктор.
Описанное в статье счастливое решение проблемы за счет компетентности третьей стороны
Приглашение экспертов на стадии реализации — это свидетельство провала
Заглянув в даташит микроконтроллера, мы обнаружили, что время пробуждения микроконтроллера зависит от множества факторов и это существенно сказывалось на точности измерений.
Программист знал, что время пробуждения сравнимо со временем нахождения клапана в открытом состоянии, однако он рассчитывал, что оно приведёт лишь к равномерному смещению момента запуска/останова таймера относительно входного сигнала.
То, что программист некомпетентен (что, в принципе, несложно угадать после слов про sleep mode и interrupt pin), это полбеды. Но вы даже не попробовали провести тривиальные тесты на стыке областей, которых нужно было ровно два:
- Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.
- Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.
Это даже не проблема проект-менеджера, это проблема элементарного взаимодействия между работниками.
Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.
Были скачки фронтов, но такое исследование проводилось когда команда была сильно разобщена. Схемотехник говорил, что клапан даёт нестабильный/некачественный сигнал, конструктор говорил, что так-то оно так, но надо бы обрабатывать и такой сигнал тоже. Схемотехник понимал, что для этого будут нужны компараторы, а почему он их не хотел, я уже писал в статье. В общем ему было проще наехать на конструктора и сказать, чтобы он чинил клапан. Потом пришли мы, показали, что компаратор можно и проблема отвалилась.
Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра. А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит. Мы могли запилить свой генератор и провести тестирование, но заказчику больше понравился вариант с человеком-оркестром, который в короткий срок проанализировал проект, показал где косяки и как их исправить.
Кстати упустил момент в статье, программист также считал, что смещение допустимо, даже если вносит погрешность. Когда-нибудь всё равно усреднится и всё будет норм. Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работает
А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит.
Стесняюсь спросить, вы где такие генераторы нашли? У одного из самых дешевых аналоговых генераторов асимметрия меандра менее 2%. У генератора фиксированной частоты, собранного за десять минут на коленке из любой атмеги и кварца, она определяется кварцем и фронтами выходов — это заведомо менее 0,1%.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра.
Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работает
Мало того, что вы себе противоречите, так оказывается программист без задней мысли среднюю температуру по больнице измерял. "Чиновники едят мясо, я — капусту, в среднем мы едим голубцы."
Руководству нужно задать себе вопрос: почему люди не хотят работать в команде, не болеют за результат и перекладывают ответственность на другого.
Может стоит для начала собрать коллектив и устроить пикник-тимбилдинг? Или может проблема в низкой оплате труда и мотивации, из-за которой люди ходят на работу, чтобы отсидеть 8 часов и уйти домой?
Склоняюсь к варианту с неправильным управлением группой специалистов. Плюс в данной ситуации руководителю этого проекта просто необходимы знания из всех областей, чтобы продуктивно общаться со всеми спецами (а не просто «на завтра и все зеленое») и видеть нестыковки.
По факту не было адекватной обратной связи / анализа «что не так», как результат — не было адекватного решения «что исправить», как результат — проблема висела и висела…
В этой ситуации очень полезно иметь под рукой человека, разбирающегося во всех областях, связанных с проектомНа сколько понимаю, это должен быть руководитель проекта. Не вдаваясь в детали, видеть общую картину и координировать действия, и, естественно, должен быть компетентным в нужных областях.
Но чаще бывает, что руководители могут только требовать…
Если он не самодур, то он даже будучи совсем не компетентным сумеет нормально руководить. Руководителю, конечно, полезно знать техническую сторону вопроса, но не жизненно важно. Чтобы получить от одного специалиста ответ, который будет понятен другому специалисту, начальник должен вызвать их обоих к себе и правильно сформулировать вопросы.
Если он не самодур, то он даже будучи совсем не компетентным сумеет нормально руководить.Совсем некомпетентный вряд ли, он просто не сможет вывести специалистов на дискуссию о проблемных местах, так как они будут в полной уверенности, что проблем нет и каждый знает своё дело (о чём и сообщат), а проблемы вылезут уже после реализации.
Единственное, талантливый руководитель, подозревая это, может пригласить стороннего эксперта для взгляда со стороны, тут да.
Конечно же обрабатывать такой сигнал непосредственно микроконтроллером не представляется возможным
Пока Вы не нанесли на график тарировку шкал по времени и по напряжению, данное утверждение не вполне очевидно.
По осциллограмме схемотехник не мог увидеть, что крутизна ключевых фронтов A и B будет недостаточной, чтобы обеспечить стабильное и своевременное срабатывание оптронов. По факту, для корректной работы схемы преобразования было необходимо использование компараторовТо есть Вы всерьез полагаете, что на заваленных фронтах компаратор предпочтительнее оптрона? Из чего вытекает такая уверенность? Ну и по поводу первой схемы с оптронами — помеху надо ловить в точке возникновения, а не после преобразования.
Наблюдал это в жизни множество раз, с «вариациями на тему».
P.S. Кто я — благодаря Вам, я уже понял. Осталось найти, куда бы на гастроли податься. Всем составом оркестра… ;) :)))
В исходной схеме была гальваноразвязка, в итоговой мало того что она исчезла, так ещё и полностью отсутствуют элементы защиты входной цепи. Возможно в данном проекте всё обошлось, но так бывает далеко не всегда и рано или наплевательский подход к цепям защиты приведёт к плачевным результатам. Так работать в серьёзных проектах, которые связаны с промышленной автоматизацией, НЕЛЬЗЯ.
В статье я хотел сказать, что было очень сложно диагностировать дефекты в клапане. Для этого приходилось полностью снимать характеристики в различных условиях, отслеживать изменение характеристик по мере износа клапана и т.д.
Чтобы разобраться с клапаном, мы сначала довели до ума всё остальное.
Я тоже уточню. Я не настаиваю на необходимости гальваноразвязки, она нужна далеко не всегда. Но это не отменяет необходимости защиты входных цепей. Вполне вероятно в вашем случае вполне достаточно супрессора — стоит копейки, но вкупе с сопротивлением способен надёжно защитить цепи от коротких выбросов непонятного происхождения и статики. В исходной схеме в качестве этой задачи служили оптроны, у вас никакой защиты просто нет. Это плохо.
Посмотрите на свою схему — у вас высокоомный вход компаратора напрямую для
Так все это к сожалению и происходит в реальности.
Про разделение труда и его последствия