В разработке счётчика газа принимало участие трое специалистов (по факту больше, но в рамках статьи нас интересуют лишь три компетенции). Это были:
- Инженер-конструктор, по совместительству специалист по метрологии
- Схемотехник
- Программист
Конструктор предоставил устройство, выдающее сигнал открытия и закрытия специального клапана. Выглядел он примерно так:
Требовалось измерить время нахождения клапана в открытом состоянии (расстояние от A до B), и частоту открывания клапана.
Конечно же обрабатывать такой сигнал непосредственно микроконтроллером не представляется возможным, так что перед схемотехником была поставлена задача по разработке промежуточного преобразователя, формирующего следующий сигнал:
Устройство будет работать от батареи, так что большую часть времени микроконтроллер будет находиться в Sleep Mode. Поэтому программист попросил завести сигнал на Interrupt pin, настроил пробуждение микроконтроллера по прерыванию от соответствующего порта и в обработчике прерывания выполнял запуск/останов таймера.
Всё пока выглядит хорошо, каждый специалист выполнял свою работу и делал её качественно. Только вот качество работы устройства в целом мало кого устраивало. При постоянном расходе, устройство выдавало показания со значительным разбросом и было совершенно не ясно в чём причина.
Почему так получилось?
Некорректную работу расходомера обнаружили на раннем этапе разработки. Такие ошибки случаются и в этом нет ничего страшного. Страшно другое, никто не знал где ошибка и как её найти.
Причинами недостаточной точности расходомера могли служить:
- Ошибки в конструкции клапана и генератора входного сигнала
- Ошибки в схеме преобразования входного сигнала
- Ошибки в программном обеспечении
К тому же, разработчики не имели полной уверенности в том, что проблема имеет место в принципе, ведь характеристики расходомера определялись с помощью эталонного стенда, который разрабатывался параллельно с расходомером и тоже был далёк от идеала.
В итоге рано или поздно мы получаем ситуацию, когда каждый участник команды, будучи уверенным в безупречности результатов своей работы, крошит батон на соседа. Тогда как вышестоящее руководство воспринимает проект целиком и недовольно всей командой. В команде зарождаются конфликты, громкие споры, разобщение. Конструктор заявляет, что ошибка в программе, программист говорит, что ошибка в конструкции клапана и т.д.
Что делать?
Разработка расходомера значительно усложнилась и заказчик принял решение привлечь новых специалистов. Так что мы принялись за работу.
Мы видели два пути решения проблемы:
- Тотальное тестирование и приёмка работы каждого члена команды
- Человек-оркестр
Первый вариант выглядит довольно таки стандартно и очень популярен в сфере разработки ПО. Например, чтобы проверить программную часть, мы покупаем или разрабатываем прецизионный генератор сигнала, формируемого на выходе преобразователя, подаём его на микроконтроллер и сравниваем его показания в различных условиях с показаниями генератора. Решение не самое дешёвое и, иногда, далеко не самое быстрое, но вполне рабочее.
Работоспособность и качество преобразователя входного сигнала также можно оценить с помощью хорошего и корректно настроенного осциллографа. Либо разработать специальное устройство для анализа преобразования.
А вот с проверкой работы клапана всё намного сложнее, нужно подать фиксированный расход, провести преобразование сигнала клапана и измерять сигнал с помощью специализированного частотомера. По факту это мало чем отличается от того расходомера, который у нас уже был.
К сожалению, наш заказчик не был готов идти таким путём, ему нужно было более изящное решение, тем более, что не удалось разработать удачный алгоритм проверки клапана и генератора сигнала.
Поэтому заказчику был предоставлен сотрудник, имеющий компетенцию как в схемотехнике, так и в программировании с метрологией. Его задачей было проанализировать ситуацию в целом и избавить команду от возможности валить вину друг на друга.
Заглянем под капот. И вот наш человек-оркестр приступил к анализу проекта. Анализ начался с преобразователя входного сигнала:
Оригинал схемы не сохранился, но суть её можно уловить по картинке. Как видно, схема построена на триггере (4013) и оптронах. Ложные срабатывания устранены с помощью стабилитрона D1 и RC-цепочек.
Схема вполне неплохо преобразует входной сигнал от клапана. Но при её построении схемотехник не учитывал конечную цель и специфику сигнала.
Суть проблемы была в том, что при постановке задачи схемотехнику, ему была предоставлена осцилограмма входного сигнала и ожидаемый вид выходного. По осциллограмме схемотехник не мог увидеть, что крутизна ключевых фронтов A и B будет недостаточной, чтобы обеспечить стабильное и своевременное срабатывание оптронов. По факту, для корректной работы схемы преобразования было необходимо использование компараторов. Схемотехника такое решение не очень устраивало, т.к. компараторы усложнят схему и наверняка дадут большее потребление. Во многом такое опасение связано с привычкой решать поставленные задачи исключительно схемотехнически, не кооперируясь с программистом и не используя возможностей микроконтроллера.
С программой тоже не всё было гладко. С одной стороны, если микроконтроллер всё время бодрствует, он получает прерывания и мгновенно запускает/останавливает таймер. Однако стоило включить энергосберегающий режим, как начиналось странное. Заглянув в даташит микроконтроллера, мы обнаружили, что время пробуждения микроконтроллера зависит от множества факторов и это существенно сказывалось на точности измерений. Запуск и останов таймера значительно отставал от входного сигнала. Программист знал, что время пробуждения сравнимо со временем нахождения клапана в открытом состоянии, однако он рассчитывал, что оно приведёт лишь к равномерному смещению момента запуска/останова таймера относительно входного сигнала. По факту же мы получили значительный разброс в показаниях энергосберегающего и бодрствующего микроконтроллеров. Для метролога эта проблема была бы очевидной, но он не участвовал в разработке ПО, т.к. не имел такой экспертизы.
Анализ работы клапана провести не удалось. Испытать клапан и оценить его работу без преобразования и измерения его сигнала было сложно или невозможно. Мы решили разобраться с проблемами в преобразователе и программе, получить измерительно-вычислительный блок, который не будет вызывать у нас сомнений и провести испытания клапана с помощью полученного блока.
Человек-оркестр
Разобравшись в проекте в целом, мы приступили к решению очевидных проблем. Проще всего было решить программную проблему — запуск и останов таймера. На применявшемся нами микроконтроллере имелся Gate-controlled timer, который мог запускаться и останавливаться аппаратно, до пробуждения микроконтроллера и, если потребуется, даже без его пробуждения. Если бы программист интересовался метрологией, он бы и сам давно нашёл такое решение и постарался его реализовать. Но зачастую программистов интересует лишь программирование. К тому же было ещё два фактора, значительно повлиявших на принятие неудачных решений программистом:
- Программист не работал в режиме активного энергосбережения. Он просто не сталкивался с проблемой медленного пробуждения микроконтроллера и эффектами, проявляющимися в связи с этим
- Программист уже работал c Gate-controlled таймером и столкнулся с тем, что он просто не работает. Так что на всех последующих проектах он избегал этой функции и боялся её как огня. Как оказалось, не все программисты читают Errata и отслеживают ревизии микроконтроллеров. На ранних ревизиях микроконтроллера эта функция действительно не работала.
Попутно мы затронули точность преобразования входного сигнала. Для нас была очевидна необходимость перехода от оптронов к компараторам. Заказчика беспокоила проблема повышения потребления, он уже слышал об этом от своего схемотехника. Схемотехник отлично разбирался в своей предметной области, но даже не задумывался о функционале применяемого на проекте микроконтроллера. Мало того, что микроконтроллер уже содержал в себе два компаратора, так ещё оказалось, что нам вполне хватит одного из них, мы просто будем коммутировать нижний и верхний уровни опорного напряжения программно, без применения дополнительных внешних коммутаторов. Учитывая, что низкое энергопотребление было одним из ключевых преимуществ применяемого нами микроконтроллера, компаратор обошёлся нам очень дёшево (около 8 мкА). А высокое входное сопротивление компаратора позволило сделать достаточно недорогой по потреблению набор опорных напряжений (не более 10 мкА). В итоге имеем довольно таки простую схему обработки входного сигнала:
Т.к. От клапана приходит сигнал как положительный, так и отрицательный, мы смещаем его с помощью резисторов R1 и R2. Делителем R3-R5 мы задаём опорные напряжения. По мере снижения напряжения на батарее опорные напряжения и смещение на R1 и R2 будут понижаться синхронно, так что на точности преобразования сигнала это скажется незначительно.
Чтобы запускать и останавливать таймер за счёт применения технологии gate-control, наш микроконтроллер формирует сигналы открытия и закрытия ворот с помощью компаратора на аппаратном уровне без выхода из sleep mode. RC цепочки упразднены, так как мы можем программно управлять воротами с помощью порта RA5 микроконтроллера. Выход компаратора соединён с CLK входом триггера. Опорное напряжение компаратора комутируется программно (подключается либо C12IN0-, либо C12IN1-, в зависимости от того, ожидаем мы открытия или закрытия клапана).
Что в итоге?
Разработав свою схему преобразования сигнала и свою прошивку микроконтроллера, мы значительно повысили точность измерения расхода газа. Также мы помогли конструктору расходомера. Теперь он легко мог заметить огрехи в работе клапана и генератора сигнала, и ему не приходилось думать, что проблема не на его стороне. Даже если у него возникали вопросы, ему было с кем их обсудить, т.к. мы всегда могли описать алгоритм преобразования и измерения сигнала с точки зрения метрологии и, при необходимости, откорректировать что-то.
Разделение задач по компетенциям позволяет членам команды достигать очень высокого уровня развития в своих областях, но рано или поздно мы приходим к тому, что специалисты перестают понимать друг друга. В этой ситуации очень полезно иметь под рукой человека, разбирающегося во всех областях, связанных с проектом. Может не так хорошо, как какждый специалист в отдельности, но способный видеть картину в целом. Также опыт этого проекта показал, что такой специалист очень положительно влияет на взаимодействие специалистов, культивирует интерес инженеров к работе друг с другом. Программист и схемотехник стали чаще думать о погрешности измерений, схемотехник открыл для себя новые возможности использования периферии микроконтроллера, конструктор-метролог начал доверять своим коллегам и активно использовать результаты их работы для анализа аппаратной части.
Также хотелось бы обратить внимание на то, что имея поверхностные знания по широкому кругу областей, человек-оркестр на этапе собеседования не выглядит привлекательным как с точки зрения программиста, так и с точки зрения метролога и схемотехника. Но по факту он может сыграть ключевую роль в сложной ситуации.
Комментарии (44)
vlfesko
19.08.2016 11:31+3Получается, что проблема не в самом разделении труда, а в отсутствии конкретного опыта у членов команды, которые, в итоге, прошли тернистый путь в решении определенной задачи и присущих ей проблем. Хотя слабее всего тут выглядит программист, который «рассчитывал, что задержки приведут лишь к равномерному смещению момента». Странно слышать о том, что программист на что-то подобное рассчитывал при работе с устройством, ключевая функция которого зависит от подобных допущений.
SSul
19.08.2016 11:37Программист рассуждал довольно просто. Микроконтроллер всегда просыпается в равных условиях. Т.е. запускает один и тот же осциллятор, включает одну и ту же периферию, так что и задержка должна быть равномерной. К тому же, просмотрев даташит, программист увидел, что задержка довольно таки небольшая. Он не рассчитывал, что она внесёт столь ощутимый вклад, чтобы обсуждать этот вопрос с метрологом. Всё-таки чтобы понимать что важно с точки зрения метрологии, а на что можно забить, нужно иметь какое-то представление о погрешностях и как их правильно считать.
vlfesko
19.08.2016 11:51Да, конечно, особенно если «программист знал, что время пробуждения сравнимо со временем нахождения клапана в открытом состоянии». В таких проектах, где хард и софт должны объединиться в готовое устройство, и эти части не разрабатываются на условном аутсорсе по сухим спецификациям, члены команды с разным профилем обычно проявляют интерес к соседним областям знаний, чтобы поменьше проблем потом вылезло. Да и расширить свой кругозор никогда лишним не бывает.
Спасибо)
sbnur
19.08.2016 11:37+4Роль человека оркестра, точнее дирижера, в каждом проекте должен играть руководитель. Только его компетентность в целом по проекту даст положительный эффект.
А руководитель по принципу — чтобы было завтра и главное покрасить зеленым — ожидаемо проваливает проектSSul
19.08.2016 11:49Это не всегда так. В частности в этом проекте ключевой фигурой был инженер-конструктор. Именно он придумал расходомер и принимал ключевые решения. Программист и схемотехник играли роль помощников, которые должны были добавить к устройству мозги, преобразующие показания клапана в осмысленные числа. Почему так сложилось, что проектом руководит человек, ничего не понимающий в программировании — тема отдельного разговора.
В сложившейся ситуации человек-оркестр не брал руководство на себя, он лишь решил возникшие проблемы в реализации и коммуникации внутри проекта. Проектом продолжал руководить инженер-конструктор.sbnur
19.08.2016 12:40+2А когда не так — обращение к сторонним специалистам говорит о некомпетентности руководства, которое либо не способно подобрать для проекта нужных специалистов, либо скоординировать их работы
Описанное в статье счастливое решение проблемы за счет компетентности третьей стороныSSul
19.08.2016 12:45Всё верно, увидели, что собственной компетентности не хватает — нашли компетентного спеца на стороне, happy end.
progchip666
20.08.2016 11:28Обращение к экспертам на самом деле как раз очень правильная практика, к сожалению крайне редко используемая в России. Её не мешает практиковать даже если в проекте всё с виду хорошо, а уж если появились большие задержки на «ровном» месте тем более. Сторонний взгляд на проект всегда полезен, правда это совсем не значит что следует отдавать проект в руки приглашённых специалистов. Работа экспертов определить проблемные места и предложить способы решения. Если в команде нет специалистов, способных оценить предложения и в случае их разумности реализовать на практике нужно либо отдавать часть работ на аутсортинг, либо менять состав команды.
sbnur
20.08.2016 11:59+2Обращение к экспертам применимо не на стадии реализации проекта, а на стадии его обсуждения — задача эксперта (экспертов) определить возможность реализации, условия реализации, способы реализации и примерные результаты реализации
Приглашение экспертов на стадии реализации — это свидетельство провала
Igreh
19.08.2016 11:45+1Что-то из разряда: как подружить хоббита, эльфа и гнома — нужен Гэндальф. Всегда нужен Гэндальф!
qbertych
19.08.2016 11:47+3Заглянув в даташит микроконтроллера, мы обнаружили, что время пробуждения микроконтроллера зависит от множества факторов и это существенно сказывалось на точности измерений.
Программист знал, что время пробуждения сравнимо со временем нахождения клапана в открытом состоянии, однако он рассчитывал, что оно приведёт лишь к равномерному смещению момента запуска/останова таймера относительно входного сигнала.То, что программист некомпетентен (что, в принципе, несложно угадать после слов про sleep mode и interrupt pin), это полбеды. Но вы даже не попробовали провести тривиальные тесты на стыке областей, которых нужно было ровно два:
- Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.
- Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.
Это даже не проблема проект-менеджера, это проблема элементарного взаимодействия между работниками.
SSul
19.08.2016 12:05Железо-электроника: подать сигнал с обоих на два входа осциллографа; понаблюдать полчаса, не скачут ли фронты.
Были скачки фронтов, но такое исследование проводилось когда команда была сильно разобщена. Схемотехник говорил, что клапан даёт нестабильный/некачественный сигнал, конструктор говорил, что так-то оно так, но надо бы обрабатывать и такой сигнал тоже. Схемотехник понимал, что для этого будут нужны компараторы, а почему он их не хотел, я уже писал в статье. В общем ему было проще наехать на конструктора и сказать, чтобы он чинил клапан. Потом пришли мы, показали, что компаратор можно и проблема отвалилась.
Электроника-софт: подать меандр на пин прерывания, понаблюдать полчаса, не сходит ли контроллер с ума.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра. А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит. Мы могли запилить свой генератор и провести тестирование, но заказчику больше понравился вариант с человеком-оркестром, который в короткий срок проанализировал проект, показал где косяки и как их исправить.
Кстати упустил момент в статье, программист также считал, что смещение допустимо, даже если вносит погрешность. Когда-нибудь всё равно усреднится и всё будет норм. Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работаетqbertych
19.08.2016 13:02+1А то, что значения для каждого импульса отличаются на 2-5% — можно было сказать, что генератор меандра косячит.
Стесняюсь спросить, вы где такие генераторы нашли? У одного из самых дешевых аналоговых генераторов асимметрия меандра менее 2%. У генератора фиксированной частоты, собранного за десять минут на коленке из любой атмеги и кварца, она определяется кварцем и фронтами выходов — это заведомо менее 0,1%.
В течение получаса в среднем мы в любом случае получим нормальные показания для меандра.
Только вот испытания были не столь долгосрочны и ничего не усреднилось, так что заказчик увидел, что расходомер не работаетМало того, что вы себе противоречите, так оказывается программист без задней мысли среднюю температуру по больнице измерял. "Чиновники едят мясо, я — капусту, в среднем мы едим голубцы."
zenkz
19.08.2016 22:04+2Мне кажется тут больше была проблема отсутствия командного духа, а не отсутствия человека-оркестра.
Руководству нужно задать себе вопрос: почему люди не хотят работать в команде, не болеют за результат и перекладывают ответственность на другого.
Может стоит для начала собрать коллектив и устроить пикник-тимбилдинг? Или может проблема в низкой оплате труда и мотивации, из-за которой люди ходят на работу, чтобы отсидеть 8 часов и уйти домой?
eugene_e
19.08.2016 12:33+2Все это хорошо, вот только в старом варианте была гальваническая развязка, а в новом она отсуствует. Насколько я понимаю, оптроны были использованы именно для этих целей, иначе можно было бы ограничиться обычными транзисторами. Для промышленных приборов гальваническая развязка требуется практически всегда, чтобы гарантированно избавиться от наводок, которые могут приводить к периодическому ресету процессора или, вообще, к его странному поведению. Причем ловить такие проблемы достаточно тяжело, они будут рандомно проявляться только в каком-нибудь цеху, где технологические процессы достаточно мощные; при этом на столе у разработчика все будет отлично работать.
SSul
19.08.2016 12:38Нет, развязка была связана с особенностями сигнала (отрицательное напряжение), этот момент обошли оптроном. Во второй схеме этот же момент решается смещением. Девайс прошёл все испытания и используется. Жалоб на наводки и подобные странности пока не поступало.
ogoNEKto
19.08.2016 13:18Отличная история, спасибо!
Склоняюсь к варианту с неправильным управлением группой специалистов. Плюс в данной ситуации руководителю этого проекта просто необходимы знания из всех областей, чтобы продуктивно общаться со всеми спецами (а не просто «на завтра и все зеленое») и видеть нестыковки.
По факту не было адекватной обратной связи / анализа «что не так», как результат — не было адекватного решения «что исправить», как результат — проблема висела и висела…
ploop
19.08.2016 13:30+2В этой ситуации очень полезно иметь под рукой человека, разбирающегося во всех областях, связанных с проектом
На сколько понимаю, это должен быть руководитель проекта. Не вдаваясь в детали, видеть общую картину и координировать действия, и, естественно, должен быть компетентным в нужных областях.
Но чаще бывает, что руководители могут только требовать…progchip666
20.08.2016 11:31+1Очень часто на практике руководитель проекта является всего лишь администратором и никуда от этого не уйти.
Zenitchik
20.08.2016 12:27+1Если он не самодур, то он даже будучи совсем не компетентным сумеет нормально руководить. Руководителю, конечно, полезно знать техническую сторону вопроса, но не жизненно важно. Чтобы получить от одного специалиста ответ, который будет понятен другому специалисту, начальник должен вызвать их обоих к себе и правильно сформулировать вопросы.
ploop
22.08.2016 14:27Если он не самодур, то он даже будучи совсем не компетентным сумеет нормально руководить.
Совсем некомпетентный вряд ли, он просто не сможет вывести специалистов на дискуссию о проблемных местах, так как они будут в полной уверенности, что проблем нет и каждый знает своё дело (о чём и сообщат), а проблемы вылезут уже после реализации.
Единственное, талантливый руководитель, подозревая это, может пригласить стороннего эксперта для взгляда со стороны, тут да.
GarryC
19.08.2016 14:51+2Конечно же обрабатывать такой сигнал непосредственно микроконтроллером не представляется возможным
Пока Вы не нанесли на график тарировку шкал по времени и по напряжению, данное утверждение не вполне очевидно.
GarryC
19.08.2016 14:54+1По осциллограмме схемотехник не мог увидеть, что крутизна ключевых фронтов A и B будет недостаточной, чтобы обеспечить стабильное и своевременное срабатывание оптронов. По факту, для корректной работы схемы преобразования было необходимо использование компараторов
То есть Вы всерьез полагаете, что на заваленных фронтах компаратор предпочтительнее оптрона? Из чего вытекает такая уверенность? Ну и по поводу первой схемы с оптронами — помеху надо ловить в точке возникновения, а не после преобразования.SSul
19.08.2016 15:10С компаратором мы можем точно задать на каком уровне напряжения будет запущен таймер. Для оптрона это не так, он откроется когда откроется. Можно сказать, что скорее всего он будет открываться на одном и том же напряжении, но это не совсем так. Компаратор однозначно лучше с точки зрения повторяемости. К тому же, на первой схеме стоял стабилитрон, который задирал уровень открытия. Он там играл страховочную роль, чтобы избежать ошибочного срабатывания, вызывающего переворачивание выходного сигнала со смещением (из-за дополнительных всплесков после открытия/закрытия). Так вот, во второй схеме задирать уровень не обязательно, т.к. микроконтроллер сам управляет выходным сигналом. Был разработан функционал программной самодиагностики, восстанавливающий работоспособность схемы в случае ошибки. Отсутствие стабилитрона очень важно, т.к. чем выше уровень — тем более пологий фронт, тем больше погрешность.
progchip666
20.08.2016 10:36Совершенно не понимаю почему нельзя поставить компаратор после оптрона — это решит все проблемы, в том числе и главную — с гальваноразвязкой.
SSul
20.08.2016 11:07Оптроны внесут свою погрешность, в таком случае применение компараторов не будет иметь смысла, проще напрямую за оптрон зацепиться тогда
GarryC
19.08.2016 15:00+1Ну и внешний триггер (для формирования выхода из сна?) это классно, Что Я Не Так Делаю, если обычно обхожусь без него?
SSul
19.08.2016 15:13Он не для формирования выхода из сна. В статье указано, что он формирует ворота, управляющие таймером. Триггер позволяет остановить/запустить таймер не пробуждая микроконтроллер. Это позволило значительно снизить погрешность измерений.
vadimr
19.08.2016 17:45Инженеров-программистов в институте не зря обучают как курсу метрологии, так и основам цифровой схемотехники. Образование (или опыт работы) иногда бывает полезно.
sav1812
20.08.2016 09:52+1Спасибо, хорошая статья и очень показательный пример, иллюстрирующий басню «Лебедь, рак и щука». :)
Наблюдал это в жизни множество раз, с «вариациями на тему».
P.S. Кто я — благодаря Вам, я уже понял. Осталось найти, куда бы на гастроли податься. Всем составом оркестра… ;) :)))
progchip666
20.08.2016 10:30Проблема, описанная в статье имеет место быть, но есть один существенный нюанс на который наши «оптимизаторы» не обратили ни малейшего внимания…
В исходной схеме была гальваноразвязка, в итоговой мало того что она исчезла, так ещё и полностью отсутствуют элементы защиты входной цепи. Возможно в данном проекте всё обошлось, но так бывает далеко не всегда и рано или наплевательский подход к цепям защиты приведёт к плачевным результатам. Так работать в серьёзных проектах, которые связаны с промышленной автоматизацией, НЕЛЬЗЯ.SSul
20.08.2016 11:04Повторюсь, оптроны ставились не ради гальванической развязки, это был хак. Первичный генератор сигнала устроен так, что гальваническая развязка там не нужна. Втыкать развязку повсеместно «на всякий случай» и в ущерб метрологическим характеристикам не вижу смысла.
progchip666
20.08.2016 11:36В статье делался упор на тот факт, что вообще неизвестно как устроен первичный генератор и что он на самом деле выдаёт без длительных исследований не понять. Соединять в таких случаях микроконтроллер с источником входного сигнала не предусмотрев защитных цепей это чистой воды авантюризм, который в большинстве случаев кончается очень печально. Печально, потому что сюрпризы начинаются уже в серийном изделии, а отзыв партии установленных устройств в ремонт по своим последствиям гораздо серьёзнее, чем затягивание сроков разработки.
SSul
20.08.2016 11:58Возможно я не точно выразился. Мы знали как устроен источник сигнала, знали, что генератор сигнала изолирован от трубопровода и клапана.
В статье я хотел сказать, что было очень сложно диагностировать дефекты в клапане. Для этого приходилось полностью снимать характеристики в различных условиях, отслеживать изменение характеристик по мере износа клапана и т.д.
Чтобы разобраться с клапаном, мы сначала довели до ума всё остальное.progchip666
20.08.2016 12:52Хорошо. Вы действительно нашли очень интересное программно-аппаратное решение задачи.
Я тоже уточню. Я не настаиваю на необходимости гальваноразвязки, она нужна далеко не всегда. Но это не отменяет необходимости защиты входных цепей. Вполне вероятно в вашем случае вполне достаточно супрессора — стоит копейки, но вкупе с сопротивлением способен надёжно защитить цепи от коротких выбросов непонятного происхождения и статики. В исходной схеме в качестве этой задачи служили оптроны, у вас никакой защиты просто нет. Это плохо.
Посмотрите на свою схему — у вас высокоомный вход компаратора напрямую дляимпульсных сигналовподключен к источнику сигнала! Более того, входной делитель явно высокоомный. Если вас не смущает данная ситуация это очень печально и говорит о многом.SSul
20.08.2016 13:09Да, все верно, если подать мощный импульсный сигнал, компаратор погибнет вместе с микроконтроллером. Мы вполне понимали это, когда ваяли схему.
progchip666
20.08.2016 14:13Не «мощный импульс», а импульс обусловленный накопившимся статическим электричеством либо обусловленный помехами проникающими извне, как пример по электросетям. Если бы вы это понимали, то добавили бы в схему как минимум одно сопротивление и подходящий по параметрам супрессор.
SSul
20.08.2016 14:26Скорее всего на финальной версии схемы так все и сделано. Проекту 3 года, я точно не помню. Схемы, приведенные в иллюстрациях, рисовались в Proteus ради симуляции, они специально упрощались, чтобы не нагружать процессор
SSul
20.08.2016 14:31Ещё генератор сигнала позже усилили, он стал давать более мощный сигнал, излишки забирали стабилитронами и заряжали ими ионистор. Это был дополнительный источник питания, который неплохо так прокачал автономность расходомера
Shamov
20.08.2016 13:08Про подобное «разделение труда» есть хороший анекдот. На фабрике по производству карандашей начальник грифельного цеха обратил внимание на то, что никто не использует грифель до конца, потому что в какой-то момент карандаш становится слишком коротким и его невозможно дальше использовать. Он распорядился делать грифель короче на 4 см, чтобы не тратить зря драгоценный графит. А через какое-то время начальник цеха, где делают деревянные оправы, обратил внимание на то, что грифели стали на 4 см короче, и распорядился делать оправы тоже на 4 см короче, чтобы не тратить зря драгоценную древесину.
Arlekcangp
22.08.2016 09:03А еще через какое то время на эту ситуяцию обратил внимание маркетолог — и запустил рекламу что укороченные на 20% карандаши удобнее лежат в руке и меньше ломаются. Продажи немножко подросли правда никто точно не уверен почему — то ли из за «сообразительности» маркетолога то ли из за первого сентября =)
Так все это к сожалению и происходит в реальности.
polar_winter
22.08.2016 09:03Мне показалась что ваше статья написана в стиле детектив. Читателю было бы самому приятно разобраться во всем этом, ещё до ваших обяснений. Для этого на ваших диаграммах не плохо иметь указания единиц измерения и единичные отрезки.
Zenitchik
Проблема была в том, что участники проекта мало обсуждали друг с другом проблемы на стыке областей. Скажем, инженер мог бы вместе со схемотехником подумать об улучшении конструкции датчика, а схемотехник с программистом — о рациональном использовании периферии микроконтроллера.