Форма контролю

Definition of Done курсу — залік. Проміжні точки:

Потік ділиться на 6–7 команд. Формування команд — самоорганізація студентів; викладач задає лише розмір групи. Обґрунтування: нав’язаний партнер у команді — гарантована проблема, і жодна методика цього не компенсує.

Кожна команда пропонує власну міні-бізнес-модель навколо embedded-виробу, який обов’язково містить програмну, апаратну та механічну складові (див. 2.4). Для кожної атестації окремо задається свій definition of done — який саме стан «бізнесу» має бути досягнутий.

Термінологічний режим

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

Робоче визначення

Вбудоване програмне забезпечення — це ПЗ, яке виконується у наперед визначеному, апаратно обмеженому середовищі, спроєктованому спеціально під нього.

Три ознаки, які мають виконуватися одночасно:

1. Обмежені ресурси — пам’ять, частота, енергоспоживання, периферія.
2. Прив’язка до конкретного таргета — ПЗ заточене під конкретний апаратний виріб, а не під клас машин.
3. Ієрархія абстракцій — від бізнес-логіки до фізичного рівня.

Формально під цей опис можна підвести майже будь-яке ПЗ. Відмінність embedded у тому, що воно відповідає йому найпростішим способом, без натяжок.

Дві топології

Практично всі embedded-системи зводяться до однієї з двох конфігурацій.

Топологія A — bare-metal.

Application (бізнес-логіка)
        ↓
HAL (Hardware Abstraction Layer)
        ↓
Hardware

Ви берете мікроконтролер (STM32, Atmel, NXP), відкриваєте IDE вендора, підключаєте його HAL-бібліотеку і пишете бізнес-логіку, яка смикає цю бібліотеку напряму. Підхід дуже поширений і фінансово доцільний для невеликих систем.

Топологія B — з операційною системою.

Application (бізнес-логіка)
        ↓
Middleware (високорівневі драйвери, сервіси)
        ↓
Operating System (як правило, Linux-based)
        ↓
HAL / низькорівневі драйвери
        ↓
Hardware

Застосовується там, де потрібні вища гнучкість, робота з абстрактно вищими рівнями периферії або перевикористання великих обсягів чужого коду. Типовий приклад — система на Raspberry Pi, де треба підняти Ethernet, Wi-Fi, тунельовані протоколи, поштовий чи веб-сервіс. Писати це з нуля економічно безглуздо: спершу піде половина життя на написання, друга — на виправлення власних помилок. Reusing тут не компроміс, а норма.

Топологія B — беззаперечний чемпіон у великих системах: automotive, aerospace, military, industrial engineering, тобто скрізь, де коду дуже багато.

Сфери застосування

Вбудовані системи поширилися з 1950-х років: military, industrial engineering (верстати, автоматизовані лінії), aerospace, automotive (ECU), home and office use. Підходи в усіх цих галузях плюс-мінус однакові — різниться лише ступінь строгості.

Ключовий наслідок

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

Запитання, яке ставилося аудиторії

Які додаткові накладні витрати виникають при розробці ПЗ, що виконується на залізі? Куди інженерам і менеджменту треба дивитися найпильніше?

Відповідь: тестування.

Аргумент простий. Вбудована система ізольована. У топології A після деплою на залізо вона стає атомарним юнітом: дослідити її зсередини вже не можна, а якщо помилка виявилася після виготовлення партії плат — це прямі фінансові втрати. У топології B ситуація м’якша: залишається можливість runtime-діагностики, дебагу і навіть зміни бізнес-логіки після деплою. Це серйозна перевага таких систем — але, як буде показано нижче, вона ж є їхньою вразливістю.

Зробити якісне ПЗ — це не написати його. Це його протестувати.

Кейс К-1.1. Верстат і watchdog

Ви розробляєте систему керування верстатом. Оператор аварійно зупинив верстат і поліз руками виймати заготовку. У коді працює watchdog-таймер, який ви забули занулити. Чіп ребутнувся, система запустилася.

Наслідок — травма або втрата працездатності оператора, довічні зобов’язання роботодавця, і, окремо, ваша відповідальність як розробника. Помилка в одному рядку коду перетворилася на подію у фізичному світі.

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

Функційна безпека

Функційна безпека (functional safety) — властивість системи не створювати неприйнятного ризику внаслідок власної некоректної поведінки. Джерело проблеми тут — ненавмисна помилка: некомпетентність, брак часу, дефект, який не був виявлений на тестуванні й дійшов до деплою.

Наслідки ранжуються за тяжкістю — від простого malfunction (функція не відпрацьовує) через пошкодження компонентів до шансу травмування людини, високого шансу травмування, шансу загибелі й гарантованої загибелі.

Відповідно ранжуються і класи функційної безпеки. У шкалі ISO 26262 це рівні ASIL:

Чим вищий клас — тим вищі ставки й тим суворіші вимоги до процесу. Для кожного класу існують свої підходи до тестування.

ISO 26262 — фундаментальний стандарт, історично автомобільний, який згодом розгалузився в похідні редакції для industrial, aerospace, military, medical та інших галузей.

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

Кібербезпека

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

Розрізнення принципове:

Цікавий парадокс двох топологій:

• Топологія A — складна в дебазі, негнучка, важка для тестування. Саме через негнучкість вона непогано захищена від зовнішнього втручання.
• Топологія B — гнучка, дозволяє runtime-дебаг, runtime-зміну ПЗ. Саме тому вона вразливіша і є основною зоною інтересу для атак.

Обидві складові — функційна безпека і кібербезпека — є обов’язковими вимогами до розробки ПЗ відповідних класів і предметом окремих умов, які замовник виставляє виконавцю.

Точка входу в розробку

З чого починається правильна побудова системи, вибір підходів і архітектури?

Відповідь банальна і водночас принципова: з розмови з клієнтом. Розмови, яка обов’язково має бути формалізована у вигляді системних вимог і специфікацій (System Requirements).

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

Ідея чи гроші

На запитання до аудиторії прозвучали дві відповіді: «з ідеї» і «з бажання заробляти гроші». Обидві правильні — але тільки разом.

• Ідея без ресурсу залишається гарною темою для розмови за пивом.
• Ресурс без ідеї — просто привід випити те пиво.

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

Гроші при цьому — не самоціль, а зручно вимірювана конвертація ресурсів.

Ланцюг «ідея → технологія → гроші»

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

1. Не було ресурсу, щоб довести ідею до розгорнутого стану.
2. Ідея не була перетворена на технологію.

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

ідея → [ресурс] → технологія → [ринок] → гроші

Розрив на будь-якому кроці зупиняє весь ланцюг.

Дві моделі

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

Сервісна компанія. Ідея чужа. Її власник має гроші, вірить у неї і фінансує вас. Ви передаєте людські, технологічні й апаратні ресурси; він компенсує вам витрачений час грішми. Так працюють N-iX, GlobalLogic, SoftServe та інші. Це надання послуги з перетворення чужої ідеї на технологію для подальшої комерціалізації.

Мета в обох випадках однакова — виграш у конкурентній боротьбі.

Сервісна компанія

Золоте правило: IP залишається за клієнтом.

Ви витрачаєте свій час — компанія компенсує його грішми. Звідси коректний термін: не «зарплата», а компенсація. Але авторське право на результат роботи залишається за замовником.

Наслідок, який варто усвідомити: власник сервісної компанії не є власником її розробок. Власники — клієнти цієї компанії.

NDA (Non-Disclosure Agreement) — угода про нерозголошення. Як учасник проєкту — розробник, тестувальник, менеджер — ви не маєте права розповідати про нього нікому, хто не має такого самого NDA. У межах компанії — можна, за межами — ні.

Продуктова компанія

Механіка та сама, змінюється лише коло осіб.

Приклад української продуктової компанії, наведений на лекції, — Ajax Systems.

Обмеження NDA на практиці

NDA працює, але не бездоганно. Показові ситуації:

• Звільнений співробітник. Формально він під NDA, фактично він уже поза компанією. Робоче правило: обговорювати з ним лише ту стадію проєкту, у якій він був залучений.
• Сім’я. Повна ізоляція інформації в побуті неможлива, і всі це розуміють.

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

Чому не варто починати зі свого бізнесу

Досвід накопичується через помилки. Розумна людина набиває ґулі за чужий кошт. Тому як точка входу рекомендується найм, а не власна справа.

Чому сервісна компанія

Порівняно з продуктовою, сервісна модель вигідніша як стартова:

1. Продуктова компанія захищає свої інтереси значно жорсткіше.
2. Сервісна компанія дає величезний асортимент проєктів, підходів, практик і методик. Проєкт закінчився — ви перейшли на наступний, потім ще на один. За кілька років ви бачите десяток різних конфігурацій замість однієї.

Правило двох років

Рекомендація: близько двох років на компанію, 1–2 проєкти, потім перехід.

Чому не менше. З погляду hiring-менеджера, який особисто співбесідує кандидатів і читає CV: у людину вклали гроші на hiring, потім на onboarding і навчання. Якщо вона йде через 6–12 місяців — інвестиція не відбилася. Це червоний прапорець у резюме.

Два роки виглядають нормально: приблизно 7 місяців onboarding і адаптації, далі півтора року продуктивної роботи. Інвестиція відбита, прибуток компанії принесений, досвід отриманий.

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

Траєкторія цілком

1. 2–3 компанії × 1–2 проєкти          ~4–6 років, junior → senior
   мета: побачити різні процеси, тули, сетапи команд

2. Довгий марафон: 1–2 проєкти, 4+ роки в одній компанії
   мета: пройти ПОВНИЙ цикл проєкту —
   як він заходить у компанію, стартує, вибудовується,
   виходить у сталий режим, завершується, як робиться handover

3. Рух назад по воронці
   delivery → lead → pre-sale
   мета: побачити, як компанія взагалі отримує клієнтів

4. Власний бізнес

Крок 3 варто пояснити окремо. Спершу ви бачите проєкт зсередини delivery. Потім треба дослідити точку, у якій lead переходить у delivery. Потім — як lead перетворюється на клієнта. І нарешті — як невідома компанія взагалі перетворюється на lead. Цим займаються Sales Management і Marketing Department, які будують цілу піраміду дій для конвертації.

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

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

Аргумент про горизонт

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

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