На днях (18 сентября 2014 года) появился крайне интересный не совсем документ (юридической силы он не имеет) очень уважаемого в индустрии автора, участника и эксперта «технических расследований», расставляющий точки над «i» в оказавшейся очень непростой истории с автомобилями Toyota. Истории поучительной, если использовать доступные результаты по назначению. Но здесь надо сразу сделать важное отступление, потому что в явном виде формулировка, которой посвящено отступление, мне пока не попадалась на глаза. Так что считайте это спорным, уникальным и чем угодно, я постараюсь насколько возможно в формате статьи всё объяснить и даже проиллюстрировать ссылками. К сожалению, без этого обширного отступления всё последующее может оказаться бессмысленным.
Наблюдая за далёкими и нисколько особо никого не затрагивающими событиями, вынужден резюмировать — уже и компании-гиганты стали обращать пристальное внимание на бизнесы в «длинном хвосте». Там неожиданно оказалось много денег, но не это главное. Там находятся неизмеримые деньгами ресурсы, обеспечивающие то, что принято называть «инновациями». Потому что с инновациями (точнее, без них) всё очень плохо. Это «очень плохо» видно невооружённым глазом. Microsoft провела за пол года два очень ощутимых сокращения персонала (примерно 14% штата, и второе сокращение буквально на днях «выкосило» фрагмент как раз вроде бы нацеленной на инновации Microsoft Research, а также полностью Microsoft Robotics, вовсе не о подразделениях Nokia идёт речь). Apple, несмотря на бравурные результаты, упорно показывает такое «новое», от которого уже откровенно зевают все, и даже у яростных апологетов не хватает сил дольше двух дней после анонса высасывать из пальца мучительные тексты в традиционном стиле «почему вы должны это купить» (я это вижу по своей rss-подписке, уже всё прошло и все забыли). Sony вынуждена была признать переоценку мобильных подразделений, вызвавшую потери порядка $1,7 млрд. Toshiba реструктуризирует PC-подразделения, читай — сокращает 900 рабочих мест. Очень интересна тактика Intel — корпорация буквально рвётся в новые технологические нормы, 14 нм, 7 нм (а это новые фабы и колоссальные затраты), но радикальных архитектурных изменений в фактически достигших совершенства процессорах всех семейств мы не видим. Потому что совершенство практически достигнуто, и любое незначительное улучшение даётся уже очень большой «кровью бизнеса», то есть деньгами, умноженными на время. Перечислять подобное можно долго, это вовсе не «ужас и кошмар». Это очередной виток технологического развития на этапе насыщения. Платёжеспособные рынки пресыщены, рынки третьих стран — насыщены, нужны свежие ниши. Всем. Независимо от масштабов. Ситуация усложняется непозволительными провалами гигантов и агрессивностью новых игроков в неожиданных для них сегментах рынка. То Windows RT незаметно отпоют и забудут настолько, что вроде её и не было никогда, то «настольная» 8.1 окажется такой удачной, что срочно надо выводить на рынок 9-ю версию. То, вроде как сугубо «сервисная», Google своими обновлёнными бюджетными сериями смартфонов и планшетов (Moto G, Nexus) так высоко установит планку «цена-качество», что от этой высоты покрываются льдом ужаса сердца многих привычно кормившихся высокой доходностью рынка мобильных терминалов. То уже многократно объявленная сдавшейся Samsung, внезапно упорно оживляет свою ОС Tizen и, несмотря на всё, активно эту ОС продвигает. То Blackberry окажется вполне живой и даже угрожающей. В общем, одну из главных причин всего этого кратко можно описать примерно такой фразой — «ориентированный на массовый рынок вычислитель в любом исполнении стал расходным материалом». Срок службы такого вычислителя определяется массой факторов, но он очень недолог. Скажем, два-три года — это уже долго. Особенно для устройств с аккумуляторным питанием (а они теперь самые массовые). Платить дорого за это потребитель уже не хочет. И не только в третьих странах. Имиджевый фактор сильно ослабел (опять же, следствие насыщения рынков), технические параметры особо улучшать дальше некуда, все инновационные приёмы уже перепробованы: разницы в разрешениях экранов никто не видит невооружённым глазом, ± 200 MHz тактовой частоты неощутимы, даже передовую 64-битовость уже задействовали, причём именно там, где она крайне сомнительна — в вычислителях с физическим адресным пространством, чуть ли не в 2 раза меньшим, чем позволяет 32-битовое слово, при де-факто отсутствии приложений, которым реально нужны возможности 64-битовых вычислений с плавающей точкой (потому что всё, что связано, например, с цифровой обработкой сигналов, всё равно выносится в «облака», для серьёзных задач из этого класса только «ширины слова» и DSP-возможностей процессора крайне недостаточно). Остаются две очевидные возможности — дизайн (это же не столько технологическое, сколько очень человеческое и потому оно «работает всегда») и насыщение уже «традиционного человеческого» новыми возможностями (далеко не первый вал smartwatches уже «пошёл»). Этого слишком мало для активного движения. И тут все заметили «длинный хвост». В котором всё время что-то кипит и варится. И все побежали. И у каждого, кто вчера ещё был принципиально страшно далёк от специфики и интересов «длинного хвоста», внезапно стало появляться и своё видение, и даже целые «платформы» (например, у Microsoft, или вот чудесный пример от Intel, кроме уже известных Quark и Edison — 3G модем для IoT, а вот и много лет назад удалившаяся от массовых потребительских рынков Ericsson «неожиданно» занялась переориентацией своего бизнеса, и тут же столкнулась с нехваткой квалифицированных инженеров, и ещё есть китайские производители, заявляющие о себе чуть ли не каждый день, и всё чаще — очень неожиданно, на компонентном уровне, с собственными уникальными разработками, и весь поток таких событий совершенно невозможно описать в обозримых объёмах текста). Ещё нагляднее процесс виден в поведении разработчиков вчера крайне специфических программных пакетов «сугубо для узких специалистов». Здесь настоящая новая технологическая революция. Успехи и востребованность первопроходцев замечены и поняты настоящими «монстрами» в своих отраслях. Вот Altium «выкатывает» сервис для разработчиков из «длинного хвоста», вот уже созданные дистрибьютором электронных компонентов Electrocomponents plc сервисы и программное обеспечение Designspark объединяют более миллиона (!) пользователей-инженеров (картина «длинного хвоста в натуральную величину» отлично просматривается в отчёте компании), вот уже Wolfram предлагает идеально междисциплинарный сервис Alpha, вот канадцы, Upverter, меньше чем за два года формируют (на инвестициях YCombinator) сервис проектирования электроники, такое тоже можно перечислять долго. Продукция пользователей всех этих сервисов ведь куда-то девается и кем-то востребована (иначе откуда бы они все взялись)? И она явно не крупносерийная (большие производители работают напрямую с поставщиками компонентов). Это и есть отлично видимая «голова длинного хвоста», такой вот каламбур. Почему всё это выпадает из поля зрения в пост-советском пространстве? А оно выпадает, востребованность всех услуг той же Electrocomponents plc ненавязчиво об этом напоминает, чёрное и серое — «практически невостребовано»:
У меня есть версии ответов на этот вопрос, но я не специалист ни в социологии (которая в пост-СССР нечто среднее между оскорблением и синекурой), ни в урбанизации, ни в ещё в списке нужных для серьёзного ответа дисциплин), посему промолчу, каждому для нахождения вполне разумного ответа достаточно здравого смысла, жизненного опыта и наблюдательности.
Итак, короткий результат обширного отступления. «Длинный хвост» стал интересен всем. Если оценки и прогнозы развития IoT отражают качественную готовность индустрий к этому явлению (количественные оценки — гадание на кофейной гуще), то IoT безусловно та область, в которой неизмеримо и необъятно разнообразные потребности неисчислимых потенциальных конечных пользователей не сможет удовлетворить ни один «монстр» IT, ни конгломерат «монстров». Это громадные бизнесы для сонма производителей, работающих на «длинный хвост». Потому все «монстры» озаботились обязательными заявлениями о «видениях» и «платформах» — системообразующие сверхкомпоненты и узлы в этой области обещают очень много денег. А инновации перекладываются на плечи мелких производителей, которым и выдумывать «на местах», что можно со всей этой незаконченной, базовой красотой сделать такого, чтобы конечный потребитель закричал «ах!» и начал лихорадочно рассчитываться. Ничего неожиданного и неочевидного во всём этом нет, все индустрии с материальным продуктом всегда так развивались, так что это и следствие «дозревания IT до традиционной индустрии».
К сожалению, всё ещё не настала пора поговорить о тех «подводных камнях», которые могут быть и непременно будут в этом непростом процессе «дозревания». Ещё нужно вернуться к истории Toyota. Здесь я немного повторюсь (уже писал об этом в блоге), но постараюсь по возможности лаконично.
Процесс выяснения причин и обстоятельств проблем с автомобилями Toyota начался всерьёз с крайне печального события — 28 августа 2009 года в Сан Диего (США) погибли водитель Lexus’а ES 350 Марк Сейлор (Mark Seylor) и трое его пассажиров, из которых кто-то успел позвонить 911 и в панике сообщить о неуправляемом наборе скорости машиной (статья в The New York Times):
Тогда виновником аварии объявили коврики, которые смещались и поддавливали педаль газа. Поиск виноватых облегчался тем, что история с ковриками начиналась ещё в 2007 году, и вызывала уже отзывы машин с рынка. Но уже в 2010м стало понятно, что коврики не при чём. Потому что количество жалоб на разгоняющиеся по собственному желанию машины выросло до более чем 6000, а количество жертв аварий — до заявленных 89 и 57 раненых. Toyota отозвала с рынка более 8 миллионов автомобилей для доработок, и дошло до того, что Президент Toyota свидетельствовал перед Конгрессом США (в апреле 2010го). В процесс расследования инцидентов были вовлечены специалисты NASA, которые в течение почти двух лет (2010 — 2011) пытались разобраться с бортовой электроникой Toyota, в первую очередь с электронной системой управления дроссельной заслонкой (Electronic Throttle Control System, ETCS). Несмотря на очень чёткое название, подсистема ETCS является жизненно важной для всего управления автомобилем, в том числе и для подсистем управления торможением. Итогом расследования NASA стало... почти ничего. Что неудивительно — в реальности невозможно восстановить всё, что может быть возможным в ходе многолетней эксплуатации восьмимиллионного парка автомобилей. Но скрупулёзные специалисты NASA, всё-таки, высказали обоснованные (об этом чуть позже) подозрения: «Доказательств гипотезы об ошибках в работе ETCS, приводящих к чрезмерному открытию дроссельной заслонки... не было найдено в результате проведенных тестов аппаратных и программных средств. Этот факт не означает, что ETCS не может быть причиной подобного события...». Чёткий вердикт специалистов NASA трансформировался в окончательное заключение, без допущений, Министра Транспорта США Рея ЛаХуда — «Мы привлекли лучших ярчайших инженеров для изучения электронных систем Toyota, и получили заключение: доказанных причин вызванного электроникой неконтролируемого роста скорости в автомобилях нет». Хорошая иллюстрация взаимоотношений инженерного и юридически-делового видений одной и той же проблемы, на удивление неоспоримых для двух точек зрения. Казалось бы, вопрос закрыт. Но не тут-то было. В 2013 году, несмотря на вердикт Министерства Транспорта, один из долгих судебных процессов против Toyota был завершён в пользу истца. В 2007 году 76-летняя Джин Букаут и её пассажирка Барбара Шварц попали в тяжёлую аварию на Toyota Camry 2005го года выпуска. Причиной аварии стал неконтролируемый разгон автомобиля. Эксперты Toyota пытались объяснить причину разгона возрастом Джин Букаут и, грубо говоря, тем, что она «перепутала педали». Но эту версию разгромили представители дорожной полиции простейшим фактом с места происшествия — попыткой использования для торможения машины даже ручного тормоза и почти 46-метровым следом жжёной резины шин на дорожном покрытии. В итоге, несмотря на категорическое несогласие представителей Toyota любыми версиями о причинах аварии, кроме вины самой Джин Букаут, корпорация выплатила пострадавшим $3 миллиона. В этом же году Toyota была вынуждена заплатить $1,1 миллиард истцам в групповом иске, за экономически потери, вызванные неконтролируемым разгоном автомобилей. И, наконец, уже в марте 2014 года суд США наказал Toyota еще на $1,2 миллиарда за «постыдное поведение» и «вопиющее неуважение к закону» (эти слова не выдуманы, именно так жёстко высказался генеральный прокурор США Эрик Холдер), выражающееся в сокрытии дефектов автомобилей. Правда, список дефектов, по мнению многих признанных специалистов из мира встраиваемого (embedded) компьютинга, оказался хоть и юридически верным, но не отражающим глубинных причин — в нём опять злополучные коврики и «залипающая» (неизвестно почему) педаль газа. Это судебное решение вызвало фундаментальную перестройку внутрикорпоративной структуры Toyota, направленную на повышение безопасности производимых автомобилей, и на этом мы заканчиваем все юридически-событийно-аварийные отступления, и возвращаемся к близкой IT сути.
Из-за большого резонанса и полной открытости всех процессов в ходе изучения электроники и ПО Toyota специалисты в области встраиваемых систем обратили внимание на целый ряд особенностей и нюансов, которые трудно (но, безусловно можно) объяснить, например, юристу или менеджеру высокого уровня.
Во-первых, если посмотреть на компоненты подозреваемого электронного узла (ETCS), можно заметить, что в нём используются два независимых микроконтроллера:
Красным прямоугольником отмечен основной вычислитель узла ETCS, синим — микроконтроллер, осуществляющий функции мониторинга работы основного вычислителя. Обе микросхемы исполняют собственное программное обеспечение, но специалисты NASA изучали только встроенное ПО основного вычислителя.
Во-вторых, несмотря на заявленную производителем поддержку подсистемой встроенной оперативной памяти основного вычислителя механизмов защиты от сбоев любого бита (SEC, Single Error Correction) и обнаружения сбоев в двух и более битах (MED, Multiple Error Detection), оказалось, что в микросхемах этого узла, выпущенного до 2006 года, нет ни SEC, ни MED вообще, а в более современных есть только SEC. Это совсем не «игрушечная» деталь. Дело в том, что вызываемые случайными высокоэнергетическими нейтронами (которых в бесконечной Вселенной бесконечное количество) сбои в работе полупроводниковых устройств хоть и редки, но не настолько, чтобы не обращать на них внимание в некоторых случаях. Так, частота сбоев в одном бите микросхемы оперативной памяти из-за высокоэнергетических нейтронов оценивается специалистами (Obermaisser, «A Fault Hypothesis for Integrated Architectures», 2006) на уровне 1 за 100 тысяч часов, и примерно 2% таких сбоев являются критически опасными для функционирования микросхемы (и, возможно, всего устройства, которое её использует). 2 критических сбоя за 10 миллионов часов — это, вроде, не цифра. Но. При объёмах производства и сбыта порядка 500 тысяч автомобилей в год, и при предположении, что средний водитель пользуется автомобилем 1 час в день, результирующий пробег всей этой армады за год получается впечатляющим — порядка 182 миллионов часов. При возможных двух критических сбоях за 10 миллионов часов получаем порядка 36 сбоев во всём 500-тысячном парке, или примерно один критический сбой каждые 10 дней. И не забываем, что речь идёт о сбоях в одной микросхеме памяти всего (или в одном микроконтроллере со встроенной RAM).
В-третьих, программная сложность ETCS оказалась очень высокой. Встроенное ПО основного вычислителя на уровне исходных текстов — это 256,6 тысяч строк языка C, и ещё 39,5 тысяч строк заголовочных (.h) файлов (чистый код, без комментариев). Заявленный Toyota уровень качества тестирования этого ПО эквивалентен пробегу в 35 миллионов миль (на уровне автомобиля как системы) и 11 миллионам часов работы модуля ETCS, оперативное тестирование каждого автомобиля, сходящего с конвейера, по оценкам специалистов, не превышает одного-двух часов.
В-четвёртых, так как законы США не требуют сертификации встраиваемого ПО автомобилей, и, видимо, по ряду ещё многих причин, разработка встраиваемого ПО велась без соблюдения рекомендаций Ассоциации Надёжности ПО Автомобильной Индустрии MISRA (Motor Industry Software Reliability Association), и сами представители Toyota никогда такого не утверждали. Рекомендации MISRA (в том числе и рекомендуемое подмножество языка С) — это не прихоть и не «ещё одна корпоративная забава», они формировались обширным опытом огромной индустрии и рациональность их обоснована до уровня правил вроде «каждым тридцати нарушениям MISRA в исходном коде соответствует одна серьёзная ошибка в исполнении этого транслированного кода». И вот за «соответствие» Toyota принятой в индустрии культуре embedded-кодирования экспертами был устроен настоящий погром (не-программисты могут пропустить всё последующее до конца абзаца). Экспертиза Майка Барра (Mike Barr) выявила 80 тысяч нарушений MISRA C (не всех вообще рекомендаций MISRA, а всего лишь подмножества языка С). Больше того. Embedded-программисты вообще часто не следовали никаким правилам и культуре весьма опасного языка С, достаточно сказать, что из 343 операторов switch во «всего лишь» 105ти не были на основании каких-то допущений использованы default ветки исполнения (может быть, где-то их просто забыли). Анализ исходных текстов ETCS с помощью заслуженно популярной системы статического анализа и контроля качества ПО Codesonar выявил 2272 глобальные переменные разных типов, причём 64 объявлены многократно, а 97 из объявленных нигде не используются, а также 22 неинициализированные переменные. Более детальный анализ выявил 11528 неконстантных глобальных переменных, из которых 6971 по мнению программистов NASA могли быть локальными (читай — должны были ими быть), а область видимости ещё 1086 могла быть ограничена модулем (файлом). Для любителей совсем острых ощущений, цитирую «не все глобальные переменные были объявлены volatile» (это при том, что код — «многозадачный», с разделением времени между задачами). Другие, не менее серьёзные пакеты анализа отыскали такие «перлы», как инициализацию 16-байтового массива 17ю значениями, 5 рекурсивных процедур (что во время исполнения приводит к постоянному 94% использованию области оперативной памяти, выделенной для стека, при этом стек растёт в сторону адресов, где в ОЗУ располагаются глобальные переменные), 99 условных операторов с побочными эффектами (изменяющих в коде проверки значения переменных), 333 случая потенциально опасных приведений типов (с возможным изменением значения). Классический анализ сложности структурированного кода (цикломатическая сложность МакКейба) выявил 67 функций с уровнем сложности выше 50 (в классике структурного программирования этот уровень сложности считается нетестируемым) и одну, самую главную, управления углом дроссельной заслонки, с уровнем сложности 146 при 1300 строках кода. Это настолько впечатляющая цифра, что я вынужден иллюстрировать её, благо, есть возможность «мощным научным методом» реконструировать это. Цикломатическая сложность МакКейба для подпрограммы (а мы о ней и говорим) описывается формулой M = E — N + 2, где E — число линейно исполняемых фрагментов кода, N — число любых операторов, формирующих «нелинейность» поток исполнения (ветвлений, циклов, селекторов). Нам известно число строк подпрограммы (1300), и при такой сложности мы можем допустить, что самая короткая возможная линейно исполняемая последовательность кода в нём — одна строка. Тогда E + N должно быть равно 1300. А E — N + 2 = 146. Из чего следует, что в функции из всего 1300 строк должно быть 578 «нелинейных» операторов и 722 линейно исполняемых фрагмента. Можно попробовать сгенерировать случайный граф с 578ю узлами и 722 рёбрами, чтобы представить себе, о чём вообще идёт речь:
Кружочки на этой «весёлой картинке» могут быть всякими if-then-else, for, do-while, switch. А случайность графа при такой цикломатической сложности совершенно оправдана (внимание, это была ирония!). С многозадачностью ETCS также всё оказалось не слава богу, здесь даже была найдена классическая ошибка (две задачи с одинаковым приоритетом не могут прервать друг друга, что в итоге может привести к очень странной модификации глобальных данных). Заодно и операции модификации не всех глобальных переменных оказались атомарными. Совершенно удивительной логике была подчинена работа «сторожевого таймера» системы (watchdog), его действие не распространялось на ключевые подпрограммы (в том числе и того самого главного кошмара с цикломатической сложностью 146), при этом коды ошибок операционной системы реального времени (RTOS) игнорировались вообще (к слову, неудивительно, что в режиме исполнения всё это непрерывно загружало процессор микроконтроллера главного вычислителя более чем на 80%). Из результатов анализа технологической стороны кода ETCS также можно почерпнуть нечто интересное — оказывается, при разработке не использовались ни системы контроля версий, ни управления конфигурациями, ни, тем более, формальных спецификаций, большинство немаленьких подпрограмм (более 75 строк чистого кода) не сопровождалось комментариями вообще, неформальному обзору и инспекции кода подвергались только несколько модулей.
Кажется, с обязательной вступительной частью закончено. И теперь уже точно можно сложить одно с другим, и получить нечто третье, возможно, кому-то важное и полезное. С одной стороны мы имеем массовый интерес к «длинному хвосту», там сейчас интересно всем, в том числе и миллионам (да, речь уже идёт о миллионах) разработчиков малосерийной продукции, и их заказчикам (потому что мелкие, но очень нужные «конкретно здесь» инновации тут и делаются, и индустрия с этим не просто соглашается, а стимулирует процесс), и их поставщикам. А с другой стороны мы имеем ужасы «культуры embedded программирования», которые нам продемонстрировала трагическая история c Toyota, и если бы череды трагедий и человеческих жертв не было, мы, возможно, никогда бы этих познавательных ужасов и не увидели бы. И если у Toyota в «невидимом программировании» творится такое, при японской корпоративной культуре и дисциплине, то что уж говорить о малых производителях, ещё и инновационного характера, спешащих как можно быстрее донести рынку свои творения. Ничего хорошего, наверное, так что лучше ничего и не говорить. Но и ничего страшно плохого тоже, всё надо перерасти, и всему можно научиться. Хотим мы того, или нет, через год-другой потный вал IoT вдохновения докатится и до нашего рынка, это неизбежно, раз самые большие уже побежали в эту область. Так что, есть некоторые очевидные соображения, предваряющие и даже исключающие возможные позоры и потери денег (конечно, не такие, как у Toyota, по которой вся эта история ударила весьма тяжело, отзывы миллионов машин — это уже астрономические затраты, и ещё судебные миллиарды).
Первое, что начинает тревожить в мире IoT — уже проявляющееся увлечение сложностью. Понятно, что поставщики «платформ» стараются адаптировать имеющееся для новой потенциально привлекательной ниши. Но и большие, избыточные системы, не кажутся очень уж перспективными для сонма устройств, назначение которых в первую очередь — не создавать лишних проблем, которых не было до этих устройств. Любое лишнее и неоправданное усложнение — зло, и если раньше это было забавное зло, то с приходом IoT оно может утратить всякую обаятельностью. Если совсем «мелкая» по меркам, скажем, мира «настольного ПО» программа ETCS Toyota (всего-то порядка 300 KLOC) оказалось при рассмотрении «под микроскопом» таким кошмаром (и всё равно работающим в подавляющем большинстве случаев), то что говорить о «монстрах» с десятками миллионов строк кода? Из этого простого соображения следует очевидный обоснованный скепсис по отношению к жизнеспособности IoT-применений всяких адаптаций ПО из не-IoT миров. Увы, это новый мир, и он требует нового. Предельно простого в первую очередь. Или формально верифицированного. Или и того, и другого (в идеале). То же самое можно сказать и о протоколах сетевого (что ещё хуже — часто беспроводного) взаимодействия, и об их безопасности, и о подсистемах аутентификации. Всё это только на стадии осмысления, по большому счёту. Есть яркие разработки, но они даже не внедряются, а и одобряются далеко не с той скоростью, которая могла бы обещать что-то вразумительное во вразумительные сроки. Далеко не всё хорошо (точнее, всё совершенно ужасно) с технологиями программирования для IoT-устройств. Де-факто сверхстандартный ANSI С и сомнительно подходящий для реализации высоконадёжных систем C++ — вот, собственно, и весь выбор пока. К сожалению, ни первый язык, ни, тем более, второй, в реальности очень далеки от потребностей разработчиков. C слишком изобилует зафиксированными нечёткостями и неоднозначностями даже на уровне спецификаций языка, а С++ просто слишком изобилует всем (настолько, что рекомендации той же MISRA оставляют от него разумное почти ничего). И в ближайшие несколько лет картина в этой области не изменится, ничто не предвещает перемен, разработчиками компиляторов затрачены огромные усилия на совершенствование своих продуктов, система образования адаптировалась к производству специалистов, из этой замкнутой системы выхода пока не видно. Ещё хуже обстоит дело с профессиональной междисциплинарностью. Например, повышение надёжности системы в мире IoT не решается только программными средствами, это классическая аппаратно-программная задача. А вот её практическим решением занимались считаные единицы специалистов из очень закрытых областей (авионика, медицинская техника). И методы, приёмы, решения в этой области выходят за пределы знаний подавляющего большинства хорошо классически подготовленных и программистов, и инженеров-конструкторов. «Игривый» характер развития IoT не добавляет к этому очевидному факту радужности перспектив. «Самоучки по классу Arduino», безусловно, в мире IoT могут сказать и скажут своё слово когда-нибудь, но реальный этот мир требует намного большего.
Получился, конечно, немного странный материал, в котором предварительные части больше, чем посвящённая сути. Много чего в подготовке IoT уже сделано, и сделано очень хорошо. Есть и доступные очень развитые среды сквозной разработки (яркий пример — MPLAB® Harmony), и целые завершённые системы (Contiki, RIOT, FreeRTOS), делаются попытки уже на уровне стандартизации определить простой и удобный протокол (MQTT), очень быстро и изобильно развиваются подсистемы беспроводной связи. Всё это буквально «взорвалось» за каких-то полтора года, и это уже очень много. Осталось только учесть «некоторые нюансы», показанные нам Toyota, чтобы не повторять ошибок. Пример со сложным расчётом «на пальцах» количества сбоев в работе электроники при большом тираже изделия и непрерывной его работе был приведен не случайно. IoT — это намного больше изделий, работающих непрерывно. В этом случае надёжность становится критическим показателем, и её надо обеспечивать за копейки, иначе это никому не будет нужно — ну какой пасечник, например, поставит в ульи IoT-мониторы веса сот, температуры, влажности и звука, при стоимости такого удовольствия $10K за единицу? Разве что не очень психически здоровый и очень богатый пасечник, а такого попробуй найди.
Про DCIM у забезпеченні успішної роботи ІТ-директора
1. Что-же делать
http://johndayautomotivelectronics.com/automotive-automation-lessons-fro...
2. Выбор Toyota
http://www.adacore.com/press/toyota-itc-japan-selects-spark-pro-language...
3. От теории к практике
http://www.spark-2014.org/entries/detail/using-spark-to-prove-aorte-in-r...
4. Практика
http://electronicdesign.com/dev-tools/armed-and-ready
http://www.embeddedrelated.com/showarticle/625.php
опять Ada
есть очень большие и обоснованные сомнения
начиная с внутренней готовности эмбеддеров таёты осилить Ada (на это нужно много времени + ещё и практический опыт, а язык очень перетяжелённый, и ведь ещё в нагрузку язык описания для верификации есть, насколько я понимаю)
на универсальный рецепт это никак не "тянет", даже не из-за серьёзной ограниченности возможностей кросс-средств, а просто потому что почти нет специалистов.
собственно, таёта для исследовательского проекта в это играет, было бы очень странно, если бы они сломя голову кинулись в такое в реальной своей промышленной части.
так что єто интересно, потому что очень не ново, но никак не лекарство :(
ps
смешная описка была, извините, я не специально