`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Рынок конфигурируемых вычислителей – будет ли чёрный лебедь?

Чтобы рассмотреть это явление, надо следить одновременно за информационными источниками из очень разных и традиционно несвязанных областей (вот так «междисциплинарность» распространяет область влияния). Но высмотреть всё-таки удалось.

Начнём с обзора с высоты птичьего полёта. Основа реконфигурируемых вычислителей – так называемая «программируемая логика», проще говоря – микросхемы, аппаратные соединения логических компонентов которых определяются программно и, в общем случае – многократно. Это весьма специфические микросхемы, со своим сопутствующим технологическим стеком разработки конкретных соединений для какой-то цели, в стек входят и специфические «языки программирования аппаратных средств», системы верификации, и много чего ещё, что за пределами области программируемой логики практически никто не видит.

Нужна программируемая логика разным индустриям и по разным причинам. Простые и дешёвые микросхемы с низкой степенью интеграции используются для замены множества отдельных простых логических микросхем (то есть, для существенного удешевления конечной конструкции). Сложные, мощные и дорогие – для использования в областях, где производительности универсальных вычислителей и DSP (цифровых сигнальных процессоров) недостаточно, требуется аппаратный акселератор, но серийность продукции не такая большая, чтобы создавать с нуля полноценную предназначенную для решения конкретной задачи микросхему. С учётом специфики продукции, развитие рынка самых развитых представителей программируемой логики, FPGA, на «взрыв» ничуть не похоже:

Рынок конфигурируемых вычислителей – будет ли чёрный лебедь?

Из графика видно – ёмкость рынка (согласно прогнозам) линейно и неспешно растёт до где-то до $9 млрд к 2023 году, наибольшую долю его занимает потребность коммуникационных индустрий, примерно на втором месте – промышленность, третье место делят почти равные в объёмах потребления строго противоположные потребительская и оборонная промышленности, и за пределами пресловутой «тройки призёров» находятся автомобильная и «чисто IT» индустрии. Картина не очень впечатляющая, ожидаемую ёмкость рынка нельзя назвать «планетарно значимой», но не будем забывать, что это всего лишь один из возможных прогнозов, причём очевидно самый простой, линейный. И он, естественно, не учитывает возможность появления «чёрного лебедя» (теория Нассима Николя Талеба, о трудно прогнозируемых событиях).

На фоне такого спокойного прогноза происходит совсем малозаметное событие. Приобретённая Intel компания Altera, один из двух ключевых игроков рынка FPGA, приоткрывает технические детали ожидающихся в следующем году микросхем Stratix 10. В силу того, что семейство Stratix вообще относится к условному классу «state-of-the-art products» (что означает – «очень недешёвое и сложное для массово интересного»), шума это не сделало. Попробуем без глубокого погружения в детали разобраться, что нового и, главное, совместного с Intel, в этом семействе микросхем.

Stratix 10 – гибридные микросхемы, в корпусе которых размещается несколько кристаллов. Для межкристалльного соединения на подложке гибридной микросхемы располагаются отдельные кристаллы EMIB – специального интерфейса уровня «внутри корпуса микросхемы», разработанного Intel. Самая понятная для непрофессионала «внутрикорпусная периферия» Stratix 10 – быстрая оперативная память. Максимальный объём которой уже заявлен – 16 GB. EMIB-соединение этой памяти с собственно массивом программируемой логики обеспечивает полосу пропускания 1 TB/s.

Рынок конфигурируемых вычислителей – будет ли чёрный лебедь?

Гибридное исполнение Stratix 10 - набор разных кристаллов в одной корпусе на единой подложке

 

Масштабы программируемого массива – до 5,5 млн логических элементов (в терминах Altera «логический элемент» - довольно сложная схема, содержащая позволяющую реализовать любую булеву функцию четырёх переменных аппаратная программируемая таблица поиска, в сочетании с управляющей и синхронизирующей логикой и механизмами «соединения» элементов в одно целое), до 1,8 млн адаптивных логических модулей (они ещё сложнее логических элементов, и позволяют реализовать булевы функции от 6 переменных, а также содержат сумматоры etc), до 5 тысяч блоков цифровой обработки сигналов, до 11 тысяч аппаратных умножителей 18-битовых слов.

Кроме памяти и логического массива таких масштабов в корпусе микросхемы располагается четырёхядерный 64-битовый процессор ARM Cortex A-53 с тактовой частотой до 1,5 GHz.

Всё это упаковано в корпус, дающий возможность задействовать до 1640 выводов, тактируется частотой до 1 GHz и обеспечивает эквивалентную производительность до 10 TFLOPS.

Для взаимодействия с «внешним миром» кроме 1640 выводов GPIO в том же корпусе располагаются до 96 30 GB/s и до 48 17,4 GB/s полностью дуплексных трансиверов (приёмопередатчиков последовательных интерефейсов).

В общем, масштабы Stratix 10 поражают – это действительно самые большие из уже заявленных FPGA, позволяющие конфигурировать исключительно сложные и мощные специальные вычислители и акселераторы. А внутренняя память большой ёмкости (всё-таки, 16 GB это немало), доступная таким вычислителям через шину с очень высокой полосой пропускания (сравните 1 TB/s с примерно 70 GB/s лучших образцов DDR4) превращает Stratix 10 в исключительно интересную конструкцию.

Параметры и специфика исполнения Stratix 10 явно нацелены не столько на оборонные (при таком уровне сложности невозможно добиться требуемой военным надёжности в сложных условиях эксплуатации), автомобильные и промышленные (слишком дорого и избыточно) применения, сколько на датацентры. Мало что это соображение подтверждается открытым позиционированием в обзорной документации Altera, оно логично следует из соотношения затрат Intel на приобретение Altera ($16,5 млрд) и линейно прогнозируемым ростом рынка FPGA – без «чёрных лебедей» даже при условии очень большой 50% доли рынка, дуэту Intel-Altera понадобится лет 6-7 для возврата этих затрат.

Так что, кажется, Stratix 10 – это и есть тот первый «черный лебедь», которого Intel готовит рынку. Точнее, пока видимый фрагмент чёрного лебедя. Потому что индустрия уже отреагировала. Образованием ответного угрозе альянса.

В понедельник, 23 мая, главный конкурент Altera, Xilinx, вошла в альянс с AMD, IBM, ARM, Qualcomm, Huawei и Mellanox. Цель альянса – создание единых спецификаций шин, позволяющих когерентно разделять оперативную память с центральными процессорами и акселераторами этих производителей. По сути, речь больше идёт об аналоге EMIB-соединённой внутри Stratix 10 памяти, но реализованной на уровне выше – на уровне печатной платы, чем об аналоге Intel QPI (когерентная шина). Такое предположение можно сделать хотя бы потому, что у IBM, в частности, уже есть своя аналогичная QPI разработка - CAPI (Coherent Accelerator Processor Interface, когерентный интерфейс акселерирующих сопроцессоров), и Xilinx уже собирается её использовать именно для ориентированных на датацентры FPGA.

Итак, станут ли FPGA масштаба Stratix 10 тем самым черным лебедем, который одновременно изменит картину рынка FPGA, откроет новые возможности облачным вычислениям, в том числе в области «искусственного интеллекта» и вообще значимым событием индустрии?

Как ни странно, такой сложный вопрос имеет довольно простой ответ.

Чтобы быстро, правильно и полезно реконфигурировать FPGA-акселераторы, нужно системное ПО, радикально отличающееся от доступного технологического стека разработки «прошивок» FPGA. Безусловно, есть возможность по мере надобности «прошивать» разные предварительно разработанные акселераторы из библиотеки предоставленных производителем проектов, и это уже немало и полезно, но такое решение – «не совсем то», чего все ждут от реконфигурируемых вычислений.

Три заявления Google и вопросы о нюансах

Очень интересно наблюдать развитие Google. Понятно, что каждая планетарного масштаба компания интересна сама по себе, но Google – особый случай, хотя бы из-за неклассического изначально «непродуктового» характера. И, если жизненный цикл классических «продуктовых» компаний уже неплохо изучен благодаря истории, крупные поставщики изначально нематериального и нефинансового продукта – явление совсем новое. Тем и очень интересное.

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

Много повторять не буду об очередном Google IO, ограничусь констатацией трёх ключевых фактов – слияние Chrome OS и Android, неожиданно оказавшийся живее всех живых проект Ara и, наконец, формирование недостающего для уже имеющегося наследия Nest, домашний ассистент.

Слияние Chrome OS и Android оказалось в каком-то смысле неожиданным. По крайней мере, в Google довольно долго и старательно удерживали дистанцию между двумя системами. Хотя сближение напрашивалось и даже было очевидным. Теперь это официальный факт – Chrome OS будет исполнять (и уже исполняет) Android-приложения. Факт очевидный, но что он может означать, особенно на фоне недавно объявленной «победы числом» проданных хромобуков над такой классикой американского рынка, как Apple Mac (около 2 млн хромобуков против 1,76 млн. разных Mac суммарно)? С одной стороны, понятно, что сравнение в очень разных ценовых категориях не совсем показательно. С другой стороны – факт есть факт, и не просто «вполне возможно», а уже очевидно – дешёвые хромобуки, покупаемые в том числе и в первую очередь школьникам и студентам, уже формируют класс будущих пользователей (в конце концов, то же самое когда-то делали макинтоши классик, они тоже не были суперсовершенными машинами, но своё дело сделали). Но эти соображения слишком поверхностны и очевидны, чтобы всерьёз уделять им внимание.

Если даже не очень сильно задумываться, Android-приложения дают Chrome OS не столько «очень много приложений» (об этом говорят все, но это очень уж очевидно). Они дают полноценную оффлайн работу с приложениями. Потому что Android, несмотря на «ориентацию» (смартфоны и планшеты) никогда не была «ОС для тонкого клиента» или, если хотите, для «терминала 2.0» (чем, собственно, и является, точнее, уже «являлась», Chrome OS). С другой стороны, Chrome OS с её весьма щепетильно продуманной в части безопасности архитектурой (тройная верификация на этапе загрузки, каждое приложение – в своей «песочнице», sandbox) и с ориентацией на клавиатурный (а не тактильный) ввод – далеко, на первый взгляд, не лучшая платформа для расширения её функциональности (хотя бы потому, что она тщательно проектировалась со строго противоположной целью). С третьей стороны, кто только не критиковал Google за сосуществование Chrome OS и Android (достаточно вспомнить Стива Баллмера во времена, когда он был CEO Microsoft, да из самой Google слышалась критика), но потребители хромобуков «совершенно внезапно» не прислушались к этой критике. С четвёртой стороны, кто только сейчас не переносит свои приложения в облачные сервисы (просто из-за правила «задачи 80% потребителей соответствуют возможностям клауд-сервисов, для 20% есть рабочие станции»). Оставим пока все эти соображения, и посмотрим на остальные факты.

Проект Ara. Очень красивый проект. И технически сложный. И всё же Google его тихо не списала «в небытие» (это в Google умеют). Больше того, после довольно продолжительного затишья (по меркам скоростей Google), Ara неожиданно звучно предъявлен публике. И не просто предъявлен, а с конкретными обещаниями. При всей инженерной красоте проект кажется немного странным. Например, производитель очевидно не очень заинтересован в увеличении срока службы смартфонов сменной батареей. Просто потому, что это потенциально увеличивает время жизненного цикла продукта, и на каком-то временном интервале уменьшает обороты. Свидетельство этому мы видим невооружённым глазом (говорят, есть ещё потребительский фактор «толщины», но он совсем из другой оперы и не факт, что он - причина). Проект Ara, наоборот, предполагает даже возможность временной установки нескольких аккумуляторных модулей, и, тем более, их замену. Гибкость и свобода конфигурирования продукта самим пользователем – очень интересная декларация. И нетривиальная. И в Google решили такое декларировать. Вопреки устоявшимся традициям разных индустрий. С какой целью? И этот вопрос, и эти соображения временно оставим на потом.

Третий факт – Google обьявляет «домашний ассистент». Причём делает это не на «ровном месте». Во-первых, у Google есть Nest и инсталляционная база. Во-вторых, мало кто заметил, но совсем недавно Google сделала публично доступной открытую реализацию протокола Thread (о ней я напишу отдельно), причём мало что Thread «обгоняет» конкурентов (например, в нём есть mesh-сеть), так ещё и лицензирование исходных текстов реализации очень забавное для Google. Потому что Google не так часто распространяет что-то на основе лицензии BSD (самая либеральная из всех, не обязывающая ни к чему, кроме упоминаний первичных авторов). И на фоне этого Google заявляет претензии на нечто много большее, чем просто «роутер умного дома», которых в достатке. И нечто возможно большее, чем аналог-предшественник от Amazon (хоты бы потому, что у Amazon нет ничего подобного перечисленным «во-первых» и «во-вторых»).

А теперь попробуем собрать всё это воедино.

В прагматичности Google сомневаться не приходится – это соображение подтверждается стабильным коммерческим успехом компании. Потому все три декларации можно считать весьма прагматичными.

Гибрид Chrome OS и Android – одновременный сигнал и производителям аппаратных средств, и мигрирующим в клауд-сервисы производителям прикладного ПО, и разработчикам локально исполняемых приложений: «на рынке появилась программно-сервисная платформа, способная работать онлайн и оффлайн». И, похоже, за ней стоит целая и весьма стройная концепция: «повседневные не требующие больших ресурсов приложения – из мира Android, более сложное и ресурсоёмкое – в cloud, масштабные сервисы – это масштабные сервисы». Это уже совсем не «терминал 2.0», и не «тонкий клиент». Это нечто новое, для чего фактически есть все предпосылки. Самое интересное, что момент выбран для такого формирования нового класса персональных вычислителей очень удачно – крупные производители компонентного уровня для мира Wintel уже сталкиваются со снижающимся спросом. А принципиально нового никто не видит. Windows всё так же плохо пригодна для небольших экранов, Linux (какой из дистрибутивов?) всё так же в ожидании «года Linux-десктопа», Mac OS X – «священная корова» Apple, которую «свободно бегать» в Apple не отпустят никогда (и даже лицензирование её крайне сомнительно). А людям нужна простая рабочая машинка, с которой как можно меньше забот. И дешёвая. Потому что у людей уже есть всякое, и это «обновление зверинца» бить по карману не должно (и вообще, уже не первый год персональные вычислители – расходный материал, что вынужденно сообразили хитрые китайские производители новой волны и с чем вышли на мировые рынки). Вот она и появляется на наших глазах. Изящная, тонкая, лёгкая, долго автономная, в ценовой категории «до $500». И уже достигнутый результат, без всякой доступности Android-приложений, убеждает, что такая стратегия действенна.

Ara – это, похоже, как раз об эффекте китайских производителей новой волны, и, косвенно – следствие тех самых 600+ моделей Android-смартфонов, выведенных на рынок в прошлом году. Похоже, в Google решили превратить то, за что их всегда яростно критиковали («распыление всего»), в совершенное оружие. Ara – это дальнейшее «бизнес-распыление» производства смартфонов с одновременной инженерной унификацией. В производственные цепочки могут включаться компании, для которых проектирование и массовое производство «завершённого смартфона» было экономически невозможно. А вот отдельный модуль в соответствии с открытыми спецификациями – вполне реалистичен. Естественно, модульный аппарат будет дороже крупносерийных аналогов, произведенных брендами с чудовищными мощностями. И потому конкуренции (особенно на чувствительных к цене рынках) составить им не должен. Это если следовать простой логике. Но в Google собираются знаково «обкатывать» Ara в Индии. На весьма чувствительном к цене очень большом рынке. Поразительно дерзкое сочетание для очень осторожных прагматиков. Вполне возможно, что Ara – ещё и одновременное «подстёгивание» А-брендов к снижению верхней ценовой планки смартфонов (уж кто-кто, а Google очень заинтересована в повышении доступности смартфонов), потому что в верхнем и среднем ценовом диапазоне с появлением Ara конкуренция явно обострится. И, наконец, есть открытое заявление Рафа Камарго (ведущего инженера проекта Ara) – «мы хотим построить инфраструктуру аппаратных средств масштаба нашей инфраструктуры ПО».

Ну и третье направление, злополучный «умный дом», который до появления домашних ассистентов фактически был сигнализацией в комбинации со сверхразвитым (и потому не совсем понятно кому и зачем нужным) управлением освещением («потому что это красиво и просто в реализации»). Пока что ни у кого не было такого набора карт на руках – домашнего ассистента, мощных и востребованных сервисов, полностью открытого без всяких роялти протокола беспроводной сети, инсталляционной базы «модных» устройств, одной из самых массовых открытых ОС (Android – это же не только смартфоны, это ещё и тьма всяких приставок etc).

И, конечно, не следует забывать, на чём «крутятся колёса» всей машины, которую построил Google. Открытость всего, что не является «прямым бизнесом» неоклассического нематериального производителя. Android без вынесенных в Play и ставших приложениями интерфейсов «гуглосервисов» - бери и используй. Chrome OS есть в открытой версии, Chromium OS (и неизвестно, как долго продлится их сосуществование, вполне возможно, что в Google поступят с этой ОС так же, как с Android – вынесут в приложения всё, что требует согласования с третьими производителями и своё сугубо коммерческое). Несмотря на заявление Google о желании стать одним из первых разработчиков и производителей модульного смартфона, очевидно, что модульная конструкция создаётся под тот же принцип открытости (иначе зачем она нужна вообще?). Возможно, в Google хотят установить планку «цена-качество» (как это было в случае с модельными рядами Nexus).

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

Например, будет ли в домашнем ассистенте маршрутизатор беспроводной сети, поддерживающий протокол Thread? Без такого заявления даже самый хороший протокол потребует очень больших затрат на продвижение. Удастся ли Google обеспечить своему домашнему ассистенту достаточную для заинтересованности сторонних производителей аудиторию? Как разрешится противоречие между тактильно-ориентированным интерфейсом Android и клавиатурно-мышино-ориентированной Chrome OS (ответ очевиден, но как это скажется на цене хромобуков и какой будет реакция рынка на её изменение)? И, наконец, как далеко заведёт Google проект Ara, какой будет реакция на него основной массы потребителей и в «длинном хвосте», не расширит ли Google его на те же хромобуки?

Всё это интересно. Как минимум, куда интереснее, чем многое из вообще не происходящего.

 

PS

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

Полноценная «облачная» CAD?

Системы машинной поддержки проектирования (CAD) всегда были особенным, «отдельностоящим» классом ПО. Сугубо «IT-причина» этого очевидна – потребность в очень больших вычислительных мощностях и объёмах памяти (что всегда дорого, независимо от текущей оценки «очень большого»). И эта потребность была одной из причин существования класса персональных вычислителей «рабочая станция», который никуда не делся, в текущем году он соответствует следующему примерному списку критериев:

  • от 6 до 12 и больше 64-битовых процессорных ядер;
  • до 1 TB RAM;
  • условно «самая совершенная графическая подсистема».

Таких рабочих станций на рынке в достатке (причём производятся они не только А-брендами), что свидетельствует – спрос на них есть. И, в том числе, спрос потребителей из сектора проектирования.

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

В итоге все, кто задействован в продуктовых цепочках, постоянно наступают «на грабли», разбросанные в результате очень странного в 2010х годах явления – уверенности конечного потребителя в «растущих на деревьях булках».

Резкое снижение ценовых планок в сегментах прекрасно отработанных и сравнительно простых (для конструкторов сравнительно простых) продуктов, как-то – смартфонов, планшетов, фитнесс-трекеров и прочей «потребительской чепухи», – фактически обнуляют массовое любопытство и вселяют в массы уверенность, с которой один из персонажей Булгакова утверждал фундаментальное «и очень даже просто!».

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

В реальности же, за милым резиновым браслетом копеечного фитнесс-трекера стоит мощная человеко-машинная система проектирования, настолько сложная, что даже небольшое погружение в неё открывает очень скучные (потому что невероятно сложные) картины.

Грустно наблюдать, как любителями «революционных, не имеющих аналогов, уникальных» и прочих «открытий» и «решений» разрывается элементарная и очевидная логическая связь – одновременно массовое и дешёвое, делающее что оно должно делать, и так, как это надо делать, – просто обязано требовать колоссальных затрат (материальных и, если хотите, умственных) на этапе проектирования. И в этом, как раз, заключается и одна из великих «тайн» конкурентных преимуществ.

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

Усугубляет ситуацию и «стоимость входа» в профессиональное проектирование – хорошую рабочую станцию в сочетании с легальным ПО можно смело оценивать на уровне $20K. Даже эта стартовая (в мире материального производства) цифра несравнима с затратами на подготовку рабочего места «просто программиста», она примерно на порядок выше.

Такое «незначительное отличие», с учётом оценки всех рисков и сложности вхождения в рынок проектных услуг (ведь все заказчики требуют от исполнителя подтверждённых предыдущих результатов, не правда ли?), означает одно – так рисковать, чтобы решиться начать высокотехнологичное конкурентоспособное массовое производство, осмелятся единицы. Что, собственно, все мы и видим. И это очень грустно, потому что параллельно развитию IT развиваются и «IT-ёмкие» отрасли, и в их развитии видны новые очень серьёзные угрозы для «третьих стран».

Пока ещё неопределённая, но уже опасная для классической автоиндустрии, бизнес-модель Tesla, например – это уже реальная угроза. Электрокары несоизмеримо конструктивно проще классических авто. В них меньше агрегатов, эти агрегаты компактнее и технологичнее аналогов «со внутренним сгоранием» (для интереса попробуйте сравнить требующий прецизионности во всём дизельный двигатель с электромотором). Такое изменение «основы автомобиля» в сочетании с короткой предысторией и с пока скромными производственными мощностями выходящих на рынок новых компаний, а также с учётом их «дерзости» и амбиций, не может не сказаться на высокоуровневой бизнес-модели. Лет пять-десять, и картина массового производства автомобилей может радикально измениться. Проектирование кузовов может отделиться от шасси (никто этого не запрещал, как и несущие фермы вместо несущих кузовов, нюансы с жёсткостью решаемы даже больше за счёт новых методов проектирования, чем за счёт новых материалов). Могут возникнуть целые новые отрасли. То же самое можно сказать о масштабных системах, например, энергоснабжения. Smart Grid, например, – это и принципиально новые генераторы, и новые накопители энергии, и новые распределительные подсистемы. И нечто похожее можно высмотреть в сугубо потребительском секторе. Та же Google на днях объявила о более чем шести сотнях моделей Android-смартфонов, вышедших на рынок в прошлом году. Кто-то же их проектировал, от общего дизайна до каждой детальки? И кто-то проектировал технологическую оснастку для их массового производства. В то же время производство агрегатного уровня (программисты и вообще «айтишники» должны его хорошо понимать – речь идёт о том самом «повторно используемом всеми») будет максимально автоматизироваться и роботизироваться.

При таком подходе достоинства «третьих стран» (в первую очередь – низкая стоимость рабочей силы) со временем почти полностью нивелируются (иными словами – добавленная стоимость, сформированная требующими ручного труда сборочными процедурами, стремится к нулю).

В общем, как бы ни развивался «то ли кризис, то ли не кризис пресыщения», вывод один – первичная потребность в «синих воротничках» квалифицированных конструкторов будет расти. Это неизбежно (и, как это ни грустно признавать, потребность в программистах, software engineers, devops и прочих из сугубо мира IT, вторична). Но первичная потребность связана с IT. И даже не косвенно. Без ПО, системного и прикладного, без аппаратного обеспечения, удовлетворение роста этой потребности невозможно.

Вся иллюстративная часть была подчинена одному очевидному соображению – снижение стоимости вхождения в современный «мир проектирования материальных объектов» очень важно. И полезно всем (в конце концов, конструкторов надо где-то брать, они сами по себе не заводятся).

Заранее предваряя распространённый скепсис «узкоспециальные сервисы долго не живут», вспоминаю давний спор об этом. Потому привожу в качестве примера идеально узкоспециализированный клауд-сервис, ещё и с традиционными элементами соцсетей, переживший неисчислимое количество всевозможных «для всех» сервисов. ShareLaTeX живёт и здравствует уже три с лишним года. Несмотря на идеальную «специфическую ориентацию» и открытые исходные тексты реализации, его пользовательская база в середине прошлого года превысила 500 тысяч. Более того. Никто не вправе отменить очевидную гипотезу – как в пресыщенном материальном мире живучесть производителя начинает зависеть от его гибкости и адаптивности к требованиям отдельных категорий пользователей (что означает расширение продуктовых рядов с одновременным снижением тиражности каждого продукта), точно так может быть и в сугубо IT-мире, и как раз специализированные, ориентированные на конкретную категорию потребителей сервисы могут получить большой плюс к живучести.

 

Преамбула была длинной, извините. Перейдём к делу.

Джон Хирштик (Jon Hirschtick) – человек в CAD-мире легендарный. И не только в нём. Но совершенно малоизвестный за пределами этих миров. Когда-то он был одним из ведущих игроков MIT Blackjack Team, команде студентов, обыгрывавшей казино легальными методами, и готовил в ней новичков (многие видели фильм «21» с Кевином Спейси в главной роли, Джон Хирштик был приглашён почётным гостем на его премьерный показ). На покерном подсчёте карт (куда менее драматичном, чем показано в фильме) и стратегии командной игры студент MIT Хирштик сделал миллион долларов. Но интересно ему было другое. Этот интерес оформился в компанию SolidWorks. В 1993 году компания наняла команду инженеров и программистов, в 1995 году появилась первая версия SolidWorks и так о себе заявила, что через два года корпорация Dassault Systèmes купила SolidWorks за $310 миллионов. Сегодня SolidWorks – де-факто стандартная CAD-система в машиностроении, а главный герой истории, Джон Хирштик, не успокоился. И даже в одном из интервью сказал прямо – «I Want to Make CAD Fun Again».

Его новое детище – клауд-CAD Onshape.

Идея создания клаудной мощной 3D параметризованной CAD-системы, объединённой с механизмами взаимодействия инженеров-конструкторов, может показаться на первый взгляд странной. Просто потому что для CAD нужны ресурсы, трудно сопоставимые с достаточными для всевозможных классических серверных приложений. И требования у CAD-приложений совершенно другие, и характер их активности радикально отличается от всего классически серверного. Наивный подход –доступ к CAD-программе, исполняющейся ресурсами удалённой рабочей станции, с помощью какого-то фокуса на уровне буфера экрана (например, VNC), – выглядит бесперспективно, он требует очень больших затрат при создании «облака». В Onshape (изначально компания называлась Belmont Technology) решили использовать технологию WebGL – сравнительно молодой JavaScript API к реализации OpenGL ES (для встраиваемых, точнее, мобильных, систем), поддерживаемый всеми основными браузерами. К такому же решению пришли и в Autodesk буквально через год после появления первого релиза WebGL.

Упоминание о WebGL не случайно и не для красного словца – да, облачный CAD не требует таких вычислительных ресурсов, которые нужны локально исполняемой системе, но не следует обольщаться и считать его совсем уж нересурсоёмким. WebGL требователен и к производительности видеокарты, и при работе браузер любит «покушать» и ресурсы процессора, и, особенно, память.

Итак, немного конкретики об Onshape, соответствующей состоянию сервиса на момент написания этой записи. Сервис непрерывно совершенствуется и изменяется, чему способствуют не только усилия разработчиков, но и открытые API и система FeatureScript, из-за сравнительно недавнего анонса которой я и решил обо всём этом написать (о ней чуть позже).

Даже по беглому обзору меню в режиме 3D-моделирования можно сказать, что это вполне «оформившаяся» CAD-система. Здесь есть привычный набор операций, включая loft (создание гладкой поверхности, заданной или граничными контурами в разных плоскостях, или кривой пути, по которой движется контур), при этом лаконичность меню обманчива – все операции допускают одновременно дополнительные булевы (объединение, «вырезание», пересечение) с их результатом и другим 3D-телом или поверхностью. Разработчиками явно сделана ставка на увеличение возможностей операций одного класса за счёт очень развитых параметров, чем на увеличение числа разных классов операций, это надо учитывать при изучении, потому что возможностей реально несоизмеримо больше, чем видно в основном меню (например, все булевы операции допускают заданное параметризованное смещение, что превращает их в очень мощный инструмент). Интересно визуально реализован механизм выполнения операций – он требует предварительного выделения необходимых для операции объектов и при инициализации операции «очищает» экран от всего остального, оставляя видимой только эти объекты и версию результата с учётом значения параметров операции по умолчанию.

Естественно, Onshape – параметризованная система, и любой параметр всех features (не буду переводить это общепринятое в CAD слово) в истории изменений можно изменить в любой момент. Кроме того, система допускает использование переменных для задания параметров (в том числе и векторных, для 3D-объектов), и вычисляемых выражений в переменных. В целом, всё реализовано удобно и очень понятно (особенно если есть опыт работы с какой-нибудь CAD-системой).

Режим «набросочного черчения» (sketch) также вполне традиционный, со всем современным нужным набором инструментов, также параметризованный и с возможностью принудительного задания ограничений (constraints). Практически полностью идентичен возможностям локальных систем. Переход из этого режима в режим 3D-моделирования немного неожиданный, но совершенно логичный – он осуществляется автоматически по завершению редактирования (зелёная кнопка дополнительного меню), или принудительным отказом от редактирования (очевидный красный «x»).

Onshape поддерживает и сборочное проектирование. Режим сборочного проектирования специфичен, но также прост и понятен, в нём можно импортировать как своей разработки детали и тела, так и из разделённых (shared) кем-то, и из публичных общедоступных проектов. Сборочные операции более чем очевидны, терминология (например, mate connectors) детально описана в руководстве. В целом эта подсистема выглядит и ощущается «приятной» (она безоговорочно работоспособна, но в ней, как в любом продукте такого масштаба, есть нюансы, не соответствующие уровню обзорной заметки).

Результатом подписанного в апреле прошлого года долговременного соглашения о сотрудничестве между Onshape и немецкой компанией Graebert Technology стала доступность подсистемы построения чертежей из 3D-моделей. Естественно, никакой ЕСКД в наборе шаблонов для генерирования чертежей нет, только ANSI и ISO. Со сгенерированным чертежом можно работать в отдельном табе интерфейса – выбирать проекции, расставлять размеры, указывать толерантности etc, всё это очень очевидно и удобно (видимо, Graebert Technology была выбрана неслучайно). При этом подсистема формирования чертежей допускает генерацию множества их, с отдельным собственным меню выбора нужного. Само собой, при любом изменении модели достаточно нажать кнопку «обновить» в меню таба работы с чертежами – и чертёж изменится с автоматическим изменением всех расставленных на нём размеров.

Если обратить внимание на общее, независящее от выбранного таба, меню, можно увидеть две иконки, отвечающие за управление версиями проекта. Здесь всё привычное – создание версии, формирование ветвей (branches), слияние ветвей etc. Графический навигатор лаконичен и удобен.

Групповая работа. Было бы смешно, если бы её не было в клауд-CAD. Над одним проектом в реальном времени могут параллельно работать несколько конструкторов. Естественно, для поддержки такой работы предусмотрены всякие мини-чаты и комментарии, а также полезные механизмы, включающие, например, «следуй за мной» – когда несколько конструкторов работают над одним документом, они могут выбирать за кем «следовать», что даёт возможность видеть его действия в реальном времени.

С групповой работой связан и один важный элемент бизнес-модели Onshape. Пользование системой полностью бесплатно для одного конструктора. Ограничения на количество проектов, деталей в них (parts), тел, сложность сборочных моделей и число чертежей – только косвенные: суммарный объём документов не может превышать 100 MB для приватных проектов и 4,9 GB – для публичных. Больше никаких ограничений функциональности нет. Именно по этой причине я решил вообще отказаться от скриншотов - регистрация для пользования бесплатной версией требует минимальных усилий, так что все желающие могут посмотреть-попробовать всё что система может, без каких-либо ограничений.

За $100 в месяц на одного конструктора эти ограничения полностью устраняются – компанию Onshape вообще не тревожит расход дискового пространства, а функциональность системы расширяется только двумя сугубо корпоративными дополнениями – правом собственности на документы и биллингом. По-моему, такого дерзкого шага в мире CAD не делал ещё никто вообще. К этой дерзости добавляется интеграция с огромным «банком 3D-моделей» traceparts, уже работающий Onshape AppStore («пустующим» его никак не назовёшь, причём в несть есть и расширения, позволяющие соединять документы и программы сервиса с локально исполняемыми, например, с CAE системами), и, наконец, социализация конструкторов – они с помощью языка FeatureScript смогут расширять функциональность системы и публиковать собственные расширения на уровне открытых исходных текстов. И, конечно, совсем удивительное – становление FeatureScript в Onshape собираются поддержать нарушением всех канонов – открыть исходные тексты собственных реализаций всех features системы (фактически, это и есть код реальзации системы, за исключением ядра Parasolid и служебных надстроек над ним).

В качестве итога и лаконично.

Система в её настоящем состоянии полностью работоспособна и непрерывно совершенствуется (за несколько месяцев её изучения и «игрового» использования динамика изменений очень заметна). Возможности её уже позволяют выполнять коммерческие проекты, что подтверждается опытом разных компаний, включая мелкие, разрабатывающие малосерийную продукцию. Безусловно, фантастическая по меркам CAD индустрии дерзость Onshape должна сыграть свою роль - когда такое было, чтобы полноценную систему, фактически уже объединяющую CAD, PLM, PDM, с удалённым доступом к проектам со в том числе мобильных устройств, раздавали совершенно безвозмездно?. Эту систему очень дёшево совершенно легально осваивать (когда-то массовое пиратство вовлекло в ex-СССР массу старательных самоучек в мир AutoCAD, например). И в нынешнем состоянии она уже далеко не игрушечная.

Похоже, тех гипотез, с которых начиналась эта запись, придерживаюсь не я один, и Onshape делается «под заказ» растущего спроса на услуги проектирования материальной продукции. Учитывая весьма бодрое инвестирование Onshape и скорость развития проекта (скажем, в прошлом году той же loft feature в наборе функциональности ещё не было), логика рассуждений кажется достаточно убедительной.

В любом случае – замечательный проект, основанный очень интересными людьми. Ну и готовая учебная парта (а, возможно, и совершенно законный «билет в профессию») для всех желающих.

Потому ещё раз повторю – замечательный облачный проект, побольше бы таких.

Однокорпусный реконфигурируемый гибрид

В секторе производства полупроводников с прошлого года замечается насыщение. И чудес роста, показанных в 2013 и 2014 годах, никто уже не ожидает, прогнозы, мягко говоря, скромные. Ситуация обостряется и IoT истерией – для производителей микросхем она может предвещать увеличение объёмов производства с непропорциональным ростом прибыли (потому что IoT – это очень-очень много совсем дешёвого, настолько много, чтобы произошли качественные изменения).

Естественно, крупные производители, располагающие мощной производственной базой, не ориентированной на IoT-специфику, ищут способы расширения рынков сбыта и, само собой, новые «очень большие очень дорогие очень мощные» конструкции микросхем, способные обеспечить ROI в фабы и циклы проектирования.

Если уж столько раз использовалось слово «очень», то в таком контексте будем говорить в основном об Intel. Даже не из-за «системообразующей» роли в индустрии. А из-за масштаба инвестиций в R&D, который по данным «The 2016 McClean Report» в 2015 году составил $12,128 миллиардов (это 24% от общего объёма продаж полупроводниковой продукции).

К слову, наблюдения за динамикой процента затрат на R&D от объёмов продаж Intel позволяют косвенно рассмотреть признаки насыщения – в 1995 году этот показатель был всего 9,3% (менее одной десятой), теперь почти четверть. А технологическое насыщение, как процесс – это когда каждый новый шаг становится всё дороже. Что мы и видим.

Итак, о реакции Intel на технологическое насыщение. Дорогое и казавшееся многим аналитикам неочевидным приобретение корпорацией производителя программируемой логики Altera, в этом контексте начинает «звучать». Естественно, пока есть только просочившиеся ранние сведения, но их уже достаточно для описания ещё одного направления развития «больших микропроцессоров». Вероятный продукт, который станет первым шагом на этом направлении, выглядит так (в лучшем качестве иллюстрация не нашлась, но этого особо и не нужно):

Однокорпусный реконфигурируемый гибрид

Это «упакованный» в один корпус набор из CPU семейства Broadwell (по слухам, 15-ядерный) и мощная микросхема программируемой логики (FPGA) из «десятого поколения» старших устройств производства Altera (максимальные возможности блоков вычислений с плавающей точкой которых оцениваются на уровне 1,5 TFLOPS).

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

Решение объединения двух устройств в одном корпусе выглядит очень разумным (просто потому, что упрощает печатные платы за счёт сокращения числа выводов), как будет решена задача теплоотвода – пока тайна, но она без сомнения будет решена.

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

Но такое «железо» само по себе – товар очень и очень спорный, если его возможности не утилизируются системным ПО, в первую очередь, компиляторами и наборами библиотек.

Реконфигурируемые вычислители – идея не новая, но в случае Intel-Altera мы впервые видим производителя, обладающего ресурсами, достаточными для превращения этой идеи в полноценную технологию.

Так что немного о системном ПО (увы, это пока только «не совсем слухи», просочившиеся крупицы информации).

Что в Intel работают над программной поддержкой реконфигурируемых гибридных вычислителей, подтверждается выступлениями вице-президента Data Center Group Джейсона Ваксмана на Open Compute Summit. Были упомянуты библиотеки RTL (register-transfer level, абстракция для описания синтезируемых синхронных цифровых схем), позволяющие создавать аппаратные ускорители для разных задач (например, шифрования-дешифрования для SSL). И, естественно, речь шла о будущей принципиальной открытости этих библиотек (в противном случае ни о каком серьёзном продвижении новой платформы речи идти не может, весь смысл реконфигурируемых вычислителей – в открытости и мощной поддержке процесса задания и изменения конфигураций аппаратных ускорителей). Это поверхностная и очевидная часть. Явно должна быть и скрытая.

В «пакете Altera» Intel получила доступ и к интеллектуальной собственности компании, связанной именно с синтезом цифровых схем на основе их моделей. Это очень специфический мир программирования, от которого далека основная масса сегодняшних программистов. А время сейчас идёт быстро, и условия требуют от Intel скорого вывода новой платформы на рынок. Что в совокупности обуславливает очень достоверную гипотезу – вместе с реконфигурируемой платформой Intel просто обязана вывести на рынок технологические средства, позволяющие утилизировать её возможности сразу, без нескольких лет на подготовку нового поколения программистов, которые «умеют и на традиционных языках программирования, и на HDL (языках для синтеза аппаратных средств)». Вероятнее всего, работа по созданию такой поддержки идёт полным ходом, но лучше не заниматься гаданиями, а присмотреться к реакции на эту тихую революцию в первую очередь публики из прикладной науки. Реакция есть, просто о ней много не пишут. Точнее, пишут, и даже много, но не в массовых изданиях. Совсем свежие научные сборники Springer, например, всё это подтверждают:

Однокорпусный реконфигурируемый гибридОднокорпусный реконфигурируемый гибрид
 
Это не монографии, а именно сборники. За ними – труд десятков учёных, причём всё это не «на горячую руку» (стало быть, для исследований выделялись гранты, и ведётся вполне упорядоченная работа изучения ниши реконфигурируемых вычислителей). И очень характерные области применения – финансовые и аэрокосмические расчёты. Области, где раньше технологической основой были мэйнфреймы, суперкомпьютеры и рабочие станции. И где сейчас невооружённым взглядом видна миграция в клауд-системы.

Всё сказанное выше в какой-то мере подтверждается и прошлогодней конференцией по высокопроизводительным вычислениям, показавшей, что у Intel уже есть конкуренты – альянс Qualcomm, Xilinx, IBM. И, конечно, Microsoft, с проектом Catapult. Причём понять кто из них опаснее сейчас очень непросто.

Если с альянсом производителей CPU, FPGA и системного ПО всё очевидно в силу схожести его с Intel-Altera, то с Microsoft всё непросто. Потому что, с одной стороны, Microsoft исключительно сильна в самом главном – в системном ПО, с другой стороны – зависима от поставщиков FPGA (в случае Catapult – от Altera). И Microsoft в проекте Catapult всё-таки решала частную задачу построения реконфигурируемой машины для задач классификации на основе алгоритмики «глубокого обучения» (deep learning). Это важный и большой опыт, но никак не сверхзадача построения новой платформы. Но есть и малозаметный аспект – Microsoft через специалистов с большим именем активно работает в суперкомпьютерных проектах масштаба TACC (Texas Advanced Computing Center), где применение гибридных реконфигурируемых вычислителей на основе FPGA планируется, и где задействованы такие серьёзные третьи стороны, как Impulse Accelerated Technologies с технологическим стеком трансляции программ на языке С в синтезируемые вычислители на основе FPGA.

Отдельный предмет обсуждения – суперкомпьютеры. Пока в их списке (TOP-500) нет машин с реконфигурируемыми FPGA гибридными вычислителями. И даже не факт, что такие машины как массовое явление появятся вообще. Скорее всего, суперкомпьютеры, как нечто уникальное и «микросерийное», всем игрокам интересны исключительно косвенно (и Intel в том числе, тем более, что не-Intel их почти и не осталось). Производителям необходимы большие рынки. Очень большие. Даже больше рынка оборудования для клауд-систем. Это диктует логика бизнеса и ROI. Что это будет? Новые рабочие станции с недостижимыми ранее показателями производительности? Вполне возможно. Новые управляющие машины для робототехники? Тоже вполне возможно. Эти два сектора неизбежно будут расти параллельно – насыщение рынков одновременно требует максимальной автоматизации и роботизации крупносерийного производства узлов и компонентов (для снижения себестоимости) и создания очень гибких, с большим количеством ручного труда, сборочных производств (для расширения спектра моделей или вообще «производства под заказчика», к такой стратегии приходят разные большие производители, от Levi’s до Mercedes). Естественно, сегментирование продуктов на фактически сборочном этапе, требует увеличения армии дизайнеров, конструкторов etc, основным рабочим инструментом которых всегда была рабочая станция.

В любом случае главным остаётся «некремниевая» составляющая – системное ПО. Чем лучше Intel (и Altera в её составе) удастся сократить дистанцию между «обычным кодом» и «языками синтеза аппаратных средств», в идеале – вообще её устранить, – тем больше рынков откроется новой платформе. И, что главное, такой инструментарий действительно станет The Next Big Thing, потому что вычислители с созданной «под задачу» архитектурой используются давно и убедительно доказали свою незаменимость, осталась «самая малость» – получить возможность формирования таких архитектур непосредственно из программы для универсального вычислителя.

Синтезируемая экзоядерная ОС как сервис

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

Дальше, увы, текста будет много, зато без картинок )

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

Вот и ещё одна «трудная новизна», из той же «оперы».

Сразу придётся предупредить – я ни в коем случае не «пропагандирую» всё, о чём будет идти речь далее (и даже не буду скрывать где и что меня смущает). Но и интересности явления не отвергаю.

Начнём издалека. Буквально на днях корпорация Microchip объявила о пополнении списка своих сторонних партнёров со статусом «Premier» небольшой компанией Ziedman Technologies. И, так как само событие очень трудно назвать незаурядным, и с учётом фона (Microchip как раз пребывает в шумной стадии приобретения Atmel, сделка временно задерживается решением… Министерства Обороны Франции, потому что Atmel является поставщиком радиационно стойких компонентов), об этом почти никто не слышал. Восполняю пробел, так как Zeidman предлагает нечто новое и, как идею, весьма интересное. Правда, придётся выдержать вынужденное отступление.

«Встраиваемые системы» где-то с прошлого года становятся полноценной отраслью IT, частично IoT hype в этом и заключается. И специфика мира «встраиваемых систем» тоже перестаёт быть тайной, тем более, что громадных отличий от «настольного» и «серверного», в ней нет. К этой специфике относятся и операционные системы. Не буду вдаваться в их принципиальные отличия (в конце концов, даже хорошая RTOS с плохо написанной "прикладной" программой на практике ничего от особенностей «систем реального времени» не оставляет).

В контексте интереснее способы распространения и развёртывания (deployment) ОС для встраиваемых систем. Их всегда было несколько. Традиционный в мире IT, при котором ОС является «черным ящиком» в машинных кодах, в мире встраиваемых систем тоже распространён (с защитой от реверс-инжиниринга лицензионным соглашением). Но сообщество разработчиков по ряду очевидных причин предпочитает Open Source, когда ОС поставляется в исходных текстах. Есть и гибридный способ, когда, например, ядро (микроядро) ОС – «черный ящик», а сервисы и библиотеки – Open Source (или наоборот, бывает всякое).

Были попытки «уложить» эти схемы распространения и развёртывания ОС в формат web-сервисов (причём одна попытка была сделана совсем недавно, по-моему, я об этом уже писал, ОС для IoT Wind River).

Но сама суть разработки «прикладного ПО» для "встраиваемой" полноценной (пусть маленькой и специфической) ОС делала процесс адаптации модели распространения и развёртывания к web-сервисам крайне сложным, а разработку в довольно странной среде – непривычной для программистов и в целом подходящей только для ограниченного спектра чётко определённых аппаратных средств. В общем, удач на этом поприще не было ни у кого.

В Ziedman Technologies попробовали посмотреть на задачи распространения, развёртывания и разработки встраиваемого ПО как на нечто цельное. Выделили из всех упрятанных за каждой задачей ключевые фрагменты функциональности так, чтобы как можно дальше отдалиться от особенностей конкретной встраиваемой системы (включая всё, что относится к архитектуре вычислителя), но сохранить самое важное для работоспособности результирующей системы – поддержку и реализацию concurrency (специально не перевожу, чтобы не искажать смысл, потому что «concurrency is not parallelism» © Роб Пайк).

Радикальным изменением при таком подходе стало… отсутствие ОС в традиционном её понимании. Операционной системы, как единой распространяемой и развёртываемой сущности, больше нет. Её функциональность автоматически формируется на основе кода «прикладного» программиста и «размазывается» автоматической генерацией кода по всей результирующей встраиваемой программе (условно говоря, это можно назвать экзоядром). При этом программист почти полностью освобождается от ответственности за любые механизмы синхронизаций доступа к общим ресурсам и от прочих нюансов, а система генерации дополнительного кода следит за возможными неприятностями (гонками, дедлоками etc, обо всё этом – далее).

О механизмах, реализующих эти процессы, известно только самое важное – они работают, на уровне идей они в чём-то похожи на языки моделирования и синтеза аппаратных средств (VHDL etc), и, наконец, что в реализации используется ANTLR (очень старый, очень мощный «швейцарский нож» чуть ли не для всего, что связано с генерацией программ распознавания языков, описанных формальными грамматиками).

У Ziedman Technologies есть даже патентный портфель, защищающий всё перечисленное, но патенты делали очень опытные поверенные (что неудивительно, учитывая историю основателя компании – он много лет занимался в том числе консалтингом и анализом программ в юридических тяжбах, связанных со спорами из-за кода), так что реально полезной информации из него выудить трудно.

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

Но политика Ziedman Technologies (система стала полностью бесплатной и сгенерированный код не требует роялти) в сочетании с поддержкой мощного производителя популярных микроконтроллеров, могут всё изменить.

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

Теперь можно и о сути. Это не так просто, как кажется, потому что SynthOS (сервис? система? подход к разработке? инструмент?), несмотря на «OS» в названии, совершенно нетривиальна.

На самом высоком уровне работа с SynthOS выглядит так – вы изучаете руководство, регистрируетесь на сайте сервиса, чем хотите, где хотите и как хотите (естественно, с учётом правил сервиса) пишете свой код на языке С и готовите отдельный файл описания кода (единственный с фиксированным именем - project.sop). Если вы считаете, что всё сделано – дальнейшие действия незначительно зависят от используемой вами рабочей ОС. Вы или создаёте сетевой накопитель (ОС Windows), или отдельный каталог (Unix-подобные ОС). В первом и втором случае надо создать два каталога (подкаталога) с именами «in» и «out». В каталог с именем «in» скопировать свои рабочие файлы, смонтировать с помощью протокола WebDAV накопитель или созданный каталог верхнего уровня с URL сервиса и нажать единственную кнопку Run на странице сервиса. В подкаталоге «out», соответственно, появятся модифицированные исходные тексты со всем недостающим, что вместе с вашим приложением образует работающую систему реального времени. Из совсем нетривиального – так как SynthOS работает на уровне исходных текстов на языке С, то вся ответственность за «прямое низкоуровневое использование целевой платформы» лежит сугубо на программисте, указание точного названия целевой платформы в файле project.sop имеет сугубо информационный характер.

О специфике разработки в SynthOS, в силу непрофильности нашего издания, много не напишу. Но назову её «предельным минимализмом программирования систем реального времени, в том числе и для сверхмалых вычислителей без подсистем управления памятью (MMU)».

Потому что как инструмент, SynthOS требует понимания действительно минимального количества абстракций.

Например, высокоуровневый понятийный ряд содержит только процесс инициализации (Init Task), запускаемые планировщиком задач процессы (Loop Task), запускаемые программистом процессы (Call Task), и, наконец, обработчики прерываний (ISR Task, та единственная область, где может быть нужен язык ассемблера, если компилятор целевой платформы не позволяет писать обработчики прерываний на С).

Для управления процессами и синхронизации используются всего 5 «примитивов», которые в С-коде выглядят как вызовы функций. При этом только один «примитив-функция» (SynthOS_wait), допускающий любые легальные С-выражения в качестве параметра, заменяет массу синхронизирующих конструкций, обязательных при разработке ПО реального времени (а скрытые алгоритмы автогенерации кода спасают от традиционных же проблем).

Очень интересный сервис. Совершенно отдельно стоящий от всех принятых подходов, в которых циклы «ОС - разработка – верификация – отладка - тестирование» трансформируется в нечто иное (что именно – даже трудно сказать, исходя из непродолжительного опыта изучения сервиса). И такой подход действительно позволяет ощутимо экономить ресурсы маленьких вычислителей.

Но и ощутимо нетривиальный. Сказывается недостаточность примеров, «необласканность» вниманием и даже некоторое отторжение со стороны сообщества разработчиков (например, кому-то категорически не нравится отправка своих исходных текстов куда-то, кто-то высказывает сомнения в надёжности результатов по сравнению с традиционным подходом).

Из-за этих нюансов судьба сервиса становится тем более интересной. Что с ним сделает Microchip (компания, очень осторожная в приобретениях и альянсах)? Как повлияют на неё действия производителя? Ответов на эти вопросы пока нет.

Зато уже можно совершенно безвозмездно «играться» с SynthOS. Хотя бы потому, что это действительно интересно.

Беспроводные сети с модуляцией «чужого сигнала»

В новостных лентах название предмета этой записи звучало менее внятно, чаще всего как «пассивный Wi-Fi» (позаимствованное из статьи авторов разработки). К сожалению, новость промелькнула и осталась почти незамеченной. К сожалению потому, что такой инженерный подход к решению задачи построения больших энергоэффективных беспроводных сетей мало что технически очень интересен, он ещё и реализуем «в кремнии и металле» доступными сегодня технологическими средствами. И безусловно очень красив.

Итак, есть задача – на локальном участке пространства создать беспроводную сеть, соединяющую N устройств. Сделать это надо так, чтобы развёртывание N устройств было максимально дешёвым, обслуживание – тоже, при этом должны соблюдаться требования к безопасности сети и, конечно, вся сеть должна соответствовать сугубо техническим (в том числе и IT) критериям (пропускная способность etc).

Решение задачи, очевидно, зависит от размеров локального участка пространства. Они могут варьироваться от десятков метров (smart house, ритейл, музеи и библиотеки etc) до тысяч километров. «Неважных» участков в этом диапазоне размеров, очевидно, нет. Больше того. При территориальном размере беспроводной сети порядка десятков метров ничего, упрощающего задачу, нет.

Давайте внимательно присмотримся к состоянию рынка, удовлетворяющего потребности в беспроводных сетях малого радиуса (десятки метров). Беспроводных технологий, созданных именно для решения такой задачи, было и есть очень много. Стандарты и конкретные решения уже успели пройти пару этапов эволюционного развития. Созданы и коммерчески доступны «многопротокольные» чуть ли не однокристальные реализации беспроводных каналов. И что в итоге?

Вы можете увидеть – что, поискав в своих беспроводных маршрутизаторах, смартфонах, умных часах и планшетах образца 2016 года какой-то беспроводной интерфейс, основанный на 802.15.4, например. Не отыскивается такой? Нет ни ZigBee, ни EnOcean, ни 6LoWPAN, ни Thread? А ведь стандарту 802.15.4 скоро будет 13 лет. Со всем, надстроенным над 802.15.4, производится вроде как очень немало  продуктов. И всё это – как раз для построения беспроводных сетей устройств на участках пространства размером порядка десятков метров. При этом все технологии доказанно работоспособны и уже дёшевы на уровне реализующей компонентной базы. Но производители терминалов и маршрутизаторов не спешат всё это использовать. В чём причина?

Можно выдумывать много ответов на поставленный вопрос. Но самый простой и очевидный будет самым правильным - источники питания узлов беспроводной сети. Они необходимы, чтобы снизить стоимость развёртывания сети (иначе или узлы можно размещать только там, где есть доступ к питанию, или придётся вносить очень дорогие изменения в локальный участок пространства). И их надо периодически заменять, что означает – за их состоянием надо постоянно следить etc.

Эту логику подтверждает опыт серийных производителей beacons (в контексте записи – Bluetooth LE маячков). Именно эти производители раньше всех поняли реальные потребности пользователей и особенности «больших инсталляций на малых участках пространства» и стали выпускать… одноразовые маячки, в которых батарея вообще не меняется. Отработал маячок своё (определение этого факта – отдельная задача), на его место просто устанавливается новый.

Для Bluetooth LE маячков, хоть они и попадают в категорию «беспроводных сетей», с учётом специфики их фундаментальной функциональности (а они по сути ничего не делают, кроме как периодически «выбрасывают в эфир» крохотные пакетики данных), такой подход возможен и оказался оправдан спецификой их использования. В общем случае же полная замена узлов беспроводной сети или невозможна, или настолько дорога, что эксплуатация сети утрачивает всякий смысл. Снижение энергопотребления узлов сети всеми прямыми мыслимыми способами, конечно, даёт какой-то эффект, но он далёк и от маркетинговых обещаний, и от маркетинговых же ожиданий.

И вот появляется совершенно новое и технически очень красивое решение.

Предложенное решение задачи основывается на хорошо известном принципе «разделяй и властвуй». Заодно оно демонстрирует и саму возможность применения принципа – буквально 15 лет назад так применить этот принцип было технически невозможно из-за стоимости элементной базы.

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

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

Беспроводные сети с модуляцией «чужого сигнала»

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

Каким бы ни был Wi-Fi адаптер, всё это аналоговое в нём обязано быть. И всё это аналоговое требует много энергии. По меркам встраиваемых устройств с автономным источником питания – непозволительно много энергии. Например, тот же популярный модуль ESP8266 в режиме передачи требует ток порядка 400 mA (миллиампер, 0,4 ампера, при напряжении питания порядка 3,3V потребляемая мощность более 1 ватта), что даже при самом хитром построении подсистемы батарейного питания и батареях большой ёмкости делает его нерациональным.

Предыдущий абзац содержит утверждения, справедливые для классической внутренней архитектуры Wi-Fi адаптеров. Решение же, основанное на принципе «разделяй и властвуй» предусматривает выделение в отдельное устройство (ему трудно даже придумать название, пусть это будет «излучатель») синтезатора несущих частот, усилителя для получения радиосигнала достаточной мощности и некоторых дополнительных схем (для реализации механизмов доступа к сети), а в множество отдельных устройств – хитрые модуляторы радиосигнала «излучателя», у которых аналоговый тракт состоит из фактически одного ключа (грубо говоря – высокочастотного транзистора, работающего в ключевом режиме).

Если не вдаваться в технические детали, принцип работы такой Wi-Fi системы в целом заключается в постоянной «накачке» локального участка пространства электромагнитными волнами подключенным к стационарному источнику «излучателем», и в изменении «пассивными» устройствами этих волн в реальном времени (по временным меркам периода несущей частоты Wi-Fi сигнала). То есть, многочисленные «узловые» устройства сами ничего не излучают, они изменяют сигнал одного единственного передатчика.

Зачем всё это? Начнём не с самого главного. Во-вторых, это даёт возможность использовать обычные Wi-Fi роутеры и контроллеры, которые сейчас есть во всём «пользовательско-терминальном». Никаких изменений уже существующего и работающего не требуется. А вот, во-первых, – энергопотребление. Разработчики заявляют подтверждённое потребление «пассивным» узлом такой системы при передаче со скоростью 1 Mbps на уровне 14,5 микроватт (сравните с 1 ваттом ESP8266). Это в тысячи раз меньше, чем требуется даже специально созданным для микропотребления системам на основе 802.15.4 при работе «на передачу».

Расписывать детали реализации в этой записи не буду, они слишком «радиочастотные» для неспецифического издания (да и особых тайн из проекта «пассивного Wi-Fi» никто не делает). Ограничусь только небольшим замечанием – разработанные узлы беспроводной сети фактически полностью цифровые (исключение – дешёвый высокочастотный арсенид-галлиевый ключ производства Analog Devices). И сравнительно несложные.

Но вот на что хочу обратить внимание – по сути, проект является самым настоящим «хаком» высочайшего уровня. В нём всё – от высокоуровневой архитектуры с разделением устройств на «излучатель» и потребляющие микроватты «модуляторы», до механизмов прямой цифровой модуляции несущего сигнала «модуляторами», является «хаком». Всё работает «вообще не так, как задумывалось», но в итоге – работает, и «хакинг» позволил добиться параметров, абсолютно недостижимых при других подходах. В этом смысле проект «пассивного Wi-Fi» является показательным – это уже не уровень «хакинга», хорошо знакомый многим по всевозможным тематическим сообществам. Это уровень серьёзного инженерного подхода. Потому очень рекомендую всем заинтересованным ознакомиться с проектом самостоятельно и детально. Это очень красивая и глубокая инженерная работа, вызывающая уважение. И надо учитывать, что проект уже коммерциализируется компанией Jeeva Wireless.

И, конечно, что не следует забывать, что проект открывает целое новое направление.

Кто сказал, что на принципе «излучатель-модуляторы» обязательно должен работать Wi-Fi? Совершенно необязательно. В проекте решили заведомо сложную задачу – адаптировали абсолютно непредназначенный для такой высокоуровневой архитектуры Wi-Fi. Только это соображение позволяет утверждать, что потребляемые узлами "пассивного Wi-Fi" микроватты - не предел.

Но никто не запрещает создать «ещё одну беспроводную сеть IoT», учитывающую особенности такой модели. Первый шаг к этому сделан. Точно так же никто не запрещает в подобной системе «накачивать» энергией «излучателя» узлы-модуляторы, полностью избавившись от источников питания в них. Теперь это сугубо инженерные, а не исследовательские, задачи.

Industry 4.0 и IoT – итоги года, видение будущего, часть 3, заводы будущего Airbas и прецизионная агрокультура John Deere

Чтобы завершить короткий цикл записей и чётко определить «что есть что», собрал в одно целое доступную информацию о программе модернизации заводов Airbus. Ею и делюсь. Никто лучше реальных специалистов огромного мощного производства обо всём этом не знает.

Итак, Airbus – это парк более 8000 произведенных самолётов уже в эксплуатации (что означает работы по его обслуживанию, модернизации etc) и пакет заказов на больше чем 15 тысяч машин (на конец 2015 года).

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

Единственное «но» - пример Airbus даёт только частное видение огромного сборочного производства с миллионами деталей и узлов. И с продолжительностью жизненного цикла одной сборочной линии порядка десяти лет. Это далеко не все варианты «индустрий». Просто такой степени деталировки описания, как у Airbus, мне пока не встречалось.

Планы «внутренней промышленной революции», перехода к Industry 4.0, у Airbus очень чёткие. 

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

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

Второй сегмент ближе к традиционным IT. Речь идёт о сквозной конструкторско-сборочной документации, о 3D-моделях, которыми практически с любых носимых устройств могут пользоваться работники. Это крайне непростая задача, потому что степень точности, используемая на этапах проектирования, на этапе сборки не нужна. Но терять то, что информативно для сборщиков, тоже нельзя. Потому речь идёт о «digital mockups» – не совсем традиционных 3D-моделях, которые автоматически генерируются из конструкторской документации и учитывают потребности работников цехов. К этому же сегменту следует отнести сквозную систему управления жизненным циклом продукта (PLM), далеко не новое слово в промышленности, но, если в ней нужен учёт всего нового, что здесь описывается (неужели кто-то может подумать, что те же «коботы» могут работать без непрерывного доступа к информации из PLM?), она радикально изменяется.

Третий сегмент – это как раз то, что и есть IoT-составляющая Industry 4.0. Это «умный инструмент». Работающий «в связке» с подсистемами PLM и с собственными IoT-сервисами, решающими задачи прогнозирования и являющимися источниками данных для глобальной системы контроля и управления качеством. «Умный инструмент» контролирует своё положение в пространстве, например. Не просто потому, что «мы теперь это можем».

Industry 4.0 и IoT – итоги года, видение будущего, часть 3, заводы будущего Airbas и прецизионная агрокультура John Deere

(просто забавное сведение - этот файл на сайте Airbus имеет имя с сочетанием букв "IoT")

Сочетание положения инструмента и сборочного узла даёт информацию для системы инструкций работнику. Простым языком – подносишь «умную электроотвёртку» к фрагменту собираемого фюзеляжа – получаешь инструкцию что ею делать именно в этом месте. Для повышения точности взаимного позиционирования инструмента и узлов конструкции используются все средства – от инерциальных датчиков до систем машинного зрения и лазерной проекции опорных сеток на конструкцию.

Директор R&D механотроники Airbus Себастьен Бориа (Sébastien Boria) чётко определяет даже классы традиционного ручного инструмента, который делается «умным и IoT» - всё для сверления, закручивания и обжима, и, конечно, для измерений.

Естественно, возможность точного определения положения инструмента в пространстве и относительно конструкции, даёт и возможность самого главного – гарантировать качество выполненной операции независимо от выполняющего операцию человека-сборщика. Точные требуемые усилия, углы поворота etc – в авиационной промышленности мелочей нет. И учёт состояния износа инструмента – это тоже плюс к результирующим показателям качества. Всё это делается с помощью того, что сейчас называется IoT. Потому что это уже возможно, дешёво (дешевизна обусловлена в первую очередь распространённостью «всего что для Internet», включая и разработчиков) и прекрасно отвечает задачам.

Ну и для полноты картины – немного о John Deere и одном из прошлогодних приобретений этой компании, Precision Planting. У самой компании John Deere есть свои клауд сервисы для прецизионной агрокультуры (в терминах компании – Precision Ag, к слову, в John Deere используют свои алгоритмы обработки больших данных, реализованные на R, а также прогностические механизмы SAP) и свои IoT системы для мониторинга полей (John Deere Field Connect) и состояния проданных машин (для планирования поставок запчастей, это пример как раз использования тех самых сенсоров IoT, о которых шла речь ранее, myjohndeere.deere.com).

Industry 4.0 и IoT – итоги года, видение будущего, часть 3, заводы будущего Airbas и прецизионная агрокультура John Deere

IoT-станция мониторинга поля John Deere, измеряет влажность почвы, температуру, влажность воздуха, оценивает точку росы, скорость ветра, объём осадков и проч.

С приобретением Precision Planting компания становится ещё большим клауд и IoT-оператором за счёт интеграции систем планирования и учёта посадочных работ. Ещё интереснее интеграционный опыт использования IoT-агросистем от разных производителей. Простота их сопряжения и достаточное количество специалистов в области «разработки с использованием Internet-протоколов» уже даёт результаты. Например, для совместного использования разных полевых сенсоров (среди которых есть очень интересные, например, оценивающие количество и вид насекомых на фруктах).

Теперь можно подвести итог.

IoT – это всё-таки «интернет». Не как пустой термин, а как использование прекрасно отработанных стеков протоколов. Можно считать это явление «большим хаком» (потому что протоколы используются не для того, для чего создавались), можно – естественной эволюцией. Это явный факт. Неявный же факт – попытки использовать интернет-протоколы «где угодно» сами породили влияние на интернет-протоколы. И вот уже есть 6LoWPAN, например. Есть COAP и MQTT. И непременно будут ещё протоколы, расширяющие понятие «интернет». Весь процесс – адаптации стека Internet к задачам, расширения круга задач и расширение стека internet – и есть, наверное, IoT. А вовсе не то, о чём пишут неисчислимые эксперты. И уж точно не злополучная «интернет-управляемая кофеварка».

Industry 4.0 и IoT – итоги года, видение будущего, часть 2

В первой записи речь шла о предпосылках «настоящего IoT» или Industry 4.0. Причём эти предпосылки не очень очевидно содержались в оцененных специалистами (а не сторонними экспертами) значимостях ключевых показателей эффективной (KPI, Key Performance Index) реальных производственных компаний. Теперь можно начать детализировать картину до уровня «что, зачем и как».

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

Раз прозвучали слова «производственное оборудование», об их смысле стоит подумать. В общем случае речь идёт о парке машин разного уровня сложности. Общее у этих машин одно – они состоят из узлов, узлы – из деталей, и всё это подвержено износу. Машины могут отличаться текущим «накопленным» сроком эксплуатации, это могут быть и совсем не новые станки, и промышленные роботы, и турбины, и что угодно (шкала продолжительности жизненного цикла производственного оборудования содержит характерные диапазоны 5-10 лет, 10-20 лет, 20-50 лет). Выведение машины из эксплуатации – это не просто её «замена», а в общем случае и модернизация всего технологического процесса. Потому все производители хотят увеличить срок эксплуатации машин и стараются прибегать к их заменам только в самых очевидных случаях, например, когда технологический процесс безнадёжно устарел и потому стал неконкурентоспособен.

Учёт износа узлов и деталей – задача, которую классически решали методом «учётного журнала и планов регламентных работ». То есть, процедура учёта износа была фактически полностью «отвязана» от реального износа и строилась на предварительных допущениях производителя машины и опыте эксплуатирующей машину компании. Причина предельно проста – стоимость микроэлектроники и сенсоров, особенно пригодных для промышленной эксплуатации (industry grade, температурный диапазон, вибрации, электромагнитные поля etc, при которых компоненты гарантированно работоспособны), начала стремительно падать совсем недавно. А по меркам продолжительности жизненного цикла производственного оборудования – так и вовсе «вчера». И «напичкивать» всем этим удовольствием без того сложные машины совсем недавно было астрономически дорого. А каким образом, без дополнительных датчиков (которые в общем случае далеко не примитивны), можно учитывать время наработки, например, отдельных деталей сложной машины? При этом выход из строя детали, или просто её увеличенный износ, порождают или временную остановку технологического процесса (и время этой остановки фактически всегда больше времени, требуемого на просто замену детали), или снижают качество продукции (потому что гарантируемые параметры машины, на основании которых строился технологический процесс, уже не обеспечиваются).

Значительная часть ландшафта Industry 4.0 и «настоящего IoT» - «всего лишь» способ решения этой задачи, дополненный машинной аналитикой (всё, что недавно называлось big data, в сочетании с задачами прогнозирования, распознавания образов, классификации etc, или, как сейчас модно, machine learning).

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

Радикальная модификация задействованной в производственном процессе машины чаще всего невозможна (никто не хочет останавливать производственный процесс). Или непозволительно дорога. Это означает, что в общем случае никаких непосредственных методов оценки времени работы узла или детали не существует. Просто потому что в общем случае до них нельзя «добраться» без остановки и разборки-модификации-сборки машины. Простая задача «давайте посчитаем сколько времени крутился подшипник № X в узле Y» становится крайне непростой. Но в индустрии «любой ценой» ничего не делается, потому задача звучит примерно так – «давайте развернём подсистему учёта времени работы подшипника № X в узле Y за N единиц денег и M единиц времени». Причём N и M в идеале стремятся к нулю.

Не обращаясь к реальной конструкции какой-то производственной машины, мы уже сформулировали одну из крайне сложных задач IoT в концепции Industry 4.0. Непосредственного доступа к подшипнику № X нет, возможности прокладывать провода или кабель от датчиков – нет, но пользователь машины очень хочет получать хотя бы эту информацию (временно забудем о высокоуровневой обработке и прочем, что делается мощными вычислительными ресурсами cloud платформ), ещё и с минимальными затратами (материальными и временными) на развёртывание, эксплуатацию и обучение персонала. Поставленная задача (несмотря на то, что мы говорим всего о подмножестве IoT – о SN, Sensor Networks, сетях сенсоров) содержит в себе фундамент того, что мы видим даже в IoT hype.

«Минимизация расходов на эксплуатацию» для устройства, которое фундаментально, «в общем случае», невозможно подключить к источнику питания, означает очень долгое время работы от батарей, или, ещё лучше, замену батарей в нём системой «сбора энергии» (energy grabber). Что мы и видим даже в hype – стремление к снижению энергопотребления, постоянные упоминания «год и более от батареи», проникновение подсистем «сбора энергии» из технологий «умного дома» в претендующие на универсальность (о чём свидетельствует, например, рост популярности альянса EnOcean, пропагандирующего и поддерживающего развитие систем energy grabbing  и его активность в сугубо IoT консорциумах).

Невозможность использовать в общем случае проводные каналы связи порождает следствием бурный рост интереса к малопотребляющим беспроводным, и вот буквально недавно на и без того не пустующее поле битвы за долю рынка энергоэффективных радиоканалов для IoT включился альянс Wi-Fi с уже готовыми спецификациями HaLow (причём весьма многообещающими).

Это очевидные, поверхностные следствия фундаментальных особенностей задач IoT. Настало время для неочевидных, причём никакого дополнительного усложнения совершенно абстрактной задачи о подшипнике № X узла Y некоей промышленной машины нам не потребуется.

Если бы машины были идеальными и не подчинялись законам физики, мало что никакой потребности в IoT как сегменте Industry 4.0 не было бы, хуже того – при всех прочих требованиях реализация IoT была бы вообще невозможна. Потому что эти самые «прочие требования» в общем случае исключают наличие непосредственных данных и простых способов их преобразования. В реальности владелец машины не может её разобрать, добраться до злополучного подшипника № X, укрепить на нём какой-нибудь простой преобразователь вращения в электрические импульсы, протянуть провода, собрать всё это и наслаждаться результатом.

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

Значит, для начала нужны преобразователи этих в общем случае неэлектрических явлений в электрические сигналы. Это мир сенсоров. И в нём за счёт MEMS-технологий произошёл явный взрыв. То, что стоит сегодня сущие копейки (MEMS-микрофоны, акселерометры, гироскопы, магнетометры, датчики газов etc), буквально 10 лет назад было фактически недоступным. А парк промышленных машин, не выработавших свой ресурс за эти 10 лет, огромен. И они очевидно вступают в опасный период жизненного цикла, когда вероятности отказов из-за износа деталей и узлов возрастают. Так что разработчики и производители сенсоров «подстёгиваются» не только стремлением к увеличению числа датчиков положения смартфона в пространстве, чтобы «поворачивать экран».

Замечательно. Мы уже можем за доллар с центами, например, преобразовывать вибрации узла, где находится подшипник, в электрические сигналы. Проблема в том, что считанная картина содержит в себе слишком много лишнего. А нас интересуют только вибрации от злополучного подшипника. И вот примерно с этой задачи «отделения зёрен от плевел» и начинается самое интересное и сложное в IoT, о чём почему-то пишут только в серьёзных профессиональных изданиях.

Сразу предупреждаю – всё, что будет дальше, присутствует здесь совершенно не случайно и не потому, что «мне это нравится». Я постараюсь объяснять, не выходя за рамки нашей высокоуровневой модели, почему именно эти междисциплинарные разделы IT сейчас очень цитируемы, почему им уделяют столько внимания в НИОКР и зачем на всё это тратятся гранты академической наукой.

Давайте ещё раз соберём вместе те очевидные следствия фундаментальных особенностей задач IoT, о которых только что говорили: высочайшая энергоэффективность и в общем случае вызванное ограничениями реальности использование беспроводных каналов связи, и всё это – за очень скромные деньги, потому что этим теперь уже трём критериям должны соответствовать самые массовые в IoT-системах устройства, «оконечные узлы».

Так как в общем случае никаких допущений о местах развёртывания этих узлов мы делать не можем, потому всякие низкоуровневые «прямолинейные» решения в общем случае же «не работают». Например, исполнение всей электроники встроенного в узел вычислителя в виде SoC (системы на чипе) со снижением его энергопотребления за счёт технологии изготовления этой системы на чипе «sub-threshold» (модное направление снижения энергопотребления за счёт работы транзисторов в диапазоне напряжений, меньших обычного для PN-перехода падения напряжения порядка 0,6-1,2 вольта), не является панацеей. Оконечный узел IoT может быть установлен там, где уровень помех сделает работу всей системы просто непредсказуемой (с подобным уже столкнулись разработчики бортовой электроники автомобилей, и если внимательно присмотреться к рынку компонентов, можно заметить возвращение популярности в автоэлектронике пятивольтового напряжения питания).

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

Первое в алгоритмике, на что «покусился» IoT – на фундаментальный принцип «оцифровки» аналоговых сигналов, на теорему Найквиста-Шеннона. Это классика всей цифровой обработки сигналов – «частота оцифровки аналогового сигнала должна быть минимум в 2 раза выше самой высокой частоты в спектре аналогового сигнала» (формулировка неточная, но для целей этой записи достаточная). Для нужд IoT, с учётом специфических критериев, это фундаментальное оказывается избыточным. Потому что теорема Найквиста-Шеннона даёт «пессимистическую оценку», гарантирующую восстановление всего спектра аналогового сигнала, без учёта особенностей породившей его системы и его пригодности, например, к процедурам сжатия данных (важный момент, фундаментально теорема Найквиста-Шеннона основана на линейной модели, а сжатие данных является сугубо нелинейной операцией). Классические, «по Найквисту-Шеннону», аналогово-цифровые системы (к которым относится всё, что есть в IoT) в общем случае требуют высокой производительности вычислителей, встроенных в сенсоры, и высокой полосы пропускания каналов связи. Что входит в противоречие с критериями IoT. Название «нового» подхода, популярность которого буквально достигла взрывного уровня с ростом IoT hype – Compressive Sensing. Эта теория, в основе которой «смесь всего» (в том числе и молодая «Uncertainty Theory»), уже далеко не «бумажная». Так как я ставил себе задачу всего лишь привлечь внимание к важным областям, в которых «настоящий IoT», ограничусь только самым главным – Compressive Sensing необходима для такой минимизации числа измерений (или аналогово-цифровых преобразований), при которой сохранившая в результатах «оцифровки» информация достаточно для практических целей хорошо аппроксимирует исходный сигнал. А о её «небумажности» говорят многие прикладные работы прагматичных китайских учёных и многие устройства, где Compressive Sensing уже используется. Трудно поверить, но «простой» класс недорогих гаджетов, как трекеры физической активности (популярный Fitbit, например), является одной из прикладных областей, где Compressive Sensing очень востребована.

Второе «из мира IoT» - Sensor Fusion и Multi-Sensor Fusion. Локальное по месту измерения «улучшение данных от физических сенсоров» для сокращения требований к полосе пропускания каналов связи, повышения устойчивости к их сбоям, улучшения показателей качества всей системы в целом. Огромная область, разделённая на специфические (в зависимости от сенсоров) сектора. Большего о ней, в силу её «габаритов», в таком объёме сказать нечего, кроме одного очевидного – это настолько востребованная область, что буквально за год большинство производителей электронных компонентов вывели на рынок системы на чипе, реализующие алгоритмы Sensor Fusion для разных сенсоров.

Третье, не менее фундаментальное, что также «взорвалось» с ростом популярности IoT-тематики – теория систем управления с обратной связью. В классическом своём варианте она основывалась на непрерывной коррекции возмущений во всей системе, охватывающей управляемый объект. Для IoT с его фундаментальными критериями эта фундаментальная непрерывность оказывается слишком суровым требованием, соответствия которому в общем случае добиться просто невозможно (и вообще не нужно). Реакция на явное противоречие – рост интереса к Event-Based Control, теории управления, основанной на событиях. Она изучает системы, в которых цепь обратной связи «срабатывает» только тогда, когда сенсоры обнаруживают значимые изменения в системе (причём при таком подходе возможна успешная реализация таких «классически непрерывных» алгоритмов, как PID-регуляторы). Сравнительно молодая теория, без которой построение масштабных реально полезных и гарантированно работоспособных IoT систем для Industry 4.0 практически невозможно. Если даже бегло «порыться в интернете» по словосочетанию “Event-Based Control”, можно заметить, что основная область применения этой теории – автоматизация производства. Ей уже посвящаются тематические конференции IEEE, курсы лекций по ней уже читаются в хороших университетах, и, что главное, такие гранды большой автоматизации, как Emerson, уже «по полной» используют Event-Based Control в своих системах. В общем, всем, кто всерьёз интересуется IoT, изучение хотя бы основ Event-Based Control необходимо. По-другому IoT-системы, с учётом их особенностей, работать не могут.

И есть ещё четвёртое, о чём говорят почему-то совсем мало. Принципиальная интердисциплинарность IoT требует адекватной поддержки моделирования систем разной природы. Как и вся новая IoT-алгоритмика. Без качественного моделирования создание реально хороших и полезных систем невозможно.

Для завершения, чтобы всё из двух этих записей не оказалось пустыми словами. Всё это – уже реальность, например, в Bosch. 73% профильных специалистов корпорации подтвердили использование IoT-составляющей Industry 4.0 в реальных производственных процессах. То есть, в Bosch действительно «обвешивают» производственное оборудование «умными IoT-сенсорами», реально создают системы сбора информации о режимах работы оборудования, на основании моделей формируют прогнозы регламентных работ, и замыкают цепь обратной связи оповещениями персонала о прогнозируемом времени необходимых работ, что даёт возможность спланировать их проведение так, чтобы снизить потери производства от простоев. В Boeing точно так же собирают данные с «умных отвёрток» об их износе и поставляют им данные о необходимом усилии при закручивании конкретного болтового соединения (эти цепочки нужны для того, чтобы изношенными электроотвёртками не нарушить требования к технологическому процессу). Всё это уже работает. И в той же Bosch уже говорят о том, что самыми существенными причинами слабой распространённости IoT-технологий в производстве являются не финансовые или технологические проблемы, а, например, низкая квалификация «экспертов», набросившихся на IoT-тематику из-за hype, и слабая информационная поддержка профильными изданиями (потому что, вопреки всем домыслам, львиную долю информации специалисты получают именно из них).

Прямых ссылок не приводил, потому что всё упомянутое настолько «на слуху» и популярно, что безошибочно находится с «первого раза» в избыточных количествах.

Industry 4.0 и IoT – итоги года, видение будущего

Временно прерываю цепочку о «десктопных» версиях Android (просто чтобы опробовать всё доступное на себе, это требует времени), и соберу в одно целое очень интересные результаты работы специалистов Bosch и много всякого разного не менее интересного, посвящённого тематике Industry 4.0. Или, если больше нравится, «четвёртой промышленной революции».

Без отступления не обойтись. Термин «IoT» из-за пресыщения рынков с товарами с IT-составляющей за прошедший год довели до полной непонятности. В каком-то смысле финалом этого «расширения границ IoT» стала малозаметная, но показательная истерика, устроенная на популярных ресурсах ars technical, и Slashdot. Истерика вышла по меркам Internet 2.0 крохотной, и, даже можно сказать, не удалась. Показательно в ней то, что в IoT уже записали что угодно. И web-камеры, например. Которые были (в том же, если не худшем) состоянии задолго до появления термина IoT. В общем, в потребительском сегменте в IoT теперь записывается всё, что «по предназначению не ПК, но имеет сетевой интерфейс». Не будем разбираться с этим, и вообще о нём забудем, просто потому что это временная девиация, вызванная hype. С другой стороны, в мире производителей всех этих «по предназначению не ПК…» (и не только), с IoT очень неплохо определились и особого непонимания не наблюдается. IoT видят одним из ключевых механизмов Industry 4.0, а о прочем (почему так, зачем и даже немного – как это), будет дальше.

Больше абстрактных отступлений не будет, переходим к делу.

В 2015 году в Bosch организовали и провели очень важное и немаленькое мероприятие – опросили 190 управляющих производством (production managers) сугубо производящих компаний (manufacturing companies) Германии, Австрии и Швейцарии. После чего дополнили этот опрос оценками почти двух сотен собственных производственников высокого уровня (Bosch – гигантский производитель чуть ли не чего угодно массового и одновременно высокотехнологичного).

Выбор стран не случаен. Давайте взглянем на выборки из «топ 10» позиций в структуре их экспорта (данные о Германии – за 2015 год, остальные – за 2014й):

  • Германия: 17,2% всего экспорта – автомобили, 17,1% - продукция машиностроения, 9,8% - электроника, 4,6% - медицинское оборудование, 2,9% - авиа- и космическая продукция;
  • Австрия: 18,2% - продукция машиностроения, 12% - электроника, 8,4% - автомобили, 2,7% - медицинское оборудование;
  • Швейцария: 8,3% - продукция машиностроения, 7,8% - продукция часовой промышленности, 5,2% - медицинское оборудование, 4,3% - электроника.

В итоге, доля продуктов «сугубо производящих компаний» в структуре экспорта Германии – 51,6%, Австрии – 41,3%, Швейцарии – 25,6%. Это очень высокие показатели, косвенно свидетельствующие о высочайшем уровне не только производств, но и всего «сопутствующего», от финансовых систем до логистики, подготовки квалифицированного персонала etc.

Самым важным в результатах опроса Bosch стала оценка управляющими производствами важности «ключевых показателей эффективности», KPI (Key Performance Index). Картина получилась настолько интересной, что позволил себе изменить оригинальные результаты для повышения наглядности.

Итак, самым важным показателем эффективности из ключевых для промышленников (1) оказалась стоимость обслуживания и ремонта оборудования. Второе место по важности отдано убыткам из-за сбоев оборудования. Третье (всего третье) – объёмы производства. Четвёртое – стоимость логистического обеспечения. Пятое – эффективность управления inventory, запасами готовой, но нереализованной продукции. Три последних, самых маленьких по значимости (но всё же значимых) KPI в порядке убывания – прямые (6) и непрямые (7) трудовые и постоянные затраты (8).

Industry 4.0 и IoT – итоги года, видение будущего

 
Эта картина, свидетельствующая об очень высоком уровне развития производства, является опорой использования технологий IoT в Industry 4.0. А уже их использование даже не обещает, а реально даёт такие плоды, что специалисты открыто говорят о «четвёртой промышленной революции». Чтобы было нагляднее, переформатирую предыдущую картинку, и красным выделю те области, в которых IoT технологии уже нашли своё место в производственной системе той же Bosch:

Industry 4.0 и IoT – итоги года, видение будущего 
 
По-моему, здесь всё понятно, и в объяснении не нуждается. Подавляющая доля в оценке KPI по важности попадает в «область действия» IoT. И, что интересно, прекрасно ей соответствует. Об этом всегда говорят или совсем немного, или очень размыто, или вообще неявно, но так, чтобы было понятно для специалистов «в качестве очевидного». Позволю себе об этом соответствии сказать прямо. Это пригодится в последующем.

IoT – это использование Internet-протоколов. Настолько факт, что он «зафиксирован» в названии. А семейство Internet-протоколов никогда не создавалось для использования в системах промышленного управления с их требованиями «жёсткого реального времени» (hard realtime). Более того. Если говорить не о высокоуровневых протоколах, а об уровне технологий передачи данных, например, об Ethernet (и о всём, что основано на технологии множественного доступа CSMA/CD), они очень долго не приживались в промышленности (речь не об офисах, а о реальных производственных процессах), а их «промышленные версии» (например, EtherCAT) модифицированы глубоко и до неузнаваемости и требуют очень специфических контроллеров. В общем, Internet-протоколы и «обычные, офисные» технологии передачи данных (в том числе и беспроводные) – это очень «не совсем то», что нужно для задач реального времени, характерных в промышленном производстве. И всё же IoT находит себе место в задачах, важность которых считается настоящими специалистами, из реальной промышленности, высочайшей. Причина такого «несоответствия» - в специфике задач. Это тоже задачи «реального времени», и даже с замкнутым контуром регулирования, но их объекты управления изменяются очень медленно, а контур управления замкнут не на машинах, а на организационных системах.

TBC

PS

В силу специфичности и объёмов решил разбить этот материал на цепочку записей в блоге. В итоге мы доберёмся до таких интересных вещей, как алгоритмика основанных на событиях систем управления, sensor fusion, compressive sensing и проч., конечно, на уровне "что это и зачем оно", чтобы расставить если не всё, то многое, по своим местам. Очень "тяжело" подъёмная тема, но кто-то должен это сделать. Вести "цепочечный" тематический блог в издании широкого профиля очень трудно.

Android – путь к десктопу

В качестве преамбулы могу сказать только неинтересное, увы (зато сразу, потом будет интереснее). Опыт и успех разработчиков ОС Android прямым текстом подсказывал «дистрибутивостроителям» Unix-подобных ОС готовый проверенный путь. Не один раз и очень долго об этом писал, и всё равно позволю себе повториться.

Проблема Unix-подобных ОС отлично всем известна – фрактальный хаос на пользовательском уровне (userspace). Это уже даже не «проблема», а унаследованная от специфики разработки особенность фактически любого дистрибутива, будь он из мира Linux или *BSD. Попытки сформировать «цельную экосистему» пользовательского уровня, например, Gnome или KDE, остаются попытками, не более. Любая реальная инсталляция нужного и полезного пользователям ПО приводит к диковинному разнообразию технологических библиотек и целых «миров» подсистем, которые или плохо, или вообще никак не согласуются друг с другом, при этом разработка их также никак не согласована.

Справедливости ради, это особенность не только мира FreeNix, та же самая ОС Windows с её огромной историей эволюции и централизованным контролем технологического стека показывает, насколько трудно решается задача спасения от технологического хаоса в ходе продолжительной эволюции большой программной системы (потому если у вас установлен .NET 4, а приложение требует .NET 2, не удивляйтесь загрузке и инсталляции «всего сверху вниз»).

Виртуализированный пользовательский уровень, главная и уникальная для мобильных приложений архитектурная особенность Android, была в своё время (и убедительно доказанно стала) сильнодействующим лекарством от этой «болячки». Очень давно корпорация Sun, косвенно имеющая отношение и к истории Android, пыталась использовать это лекарство в проекте Sun Java Desktop, но использование было очень преждевременным (вычислительные мощности и оперативная память были слишком дорогими), и вообще гомеопатическим (потому что сохраняло унаследованные громадные подсистемы, например, X Window, с соблазнами бесконечного числа технологических библиотек).

В общем, было бы очень странным, если бы всё это понимал один человек. И если бы не было попыток использовать или опыт Android, или вообще кодовую базу этой ОС, для создания ориентированных на «настольные приложения» дистрибутивов. Так что подобные дистрибутивы есть, причём речь идёт уже не о единичном уникальном явлении. Забавно, что в этом направлении идут сразу несколько китайских разработчиков (в чём, а в прагматичности, китайцам отказать трудно).

Здесь надо сделать небольшое отступление. Давайте мельком посмотрим, чем располагает ОС Android образца 2016 года. Даже взгляд с высоты птичьего полёта на архитектуру ОС говорит о том, что перед нами высокоразвитая операционная система, надстроенная над интересным высокоуровневым уровнем абстракции (заметно, что HAL, Hardware Abstraction Layer, расположен над ядром ОС Linux):

Android – путь к десктопу

Так как система сравнительно «молода», она проектировалась на базе опыта предыдущих разработок, и потому, например, в части построения пользовательских интерфейсов, куда совершеннее, чем «настольные ОС», за которыми тянется очень долгая предыстория. То, что в пользовательских ОС переложено на уровень инструментальных средств (например, высокоуровневые описания интерфейса на основе XML), здесь архитектурный элемент. С другой стороны, быстрая эволюция и ограниченность целевых платформ носимыми с тактильным интерфейсом, сформировали определённые «провалы», например, в технологической поддержке характерных «настольных» возможностей, например, drag and drop.

Графическая подсистема (как одна из самых важных в пользовательской ОС) Android также очень высокого уровня и основана на стандарте OpenGL ES – подмножестве OpenGL для встраиваемых систем. Отличия между «взрослой» OpenGL (на возможностях которой в «настольном мире» или в рабочих станциях основываются практически все большие профессиональные программные пакеты) и OpenGL ES описаны в огромном сложном документе, но совместимость этих систем гарантируется. Что значит – принципиально задача расширения ОС полноценной, класса рабочих станций, графической подсистемой, решаема. Более того, решаема так, что «родное» ПО немодифицированной Android сохранит свою работоспособность. Это очень большой и тяжёлый проект, но кто может знать, что получится в итоге из всех попыток, о которых пойдёт речь дальше. Совершенно не исключен вариант, что такая задача покажется кому-то интересной.

Отступление было сделано просто для того, чтобы предельно кратко пояснить – задача трансформации Android в «настольную ОС» (что сейчас ассоциируется и с рабочими станциями) не является ни нерешаемой, ни бессмысленной. Второе хотя бы потому, что две доминирующих на «настольном» рынке ОС, Windows и Mac OS X (на деле – NeXTSTEP с доработками графической подсистемы), действительно стары, а дистрибутивы ОС Linux не являются цельными системами с вытекающими из этого факта особенностями. И "свежая кровь" всегда была нужна рынку, всё сегодня старое когда-то было "свежей кровью".

Remix OS

Начну с самого «свежего» анонса. Буквально на днях появилась альфа-версия принципиально 64-битовой Remix OS «для ПК». Проект, основанный на исходных кодах AOSP, интереcен просто потому, что его основатели – бывшие сотрудники Google. Трое основателей проекта – этнические китайцы c американским образованием университетах класса «из лучших», прошедшие через «школы» таких компаний, как Oracle и Google, стоящая за проектом компания Jide зарегистрирована в Пекине.  Из непродолжительной истории компании интересным является её ошеломляющий успех на Kickstarter – двумя проектами она собрала почти $2 млн.

Вопреки журналистской традиции «пиши о хорошем», начну со строго противоположного. Альфа-версия – это понято что. Это практически «не работающее», или «работающее чудом». С чем, в принципе, все согласны. Но «несчастный случай» (дальше будет понятно, о чём речь и почему так жёстко) Remix OS даёт новые уроки «как нельзя выводить на рынок альфа версии».

Во-первых, дистрибутив рассчитан на запуск на реальной, физической машине. Это, вроде, небольшой нюанс, но. Раз альфа-версия, то она рассчитана на, в первую очередь, разработчиков. А что «святое» у любого разработчика? Его инструмент. Реальная, «физическая» машина. Да, дистрибутив не требует инсталляции, да, он работает с запуском с флэш-накопителя, но даже временно «выводить из строя» физическую «боевую» машину альфа-версией ОС – это немного слишком. Немногие на такое согласятся. Кроме того, дистрибутив устанавливает требование к пропускной способности шины USB-накопителя (более 20 MB/s, это USB 3.0 плюс реально быстрый накопитель). В 2016 году, когда проще «перебросить» любой файл с одной машины на другую с помощью неисчислимых сетевых сервисов, это требование неожиданно оказывается проблемой. Потому что просто или вообще нет USB-накопителя, или имеющийся покрыт пылью и очень стар, потому не соответствует требованию полосы пропускания шины. При этом никаких инструкций инсталляции ОС в популярных виртуальных машинах разработчик не даёт. В итоге получается почти идеальное руководство «как не надо», которое доводится до «как нельзя» особенностями инсталляции. Потому что даже если ваш флэш-накопитель обладает быстродействием, незначительно меньшим 20 MB/s, вы сможете попробовать эту систему (о чём нигде заранее не сказано). Только вам придётся подождать. Первая «инсталляция» ОС требует нечеловеческого терпения. В моём случае процесс длился почти час (несмотря на то, что никакой «установки» нет, это же вроде как live дистрибутив). Ещё хуже, что при инсталляции система «впадает» в загадочное состояние, никакими внешними признаками не обозначающее, что она «жива» и что-то делает. И уж совсем плохо, что об этом нюансе тоже никто ничего нигде не сказал.

К этим неприятностям добавился и небольшой «погром», который разработчикам Jide устроили дотошные аналитики Linux Forefront Project. Во-первых, поставляемый в составе дистрибутива исполняемый файл  remixos-usb-tool-*.exe оказался слегка модифицированной GPL-лицензированной программой UNetbootin (модификации крайне незначительны), при этом никакой информации о происхождении утилиты нет, как и обязательных согласно GPL исходных текстов. Во-вторых, компания Jide очень быстро, но довольно странно и категорично реагирует на запросы раздражённых этим фактом программистов. И, наконец, на фоне таких незначительных деталей совсем уж забавно и неожиданно смотрится собственное лицензионное соглашение ОС, которое почему-то распространяет действие Конституции Китайской Народной Республики на всех пользователей, безотносительно их гражданства, и вообще не упоминает лицензирование базовой системы Android x86 (Apache Public License 2.0) и всё, что оно требует. Впрочем, поднятый в среде разработчиков шум в Jide в итоге не оставили без внимания, и нюансы с лицензированием в итоге компанией были устранены.

Желающим попробовать этот дистрибутив (такое желание может быть подкреплено одним – участием в его разработке) могу порекомендовать инсталляцию в виртуальной машине. Например, в VirtualBox необходимо создать виртуальную машину для 64-битовой ОС семейства Linux (соответственно, лучше всего, если основная ОС вашей машины 64-битовая, а если вы работает в основной ОС Windows, вам вероятно понадобится включение в BIOS Virtualization Technology и VT-d, а в меню Windows Feature – выключение Hyper-V), а при запуске виртуальной ОС вызвать клавишей TAB меню дополнительных параметров и указать строку «VGA=791» без кавычек (иначе будут проблемы с управлением курсором).

Итогом этих увлекательных процедур будет в целом вполне рабочая ОС. И вполне «настольная». Только пока «медленная» и иногда впадающая в «коматозное состояние». Настольно-мультизадачная, с традиционным и привычно невидимым оконным менеджером (перемещаемые окна изменяемых размеров) с таскбаром и панелью нотификаций, с нормальным управлением курсором с точным позиционированием мышкой, с цельным (спасибо Android Lollipop) «материальным» дизайном интерфейса, естественно, с хорошим браузером (Chrome) и с возможностью использовать в этом окружении «родные» приложения Android по принципу «отдельное приложение – в отдельном окне». Выглядит всё это очень мило и цельно, намного «красивее» большинства дистрибутивов Linux.

В целом, система пока «сырая» (всё-таки, альфа-версия очень серьёзных модификаций ОС Android), но многообещающая. Отбросив начальные сопровождающие её «в нагрузку» перечисленные выше странности, можно говорить о ней, как о действительно интересном проекте. Возможно, все эти странности – просто «болезни роста» проекта и попытка защитить его от уже существующих нескольких конкурентов.

TBC

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT