Files

T

kk0t9 fb27d8d2fe docs: завершить Tier 1 (контракты) + ревью-фикс red-line CAN

- security-privacy: изоляция, capabilities, гейтинг по каналам, приватность/152-ФЗ;
  first-party = вшит в подписанный образ; рисковые комбинации (vehicle_read+network)
- plugin-sdk: манифест, точки расширения, коллизия интентов, host-allowlist
- hardware: RK3588, power-safe, периферия, HAL/BSP портирование
- ВАЖНО: уточнён red-line CAN (принцип #2 + hardware §4): «чтение» = без
  управляющих/actuator/write-передач; диагностические OBD read-запросы допустимы
  (иначе не прочитать DTC); listen-only — только пассивный сниффинг
- + автозащита питания, тепло, износ eMMC; кросс-доковые аннотации

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-20 20:28:52 +03:00

7.8 KiB

Raw Blame History

Контракт: железо и board-support

Целевой таргет, топология питания, периферия — и HAL/BSP для портирования под другое железо/авто (то самое «API для автопроизводителей/автолюбителей» из vision).

Статус: v1 (на ревью). Связано с: architecture.md · dev-environment.md · data-model.md (§7 DBC) · security-privacy.md (якорь доверия) · домены A/B/E/J/K

1. Целевой SoC

RK3588 / RK3588S класс, 8–16 ГБ RAM. Почему: приличная mainline-Linux-поддержка, Panfrost GPU, мощности хватает на плавный UI и локальную мелкую LLM; это же класс реальных автоголов.

2. Хранилище

eMMC — rootfs, read-only.
Раздел /data (SD/eMMC) — read-write, журналируемый.
Прямое следствие power-safe (принцип #5): запись только в /data.

3. Питание (критично) — power-safe by design

Управляемый power-path: питание устройства коммутируется по зажиганию.
Детект ACC/зажигания — через GPIO (12 В → level-shift).
Автомобильная защита входа: широкодиапазонный DC-DC + защита от load-dump, транзиентов и переплюсовки (бортовые 12 В грязные — скачки до 40+ В).
Hold-up энергия для graceful shutdown при резком пропадании 12 В.
Secure boot (verified boot RK3588) — якорь доверия first-party (из security-privacy.md: first-party = вшит в подписанный образ). Подпись OTA — домен A.

🟡 Выбор hold-up механизма:

(рек.) MCU-копилот — маленький always-on МК: мониторит зажигание, сигналит SoC «выключайся» по ACC-off, держит watchdog, управляет power-sequencing и sleep/wake.
- конденсатор/supercap на пару секунд для флаша и размонтирования.
(проще) только supercap — буфер энергии без логики (детект ACC — на SoC-GPIO).

Рекомендую MCU-копилот: он же закрывает watchdog и пробуждение. (Прошивка МК — домен B.)

4. Периферия

Узел	Старт	Прод / позже
Дисплей	HDMI + USB-тачскрин	MIPI-DSI / LVDS панель
CAN/OBD	ELM327 (USB/BT)	нативный CAN-трансивер → SocketCAN
GPS	USB/UART, NMEA	—
Связь	USB-модем (ModemManager) / Wi-Fi	—
Аудио	I2S codec + усилитель	—
Микрофон	USB mic-массив (wake-word, шумоподавление)	—
Камеры	задняя (CVBS capture-чип + драйвер, фаза 2)	dashcam / surround (задел, домен J)
Мультируль	кнопки руля: чтение с CAN или ADC (резистивная лесенка)	—

Два пути чтения и точный смысл «read-only»:

Пассивный сниффинг (listen-only): CAN-контроллер в silent-режиме — физически не передаёт и не шлёт ACK; читаем broadcast-кадры машины (нужен DBC). Ноль TX.
OBD-II поллинг: чтобы прочитать DTC и PID, протокол требует отправить кадр-запрос (Mode 01/03/07/09). Это НЕ listen-only — мы передаём, но только стандартные диагностические read-запросы.

Red-line (принцип #2): запрещены управляющие/actuator-команды, запись в ECU, сброс DTC (Mode 04), UDS-write — любые state-changing передачи. Безобидные read-запросы OBD-II разрешены (без них не прочитать ошибки). Чистый listen-only — только для пассивного пути.

5. HAL / board-support (портирование)

HAL абстрагирует железо-специфичное, чтобы платформа переносилась на другие платы/авто:

Power/зажигание (карта GPIO + протокол MCU-копилота).
CAN (контроллер + listen-only).
Дисплей (тип панели + тач), аудио (codec/усилитель/маршрутизация).
GPS-источник, захват камер, карта ввода мультируля.

BSP (board-support package) = device tree (overlay) + конфиг HAL + per-vehicle DBC/маппинг сигналов (см. data-model.md §7).

Порт = новый BSP. Это и есть «API под конкретное железо/авто» из vision: автопроизводитель/энтузиаст поставляет BSP, ядро не трогается.

6. Первый таргет vs портируемость

Один reference-таргет доводим end-to-end (vision: не «любое железо из коробки»). Портируемость — силами других через BSP/HAL.
🟡 Выбор конкретной платы — отложен (решение по доступности/цене). Кандидаты: Radxa Rock 5B / 5B+, Orange Pi 5 / 5 Plus, Khadas Edge2 — критерии: mainline-поддержка, доступность (в т.ч. в РФ), цена, IO (CAN-способные пины).

Открытые вопросы (→ роутинг)

🟡 Выбор reference-платы — procurement-решение (доступность/цена в РФ). → отдельно.
◻️ Прошивка MCU-копилота (детект ACC, sequencing, watchdog, протокол к SoC). → домен B.
◻️ Ранний путь задней камеры (Stage 0 boot) — аппаратная сторона. → домен J + B.
🟡 Подписанные OTA (вторая половина цепочки доверия; secure boot закрыт здесь). → домен A.
◻️ Тепловой режим: RK3588 в горячем салоне/закрытом корпусе — радиатор, throttling. → домен A.
◻️ Износ eMMC/SD при записи (логи/трипы/телеметрия) — минимизация записи, особенно на SD. → домен A/B.

Журнал решений (hardware)

Решение	Выбор	Дата
SoC	RK3588/RK3588S класс, 8–16 ГБ	2026-06-16
Хранилище	eMMC RO rootfs + журналируемый `/data`	2026-06-16
Hold-up питания	MCU-копилот + cap (🟡); supercap-only — проще	2026-06-16
CAN	пассивный listen-only + OBD read-запросы (без state-changing TX); ELM327 на старте	2026-06-16
Доверие	secure boot анкорит first-party; подпись OTA — домен A	2026-06-16
Портируемость	HAL + BSP; один reference-таргет first-party	2026-06-16

7.8 KiB Raw Blame History Unescape Escape