Лекція 01. Вбудовані системи та дві моделі ІТ-бізнесу

Хронологія: 01.09.2026 · старт курсу.
Первинне джерело: повний автоматичний транскрипт.
Статус: реконструйовано з первинного запису та зафіксовано 28.09.2026.

Навіщо існує цей курс

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

Ключова рамка курсу:

ідея
  ↓
формалізація потреби
  ↓
клієнт / ринок / фінансування
  ↓
команда + процеси + артефакти
  ↓
розробка embedded-системи
  ↓
верифікація / валідація / інтеграція
  ↓
delivery / підтримка / завершення

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

1. Що таке embedded у робочому сенсі курсу

Робоча ознака embedded-ПЗ — воно створюється для визначеного апаратного середовища і є частиною фізичного виробу або системи. Для нього суттєвими є не тільки функції програми, а й пам'ять, обчислювальні ресурси, енергоспоживання, периферія, інтерфейси, часові характеристики та фізичні наслідки помилки.

У лекції протиставлені дві типові топології.

1.1. Компактна система: application → HAL → hardware

Для відносно невеликих MCU-рішень прикладна логіка може працювати безпосередньо поверх vendor HAL/driver layer.

Application / business logic
            ↓
HAL + low-level drivers
            ↓
MCU / DSP / SoC / інший target

Переваги: менший стек, контрольовані ресурси, передбачуваність. Ціна — більша прив'язаність до target і потреба власноруч закривати більше інфраструктурних задач.

1.2. Багаторівнева система: application → middleware/OS → HAL → hardware

У більших системах доцільно перевикористовувати готові мережеві, файлові, діагностичні та інші служби.

Application
    ↓
Middleware / services
    ↓
Operating system / runtime
    ↓
HAL / drivers
    ↓
Hardware

Це не робить систему автоматично «кращою». Це інший компроміс: більше повторного використання і гнучкості, але складніший software stack, інтеграція, update/security surface і більше взаємозалежностей.

2. Чому embedded не можна розглядати як «просто software»

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

• неправильна команда актуатору;
• пошкодження hardware;
• небезпечний стан обладнання;
• дорогий rework вже виготовленої партії;
• порушення вимог safety/security;
• втрата довіри клієнта.

Звідси центральна теза лекції: якісна embedded-розробка невіддільна від тестування, системної інженерії та контролю ризиків.

3. Functional safety та cybersecurity — це різні осі ризику

Лекція вводить два різні джерела небажаної поведінки:

Ці сфери взаємодіють, але не заміняють одна одну.

Редакторське уточнення 01 — ISO 26262

Усне формулювання лекції було ширшим, ніж коректна область застосування стандарту. ISO 26262 — стандарт функціональної безпеки для E/E-систем серійних дорожніх транспортних засобів. Для industrial, aerospace, railway, medical та інших доменів існують власні профільні стандарти; ISO 26262 не є універсальним «базовим стандартом для всіх safety-critical галузей».

Офіційне джерело: https://www.iso.org/standard/68385.html

Редакторське уточнення 02 — QM та ASIL

Для automotive у ISO 26262 використовується QM та ASIL A–D. ASIL у HARA не отримується простим множенням «ймовірність × наслідок». Класифікація базується на поєднанні Severity, Exposure та Controllability. Детальний алгоритм треба вивчати безпосередньо за ISO 26262-3.

Для cybersecurity автомобільного E/E-життєвого циклу профільним джерелом є ISO/SAE 21434: https://www.iso.org/standard/70918.html.

4. Ідея + ресурс = шанс на технологію

У лекції бізнес розглядається через дві необхідні складові:

ІДЕЯ  +  РЕСУРСИ  →  ТЕХНОЛОГІЯ  →  ЦІННІСТЬ ДЛЯ РИНКУ

Сама ідея не гарантує продукту. Потрібні люди, час, гроші, обладнання, виробництво, маркетинг, legal/IP, тестування, доступ до ринку. Гроші тут зручні як універсальна форма ресурсу, але не є єдиним ресурсом.

5. Дві бізнес-моделі, які курс використовує як основну розвилку

5.1. Product company

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

5.2. Service company

Клієнт має бізнесову або технічну потребу, але залучає зовнішню engineering capacity. Сервісна компанія надає людей, процеси, інфраструктуру, domain expertise, іноді hardware/manufacturing capacity і бере оплату за погоджену модель співпраці.

Курс свідомо починає шлях із service model, бо вона дозволяє розібрати багато реальних процесів — lead generation, pre-sale, proposal, staffing, delivery — до переходу до product model.

6. IP та NDA: що треба зрозуміти до початку роботи

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

Редакторське уточнення 03 — NDA

Правильне розшифрування: Non-Disclosure Agreement, а не Not Discussion Agreement. NDA визначає зобов'язання щодо нерозголошення конфіденційної інформації; конкретні межі залежать від тексту договору й права, що застосовується.

Редакторське уточнення 04 — IP ownership

Теза «в service company IP завжди належить клієнту» корисна як типова бізнесова модель, але не є універсальним юридичним правилом. Ownership, assignment, licensing, background IP, foreground IP та право повторного використання визначаються договором і застосовним правом. На практиці це треба читати в MSA/SOW/IP clauses, а не виводити з самого факту аутсорсингу.

7. Авторська кар'єрна теза лекції

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

Це кар'єрна рекомендація лектора, а не універсальна єдина траєкторія.

8. Контрольні запитання

1. Яка властивість робить embedded-ПЗ відмінним від довільної desktop/web-програми?
2. Коли bare-metal/HAL-підхід може бути кращим за OS-based stack?
3. Чому software defect в embedded може перетворитися на hardware або safety problem?
4. Чим functional safety відрізняється від cybersecurity?
5. Чому «ідея» ще не є технологією?
6. Що продає product company, а що — service company?
7. Чому IP ownership не можна визначати лише зі слова «outsourcing»?
8. Які обмеження NDA реально накладає на інженера?

9. Міні-завдання

Сформулюйте одну embedded-ідею і опишіть її у двох режимах:

• Product: ви самі фінансуєте і продаєте продукт.
• Service: цю ж потребу приносить клієнт, а ви продаєте йому engineering service.

Для кожного режиму вкажіть: owner ідеї, owner ризику, джерело фінансування, очікуваний результат, ключові IP/NDA питання.

10. Місток до 02.09.2026

Після визначення embedded-системи та двох бізнес-моделей логічне наступне питання: хто саме перетворює ідею на фізичний виріб? Наступне заняття переходить від абстрактної моделі до engineering team: firmware, hardware, mechanics, architecture, management і фізичний supply chain.

Перевірені посилання

• ISO 26262-3:2018, Concept phase / HARA: https://www.iso.org/standard/68385.html
• ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering: https://www.iso.org/standard/70918.html
• AUTOSAR Classic Platform: https://www.autosar.org/standards/classic-platform