Про розподіл праці та його наслідки

Кілька років тому довелося нам взяти участь у розробці лічильника газу. На момент початку робіт із замовником, у нього вже були деякі напрацювання. І ці напрацювання здалися нам дуже цікавим прикладом для демонстрації наслідків невдалого поділу праці за компетенціями. Під катом опишемо, чому поділ було невдалим, і як ми вирішували проблеми, що виникли в результаті.

У розробці лічильника газу брало участь троє фахівців (за фактом більше, але в рамках статті нас цікавлять лише три компетенції). Це були:
  1. Інженер-конструктор, за сумісництвом фахівець з метрології
  2. Схемотехник
  3. Програміст
Конструктор надав пристрій, що видає сигнал відкриття і закриття спеціального клапана. Виглядав він приблизно так:

Потрібно виміряти час знаходження клапана у відкритому стані (відстань від A до B), і частоту відкривання клапана.
Звичайно ж обробляти такий сигнал безпосередньо мікроконтролером не представляється можливим, так що перед схемотехником була поставлена задача по розробці проміжного перетворювача, що формує наступний сигнал:

Пристрій буде працювати від батареї, так що більшу частину часу мікроконтролер буде перебувати в Sleep Mode. Тому програміст попросив завести сигнал на Interrupt pin, налаштував пробудження мікроконтролера по перериванню від відповідного порту і в обробника переривання виконував запуск/зупинка таймера.
Все виглядає добре, кожен фахівець виконував свою роботу і робив її якісно. Тільки ось якість роботи пристрою в цілому мало кого влаштовувало. При постійній витраті, пристрій видавало свідчення зі значним розкидом і було зовсім не ясно в чому причина.

Чому так вийшло?

Некоректну роботу витратоміра виявили на ранньому етапі розробки. Такі помилки трапляються і в цьому немає нічого страшного. Страшно інше, ніхто не знав де помилка і як її знайти.
Причинами недостатньої точності витратоміра могли служити:
  1. Помилки в конструкції клапана і генератора вхідного сигналу
  2. Помилки в схемі перетворення вхідного сигналу
  3. Помилки в програмному забезпеченні
До того ж, розробники не мали повної впевненості в тому, що проблема має місце в принципі, адже характеристики витратоміра визначалися з допомогою еталонного стенду, який розроблявся паралельно з витратоміром і теж був далекий від ідеалу.
В результаті рано чи пізно ми отримуємо ситуацію, коли кожен учасник команди, будучи впевненим у бездоганності результатів своєї роботи, кришить батон на сусіда. Тоді як вище керівництво сприймає проект цілком і невдоволено всією командою. У команді зароджуються конфлікти, гучні суперечки, роз'єднання. Конструктор заявляє, що помилка у програмі, програміст каже, що помилка в конструкції клапана і т. д.

Що робити?

Розробка витратоміра значно ускладнилася і замовник прийняв рішення залучити нових фахівців. Так що ми взялися за роботу.
Ми бачили два шляхи вирішення проблеми:
  1. Тотальне тестування та приймання роботи кожного члена команди
  2. Людина-оркестр
Перший варіант виглядає досить стандартно і дуже популярний в сфері розробки ПЗ. Наприклад, щоб перевірити програмну частину, ми купуємо або розробляємо прецизійний генератор сигналу, який формується на виході перетворювача, подаємо його на мікроконтролер і порівнюємо його показання в різних умовах з показаннями генератора. Рішення не найдешевше і, іноді, далеко не найшвидший, але цілком робочий.
Працездатність і якість перетворювача вхідного сигналу також можна оцінити з допомогою доброго і коректно налаштованого осцилографа. Або розробити спеціальний пристрій для аналізу перетворення.
А ось з перевіркою роботи клапана все набагато складніше, потрібно подати фіксований витрата, провести перетворення сигналу клапана і вимірювати сигнал за допомогою спеціалізованого частотомера. По факту це мало чим відрізняється від того витратоміра, який у нас вже був.
На жаль, наш замовник не був готовий йти таким шляхом, йому потрібно було більш витончене рішення, тим більше, що не вдалося розробити вдалий алгоритм перевірки клапана і генератора сигналу.
Тому замовникові був наданий співробітник, який має компетенцію як у схемотехніці, так і в програмуванні з метрологією. Його завданням було проаналізувати ситуацію в цілому і позбавити команду від можливості звалювати вину один на одного.
Заглянемо під капот
І ось наш людина-оркестр приступив до аналізу проекту.
Аналіз почався з перетворювача вхідного сигналу:

Оригінал схеми не зберігся, але суть її можна вловити по картинці. Як видно, схема побудована на тригері (4013) і оптронах. Помилкові спрацьовування усунуті з допомогою стабілітрона D1 і RC-ланцюжків.
Схема цілком непогано перетворює вхідний сигнал від клапана. Але при її побудові схемотехник не враховував кінцеву мету та специфіку сигналу.
Суть проблеми полягала в тому, що при постановці завдання схемотехніку, йому була надана осцилограмма вхідного сигналу і очікуваний вигляд вихідного. По осцилограмі схемотехник не міг побачити, що крутизна ключових фронтів A і B буде недостатньою, щоб забезпечити стабільне і вчасне спрацьовування оптронів. За фактом, для коректної роботи схеми перетворення було необхідно використання компараторів. Схемотехніка таке рішення не дуже влаштовувало, т. к. компаратори ускладнять схему і напевно дадуть більше споживання. Багато в чому таке побоювання пов'язано з звичкою вирішувати поставленні завдання виключно схемотехнически, не кооперуючись з програмістом і не використовуючи можливостей мікроконтролера.
З програмою теж не все було гладко. З одного боку, якщо мікроконтроллер весь час спить, він отримує переривання і миттєво запускає/зупиняє таймер. Однак варто було включити енергозберігаючий режим, як починалося дивне. Заглянувши в даташит мікроконтролера, ми виявили, що час пробудження мікроконтролера залежить від багатьох факторів, і це суттєво позначалося на точності вимірювань. Запуск і зупинка таймера значно відставав від вхідного сигналу. Програміст знав, що час пробудження порівнянно з часом знаходження клапана у відкритому стані, однак він розраховував, що воно призведе лише до рівномірного зміщення моменту запуску/зупинки таймера щодо вхідного сигналу. За фактом ж ми отримали значний розкид у свідченнях енергозберігаючого та безсонного мікроконтролерів. Для метролога ця проблема була б очевидною, але він не брав участь в розробці ПЗ, т. к. не мав такої експертизи.
Аналіз роботи клапана провести не вдалося. Випробувати клапан і оцінити його роботу без перетворення і вимірювання його сигналу було складно або неможливо. Ми вирішили розібратися з проблемами в перетворювачі і програмі, отримати вимірювально-обчислювальний блок, який не буде викликати у нас сумнівів і провести випробування клапана за допомогою отриманого блоку.

Людина-оркестр

Розібравшись у проекті в цілому, ми приступили до вирішення очевидних проблем.
Простіше всього було вирішити програмну проблему — запуск і зупинка таймера. На применявшемся нами мікроконтролері був Gate-controlled timer, який міг запускатися і зупинятися апаратно, до пробудження мікроконтролера і, якщо буде потрібно, навіть без його пробудження. Якби програміст цікавився метрологією, він би і сам давно знайшов таке рішення і спробував його реалізувати. Але найчастіше програмістів цікавить лише програмування. До того ж було ще два чинники, які значно вплинули на прийняття невдалих рішень програмістом:
  1. Програміст не працював в режимі активного енергозбереження. Він просто не стикався з проблемою повільного пробудження мікроконтролера і ефектами, що проявляються в зв'язку з цим
  2. Програміст вже працював c Gate-controlled таймером і зіткнувся з тим, що він просто не працює. Так що на всіх наступних проектах він уникав цієї функції і боявся її як вогню. Як виявилося, не всі програмісти читають Errata і відстежують ревізії мікроконтролерів. На ранніх ревізіях мікроконтролера ця функція дійсно не працювала.
Попутно ми торкнулися точність перетворення вхідного сигналу. Для нас була очевидна необхідність переходу від оптронів до компараторам. Замовника турбувала проблема підвищення споживання, він вже чув про це від свого схемотехніка. Схемотехник відмінно розбирався в своїй предметній області, але навіть не замислювався про функціонал застосовується на проекті мікроконтролера. Мало того, що мікроконтролер вже містив у собі два компаратора, так ще виявилося, що нам цілком вистачить одного з них, ми просто будемо комутувати нижній і верхній рівні опорного напруги програмно, без застосування додаткових зовнішніх комутаторів. Враховуючи, що низьке енергоспоживання було одним з ключових переваг застосовуваного нами мікроконтролера, компаратор обійшовся нам дуже дешево (близько 8 мкА). А високий вхідний опір компаратора дозволило зробити досить недорогий по споживанню набір опорних напруг (не більше 10 мкА). У підсумку маємо досить таки просту схему обробки вхідного сигналу:

Т. к. Від клапана приходить сигнал як позитивний, так і негативний, ми зміщуємо його з допомогою резисторів R1 і R2. Дільник R3-R5 ми задаємо опорні напруги. По мірі зниження напруги на батареї опорні напруги зміщення на R1 і R2 будуть знижуватися синхронно, так що на точності перетворення сигналу це позначиться незначно.
Щоб запускати і зупиняти таймер за рахунок застосування технології gate-control, наш мікроконтролер формує сигнали відкриття і закриття воріт з допомогою компаратора на апаратному рівні без виходу з sleep mode. RC ланцюжка скасовані, так як ми можемо програмно управляти воротами з допомогою порту RA5 мікроконтролера. Вихід компаратора з'єднаний з CLK входом тригера. Опорне напруга компаратора комутируется програмно (підключається або C12IN0-, або C12IN1-, в залежності від того, очікуємо ми відкриття або закриття клапана).

Що в підсумку?

Розробивши свою схему перетворення сигналу і свою прошивку мікроконтролера, ми значно підвищили точність вимірювання витрати газу. Також ми допомогли конструктору витратоміра. Тепер він легко міг помітити огріхи в роботі клапана і генератора сигналу, і йому не доводилося думати, що проблема не на його боці. Навіть якщо у нього виникали питання, йому було з ким їх обговорити, т. до. ми завжди могли описати алгоритм перетворення та вимірювання сигналу з точки зору метрології та, при необхідності, відкоригувати щось.
Розподіл завдань за компетенціями дозволяє членам команди досягати дуже високого рівня розвитку в своїх областях, але рано чи пізно ми приходимо до того, що фахівці перестають розуміти один одного. У цій ситуації дуже корисно мати під рукою людини, що розбирається у всіх областях, пов'язаних з проектом. Може, не так добре, як какждый спеціаліст окремо, але здатний бачити картину в цілому. Також досвід цього проекту показав, що такий фахівець дуже позитивно впливає на взаємодію фахівців, культивує інтерес інженерів до роботи один з одним. Програміст і схемотехник стали частіше думати про похибки вимірювань, схемотехник відкрив для себе нові можливості використання периферії мікроконтролера, конструктор-метролог почав довіряти своїм колегам і активно використовувати результати їх роботи для аналізу апаратної частини.
Також хотілося б звернути увагу на те, що маючи поверхневі знання по широкому колі областей, людина-оркестр на етапі співбесіди не виглядає привабливим як з точки зору програміста, так і з точки зору метролога і схемотехніка. Але по факту він може зіграти ключову роль у складній ситуації.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.