Сбор данных

Как Uber хочет сделать беспилотные автомобили, так и Spotify хочет создавать музыку с помощью компьютера.

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

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

Плагиат серьезная проблема в музыкальной отрасли. Достаточно вспомнить судебную тяжбу в отношении композиции Blurred Lines, по итогу которой суд постановил, что Робин Тик и Фаррелл Уильямс скопировали один из хитов Марвина Гэя, и поэтому должны выплатить семье автора более 5миллионов долларов. С помощью описанной в патенте системы проблему с плагиатом мелодии можно было бы своевременно устранить даже виртуальные чернила не успели бы высохнуть.

На других платформах (например, YouTube) есть системы идентификации музыки, защищенной авторским правом (YouTube называет ее ContentID), но подход Spotify больше ориентирован на авторов, создающих музыку, а не на тех, кто добавляет уже защищенную авторским правом музыку в видео. Кроме того, системы вроде ContentID полагаются на анализ самого звука, а не соответствующих нот.

Музыкант передает компании нотную тетрадь документ, описывающий мелодию, аккорды, а иногда и текст песни.

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

Джордж Ховард (George Howard), профессор теории музыкального бизнеса в колледже Беркли, настроен в этом отношении скептически. Ховард бывший президент музыкального лейбла Rykodisc, владелец одноименной консалтинговой фирмы и сооснователь компании Music Audience Exchange, которая помогает авторам лицензировать музыку для брендов. Также он стоял у истоков сервиса TuneCore, посредством которого исполнители продают музыку на крупных стриминговых платформах (например, Spotify).

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

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

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

Как Uber хочет сделать беспилотные автомобили, так и Spotify хочет создавать музыку с помощью компьютера, говорит Ховард.

Предположение о потенциале Spotify по созданию музыки с использованием ИИ высказываются и другими особенно в свете того, что в качестве главы исследовательской лаборатории Spotify Creator Technology Research Lab фирма наняла Франсуа Паше. При этом компания уклоняется от ответа на вопрос, является ли создание музыки одной из конечных целей.

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

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

Самый известный проект Паше Flow Machines в создании музыки в значительной степени полагался на нотные тетради и привлек внимание прессы после того, как в его рамках искусственным интеллектом впервые была создания поп-песня. Перед этим Паше с командой пять лет (с 2012 по 2017г.) собирали базу данных, в которой в итоге оказалось более 12000машиночитаемых нотных тетрадей, использованных для обучения алгоритмов.

В 2016г. Паше стал соавтором статьи, описывающей алгоритм, генерирующий новую музыку в стиле Баха о чем я уже писал. Несколько месяцев спустя, в начале 2017г., Паше стал одним из авторов исследования о вариантах выборки нотных тетрадей Sampling Variations of Lead Sheets, в котором группа исследователей вышла за рамки репертуара Баха. Например, алгоритм сгенерировал список потенциальных нотных тетрадей для версии In A Sentimental Mood Дюка Эллингтона и Джона Колтрейна в стиле The Beatles.

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

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

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Привет, Хабр! Я люблю считать и собирать данные. 2020 год состоял из 8784 часов, 4874 из которых я смог учесть в собранной мною статистике. Я знаю как потратил 55% всего прошлого года! В этой статье я постараюсь доказать, что учиться в университете совсем не сложно, а также расскажу о своем методе учета времени, и заодно проанализирую собранные за год данные о временных затратах почти на все, чем я занимаюсь. С самого начала учебы в университете на старте каждого семестра я наблюдал вздыхающих студентов: "Ой ряды начались! А теперь страшный теорвер! Диффуры душат. Как же сложно закрыть ТАУ или случайные процессы". И каждый раз мы сдавали экзамены, и каждый раз выдыхали с облегчением, ведь столько времени потратили, такую сложную задачу решили А насколько сложную? А сколько времени? Чем дальше, тем чаще я задавался этими вопросами, ведь субъективные мнения такие субъективные. Мы ведь в техническом вузе учимся, где циферы? С тех пор как я стал хорошо учиться, меня все больше озадачивали суждения других студентов обо мне, мол просто с мозгами повезло. Причем на мой вопрос, сколько времени они ботали на этой неделе я часто слышал: "Ну не знаю, примерно часа два". Недавно я смог совершенно четко самому себе отвечать на этот вопрос, и собрал доказательства в пользу очевидного тезиса: в вопросах учебы дело вовсе не в везении с объемом серого вещества в голове, а в количество потраченного времени.

Около двух лет назад стал пользоваться сервисом clockify.me где мои деньги за рекламу?. В начале прошлого года я стал интересоваться Data Science, а к его концу собрал неплохой датасет, который и хочу проанализировать, одновременно сдобрив его мыслями о жизни, вселенной и всем таком, а также воспоминаниями и главное, попытками выжать из имеющихся данных знания. Ведь в этом и заключается работа дата сайнтиста?

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

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

import mathimport pandas as pdimport numpy as npimport matplotlib.pyplot as pltimport seaborn as sns%matplotlib inlineimport matplotlib.dates as datesimport matplotlib.dates as mdates                file_name = "CLK 31 12 20.xlsx"sheet =  "Sheet 1"df = pd.read_excel(io=file_name, sheet_name=sheet)print(df)print(df.info())

[2823 rows x 4 columns]<class 'pandas.core.frame.DataFrame'>RangeIndex: 2823 entries, 0 to 2822Data columns (total 4 columns): #   Column              Non-Null Count  Dtype         ---  ------              --------------  -----          0   Project             2823 non-null   object         1   Description         2823 non-null   object         2   Start Date          2823 non-null   datetime64[ns] 3   Duration (decimal)  2823 non-null   float64       dtypes: datetime64[ns](1), float64(1), object(2)

projects = df.Project.unique()descriptions = df.Description.unique()for project in projects:    print("\n Проект: ", project, "\n Задачи:")    for description in df[df.Project == project].Description.unique():        print("       ", description)

Задача:  Rest  Подзадачи:        Games        Watching anime        Watching films        Kara no Shjo        Doki-Doki! Задача:  Life  Подзадачи:        Sleep        Walks Задача:  Study at home  Подзадачи:        m_3_Other        m_3_ILNT        m_3_C-A DaP S        m_3_Research work        m_3_ET_in_SR        m_3_Course_work        m_3_IPT_in_IMR        m_2_Practice        m_2_English_courses        m_2_AIS_MR        m_2_HaSCS_IMR        m_2_S-LaF_in_CS_IMR        m_2_K_Practice        m_2_Research work        m_2_Course_work        Other        m_2_Other        m_1_GT_MIMR        m_1_OMaT        m_1_Practice        m_1_AB_ACS        Schedule        m_1_SDoAS        m_1_English        m_1_IS_MaR        Master's dissertation        b_8_Math for master's        b_8_DepLoME        b_8_GOSI        b_8_AI        b_8_Research work        b_7_Prak 7        b_8_Basics of designing        b_8_VM        b_8_Electronics Задача:  Development  Подзадачи:        Data Science        Drawing        Guitar        Reading books        SQL for DS        Japanese        Writing        Sport        English        Python        Machine Learning        Handmade        Python finance        Reading articles        Programming Задача:  Studying at the University  Подзадачи:        m_3_ET_in_SR        m_3_English_courses        m_3_IMR_CS_TA        m_3_IPT_in_IMR        m_3_C-A_DaP_S        m_3_ILNT        m_2_English_courses        m_2_S-LaF_in_CS_IMR        m_2_HaSCS_IMR        m_2_K_Practice        m_2_Practice        m_1_AB_ACS        m_1_GT_MIMR        m_1_SDoAS        m_1_English        m_1_IS_MaR        B&R Practice        m_1_OMaT

def remove_duplicates(df):    date = df["Start Date"].to_numpy()    time = df["Duration (decimal)"].to_numpy()        length = len(date)    remove_list = []    for i in range(length - 1):        for j in range(i + 1, length):            if date[i] == date[j]:                time[i] += time[j]                if not j  in remove_list:                    remove_list.append(j)        df = df.drop(df.index[remove_list])    date = np.delete(date, remove_list)    time = np.delete(time, remove_list)    return df

data = pd.DataFrame()for project in projects:    descriptions = df[df.Project == project].Description.unique()    for description in descriptions:        df_temp = df[df.Project == project]        df_temp = df_temp[df_temp.Description == description]        new = remove_duplicates(df_temp)        data = data.append(new, ignore_index=True)            print(data.info())df = data

<class 'pandas.core.frame.DataFrame'>RangeIndex: 2095 entries, 0 to 2094Data columns (total 4 columns): #   Column              Non-Null Count  Dtype         ---  ------              --------------  -----          0   Project             2095 non-null   object         1   Description         2095 non-null   object         2   Start Date          2095 non-null   datetime64[ns] 3   Duration (decimal)  2095 non-null   float64       dtypes: datetime64[ns](1), float64(1), object(2)

def reindex(data_frame, name='data', start_date='1-1-2019', end_date='12-31-20'):    idx = pd.date_range(start_date, end_date)    dates = pd.Index(pd.to_datetime(data_frame['Start Date'].tolist(), format="%Y%m%d"))        column = data_frame['Duration (decimal)'].tolist()    column = [float(i) for i in column]    series = pd.Series(column, dates)    series.index = pd.DatetimeIndex(series.index)    series = series.reindex(idx, fill_value=0)        data = series.to_frame(name=name)    return data  def plot_kde(data_frame, col_name):    fig = plt.figure(figsize=(14, 7))    ax = fig.add_subplot(111)    sns.distplot(data_frame[col_name], hist=True, ax=ax, bins=20)    fig.savefig('kde.png', dpi=300)# Помимо баров также прорисую линию среднего значения и среднее отклонение.   def plot_bar(data_frame, img_name):    fig = plt.figure(figsize=(20, 10))    ax = fig.add_subplot(111)    data_frame.plot.bar(ax=ax, legend=False)        ax.xaxis.set_major_locator(dates.MonthLocator())    ax.xaxis.set_major_formatter(dates.DateFormatter('\n\n\n%b\n'))    plt.tight_layout()    ax.tick_params(labelsize=20)    ax.set_xlabel("Месяц 2020", fontsize=25)    ax.set_ylabel("Время", fontsize=25)            plt.axhline(y=data_frame.data.mean(), color='r', linestyle='-')    x = list(range(0, data_frame.data.shape[0]))    mean = data_frame.data.mean()    std = data_frame.data.std()    ax.fill_between(x,                    (mean - std) if (mean - std) > 0 else 0,                    mean + std,                    color='silver')    plt.tight_layout()    fig.savefig(img_name, dpi=500)    return ax# Да, я хотел написать это своими руками :)    def stat(data_frame, col_name):    print("Sum: ".ljust(10), "%0.2f" % data_frame[col_name].sum())    print("Mean: ".ljust(10), "%0.2f" % data_frame[col_name].mean())    print("Std: ".ljust(10), "%0.2f" % data_frame[col_name].std())    print("Min: ".ljust(10), data_frame[col_name].min())    print("Max: ".ljust(10), data_frame[col_name].max())    print("Zero: ".ljust(10), (data_frame[col_name] == 0).astype(int).sum())    print("Not zero: ".ljust(10), (data_frame[col_name] != 0).astype(int).sum())

Анализ временных затрат на полезности и бесполезность

Пришло время смотреть на палочки заняться разведочным анализом! Начнем со сна. В этом случае пропуски в данных нужно заполнить не Nan-ами, а средним значением. Причем в некоторых случаях объект исследования действительно не спал сутки, а в некоторых просто забил на сохранение данных. Будем считать, что если встречается один пропуск посреди данных, то сутки были бессонными, а если пропусков сразу несколько, то поля нужно заполнить средним значением.

start_date = '1-1-2020'end_date = '12-31-2020'sleep_data = df.loc[df['Description'].isin(['Sleep'])]sleep_data = reindex(sleep_data,                     start_date=start_date,                     end_date=end_date)sleep_data['data'] = sleep_data['data'].replace({0:np.nan})sleep_arr = sleep_data['data'].to_numpy()for i in range(1, len(sleep_arr - 1)):    if math.isnan(sleep_arr[i]) and not math.isnan(sleep_arr[i - 1]) and not math.isnan(sleep_arr[i + 1]):        sleep_arr[i] = 0        sleep_arr[np.isnan(sleep_arr)] = np.nanmean(sleep_arr)sleep_data['data'] = sleep_arrstat(sleep_data, 'data')plot_bar(sleep_data, 'sleep.png')plot_kde(sleep_data, 'data')

В итоге, за год я проспал 3224 часа. Для полноты картины стоит заметить, что в этом году всего было 8784 часа. Со средним ладно, а вот отклонение слишком большое. Ну и минимум с максимумом в виде 0 и 20 часов выглядят не очень. На добивании 16 суток без сна. Хорошо еще, что на графике не видно, как часто мой режим переворачивается вверх тормашками. Определенно, нужно что-то менять

Можно было бы перевести во временной формат, но и без этого все понятно.Sum:       3224.42Mean:      8.81Std:       3.28Min:       0.0Max:       20.0Zero:      16Not zero:  350

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

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

Итого 152 часа за год. На самом деле я читал книги 216 часов, но недостающая часть времени записана в DS, потому что читал я Рашку, Николенко и прочих. В целом, в этом году я читал мало, и объясняется это очень просто. Много читать, а точнее слушать книги, я стал в тот момент, когда вдруг заметил, что в универ мне ехать полтора часа в одну сторону, а кубик Рубика уже реально надоел, да и люди косятся. И не потому, что я гениально выучил целых восемь комбинаций, а из-за шума. Так вот в этом году я в университете почти не появлялся (из-за пандемии и уменьшения количества пар), отсюда и низкие показатели. Странно осознавать, как сильно внешние условия могут влиять на жизнь. А еще страннее объяснять знакомым, почему мне выгодно ехать в универ даже на одну пару.

Sum:       152.50Mean:      0.42Std:       0.89Min:       0.0Max:       7.73Zero:      267Not zero:  99

Искусство и страх (годна книга, кстати). Ну тут все плохо. Получше, чем за все пять прошлых лет, но недостаточно. Однако, все собранные мною данные можно легко использовать как почву для поиска мотивации. За это время я перешел в digital и освоил несколько интересных инструментов и техник, так что почувствовал неплохой прирост качества, причем стоило этого всего 47 часов. Уф, а если за год я порисую часов эдак 100, или 160. Уф, это ведь всего пол часа в день Но все равно заставить меня взять в руки планшет не для игры в osu, а для рисования очень и очень сложно.

Sum:       46.60Mean:      0.13Std:       0.58Min:       0.0Max:       5.8Zero:      339Not zero:  27

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

Sum:       90.69Mean:      0.25Std:       0.58Min:       0.0Max:       3.13Zero:      282Not zero:  84

Оо, нихонго. Решил я в третий раз штурмовать учебник Струговой и в этот раз бросил его не на пятнадцатой и даже не на пятидесятой страницей, а аж на сто восьмидесятой! Когда садился ботать, задача казалась нереально сложной. Некоторые иероглифы имеют до пяти чтений, да еще и запоминаются ну реально тяжело. А когда вся дневная норма в пять страниц выпадала на грамматику, я вообще хотел заняться вообще чем угодно, только не этим (хоть за курсачи сесть). Но если взглянуть на данные, то потратил-то я всего 50 часов, а проработал много материала и сильно продвинулся. Ватащи ва нихонго во декимасу сукощи декимасу тотему сукощи декимасу Ну ладно, декимасен не умею я, но прирост знаний меня впечатлил. На графике видны два пика мотивации и плато безнадежности. Выводы таковы. Большой ошибкой было выставлять чрезмерные нормы, и попытка жестко придерживаться расписания. Сначала я проходил пять страниц в день без выходных, потом добавил выходные, потом снизил объем до трех страниц, а потом забил, выгорел. Впрочем, ничего нового.

Sum:       52.42Mean:      0.14Std:       0.45Min:       0.0Max:       3.18Zero:      320Not zero:  46

Да всего-то пара пабов в день, аим потренить.

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

Sum:       344.03Mean:      0.94Std:       1.62Min:       0.0Max:       12.0Zero:      165Not zero:  201

А теперь data science. Воспользуюсь размытостью данного понятия и засчитаю сюда вообще все, что связано с работой с данными. Конкретно этим направлением я стал интересоваться примерно в марте, а до этого просто кодил что-то для себя. 208 часов выглядят весьма неплохо, и тут есть над чем подумать. С одной стороны, я до сих пор не чувствую, что реально что-то знаю в этой области, но за это время я изучил немало новых методов, и лучше понял старые. А после курса от Anrew Ng я наконец-то приобрел общее понимание проблемы машинного обучения. Но больше всего меня радует то, что никто меня не заставляет этим заниматься, а я ботаю, потому что мне это реально нравится, и нравится все больше и больше.

Основными чекпоинтами можно выделить Python и машинное обучение в апреле (18 часов), курс Andrew Ng в октябре (32 часа), Глубокое обучение Николенко в ноябре (19 часов).

Sum:       208.30Mean:      0.57Std:       1.04Min:       0.0Max:       6.0Zero:      254Not zero:  112

Ну сериальчики под чайок это наше все. Можно даже пледик достать на +10 к ламповости. В целом, тут меня ничего не напрягает, и ограничивать себя в просмотре годного кино я не собираюсь. Однако, более полезные занятия точно нужно дотянуть до этих показателей. В апреле опять же самоизоляция и Breaking Bad. А выброс в ноябре связан с пиццей и ночным марафоном по просмотру аниме. И да, по идее, если присмотреться, то ближе к концу года можно найти периодичность, ведь основное время просмотра я стал переносить на выходные.

Sum:       271.24Mean:      0.74Std:       1.25Min:       0.0Max:       9.5Zero:      220Not zero:  146

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

Sum:       192.04Mean:      0.52Std:       0.41Min:       0.0Max:       1.0Zero:      128Not zero:  238

Интересно, смогу ли я продать эти данные маркетологам?

Анализ временных затрат на учебу

Перейдем к главному - данным по учебе. Начну с последнего семестра бакалавриата. Сначала нужно слегка переписать методы вывода. Что значат названия предметов не имеет значения.

def plot_bot(data_frame, start_date, end_date, year, img_name):    descriptions = data_frame.Description.unique()    df = pd.DataFrame(reindex(remove_duplicates(data_frame[data_frame.Description == descriptions[0]]),                              name=descriptions[0],                              start_date=start_date,                              end_date=end_date))    for description in descriptions[1:]:        new = reindex(remove_duplicates(data_frame[data_frame['Description'] == description]),                      name=description,                      start_date=start_date,                       end_date=end_date)        df[description] = new[description].to_numpy()    fig = plt.figure(figsize=(20, 10))    ax = fig.add_subplot(111)    df[descriptions].plot(kind='bar', stacked=True, figsize=(30, 15), ax=ax)        ax.xaxis.set_major_locator(dates.MonthLocator())    ax.xaxis.set_major_formatter(dates.DateFormatter('\n\n\n%b\n'))    ax.tick_params(labelsize=20)    ax.set_xlabel("Месяц " + str(year), fontsize=25)    ax.set_ylabel("Время", fontsize=25)    ax.legend(fontsize=30)    ax.grid(axis='y')        df['Sum'] = df[list(df.columns)].sum(axis=1)    #ax.set_xlim(243, 395) #m1    #ax.set_xlim(45, 181) #m2    #ax.set_xlim(245, 366) #m3    plt.tight_layout()    fig.savefig(img_name, dpi=300)    return ax, df

Картина матплотибом: последний семестр учебы, прокрастинация душит. Вообще, в начале семестра я не так плохо работал, но это потому, что сессия намечалась на апрель. А когда я с ней покончил и остался один на один с дипломом, почему-то решил почти месяц ничего не делать. Как обычно. Причем чем больше задача, тем ближе к дедлайну я буду подбираться в безделии. Когда до сдачи диплома осталось около месяца, я таки взялся за работу, и поработал очень даже неплохо. 212 часов = 116 страниц, или одна страница каждые 1,8 часа. Ладно, по словам и строкам кода считать уже не буду. Ну а вообще, это было очень круто. Почти каждый день я полностью отдавался делу, видел результаты и решал интересную задачу. Правда через пару часов после успешной сдачи я стоял на автобусной остановке и думал над одним вопросом. "И чо?" Помню, с соседом по общаге мы собирались купить пару сигар и с пафосом раскурить их по поводу успешной защиты. Но сигары мы так и не купили, а в тот вечер стояли на балконе и давились дешевым табаком, при этом думая: "И ЧО???" Я долго думал, что дальше, и ничего лучше магистратуры не придумал. Сосед к концу года перебрался в другую страну на хорошую работу, а я остался, и видимо, останусь снова.

Ну а дальше была подготовка к поступлению в магистратуру. 66 часов матана и "Вы зачислены на бла бла бла". Снова посчитаем. Если покрутить формулировки, то получается, что за два года я приобретаю ресурсы, которые стоят 400 тысяч рублей, ведь год обучения стоит 200 тысяч. Переворачиваем схему деньги=ресурсы в ресурсы=деньги и "Маааам, так я работаю, целых 400 000 / 24 = 16 666 рублей в месяц зарабатываю!!!" А ведь еще можно посчитать стипендию! За первые шесть месяцев учебы это 13700. Делим на 66 часов подготовки к поступлению и получаем 208 рублей в час. Очень даже неплохо, ведь на прошлой работе я получал около 236 рублей в час, а долгосрочной пользы от этой работы было чуть меньше чем никакой.

Sum:       390.97Mean:      1.07Std:       2.10Min:       0.0Max:       10.0Zero:      252Not zero:  113DepLoME_sum:  212Math_for_masters:  66b_8_Math_for_masters:     66b_8_DepLoME:              212b_8_GOSI:                 15b_8_AI:                   28b_8_Research work:        25b_8_Basics of designing:  16b_8_VM:                   12b_8_Electronics:          13

Дальше первый семестр магистратуры. Ситуация выглядит получше, ведь работал я стабильнее, хотя ближе к сессии все же есть слабый перегиб. В итоге получается, что чтобы закрыть этот семестр на отлично мне потребовалось 234 часа (практика по B&R не считается). Если пересчитать стипендию, то выходит 96 рублей в час. Негусто, но лишним не будет. Кстати, когда я впервые пересчитывал эти часы, было удивительно, что в итоге нужно было тратить всего 1 час 20 минут в день, чтобы без проблем все сдать. С этого момента я перестал даже думать о нытье по поводу учебы, и совершенно перестал понимать других студентов в этом вопросе.

Sum:       234.95Mean:      0.59Std:       1.40Min:       0.0Max:       12.64Zero:      296Not zero:  99Average per day:  1.22Studying at the university:  62Study at home:  172m_1_GT_MIMR:              34m_1_OMaT:                 13m_1_Practice:             56m_1_AB_ACS:               52m_1_SDoAS:                18m_1_English:              15m_1_IS_MaR:               28

Второй семестр маги. Прокрастинатор возвращается. Идея так распределить время работы явно была плохой, но я справился. А вот нервные клетки все равно не вернуть. Всего на второй семестр ушло 165 часов. Неплохо. Ну и по стипендии. Выходит 152 рубля в час. Сойдет. Кстати забавно, что в университете я провел всего 12 часов. Пандемия, что еще сказать.

Sum:       165.84Mean:      0.45Std:       1.21Min:       0.0Max:       7.97Zero:      301Not zero:  65Average per day:  0.92Studying at the university:  12Study at home:  153m_2_Practice:             29m_2_AIS_MR:               7m_2_HaSCS_IMR:            48m_2_S-LaF_in_CS_IMR:      12m_2_K_Practice:           18m_2_Research work:        40m_2_Course_work:          8

Ну и третий семестр маги. Было потрачено всего 58 часов, а нужно еще часов эдак 120. В общем, январь у меня будет веселым. Люблю наступать на грабли, что поделать.

Sum:       58.60Mean:      0.16Std:       0.58Min:       0.0Max:       4.5Zero:      327Not zero:  39Studying at the university:  15Study at home:  43m_3_Other:                1m_3_ILNT:                 6m_3_C-A DaP S:            0m_3_Research work:        5m_3_ET_in_SR:             24m_3_Course_work:          4

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

Study:        787Development:  492Rest:         650

И еще раз сведу все вместе для 2020 года.

                Time, h  Time, %  Time per dayNan                3910     44.5          10.7Sleep              3224     36.7           8.8Games               344      3.9           0.9Study               295      3.4           0.8Watching films      271      3.1           0.7DS                  208      2.4           0.6Walks               192      2.2           0.5Reading books       152      1.7           0.4English              90      1.0           0.2Japanese             52      0.6           0.1Drawing              46      0.5           0.1

Заключение

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

Вторым открытие для меня стало количество времени, которое я потратил на учебу. В первом семестре мне потребовалось 235 часов, чтобы закрыться на отлично и получать в среднем 96 рублей за потраченный на учебу час. Ребят, мне платили за мое же образование! В течение шести месяцев это 1 час 13 минут в день без выходных, или 2 часа в день с выходными. Что в этом сложного? И больше всего этот вопрос я задавал самому себе. Сложного ничего нет, просто мозг по-другому видит ситуацию. А точнее не видит, попробуй ему объясни, зачем тратить энергию на что-то далекое и не обязательно светлое. На второй семестр потребовалось вообще 165 часов с оплатой в 152 рубля за час. Это 55 минут в день без выходных, или 1 час 22 минуты в день с выходными. Опять же ничего сложного в этом нет.

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

P.S.

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

1) Сколько времени уходит на сбор такой статистики? - Не больше пяти минут в день. Согласитесь, это время можно было потратить намного бесполезнее.

2) Зачем я это делаю и что дальше? - А это хороший вопрос. На самом деле все эти графики появились не из-за того, что год назад я начал интересоваться Data Science. Наоборот, в каком-то смысле я стал интересоваться темой данных еще восемь лет назад, когда открыл блокнот и записал: "Кажется, я чувствую необходимость вести дневник". С тех пор я собрал кучу разных записей, заметок, статистики по временным и денежным затратам и так далее. Например, сейчас у меня имеется 1089 страниц дневниковых записей, которые хотелось бы прогнать через несколько слоев LSTM. Тут должно быть интересно, ведь на 400 тысячах слов уже можно что-то научить. Ну и все остальное можно проанализировать хотя бы ради интереса. Например, в 2020-том я потратил на обновление железа больше половины всех денег, что потратил за год. Может я в итоге покопаюсь во всем этом, а может быть и нет. А вдруг, вдруг эти данные пригодятся для воссоздания моей личности в будущем?! По крайней мере, эти привычки сохранительства приучают меня замечать детали, обдумывать, соотносить и т.п. Хотя, это лишь мое субъективное мнение.

Кстати, кроме удовлетворения собственного интереса такой подход может принести пользу другим людям. Меня всегда очень обнадеживают численные представления объема работы, лучше всего во времени. Хорошим примером может быть чтение книг. Одно дело взять в руки Python и машинное обучение на 420 страниц, а другое дело знать, что у какого-то робототехника на ее изучение ушло 18 часов. Это совсем немного, дерзайте. Аналогичную статистику можно собрать по поводу чего угодно, и кому-то она возможно принесет пользу. Но это потом, всё потом)

P.P.S.

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

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

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

Чтобы понять, как все это мониторить, давайте разберемся кто вообще работает с данными, которые мы с таким трудом намайнили:

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

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

Код - запускается следующий в цепочке пайплайн, происходят преобразования, рисуются графики и т.п.

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

Вот примеры:

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

• Пайплайн стучится в источник с надеждой получить свежие данные, которые появляются в API источника с неопределенной задержкой (привет Apple), пайплан может успешно завершиться как скачав отчет, так и получив сообщение о том, что отчета еще нет. Тут, конечно, можно делать бесконечные ретраи внутри, либо просто ронять пайплайн, но тогда не особо очевидно будет, по какой причине он упал - что-то пошло не так, или данные в источнике еще не подтянулись.

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

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

Чего не хватает во встроенных мониторингах систем работы с данными:

• Бизнес не может просто посмотреть в модный мониторинг типа того же Airflow или ELK и понять, можно или нельзя доверять данным, актуальность состояния данных непрозрачна.

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

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

Все это превращается в такие вот проблемы:

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

2. Люди из бизнеса хотят более наглядного отображения состояния данных и системы, чем оно представлено в технических мониторингах.

3. Статистика, если и собирается, то собирается по техническим проблемам и нельзя понять, насколько эти технические проблемы повлияли на бизнес.

Концепция

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

Почему вообще вебхуки?

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

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

• запустилась ли наша задача 10 раз за последний день?

• не превышает ли количество падений (определяем падение, если полученное значение > 0, например) 15% от всех запусков за сегодня?

• нет ли процессов, которые длятся больше 20 минут?

• не прошло ли больше часа с момента последнего успешного завершения?

• стартовало ли событие по планировщику в нужное время?

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

Реализация

Я начал с дашборда, дизайн - не моя профессия, так что просто взял за основу дашборд, показывающий состояние крон-джобов на сайте Nomadlist, у меня получилось как-то так:

Каждый монитор на этом дашборде - это комбинация метрик, которые должны быть понятны и бизнесу, и инженерам.

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

Для инженера тут все понятно:

• скрипт отрабатывает быстро (еще бы, простая крон-джоба);

• монитор вполне живой, 25 минут назад обновился;

• места еще с запасом (цифра 53 в левом нижнем углу - это последнее принятое значение);

Для людей из бизнеса тут тоже все просто:

• монитор зеленый;

• статус прописан в первой же строчке;

• никакой лишней информации;

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

И насколько просто такое настроить?

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

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

   df -h |grep vda1 | awk  '{ print $5 }'| sed 's/.$//' | xargs -I '{}' curl -G "https://sensorpad.link/<уникальный ID>?value={}" > /dev/null 2>&1
   

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

4. Настраиваем правила, по которым монитор меняет свой статус.

5. Присоединяем каналы для отправки уведомлений.

6. Добавляем монитор на один или несколько дашбордов.

А можно поподробнее?

Для вебхуков я пока что сделал саму простую имплементацию:

• базовый вебхук, который будет нужен для 80% проектов;

• cron-вебхук, который ожидает события в заданное через cron-синтаксис время;

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

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

Дальше создаем тот самый монитор - квадратик, меняющий статус и цвет.

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

Теперь, собственно то, из-за чего я и написал эту балалайку: правила и гибкая логика.

К каждому монитору можно прицепить определенное количество правил, дальше движок мониторинга проверяет все правила раз в пару секунд. Правила проверяются поочередно, как только одно из правил вернет значение True, статус монитора изменится и остальные правила проверяться не будут. Если никакое из правил не сработало, статус монитора примет значение по умолчанию - то самое, которое задавалось при создании монитора.

На скриншоте выше видно уже созданные правила, но я покажу как они создаются.

Например правило, которое можно сформулировать так: "установи статус Warning, если за последний день было больше 5 джоб, которые работали дольше 10 секунд".

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

И какие реальные кейсы можно покрыть этими правилами?

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

• Cron job, Airflow DAG или любой другой процесс не запустился по расписанию;

• 20% задач одного и того же пайплайна за день не отработали как надо;

• связанная задача в пайплайне не запустилась через 2 минуты после окончания родительской задачи;

• интервал между запусками двух задач меньше 1 минуты (похоже, у нас две конкурентные джобы);

• с момента последнего успешного завершения пайплайна прошло 2 часа (а данные должны считаться каждый час);

• время работы пайплайна уже целых 20 минут (а должен был отработать за 5, что-то подвисло).

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

А теперь - статистика!

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

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

Вот такой концепт. Чего не хватает?

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

Потыкайте его вживую, заодно зацените, какой я у мамы дизайнер лендингов: https://sensorpad.io

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

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. Общие характеристики задачи

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

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

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

4. Восприятие. Для восприятия требуется передать модели новые собранные данные для распознавания объектов и их взаимоотношения с более крупными областями вокруг автомобиля. Компоненты этого этапа: локализация (где автомобиль?), контекстуализация (какая вокруг обстановка, возможно с использованием карт высокого разрешения?), распознавание объектов (интеграция данных с лидаров и с других датчиков) и отслеживание объектов (с помощью интеллектуальных моделей).

5. Принятие решения. Решение это подготовка к действию. Что автомобиль должен сделать? Повернуть? Затормозить? Продолжить ехать прямо? Бортовой компьютер автомобиля принимает решения на основе данных с датчиков, обработанных в контексте окружающей обстановки. Модели обучаются с помощью алгоритмов машинного обучения и огромного объема данных, полученных с комплексов автомобильных датчиков. это позволяет создать алгоритмы, способные предсказывать потенциальные события на основе поступающей в реальном времени ситуативной информации. После этого можно применять логические схемы для определения предпочитаемой последовательности действий. Основная цель состоит в составлении стратегии вождения: уклонении от препятствий, планировании поведения, управлении на основе данных GPS, планировании маршрутов, прогнозировании явно незафиксированных событий.

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

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

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

• Модель в контуре управления (MIL). Тестирование модели системы и операционной среды без проведения тестов на оборудовании HAD (часто выполняется на обычных рабочих станциях). Проверка MIL обычно проводится на ранних этапах цикла разработки.

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

• Оборудование в контуре управления (HIL). Тестирование и проверка системного оборудования HAD для выявления всех ошибок в архитектуре оборудования или вызванных используемым компилятором.

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

2. УРОВНИ АВТОНОМНОСТИ

В соответствии с подходом 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 они проходят каждый из уровней.

3. СБОР, ПРЕОБРАЗОВАНИЕ И АНАЛИЗ ДАННХ

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

Поток данных от набора датчиков одного автомобиля составляет в среднем 33 Гбит/с, это примерно 120 ТБ данных за 8-часовую поездку. Технологии еще находятся на этапе разработки, поэтому в силу действующих правовых норм потребуется хранить весь объем данных с автономных автомобилей. Однодневный тест-драйв парка из 80 автомобилей это около 10 ПБ исходных данных. Следовательно, небольшой парк автомобилей будет генерировать от 100 до 500 ПБ данных в день.

3.1. Основные принципы

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

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

Существуют инструменты для построения конвейеров непрерывной интеграции/непрерывной разработки (CI/CD), предоставляющие возможность гибкого и эффективного тестирования и разработки алгоритмов.

4. ПОИСК КОМПЛЕКСНОГО РЕШЕНИЯ HAD

Для систем 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 (четыре дорожки).

5. УСЛУГИ И РЕШЕНИЯ ПАРТНЕРОВ

Корпорация 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 в содружестве с другими разработчиками. Каждый партнер привносит собственные услуги в экосистему и обеспечивает всестороннее обслуживание клиента.

6. ЗАКЛЮЧЕНИЕ

В дорожно-транспортных происшествиях во всем мире ежегодно гибнет около 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 для надежных и безопасных транспортных сетей будущего.