Несколько лет назад довелось нам принять участие в разработке счётчика газа. На момент начала работ с заказчиком, у него уже были некоторые наработки. И наработки эти показались нам очень интересным примером для демонстрации последствий неудачного разделения труда по компетенциям. Под катом опишем, почему разделение было неудачным, и как мы решали проблемы, возникшие в результате.
В разработке счётчика газа принимало участие трое специалистов (по факту больше, но в рамках статьи нас интересуют лишь три компетенции). Это были:
- Инженер-конструктор, по совместительству специалист по метрологии
- Схемотехник
- Программист
Конструктор предоставил устройство, выдающее сигнал открытия и закрытия специального клапана. Выглядел он примерно так:
Требовалось измерить время нахождения клапана в открытом состоянии (расстояние от 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-, в зависимости от того, ожидаем мы открытия или закрытия клапана).
Что в итоге?
Разработав свою схему преобразования сигнала и свою прошивку микроконтроллера, мы значительно повысили точность измерения расхода газа. Также мы помогли конструктору расходомера. Теперь он легко мог заметить огрехи в работе клапана и генератора сигнала, и ему не приходилось думать, что проблема не на его стороне. Даже если у него возникали вопросы, ему было с кем их обсудить, т.к. мы всегда могли описать алгоритм преобразования и измерения сигнала с точки зрения метрологии и, при необходимости, откорректировать что-то.
Разделение задач по компетенциям позволяет членам команды достигать очень высокого уровня развития в своих областях, но рано или поздно мы приходим к тому, что специалисты перестают понимать друг друга. В этой ситуации очень полезно иметь под рукой человека, разбирающегося во всех областях, связанных с проектом. Может не так хорошо, как какждый специалист в отдельности, но способный видеть картину в целом. Также опыт этого проекта показал, что такой специалист очень положительно влияет на взаимодействие специалистов, культивирует интерес инженеров к работе друг с другом. Программист и схемотехник стали чаще думать о погрешности измерений, схемотехник открыл для себя новые возможности использования периферии микроконтроллера, конструктор-метролог начал доверять своим коллегам и активно использовать результаты их работы для анализа аппаратной части.
Также хотелось бы обратить внимание на то, что имея поверхностные знания по широкому кругу областей, человек-оркестр на этапе собеседования не выглядит привлекательным как с точки зрения программиста, так и с точки зрения метролога и схемотехника. Но по факту он может сыграть ключевую роль в сложной ситуации.
Автор: SimbirSoft
