Важно: эта статья написана для оценки безопасности паролей и графических паттернов, используемых владельцами мобильных устройств. Если вы решите разблокировать мобильное устройство с помощью описанных методов помните, что все действия по разблокировке устройств вы совершаете на свой страх и риск. При манипуляции с мобильными устройствами вы можете заблокировать устройство, стереть пользовательские данные или привести устройство в неисправное состояние. Также даны рекомендации пользователям, как повысить уровень защиты своих устройств.
PIN | Частота, % |
---|---|
1234 | 10,713 |
1111 | 6,016 |
0000 | 1,881 |
1212 | 1,197 |
7777 | 0,745 |
1004 | 0,616 |
2000 | 0,613 |
4444 | 0,526 |
2222 | 0,516 |
6969 | 0,512 |
9999 | 0,451 |
3333 | 0,419 |
5555 | 0,395 |
6666 | 0,391 |
1122 | 0,366 |
1313 | 0,304 |
8888 | 0,303 |
4321 | 0,293 |
2001 | 0,290 |
1010 | 0,285 |
В течение нескольких часов, после первого запроса ФБР, 6 декабря 2019 года, мы представили широкий спектр информации, связанной с расследованием. С 7 по 14 декабря мы получили шесть дополнительных юридических запросов и в ответ предоставили информацию, включая резервные копии iCloud, информацию об аккаунте и транзакциях для нескольких учетных записей.
Мы отвечали на каждый запрос незамедлительно, зачастую в течение нескольких часов, обмениваясь информацией с офисами ФБР в Джексонвилле, Пенсаколе и Нью-Йорке. По запросам следствия было получено много гигабайт информации, которую мы передали следователям. [17, 18, 19]
Однажды я спросил у своего знакомого: Что это у тебя за устройство все в пыли? Это видеорегистратор - ответил мой приятель. Пробовал настроить запись с камер по детекции движения, но в нужный момент ничего не писалось. А если и происходила запись, то, в основном, когда было не нужно - из-за изменений освещения, погодных условий, комаров и насекомых возле камеры. В общем, включил этот видеорегистратор в режим непрерывной видеозаписи и забыл про него. Надо проверить пишет ли он до сих пор ? Знакомая ситуация?
Если посмотреть на большинство крупных брендов, то на деле все они использует OEM поставки от одних и тех же китайских производителей почти с одним и тем же софтом внутри (Dahua и Hikivision).
Объединяет их всех одно крайне неудобный и пыльный интерфейс программного обеспечения в стиле 90-х. Тем не менее, рынок таких систем огромен, а спецы-слаботочники крайне непритязательны. Если монтажник системы сказал, что для видеонаблюдения нужен белый IP адрес и танец с бубном вокруг роутера, то без них никак. Результат хорошо известен большое количество взломанных IP камер и замечательные пранки над их владельцами.
Итак, приготовьте лупу. Выглядит китайский софт на современном компьютере с хорошим разрешением примерно так:
Скриншот программы SmartPSSСкриншот программы SmartPSSСкриншот программы CMSНа рынке существует множество тяжеловесных дорогостоящих систем для корпоративных пользователей. Чтобы удовлетворить запросы клиентов, такие продукты постепенно превращаются в монстров, для которых нужны выделенные дорогостоящие сервера и лицензии, внедрение, подробная документация и обучение. Все это делает систему тяжеловесной и недоступной для SOHO пользователей.
Современное программное обеспечение позволяет использовать компьютерное зрение в онлайн-режиме. Появление видеоаналитики положительно повлияло на ситуацию. Однако, она тоже имеет ряд недостатков, обусловленных высокой стоимостью обслуживания, сложными настройками и необходимостью содержания серверов с GPU картами.
Многие компании предлагают облачную видеоаналитику. Но этот подход имеет существенный недостаток - высокую стоимость трафика и самих сервисов.
Представленный на рынке софт для видео наблюдения можно разделить на следующие категории:
Небольшие программы, open source и подручные самописные средства.
Сложные дорогие программы, разработанные для корпоративных заказчиков. Они эффективно работают, но требуют больших затрат в обслуживании и специальной инфраструктуры.
Используемые по наследству морально устаревшие hardware-решения, неудобные в использовании и обладающие ограниченными возможностями. Они функционируют на основе старых алгоритмов видео-кодирования.
VSaaS (video surveillance as a service) - Облачные решения для записи и хранения видеозаписей с облачными сервисами. Такие сервисы часто предлагают уже преднастроенные ip камеры, привязанные к собственным облачным сервисам.
VSaaS значительно упрощает подключение устройств, но в этом случае приходится ежемесячно оплачивать услуги для каждой из ip камер. Эти услуги не дешевы и стоимость сильно зависит от желаемого срока хранения видеозаписей на сервере. Если вы хотите использовать, например, 10 камер, то стоимость выльется в существенную сумму - от 1000 до 30000 долларов в год в зависимости от срока хранения архива без учета стоимости оборудования. Т.е. каждый ежемесячный платеж может быть больше, чем стоимость самого оборудования. Стоимость облачных камер, как правило, существенно выше рыночных аналогов, несмотря на одинаковое железо внутри. Узким местом VSaaS является пропускная способность канала передачи данных.
При круглосуточной трансляции видео 1920х1080 (HD) в течение одного месяца каждая ip камера может съесть до 648 Гб интернет-трафика. При большой нагрузке провайдер может понижать скорость вашего соединения. Одна камера с высокой четкостью изображения, использующая продвинутые алгоритмы сжатия, например, H.264, генерирует поток данных со скоростью 2 - 10 Мбит/с. С другой стороны, средняя скорость исходящего канала в мире сейчас составляет только 5 Мбит/с.
Получается разрыв между текущими запросами пользователей VSaaS и возможностями каналов интернет провайдеров. Использование нескольких камер становится проблематичным, особенно для камер высокого разрешения. Суммарный поток данных при использовании 150 видеокамер разрешением 2 Мп (30 fps) для охраны периметра, имеет нагрузку на канал связи более 1 Гб/с. Удаленный просмотр, запись видео становятся ненадежными и невозможными. В итоге, облачное видеонаблюдение может превратиться в туманное с потерей важных данных. Многие пользователи уже успели разочароваться в таких сервисах из-за потери важных кадров.
Простой детектор движения сокращает поток. Однако, детектор может реагировать на случайные изменения картинки. Эту проблему решает технология интеллектуальной видеоаналитики в режиме реального времени, функционирующей на стороне абонента.
Нейросетевые технологии позволяют производить детекцию объектов, обнаружение людей и распознавание лиц, определение номеров автомобилей. Таким образом, в сравнении с обычным детектором движения, видеоаналитика может сократить нагрузку на канал связи и облачное хранилище в десятки раз. Очевидно, что облачная инфраструктура оказывается неэффективной для первичной обработки сырого видеоматериала. Чем лучше видеоаналитика, тем меньше нагрузка на каналы передачи данных.
С другой стороны, облачная инфраструктура может быть эффективно использована для горизонтального масштабирования системы видеонаблюдения - для хранение видео и данных видеоаналитики, для подключения новых объектов наблюдения, для обслуживания большого числа пользователей. Локальное хранилище NVR позволяет буферизовать данные. Оно увеличивает отказоустойчивость системы видеонаблюдения. Срабатывание по событию активирует запись и данные передаются в облачное хранилище в зависимости от загруженности канала.
Необходимо учитывать ограничения по скорости передачи, а также наличие сложных топологий с трансляцией адресов (NAT) и сетевыми экранами. Как правило, большинство технологий, которые для этого используются, требуют присвоения камере или видеорегистратору дорогостоящего белого IP адреса, сложной процедуры настройки с использованием сервисов VPN, UPnPct или DDNS.
Интернет провайдеры предоставляют услуги подключения к сети интернет на основании динамически изменяющихся IP адресов из определенного массива. При каждом входе в сеть этот адрес для пользователя изменяется, что требует систематической перенастройки камер системы видеонаблюдения. Провайдер может предоставлять внутренний IP адрес подсети, который будет отличаться от внешнего адреса. Белый статический IP адрес провайдер выделяет на платной основе и стоит эта услуга недешево. Как известно, общее количество IPv4 - адресов в мире ограничено и все они были розданы уже много лет назад. IPv6 - адреса многие камеры до сих пор не поддерживают. Но главная проблема использование внешнего IP адреса для IP камеры крайне небезопасно. IP камера - это простенький и малозащищенный микрокомпьютер, что приводит к большому количеству взломов и утечек информации.
В последнее время благодаря новым решениям и технологии P2P (peer to peer) можно установить и настроить удаленное видеонаблюдение самостоятельно и очень легко.
Технология эта уже не нова, она, например, широко используется многими популярными мессенджерами. В основе технологии лежит алгоритм, согласно которому устройства общаются между собой напрямую децентрализованно без выделенных ip адресов. Пиринговый протокол отличается от привычной клиент-серверной архитектуры отсутствием выделенного сервера, так как каждый узел одновременно выполняет функции, как клиента, так и сервера.
Основная часть затрат в содержании сервисов облачных решений складывается из расходов на оплату трафика, а также содержание серверов кодировки и декодирования потоков видеосигнала. P2P технологии исключают подобные расходы для поставщика сервиса. Для соединения используются сигнальные сервера, которые всего лишь соединяют между собой камеры и удаленные устройства.
В итоге, Р2Р отличается более эффективным использованием полосы пропускания канала. В этом случае не требуется дополнительная облачная ретрансляция и обработка видеопотока (кодирование/декодирование) и пользователь не зависит от бутылочного горлышка возможностей облачного провайдера. Сервер в данном случае выступает только в качестве посредника, пробивающего NAT, связывающего вашу IP-камеру и устройство пользователя напрямую. Видеопоток передается напрямую от одного вашего устройства к другому вашему компьютеру или мобильному устройству.
Простота настроек сетевого оборудования - основное преимущество Р2Р технологии перед другими способами передачи сигнала. Возможность работы с серыми и динамическим IP позволяет установить видеонаблюдения в местах, где нет доступа к проводному интернету. Достаточно будет приобрести 3G/4G модем с поддержкой Wi-Fi и настроить программное обеспечение.
P2P видеонаблюдение совмещает в себе систему удаленного доступа к компьютеру и программу получения изображений с видеокамер. Введя определенный код и пароль (аналогично тому, как это делается в приложениях для удаленного доступа к компьютеру), вы можете вести видеонаблюдение и управление системой.
Подробнее можно посмотреть на видео.
Для осуществления мониторинга системы видеонаблюдения вы можете использовать как стационарный ПК или ноутбук, так и мобильные устройства: планшеты, смартфоны. Качество изображения зависит только от ширины канала и стабильной работы связи.
У некоторых китайских производителей камер сейчас есть свои облачные и P2P сервисы. Однако, такие сервисы имеют очень специфический интерфейс, нестабильны и медленны, рассчитаны на крайне непритязательных китайских пользователей. Как правило, требуется установка ActiveX расширений и использование определенных версий браузеров и flash-плагинов, а сервера могут располагаться за великой китайской стеной.
Облачный сервис для камер HikivisionДля китайцев характерен принцип Чабудо. В переводе с китайского в буквальном смысле это означает - да вроде же ничего, и так сойдет, совсем небольшая разница. Он может проявляться в том, что вам, например, скажут, что onvif протокол на ip камере не нужен, так как он уже устарел, или вам поставят розетку неправильного размера, унитаз установят на балконе и т.д..
Чабудо полная противоположность позыву сделать свое дело качественно и с полной отдачей. Дверь не подходит к раме? Чабудо, можно привыкнуть закрывать ее пинком. Алиэкспресс прислал ip камеру, которая глючит? Чабудо же, она хоть и криво, но работает, на что ты жалуешься? Интерфейс неудобный, не рассчитан на крупные шрифты и высокое разрешения монитора? не проблема, китайские пользователи вполне cмогут использовать, поменяв разрешение экрана.
Удивительно, но до сих пор обычный пользователь или небольшая компания практически не имеют возможности купить недорогой и качественный продукт с искусственным интеллектом. Если вы попробуете найти решение, которое можно установить на домашний компьютер для видеонаблюдения на основе искусственного интеллекта, вы обязательно столкнетесь с так называемыми лэндингами или дорвеями. Они представляют собой небольшие сайты, красиво описывающие преимущества какой-либо системы. Однако, на сайте в реальности отсутствует возможность протестировать рекламируемый продукт, и даже нет конкретной цены владения. Вам будет предложено заполнить стандартную форму со своими данными для дальнейшей связи. Вероятнее всего их система еще не готова, либо компания проводит предварительное исследование потребительского спроса для очередного стартапа.
Сочетание искусственного интеллекта и Р2Р технологией дает возможность быстрого построения эффективной системы видеонаблюдения без привлечения дорогостоящих специалистов. Простота настройки и эксплуатации не требуется знаний протоколов связи и каких-либо особых требований. В этом случае не нужна дополнительная облачная ретрансляция и обработка видеопотока (кодирование/декодирование) и вы не зависите от бутылочного горлышка возможностей облачного провайдера. Сервер в данном случае выступает только в качестве посредника, связывающего вашу IP-камеру и устройство пользователя напрямую. Видеопоток передается напрямую от одного вашего устройства к другому вашему компьютеру или мобильному устройству.
Для осуществления детекции объекта применяются оптимизированные алгоритмы нейронных сетей на стороне клиента. Они способны работать на относительно дешевых чипах и процессорах микрокомпьютеров. Данные передаются посредством пиринговых соединений в обход облачных сервисов без излишнего кодирования и декодирования. Р2Р отличается более эффективным использованием полосы пропускания канала для передачи видео потока.
Web Camera Pro - бесплатная программа, которая написана на Qt, С++ как мультиплатформенное решение. Вы можете использовать любую ip или usb камеру для полноценной системы видеонаблюдения с удаленным доступом из любой точки мира и с минимальными затратами.
Интерфейс Web Camera Pro:
Для детекции предусмотрен встроенный модуль распознавания лиц и номеров автомобилей. За счет умной детекции программа может отличать людей от домашних питомцев и отправлять вам видео в Telegram или в мобильное приложение, только в том случае, если в кадре появится человек.
Видеоинструкция:
https://www.youtube.com/watch?v=OvSQ1C5Lsd8
https://www.youtube.com/watch?v=CreFNidJqZI
https://www.youtube.com/watch?v=fRJdZATpixg
Скачать бесплатную версию Web Camera Pro можно здесь:
Мрачные пророчества об уходе иностранных корпораций из-за закона о предустановке российских приложений на ввозимые в РФ гаджеты не сбылись. Что выиграют попавшие в списки Минцифры разработчики приложений, почему равный доступ, а не ограничения самый эффективный способ защиты внутренних цифровых рынков, при чем здесь Германия и что думают обо всем этом эксперты рынка в статье.
С 1 апреля на всех продаваемых в России смартфонах, планшетах, ПК и умных телевизорах должны стоять отечественные приложения. Продажа цифровой техники без предустановленного российского ПО будет считаться нарушением федерального законодательства. Даже на торговые полки нельзя будет выставлять такие устройства. Если человек купил гаджет в упаковке без предустановленных отечественных приложений, он может пожаловаться в Роспотребнадзор. Наказывать за продажу электроники без предустановленных приложений начнут позже с 1 июля штраф для физлиц составит от 30 тыс. до 50 тыс., для компаний 50-200 тыс. рублей. Соответствующие поправки в Кодекс об административных правонарушениях РФ 16 марта приняла Госдума.
Поправки в закон О защите прав потребителей об обязательной предустановке российского софта были одобреныпрезидентом Владимиром Путиным в 2019 году. Они должны были вступить в силу в середине 2020 года, но из-за пандемии коронавируса дату перенесли на 1 января, а затем на 1 апреля нынешнего года. Новый закон уменьшит количество злоупотреблений со стороны иностранных корпораций и обеспечит защиту интересов российских интернет-компаний, говорится в пояснительной записке к документу. В Минцифре подчеркивают, что предустановка отечественного ПО - это часть стратегии импортозамещения и развития собственных цифровых продуктов.
Нововведение обеспечит равные условия конкуренции для иностранных и отечественных разработчиков ПО, отмечают в Федеральной антимонопольной службе (ФАС). В конечном счете [от этого] выиграют все: разработчики, производители устройств, разработчики приложений и потребители, у которых появится дополнительная возможность для выбора, сказали RSpectr.com в ФАС.
Соавтор закона, председатель комитета по экономической политике, промышленности, инновационному развитию и предпринимательству Госдумы Сергей Жигарев объясняет требование по предустановке отечественного ПО заботой о российском потребителе. Чтобы человек сам выбирал, пользоваться ли ему зарубежными или российскими приложениями. Например, когда вы покупаете айфон, там уже стоят приложения Apple. Если же там будут установлены привычные Яндекс, Mail.Ru, Кинопоиск и прочее, у человека будет выбор, какими приложениями пользоваться, а какие удалить, пояснил он.
Идея о том, что пользователи могут сами выбирать приложения, а между глобальными цифровыми гигантами и местными IT-компаниями должны быть равные конкурентные условия, реализуется не только в России. В январе этого года в Германии вступил в силу закон об ограничении конкуренции (Gesetz gegen Wettbewerbsbeschrnkungen, GWB). С его помощью правительство ФРГ намерено ограничить влияние транснациональных корпораций и добиться более справедливой конкуренции в сфере цифровых услуг.
Инициатива Германии может вдохновить ЕС на создание закона, который предоставит Европейской комиссии широкие полномочия для регулирования цифрового рынка,пишетнемецкий журнал Business & Diplomacy.
Эксперты из ФРГ позитивно оценивают аналогичный процесс в нашей стране.
Россия приняла закон о предустановке при покупке гаджетов в стране собственного ПО, но не стала вводить ограничения против глобальных корпораций, отмечает издание: Вместо этого был принят подход, при котором всем IT-компаниям предоставляется одинаковый доступ к платформам, что обеспечивает соблюдение принципа честной конкуренции.
Депутат федерального парламента Германии от Свободной демократической партии Александр Кулитц (Alexander Kulitz) предлагает понаблюдать, сможет ли РФ с помощью нового закона изменить рыночную монополию иностранных цифровых транснациональных корпораций и продвинуть собственное ПО. Он подчеркивает, что Россия и Евросоюз одновременно занялись защитой своих цифровых рынков от монополии IT-гигантов.
На какие типы устройств должно быть установлено российское ПО, говорится в постановлении правительства 1867от 18 ноября 2020 года. В канун нового года кабмин утвердил переченьиз 16 классов программ для предустановки. В список вошли наиболее популярные браузеры, поисковики, навигационная система Яндекса, электронная почта и новостной агрегатор Mail.ru, антивирус Kaspersky, а также Мой офис, Госуслуги и платежная система Мир. В аудиовизуальные сервисы для телевизоров включены Яндекс, ivi, More.tv, Okko, Premier, Start, Wink, Кинопоиск, НТВ Плюс, Первый канал, Смотрим. Предустановленные программы будут доступны на смартфонах, планшетах, умных телевизорах, ноутбуках и ПК, произведенных после 1 апреля 2021 года,разъяснилоМинцифры 15 марта.
Однако появление в гаджетах предустановленного ПО увеличит разрыв между лидерами отечественного рынка и небольшими компаниями, констатируют эксперты.
Чтобы попасть в перечень предусмотренных программ, разработчик должен представить приложение с не менее чем 500 тыс. скачиваний за предыдущий год.
Поэтому в списке нет ни одного стартапа, хотя магазины мобильных приложений часто становятся платформами для продвижения многих успешных проектов, отмечают они.
Также появление предустановленных приложений соцсетей на смартфонах может негативно сказаться на рынке аудиовизуального контента, прогнозирует заместитель генерального директора по правовым вопросам Института развития интернета (АНО ИРИ) Борис Едидин. Пока там [в соцсетях] еще много нелицензионного контента, и таким образом он станет доступнее, отмечает он.
На этом фоне компании разработчики отобранных в перечень приложений расширят свою пользовательскую аудиторию, отмечает технический директор компании Техносерв Юрий Корчуков. Сначала [пользователям] будут предложены версии продуктов с базовым функционалом для дальнейшего стимулирования перехода на расширенные версии и другие продукты, рассказалRSpectr.com Корчуков. По его словам, рост клиентской базы будет способствовать улучшению программ за счет получения отзывов о качестве их работы и актуальности наполнения.
Продукция Samsung уже продается с пакетом приложений от Яндекса. Huawei и LG Electronics пообещалиМинцифре, что все их новые модели будут соответствовать требованиям российского законодательства. Компания Apple долго думала, но также согласилась с новыми правилами, сообщилиСМИ в середине марта. Корпорации пришлось подстроиться под законодательство РФ для обеспечения своей ценовой политики, считают в компании Информзащита. Продукция Apple успешно продается на отечественном рынке, выручка составляет в России почти 200 млрд рублей, прибыль растет, и вряд ли корпорация допустит ослабление своих позиций, говорит представитель Информзащиты.
Но согласие с требованием о предустановке приложений страны это прецедент для Apple, отмечают участники рынка. Он показывает всему миру, что это возможно, поэтому в ближайшие годы мы можем увидеть аналогичные требования к компании от правительств других государств, считает гендиректор IT-компании Omega Алексей Рыбаков. Впрочем, опыт локализации своих устройств для отдельных рынков у американской корпорации все же есть. Apple перенесла данные iCloud на территорию Китая, изменила набор программного обеспечения App Store и конструкцию телефона в стране продавался iPhone с двумя физическими SIM-картами, рассказывает директор по IT компании Oberon Дмитрий Пятунин.
Иностранным производителям для выполнения требований нового закона необходимы прочие технологические контакты с российскими разработчиками софта.
Так считает гендиректор Доктор Веб Борис Шаров. Процесс предустановки требует полной технологической совместимости устанавливаемого софта и железа это становится заботой как для производителей устройств, так и для разработчиков. Нетрудно догадаться, что процесс довольно хлопотный, и каждый хотел бы получить за это какую-то компенсацию, прокомментировал он RSpectr.com. Эксперт отмечает, что для производителей такой компенсацией станет сохранение доли на российском рынке, для разработчиков увеличение аудитории.
Закон о предустановке отечественного ПО добавил юридических и технических проблем производителям электроники, говорит директор по связям с общественностью Ассоциации торговых компаний и товаропроизводителей электробытовой и компьютерной техники (РАТЭК) Антон Гуськов. Многие производители жалуются, что разработчики не хотят заключать никаких договоров: берите [наше ПО], мол, и все. Но без договора в этой ситуации невозможно, рассказывает он. При этом отношения между производителем устройств и разработчиком ПО должны быть безвозмездными, отмечается в регулирующем выполнение требования о предустановке постановлении. Но Налоговый кодекс РФ не предусматривает безвозмездных отношений между юридическими лицами, обращает внимание Гуськов.
Требование об обязательной предустановке, которое планировалось ввести летом 2020 года, могло бы вызвать на рынке коллапс.
К счастью, правительство сдвинуло старт проекта сперва на январь, а затем на апрель нынешнего года, отмечает директор ассоциации АПКИТ, председатель совета ТПП РФ по развитию ИТ и цифровой экономики Николай Комлев. Разработчикам ПО и производителям железа требовался переходный период. Теперь, полагаю, все пройдет без потрясений. Небольшие накладки будут, но рынок их практически не заметит, говорит он.
Влияние нормы о предустановке российских мобильных приложений на российский IT-рынок не будет ощутимым, уверен директор Центра Solar appScreener компании Ростелеком-Солар Даниил Чернов. Последует незначительный прирост использования российского ПО на устройствах, предназначенных для нашего рынка. Просто большее количество пользователей узнает о существовании некоторых отечественных продуктов, сказал он RSpectr.com.
Тем не менее в условиях, когда уровень локализации зарубежных цифровых продуктов и устройств оставляет желать лучшего, предустановка это хороший шаг, полагает директор центра разработки Artezio Дмитрий Паршин. В конечном счете сам потребитель будет решать, какими приложениями он будет пользоваться, подчеркивает он. Предустановленные программы можно рассматривать, как рекомендацию, мы не всегда используем все, что установлено, например, в Windows, напоминает Паршин.
Для пользователей нововведение не повлечет каких-либо негативных последствий, считают участники рынка. Напротив, отечественные сервисы лучше ориентированы под запросы россиян, чем абстрактные услуги глобальных корпораций, отмечает гендиректор DZ Systems, создатель Яндекс.Маркета Дмитрий Завалишин. Те, кто ездит по России, предпочитают использовать Яндекс.Карты, они детальнее, быстрее обновляются, их создатели лучше понимают нашу страну и ее особенности, сказал он RSpectr.com. Но при установке предлагаемых приложений нужно быть готовыми, что они займут полтора гигабайта памяти в смартфоне или другом устройстве, предупреждает ведущий аналитик Mobile Research Group Эльдар Муртазин.
Впрочем, те, кому не нравится какая-то программа, смогут отказаться от ее установки или самостоятельно удалить этот софт, если он предустановлен.
Пользователям, которые меняют старые смартфоны на новые, будет немного удобнее им не нужно будет устанавливать самостоятельно уже привычное ПО, а всего лишь нужно будет войти и авторизоваться, отмечает руководитель центра бизнес-аналитики ГК РАМАКС Сергей Левашов.
Возможно, в переходный период производители могут почувствовать некоторый рост издержек из-за предустановки российского ПО, говорят эксперты. Но они отмечают, что влияние предустановки софта на себестоимость производства гаджета минимально и розничные цены устройств из-за этого вряд ли вырастут.
В целом, заключают эксперты, преимущества нового закона ощутят несколько категорий участников рынка:
компании разработчики ПО, чьи продукты попадут в списки Минцифры, расширят пользовательскую аудиторию;
пользователи по умолчанию получат доступ к локализованным базовым версиям привычных сервисов;
государство обеспечит улучшение бизнес-климата для IT-индустрии, что повысит ее конкурентоспособность и увеличит число рабочих мест.
Продолжаю делиться историей разработки аппаратной платформы GM-Box G1. В предыдущей статье я рассказал о первых шагах на пути создания продукта - прототипировании для проверки продуктовых гипотез. Этот этап позволил сформулировать требования к серийному изделию.
Сейчас речь пойдет о непростом пути от технического задания до решений промышленного дизайна и запуска серийного производства в России. Снова будет много технических деталей, фотографий и моих откровений инженера.
Наступил долгожданный момент, когда после множества презентаций мы получили инвестиции и начали подготовку к разработке серийной версии нашего продукта. GM-Box стал превращаться, конечно не из гадкого утенка в прекрасного лебедя, но из прототипа во вполне симпатичное и рабочее серийное изделие. Собранные на этапе прототипирования инсайты и знания о нашем продукте мы оформили в виде технического задания (ТЗ). Формат выбрали в международной нотации - Product Requirement Document (PRD), потому что готовились к общению с иностранными подрядчиками.
Без ТЗ получается ХЗПеред нами стояли следующие задачи:
промышленный дизайн;
разработка конструкции корпуса и молдинга для литья пластика;
разработка схемотехники и трассировка печатных плат;
разработка Firmware, системного, прикладного и серверного программного обеспечения;
организация цепочки и снабжения компонентами, в том числе серийного литья пластика;
сборка и тестирование печатных плат;
узловая сборка, заливка софта, испытания (приемочные, приемо-сдаточные и т. д.);
организация ремонта, технического обслуживания и поддержки;
организация логистики (в т. ч. международной);
управление качеством;
И, конечно же, мы бились над извечной дилеммой делать всю разработку самим (In House Design - IHD) или заказать на стороне (Original Design and Manufacturing - ODM). Выполнение всех задач внутри требовало немаленькой команды профи разных направлений, а еще много специального оборудования и софта. Это недоступная роскошь для стартапа, и мы решили скомбинировать IHD и ODM. Вот какими были наши ключевые требования к потенциальным партнерам:
опыт разработки x86 платформ на современных SoC, включая BIOS и EC;
опыт разработки продуктов сегментов: планшеты, телефоны;
опыт разработки сложных пластиковых корпусов;
высокий уровень качества продукции, услуг;
опыт организации и сопровождения крупносерийного производства собственных продуктов.
Изучив рынки России и Беларуси, мы с удивлением осознали, что не можем найти компанию, соответствующую всем нашим ожиданиям. Тогда, хоть и с тревогой, но мы приняли решение ехать в более дальнее зарубежье в поисках партнера. Шел 2017 год Мы нашли азиатскую ODM компанию с нужным нам технологическим стеком, опытом и хорошим качеством. В итоге разделение между нами и ODM перечисленных выше задачах получилось такое: 60% (мы) на 40% (ODM). Работа закипела, и мы начали готовить требования к внешнему виду изделия.
Нам предстояло описать, как наше устройство будет выглядеть внешне, со стороны пользователя, взаимодействовать с ним и окружающим пространством, интерьером корпоративного офиса или его рабочего места дома в случае удаленки. Функциональные и нефункциональные, технические требования, определяющие форму и содержание, были собраны в ТЗ, их было достаточно много. Одним из ключевых требований было обеспечить удобную и стильную реализацию синергии в продукте смартфона и GM-Box.
Наш дизайнер Михаил, зарядившись ТЗ, идеями и инсайтами команды, с учетом опыта, полученного на прототипах, принялся за работу, а мы стали ждать от него волшебства. Сначала, как и на этапе прототипирования, появились черновые наброски скетчи:
Скетчи на бумагеСкетчи на доске для рисованияДальше перешли к 3D моделированию в Autodesk Inventor. Было безумно много вариантов дизайна на разный вкус и цвет.
Коллаж рендеров концепта GM-Box G1Внутри команды мы периодически проводили презентации очередной версии дизайна. Обсуждали решения, предлагали изменения, спорили и, конечно же, даже ругались (какой стартап без ссор?), но всегда договаривались.
Презентация одной из последних версий дизайнаВ итоге родился промышленный дизайн будущего серийного продукта.
Рендер финального дизайна GM-Box G1Мы глубоко проработали дизайн и даже элементы внутренней механики, но все это нужно было связать с начинкой нашего изделия электроникой и обеспечить технологичность при серийном производстве. На базе 3D модели нашего дизайна и требований ТЗ наш ODM партнер начал проработку конструкции. Моделирование делали в Pro Engineer и присылали нам презентации с картинками и вопросами. В ответ мы моделировали в Autodesk Inventor и отправляли им свои идеи. Начитавшись про методологии разработки известных мировых брендов, мы погрузились в длительный итерационный процесс создания MDP (Minimum Desirable Product), сохраняя 3 его точки опоры:
гештальт продукта;
дизайн;
качество.
Расскажу коротко о самых сложных узлах, попивших у нас крови.
Мы искали решение, которое обеспечит складывание ноги в транспортном режиме. При этом в разложенном состоянии нога должна слегка фиксироваться, предотвращая складывание ноги при работе с устройством. А еще нужно чтобы петля занимала мало места и была недорогой.
Необходимо было продумать такую защитную крышку, которая обеспечит эффективный отвод тепла от внутренней электроники, совместив это с размещением там же динамиков. При этом это должна сохраниться дизайнерская мысль и технологичность производства.
Необходимо было обеспечить разъемное соединение смартфона с Gm-Box. При этом, реализовать возможность подключения любого смартфона, удобство пользователя и высокую надежность узла.
Конечно, были непростые задачи и с другими частями конструкции. Вот самые запомнившиеся элементы:
система охлаждения;
клавиатура;
трубка;
держатель кабелей;
внешние микрофоны;
слот батарейки часов реального времени;
собираемость изделия.
Финалом работы над корпусом стали:
подробная 3D модель GM-Box;
Mockup образец (неработающий опытный образец).
Целью изготовления Mockup образцов было подтвердить соответствие дизайна, 3D модели и материалов ожиданиям заказчика (нас) и пользователей. Технологически процесс их изготовления состоял из операций:
3D печать;
фрезеровка напечатанной заготовки;
ручная доработка: снятие заусенцев, ошкуривание, шлифование;
покраска;
финальная сборка и "доработка напильником".
Пока мы не ушли далеко от разработки корпуса, расскажу о сложностях, с которыми мы столкнулись на этом этапе, и как мы с этим справились. Получив на руки Mockup образцы, мы стали оценивать его реальный дизайн, а не рендеринг. Разница между картинкой и физическим объектом значительная и именно поэтому изготовление и анализ Mockup так важен для получения качественного продукта. Нас не устраивал дизайн клавиатуры и трубки, с точки зрения их визуального восприятия. Получилось не то. И мы решили переработать эти узлы.
Образец - Mockup2В поисках нашего гештальта для MDP (писал об этом выше) мы потратили 4 месяца на дизайн и дополнительное прототипирование:
искали альтернативные варианты дизайна клавиатуры и трубки;
прототипировали;
обсуждали;
вносили изменения в дизайн изделия и его 3D модель;
вносили изменения в 3D модель конструкции.
Параллельно с созданием корпуса мы начали разработку электроники. Нам предстояло решить следующие задачи:
разработка архитектуры;
выбор элементной базы;
компоновка печатных плат и устройства;
расчет себестоимости, оптимизация;
Design For Manufacturing (DFM) анализ и доработка;
наладка (брингап) электроники.
Этапы разработки электронной части в связке с корпусом\механикой и софтом у нас получились такие:
Mockup прототип, пустышка, полноразмерный неработающий образец;
EVT инженерные образцы, частично работающие, позволяющие отлаживать софт;
DVT полнофункциональные опытные образцы с косяками;
DVT2 - полнофункциональные опытные образцы без косяков;
PVT образцы, собранные на конвейере по серийной технологии;
MP серийные изделия.
Очень похоже на наш отечественный процесс разработки по ГОСТ 15: ЭП, ТП, РКД, постановка на производство.
Отрисовку схемотехники и топологию печатных плат выполнял ODM партнер. Использовали Cadence ORCAD. Буквально через 3 недели после готовности топологии появились первые образцы системных плат, и мы поехали их брингапить в Азию.
Один из первых запусков электроникиРабота программистов в командировке над bring up электроникиСначала железо запускали и тестировали на Win10, т. к. много готовых утилит, примеров, референсов для наладки. После того как железо ожило на Win10 мы перешли к проверке и доработке на Linux Ubuntu. Это был итерационный процесс поузловой наладки и доработки BIOS и программы EC контроллера. Больше всего досталось нашим программистам, т. к. железо без софта не работает, а софт у нас на Linux Ubuntu и заточен под особенности продукта. Пришлось сильно попотеть в раскуривании работы чипов и общей логики работы устройства и отдельных узлов. Ну и конечно перед нами стояла задача финальной валидации работоспособности продукта на этом этапе разработки (EVT).
Снаружи GM-BOX все просто, а под капотом много интересных штук:
Это настоящий компьютер!Железо без софта безжизненный организм, хотя мне больше по вкусу вот такая визуализация архитектуры программного обеспечения:
Архитектура нашего программного обеспечения GM SMART SYSTEMЕсли серьезно, то наш софт это достаточно сложный набор компонентов:
Firmware;
системное ПО;
серверное ПО;
мобильное ПО.
У каждого компонента свое предназначение, история разработки, набор применяемых технологий, интересных фич. Поэтому про каждый элемент в отдельности мы расскажем в наших следующих статьях.
Вкратце расскажу сейчас только про устройство Firmware, как крайне важный компонент для оживления электроники. Это даст более цельное понимание устройства нашей аппаратной платформы.
Firmware GM-Box G1 состоит из:
BIOS (Basic Input Output System) обязательная часть х86 платформ;
EC (Embedded Controller) система управления аппаратной инфраструктурой (питание, сброс, периферия).
BIOS для x86 платформ на рынке предлагают несколько вендоров: AMI, Insyde и т.д. У каждого такого продукта есть свои преимущества и недостатки. Сделать оптимальный выбор и разработать BIOS под нашу аппаратную платформу нам помог наш ODM партнер с учетом: своего опыта, наличия лицензий, исходников и тулчейна для разработки. Итого, мы получили рабочий BIOS, исходники и тулчейн для возможности модификации.
EC контроллер аппаратно реализован на чипе IT8987. Это интегрированное решение для управления инфраструктурой простеньких ПК. Внутри ядро классического микроконтроллера х8051. Программа для EC тоже разрабатывалась ODM, но мы потом кое-что дописали сами. Итого, мы получили рабочую прошивку EC, исходники и тулчейн для возможности модификации.
С дизайном GM-Box мы успешно справились и настал черед сделать красивую упаковку. С одной стороны, это продукт для B2B и B2G рынков, а значит коробку, скорее всего, выбросят сразу после приобретения, и нет необходимости заморачиваться над дизайном. С другой стороны, учитывая специфику нашего продукта, важно было обеспечить безопасную транспортировку и сохранить его презентабельный вид. К тому же мы выходили на рынок с новым продуктом, поэтому упаковка выполняла еще и задачу презентации устройства показать, что внутри высокотехнологичный, качественный продукт. Так что мы продумывали все до мелочей.
Наша упаковка должна решать следующие задачи:
защита изделия от повреждения во время транспортировки и хранения;
удобное паллетирование и одиночное хранение;
удобное размещение компонентов изделия для легкого доступа к ним пользователя;
понятный процесс подготовки и включения изделия;
дополнение образа качественного, инновационного продукта.
Мы снова воодушевились, взяли для примера лучшие бренды электроники и получилось вот такое решение:
3D рендер пользовательской упаковкиКоробка выполнена из гофрокартона с нанесением цвета и дополнительной графики.
Нас очень сильно беспокоило транспортирование кабеля телефонной трубки. Он спиральный и легко деформируется. Мы не хотели, чтобы пользователь брал в руки изуродованный кабель. В жизни это выглядит так:
Ожидание - реальностьРешение нашлось, в виде специальной коробки с ложементом для кабеля:
Ложемент кабеля телефонной трубкиВ реальном производстве коробки выглядят также хорошо, но технологичность получилась не идеальная. Мы уже переработали конструкцию упаковки и ждем, когда она пойдет в серию.
Успешное прохождение этапа прототипирования не означает, что при разработке серийного продукта все будет гладко. Неожиданности поджидают на каждом шаге разработки, к этому нужно быть готовым морально и технически. Самое важное в успешном преодолении этих трудностей командная работа, вовлеченность (даже увлеченность) каждого члена команды и фокусирование на поиске лучшего решения для продукта. Тщательная подготовка к предстоящему этапу работ и формализация требований помогают подстелить соломку и снизить риски неудач.
В следующей публикации я расскажу об этапах тестирования и постановки на производство. Снова будет много технических деталей и фотографий.
2. От дизайна до производства: Как обеспечивается качество продуктов Apple
waypoint up
. Waypoint из
коробки поддерживает Kubernetes, HashiCorp Nomad, Amazon ECS,
Google Cloud Run, экземпляры контейнеров Azure, Docker, Buildpacks
и не только. Читайте дальше, чтобы увидеть небольшой пример, узнать
больше о функциях Waypoint и о проблемах, которые решает
инструмент.
project = "HashiCorp Waypoint"app "waypoint-up" { build { use "docker" {} registry { use "docker" { image = "hashicorp/wpmini" tag = gitrefpretty() } } } deploy { use "kubernetes" { probe_path="/" service_port=80 } } release { use "kubernetes" { load_balancer=true port=80 } }}
Привет, Хабр! В OTUS открыт набор на новый поток курса "Software Architect", в связи с этим приглашаем всех желающих на онлайн день открытых дверей, в рамках которого наши эксперты подробно расскажут о программе обучения, а также ответят на ваши вопросы.
Все течет, все меняется. Программирование как нельзя лучше подтверждает правильность этого изречения: разработчики ежедневно модифицируют, адаптируют, дорабатывают и даже перерабатывают свои системы.
Приложения становятся все сложнее, над ними трудятся все больше разработчиков, и поддерживать понятность программного обеспечения становится нелегко. Сложный код труднее понять и при необходимости изменить.
Понятность системы это то ее свойство, благодаря которому инженеру не составит труда в ней разобраться. Чем понятнее система, тем проще инженерам вносить в нее изменения, которые будут вести себя предсказуемо и не сделают систему уязвимой.
Система является понятной, если она отвечает следующим критериям: завершенность, компактность, открытость и структурированность.
Со свойством понятности связано свойство наблюдаемости, однако основными характеристиками наблюдаемости являются: 1)способность предупреждать о неправильном функционировании системы и помогать выявлять причины ошибки, чтобы восстановить нормальную работу системы, и 2)способность помогать выявлять факторы, ограничивающие производительность системы, чтобы задействовать дополнительные ресурсы или сообщить о проблеме ответственным лицам.
2500 лет назад Гераклит сказал: Все течет, все меняется. Программирование как нельзя лучше подтверждает правильность этого изречения: разработчики ежедневно модифицируют, адаптируют, дорабатывают и даже перерабатывают свои системы. Еще один аспект, который отличает разработку программного обеспечения ото всех остальных направлений деятельности, большая свобода действий, ограниченная лишь техническими возможностями информационных систем.
Однако часто на нашем пути к реализации этого мощнейшего потенциала возникает неожиданное препятствие ограничены наши знания о собственных разработках. Приложения становятся все сложнее, над ними трудятся все больше разработчиков, и поддерживать понятность программного обеспечения становится нелегко. В результате проекты рушатся, как Вавилонская башня.
Большинство коммерческих проектов по разработке программного обеспечения начинается не с чистого листа. Как правило, уже существует какое-то приложение, написанное на определенном языке (или языках) программирования для одной или нескольких операционных систем, в котором используется набор фреймворков и библиотек.
Самый быстрый и надежный способ выпуска приложений. Развертывание, подключение, защита и эксплуатация приложений в мультиоблачных средах и на периферии. Начните бесплатно.
Мы (или наша команда) изменяем это приложение таким образом, чтобы оно соответствовало некоторым требованиям, например разрабатываем новую возможность, устраняем существующий баг и так далее. При этом мы обязаны соблюдать все действующие (не только задокументированные) требования и, насколько это возможно, не менять существующее поведение программы.
Устроившись на работу, любой начинающий разработчик осознает, что написать фрагмент кода для решения простой задачи по информатике (или найти ответ на StackOverflow) это совсем не то же самое, что встроить такой фрагмент в большую сложную систему.
Посмотрим, как толкуют понятность финансисты, и на основе этого определения дадим свое: Понятность системы это то ее свойство, благодаря которому инженеру не составит труда в ней разобраться. Чем понятнее система, тем проще инженерам вносить в нее изменения, которые будут вести себя предсказуемо и не сделают систему уязвимой.
Опираясь на эту аналогию, можно сказать, что система является понятной, если она отвечает следующим критериям.
Завершенность. Система должна поставляться с определенным набором исходной информации (исходный код, документация и т.д.). У инженера должна быть вся важная информация о системе.
Компактность. Исходный код не должен содержать слишком много ненужной информации, в которой пользователь может захлебнуться. Здесь в дело вступают принципы разделения ответственности и абстракции, которые позволяют инженеру сосредоточиться на своей задаче.
Открытость. Это такой метод представления программы, который позволяет человеку понять ее в результате чтения кода. Огромное значение здесь имеют согласованность, соглашения о кодировании, форматирование исходного кода, комментарии к коду и подсветка синтаксиса.
Структурированность. В структурированной системе должны присутствовать перекрестные ссылки, чтобы инженеру не составляло труда найти нужную информацию. Ориентироваться в системе программистам позволяет модульность кода, документация на программное обеспечение, средства навигации по исходному коду и инструменты управления исходным кодом.
С распространением модели программное обеспечение как услуга (SaaS) и других моделей поставки приложений многие организации предпочитают самостоятельно реализовывать полный жизненный цикл программного обеспечения.
В таких организациях понятность кода играет еще более важную роль: разработчикам необходимо отслеживать, как работает приложение и как его используют клиенты.
Поэтому у специалистов, которые занимаются этой задачей, должен быть доступ к информации о закономерностях использования системы, реальным примерам входных и выходных данных, сведениям о фактической производительности и доступности приложения.
Сейчас вы, возможно, подумали, что для этого нужно обеспечить наблюдаемость приложения и использовать средства мониторинга. К сожалению, это не так. Средства мониторинга предназначены для решения более традиционных задач в ИТ:
Предупреждение о неправильном функционировании системы и помощь в выявлении причины ошибки, чтобы восстановить нормальную работу системы.
Выявление факторов, ограничивающих производительность системы, чтобы задействовать дополнительные ресурсы или сообщить о проблеме ответственным лицам.
Ведение подробных журналов событий для обеспечения корректной эксплуатации системы, ее защиты и поддержки.
С этими проблемами ИТ-индустрия сталкивается с незапамятных времен. А поскольку их экономический эффект вполне очевиден, рынок насыщен эффективными инструментами для решения этих проблем. Однако это не те задачи, которые возложены на плечи разработчиков ПО, и эти средства никогда не предназначались для помощи в разработке.
Все эти задачи объединяет то, что сотруднику с базовыми знаниями о системе нужно получить точную информацию о сбое в каждом конкретном случае и принять необходимые меры. То есть мы собираем данные о заранее известных типах событий, в основном о взаимодействии системы с внешними факторами.
С другой стороны, разработчики ПО отлично знают внутренние механизмы системы и стараются получить больше информации о том, как она работает в реальном мире. Нужные им данные изменяются ежедневно (или даже ежечасно) в зависимости от изменений, которые они вносят в систему.
Программное обеспечение становится все более сложным по мере его масштабирования и модификации. Во многих случаях усложнения систем не избежать, поскольку коммерческие потребности компаний постоянно растут. Однако усложнение программ по другим причинам нежелательно. Оно связано с некачественной модификацией либо с неудачными проектными решениями и часто называется техническим долгом.
Независимо от причин, сложный код труднее понять и при необходимости изменить. Эта проблема усугубляется потерей интеллектуального потенциала в связи с текучестью кадров.
Всем, занятым в индустрии программного обеспечения, известно, что системы должны быть максимально простыми. Чем сложнее ПО, тем затратнее разработка и внедрение обновлений и ниже качество системы в целом. Уже написано много руководств по разработке приложений с минимальным уровнем сложности и эффективному масштабированию систем и команд разработчиков.
Многие разработчики нового программного обеспечения излишне усложняют приложения, в результате чего они становятся менее понятными. Отказавшись от сложных приемов или максимально сократив их количество, можно естественным образом обеспечить понятность кода. К счастью, для этого сейчас существует множество средств и методов разработки ПО.
В первую очередь нужно привлекать высококвалифицированных сотрудников. Талантливые разработчики, опираясь на собственный опыт, могут найти простое и элегантное решение сложной бизнес-задачи и сделать понятными исходный код и архитектуру.
Старайтесь создавать небольшие системы, насколько это возможно, такие системы по своему характеру являются менее сложными и более понятными. Системы можно упростить сверху: создавайте такое ПО, которое будет отвечать ключевым потребностям бизнеса, отказавшись от дополнительных функций (по крайней мере, временно). Часто системы можно упростить и снизу: используйте абстракции высокого уровня, например новые языки программирования, фреймворки с расширенными возможностями и современные базы данных.
И, что не менее важно, используйте скаффолдинг при разработке сложных приложений. Пишите автоматические модульные и системные тесты, которые позволят программистам безопасно заниматься рефакторингом кода для его упрощения. Используйте качественные инструменты для мониторинга системы, дающие общее представление о ее функционировании. Автоматизируйте конвейеры интеграции и развертывания приложений, и вы сможете эффективнее их совершенствовать и быстрее поставлять релизы.
Когда речь заходит о существующем программном обеспечении, мы воспринимаем неспособность программистов понять код как проклятье. Не нужно с ходу бросать все силы на упрощение приложения, это не самый эффективный подход к повышению понятности.
В большинстве случаев вам приходится иметь дело с устаревшими системами, для создания которых использовались менее продвинутые инструменты, чем те, которыми мы пользуемся сегодня, средства автоматизации и скаффолдинг в них не предусмотрены, а разработчиков уже не найти. Жалобами на технический долг, с которым вы столкнулись, и на нечитаемый код, в котором ваши программисты никак не разберутся, вы ситуацию не исправите. Не помогут и рассуждения о долгосрочном рефакторинге и миграциях чаще всего на разговорах дело и заканчивается.
В этих случаях просто незаменимы платформы для отладки кода в продакшне. Получив результаты глубокого анализа механизмов работы кода в реальных условиях, инженеры начнут понимать систему. А собрав по крупицам данные о работе приложения из разных сред и получив представления о сценариях его использования, они смогут постепенно распутать сложный код.
Мы получили более широкое представление о том, насколько важно обеспечивать понятность кода при разработке ПО. С одной стороны, мы всегда знали, что код должен быть читаемым и простым в использовании, это одна из важнейших задач разработчиков. И тем не менее сейчас становится все более очевидным, что именно это свойство кода позволяет приложениям эволюционировать.
С другой стороны, мы убедились, что повысить понятность системы (упростить ее, тщательнее поработать над проектом, написать более простой код) не всегда просто. Чаще всего мы запрыгиваем в вагон на ходу, когда взять управление в свои руки практически невозможно. Отсюда вывод, что понятность это ключевой показатель, который необходимо отслеживать и которым надо управлять. Обеспечив понятность системы, можно добиться максимальной скорости ее доработки с максимально качественными результатами, даже если условия для этого не самые благоприятные.
Подробнее о курсе "Software Architect". Посмотреть открытый урок по теме "Мониторинг и Алертинг" можно здесь.
Технологии автономных автомобилей способны совершить настоящий
переворот в транспортной отрасли и оказать существенное
долгосрочное влияния на образ нашей жизни, работы и бизнеса: они
могут снизить количество жертв дорожно-транспортных происшествий,
разгрузить дорожную сеть и высвободить время. Кроме того, в этом
случае появятся новые транспортные парадигмы, включая автономные
такси и модели перевозка как услуга с автомобилями совместного
владения. Продукты и услуги из области автономного вождения также
включают автоматическую парковку и автоматическое техобслуживание.
Преимущества образуются и в таких областях, как использование земли
и городское проектирование, поскольку по дорогам перемещается
меньше автомобилей. При этом обеспечивается существенная экономия
за счет более эффективного использования топлива и снижения
эксплуатационных расходов.
1. ВВЕДЕНИЕ
Помимо преимуществ у автономных автомобилей есть и
немало серьезнейших проблем.
Водить даже обычный автомобиль бывает очень непросто, но ситуация дополнительно осложняется, если нужна автоматическая отказоустойчивая система, способная работать в любых условиях вождения с крайне низкими показателями допустимых ошибок. Автономные автомобили образуют и потребляют огромные объемы данных. При этом в новом отчете прогнозируется рост глобального рынка автомобилей с сетевыми возможностями на 270% к 2022 году. Предполагается, что к 2022 году будет продано свыше 125 миллионов пассажирских автомобилей с возможностями сетевого подключения [1].
Суммарные расходы на разработку автономных систем вождения могут достигать миллиардов долларов, при этом стоимость оборудования одного автомобиля всем необходимым для полностью автономного вождения также будет весьма велика и может достигать 100 тысяч долларов [2].
Потребуется модернизация инфраструктуры. Может потребоваться переделать дороги, чтобы обеспечить безопасность и согласованность условий для новых типов автомобилей. Достижение такого уровня согласованности на международном уровне или хотя бы в пределах городов будет непростой задачей.
Также необходимо учитывать нормативно-правовые аспекты и вопросы ответственности. Например, если из-за автономного автомобиля возникнет авария, чья будет вина: водителя, производителя автомобиля или компании, разработавшей программное обеспечение для автономной езды?
Необходимо обучение и информирование потребителей, чтобы дать им возможность принимать решения и не реагировать на слухи, мифы и ошибочные представления об отрасли и технологии автономных автомобилей.
Во все времена существования автомобилей именно технологии
определяли самые современные возможности безопасности. С 70-х годов
автопроизводители стали выпускать подушки безопасности, что
позволило избежать множества человеческих жертв. Применение
антиблокировочных тормозных систем, которыми автомобили оснащаются
с 90-х годов, привело к снижению столкновений без человеческих
жертв на 6-8%
[3]. Тем не менее почти 1,3 миллиона человек ежегодно
становятся жертвами дорожно-транспортных происшествий
[4].
Передовые достижения в области высокопроизводительных вычислений и
машинного обучения, использование новых технологий в датчиках
(например, лидары технология получения и обработки информации
дистанционного зондирования с помощью активных оптических систем
(лазеров), использующих, в том числе, явления отражения света от
поверхности Земли с проведением высокоточных измерений X, Y, Z
координат) и мощные вычислительные системы периметра открывают
новую перспективу снижение количества человеческих жертв в
дорожно-транспортных происшествиях за счет реализации автономных
автомобилей.
По мере роста экономики и урбанизации все более остро встает
проблема перегруженности дорожных сетей. Средний городской житель
проводит на дороге 40 минут в день. Таким образом, за год такой
житель тратит 167 часов (свыше четырех полных рабочих недель) на
сидение за рулем, и в течение этого времени он не может обращать
внимание ни на что иное, кроме собственно вождения автомобиля.
Беспилотные автомобили будут играть важную роль в будущем умных
городов и повлияют на построение и устройство городской
инфраструктуры. В настоящее время только в США свыше 700 миллионов
выделенных парковочных мест, занимаемая ими общая площадь сравнима
с площадью всего штата Коннектикут. Автомобиль в среднем занимает
парковочное место в течение всего 4% времени, тогда как при
использовании беспилотных автомобилей коэффициент использования
возрастает до 75%
[5]. По этим причинам автономные автомобильные парки станут
важным компонентом в умных городах будущего.
Распространение автономных автомобилей и транспортных решений
совместного пользования может повлечь объединение бизнес-моделей
агрегаторов такси и каршеринга.
Отчет, опубликованный компанией Allied Market Research, гласит, что
объем глобального рынка автономных автомобилей составил 54,23 млрд
долларов в 2019 году, а к 2026 году может вырасти до 556,67 млрд
долларов, при этом совокупные темпы годового роста с 2019 по 2026
год составят 39,47%
[6]. Для систем вождения высокой автономности (HAD) и
полуавтономных функций в расширенных системах помощи водителям
(ADAS) требуется платформа, способная получать и обрабатывать
данные как в ядре, так и на границе сети. Высокопроизводительные
решения HPE для хранения и архивации данных повышают надежность
развертывания, обеспечивают защиту данных и их готовность к
анализу. Множество решений HAD могут предоставляться по модели как
услуга или по другим моделям потребления с оплатой по мере
использования. Именно в этой области действуют решения пакета HPE
GreenLake, упрощая обслуживание ИТ-инфраструктуры и сохраняя
конфиденциальность и контроль над ней.
В этой статье рассматриваются проблемы HAD, включая составные части
процесса разработки автомобилей с высоким уровнем автоматизации и
автономности.
1.1. Общие характеристики
задачи
Обнаружение. Решения HAD опираются на технологии автомобильных встроенных датчиков. Основные датчики: спутниковая система геопозиционирования (GPS), блок инерциальных датчиков (IMU), камеры, лидары, радары, ультразвуковые источники, а также различные датчики, установленные внутри автомобиля и в его силовом агрегате. Некоторые технологии уже широко применяются (например, GPS и камеры), тогда как другие (например, лидары) в настоящий момент достаточно дороги, однако по мере развития автономных автомобилей такие системы будут становиться дешевле и компактнее. Таким образом, на первом этапе необходимо преобразовать объем данных, поступающих от всего комплекса датчиков автомобиля, в подробное представление окружающей обстановки.
Понимание. Модели машинного обучения в автомобиле (граница сети) и в подключенных центрах обработки данных (ядро) проводят сопоставление картины, поступившей от датчиков, с известными и заранее обработанными сценариями (например, плотный поток автомобилей на дороге дождливым днем, автомобильная стоянка ночью). Принятие решений автомобилем будет частично основываться на моделях, которые используются для понимания окружающей обстановки и обеспечения безопасности. По мере поступления новых данных автомобиль должен сопоставить их с уже обработанными и использовать результирующий поток данных на следующих шагах для принятия решения.
Распознавание объектов. На этапе обнаружения выделяются объекты вокруг автомобиля: другие автомобили, дорожная разметка, знаки дорожного движения, пешеходы, маршруты движения и т. п. Цель обнаруживать окружающие объекты и на основании этих данных строить картину окружающей обстановки, причем как при наличии карты высокого разрешения, так и на новой неизвестной местности. Разумеется, важно и обнаружение знаков дорожного движения, и обмен информацией между автомобилем и инфраструктурой, а также с другими автомобилями (V2X).
Восприятие. Для восприятия требуется передать модели новые собранные данные для распознавания объектов и их взаимоотношения с более крупными областями вокруг автомобиля. Компоненты этого этапа: локализация (где автомобиль?), контекстуализация (какая вокруг обстановка, возможно с использованием карт высокого разрешения?), распознавание объектов (интеграция данных с лидаров и с других датчиков) и отслеживание объектов (с помощью интеллектуальных моделей).
Принятие решения. Решение это подготовка к действию. Что автомобиль должен сделать? Повернуть? Затормозить? Продолжить ехать прямо? Бортовой компьютер автомобиля принимает решения на основе данных с датчиков, обработанных в контексте окружающей обстановки. Модели обучаются с помощью алгоритмов машинного обучения и огромного объема данных, полученных с комплексов автомобильных датчиков. это позволяет создать алгоритмы, способные предсказывать потенциальные события на основе поступающей в реальном времени ситуативной информации. После этого можно применять логические схемы для определения предпочитаемой последовательности действий. Основная цель состоит в составлении стратегии вождения: уклонении от препятствий, планировании поведения, управлении на основе данных GPS, планировании маршрутов, прогнозировании явно незафиксированных событий.
Действие. После принятия решения о дальнейших действиях автомобиль должен как можно быстрее приступить к их выполнению. Здесь требуется программный анализ, поскольку важно составить правильный план действий в зависимости от внешней обстановки. Если нужно, допустим, повернуть автомобиль влево, то летним днем на сухой дороге условия для этого будут совсем не такими, как зимой на скользкой дороге. Производители автомобилей уже делают шаги на пути к решению этой задачи: они уже сейчас предлагают функции помощи при перестроении и адаптивный круиз-контроль. Тем не менее по-прежнему очень непросто заставить систему управления правильно настроиться на внешнюю обстановку, в которой находится автомобиль.
От описания составных частей системы HAD перейдем к описанию ее важнейших компонентов. Данные с датчиков обычно собираются измерительными блоками в багажниках автомобилей. Первая задача при тестировании HAD заключается в выгрузке данных и в сохранении их в станции сбора данных (она также называется станцией отправки или станцией буферизации). Главное хранилище данных, как правило, представляет собой гибридное облачное решение с комплексом компонентов, по большей части расположенных в центре обработки данных (ЦОД) с возможностью использования облачных ресурсов при пиковой нагрузке.
Высокоуровневый вид компонентов разработки полного цикла системы HADВ зависимости от сложности автомобиля и от степени использования программной эмуляции тестирование при разработке решений HAD обычно включает три этапа.
Модель в контуре управления (MIL). Тестирование модели системы и операционной среды без проведения тестов на оборудовании HAD (часто выполняется на обычных рабочих станциях). Проверка MIL обычно проводится на ранних этапах цикла разработки.
Программное обеспечение в контуре управления (SIL). Испытание и проверка автоматически созданного кода, используемого в контроллере системы. Тестирование SIL часто происходит в сэмулированной среде, также без проверки на системном оборудовании HAD.
Оборудование в контуре управления (HIL). Тестирование и проверка системного оборудования HAD для выявления всех ошибок в архитектуре оборудования или вызванных используемым компилятором.
Данные, полученные от различных датчиков, используются для разных целей. Видеоданные можно хранить вместе с данными трансмиссии или информацией с лидара. Файлы данных хранятся на общем хранилище и используются для обучения моделей ИИ, а также для тестирования программного обеспечения и оборудования в контурах управления (SIL и HIL). Разработчики внешних датчиков используют эти данные для тестирования и усовершенствования автомобильных датчиков.
В соответствии с подходом SAE (Society of Automotive Engineers), который поддерживается Национальным управлением по безопасности движения автотранспорта США (NHTSA), автономность автомобилей определяется по шестиуровневой иерархии (с Уровня 0 по Уровень 5).
Уровень 0. Без автоматизации. Автомобилем всегда управляет только человек. При этом автомобиль может быть оснащен определенными системами предупреждения, но задача динамического вождения полностью выполняется человеком.
Уровень 1. Помощь водителю. Автомобиль может выполнять определенные задачи, такие как замедление и ускорение, с помощью информации, полученной из окружающей среды. При этом человек должен всегда контролировать автомобиль и выполнять задачу динамического вождения.
Уровень 2. Частичная автоматизация. Автомобиль может совершать маневры (перестраиваться из ряда в ряд), ускоряться и замедляться. При этом человек по-прежнему постоянно контролирует движение автомобиля и выполняет все остальные аспекты задачи динамического вождения.
Уровень 3. Условная автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения, но человек должен быть способен вмешаться в управление при необходимости.
Уровень 4. Высокая автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения и может принимать решения, даже если человек не отреагирует на запрос на вмешательство. Тем не менее это возможно лишь в определенных условиях вождения, например при совместных поездках в городской местности или в регионах, для которых составлены подробные карты.
Уровень 5. Полная автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения на всех дорогах и в любых условиях, в которых в современной обстановке может вести машину человек.
Последние инвестиции и корпоративные приобретения
свидетельствуют об интересе отрасли к разработке HAD и о стремлении
как можно скорее добиться автономности Уровня 5. Корпорация Ford
инвестировала 1 миллиард долларов в Argo AI
[8]. Корпорация GM инвестировала средства в Lyft и приобрела
Cruise Automation
[9]. Корпорация Volvo создала совместное предприятие с Uber
[10]. Корпорация Uber приобрела Otto
[11]. Корпорация Intel инвестировала 15,3 миллиарда долларов
для приобретения Mobileye
[12]. Корпорации Hyundai и Toyota объявили о собственных
инвестициях в исследования и разработку HAD. Это лишь небольшая, но
достаточно репрезентативная выборка деятельности в этой весьма
динамичной отрасли.
Некоторые производители рассматривают концепцию автономные
автомобили как услуга и предполагают, что такая модель станет
важным источником доходов. Автомобили Уровня 3 станут ключевым
звеном для тестирования технологий и позволят решениям HAD выйти на
массовый рынок.
Инициатива достижения Уровня 5 набирает все большие обороты. Тем временем крупнейшие автопроизводители осваивают направление автономных автомобилей самостоятельно либо заключают партнерские соглашения с другими компаниями, разрабатывающими такие программы. Все производители по-разному подходят к решению проблемы. Компания Waymo (принадлежит корпорации Alphabet/Google) объявила, что интересуется только Уровнем 5. Другие компании, такие как Uber и Ford, готовятся к Уровню 4 [13]. Корпорации Daimler и Bosch объявили [14] о планах разработки автономных автомобилей Уровней 4 и 5 с возможным стартом производства к началу следующего десятилетия. Другие компании выбрали последовательное развитие: по мере совершенствования технологий HAD они проходят каждый из уровней.
Чтобы объединить все составные части инфраструктуры HAD, требуется организовать передачу больших объемов данных из автомобиля в центр обработки данных и в обратном направлении. Установленные в автомобиле (на границе сети) камеры, лидары и другие датчики генерируют огромные объемы данных, а в центре обработки данных производится обучение моделей ИИ и их настройка для принятия решений в реальном времени во время езды.
Поток данных от набора датчиков одного автомобиля составляет в среднем 33 Гбит/с, это примерно 120 ТБ данных за 8-часовую поездку. Технологии еще находятся на этапе разработки, поэтому в силу действующих правовых норм потребуется хранить весь объем данных с автономных автомобилей. Однодневный тест-драйв парка из 80 автомобилей это около 10 ПБ исходных данных. Следовательно, небольшой парк автомобилей будет генерировать от 100 до 500 ПБ данных в день.
3.1. Основные принципы
Кроме наличия гибкой, масштабируемой и высокопроизводительной файловой системы при создании среды исследований и разработки HAD необходимо создать возможности для параллельной разработки, моделирования и тестирования одновременно множеству разработчиков и команд разработки. Для поддержки этих потребностей со стороны разработчиков HPE может предоставить среды разработки, работающие по облачному принципу и расположенные как можно ближе к данным как в ядре, так и на границе сети.
В этих средах крайне важно свести к минимуму перемещения данных и разместить вычислительные мощности рядом с данными. Кроме того, необходимо обеспечить возможность быстрого планирования и общего использования вычислительных ресурсов и ускорителей, чтобы повысить эффективность использования среды. В такой обстановке могут оказаться полезными решения платформа как услуга и программное обеспечение как услуга, а также контейнеры с их возможностью быстрого развертывания для выполнения определенных задач.
Существуют инструменты для построения конвейеров непрерывной интеграции/непрерывной разработки (CI/CD), предоставляющие возможность гибкого и эффективного тестирования и разработки алгоритмов.
Для систем HAD уровней 3 и 4 требуются современные информационные технологии. Корпорация HPE является одним из ведущих мировых поставщиков решений в области высокопроизводительных вычислений, предлагая мощнейшие решения своим заказчикам, имеющим самые сложные вычислительные задачи.
Конечная цель (уровень 5) в реализации автономных автомобилей повсеместно доступный каршеринг, причем все без исключения люди, находящиеся в автомобиле, являются его пассажирами (а не водителями), а часть пути автомобиль может проезжать вообще без людей в салоне. При этом автомобили будут обмениваться данными друг с другом, постоянно предупреждая о своих намерениях и ходе движения по маршруту. Для этого будут использоваться технологии беспроводной связи, такие как Wi-Fi и 5G.
Пока такой уровень автономности не достигнут, для вождения и тестирования на уровнях 3 и 4 по-прежнему требуется мощная платформа для сбора, получения, преобразования, хранения и потребления данных. В этой инфраструктуре данные поступают от датчиков в автомобильный регистратор данных. Затем через бортовое хранилище данные поступают на станцию сбора данных. Оттуда данные передаются в озеро данных, где они преобразуются и подготавливаются к анализу и потреблению.
Центральным хранилищем, куда стекаются все данные, является
озеро данных: в нем хранятся все данные, собранные автомобилями, и
все данные, сгенерированные в процессе работы системы. Различные
этапы потока данных, предоставленного озером данных, см. на
рисунках:
4.1. Регистрация данных
Бортовое оборудование тестовых автомобилей собирает
данные, поступающие от датчиков, и сохраняет их, при этом скорость
потока данных может превышать 30 Гбит/с. Например, если
эксплуатационный парк из 80 автомобилей собирает 18 ТБ данных за
8-часовую смену при скорости 5 Гбит/с в каждом автомобиле, за всю
смену будет сгенерировано 1,44 ПБ сырых данных. сли же такой же
автомобильный парк генерирует данные на скорости 30 Гбит/с в каждом
автомобиле, за смену будет создано 8,64 ПБ данных.
Для таких высоких скоростей данных рекомендуется конвергентная
система для границы сети
HPE Edgeline EL8000. Это универсальная модульная конвергентная
платформа, объединяющей вычислительные ресурсы и ресурсы хранения
данных, и допускающая подключение датчиков. Системы HPE EL8000
могут работать в более жестких условиях окружающей среды, чем
стандартное ИТ оборудование, и поддерживают удаленное управление.
HPE EL8000 это идеальный регистратор данных, представляющий собой
интегрированное расширение центра обработки данных.
Система HPE EL8000 может принимать десятки гигабит данных в секунду
от лидаров, радаров и видеопотоков, это практичная конвергентная
автомобильная вычислительная платформа для тестирования и
разработки. Каналы ввода-вывода шины PCIe в системах HPE EL8000
связаны напрямую с ЦП, обеспечивается непосредственный доступ к
внутренней шине ЦП. Таким образом, данные напрямую движутся в
память и из памяти, а также в кэш процессора и в другие устройства
PCIe.
HPE EL8000 это не просто модуль хранения данных. Эта система
поддерживает 64-разрядные ЦП x86 и специализированные ускорители
вычислений, в том числе видеоускорители (GPU) и П ИС. В этом
отношении HPE EL8000 представляет первый шаг конвейера
преобразования данных. HPE EL8000 может устранить одно из узких
мест потока данных за счет автоматической разметки содержимого
тегами на лету. При этом снижается объем необходимых операций
предварительной обработки.
4.2. Получение данных
Существует два способа выгрузки данных.
Замена физических носителей. Система HPE EL8000 оборудована накопителями с поддержкой горячей замены; можно вставлять накопители в автомобильную систему и извлекать их. При этом в качестве носителей данных используются твердотельные накопители, чтобы свести к минимуму риск потери данных при манипуляциях и транспортировке. Носители информации передаются в местный центр сбора информации, информация с них считывается и по высокоскоростным каналам передачи данных передается в ЦОД.
Выгрузка данных по высокоскоростным локальным сетям в станции сбора данных или центры обработки данных. В этом случае для выгрузки данных с автомобилей в станции сбора данных используется локальная сеть. Станции сбора данных расположены в центрах обработки данных, где автомобили подключают непосредственно к сети ЦОД. После подключения автомобили выгружают данные в указанные целевые системы по каналам с пропускной способностью 100 Гбит/с.
Дополнительная станция сбора данных может использоваться для
буферизации данных, поступающих из автомобиля, чтобы дать
возможность автомобилю как можно быстрее вернуться на дорогу.
Станция сбора данных не только осуществляет буферизацию, но и
служит первой точкой определения приоритета данных. В любом
тест-драйве большая часть данных с высокой вероятностью не будет
содержать важных событий и не будет представлять немедленной
ценности для процесса разработки. Тем не менее некоторые события
будут очень важны для разработчиков. Для таких случаев на станции
сбора данных проводится приоритетная отправка, что дает возможность
быстрее высвободить автомобиль и предоставить разработчикам самые
важные данные в первую очередь. Разработчики могут применять
различные алгоритмы определения приоритета, для которых могут
потребоваться и более мощные вычислительные ресурсы, чем есть в HPE
EL8000.
4.3. Озеро данных
Основная проблема технологии хранения данных,
выбранной для этого процесса, состоит в масштабируемости. На
рисунке 6 показаны различные варианты файловых систем,
различающихся по уровню масштабируемости и производительности.
Параллельные файловые системы, такие как Lustre, поддерживают
линейное масштабирование решений. Система Lustre дает возможность
создавать компоненты заданного размера и производительности, а
также позволяет с высокой гибкостью добавлять дополнительные
компоненты по мере необходимости. На рынке есть очень немного
решений, обладающих такой надежностью, производительностью, высокой
емкостью и масштабируемостью на этом ценовом уровне.
Для параллельных файловых систем также доступны программные
интерфейсы доступа по традиционным файловым протоколам систем
POSIX, а также интерфейсы Hadoop, традиционные для Больших
данных.
Некоторые клиенты пользуются другими распределенными
крупномасштабными средами, включая Hadoop Distributed File System
(HDFS), Ceph и даже решения, совместимые с S3. Например, HDFS
работает на стандартном оборудовании и легко масштабируется. HDFS
также назначить разные уровни хранения данных в зависимости от их
температуры. Самые горячие данные, к которым требуется быстрый
доступ, размещаются на самых быстрых накопителях, а холодные данные
на менее скоростных дисках. Такой подход дает возможность создать
озеро данных с невысокими затратами и оптимизировать систему с
точки зрения важности данных и потребности в них.
4.4. Методики Программное обеспечение в контуре управления
(SIL) и Оборудование в контуре управления (HIL)
В отчете, опубликованном в 2016 году
[15], корпорация RAND подсчитала, что для снижения количества
ДТП со смертельным исходом на 20 % автономные автомобили должны
проехать около 11 миллиардов миль. сли использовать парк из 100
автомобилей, которые ездят круглосуточно 365 дней в году со средней
скоростью 25 миль в час, для выполнения этой задачи потребуется 518
лет. Очевидно, требуется другое решение.
Для решения этой задачи компании, занимающиеся разработкой
автономных автомобилей, применяют методики SIL и/или HIL,
ускоряющие тестирование.
Корпорация HPE располагает опытом создания и поставки систем
моделирования для автомобильных компаний во всем мире. В этих
решениях HPE обычно использует шасси
HPE Apollo 2000 Gen10 с серверами HPE XL170r для вычислений с
использованием центрального процессора и с серверами HPE XL190r для
вычислений с использованием видеокарт (GPU).
Индивидуальные рабочие процессы SIL создаются на основе системы
контроля и управления (CMS). Система CMS поддерживает планирование
событий по времени и обработку очередей действий, которые будут
выполняться параллельно в зависимости от наличия свободных
ресурсов.
Размещение систем SIL вместе с системами хранения данных
обеспечивает более высокую гибкость по выполнению требований к
пропускной способности, необходимых для оптимальной работы SIL.
Возможна организация доступа к системам SIL из любой точки мира для
поддержки инженеров из разных стран.
Модель Оборудование в контуре управления (HIL) также
можно интегрировать в основную сеть ЦОДа для организации
высокоскоростного доступа к озеру данных. Поскольку требуется очень
высокий уровень производительности, для конфигурации HAD
предпочтительно использовать высокоскоростные среды передачи
данных, такие как InfiniBand и Intel Omni-Path. Также стоит
предусмотреть дополнительные каналы Ethernet 10 Гбит/с для
реализации глобальной связности и индивидуальных проектов HIL.
4.5. Архивация и резервное копирование
Для создания системы HAD может потребоваться немало
тестовых автомобилей, каждый из которых ежедневно генерирует
терабайты данных. Легко заметить, что такой автомобильный парк
может быстро создать сотни петабайт данных. При этом данные после
их получения необходимо очищать, разделять и преобразовывать,
создавая разные версии (в разных форматах) одной и той же
информации.
Кроме того, в силу действующего законодательства и собственных
политик, компании может также потребоваться архивация и резервное
копирование данных. Для длительного хранения данных корпорация HPE
предлагает решение
Data Management Framework (DMF). Это иерархический диспетчер
хранения данных с более чем 20-летней историей успешной
эксплуатации. HPE DMF автоматически отслеживает свободное
пространство в управляемой файловой системе. За счет этого
гарантируется наличие необходимого свободного места, а системные
администраторы избавляются от рутинной необходимости постоянно
отслеживать загрузку ресурсов хранения данных и добавлять
новые.
HPE DMF сохраняет информацию о метаданных и о данных предыдущих
версий файлов, поэтому администраторам доступна полная история
эволюции и полное содержимое файловых систем; можно вернуться к
любому моменту и восстановить любые данные. При обращении к истории
версий можно восстанавливать как файловые системы целиком, так и их
фрагменты, указав необходимую точку во времени.
Ленточное решение HPE DMF построено на основе ленточной библиотеки
HPE TFinity ExaScale на базе технологии Spectra. TFinity ExaScale
это самая вместительная в мире отдельно стоящая система хранения
данных
[16]. Одна библиотека TFinity EE способна хранить до 53 450
ленточных картриджей на 44 шкафах.
При использовании технологии сжатия TS1150 емкость системы
превышает 1 эксабайт. Благодаря решению Dual Robotics и 72
накопителям LTO-8 скорость записи достигает примерно 21 ГБ/с, а
емкость 100,2 ПБ при использовании картриджей 8350 LTO-8 (четыре
дорожки).
Корпорация HPE занимает ведущую долю на рынке высокопроизводительных вычислений и обладает широчайшими возможностями для реализации решений HAD с самыми высокими требованиями к вычислительным ресурсам, системам хранения данных и сетевым ресурсам.
5.1. Создание
Организация
HPE Pointnext Services создает полнофункциональную платформу
для клиентов от центра обработки данных до конечных устройств (в
данном случае это станции сбора данных и автомобильные регистраторы
данных) и вплоть до готовых приложений для разработчиков. В
зависимости от потребностей и целей клиента специалисты HPE
Pointnext Services в области ИИ и обработки данных помогут:
исследовать цели и приоритеты сценариев использования для бизнеса, данных и участников ИТ-экосистемы;
определить функциональность ИИ и аналитики, необходимую для достижения поставленных целей;
выявить зависимости и источники данных для выработки стратегии интеллектуальной обработки данных.
5.2. Выполнение
Запуск в эксплуатацию налагает требования по
необходимому уровню операционной поддержки для всех компонентов,
чтобы обеспечить оптимальную доступность для поддержки бизнеса.
Предоставляя услуги операционной поддержки HPE Pointnext Services,
корпорация HPE может помочь в реализации операционных задач системы
HAD.
Услуги адаптивного управления HPE являются составным компонентом
решений HPE
GreenLake: ИТ-услуги предоставляются по модели с оплатой за
использование. Эта платформа позволяет решать эксплуатационные
задачи для инфраструктуры компании, включающей серверы, системы
хранения данных, сети, инфраструктурные программные решения,
гипервизоры, системы резервного копирования и восстановления
данных, а также средства безопасности, а также межплатформенное и
прикладное ПО, разработанное компанией HPE и определенными
сторонними поставщиками.
5.3. Потребление
Если вам требуется гибкость и полный контроль в
локальной среде или публичном облаке, воспользуйтесь предложением
HPE GreenLake это набор ИТ-решений с оплатой по фактическому
потреблению. Предлагаем каталог полных проверенных решений,
позволяющих добиться нужных результатов в области ИТ с
использованием оборудования, программного обеспечения и знаний на
ваших площадках по модели с оплатой за использование.
5.4. Партнеры
При разработке решений HAD могут возникать этапы,
когда партнерами HPE могут становиться не только наши конечные
потребители, но и другие организации (в целях создания лучших
платформ и служб для HAD). Пример такого партнерства
транспортировка носителей с информацией, собранной в процессе
тест-драйва. В месте проведения тест-драйва пропускная способность
сетевого подключения может оказаться недостаточной для отправки
данных. В партнерстве с курьерской службой мы можем обеспечить
доставку носителей информации в ближайшую станцию сбора данных в
кратчайшие сроки.
Партнерство может работать в различных формах. Возможно, что у
клиента уже есть поставщик ИТ-услуг и заказчик хотел бы реализовать
платформу HAD силами этого же поставщика. Как вариант, клиентов
заинтересует сотрудничество HPE с этими поставщиками услуг, чтобы
обеспечить плавный и эффективный переход от этапа создания решения
к этапу его использования. Корпорация HPE вместе с поставщиками
услуг предлагает конечным потребителям создание и выполнение услуг,
созданных HPE в содружестве с другими разработчиками. Каждый
партнер привносит собственные услуги в экосистему и обеспечивает
всестороннее обслуживание клиента.
В дорожно-транспортных происшествиях во всем мире ежегодно
гибнет около 1,35 миллиона человек. Аварии на дорогах обходятся
большинству стран в 3% их внутреннего валового продукта. От 20 до
50 миллионов человек получают несмертельные травмы, часто
приводящие к нетрудоспособности
[18].
Автомобили высокой автономности стремительно растущий рынок, цель
повышение безопасности и здоровья общества. По оценкам
специалистов, если распространение автономных автомобилей достигнет
10, 50 и 90%, это может привести к снижению числа человеческих
жертв соответственно на 1100, 9600 и 21 700 человек в США за год
[19].
Разумеется, HAD непростая задача. Для ее решения требуются самые
передовые и совершенные технологии, доступные на рынке в настоящее
время, включая нейросети машинного обучения и глубинного обучения,
современные ускорители вычислений, высокопроизводительные сети и
среды передачи данных.
Предложения HPE позволяют удовлетворить потребности автомобильной
промышленности в современных решениях ИИ и
высокопроизводительных вычислений для облачных развертываний HAD.
При этом клиенты могут приобрести и эксплуатировать решения
самостоятельно, а также заключить договор с HPE (используя HPE
Pointnext Services, HPE GreenLake и другие предложения услуг) и
поручить нашей корпорации обработку некоторых или всех
вычислительных задач для HAD. Корпорация HPE предлагает полный
ассортимент вычислительных систем, сетевых решений, систем хранения
данных и технической поддержки и услуг по всему миру, гарантируя,
что разработчики уже сегодня могут приступить к созданию
оптимальных решений HAD для надежных и безопасных транспортных
сетей будущего.
Разработка и запуск нового продукта - это всегда риск. Зайдет, не зайдет. Все зависит от возможностей (люди, деньги), компетенций, опыта, да и в целом понимания, зачем все это делать. Даже самая детально проработанная стратегия может в итоге провалиться. Главное понимать, в чем реальная польза продукт, тогда и процесс разработки пойдет увереннее.
С таким подходом мы пришли в 2019 к разработке готового решения для автоматизации торговли на маркетплейсах - RDV Маркет. Сделали его на бессмертной системе 1С. Ее мы знаем от и до, и убеждены, что для запуска нового проекта с точки зрения бизнеса - это наиболее подходящий вариант. Но об этом позже. Пока расскажем, как все начиналось, и к чему в итоге привело. Погнали.
Начали работу в 2018 году. Нас пригласили для интеграции goods с магазином М. Видео. Работу над процессом начали с построения архитектуры OMS (система управления заказами) вместе сразработчиками и аналитиками goods.
Наша команда выступала в качестве бизнес-консультантов. Мы прописывали ТЗ для проектной команды заказчика, строили алгоритм действий, что и как должно работать. На стороне M.Видео специалисты занимались подготовкой и выгрузкой товарных предложений (фидов), а сами заказы поступали через API goods.
Конечно, были баги. В процессе боевого тестирования интеграции заметили, что до маркетплейса систематически не поступает часть заказов, а до магазина не доходят конечные платежи. Чтобы разобраться в причине сбоя, вносили корректировки в OMS и дорабатывали вместе с аналитиками проекта биллинговую систему. В итоге исправили ошибки, и рабочий процесс пошел более или менее продуктивно.Но все равно большинство операций нужно было делать вручную, постоянно перепроверять каждый заказ, чтобы передавались корректные данные.
В итоге пришли к пониманию, что в таком режиме работать нельзя. Нужно было уходить от разрозненных бизнес-процессов и ручного вмешательства. Тогда и появилась идея готового решения, которое позволит быстро вывести продавца на площадку, автоматизировав большинство рабочих процессов.
Итак, М. Видео продавал через goods, а мы вплотную занимались вопросом упаковки интеграции в отдельную автоматизированную систему. Долго не раздумывали, на чем будем делать - мы знали 1С, какие у нее есть возможности, поэтому решение запилили именно на ней. Плюсы у нее весьма ощутимые.
Во-первых, с типовыми конфигурациями работает большинство компаний. Таким образом, им будет проще начать работу с нашим решением, так как все будет происходить в их привычной "среде обитания". Все операции в общем окне 1С!
Во-вторых, система надежна. Ее уровня нагрузки достаточно для работы крупных компаний с количеством пользователей > 1000. В 1С можно спокойно систематизировать и масштабировать процессы под потребности компании.
Еще один важный момент помимо технической оснащенности, что 1С оперирует понятиями бизнес-объектов. Для выстраивания рабочих процессов с маркетплейсами это только в плюс.
Да, сам интерфейс привлекательным не назовешь. Не ждите от нас крутых скринов :) Тут 1С себе не изменяет. Но для нас в данном случае важнее всего все-таки возможности системы, ее адаптивность и гибкость.
У нас была четкая цель - получить решение, которое встраивается в 1С и автоматизирует процессы торговли на маркетплейсе. Все просто.
Что делали.
Шаг 1. Собрали обратную связь от продавцов goods, кто на какой учетной системе работает. Для этого сделали рассылку по базе и узнали, что у большинства установлены:
1С:ERP;
1С:Комплексная автоматизация;
1С:Управление торговлей.
Была еще 1С УНФ (управление небольшой фирмой), но так как у нее мало функций под расширенную автоматизацию складских процессов, решили пока что ее не рассматривать. Но, возможно, придумаем что-то и с этой конфигурацией.
Шаг 2. Начали прорабатывать функционал и roadmap первой версии продукта. За основу взяли спринтовый вариант управления разработкой, с которым экспериментировали на goods. И где-то в течение первого полугодия выпустили первый релиз системы.
В функционал первой версии заложили автоматическую выгрузку товарного ассортимента в каталог (YML). Так как на примере goods поняли, что при увеличении количества товаров ручная работа с выгрузкой - это неэффективно, трата времени.
В планах было запустить 2 версии продукта. Взяли идею 1С про ПРОФ И КОРП. Собственно, отличия были соответствующие - в КОРП был шире функционал.
Помимо автоматической выгрузки фидов в первом релизе программы для ПРОФ было реализовано автоподтверждение заказов. До этого продавец мог только вручную пройтись по всем заказам. Да, если у него их всего 10 штук, то здесь проблемы нет. Но это такие редко встречаются.
Также в первой версии мы вплотную подошли к реализации функционала по автоматизации процесса комплектации заказов и учета отгрузки товаров.
Проблема задержки товаров на складе встречается довольно часто. При нарушении сроков отгрузки происходит блокировка аккаунта продавца, соответственно, тормозится процесс продаж, и компания несет убытки. Нам было важно сделать так, чтобы подобные ситуации сводились к минимуму, поэтому настроили единое место комплектации и отгрузки (APM кладовщика), тем самым сэкономили время на сбор и отправку заказов.
Несмотря на то, что первая версия на начальном этапе решала часть проблем с ручным вмешательством, ошибки и непонимание, как это сделать, а нужно ли это вообще, естественно, возникали.
Мы понимали, что с решением будет работать именно продавец, а не разработчик или аналитик. Поэтому старались максимально упростить любые процессы. Должна была получиться удобная система с понятной структурой: создание и загрузка товарного фида, автоматический прием и подтверждение заказа, отправка на комплектацию и отгрузку, дальнейшая доставка товара до клиента и учет платежных операций и закрывающих документов.
В ходе рабочего процесса появлялись новые баги. Например, долго пилили финансовый модуль. Контроль взаиморасчетов изначально был довольно поверхностным, и много что приходилось делать руками. Мы хотели связать все финансовые операции по маркетплейсам, чтобы пользователь мог в одном месте видеть полную информацию по проведенным платежам, отправленным актам, а также за пару кликов вносить изменения.
Помимо этого большой пул работ был по разработке функционала обновления остатков. Мы заложили его в релиз на будущее сразу же после окончания первой интеграции с goods. Понимали, что остатки на складах будут и их необходимо реализовывать.
Вопрос по работе с остатками стоял довольно остро. Разберем на простом примере. Магазин отправил на витрину 5 позиций, которые заказали покупатели. Но в это время в оффлайн уже было продано 2 товара из отправленных. Из-за того что на витрине маркетплейса никто не обновил остатки (в системе отображались только примерные данные), с маркетплейса было продано 5 товаров, но по факту в оформление ушло 3. То есть остальные заказы пришлось отменить. А с этим частить нельзя.
Рост отмен заказов отрицательно влияют на работу магазина, т.к. может произойти блокировка аккаунта (как и при сдвигах сроком отгрузки заказов). На сегодняшний день в текущей версии RDV Маркет реализовано автоматическое обновление остатков, что позволяет снижать или минимизировать % отмен, не доводя до критического момента.
В процессе работы над проектом пришла идея о возможности загрузки инфомоделей для товарного ассортимента (характеристики). Хотели сформировать в 1С инфомодели для каждого маркетплейса по всем категориям товаров, чтобы была возможность продавцам оперативно готовить свои каталоги и передавать их с минимум ошибок (в идеале - без) в маркетплейс. Но здесь не все так просто с получением подобного контента, поэтому идея пока висит - поставили ее в план на ближайшее будущее.
Goods развивался, привлекая все больше продавцов. А мы двигались
дальше - хотели запартнериться с другими популярными
маркетплейсами. На рынке уже активно вели свою деятельность
Wildberries, Ozon и Беру (сейчас это Яндекс.Маркет).
Мы начали с последнего. Причем начали довольно дерзко
уверенно, сразу разместив информацию об интеграции с Беру у себя на
сайте. Хотя на тот момент формального партнерства еще не было. Но
так как их API была в открытом доступе, то мы успели все
протестировать и настроить полноценную интеграцию с
маркетплейсом.
Далее нас заметил Wildberries, который пришел к нам, когда продавал только по модели FBO (продажа со склада маркетплейса). Не так давно на WB случился прорыв - он заработал по схеме FBS (продажа со склада продавца). Здесь можно посмотреть, как мы настроили работу по новой схеме в 1С.
Чуть позже к нам присоединился Ozon - маркетплейс с непростой системой резервов. Площадка работает таким образом, что товар резервируется сразу, как только покупатель оформил заказ. Допустим, клиент неверно ввел данные карты, чтобы все исправить и оплатить покупку, ему дается 30 минут.
Вроде все ок. Но дело в том, что если продавец работает с несколькими каналами продаж, когда сезон высокого спроса, и допустим на складе не так много остатков, то при потоке заказов, менеджер маркетплейса может данный заказ отправить другому покупателю. И будет отмена. Мы настроили систему так, что таких потерь можно избежать - история резервов сохраняется в режиме онлайн,они формируются до того, как создался заказ, и продавец не превышает порог отмен.
Работаем с Wildberries, Ozon, Я.Маркет, goods, а недавно подключили AliExpressКликайте сюда, чтобы разобраться подробнее, что и как работает в RDV Маркет.
Что дальше? Идей много. Например, хотим сделать запуск решения по одному клику на кнопку, чтобы сократить количество шагов в настройках. А также смотрим в сторону реализации мобильного приложения и ребрендинга продукта.
В общем, работаем.
Готовы ответить на вопросы, подробнее рассказать про функционал - welcome в RDV Маркет!