А Вы не пробовали знаки препинания расставлять когда задание пишете? «Но для кратных трём значений «Fizz» вместо номера...» пять минут потратил чтобы понять, что же здесь хотят)
Архитектуру взаимодействия проектировали не мы. К моменту старта разработки Android-клиента уже был реализован web-клиент. Поэтому пришлось реализовывать такое решение.
Полностью согласен с одним из комментаторов. Вы удивитесь, но многие даже не слышали о том, что есть такая методология. Полноценно набирать популярность в бизнесе они начинают сейчас.
Вы пишете правильные вещи, я согласен. Но конкретно в нашем случае мы решаем эти проблемы следующим образом:
1) начало спринта. задач в тестировании нет, автотестер занимается тем, что вкручивает дополнительные фичи в проект (как пример, Allure отчеты, реализация паралелизации тестов в GRID и так далее). Либо же оптимизация кода, рефакторинг. В общем есть чем заняться.
2) конец спринта. задачи все в тестировании, либо закрыты, на разработке задач не осталось. Разработчики занимаются тем же самым. Оптимизация кода, рефакторинг, внедрение дополнительно функционала, не так ценного для бизнеса, но очень ценного технически.
3) На мой взгляд все подобные проблемы решаются грамотным планированием, пониманием, что такое Agile и правильно построенными коммуникациями.
Ещё генератор сигнала позже усилили, он стал давать более мощный сигнал, излишки забирали стабилитронами и заряжали ими ионистор. Это был дополнительный источник питания, который неплохо так прокачал автономность расходомера
Скорее всего на финальной версии схемы так все и сделано. Проекту 3 года, я точно не помню. Схемы, приведенные в иллюстрациях, рисовались в Proteus ради симуляции, они специально упрощались, чтобы не нагружать процессор
Возможно я не точно выразился. Мы знали как устроен источник сигнала, знали, что генератор сигнала изолирован от трубопровода и клапана.
В статье я хотел сказать, что было очень сложно диагностировать дефекты в клапане. Для этого приходилось полностью снимать характеристики в различных условиях, отслеживать изменение характеристик по мере износа клапана и т.д.
Чтобы разобраться с клапаном, мы сначала довели до ума всё остальное.
Повторюсь, оптроны ставились не ради гальванической развязки, это был хак. Первичный генератор сигнала устроен так, что гальваническая развязка там не нужна. Втыкать развязку повсеместно «на всякий случай» и в ущерб метрологическим характеристикам не вижу смысла.
Он не для формирования выхода из сна. В статье указано, что он формирует ворота, управляющие таймером. Триггер позволяет остановить/запустить таймер не пробуждая микроконтроллер. Это позволило значительно снизить погрешность измерений.
С компаратором мы можем точно задать на каком уровне напряжения будет запущен таймер. Для оптрона это не так, он откроется когда откроется. Можно сказать, что скорее всего он будет открываться на одном и том же напряжении, но это не совсем так. Компаратор однозначно лучше с точки зрения повторяемости. К тому же, на первой схеме стоял стабилитрон, который задирал уровень открытия. Он там играл страховочную роль, чтобы избежать ошибочного срабатывания, вызывающего переворачивание выходного сигнала со смещением (из-за дополнительных всплесков после открытия/закрытия). Так вот, во второй схеме задирать уровень не обязательно, т.к. микроконтроллер сам управляет выходным сигналом. Был разработан функционал программной самодиагностики, восстанавливающий работоспособность схемы в случае ошибки. Отсутствие стабилитрона очень важно, т.к. чем выше уровень — тем более пологий фронт, тем больше погрешность.
Нет, развязка была связана с особенностями сигнала (отрицательное напряжение), этот момент обошли оптроном. Во второй схеме этот же момент решается смещением. Девайс прошёл все испытания и используется. Жалоб на наводки и подобные странности пока не поступало.
Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.
Были скачки фронтов, но такое исследование проводилось когда команда была сильно разобщена. Схемотехник говорил, что клапан даёт нестабильный/некачественный сигнал, конструктор говорил, что так-то оно так, но надо бы обрабатывать и такой сигнал тоже. Схемотехник понимал, что для этого будут нужны компараторы, а почему он их не хотел, я уже писал в статье. В общем ему было проще наехать на конструктора и сказать, чтобы он чинил клапан. Потом пришли мы, показали, что компаратор можно и проблема отвалилась.
Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра. А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит. Мы могли запилить свой генератор и провести тестирование, но заказчику больше понравился вариант с человеком-оркестром, который в короткий срок проанализировал проект, показал где косяки и как их исправить.
Кстати упустил момент в статье, программист также считал, что смещение допустимо, даже если вносит погрешность. Когда-нибудь всё равно усреднится и всё будет норм. Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работает
Это не всегда так. В частности в этом проекте ключевой фигурой был инженер-конструктор. Именно он придумал расходомер и принимал ключевые решения. Программист и схемотехник играли роль помощников, которые должны были добавить к устройству мозги, преобразующие показания клапана в осмысленные числа. Почему так сложилось, что проектом руководит человек, ничего не понимающий в программировании — тема отдельного разговора.
В сложившейся ситуации человек-оркестр не брал руководство на себя, он лишь решил возникшие проблемы в реализации и коммуникации внутри проекта. Проектом продолжал руководить инженер-конструктор.
Программист рассуждал довольно просто. Микроконтроллер всегда просыпается в равных условиях. Т.е. запускает один и тот же осциллятор, включает одну и ту же периферию, так что и задержка должна быть равномерной. К тому же, просмотрев даташит, программист увидел, что задержка довольно таки небольшая. Он не рассчитывал, что она внесёт столь ощутимый вклад, чтобы обсуждать этот вопрос с метрологом. Всё-таки чтобы понимать что важно с точки зрения метрологии, а на что можно забить, нужно иметь какое-то представление о погрешностях и как их правильно считать.
P.S. информацию по этой теме также можно почитать на хабре.
1) начало спринта. задач в тестировании нет, автотестер занимается тем, что вкручивает дополнительные фичи в проект (как пример, Allure отчеты, реализация паралелизации тестов в GRID и так далее). Либо же оптимизация кода, рефакторинг. В общем есть чем заняться.
2) конец спринта. задачи все в тестировании, либо закрыты, на разработке задач не осталось. Разработчики занимаются тем же самым. Оптимизация кода, рефакторинг, внедрение дополнительно функционала, не так ценного для бизнеса, но очень ценного технически.
3) На мой взгляд все подобные проблемы решаются грамотным планированием, пониманием, что такое Agile и правильно построенными коммуникациями.
В статье я хотел сказать, что было очень сложно диагностировать дефекты в клапане. Для этого приходилось полностью снимать характеристики в различных условиях, отслеживать изменение характеристик по мере износа клапана и т.д.
Чтобы разобраться с клапаном, мы сначала довели до ума всё остальное.
Были скачки фронтов, но такое исследование проводилось когда команда была сильно разобщена. Схемотехник говорил, что клапан даёт нестабильный/некачественный сигнал, конструктор говорил, что так-то оно так, но надо бы обрабатывать и такой сигнал тоже. Схемотехник понимал, что для этого будут нужны компараторы, а почему он их не хотел, я уже писал в статье. В общем ему было проще наехать на конструктора и сказать, чтобы он чинил клапан. Потом пришли мы, показали, что компаратор можно и проблема отвалилась.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра. А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит. Мы могли запилить свой генератор и провести тестирование, но заказчику больше понравился вариант с человеком-оркестром, который в короткий срок проанализировал проект, показал где косяки и как их исправить.
Кстати упустил момент в статье, программист также считал, что смещение допустимо, даже если вносит погрешность. Когда-нибудь всё равно усреднится и всё будет норм. Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работает
В сложившейся ситуации человек-оркестр не брал руководство на себя, он лишь решил возникшие проблемы в реализации и коммуникации внутри проекта. Проектом продолжал руководить инженер-конструктор.