Promwad

Недавно мы успешно портировали фреймворк Flutter на ТВ-приставку c открытой программной платформой RDK. В этой статье расскажем о трудностях, с которыми пришлось столкнуться, и предложим решения для успешного запуска и повышения производительности.

Учитывая, что программный стек RDK или Reference Design Kit сейчас активно используется для разработки OTT-приложений, голосового управления приставками и других продвинутых функций для видео по запросу (VoD), мы хотели разобраться, сможет ли Flutter работать на ТВ-приставке. Оказалось, что да, но, как это обычно бывает, есть нюансы.

Далее мы по шагам распишем процесс портирования и запуска Flutter на встраиваемых Linux-платформах и разберемся, как этот SDK с открытым исходным кодом от Google чувствует себя на железе с ограниченными ресурсами и ARM-процессорами.

Но прежде чем переходить непосредственно к Flutter и его преимуществам скажем пару слов об исходном решении, которое было задействовано на ТВ-приставке. На плате работала связка набор библиотек EFL + протокол Wayland, а рисование примитивов было реализовано из node.js на основе плагинного нативного модуля. Это решение неплохо себя показало с точки зрения производительности при отображении кадров, однако сам EFL отнюдь не самый новый фреймворк для отрисовки. А в режиме выполнения node.js со своим огромным event-loopом казался уже не самой перспективной идеей. В то же время Flutter мог позволить нам задействовать более производительную связку рендеринга.

Для тех, кто не в теме: первую версию этого SDK с открытым кодом Google представил еще шесть лет назад. Тогда этот набор средств разработки годился только для Android. Сейчас на нем можно писать приложения для веба, iOS, Linux и даже Google Fuchsia. :-) Рабочий язык для разработки приложений на Flutter Dart, в свое время он был предложен в качестве альтернативы JavaScript.

Перед нами стоял вопрос: даст ли переход на Flutter какой-то выигрыш по производительности? Ведь подход там совершенно иной, хоть в конечном счете и имеется та же графическая подсистема Wayland + OpenGL. Ну и как там с поддержкой процессоров с neon-инструкциями? Были и другие вопросы, например, нюансы по переносу UI на dart или то, что поддержка Linux находится в стадии альфы-беты.

Сборка Flutter Engine для ТВ-приставок на базе ARM

Итак, начнем. Вначале Futter нужно запустить на чужеродной платформе с Wayland + OpenGL ES. В основе рендеринга у Flutter лежит библиотека Skia, которая прекрасно поддерживает OpenGL ES, поэтому в теории все выглядело хорошо.

При сборке Flutter под наши целевые устройства (три ТВ-приставки с RDK), к нашему удивлению, проблемы возникли только на одной. Не будем с ней сражаться, т.к. из-за старой архитектуре intel x86 она для нас не является приоритетной. Лучше сосредоточимся на оставшихся двух ARM-платформах.

Вот, с какими опциями мы собирали Flutter Engine:

./flutter/tools/gn \      --embedder-for-target \      --target-os linux \      --linux-cpu arm \      --target-sysroot DEVICE_SYSROOT      --disable-desktop-embeddings \      --arm-float-abi hard      --target-toolchain /usr      --target-triple arm-linux-gnueabihf      --runtime-mode debugninja -C out/linux_debug_unopt_arm

Большинство опций понятны: собираем под 32-битный ARM-процессор и Linux, выключая при этом все лишнее через --embedder-for-target --disable-desktop-embeddings.

Для сборки в системе должен быть установлен clang версии 9 и выше, т.е. это стандартный сборочный механизм Flutter, инструментарий кросс-компиляции gcc не пойдет. Самое важное подать корректный target-sysroot устройства с RDK.

Честно говоря, мы удивились, что при сборке не возникло вообще никаких нюансов. На выходе получаем заветную библиотеку flutter_engine.so и заголовок с необходимыми функциями для эмбеддера.

Теперь можно собрать целевой проект flutter/dart с нашей библиотекой/движком. Это сделать легко:

flutter --local-engine-src-path PATH_TO_BUILDED_ENGINE_src --local-engine=host_debug_unopt build bundle

Важно! Сборка проекта должна происходить не на устройстве с собранной библиотекой, а на хостовой, т.е. x86_64!

Для этого достаточно еще раз пройти путь сборкой gn и ninja только под x86_64! Именно она указывается в параметре host_debug_unopt.

PATH_TO_BUILDED_ENGINE_src это путь, где находится engine/src/out.

За запуск Flutter Engine под системой обычно отвечает embedder, именно он конфигурирует Flutter под целевую систему и дает основные контексты рендеринга библиотеке Skia и Dart-обработчику. Не так давно в состав Flutter добавили linux-embedder, и, в частности, GTK-embedder, так что можно воспользоваться им из коробки. На нашей платформе на момент портирования это был не вариант, нужно было что-то независимое от GTK.

Рассмотрим некоторые особенности реализации, которые пришлось учесть с кастомным эмбеддером (все, кто любит разбирать не нюансы, а исходники целиком, может сразу перейти к проекту нашего форка с доработками на github.com). К тому же по производительности наш вариант немного выигрывал у версии GTK, что было крайне важно для заказчика, и не тянул за собой весь зоопарк GTK-библиотек.

Так что же вообще нужно от эмбеддера для запуска flutter-приложения? Достаточно, чтобы он просто вызывал из библотеки flutter_engine.so

FlutterEngineRun(FLUTTER_ENGINE_VERSION, &config, &args, display /* userdata */, &engine_);

где в качестве параметров идет передача настроек проекта (директория с собранным flutter bundle) FlutterProjectArgs args и аргументов рендеринга FlutterRendererConfig config.

В первой структуре как раз задается путь bundle-пакета, собранного flutter-утилитой, а во второй используются контексты OpenGL .

// пример использования на github.com/DEgITx/flutter_wayland/blob/master/src/flutter_application.cc

Все довольно примитивно, но этого достаточно для запуска приложения.

Проблемы и их решение

Теперь поговорим о нюансах, с которыми мы столкнулись на этапе портирования. А как же без них? Не только ведь библиотеки собирать :-)

1. Краш эмбеддера и замена очередности вызова функций

Первая проблема, с которой мы столкнулись краш эмбеддера под платформой. Казалось бы, инициализация egl-контекста в других приложения происходит нормально, FlutterRendererConfig инициализирован корректно, но нет эмбеддер не заводится. Значит в связке что-то явно не так. Оказалось, eglBindAPI нельзя вызывать перед eglGetDisplay, на котором происходит особая инициализация nexus-драйвера дисплея (у нас платформа базируется на чипе BCM). В обычном Linux это не проблема, но на целевой платформе оказалась иначе.

Корректная инициализация эмбеддера выглядит так:

egl_display_ = eglGetDisplay(display_);if (egl_display_ == EGL_NO_DISPLAY) {  LogLastEGLError();  FL_ERROR("Could not access EGL display.");  return false;}if (eglInitialize(egl_display_, nullptr, nullptr) != EGL_TRUE) {  LogLastEGLError();  FL_ERROR("Could not initialize EGL display.");  return false;}if (eglBindAPI(EGL_OPENGL_ES_API) != EGL_TRUE) {  LogLastEGLError();  FL_ERROR("Could not bind the ES API.");  return false;}

// github.com/DEgITx/flutter_wayland/blob/master/src/wayland_display.cc корректная реализация, т.е. помогла измененная очередность вызова функций.

Теперь, когда нюанс запуска улажен, мы рады увидеть заветное демо-окно приложения на экране :-).

2. Оптимизация производительности

Настало время проверить производительность. И, честно говоря, она нас не сильно порадовала в режиме отладки (debug mode). Что-то работало шустро, что-то наоборот, имело большие просадки по фреймам и тормозило гораздо больше, чем что-то похожее на EFL+Node.js.

Мы немного расстроились и начали копать дальше. В SDK Flutter есть специальный режим компиляции машинного кода AOT, это даже не jit, а именно компиляция в нативный код со всеми сопутствующими оптимизациями, именно это подразумевается под по релиз-версией Flutter. Такой поддержки у нас в эмбеддере пока не было, добавляем.

Необходимы определенные инструкции, поданные аргументами к FlutterEngineRun

// полная реализация github.com/DEgITx/flutter_wayland/blob/master/src/elf.cc

vm_snapshot_instructions_ = dlsym(fd, "_kDartVmSnapshotInstructions");if (vm_snapshot_instructions_ == NULL) {  error_ = strerror(errno);  break;}vm_isolate_snapshot_instructions_ = dlsym(fd, "_kDartIsolateSnapshotInstructions");if (vm_isolate_snapshot_instructions_ == NULL) {  error_ = strerror(errno);  break;}vm_snapshot_data_ = dlsym(fd, "_kDartVmSnapshotData");if (vm_snapshot_data_ == NULL) {  error_ = strerror(errno);  break;}vm_isolate_snapshot_data_ = dlsym(fd, "_kDartIsolateSnapshotData");if (vm_isolate_snapshot_data_ == NULL) {  error_ = strerror(errno);  break;}

if (vm_snapshot_data_ == NULL || vm_snapshot_instructions_ == NULL || vm_isolate_snapshot_data_ == NULL || vm_isolate_snapshot_instructions_ == NULL) {  return false;}*vm_snapshot_data = reinterpret_cast <  const uint8_t * > (vm_snapshot_data_);*vm_snapshot_instructions = reinterpret_cast <  const uint8_t * > (vm_snapshot_instructions_);*vm_isolate_snapshot_data = reinterpret_cast <  const uint8_t * > (vm_isolate_snapshot_data_);*vm_isolate_snapshot_instructions = reinterpret_cast <  const uint8_t * > (vm_isolate_snapshot_instructions_);

FlutterProjectArgs args;// передаем все необходимое в argsargs.vm_snapshot_data = vm_snapshot_data;args.vm_snapshot_instructions = vm_snapshot_instructions;args.isolate_snapshot_data = vm_isolate_snapshot_data;args.isolate_snapshot_instructions = vm_isolate_snapshot_instructions;

Теперь, когда все есть, нужно собрать приложение особым образом, чтобы получить AOT-скомпилированный модуль под целевую платформу. Это можно сделать, выполнив команду из корня dart-проекта:

$HOST_ENGINE/dart-sdk/bin/dart \--disable-dart-dev \$HOST_ENGINE/gen/frontend_server.dart.snapshot \--sdk-root $DEVICE_ENGINE}/flutter_patched_sdk/ \--target=flutter \-Ddart.developer.causal_async_stacks=false \-Ddart.vm.profile=release \-Ddart.vm.product=release \--bytecode-options=source-positions \--aot \--tfa \--packages .packages \--output-dill build/tmp/app.dill \--depfile build/kernel_snapshot.d \package:lib/main.dart$DEVICE_ENGINE/gen_snapshot                               \    --deterministic                                             \    --snapshot_kind=app-aot-elf                                 \    --elf=build/lib/libapp.so                                   \    --no-causal-async-stacks                                    \    --lazy-async-stacks                                         \    build/tmp/app.dill

Не нужно пугаться огромного количества параметров, большинство из них является стандартными. В частности:

-Ddart.vm.profile=release \
-Ddart.vm.product=release \

указывают на то, что нам не нужен профайлер в комплекте и у нас продуктовая версия.

output-dill нужен для построения нативной библитеки libapp.so.

Самыми важными для нас являются пути $DEVICE_ENGINE и $HOST_ENGINE два собранных движка под целевую (ARM) и хост-системы (x86_64) соответственно. Тут важно ничего не перепутать и убедиться, что libapp.so получается именно 32-битной ARM-версией:

$ file libapp.so libapp.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked

Запускаем и-и-и-и... вуаля! все работает!

И работает шустрее значительно! Теперь уже можно говорить о сравнимой производительности и эффективности рендеринга с исходным приложением на базе набора библиотек EFL. Рендеринг работает почти без запинки и почти идеально на простых приложениях.

3. Подключение устройств ввода

В рамках этой статьи мы пропустим то, как подружили Wayland и эмбеддер с пультом, мышкой и другими устройствами ввода. На их реализацию можно посмотреть в исходниках эмбеддера.

4. Интерфейс на ТВ-приставке под Linux и Android и как увеличить производительность в 23 раза

Коснемся еще нескольких нюансов производительности, с которыми столкнулись в продуктовом UI-приложении. Нас очень обрадовала идентичность работы UI как на целевом устройстве, так и на Linux и Android. Уже сейчас Flutter может вполне может похвастаться очень гибкой портируемостью.

Еще отметим интересный опыт оптимизации самого dart-приложения под целевую платформу. Нас разочаровала довольно низкая производительность продуктового приложения (в отличии от демок). Мы взяли в руки профайлер и начали копать идовольно быстро обнаружили активное использование функций __brcm_cpu_dcache_flush и khrn_copy_8888_to_tf32 во время анимаций (на платформе используется чип процессора Broadcom/BCM ). Явно происходило какое-то очень жесткое пиксельное программное трансформирование или копирование во время анимаций. В итоге виновник был найден: в одной из панелей был задействован эффект размытия:

//...filter: new ImageFilter.blur(sigmaX: 10.0, sigmaY: 10.0),//...

Комментирование одного этого эффекта дало увеличение производительности приложения в дватри раза и вывело приложение на стабильные 50-60 fps. Это хороший пример того, как один специфический эффект может уничтожить производительность во всем приложении на Flutter при том, что он был зайствован всего-лишь в одной панели, которая большую часть времени была скрыта.

Итого

В результате мы получили не просто работающее продуктовое приложение, а работающее приложение с качественным фреймрейтом на Flutter на целевом устройстве. Форк и наша версия эмбеддера под RDK и другие платформы на основе Wayland находится тут: github.com/DEgITx/flutter_wayland

Надеемся, опыт нашей команды в разработке и портировании ПО для ТВ-приставок и Smart TV пригодится вам в своих проектах и послужит отправной точкой для портирования Flutter на других устройствах.

[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Алексей Касьянчук, наш инженер-программист

Вот уже несколько лет производители электроники говорят о новой прорывной технологии, которая изменит привычные нам устройства и подход к их проектированию: никаких больше механических кнопок и переключателей, сокращение толщины до 2 мм, снижение веса на 70%, а себестоимости на 30%. Причем речь идет не о будущих серийных устройствах типа экрана с двойным сложением, который недавно представила Samsung, а о технологии производства, которая уже сейчас используется в автомобилях, бытовой технике и IoT-гаджетах. Эта технология называется литье с интегрированной / встроенной электроникой или In-Mold Electronics (IME).

На Хабре эту интересную тему еще почему-то не затрагивали. Исправляем это досадное недоразумение.

Начнем со спойлера и сразу отметим, что литье со встроенной электроникой (IME) это не какая-то кардинально новая технология, а эволюция техпроцессов, которые уже использовались ранее. Появились более эластичные материалы и более качественные токопроводящие чернила, которые выдерживают формовку при высокой температуре, поэтому проводники, которые раньше покрывали печатную плату, теперь можно наносить прямо на пластиковый корпус электронного устройства. В результате мы избавляемся от жесткой печатной платы в формате 2D и переключаемся на пленочные платы и 3D-электронику с резисторами, микросхемами, сенсорами, антеннами и светодиодами, которые покрывают изогнутые формы корпусов самых разных устройств.

А теперь давайте обо всем по порядку. Литье с интегрированной электроникой это одно из направлений литья с декорированием в форме, о котором мы уже рассказывали на Хабре. В англоязычных инженерных публикациях такая технология называется In-Mold Decoration (IMD). Напомним, что корпус декорируется под давлением прямо в пресс-форме или в процессе выдувного формования.

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

Принцип маркировки в форме (In-Mold Labeling, IML) Источник: Maspi S.r.l.

На схеме выше показана суть технологий IMD и IML:

1. Сначала на тонкопленочный пластик наносят нужный рисунок текст, декор или текстуру (например, лого фирмы-изготовителя или подписи для кнопок). Это делается за счет трафаретной или цифровой печати. Получается так называемая аппликация.

2. Аппликацию помещают в пресс-форму для литья.

3. Затем в формовочную машину засыпают сухие гранулы полимера, который в расплавленном виде под давлением подается в пресс-форму за пленкой или перед ней.

4. Форма заполняется полимером, и печатная этикетка приклеивается к пластику.

5. На выходе при раскрытии формы мы получаем готовую деталь пластикового корпуса уже со встроенной графикой.

Технология декорирования в форме позволяет качественно реализовать идеи промышленных дизайнеров даже в конструкционно сложных пластмассовых компонентах. Детали получаются долговечными и устойчивыми к царапинам.

На фото выше верхняя панель пульта дистанционного управления, изготовленная с декорированием в форме (IMD). Другие всем знакомые примеры устройств, которые производятся по этой технологии: мультиметры, автомобильные панели, игрушки и мобильные телефоны.

В чем разница между декорированием в форме (IMD) и маркировкой в форме (IML)?

Если графика или текстура внутри пресс-формы наносится не на всю поверхность изделия от края до края, а локально, на отдельный участок, то такой тип декорирования называется маркировка в пресс-форме или In-Mold Labeling (IML). С помощью этой технологии можно добавлять цвет, графические элементы и текстурированные области.

IML часто используют для нанесения логотипов, предупреждающих знаков, иконок сертификатов, номеров деталей или мини-инструкций. Вы наверняка встречали такую маркировку на одноразовой упаковке и пластиковых контейнерах для домашнего использования.

И вот теперь мы возвращаемся литью с электроникой (In-Mold Electronics), которая стала логическим продолжением предыдущих двух технологий. Похоже, что первое коммерческое внедрение IME было реализовано в инновационной подвесной консоли для автомобиля Ford в 2012 году. Сегодня же IME применяется в производстве бытовой техники, автомобильных панелей, медицинского оборудования, аэрокосмической и носимой электроники.

Эта технология объединяет декоративную аппликацию из IMD-процесса с функциональной электроникой. Только в этом случае на пленке печатается не декор или текст, а дорожки проводников из токопроводящих серебряных красок, также на пленку можно добавлять резисторы, микросхемы и светодиоды. В результате в процессе формовки получаются пластиковые компоненты небольшой толщины (до 2 мм) с достаточной прочностью, высокой функциональностью, добавлением света, клавиатуры и декоративных элементов.

На схеме ниже показано, как это работает:

Источник изображения: Functional Ink Systems for In Mold Electronics by DuPont

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

2. Термоформование придает печатным носителям трехмерную форму, которая соответствует форме для литья под давлением.

3. Литье под давлением.

IME, как правило, термоформованные, но не всегда. В областях с сенсорным интерфейсом поверхность может остаться плоской.

Наметившаяся тенденция использование полиэтилентерефталата (PET), который не очень хорошо поддается формовке, но подходит для конструкций с меньшим радиусом кривизны. Однако ПЭТ не переносит сильного нагрева, поэтому сейчас разрабатываются низкотемпературные припои.

Пока эта технология еще воспринимается потребителями как новаторская, сами дорожки-проводники выглядят как элементы декора. :-) Со временем промдизайнеры и hardware-стартапы наверняка предложат свежие идеи по использованию возможностей такого литься.

Источник фото: аналитический отчет IDTechEx за 2020 год.

На фото выше серийные устройства и прототипы, созданные по технологии In-Mold Electronics.

Пример литой электроники чаще всего можно увидеть в новых автомобилях и бытовой технике, где форма электроники полностью соответствует кривым поверхностям задуманного дизайна.

В приборных панелях больше нет традиционных кнопок, датчиков и других функциональных переключателей. Вместо всего этого сенсорные визуальные интерфейсы. IME позволяет встроить освещение, разъемы, микросхемы или емкостное сенсорное покрытие в практически любую изогнутую деталь.

Формованные таким образом устройства и встроенная электроника выглядят красиво, они функциональны и надежны. Из-за многократного уменьшения деталей и подвижных компонентов сокращается не только риск поломок, но и затраты на производство, сборку и обслуживание.

Емкостное сенсорное управление и пользовательские интерфейсы

Технология емкостного сенсорного управления используется во многих приложениях IME. Такой интерфейс заменяет нажатие физической кнопки на прикосновение пальца. Дорожки на плате находятся под сенсорной точкой на панели и следят за изменением в электростатическом поле. Палец действует как функциональный конденсатор, который участвует в электрической цепи устройства. Например, в автомобиле, такие интерфейсы используются для включения фар, питания или регулировки громкости.

Вот, как американская химическая компания Dupont, один из мировых разработчиков токопроводящих чернил для IME, представляет в своей презентации интерфейсы для автомобилей настоящего и будущего:

Подводим итоги

Автопром это всего лишь одна из многих сфер применения IME, которые мы уже называли выше. Но давайте на ее примере рассмотрим реальный кейс. Возьмем потолочную консоль в автомобиле, которая была спроектирована с использованием печатной платы и классического пластикового корпуса, состоящего из десятков компонентов и сборных деталей, и сравним ее с консолью финской компании TactoTek, которая сейчас разрабатывает свою технологию in-mold structural electronics (IMSE):

Итого, мы получаем значительное уменьшение веса, габаритов, количества подвижных частей и, как следствие, надежности и себестоимости устройства в целом. Судя по активным разработкам в этой теме и отчетам аналитиков, которые прогнозируют рост внедрений IME, начиная с 20232024 года, на рынке электроники намечается новый тренд переход от печатных плат в коробке к трехмерной структурной электронике. Так что если ваша работа связана hardware, можно присмотреться к этому направлению и успеть попасть на гребень волны. Надеемся, что мы вскоре сможем поделиться с читателями Хабра собственными кейсами по разработкам и запуску производства литой электроники.

Если у вас есть опыт в этой сфере или идеи по внедрению IME в новых устройствах расскажите об этом в комментариях. Будет здорово, если к обсуждению подключатся инженеры, технологи, промдизайнеры и простые юзеры. Мы сейчас горим этой темой, так что с удовольствием пообщаемся.

В ИТ-сообществе слово аутсорсинг часто воспринимается как обидное. Руководители компаний и команд, которые занимаются заказной разработкой ПО или электроники, и сами разработчики предпочитают не называть себя аутсорсерами. Даже из моих предыдущих статей об инженерных командах и их пути могло показаться, что я против этой бизнес-модели. Так что давайте разберемся, почему аутсорсинг стал для нас инженеров из Беларуси, Украины и России важной школой, и почему лидеры ИТ-рынка больше не хотят называть себя этим словом.

Сразу отмечу свое отношение к термину аутсорсинг: мне нравится эта бизнес-модель, я много лет строил компанию в сфере заказной разработки электроники и встроенного ПО, а сейчас трансформирую бизнес в этой сфере.

Более того, я уверен, что аутсорсинг сыграл ключевую роль в развитии ИТ-сектора в наших странах. Если аллегорически сравнить его с высшим образованием, то можно сказать, что это отличная бизнес-модель для обучения большого количества специалистов с оплатой в процессе обучения. Сначала надо пройти путь абитуриента и сдать экзамен на первый контракт. Потом побыть студентом, где тебе будут платить небольшую стипендию это период, когда молодая аутсорсинговая компания получает контракты, позволяющие держать на плаву небольшую команду. Затем появляются несколько клиентов и, возможно, один-два ключевых. Ключевой клиент как профессор в магистратуре или аспирантуре. Аспирант обслуживает интересы профессора в обмен на обучение. Профессор, т.е. зарубежный клиент, получает всю славу, результат и вполне солидные деньги за проект, который был создан при поддержке аспирантов.

Студентам дают стипендию. В аутсорсинге примерно также тебе дают деньги на жизнь, пока ты учишься на первых клиентских проектах

Кто и чему учится в рамках аутсорсинговой бизнес-модели:

• Основатели и менеджеры бизнесу и управлению.

• Инженеры разработке и инженерной культуре.

• Продавцы длинным и сложным B2B-продажам, где нужно вырабатывать доверие, продавая воздух.

Представьте, как долго мы выходцы из постсоветских стран проходили бы этот путь, если бы такая бизнес-модель как аутсорсинг в мире не существовала? Ведь она позволила нам получить и накопить интеллектуальный и денежный капитал. В 90-х и нулевых мы только стартовали. В 2010-х те, кто заработал капитал, инвестировали в собственный бизнес. А сегодня предприниматели с 2030 летним опытом готовы инвестировать в сторонние компании и передавать знания новому поколению.

После развала Союза у нас не было опыта в бизнесе, не хватало инженерных знаний всё это мы получили во многом благодаря аутсорсингу!

Заказные разработки позволили нам получить сегодняшних специалистов, часть из которых перешла в продуктовые компании. И теперь вопрос: как быть дальше? Как поднять эффективность своей работы и всей отрасли? Очевидно, что аутсорсинг это одна из ступеней в развитии отрасли. Те игроки рынка, которые уже прошли эту школу, могут отправляться в свободное плавание. Мы это видим на примере компаний, которые занимались аутсорсингом, а сейчас имеют продуктово-сервисные модели.

Тот же EPAM, который некоторые до сих пор по-привычке считают аутсорсинговой компанией, уже давно совершил разворот к сервисно-инжиниринговой модели. Как пишут Ведомости, если до 2005 г. около 80% заказов этой компании приходилось на аутсорсинг в разработке продуктов для технологических компаний, то сейчас на подобные заказы приходится около 20%. Сам Аркадий Добкин, основатель EPAM, так объясняет этот термин в прошлогоднем интервью журналу Большой:

Аутсорсинг это бизнес-практика, когда работа, которая раньше производилась внутри компании ее собственными сотрудниками, отдается внешним компаниям с целью сокращения расходов или высвобождения ресурсов для других более важных функций. Так начиналась офшорная индустрия в Индии. Туда передавалась много работы по поддержанию систем, которые до того выполнялись внутри компаний Нет ничего предосудительного в аутсорсинговой модели, это очень важный компонент глобального бизнеса.

Вполне понятно, почему зрелые компании стремятся уйти от этой модели и переключиться на позиционирование в качестве инжиниринговой компании с уникальной экспертизой. Но для этого требуется время, поэтому часть новых игроков на рынке будут по-прежнему выбирать аутсорсинг, чтобы за несколько лет получить нужный опыт и накопить стартовый капитал я уже писал о таком пути в прошлой статье на Хабре. Но чем более зрелой будет отрасль, чем более сильной и открытой будут экономика нашей страны, в которой работает компания, тем активнее долю аутсорсинговых компаний будут замещать инжиниринговые и продуктовые. Но у нас впереди еще долгий путь в этом направлении. В следующей статье я даже рискну предположить сколько лет займет такой путь.

Посмотрите сами: где была бы Индия со своим ИТ и где был бы Китай со своим производством, если бы не заказные проекты зарубежных заказчиков?

Зрелость индустрии соответствует зрелости государства и общества. Поэтому логично, что на данном этапе мы (IT-компании в Беларуси) занимаемся аутсорсингом, как и наши соседи в Украине, России, Болгарии, Молдове и т.д. Даже Польша, Чехия, Литва и Румыния все еще входят в список стран для ИТ-аутсорсинга, хотя там ситуация постепенно меняется. А в таких странах как Дания и Германия структура бизнес-моделей и компаний уже совсем другая. Это положение дел обусловлено стоимостью оплаты труда, индексом экономического развития и другими параметрами, поэтому не стоит думать, что мы все-еще занимаемся аутсорсингом, потому что кого-то из наших инженеров несправедливо недооценили.

Со временем мы придем другому балансу в ИТ-отрасли: по мере развития отрасли и роста экономического уровня будет все больше продуктовых и инжиниринговых компаний в противовес аутсорсинговым.

Почему в Германии много продуктовых компаний? Потому что там есть не только стартапы, но и инвесторы. Почему у нас рождаются единицы сильных стартапов, а в европеских странах сотни? Это только кажется, что везде есть фонды и везде есть классные инженеры. Бизнес-ангелы у нас в Беларуси только-только появились, они вкладывают скрепя зубами несколько десятков тысяч долларов по небольшой оценке, иногда забирая большую долю в стартапах, демотивируя этим фаундеров. Поэтому инженерные команды, которые делают свой продукт или запускают корпоративный спин-офф, предпочитают воспользоваться зарубежными институтами финансирования и поддержки инноваций, они переезжают в ЕС, чтобы быть ближе к развитым бизнес-экосистемам и быстрее достигать свои цели.

Трансформация аутсорсинга

Но и аутсорсинг как бизнес-модель не стоит на месте, она трансформируется под давлением рынка вместе с прочими моделями. Какие у нас есть варианты для трансформации? Во-первых, важно понять, что на пути между аутсорсер и продуктовая компания есть промежуточные гибридные модели. Во-вторых, мы можем посмотреть на опыт компаний в развитых экономиках Западной Европы, где заказная разработка тоже имеет место в Германии, Дании и Финляндии успешно работают инженерные сервисные компании, которые зарабатывают отнюдь не на ценовых преимуществах. А на чем же?

Давайте рассмотрим, в какие бизнес-модели они используют:

1. Свой продукт + доп. услуги по разработке. Если компания, к примеру, продает собственные процессорные модули, ее экономика формируется за счет продуктов, но при этом она генерирует дополнительную прибыль за счет дозагрузки инженеров на заказных разработках для своих клиентов.

2. Сервисная компания + доп. платформы / решения. Когда экономика компании формируется за счет заказных разработок или инженерного сервиса, она не может обеспечить себе высокую маржинальность в странах с развитой экономикой из-за высокой стоимости рабочего времени инженеров. В этом случае компании выгодно обеспечивать дополнительный поток прибыли за счет допродажи собственных готовых решений и платформ для решения задач своих клиентов в конкретных индустриях.

3. Сервисная компания + аутсорсинг. Компании в Западной Европе, которые занимаются заказной разработкой или инженерным сервисом, позволяют своим клиентам быстро подключить к проекту нужных инженеров, не нанимая их в штат. Заказчик таким образом снимает с себя задачу найма узких специалистов и бремя социальных выплат на штатных работников. При этом часть задач сервисная компания передает на аутсорсинг в Восточную Европу так они снижают затраты.

Как на это смотрят сами руководители компаний из Западной Европы? Мой коллега Зоран Вельковски, основатель датской инжиниринговой компании TekPartner, так прокомментировал перспективы сотрудничества в отрасли:

Для разработки электронных продуктов в эпоху интернета вещей, периферийных вычислений и машинного обучения требуются мультидисциплинарные команды с широким набором навыков.

Только компании с огромным бюджетом на НИОКР, такие как Apple, Tesla, Microsoft и Google, могут позволить себе полную вертикальную интеграцию. Всем остальным нужна внешняя помощь, т.е. аутсорсинг всех видов деятельности, которые не относятся к основной компетенции компании.

Поэтому более дешевые инженеры из Восточной Европы это не главное преимущество аутсорсинга для заказчика. Для него важна ориентация команды на основной бизнес, получение доступа к высококлассным технологиям/компетенциям, сокращение расходов в том числе, более быстрый выход на рынок, снижение рисков, улучшение конкурентных преимуществ.

Те компании, которые это понимают, уже сейчас повышают свою эффективность и работают с гибридными моделями, потому что на одной только разнице в оплате труда инженеров невозможно продержаться в долгосрочной перспективе.

В Беларуси, к примеру, уже была возможность за 1015 лет реализовать свою среднесрочную ИТ-стратегию в Парке высоких технологий (ПВТ), воспользовавшись специальным налоговым режимом и более низким уровнем жизни, чем в ЕС и США. В краткосрочной и среднесрочной перспективе это были правильные действия. Но дальше нужна трансформация и выбор проактивной позиции: мы можем использовать опыт европейских сервисных компаний и заниматься высокооплачиваемым инженерным сервисом, добавляя исследовательскую и интеграционную составляющую, обеспечив свою географическую близость к клиенту и более глубокое понимание его рынка.

Эта трансформация переключит нас с позиции я делаю то, что умею на я делаю то, что нужно клиенту, предлагая множество дополнительных и достаточно дорогих функций по сдаче проекта (delivery).

Ведь что такое сдача проекта delivery? Наш классический проджект-менеджер это не деливери-менеджер, потому что он, как правило, не обеспечивает бесшовную интеграцию проекта в бизнес клиента. Живой пример из нашей компании: мы в Promwad разработали для своего клиента ТВ-приставку в рамках проекта за несколько десятков тысяч долларов, а на этапе delivery ценность наших услуг и бюджет проекта исчислялся уже в сотнях тысяч долларов. Мы интегрировали свою разработку в цепочку поставок клиента: поставили приставку на серийное производство в оптимальной для клиента локации, запускали там автоматизированное тестирование и дописывали ПО. Но это случилось, потому что мы стремились увеличить свое участие в бизнесе клиента, действовали проактивно.

Рецепты

Итого, основываясь на словах своих коллег и опыте компаний с Запада, вот что можно сделать после инженерной школы, которой для нас стал аутсорсинг:

1. Расти за счет дорогих сервисов и большей маржинальности, но для этого нужно слышать клиента и быть к нему ближе географически за счет локальных офисов в ЕС и США.

2. Дополнять свои услуги продуктами / платформами / решениями.

3. Продолжать развивать аутсорсинг, но при этом быть готовым к резкому изменению ландшафта, т.е. условий для ведения подобного бизнеса в наших странах.

При этом, как видите, вы не становитесь продуктовой компанией. Ведь мы тут не обсуждаем жесткий разворот в продуктовую стратегию.

Рынок со временем все расставит на свои места. Даже пассивные компании с устаревшими бизнес-моделями будут вынуждены трансформироваться. Но куда интереснее, хотя, конечно, труднее и рискованнее действовать проактивно и самому пойти в новые бизнес-модели, опередив своих более капиталоемких соседей по отрасли! У аутсорсинга в истории ИТ-сектора в Восточной Европе большая роль и большая история, но уже сейчас пришло время наращивать свою ценность для мира: преобразовать свои знания в мировое признание, обеспечивать бОльшую добавленную стоимость и потянуть вслед за собой за собой тех, кто эту инженерную школу только проходит.

В этой статье я Роман Пахолков, основатель Promwad, поделился ключевыми выводами, которые подтолкнули меня к созданию новой стратегии для собственной компании к специализации на конкретных индустриях и развитию лидеров направлений в нашей инженерной команде. Более того, мы даже запустили целое отраслевое сообщество Hardware Ecosystem для всех, кто работает в сфере электроники. Там есть и подмастерья-студенты, и профессора. Верю, что объединившись, мы сможем достичь большего.

А в какой модели сейчас находитесь вы сами? И как вы видите трансформацию своего бизнеса или компании, в которой работаете? Поделитесь своими мыслями в комментариях, а я буду рад ответить на ваши вопросы и рассказать о собственном опыте.

Два года назад основатель нашей компании Роман Пахолков создал открытое сообщество для всех, что работает в hardware, развивает свои проекты и готов делиться опытом. Всё начиналось с небольшой LinkedIn-группы, а потом переросло серию подкастов и митапов с инженерами и руководителями компаний, которые успешно вышли на рынок электроники со своими продуктами.

В этой статье мы объясним, чем Hardware Ecosystem полезна для участников. А если захотите познакомиться с этим сообществом поближе, это можно сделать на ближайшей неделе утром в субботу, 10 октября. В этот день в Минске состоится митап, посвященный беспилотным технологиям и примерам их внедрения на земле и ввоздухе. Так что если вы не равнодушны к хардверу, дронам и автономным автомобилям, присоединяйтесь онлайн или приходите лично.

В этот раз событие будет международным, с участием докладчиков из Беларуси, России, ЕС и Китая. Запланированы презентации стартапов Aorion и Crop Fleet, совместный доклад корпораций Arrow и Analog Devices, выступления экспертов Solar LS и международной китайской корпорации Интеллектуальные технологии. Также к нам присоединится российская компания Starline, которая занимается разработкой беспилотных автомобилей.

Итак, зачем и для кого было создано сообщество Hardware Ecosystem?

У нас на рынке high-tech и электроники есть отдельные элементы экосистемы: стартапы, инвестиционные компании, ассоциация приборостроителей, университеты, научные организации, где работают инженеры. Но эти элементы работают сами по себе, связи между ними пока слишком слабые или их нет вовсе. Такое случается в незрелой бизнес-экосистеме: участники не сразу объединяются и начинают работать на общие цели.

Конечно, мировой опыт вдохновляет на то, чтобы пробежать эту дорогу быстро. У каждой страны и каждой экосистемы свой путь, и она уникальна. И это хорошо, мы разные и можем дополнять друг друга.

У наших инженеров есть шансы в определенных отраслях, которые связаны с hardware. Например, в медицинской технике, в IoT на стыке software и hardware, в беспилотных технологиях (собственно поэтому предстоящий митап и посвящен этой теме).

Живой пример: инженерная аутсорсинговая прослойка из Парка высоких технологий в Минске дает большой поток крутых разработчиков, которые пользуясь элементами экосистемы, могут создавать свое IP, решать проблемы мировых рынков, соединять решения hardware и software вместе.

За два года к сообществу Hardware Ecosystem присоединилось более 650 участников из разных стран инженеров, владельцев и менеджеров ИТ-компаний, инвесторов, руководителей тех. хабов и акселераторов. Они делились опытом в группе на LinkedIn и встречались на митапах, а в начале 2020 года из-за COVID-19 ушли в онлайн: так и появился новый подкаст и ютуб-канал c видеозаписями прошлогодних митапов про IoT, MedTech и о том, как инженеру вывести свой продукт на рынок.

И вот сейчас, при поддержке hardware-акселератора Bridgio, сообщество возвращается к формату личных встреч: в Минске, на площадке SUP, 10 октября пройдет митап Беспилотники на земле и в воздухе: бизнес-кейсы стартапов и корпораций. Впервые будет организована онлайн-трансляция встречи для русскоязычных инженеров из других городов и стран. Участники митапа из первых уст узнают о бизнес-проблемах, которые решают мировые корпоративные игроки, как проходят R&D мирового уровня. В ходе встречи организаторы постараются определить возможные варианты кооперации между инженерными командами и международными компаниями.

Если вы болеете за hardware и беспилотные технологии присоединяйтесь!

Два года назад основатель нашей компании Роман Пахолков создал открытое сообщество для всех, что работает в hardware, развивает свои проекты и готов делиться опытом. Всё начиналось с небольшой LinkedIn-группы, а потом переросло серию подкастов и митапов с инженерами и руководителями компаний, которые успешно вышли на рынок электроники со своими продуктами.

В этой статье мы объясним, чем Hardware Ecosystem полезна для участников. А если захотите познакомиться с этим сообществом поближе, это можно сделать на ближайшей неделе утром в субботу, 10 октября. В этот день в Минске состоится митап, посвященный беспилотным технологиям и примерам их внедрения на земле и ввоздухе. Так что если вы не равнодушны к хардверу, дронам и автономным автомобилям, присоединяйтесь онлайн или приходите лично.

В этот раз событие будет международным, с участием докладчиков из Беларуси, России, ЕС и Китая. Запланированы презентации стартапов Aorion и Crop Fleet, совместный доклад корпораций Arrow и Analog Devices, выступления экспертов Solar LS и международной китайской корпорации Интеллектуальные технологии. Также к нам присоединится российская компания Starline, которая занимается разработкой беспилотных автомобилей.

Итак, зачем и для кого было создано сообщество Hardware Ecosystem?

У нас на рынке high-tech и электроники есть отдельные элементы экосистемы: стартапы, инвестиционные компании, ассоциация приборостроителей, университеты, научные организации, где работают инженеры. Но эти элементы работают сами по себе, связи между ними пока слишком слабые или их нет вовсе. Такое случается в незрелой бизнес-экосистеме: участники не сразу объединяются и начинают работать на общие цели.

Конечно, мировой опыт вдохновляет на то, чтобы пробежать эту дорогу быстро. У каждой страны и каждой экосистемы свой путь, и она уникальна. И это хорошо, мы разные и можем дополнять друг друга.

У наших инженеров есть шансы в определенных отраслях, которые связаны с hardware. Например, в медицинской технике, в IoT на стыке software и hardware, в беспилотных технологиях (собственно поэтому предстоящий митап и посвящен этой теме).

Живой пример: инженерная аутсорсинговая прослойка из Парка высоких технологий в Минске дает большой поток крутых разработчиков, которые пользуясь элементами экосистемы, могут создавать свое IP, решать проблемы мировых рынков, соединять решения hardware и software вместе.

За два года к сообществу Hardware Ecosystem присоединилось более 650 участников из разных стран инженеров, владельцев и менеджеров ИТ-компаний, инвесторов, руководителей тех. хабов и акселераторов. Они делились опытом в группе на LinkedIn и встречались на митапах, а в начале 2020 года из-за COVID-19 ушли в онлайн: так и появился новый подкаст и ютуб-канал c видеозаписями прошлогодних митапов про IoT, MedTech и о том, как инженеру вывести свой продукт на рынок.

И вот сейчас, при поддержке hardware-акселератора Bridgio, сообщество возвращается к формату личных встреч: в Минске, на площадке SUP, 10 октября пройдет митап Беспилотники на земле и в воздухе: бизнес-кейсы стартапов и корпораций. Впервые будет организована онлайн-трансляция встречи для русскоязычных инженеров из других городов и стран. Участники митапа из первых уст узнают о бизнес-проблемах, которые решают мировые корпоративные игроки, как проходят R&D мирового уровня. В ходе встречи организаторы постараются определить возможные варианты кооперации между инженерными командами и международными компаниями.

Если вы болеете за hardware и беспилотные технологии присоединяйтесь!

Пандемия COVID-19 стала катализатором для новых полезных сервисов. Например, Zoom стал настолько успешным, что по стоимости обогнал в этом месяце IBM. Нас вдохновил этот пример, и мы решили пойти еще дальше: а что если онлайн-конференции реализовать на приставках и Smart TV, чтобы общаться не только по работе, но устраивать удаленные посиделки на диване с друзьями? Но ведь тогда можно на футболе вместе покричать, и кино посмотреть или спортом заняться под контролем тренера.

Почему-то у операторов цифрового ТВ такой услуги не оказалось, хотя с инженерной точки зрения все эти функции вполне можно реализовать на ТВ-приставках на базе Linux/Android и RDK. Мы это проверили на практике и вот теперь делимся с читателями Хабра своим рецептом создания аналога Zoom и видеоконференций через Smart TV. Разберем архитектуру решения и кодирование видеопотока с использованием GStreamer. Информацию для работы с этим фреймворком мы собирали по крупицам, но оно того стоило.

Разбираемся с архитектурой

При разработке архитектуры приложений для ТВ-приставок важно учитывать потенциальные ограничения программной и аппаратной части этих устройств. Те, кто создает desktop-программы, как правило, не сталкиваются с этими сложностями, а для embedded-разработчиков это обычное дело.

Итак, с чем мы столкнемся на ТВ-приставках:

1. Ограниченность ресурсов процессоров и самих приставок. Чаще всего в STB-устройствах используются разнообразные ARM-процессоры, они несут в себя ряд ограничений и дополнительных задач, в частности необходимость использования аппаратного кодирования/декодирование видеопотока. Всегда нужно учитывать, что быстродействие одно из узких мест.

2. Разность архитектур в приставках разных производителей. Некоторые базируются на Android, другие на RDK, третьи на дистрибутивах на базе Linux со своими ограничениями и нюансами. Поэтому на старте разработки лучше выбрать наиболее общие и кроссплатформенные решения в разных модулях программы. Уже не говоря о поддержке desktop-версии. А уже потом переходить к частным случаям.

3. Сетевые ограничения. Многие приставки работают как по Ethernet так и по wifi. Сжатие и передача видео/аудиопотока еще одно узкое место в приложениях такого рода.

4. Безопасность передачи потока и др. вопросы безопасности данных.

5. Поддержка камер и микрофонов на встроенных платформах.

Теперь можно разложить по полочкам и саму архитектуру. Аналог Zoom для ТВ-приставок будет состоять из нескольких больших компонентов и модулей:

• Захват видеопотока

• Захват аудиопотока

• Сетевой модуль

• Модуль кодирования видео/аудиопотока

• Модуль декодирования видео/аудиопотока

• Вывод видеоконференции на экран

• Вывод звука

• Цветовые преобразования

• Несколько других второстепенных компонентов

В упрощенном виде один из вариантов архитектуры можно изобразить так:

В рамках статьи мы сфокусируемся на кодировании декодирования видеопотока и на возможной реализации с использованием фреймворка GStreamer, т.к. это один из ключевых моментов в разработке приложений для видеоконференций.

Кодирование/декодирование потока

1) Преимущества GStreamer

Как мы уже отметили, одним из узких мест является передача видеопотока. Предположим у вас есть камера, отдающие кадры на скорости 30 кадров с секунду на небольшом разрешении 640x480. Итого, в RGB24 получается:

640 х 480 х 3 х 30 = 27 648 000 байт в секунду, т.е. более 26 Мбайт в секунду, что по понятным причинам совершенно неприемлемо в рамках сетевой передачи.

Один из вариантов решения реализовать кодирование какой-нибудь библиотекой. И тут, как можно уже было догадаться из названия статьи, выбор пал на фреймворк GStreamer. Почему именно эта библиотека? Вот несколько ее преимуществ на фоне остальных решений:

1. Хорошая кроссплатформенность и отличная поддержка Linux и Android.

2. На RDK Gstreamer является стандартом кодирования/декодирования и включен в дистрибутив по-умолчанию.

3. Поддержках широкого набора модулей, фильтров и кодеков. Тот же FFmpeg, который можно использовать для тех же целей, де-факто является лишь одним из модулей GStreamerа.

4. Простота построения конвейера (pipeline). Выстроить цепочку кодирования/декодирования не составляет большого труда, а сам подход конвейера позволяет легко заменять кодеки, фильтры и прочее без лишнего переписывания кода.

5. API для работы С/C++ идет комплекте.

6. Поддержка аппаратных кодеров/декодеров, в частности OpenMAX API что крайне важно при работе с ТВ-приставками.

2) Знакомимся с GStreamer разбираемся с конвейерами

Прежде чем приступать к рассмотрению кода, давайте разберемся с тем, что можно делать пока и без него. В состав GStreamer входят полезные утилиты для работы, в частности:

gst-inspect-1.0 позволит посмотреть список доступных кодеков и модулей, так что можно сразу увидеть, что будет работать, и выбрать набор фильтров и кодеков.

gst-launch-1.0 позволяет запустить любой конвейер (pipeline).

В GStreamer используется схема декодирования, по которой поток последовательно проходит через разные компоненты, начиная с source, заканчивая sink-выводом. При этом source может быть любым файл, устройство, для вывода (sink) также можно указать нужное файл, экран, сетевые выводы и протоколы (наподобие RTP).

Подробнее про использование утилит и принцип построения конвейера можно почитать в другой статье на Хабре. Классический пример проигрывания mp4-файла:

gst-launch-1.0 filesrc location=file.mp4 ! qtdemux ! h264parse ! avdec_h264 ! videoconvert ! autovideosink

На входе принимается mp4-файл, который проходит через демуксер mp4 qtdemux, парсер h264, затем через декодер, конвертер и, наконец, идет вывод на экран.

Можно заменить autovideosink на filesink с параметром файла и вывести декодированный поток прямиком в файл.

3) Пишем приложение на GStreamer C/C++ API. Попробуем декодировать

Теперь, когда мы разобрались немного с использованием gst-launch-1.0, проделаем все тоже самое, только уже в рамках приложения. Принцип останется тем же: мы встраиваем декодирующий конвейер (pipeline), однако уже с использованием библиотеки GStreamer и glib-событий.

О простейшем примере построения filesrc в filesink с кодом хорошо рассказано в другой хабрастатье GStreamer: элементы и контейнеры. Мы же рассмотрим чуть более реалистичный и сложный живой пример H264-декодирования.

Инициализация GStreamer-приложения происходит один раз при помощи

gstinit (NULL, NULL);

Если вы хотите сразу видеть происходящее в деталях, можно выстроить уровень логирования перед инициализацией

gst_debug_set_active(TRUE);gst_debug_set_default_threshold(GST_LEVEL_LOG);

Учтите: сколько бы у вас не было конвейеров в приложении, инициализировать gstinit достаточно один раз.

Создадим новый event-loop, в котором будут обрабатываться события:

GMainLoop *loop;loop = g_main_loop_new (NULL, FALSE);

И теперь можно начать выстраивать наш конвейер:

Объявим необходимые элементы, в частности сам конвейер как тип GstElement:

GstElement *pipeline, *source, *demuxer, *parser, *decoder, *conv, *sink;pipeline = gst_pipeline_new ("video-decoder");source   = gst_element_factory_make ("filesrc",       "file-source");demuxer  = gst_element_factory_make ("qtdemux",      "h264-demuxer");parser   = gst_element_factory_make ("h264parse",      "h264-parser");decoder  = gst_element_factory_make ("avdec_h264",     "h264-decoder");conv     = gst_element_factory_make ("videoconvert",  "converter");sink     = gst_element_factory_make ("appsink", "video-output");

Каждый элемент конвейера создается через gst_element_factory_make, где первым параметром идет тип, а вторым его условное название для GStreamer, на которое он впоследствии будет опираться, например при выдаче ошибок.

Также не мешало бы проверить, что все компоненты найдены, в противном случае gst_element_factory_make, возвращает NULL.

if (!pipeline || !source || !demuxer || !parser || !decoder || !conv || !sink) {// не инициализирован один элемент - остановкаreturn;}

Установим тот самый параметр location через gob_ject_set:

gob_ject_set (G_OBJECT (source), "location", argv[1], NULL);

Остальные параметры в других элементах можно выставлять аналогичным образом.

Теперь необходим обработчик сообщений GStreamer, создадим соответствующий bus_call:

GstBus *bus;guint bus_watch_id;bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));bus_watch_id = gst_bus_add_watch (bus, bus_call, loop);gst_object_unref (bus);

gst_object_unref и другие подобные вызовы нужны для очищения выделенных объектов.

Затем объявим сам обработчик сообщений:

static gbooleanbus_call (GstBus     *bus,          GstMessage *msg,          gpointer    data){  GMainLoop *loop = (GMainLoop *) data;  switch (GST_MESSAGE_TYPE (msg)) {    case GST_MESSAGE_EOS:      LOGI ("End of stream\n");      g_main_loop_quit (loop);      break;    case GST_MESSAGE_ERROR: {      gchar  *debug;      GError *error;      gst_message_parse_error (msg, &error, &debug);      g_free (debug);      LOGE ("Error: %s\n", error->message);      g_error_free (error);      g_main_loop_quit (loop);      break;    }    default:      break;  }  return TRUE;}

А теперь самое важное: собираем и добавляем все созданные элементы в единый конвейер, тот самый что выстраивали через gst-launch. Очередность добавления, естественно, важна:

gst_bin_add_many (GST_BIN (pipeline), source, demuxer, parser, decoder, conv, sink, NULL);gst_element_link_many (source, demuxer, parser, decoder, conv, sink, NULL);

Стоит также заметить, что такой подход линковки элементов прекрасно работает для потоковых выходов, но в случае именно проигрывания (autovideosink) необходима дополнительная синхронизация и динамическая линковка демуксера и парсера:

  gst_element_link (source, demuxer);  gst_element_link_many (parser, decoder, conv, sink, NULL);  g_signal_connect (demuxer, "pad-added", G_CALLBACK (on_pad_added), parser);static voidon_pad_added (GstElement *element,              GstPad     *pad,              gpointer    data){  GstPad *sinkpad;  GstElement *decoder = (GstElement *) data;  /* We can now link this pad with the sink pad */  g_print ("Dynamic pad created, linking demuxer/decoder\n");  sinkpad = gst_element_get_static_pad (decoder, "sink");  gst_pad_link (pad, sinkpad);  gst_object_unref (sinkpad);}

Динамическое соединение дает возможность определения типа и количества потоков в отличии от статического, и будет работать в некоторых случаях когда это требуется.

Ну и, наконец, переводим состояние конвейера в проигрывание:

gst_element_set_state (pipeline, GST_STATE_PLAYING);

И запускаем event-loop:

g_main_loop_run (loop);

После окончания этой процедуры все нужно почистить:

gst_element_set_state (pipeline, GST_STATE_NULL);  gst_object_unref (GST_OBJECT (pipeline));  g_source_remove (bus_watch_id);  g_main_loop_unref (loop);

4) Выбираем энкодеры и декодеры. Фоллбэки

Стоит еще рассказать о полезных, но не особо упомянутых вещах в документации о том, как можно легко организовать фоллбэк декодеров или энкодеров.

Поможет нам в этом функция gst_element_factory_find, которая проверяет, есть ли у нас кодек в factory элементов:

if(gst_element_factory_find("omxh264dec"))decoder  = gst_element_factory_make ("omxh264dec",     "h264-decoder");elsedecoder  = gst_element_factory_make ("avdec_h264",     "h264-decoder");

В данном примере мы приоритезировали выбор аппаратного декорера OMX на платформе RDK, и в случае его отсутствия будем выбирать программную реализацию.

Другой крайне полезной, но еще более редко используемой функцией является проверка того, что же мы на самом деле инициализировали в GstElement (какой кодек):

gst_plugin_feature_get_name(gst_element_get_factory(encoder))

Можно проделать это таким незамысловатым способом и вернуть название инициализированного кодека.

5) Цветовые модели видео

Не стоит оставлять без внимания и цветовые модели, раз уж мы заговорили о кодировании видео с камер. И тут чаще подразумевается YUV, нежели RGB.

Камеры просто обожают цветовую модель YUYV. Но это то, с чем любит работать GStreamer, для него более привычна модель I420. На выходе, если речь не идет о выводе в gl-фрейм, у нас также будут выходить I420-кадры. Будьте готовы подставить необходимые фильтры и выполнить преобразования. Некоторые энкодеры умеют работать и с другими цветовыми моделями, но чаще это исключения из правил.

Еще стоит заметить что у GStreamerа есть свой модуль получения видеопотока с камеры, и его можно использовать для построения конвейера, но об этом расскажем как-нибудь в другой раз.

Разбираемся с буферами и берем данные на лету

1) Буфер ввода

Пришло время разобраться с потоками данных. До этого момента мы просто кодировали то, что есть в файле, через filesrc и выводили все в тот же filesink или на экран.

Теперь будем работать с буферами и входами и выходами appsrc / appsink. Почему-то этому вопросу почти не уделиливнимания в официальной документации.

Как же организовать постоянный поток данных в созданных конвейерах, а точнее подать буфер на выход и получить кодированный или декодированный буфер выхода? Допустим мы получили картинку с камеры, и нам нужно ее закодировать. Мы уже определились с тем, что нам потребуется фрейм в I420. Допустим он у нас есть, что дальше? Как пропустить картинку через весь поток конвейера?

Вначале установим обработчик события need-data, который будет запускаться при необходимости подачи данных в конвейер и начнем подавать входной буфер:

g_signal_connect (source, "need-data", G_CALLBACK (encoder_cb_need_data), NULL);

Сам обработчик имеет следующий вид:

encoder_cb_need_data (GstElement *appsrc,          guint       unused_size,          gpointer    user_data){  GstBuffer *buffer;  GstFlowReturn ret;  GstMapInfo map;   int size;   uint8_t* image;  // get image  buffer = gst_buffer_new_allocate (NULL, size, NULL);  gst_buffer_map (buffer, &map, GST_MAP_WRITE);    memcpy((guchar *)map.data, image,  gst_buffer_get_size( buffer ) );  gst_buffer_unmap(buffer, &map);  g_signal_emit_by_name (appsrc, "push-buffer", buffer, &ret);  gst_buffer_unref(buffer);}

image это, условно говоря, псевдокод буфера картинки в I420.

Далее мы создаем через gst_buffer_new_allocate буфер необходимого размера, который будет соответствовать размеру буфера картинки.

При помощи gst_buffer_map устанавливаем буфер в режим записи и, используя memcpy, копируем нашу картинку в созданный буфер.

И, наконец, сигнализируем GStreamу о том, что буфер готов.

Ремарка: очень важно после записи использовать gst_buffer_unmap, а также очищать буфер после использования при помощи gst_buffer_unref. Иначе будет утечка памяти. В скудном количестве доступных примеров никто особо насчет вопроса освобождения памяти не заморачивался, а он, понятное дело, важный.

Теперь, когда мы закончили с обработчиком, нужно проделать еще одну вещь: настроить caps на поступление ожидаемого формата.

Делается это перед установкой обработчика сигнала need-data:

g_object_set (G_OBJECT (source),        "stream-type", 0,        "format", GST_FORMAT_TIME, NULL);g_object_set (G_OBJECT (source), "caps",gst_caps_new_simple ("video/x-raw","format", G_TYPE_STRING, "I420","width", G_TYPE_INT, 640,"height", G_TYPE_INT, 480,"framerate", GST_TYPE_FRACTION, 30, 1,NULL), NULL);

Как и все параметры GstElement, установка параметров осуществляется через g_object_set.

В данном случае мы задали тип потока, и его caps формат данных. Указав, что на выход appsrc будет поступать данные I420 c разрешением 640x480 и частотой 30 кадров в секунду.

Частота в нашем случае, да в целом, не играет роли. На практике мы не замечали, чтобы GStreamer как-то ограничивал вызовы need-data по частоте.

Готово, теперь наши кадры поступают в энкодер.

2) Буфер вывода

А теперь разберемся, как получить кодированный поток на выходе.

Подключаем обработчик к sink pad:

GstPad *pad = gst_element_get_static_pad (sink, "sink");  gst_pad_add_probe  (pad, GST_PAD_PROBE_TYPE_BUFFER, encoder_cb_have_data, NULL, NULL);  gst_object_unref (pad);

Похожим образом мы подключились к другому событию sink pad GST_PAD_PROBE_TYPE_BUFFER, которое будет вызываться по мере поступления буфера данных в sink pad.

static GstPadProbeReturnencoder_cb_have_data (GstPad * pad,                        GstPadProbeInfo * info,                        gpointer user_data) {  GstBuffer *buf = gst_pad_probe_info_get_buffer (info);  GstMemory *bufMem = gst_buffer_get_memory(buf, 0);  GstMapInfo bufInfo;  gst_memory_map(bufMem, &bufInfo, GST_MAP_READ);  // bufInfo.data, bufInfo.size  gst_memory_unmap(bufMem, &bufInfo);  return GST_PAD_PROBE_OK;}

Колбэк имеет похожую структуру. Теперь нужно достучаться до памяти буфера. Вначале получаем GstBuffer, затем указатель его памяти, используя gst_buffer_get_memory по индексу 0 (как правило задействован только он). И, наконец, используя gst_memory_map, получаем адрес буфера данных bufInfo.data и его размер bufInfo.size.

Фактически мы добились цели получили буфер с кодированными данными и его размер.

Итак, мы рассмотрели ключевые и самые интересные компоненты из приложения для Smart TV аналога Zoom для ТВ-приставок: архитектуру, модули кодирования / декодирования через GStreamer, буферы ввода / вывода и используемые цветовые преобразования.

Для операторов цифрового ТВ такая программная платформа может стать новым абонентским сервисом. Для нас инженеров новым интересным embedded-проектом для реализации на разных приставках на базе RDK, Linux и Android. А для всех остальных возможностью приятно проводить время за совместным просмотром фильмов и спортивных матчей, занятий спортом и посиделок с близкими в период карантина или удаленной работы.

Эту идею с сервисом видеоконференций по Smart TV можно развивать и дальше, как с точки зрения инженерных решений, так и по сценариям их использования. Так что делитесь мыслями в комментариях.

В этой статье мы рассмотрим все возможные варианты обновления прошивки на устройствах под управлением Fuchsia Android. Особое внимание уделим самому популярному способу обновлению по воздуху или OTA (over-the-air) и расскажем об этапах его развития.

Итак, как можно обновить Android на мобильных устройствах? Занимаясь разработкой ТВ-приставок под управлением этой ОС, мы определили для себя 4 способа, отбросив совсем уж экзотические варианты:

1. перепрошивка flash-памяти через аппаратный интерфейс JTAG (если есть);

2. перепрошивка flash-памяти с использованием загрузчика (bootloader);

3. обновление через Recovery Mode;

4. OTA (over-the-air).

Рассмотрим подробнее каждый из вариантов.

1. Обновление Android через JTAG-интерфейс

Вариант с JTAG позволяет обновлять устройство только локально и требует подключения девайса с Android к хосту, например, по USB-интерфейсу. Так как перепрошивается flash-память, новую версию Android можно поставить на прошивку с другими ключами безопасности, да и в целом не сильно стесняться в выборе версий самой Android, версии собранной прошивки или переконфигурации разделов flash-памяти.

Однако обычно JTAG-интерфейс присутствует только на отладочных платах, что сильно сужает область применения этого варианта обновится.

2. Обновление Android через Recovery Mode

Обычно загрузчик является проприетарным, его разрабатывает производитель чипа. Именно bootloader инициализирует доверенную среду выполнения (TEE, trusted execution environment) и проверяет целостность разделов boot и recovery перед переносом выполнения в ядро Linux. Сам загрузчик часто является составным, часть его уровней может быть открытой (например, на базе U-boot), а часть проприетарной.

Bootloader Android позволяет перепрошивать flash-память устройства подготовленными образами разделов. Для этого используется протокол fastboot либо его аналог (в случае Amlogic это будет протокол WorldCup Device). Fastboot,как и его аналог WorldCup Device, это протокол взаимодействия с bootloader через USB-интерфейс или локальную сеть Ethernet.

Для перепрошивки необходимо подключить устройство через USB к хосту (есть вариант использовать LAN Ethernet), перевести загрузчик (bootloader) в специальный update-режим и в этом режиме перепрошить flash-память устройства.

Плюсы и минусы данного метода всё те же, что и для JTAG: так как обновление проходит без участия самой системы Android, при перепрошивке нет ограничений, связанных с версией системы/сборки или ключами безопасности.

Но, как всегда, есть одно НО. :-) Bootloader должен быть разблокирован, а это значит, что мы можем перепрошить сам загрузчик или разделы устройства. Блокировка/разблокировка производится командой fastboot flashing lock/unlock, но для выполнения этой команды может понадобится пароль, установленный тем, кто добрался до этого устройства раньше вас (обычно это производитель).

3. Обновление Android через Recovery Mode и OTA

Если первые два варианта обновления оставались неизменными на протяжении всего времени развития Android, то следующие два варианта обновление через Recovery Mode и OTA реализуются средствами самой Android и эволюционировали вместе со всей ОС.

Стоит упомянуть, что Recovery Mode и OTA это два различных варианта вызова движка обновления Android.

Recovery или non-A/B System Updates

Recovery и движок обновления updater (bootable/recovery/updater) это как раз то, с чего началась система обновления Android (располагается в bootable/recovery в дереве исходников AOSP).

Схема обновления Recovery (или non-A/B System Updates) задействует специальный раздел восстановления (Recovery), где содержится специальная ОС на основе ядра Linux. Эта ОС на базе Linux содержит программное обеспечение для распаковки загруженного образа обновления и его применения к другим разделам. Так и проходит обновление Android.

Пример разметки flash-памяти на устройстве с Android 6.0:

Сам процесс обновления происходит в два этапа:

1. после загрузки с раздела Recovery происходит обновления всех остальных разделов Android;

2. и уже после перезагрузки и запуска новой версии Android происходит обновление раздела Recovery.

При обновлении с использованием движка updater на первом этапе проверяется версия и цифровая подпись образа, поэтому откатить на старую версию ОС уже не получится.

Обновиться по схеме Recovery можно как локально, выбрав в bootloader режим Recovery Mode и запустив движок обновления updater через меню Recovery Mode, либо удаленно, через OTA, когда приложение, работающее в Android, вызывает тот же updater из Java. И как раз при таком удаленном запуске можно организовать массовое обновление целой серии устройств. Этот вариант используют операторы цифрового ТВ при обновлении своих абонентских ТВ-приставок.

Сам раздел Recovery при non-A/B-схеме обновления является физическим разделом во flash-памяти. С появлением A/B-схемы раздел Recovery переместился на RAM-диск в оперативной памяти устройства, но возможность сделать его отдельным физическим разделом так же осталась.

Нужно сказать, что в системе Android нет четкого разделения на старое и новое, скорее добавляются дополнительные возможности в конфигурации сборки Android с сохранением по возможности совместимости со старыми решениями. Однако не все варианты конфигураций работают.

Одним из важных недостатков схемы Recovery или non-A/B System Updates является то, что при любом сбое во время обновления или битой прошивке мы получаем пусть и не кирпич (с раздела Recovery всё еще можно запустить устройство в Recovery Mode), но всё же не полнофункциональное и требующее восстановления устройство.

С этим, видимо, решено было что-то делать, потому что следующим этапом эволюции системы обновления стало бесшовное обновление (seamless updates) или A/B-схема обновления.

Бесшовное обновление или A/B-схема

Эта возможность появилась в Android 7.0, она реализована в новом движке update_engine, который располагается в system/update_engine в дереве исходников AOSP.

Главной особенностью A/B-схемы стало то, что в случае сбоев при обновлении можно загрузится с предыдущей рабочей версии системы Android. Flash-память устройства содержит дублирующиеся системные разделы или слоты (slot A и B), отсюда и название A/B system updates (вечная проблема с выбором названий). За выбор слота для загрузки (A или B) отвечает bootloader, анализируя состояние слотов.

Итак, как же происходит обновление:

1) Загружая систему, например, со слотов A, мы скачиваем и прошиваем обновления на слоты B.

2) После перезагрузки со слотов B мы проверяем работоспособность системы, и, если все ОК, сообщаем bootloader, что обновление прошло успешно.

В случае проблем с обновлением bootloader вернется на старую версию прошивки после нескольких неудачных попыток загрузиться с новой системы.

На официальном сайте для разработчиков Android Source этот процесс расписан более детально в 9 шагах, также там объясняется, как все работает после перезагрузки.

Особенность бесшовной A/B-схемы обновление это съедение большего объема flash- памяти. Насколько большего? Это можно оценить по приведенным ниже схемам разделов для Android 9.0. Как уже упоминалось ранее, разработчик может выбирать, какую из схем A/B или non-A/B применять в конфигурации системы.

Если сравнить эти две конфигурации, то можно заметить, что раздел data при A/B-схеме меньше на 1,6 ГБ, и это цена дублирующихся системных разделов. Много это или мало каждый решает сам, ориентируясь на характеристики своего устройства/проекта.

Проект Treble

Следующие изменения в системе обновления произошли в Android 8.0. Начиная с Android O (8.0) и продолжая в Android P (9.0), Google реализует свой проект Treble. Идея проекта состоит в том, чтобы упростить технологический процесс создания обновления для андроид-устройства. Google предложил разделить с помощью неизменных интерфейсов части прошивки, созданием которых занимаются разные компании. Процесс разработки прошивки для конкретного девайса можно упрощенно разделить на следующие шаги:

1. команда Android создает новую версию своей OC;

2. разработчик чипа или системы на кристалле (Silicon Manufacturer) создает аппаратно-зависимые патчи для запуска этой версии Android на своих платах;

3. и уже разработчики конечного устройства (Vendors) делают свою часть для реализации всех функций конкретного продукта для рынка электроники.

Проект Treble разделяет ОС Android с дополнениями от производителей чипов/СнК и код разработчика конечного устройства, так что теперь операционная система может получать обновления без реализации изменений от производителя устройства.

Разделение происходит как с помощью программного интерфейса (переход с Hardware Abstraction Layer 1.0 на HAL2.0), так и за счет выделения отдельных разделов на flash-памяти для Silicon Manufacturer и Vendor (выше в карте разделов Android 9.0 можно увидеть разделы odm, vendor, product).

Переход с HAL1.0 на HAL2.0 заключается в отказе от прямого связывания с системными библиотеками. Вместо этого, используя IPC Binder, можно подключаться к системным сервисам.

И еще одно небольшое, но полезное изменение: начиная с Android 8.0, в update_engine добавлена поддержка потоковых обновлений по A/B-схеме, в ходе которых идет прямая запись в слот B без необходимости промежуточного хранения данных в /data. Для таких потоковых обновлений практически не требуется временное хранилище, достаточно всего лишь 100 килобайт для сохранения метаданных.

При этом необходимо, чтобы http-сервер, используемый для скачивания обновления, поддерживал HTTP range requests или другими словами докачку.

Проект Mainline

Следующим серьезным этапом в развитии системы обновления Android стал проект Mainline. Реализация этого проекта началась с Android 10.0 и продолжилась в текущем Android 11.0.

Проект Mainline позволяет обновлять отдельные системные компоненты без обновления ОС целиком. Нужные данные загружаются через Google Play отдельно от OTA-обновления прошивки от производителя. Предполагается, что прямая доставка обновлений, не привязанных к оборудованию частей Android, позволит существенно сократить время получения обновлений, увеличить оперативность исправления уязвимостей и снизить зависимость от производителей устройств в поддержке безопасности ОС.

Для реализации проекта Mainline выбранные компонентов системы Android преобразуется в модули. Часть этих модулей имеет старый формат APK, а часть конвертируется в новый APEX-формат, который отличается от APK возможностью применения на раннем этапе загрузки системы. На случай возможных сбоев предусмотрен режим отката изменений.

С APEX-пакетами работает системный сервис APEX manager (apexd). Это нативный сервис, который после проверки распаковывает APEX-пакет в пользовательское пространство на диске и добавляет запись о нем в свою базу данных. При следующей загрузке системы APEX manager проверяет все пакеты из базы данных, создает loop-устройство для ext4-образа каждого APEX-пакета и монтирует его по пути /apex/name@ver.

Модули с обновлениями изначально будут поставляться с открытым кодом, они будут сразу доступны в репозиториях AOSP (Android Open Source Project) и смогут включать улучшения и исправления, подготовленные сторонними участниками.

В рамках проекта Mainline в Android 10 было добавлено 13 обновляемых модулей, а в Android 11 в дополнение к уже существующим прибавилось еще 11 модулей.

Схема Virtual A/B

Также в Android 11 к схемам non-A/B и A/B была добавлена схема Virtual A/B. Этот новый механизм обновления сочетает преимущества обоих предшественников, он обеспечивает устойчивое к сбоям обновление устройства, задействуя при этом минимальный объем flash-памяти. Это стало возможным благодаря созданию снимков файловой системы (snapshot) с использованием технологии Device-mapper (подсистема ядра Linux, позволяющая создавать виртуальные блочные устройства) и Dynamic Partitions.

Dynamic Partitions это система организации динамических разделов для Android. С ее помощью можно создавать, изменять размер или уничтожать разделы прямо в процессе обновления по воздуху (OTA). При использовании динамических разделов разработчикам больше не нужно беспокоиться о размере отдельных разделов, таких как system, vendor и product. Вместо них на устройстве выделяется суперраздел, внутри которого можно динамически изменять размер подразделов. Больше нет необходимости оставлять свободное пространство для будущих OTA-обновлений внутри отдельных образов разделов. Оставшееся свободное место в суперразделе теперь доступно для всех динамических подразделов.

И в заключении последние слухи конца 2020 года вишенка на торте. Google конвертирует Android Runtime в модуль Mainline. Android Runtime или ART это среда выполнения Android-приложений, включающая компиляцию байт-кода приложения в машинные инструкции. Так что есть вероятность, что уже в Android 12 можно будет обновить ART через GooglePlay, установив APEX-пакет.

Также, вероятно, система обновления Android мигрирует в Fuchsia, новую ОС Google, которая сейчас находится в процессе разработки. Они традиционно копируют удачные решения в своих программных продуктах. Так, например, update_engine для A/B-схемы, который применяется сейчас в Android, используется в еще одной ОC Google Chrome OS. Или еще один пример: в Fuchsia предлагается библиотека Machina, которая позволяет запускать Linux-программы в специальной изолированной виртуальной машине по аналогии с тем, как организован запуск Linux-приложений в той же Chrome OS.

Желаем всем успешных обновлений!

P.S. Как там было в Индиане Джонсе?
Как вы меня узнали?
У вас глаза вашего отца.
И уши моей матери. Но все остальное принадлежит вам.

Делимся очередной порцией заметок из жизни промышленных дизайнеров и конструкторов, которые проектируют корпус для новых электронных устройств. Этим летом мы уже делали обзор всех этапов разработки от эскизов до запуска серийного производства. А в этот раз остановимся на типичных ошибках, тонкостях и примерах из практики, которые тогда остались за кадром.

Заметка 1. Делайте дизайн для пользователей, а не для себя

Прежде начать разбор технических аспектов в работе дизайнера важно понимать главное: проблемы большинства новых продуктов для рынка электроники связаны не с техническими ограничениями, а с недостаточным пониманием целевых клиентов и рынка.

На Хабре опубликованы сотни статей о разработке под клиента (Customer Development), проверке гипотез в поле и тестировании прототипов продукта, однако практика показывает, что часть команд все еще отталкивается от своих личных ощущений, а не потребностей целевой аудитории.

Если не забывать о том, что решение задач пользователя это основа любого дизайн-проекта, то технические ограничения не помешают вам добиться цели. Вы сможете с ними справиться. Вам помогут проблемные интервью, на которых вы узнаете о реальных, а не предполагаемых проблемах своих потребителей: дорого, устарело, неудобно, мало/много функций, быстро выходит из строя, неприветливый дизайн, раздражающие цвета, не работает при нужных условиях.

Заметка 2. Учитывайте класс защиты корпуса

При разработке корпуса нужно учитывать климатические условия и интенсивность использования устройства. В некоторых проектах нужно обеспечивать виброзащиту и противоударные свойства корпуса, на других будет достаточно стандартной пыле- и влагозащиты.

Один из важных факторов для промдизайнера IP (International Protection) или степень защиты от пыли и влаги. От этого показателя зависит не только материал, но и конструкция:

Возьмем IP68 и IP30: IP68 можно топить в воде, в нем не будет открытых разъемов; в в устройстве с А IP30 вообще не будет защиты от воды, даже от легких брызг.

На фото слева телефон с классом защиты IP68, выдерживает свободное падение с высоты 1,8 метра. Справа типовая модель смартфона с защитой от пыли и легких брызг.

Заметка 3. Не забывайте об условиях эксплуатации при нанесении графики и выборе материалов

Еще один важный вопрос: устойчив ли материал к морозу или солнечным лучам? Не будет ли он осветляться? Так, при выборе наклейки для устройства важна не только графика, которую мы печатаем сверху, но также выбор материала наклейки и сам клей. Будет ли он держаться в той температуре, при которой используется устройство?

Простой пример для всех: клавиатура ноутбука. В старых бюджетных моделять спустя какое-то время буквы стирались, и на помощь приходили наклейки. В новых моделях используют более износостойкую краску и специальные защитные покрытия.

При выборе материала для кнопок нужно учесть температуру эксплуатации. Так, эластичные материалы крайне чувствительны к изменению температуры и резко теряют свою эластичность при отрицательных температурах.

На фото выше глубиномер для зимней рыбалки с эластичной кнопкой из материала TPU, легко нажимается на морозе.

Заметка 4. У серийного производства свои требования к форме и материалам корпуса

Бывает, заказчик приходит с готовым дизайном корпуса, который отлично смотрится на эскизах и 3D-моделях, но не годится для серийного производства по методу литья под давлением в пресс-форме. Мы уже подробно разбирали этот вопрос в статье про литьевые уклоны и другие тонкости работы с пластмассами.

Если корпус нетехнологичен, т.е. не адаптирован к требованиям производства, тогда дизайнер в паре с конструктором вынуждены предложить иную форму для отливки или найти иной метод изготовления корпуса.

Также у серийного производства свои требования к материалам. Хотя сегодня в ход могут пойти такие нестандартные материалы и технологии как кварцевое стекло, алюминий, древесина и даже обжиг керамики. Да-да, всё это можно использовать в производстве корпусов для электронных устройств. Один из кейсов о серийном производстве корпусов с применением металлов и древесины мы уже публиковали на Хабре, а со стеклом и алюминием мы экспериментировали при при производстве опытных образцов.

На фото беспроводной предусилитель на радиолампах, изготовлен из анодированного алюминия с ручной полировкой, внешняя форма это призма из тонкого кварцевого стекла.

На фото выше предварительные заготовки из металла и пластика (3D-печать), на которых мы проверяли дизайн и конструкцию будущего устройства.

Заметка 5. Ощущения веса и поверхности корпуса нужно проверять на практике

Сам материал это только половина дела, потому что ощущения от материала определяются технологией его обработки. Например, на рельефных выступающих элементах корпуса не всегда возможно получить нужную шероховатость или глянец, и тогда приходится по согласованию с заказчиком менять саму форму, чтобы глянец получился качественный.

А в некоторых проектах глянец, к которому так стремились дизайнеры, может сыграть с ними злую шутку. Например, на устройстве, которое часто держат в руках: мобильные телефоны, ручка или дверца СВЧ, глянцевые кнопки на передней панели любых электронных устройств.

Глянцевый корпус при постоянном контакте с пальцами будет выглядеть грязным, такое решение проигрывает моделям с матовыми покрытиями.

Заметка 6. Размер корпуса может измениться из-за печатной платы и теплового моделирования

Еще один интересный квест, с которым может столкнуться дизайнер при разработке нового устройства необходимость изменить габариты. Такое может случиться из-за теплового моделирования или анализа электромагнитной совместимости, когда компоненты на плате нужно расположить иначе (разнести подальше друг от друга). Плата становится больше и уже не влазит в исходный корпус. Бывают и обратные ситуации, когда при замене компонентов на более новые миниатюрные модели дизайнер может уменьшить всё устройство в целом.

Заметка 7. Себестоимость: крупнее серия дешевле продукт

На этапе эскизирования и моделирования можно предложить самые смелые решения различные материалы и формы, но по факту при расчете стоимости производства могут получиться неподъемные цены для заказчика, и, как следствие, для конечного потребителя. Тогда в ход идут различные методы удешевления. Например, замена металлических вставок на их имитацию металлизированный пластик. Или уход от компонентного литья (это дорого) и использование раздельного литься с последующей склейкой.

Еще один метод оптимизации бюджета на производство сокращение количество частей в корпусе. Чем меньше, тем дешевле.

Также экономить можно при увеличении серийности производства. Например, стоимость прототипов устройства может достигать нескольких тысяч долларов за штуку, а при крупносерийном производстве снизится до нескольких десятков долларов за единицу.

Заметка 8. Эргономика: форма и функция продукта должны соответствовать его целям

При разработке серийного коммерческого продукта невозмозможно учесть абсолютно всех потенциальных пользователей. Нас людей много, и мы разные. В эргономике используется понятие перцентиля: производители ориентируются на среднее большинство, составляющее 90% популяции, а 5% в начале и в конце графика параметров отсекаются. Например, в магазине обуви редкие обладатели очень маленькой или очень большой стопы не смогут найти себе новую пару.

Тот же принцип действует и на рынке электроники. Руководства по эргономике мобильных устройств рассчитаны на правшей со средними размерами ладоней и пальцев:

И в заключении скажем о функции продукта. Классический пример пульт дистанционного управления для ТВ, большая часть которого покрыта кнопками, которые никто не использует (и редко кто знает для чего они).

Цель дизайнера довести продукт до такого уровня, когда в нем нет ни одного лишнего элемента.

На сегодня на этом всё. Делитесь в комментариях собственными наблюдениями и фотографиями из сферы промдизайна и разработки конструкции. Будем вместе дополнять этот список заметок.

Если бы я основатель дизайн-центра электроники Promwad начинал свой бизнес сейчас, то не выбрал бы аутсорсинговую бизнес-модель. Это не значит, что всем командам с продуктовыми амбициями нужно обходить ее стороной. Временная работа в таком формате может стать отличным инструментом для достижения своих целей. Важно только действовать осознанно и понимать, как это работает.

Когда я только начинал работать в отрасли электроники в начале 2000-х и мечтал создавать серийные устройства на острие технологий, то мог рассчитывать только на собственные ресурсы. Не было доступа к западным рынкам свободного капитала, менторов, хабов и акселераторов всего того, что сейчас формирует hardware-экосистему, да и доступ в интернет в те времена только недавно заработал без Dial-Up :-).

Самым логичным выходом из ситуации для меня было такое решение: разрабатывать и производить устройства на заказ, работая с клиентами, у которых был бюджет и конкретные требования к решению для целевого рынка. Так мои амбиции по созданию собственного продукта трансформировались в работу по сервисной модели вместе с инженерной командой Promwad. Хотя на самом старте мы создали аппаратную платформу на базе новейшего процессора по тем временам, но все равно это не было полноценным продуктом. Где-то в далеком видении я отмечал про себя, что когда мы научимся круто разрабатывать, а затем производить серийную электронику, можно будет использовать эти навыки для трансформации в продуктовую бизнес-модель. Но это оказалось не совсем так

Теперь, оглядываясь назад, я вижу весь наш маршрут и понимаю, на каком этапе можно было свернуть к своей исходной цели. Хочу поделиться этими выводами с теми, кто и сегодня сталкиваются с такими же препятствиями отсутствием стартовых инвестиций, команды, четкого понимания рынка и бизнес-навыков, но при этом горит желанием делать собственный продукт.

Конечно, есть бизнесмены, которые осознанно запускают аутсорсинговые компании: они с самого начала мыслят категориями роста и операционной эффективности, относительно быстро преодолевают планку в 200500 сотрудников и выходят на новые рынки. В этом состоит их цель и самореализация. Но есть и те, кого просто занесло в эту гавань в силу обстоятельств: обычно такие компании работают в составе 50200 сотрудников с несколькими миллионами оборота и годами остаются на этом плато.

На менторских сессиях я вижу, как молодые инженерные команды, которые искренне любят свое дело и хотят работать над собственным продуктом, вынуждены зарабатывать на работе по контракту. Они сомневаются, стоит ли им браться за заказные разработки, не станет ли это отказом от мечты. Но надо сделать свой выбор!

Этапы развития сервисной модели и точки для разворота

Если с самого начала рассматривать сервисную модель как стартовую точку своего бизнеса для получения первых денег, опыта в продажах, поиска идеи/рынка и возможности сработаться с командой, то можно смело становиться на эту ступеньку, удерживать в сознании первоначальную цель по созданию продукта и вовремя свернуть.

Так когда надо сворачивать?!

Первый этап, первые контракты на заказную разработку позволят получить базовые бизнес-навыки. В команде до 1020 человек можно обходиться ролями, не обязательно вводить должности и функции. Под ролью я подразумеваю общее направление работы, которое интересует человека и в котором он проявляет себя лучше других. Обычно складываются такие роли:

• Предпринимательская: главный по продажам, главный конструктор/инженер/архитектор.

• Административная роль: главный по проектам, главный по операционной работе.

• Производственная (речь идет про производство сервисов в этом случае) роль: главный инженер и все инженеры-разработчики с конкретными специализациями, которые вносят в дело результат в виде готовой конструкторской документации и кода.

• Интеграционная роль: главный менеджер проектов, который в растяжке бюджет/срок/требования добивается от команды результатов через интеграцию клиента и команды разработчиков.

То, что я имею в виду под ролями, очень похоже на то, о чем пишет в своих работах Ицхак Адизес. Вот его код PAEI: P производитель результатов, A администратор, E предприниматель, I интегратор.

Второй этап, по мере роста, условно с 20 до 50 сотрудников, в бизнес-модели аутсорсинга в команде появятся должности со своими четкими функциями генеральный директор, технический директор, менеджеры проектов, инженеры по специализациям и так далее. У ключевых людей в команде останутся роли, о которых я упомянул в описании первого этапа, но функции станут над ними превалировать. Если вы стали распределять функции значит вы дошли до той точки маршрута, после которой начинается системное строительство аутсорсинговой компании. Начнут формироваться бизнес-процессы.

На этом этапе гораздо сложнее повернуть к продуктовой модели, но все еще возможно.

На третьем этапе, когда команда растет выше условной планки 5060 сотрудников, роль жестких бизнес-процессов становится превалирующей, появляются функциональные отделы маркетинга и продаж, финансов, HR и др., они начинают обслуживать выстроенную вами именно аутсорсинговую бизнес-модель, а не какую-то иную.

На этом этапе свернуть обратно к продуктовой модели будет почти нереально без трансформации всего бизнеса.

Что делать?

В случае когда пройден третий этап, вместо разворота разумнее сохранить компанию в неизменном формате и сделать следующее:

1. Передать управление и предпринимательскую роль кому-то из своих партнеров внутри и позволить им свободно принимать ключевые решения вместо вас.

2. Очертить свою новую роль в компании. Например: я остаюсь в качестве владельца и обозначаю стратегический вектор развития компании.

3. Переключиться на продуктовую модель в рамках новой компании, опираясь на весь свой накопленный опыт и хватать за хвост новые идеи. :-)

Но все равно вам придется начать этот бизнес с нуля, потому что придется собирать новую команду и преодолевать возникающие барьеры заново. Но дорогу осилит идущий!

Выводы: триггеры на пути к мечте и что дает аутсорсинг

Вернемся к тем, кто только стартовал, и для создания своего первого капитала и приобретения бизнес-опыта вступил на путь сервисной бизнес-модели. Итак, если вы только начинаете и готовы преодолевать препятствия на пути к своей продуктовой цели, то вполне можно посвятить 1-2-3 года работе по сервисной модели, но помнить о риске застрять в этой модели надолго и обращать внимание на важные триггеры, которые подскажут, что пора поворачивать к своей мечте:

1. Собралась крепкая команда профессионалов из 1020 сотрудников с высоким уровнем доверия друг к другу. Соответственно, дальнейший рост в текущей бизнес-модели будет только усложнять разворот к продуктовой модели.

2. Роли стали трансформироваться в функции и должности в компании это знак того, что нужно переключаться на продуктовую модель либо целенаправленно сохранять аутсорсинговую компанию.

3. Третий триггер, наверное, самый главный удовольствие от своего дела. Если нет драйва и вы не видите смысла в росте и масштабировании, то есть риск остаться в нише середняков в аутсорсинговой модели в будущем.

А тем основателям и владельцам, у кого аутсорсинговая компания надолго застряла на плато в 50200 человек, пора задуматься: Своим ли делом вы занимаетесь?

Как видите, аутсорсинг это тоже по-своему отличная бизнес-модель. Кому-то она позволяет самореализоваться, построить глобальные компании с сотнями, тысячами и даже десятками тысяч сотрудников, достичь успехов в бизнесе. А для команд, которые мечтают о создании собственного продукта, на первом этапе она позволяет:

• получить нужные компетенции, первый бизнес-опыт и знания об отрасли;

• собрать и сработаться с командой;

• развить свой нетворк сеть бизнес-контактов.

Выбор как всегда за нами! А вы в какой лиге сейчас? Давайте вместе решим, что делать дальше!