Рівень 1. Вибір чіпа

Обирається разом із написанням програмного забезпечення, а не до нього. Критерії:

• периферія;
• обсяг і тип пам’яті;
• тактова частота;
• енергоспоживання;
• додаткові функції;
• архітектура ядра.

Рівень 2. Базові умови запуску

Не можна просто подати живлення й очікувати, що чіп злетить. У більшості випадків потрібно забезпечити:

• живлення (power);
• скидання (reset);
• тактування (clocking);
• зовнішню пам’ять, якщо власної немає.

Винятки існують — на занятті згадано Microchip як вендора, чиї рішення часто стартують від самого лише живлення. Але це саме винятки.

Рівень 3. Захист входів-виходів

Чіп існує не заради себе. Ви оперуєте його фізичними пінами, на яких розгорнуті інтерфейси, а по інтерфейсах ідуть протоколи. Ці піни треба захистити електрично. Побудова топології захисту I/O — окрема вагома задача hardware-інженера.

Рівень 4. ESD та EMC

Далі — захист від електростатичного розряду (ESD, Electrostatic Discharge) та електромагнітних завад (EMC, Electromagnetic Compatibility). Практично це означає екранування: чіп накривається екраном із фольгованого матеріалу.

Конструювання, підбір і розміщення такого екрана — теж задача hardware-інженера.

Навіщо стільки роботи

Питання, поставлене аудиторії: чому потрібен такий обсяг зусиль, щоб просто забезпечити працездатність маленького чіпа?

З аудиторії прозвучала правильна, але часткова відповідь: кінцевому користувачеві не накажеш не братися за плату руками у вовняних рукавичках. Це справді один із видів небезпеки. Узагальнення ширше.

Теза автора: рівень надійності та безвідмовності цифрової системи керування приблизно на два порядки вищий, ніж в аналогічної системи, побудованої на механічних, гідравлічних чи пневматичних елементах.

Але — і це принциповий нюанс — вона працює так лише тоді, коли побудована правильно. Якщо порушено принципи побудови, система не відповідає тому класу безпеки, надійності й відмовостійкості, який від неї очікують. Тобто всі чотири рівні вище — не перестраховка, а умова, за якої цифрове рішення взагалі виправдовує свій вибір.

Для видання. Оцінка «~400-кратно» подана на занятті як орієнтир із власного дослідження автора (порівняння електронної, механічної, гідравлічної та комбінованої систем керування). Потребує посилання на джерело і, ймовірно, уточнення умов, за яких вона отримана.

Проблема рівнів

Мікроконтролер формує коректний інтерфейс: правильні тайминги, характер сигналу, частоти. Але рівні цих сигналів прив’язані до живлення самого контролера — 5 В, 3,3 В, 1,2 В, 1,1 В. Це логіка TTL (Transistor-Transistor Logic).

А фізичний рівень реальних інтерфейсів — Ethernet, CAN, USB — часто інший. Там може бути вищий струм, а не лише інша напруга. Контролер сам по собі, без обв’язки, не здатний підняти фізичний рівень такого інтерфейсу.

Приклад: CAN — гальванічно розв’язаний інтерфейс, сигнал у якому передається витою парою і переходить через нуль. Це вимагає окремої інтегральної схеми — CAN-трансивера. Виріб одразу розростається.

Економіка компонентів

З аудиторії надійшло слушне заперечення: на складних SoC відповідні блоки можуть бути інтегровані всередину, і зовнішня обв’язка не потрібна. Це правда — але має ціну.

Чудес не буває. Якщо топологія чіпа передбачає фізичну розв’язку всередині, то в ньому є складна схема живлення, складна схема ізоляції, складна схема тепловідведення і, як наслідок, великий корпус. Усе це підіймає ціну.

Тут вмикається логіка масового виробництва. Серійний виріб не дозволяє зайвих витрат навіть на діоді. Якщо є вибір між діодом за 4 центи та за 10, виробник зробить усе, щоб поставити той, що за 4. На mass production ця різниця б’є дуже боляче.

Крім того, embedded — це кастомізація. Ви намагаєтеся не ставити на борт систем, які ніколи не використовуватимете. Багатий SoC оснащений і CAN, і Ethernet, і ще кількома інтерфейсами — ви платите за те, чим не скористаєтеся.

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

Вендорський і геополітичний ризик

Окремий, не суто технічний критерій вибору компонентної бази.

За практикою автора, європейські та американські замовники насторожено ставляться до чіпів китайських вендорів (як приклад згадано ESP32) і намагаються їх уникати. Типовий сценарій ризику:

1. Вендор занижує ціну продукту, зокрема завдяки державній підтримці — демпінг.
2. Компанії переходять на цей компонент і вибудовують під нього свої вироби.
3. Настає момент масштабування.
4. Демпінг зникає, ціна росте, замовник опиняється в залежності.

Загальна тенденція: європейські компанії тяжіють до європейських чіпів, американські — до американських, і вони можуть дозволити собі використовувати компоненти одне одного.

Тут корисно розрізняти технічну оцінку компонента й оцінку постачальницького ризику. Це два різні критерії, і другий у промисловому проєкті часто виявляється вирішальним. Позиція, викладена вище, — практика конкретних замовників, а не універсальне правило.

Firmware

Робить прошивку: application, middleware, абстракції, HAL. На виході — скомпільований бінарний образ.

Hardware

Бере прошивку як вхід і забезпечує все, щоб вона виконувалася: вибір чіпа, енвайронмент, периферія, схематика, PCB layout, трасування, комунікація з виробництвом.

На занятті окремо зазначено: розділяти схематику, трасування та роботу з виробництвом на різні ролі можна, але це практикують лише на великих проєктах із великими бюджетами. Зазвичай це одна роль.

Mechanics

Робить корпус і механічну частину: метал, пластик, гума, дерево, кронштейни. Задача формулюється одним словом — забезпечити, щоб електроніка ефективно функціонувала. За цим словом ховається:

• тепловідведення;
• airflow;
• фільтрація;
• достатній простір для виробу;
• відповідність вимогам, які застосовуються до виробу.

Чому механіка обов’язкова

Механіку легко сприйняти як другорядну. Це помилка, і причина не інженерна, а нормативна.

Сертифікація CE в Європейському Союзі: жодне електричне обладнання не може продаватися на ринку ЄС, якщо воно її не пройшло. CE охоплює електричний, електромагнітний, електростатичний і механічний захист; для окремих категорій додаються радіаційний, хімічний, тепловий та інші аспекти.

Усі ці види сертифікації передбачають наявність корпусу. Немає корпусу — немає сертифікації — немає ринку.

Тому в embedded завжди йдеться про тріо: firmware + hardware + mechanics. Ці люди працюють пліч-о-пліч увесь шлях.

Точки взаємодії

Hardware-інженер є вузлом, що зв’язує обидва боки:

Firmware ←→ Hardware ←→ Mechanics

• Firmware ↔︎ Hardware: платформа, на якій виконується бізнес-логіка.
• Hardware → Mechanics: вимоги щодо масогабаритних характеристик, захисту, теплового менеджменту.

Профіль компетенції

Архітектор не буде настільки ж компетентним у firmware, як firmware-інженер, або в hardware, як hardware-інженер. Його компетенція широка, а не глибока: firmware, hardware, mechanics, стандарти, системна інженерія — плюс достатня відкритість до комунікації, щоб вийти на розмову з клієнтом і водночас прикрити команду зсередини.

Навіщо він потрібен

Ключовий аргумент: одне й те саме рішення може бути правильним для hardware-інженера і неправильним для firmware-інженера. Без спільного технічного фасилітатора кожен тягне свою гілку, і команда розпадається на stand-alone інженерів, які не можуть узгодити технічні рішення.

Архітектор — це нода, до якої звертаються з будь-яких питань зміни scope, зміни умов робіт та інших інженерних рішень.

Він також займається планінгом (тема, якій у курсі відведено окремий великий блок).

Життєвий цикл участі

Архітектор — перша людина з команди, яка заходить у проєкт. Фактично він заходить тоді, коли проєкту ще немає.

Етап 1. Лід. Engagement Management приносить свіжий лід: компанію знайшли на конференції, виставці, вебінарі, або вона сама постукалася через сайт. Що саме вона хоче — точно ще не відомо.

Етап 2. Підготовка. Архітектор вивчає все доступне: LinkedIn компанії, вебсторінку, історії, профілі CIO та інших осіб. Якщо мітинг уже призначено, engagement-менеджери надають референси учасників — архітектор вивчає їхню освіту, професійний профіль, досвід.

Етап 3. Initial meeting. Архітектор виходить на знайомство разом з Engagement Management. Він виступає як чемпіон — людина, яка представляє компанію: розповідає про компетенції в embedded, показує релевантні кейси.

Одночасно він уважно слухає кожен need цього ліда. Щойно прозвучать слова, у яких компанія справді сильна, — починається цілеспрямована робота.

Етап 4. RFQ. Після кількох ітерацій лід надсилає RFQ (Request for Quotation) — запит на пропозицію.

Етап 5. Пропозал. Компанія аналізує, рахує і подає пропозал — документ, у якому описано:

• яким чином вирішується задача клієнта;
• якими ресурсами;
• у якому таймлайні;
• за яку вартість;
• high-level архітектура майбутнього виробу;
• окремо — кожна ризикова точка та її інженерне рішення.

Етап 6. Старт. Якщо клієнта влаштовує побачене — проєкт починається. Архітектор нарізає епіки, фічі, сторі, таски, сабтаски і визначає dependency між стрімами.

Етап 7. Супровід. Перші дні, тижні або місяці архітектор активно веде проєкт. Далі його роль зменшується, на сцену виходить рутина, і рутиною керує менеджер. Архітектор іде в тінь, але залишається в команді й повертається, коли:

• треба ухвалити серйозне технічне рішення;
• виникають ризикові моменти;
• наближається реліз або завершення проєкту.

Окремо: в очах клієнта архітектор назавжди залишається довіреною особою. Він заходив у проєкт разом із ним, багато з ним говорив, справив враження. Ці стосунки підтримуються, зокрема очними зустрічами — практика, яка не припинилася навіть під час війни, бо є критично важливою для бізнесу.

Над командою немає нікого

На запитання, хто об’єднує трьох інженерів, з аудиторії прозвучало «той, хто стоїть зверху над командою». Відповідь автора: такої ролі немає.

Нормальний менеджмент в ІТ — горизонтальний. Є ролі, які стоять збоку, а не зверху.

Ключова концепція — Servant Leader / Servant Manager, лідер або менеджер, що служить. Автор описує власну роль Engineering Manager у N-iX саме в цій моделі.

Як це виглядає на практиці. Hardware-інженер зайшов у глухий кут: не знає, чи піде клієнт на екранування, чи вистачить місця на платі, чи влаштує це механіка. Заходить servant-менеджер і розрулює ситуацію — але служить інженеру, щоб той міг нормально зробити свою роботу. Далі він іде до клієнта і допомагає вже клієнту зрозуміти ситуацію в команді.

Ієрархія авторизації ≠ ієрархія начальства

Резонне заперечення з аудиторії: вертикаль усе одно існує — у системах авторизації, у структурі компанії. Це справді так:

власник → президенти → SVP → VP → директори → менеджмент → інженери

Але автор просить не класифікувати цих людей як начальство:

Поняття начальства — велике зло. Вони виконують свою службову роль, не більше й не менше.

Робоче правило: якщо в чиїйсь ролі є проблема, яка вам заважає, ви йдете до цієї людини з реквестом рівно так само, як вона пішла б до вас. І це працює. Грамотний керівник прийде першим і сам запитає, чи все у вас гаразд — і на це питання треба відповідати чесно.

Рекомендація автора: якщо у вашій компанії це працює інакше — змінюйте компанію або змінюйте компанію зсередини.

Що насправді робить менеджер

Формулювання, запропоноване з аудиторії й уточнене автором: менеджер з’єднує розробку з бізнесом.

Розрізнення мотивацій усередині команди:

Обидві частини необхідні. Друга, «темна» сторона — зміни scope і обіцянки, дані кимось на high-level, — псує чистий інженерний кайф. Але без неї колесо не крутиться.

Кейс К-2.1. Вентилятор

Реальна ситуація з практики автора.

Вихідний стан. Проєкт розпланований як слід. Написані proposal, architecture description, design description, hardware/software test plan. Конкурентно обрана архітектура, визначена топологія, підібрані компоненти, зібрана команда. Усі готові стартувати.

Подія. Приходить клієнт. Він минулого тижня спілкувався зі своїм замовником, і той передумав: ця фіча не потрібна, вентиляційні отвори не потрібні, активний вентилятор — надто дорого, хай тепло відводиться конвекцією.

Проблема. Команда вже прорахувала теплові процеси, зробила симуляцію, знає, що без радіатора, внутрішнього airflow і вентилятора виріб перегріється. Масштаб проєкту: 3–4 місяці підготовки, далі 2–3 роки в робочому режимі, далі кілька років на саппорті.

Чому це не можна комунікувати команді напряму. Такі меседжі деморалізують. І це не поодинокий випадок — подібні новини заходять щотижня. Результат прямої комунікації: команда вигорає, інженери йдуть, вони не хочуть мати справу з такими проєктами. Тому клієнта на таких повідомленнях ізолюють від команди.

Що робить менеджер:

1. Іде до legal department: оформити письмову згоду клієнта на технічно хибне рішення.
2. Іде до high-management і до клієнта: зафіксувати, що клієнт хоче саме цього, що його відмовляли, що він повністю усвідомлює наслідки. Правильні листи, правильна історія рішень.
3. Іде до архітектора й ліда. Вони п’ють каву, добряче лаються, і менеджер коректно доносить задачу: клієнт хоче так, думаймо, як це переробити.
4. Ініціює новий estimate — переоцінку часових витрат на rework.
5. Доносить до клієнта, скільки додаткового часу коштуватиме його рішення.
6. Тільки після загальної згоди — старт робіт.

Формулювання ролі: менеджер згладжує гострі кути там, де інженери гарантовано зірвуться, і забезпечує, щоб відповідальність за рішення лежала там, де вона й має лежати.

Дві функції менеджера

1. Знімати dependency, які виходять за зону відповідальності інженера і які він не може вирішити сам.
2. Не допускати, щоб інженер ухвалював рішення у сферах, у яких він не компетентний.

Менеджер відчуває проблему, що визріває в команді, і заменеджує її до того, як вона вистрелить. Це постійний процес.

Оскільки менеджер не є глибоко компетентним технічно, він багато комунікує: ставить мітинги, просить інженерів долучитися, розпитує — які гвинти потрібні, які контролери, які резистори, де їх зазвичай купують. Це не демонстрація статусу, а спосіб розібратися в процесі, щоб зуміти ним керувати.

Чим embedded відрізняється від чистого софту

У програмного забезпечення немає митниці, немає накладних витрат на перевезення, немає ситуації «на складі закінчилося». Кордони існують хіба що ліцензійні. Цінність софту не вимірюється фізичними мірилами.

Embedded — інша історія. Це матеріальні вироби, які:

• перетинають державні кордони;
• ґрунтуються на компонентній базі, що буває в дефіциті;
• містять компоненти, які можуть бути зняті з виробництва й потребувати заміни;
• потребують митного оформлення, брокерів, логістики.

Навіть механічна частина, яку розробляють у CAD-середовищі (FreeCAD, AutoCAD, SolidWorks, Fusion), у якийсь момент має бути виготовлена — на реальному заводі, за реальними кресленнями, у реальні терміни.

Кейс К-2.2. PCB проти PCBA

Реальна поточна ситуація з практики автора.

Контекст. Найбільші, найшвидші та найдешевші виробники друкованих плат — китайські (згадані JLCPCB, PCBWay). Попередній реліз проєкту було виготовлено там у форматі PCBA (Printed Circuit Board Assembly) — плата з уже запаяними компонентами. Усе відпрацювало нормально.

Подія. Наступний реліз розпланований: бюджет, таймлайн, сетап команди. Замовлення надсилається — і надходить відповідь: для України більше не виготовляємо PCBA. Тільки PCB — гола друкована плата без компонентів.

Наслідки. Перепланувати доводиться все:

Управлінський висновок. Зміна плану — це зміна бюджету. А зміна бюджету — це або репутаційні ризики (не встигли в терміни), або фінансові (не вклалися в гроші). У будь-якому разі — ризики.

І менеджує це тільки менеджер. Жоден інженер не захоче цим займатися: інженер любить робити інженерію. Архітектор може, але не хоче — йому цікавіші технічні речі. Проте без цієї змазки колесо не крутиться.

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

Митниця й зовнішні підрядники

Ще один шар, який виникає після виготовлення. Корпуси виготовлені й зібрані — далі їх треба вивезти з країни або зібрати з електронікою і вивезти. Починаються митниця й брокери.

Жоден із технічних спеціалістів не є достатньо компетентним, щоб робити це професійно. Тому менеджер шукає компетенцію спершу всередині компанії, а якщо її немає — назовні: субпідрядника чи вендора, який візьме на себе зобов’язання, очевидно, оплатно.