Eda

Анализ данных и базоваямодель

Вступление

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

Информация для конкурса была получена Министерством водных ресурсов Танзании с использованием платформы с открытым исходным кодом под названием Taarifa. Танзаниясамая большая страна в Восточной Африке с населением около 60 миллионов человек. Половина населения не имеет доступа к чистой воде, а 2/3 населения страдает от плохой санитарии. В бедных домах семьям часто приходится тратить несколько часов пешком, чтобы набрать воду из водяных насосов.

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

Данные

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

Пункты водоснабжения разделены на исправные, нефункциональные и исправные, но нуждающиеся в ремонте. Цель конкурсапостроить модель, прогнозирующую функциональность точек водоснабжения.
Данные содержат 59400 строк и 40 столбцов. Целевая метка содержится в отдельном файле.
Показатель, используемый для этого соревнования,это classification rate, который вычисляет процент строк, в которых прогнозируемый класс совпадает с фактическим классом в тестовом наборе. Максимальное значение равно 1, а минимальное0. Цель состоит в том, чтобы максимизировать classification rate.

Анализ данных

Описания полей в таблице с данными:

• amount_tshобщий статический напор (количество воды, доступное для точки водоснабжения)

• date_recordedдата сбора данных

• funderкто спонсировал постройку колодца

• gps_heightвысота на которой находится колодец

• installerорганизация построившая колодец

• longitudeGPS координаты (долгота)

• latitudeGPS координаты (широта)

• wpt_nameназвание, если оно есть

• num_privateнет информации

• basinгеографический водный бассейн

• subvillageгеографическая локация

• regionгеографическая локация

• region_codeгеографическая локация (код)

• district_code географическая локация (код)

• lgaгеографическая локация

• ward географическая локация

• populationколичество населения около колодца

• public_meetingда/нет

• recorded_by кто собрал данные

• scheme_managementкто управляет колодцем

• scheme_nameкто управляет колодцем

• permitтребуется ли разрешение на доступ

• construction_yearгод постройки

• extraction_typeтип колодца

• extraction_type_groupгруппа типа колодца

• extraction_type_classкласс типа колодца

• managementкак управляется колодец

• management_groupгруппа управления колодца

• paymentстоимость воды

• payment_typeтип стоимости воды

• water_qualityкачество воды

• quality_groupгруппа качества воды

• quantityколичество воды

• quantity_groupгруппа количества воды

• sourceисточник воды

• source_typeтип источника воды

• source_classкласс источника воды

• waterpoint_typeтип колодца

• waterpoint_type_groupгруппа типа колодца

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

  

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

  • уменьшать количество примеров у преобладающих классов(under-sampling)

  • дублировать строки с метками, которых мало(over-sampling)

  • генерировать синтетические выборкиэто случайная выборка атрибутов из экземпляров в классе меньшинства (SMOTE)

  • ничего не делать и использовать возможности библиотек, которые выбраны для моделирования

  Больше про тактики работы с несбалансированными датасетами можно почитать здесь.

  Посмотрим, как водяные насосы распределяются по территории страны.

  

  Некоторые данные содержат пустые значения.

  

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

  Следующая тепловая карта представляет наличие/отсутствие связи между переменными. Стоит обратить внимание на соотношение между permit, installer и funder.

  

  Давайте посмотрим на общую картину взаимоотношений на дендрограмме.

  

  В характеристиках водяных насосов есть та, которая показывает количество воды. Мы можем проверить, как количество воды связано с состоянием насосов (quantity_group).

  

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

  Влияет ли качество воды на состояние водяных насосов? Мы можем посмотреть на данные, сгруппированные по quality_group.

  

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

  

  Большинство колодцев с неизвестным качеством из quality_group не работают.

  Есть еще одна интересная характеристика водных точеких тип (waterpoint_type_group).

  

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

  

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

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

  

  Danidaсовместная организация Танзании и Дании по финансированию скважин, и хотя у них много работающих водозаборов, процент неисправных очень высок. Похожая ситуация с RWSSP (программа сельского водоснабжения и канализации), Dhv и некоторыми другими. Следует отметить, что большинство скважин, профинансированных Германией и частными лицами, находятся в рабочем состоянии. Напротив, большое количество скважин, которые финансируются государством, не функционируют. Большинство пунктов водоснабжения, установленных центральным правительством и районным советом, также не работают.

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

  

  Сильно выделяются два бассейнаРувим и озеро Руква. Количество сломанных колодцев там больше всего.

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

  

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

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

  

  Часть данных была заполнена значением 0 вместо реальных данных. Мы также можем видеть, что amount_tsh выше у исправных колодцев (label = 0). Также следует обратить внимание на выбросы в функции amount_tsh. В качестве особенности можно отметить перепад высот и тот факт, что значительная часть населения проживает на высоте 500 метров над средним уровнем моря.

Подготовка данных

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

• Фича installer содержит множество повторов с разными регистрами, орфографическими ошибками и сокращениями. Давайте сначала переведем все в нижний регистр. Затем по простым правилам уменьшаем количество ошибок и делаем группировку.

• После очистки мы заменяем все элементы, которые встречаются менее 71 раз (0,95 квантиля), на other.

• Повторяем по аналогии с фичей funder. Порог отсечки98.

• Данные содержат фичи с очень похожими категориями. Выберем только по одной из них. Поскольку в датасете не так много данных, мы оставляем функцию с наименьшим набором категорий. Удаляем следующие фичи: scheme_management, quantity_group, water_quality, payment_type, extraction_type, waterpoint_type_group, region_code.

• Заменим latitude и longitude значения у выбросов медианным значением для соответсвующего региона из region_code.

• Аналогично повторям для пропущенных значений для subvillage и scheme_name.

• Пропущенные значения в public_meeting и permit заменяем медианным значением.

• Для subvillage, public_meeting, scheme_name, permit, создаем дополнительные категориальные бинарные фичи, которы будут отмечать данные с пропущенными значениями. Так как мы заменяем их на медианные, то для модели оставим информацию, что пропуски были.

• Фичи scheme_management, quantity_group, water_quality, region_code, payment_type, extraction_type, waterpoint_type_group, date_recorded, и recorded_by можно удалить, так как там повторяются данные из других фичей, для модели они будут бесполезны.

Модель

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

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

def fit_model(train_pool, test_pool, **kwargs):    model = CatBoostClassifier(        max_ctr_complexity=5,        task_type='CPU',        iterations=10000,        eval_metric='AUC',        od_type='Iter',        od_wait=500,        **kwargs    )return model.fit(        train_pool,        eval_set=test_pool,        verbose=1000,        plot=False,        use_best_model=True)

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

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

def classification_rate(y, y_pred):    return np.sum(y==y_pred)/len(y)

Поскольку данных мало, разбивать полную выборку на обучающую и проверочную частине лучший вариант. В этом случае лучше использовать методику OOF (Out-of-Fold). Мы не будем использовать сторонние библиотеки; давайте попробуем написать простую функцию. Обратите внимание, что разбиение набора данных на фолды необходимо стратифицировать.

def get_oof(n_folds, x_train, y, x_test, cat_features, seeds):    ntrain = x_train.shape[0]    ntest = x_test.shape[0]              oof_train = np.zeros((len(seeds), ntrain, 3))    oof_test = np.zeros((ntest, 3))    oof_test_skf = np.empty((len(seeds), n_folds, ntest, 3))    test_pool = Pool(data=x_test, cat_features=cat_features)     models = {}    for iseed, seed in enumerate(seeds):        kf = StratifiedKFold(            n_splits=n_folds,            shuffle=True,            random_state=seed)                  for i, (train_index, test_index) in enumerate(kf.split(x_train, y)):            print(f'\nSeed {seed}, Fold {i}')            x_tr = x_train.iloc[train_index, :]            y_tr = y[train_index]            x_te = x_train.iloc[test_index, :]            y_te = y[test_index]            train_pool = Pool(data=x_tr, label=y_tr, cat_features=cat_features)            valid_pool = Pool(data=x_te, label=y_te, cat_features=cat_features)model = fit_model(                train_pool, valid_pool,                loss_function='MultiClass',                random_seed=seed            )            oof_train[iseed, test_index, :] = model.predict_proba(x_te)            oof_test_skf[iseed, i, :, :] = model.predict_proba(x_test)            models[(seed, i)] = modeloof_test[:, :] = oof_test_skf.mean(axis=1).mean(axis=0)    oof_train = oof_train.mean(axis=0)    return oof_train, oof_test, models

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

Кривая обучения одного изфолдов

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

Посмотрев на важность фичей в модели, мы можем убедиться в отсутствии явной утечки информации (лика).

После усреднения прогнозов:

balanced accuracy: 0.6703822994494413classification rate: 0.8198316498316498

Попробуем загрузить результаты на сайт с конкурсом и посмотрим на результат.

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

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

balanced accuracy: 0.6549535670689709classification rate: 0.8108249158249158

Результат заметно хуже.

Итоги

В статье:

• познакомились с данными и поискали идеи для модели;

• очистили и подготовили данные для модели;

• приняли решение использовать CatBoost, так как основная масса фичей категориальные;

• написали функцию для OOF-предсказания;

• получили отличный результат для базовой модели.

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

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

Код из статьи можно посмотреть здесь.

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

---

PyForest

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

Вот почему PyForest это одна из самых удобных библиотек, которые я знаю. С её помощью в ваш блокнот Jupyter можно импортировать более 40 популярнейших библиотек (Pandas, Matplotlib, Seaborn, Tensorflow, Sklearn, NLTK, XGBoost, Plotly, Keras, Numpy и другие) при помощи всего одной строки кода.

Выполните pip install pyforest. Для импорта библиотек в ваш блокнот введите команду from pyforest import *, и можно начинать. Чтобы узнать, какие библиотеки импортированы, выполните lazy_imports().

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

Emot

Эта библиотека может повысить качество вашего проекта по обработке естественного языка. Она преобразует эмотиконы в их описание. Представьте, например, что кто-то оставил в Твиттере сообщение I [здесь в оригинале эмодзи "красное сердце", новый редактор Хабра вырезает его] Python. Человек не написал слово люблю, вместо него вставив эмодзи. Если твит задействован в проекте, придётся удалить эмодзи, а значит, потерять часть информации.

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

Чтобы установить Emot, выполните команду pip install emot, а затем командой import emot импортируйте её в свой блокнот. Нужно решить, с чем вы хотите работать, то есть с эмотиконами или с эмодзи. В случае эмодзи код будет таким: emot.emoji(your_text). Посмотрим на emot в деле.

Выше видно предложение I [эмодзи "красное сердце"] Python, обёрнутое в метод Emot, чтобы разобраться со значениями. Код выводит словарь со значением, описанием и расположением символов. Как всегда, из словаря можно получить слайс и сосредоточиться на необходимой информации, например, если я напишу ans['mean'], вернётся только описание эмодзи.

Geemap

Говоря коротко, с её помощью можно интерактивно отображать данные Google Earth Engine. Наверное, вы знакомы с Google Earth Engine и всей его мощью, так почему не задействовать его в вашем проекте? За следующие несколько недель я хочу создать проект, раскрывающий всю функциональность пакета geemap, а ниже расскажу, как можно начать с ним работать.

Установите geemap командой pip install geemap из терминала, затем импортируйте в блокнот командой import geemap. Для демонстрации я создам интерактивную карту на основе folium:

import geemap.eefolium as geemapMap = geemap.Map(center=[40,-100], zoom=4)Map

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

Dabl

Позвольте мне рассказать об основах. Dabl создан, чтобы упростить работу с моделями ML для новичков. Чтобы установить её, выполните pip install dabl, импортируйте пакет командой import dabl и можно начинать. Выполните также строчку dabl.clean(data), чтобы получить информацию о признаках, например о том, есть ли какие-то бесполезные признаки. Она также показывает непрерывные, категориальные признаки и признаки с высокой кардинальностью.

Чтобы визуализировать конкретный признак, можно выполнить dabl.plot(data).

Наконец, одной строчкой кода вы можете создать несколько моделей вот так: dabl.AnyClassifier, или так: dabl.Simplefier(), как это делается в scikit-learn. Но на этом шаге придётся предпринять некоторые обычные шаги, такие как создание тренировочного и тестового набора данных, вызов, обучение модели и вывод её прогноза.

# Setting X and y variablesX, y = load_digits(return_X_y=True)# Splitting the dataset into train and test setsX_train, X_test, y_train, y_test = train_test_split(X, y, random_state=1)# Calling the modelsc = dabl.SimpleClassifier().fit(X_train, y_train)# Evaluating accuracy scoreprint(Accuracy score, sc.score(X_test, y_test))

Как видите, Dabl итеративно проходит через множество моделей, включая Dummy Classifier (фиктивный классификатор), GaussianNB (гауссовский наивный Байес), деревья решений различной глубины и логистическую регрессию. В конце библиотека показывает лучшую модель. Все модели отрабатывают примерно за 10 секунд. Круто, правда? Я решил протестировать последнюю модель при помощи scikit-learn, чтобы больше доверять результату:

Я получил точность 0,968 с обычным подходом к прогнозированию и 0,971 с помощью Dabl. Для меня это достаточно близко! Обратите внимание, что я не импортировал модель логистической регрессии из scikit-learn, поскольку это уже сделано через PyForest. Должен признаться, что предпочитаю LazyPredict, но Dabl стоит попробовать.

SweetViz

Это low-code библиотека, которая генерирует прекрасные визуализации, чтобы вывести ваш исследовательский анализ данных на новый уровень при помощи всего двух строк кода. Вывод библиотеки интерактивный файл HTML. Давайте посмотрим на неё в общем и целом. Установить её можно так: pip install sweetviz, а импортировать в блокнот строкой import sweetviz as sv. И вот пример кода:

my_report = sv.analyze(dataframe)my_report.show_html()

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

Заключение

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

Этот материал не только даёт представление о полезных пакетах экосистемы Python, но и напоминает о широте и разнообразии проектов, в которых можно работать на этом языке. Python предельно лаконичен, он позволяет экономить время и в процессе написания кода, выражать идеи максимально быстро и эффективно, то есть беречь силы, чтобы придумывать новые подходы и решения задач, в том числе в области искусственного интеллекта, получить широкое и глубокое представление о котором вы можете на нашем курсе "Machine Learning и Deep Learning".

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Другие профессии и курсы

Source: W. Playfair.

Привет, Хабр! Меня зовут Илья Селицер. В DINS мы участвуем в разработке продукта для UCaaS-провайдера RingCentral, который объединяет много функций от звонков и факса до корпоративного мессенджера и видеоконференций. Я, среди прочего, отвечаю за качество этого сервиса. В повседневной практике мне постоянно приходится анализировать взаимодействие различных сетевых элементов, которые участвуют в предоставлении той или иной услуги абонентам.

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

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

---

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

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

Рассмотрим пример: UCaaS-провайдер предоставляет некоторую услугу S (например, прием факсовых, мультимедийных и прочих сообщений, голосовую почту, запись аудио- или видеозвонка) бизнес-абонентам в нескольких регионах R_i. Процесс предоставления S имеет следующие особенности:

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

• Информация о количестве фактов успешного предоставления S для каждого R_i достоверна.

• Сетевые элементы NE_ij, непосредственно участвующие в предоставлении S, генерируют отчёты об ошибках ER_j, т.е. о фактах неуспешного предоставления S (SE). Эта информация может быть недостоверной в силу разных причин, таких как ошибки в алгоритме подсчета ошибок, проблемы на уровне ОС, аппаратные проблемы и.т.д.

• Отчёт об ошибках по региону SER_i формируется для каждого R_i путем суммирования ER_j по отчетам от каждого NE_ij.

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

• Результаты оценки достоверно. Не делаем ничего, т.е. не тратим ресурсы на дальнейший анализ. Оцениваем качество услуги на основе SER_i и количества жалоб на качество услуги со стороны абонентов.

• Результаты оценки недостоверно. Изменяем механизм формирования ER_j. Это весьма ресурсоемкая задача, так как потребуется не только дополнительный анализ сценариев взаимодействия, но, возможно, доработка сетевых элементов и даже изменение архитектуры предоставления S.

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

1. Потребление S растёт со временем. Это обусловлено, например, ростом абонентской базы и/или растущим спросом на S.

2. Количество запросов на предоставление S изменяется с некоторой периодичностью, характерной для бизнес-пользователей, например, рабочие дни-выходные.

3. Количество SE растет с ростом потребления, т.е. количества фактов успешного оказания услуги, например, из-за перегрузки сетевых элементов.

4. Количество SE растет с ростом среднего объёма F_k. Например, количество ошибок при приёме факсового сообщения вырастет с ростом размера принимаемых факсовых сообщений (и, соответственно, объёма файлов F_k): приём 10-страничного факса потребует больше времени, чем 1-страничного, вероятность возникновения ошибки при приёме увеличивается с ростом времени приёма при прочих равных условиях. Следовательно, число ошибок при приёме большого количества 10-страничных факсов будет больше, чем при приёме такого же количества 1-страничных.

Исходя из утверждений 1-4, а также учитывая, что зависимости SS и SE от времени суть временные ряды (time series, TS), используем следующие возможные результаты анализа TS SE (TSE), по которым будем определять степень достоверности информации, предоставляемой отчётами об ошибках:

• TSE стационарен, т.е. не имеет сезонности и тренда.

• TSE нестационарен, т.е. демонстрирует сезонность (seasonality) и тренд (trend) это и будет принято в качестве критерия достоверности данных, предоставляемый TSE.

Нестационарный TS может и не иметь тренда, один из примеров случайное блуждание (random walk, RW), хотя этот факт применительно к RW, в некоторых случаях, подлежит обсуждению.
В качестве инструментов анализа будем использовать различные методы тестирования стационарности TS, а также оценку автокорреляции TS (ACF). Используем TSS и TSE для одного из регионов, полученные на реальной сети UCaaS-провайдера. Для анализа используем Python и соответствующие статистические и графические библиотеки. Код доступен здесь, для просмотра кода и графиков можно использовать nbviewer.

TSS

Сначала проанализируем TSS. Построим графики TSS и декомпозиции TSS, коррелограмму рис. 1-3. Для декомпозиции использованы следующие значения параметров:

• model = multiplicative. Мы рассматриваем TSS как произведение трёх компонент: тренда, сезонных колебаний и случайной величины (остаток, residuals) [1]. На мультипликативную модель указывает, например, возрастающий со временем размах сезонных колебаний.

• period = 7 (period = None даст тот же результат).

Рис. 1. TSS Рис. 2. Декомпозиция TSSРис. 3. Коррелограмма TSS

Анализ графиков на рис. 1-3 приводит к следующим выводам:

• Сезонность чётко различима и равна 7 дням (рис.1).

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

• Величина автокорреляции уменьшается с ростом лага. Это обусловлено трендом, тогда как форма, напоминающая затухающую синусоиду, это следствие сезонности. В нашем случае корреляция между значениями TSS в момент t максимальна в момент t n*7 дней, n = 1 5. Закрашенная область на рис. 3 это доверительный интервал (confidence interval, CI) для ACF. Значения ACF, попадающие за пределы этой области, статистически значимы.

Наличие сезонности и тренда говорит о нестационарности TSS [1]. Проверим TSS на стационарность с помощью ADF-теста (Augmented Dickey-Fuller). ADF-тест в качестве нулевой гипотезы (H₀) постулирует наличие единичного корня [2, 3], что указывает на нестационарность TS. При этом отсутствие единичного корня не говорит о стационарности TS. Получаем следующие результаты:

p-value > 0.05, результат не является статистически значимым, H₀ не может быть отвергнута.
Как и предполагалось до начала анализа, TSS нестационарен, что подтверждается собственно графиком процесса, результатами декомпозиции, коррелограммой, ADF-тестом.

Объём Fk

Как указано выше, размер сообщений пропорционален объёму F_k. Оценим, как меняются значения Fk со временем. Гистограмма с линейным масштабом F_k см. рис. 4, с логарифмическим масштабом см. рис. 5, коробчатая диаграмма (box plot) см. рис. 6.

Рис. 4. Гистограмма Fk, линейный масштабРис. 5. Гистограмма Fk, логарифмический масштаб

Некоторые выводы по рис. 4, 5:

• Распределение несимметрично, присутствует правый хвост (right-skewed).

• Среди значений объёма F_k присутствуют экстремальные значения/выбросы (outliers).

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

Рис. 6. Коробчатая диаграмма Fk

Коробчатая диаграмма на риc. 6 показывает, что:

• Количество экстремальных значений F_k > 55 заметно уменьшилось;

• Медиана несколько выросла, несмотря на колебания от месяца к месяцу;

• Характер распределения F_k примерно одинаков от месяца к месяцу. Средние, медианные и максимальные значения F_k по месяцам:

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

Информация, представленная в виде графиков на рис. 1-6, в значительной степени совпадает с предположениями 1-4.

TSE

Построим TSE и попытаемся обнаружить и оценить особенности этого графика.

Рис. 7. TSE

График на рис. 7 не показывает явно выраженную сезонность, также присутствуют нулевые значения SE.

Проведём декомпозицию TSE см. рис. 8. Параметр model=additive т.к. в TSE присутствуют нулевые значения, period = None.

Рис. 8. Декомпозиция TSE

Декомпозиция TSE указывает на сезонность с периодом 7 дней, а также на отсутствие выраженного тренда.

Рис. 9. Коррелограмма TSE

Коррелограмма на рис. 9 также не показывает сезонность, как в случае TSS: всего два значения статистически значимы, остальные значения статистически незначимы. В то время как декомпозиция TSE указывает на наличие сезонности TSE с периодом 7 дней, коррелограмма TSE не показывает заметной автокорреляции с лагом, кратным 7 (рис. 9). Тот факт, что используемый для данного случая алгоритм декомпозиции обнаружил сезонную компоненту, не означает, что сезонность присутствует или существенно определяет свойства TSE: даже для RW этот алгоритм декомпозиции обнаруживает сезонную компоненту. В этом случае необходимо использовать другие доступные методы оценки стационарности TSE.

ADF-тест даёт следующие результаты:

Значение p-value << 0.05, результат статистически значим, принимаем альтернативную гипотезу (H₁): TSE стационарен. Для более надежной проверки, в дополнение к ADF-тесту используем KPSS-тест (Kwiatkowski-Phillips-Schmidt-Shin). В отличие от ADF-теста, KPSS-тест постулирует в качестве H₀ стационарность процесса, а в качестве H₁ наличие единичного корня. ADF- и KPSS-тестам свойственны некоторые недостатки, например, высокий уровень ошибок первого рода (ошибочное отвержение H₀), однако совместное применение ADF- и KPSS-тестов позволит уменьшить влияние этих недостатков на результаты анализа TSE [3].
KPSS-тест даёт следующие результаты:

Здесь p-value > 0.05, т.е. не является статистически значимым, принимаем H₀: TSE стационарен.

Приходим к следующим выводам:

1. На основании анализа коррелограммы TSE, а также ADF- и KPSS-тестов, считаем, что TSE стационарен.

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

3. Механизм формирования отчётов об ошибках нуждается в более детальном исследовании и последующей корректировке.

Заключение

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

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

Литература

1. Athanasopoulos, G., Hyndman, R. J. Forecasting: principles and practice, 2nd edition.

2. Brockwell, P. J., Davis, R. A. (2016). Introduction to Time Series and Forecasting, 3rd edition. Springer Texts in Statistics

3. Pal, A., Prakash, PKS (2017). Practical Time Series Analysis, Packt Publishing Ltd.

Применяемая, в настоящее время, для проектирования СБИС, методология с использованием языков описания аппаратуры, обладает общепризнанными недостатками, а именно:

• Разработка сложных СБИС требует сотни квалифицированных инженеров, несколько лет работы и затрат в миллиарды долларов.

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

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

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

Программы DARPA

В рамках программы Electronics Resurgence Initiative, объявленной DARPA, поставлена задача преодолеть проблемы применяемой методологии проектирования микропроцессорных систем. С этой целью реализуется следующие подпрограммы:

• CRAFT предполагает создание средств высокоуровневого синтеза СБИС;

• IDEA направлена на создание автоматического генератора компоновки SoC, многокристальных микросхем, печатных плат;

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

В случае успешного выполнения указанных программ полученные результаты должны быть объединены в перспективных САПР. Предполагается достичь 10 кратного роста в скорости разработки над ручным созданием RTL кода. Кроме того, ставится цель принципиально изменить практику разработки микропроцессорных устройств. Итоговая цель преобразования инженерной практики описана так:

• Разработка СБИС становится частью инструментария разработчика программного обеспечения.

• Каждая компания разработчик ПО, получает возможность разрабатывать СБИС.

Описывая ситуацию в отрасли разработки микропроцессорных систем, DARPA говорит о следующих проблемах (на основе Electronics Resurgence Initiative Page 3 Investments Design Thrust). Интеллектуальные системы следующего поколения, в областях искусственного интеллекта, автономных транспортных средств, связи, радиоэлектронной борьбы и радиолокации, потребуют на порядок большей эффективности обработки, чем та, которую предлагает современная коммерческая электроника. Достижение требуемых уровней производительности, потребует разработки очень сложных платформ SoC, использующих самые передовые технологии интегральных схем. В последние годы сложность микросхем быстро росла, произошел взрыв затрат и времени, необходимых для разработки усовершенствованных SoC, печатных плат и многокристальных сборок (SiP). Предлагаемая инициатива создаст новые парадигмы для интеллектуального физического проектирования и уменьшит барьеры для проектирования высокопроизводительных, высокоэффективных специализированных интегральных схем.

Исследовательский подход в программе CRAFT (из доклада Khailany Brucek CRAFT Final на ERI Summit 2019):

1. Поднять уровень абстракции при разработке аппаратуры:

   a. Использовать языки более высокого уровня, например, C ++ вместо Verilog;

   b. Использовать инструменты высокоуровневого синтеза;

   c. Использовать библиотеки и генераторы, например, MatchLib.

2. Применение методологии AGILE в разработке СБИС:

   a. Небольшие команды, совместно работая над архитектурой, реализацией, VLSI (Very Large Scale Integration);

   b. Непрерывная интеграция и средства автоматической верификации;

   c. AGILE методы управления проектами;

   d. Круглосуточная генерация из С++ в схему.

Предложен высоко продуктивный подход к разработке цифровых СБИС для создания сложных SoC. Маршрут проектирования включает средства высокоуровневого синтеза, объектно-ориентированные библиотеки синтезируемых компонентов на языках SystemC и С++. И модульный подход к физическому проектированию СБИС основанный на мелкозернистом глобально асинхронном и локально синхронном (GALS) тактировании. Методология проектирования была продемонстрирована на 16-нм тестовом чипе FinFET, предназначенном для машинного обучения и компьютерного зрения. (A Modular Digital VLSI Flow for High-Productivity SoC Design, Khailany et al., DAC 2018)

Spoiler

Рисунок 1. Вариант маршрута проектирования предложенный для программы CRAFT [1].

Программа IDEA состоит из двух этапов. На первом этапе будет создан генератор макетов, для создания автоматизированной платформы проектирования печатных плат, SoC и SiP. На втором этапе должна быть создана программная система, которая на основе функционального описание высокого уровня и заданных ограничений, будет создавать печатные платы и микросхемы правильной конструкции на основе обширной библиотеки коммерческих компонентов (COTS). Примеры компонентов COTS включают в себя коммерчески доступные микросхемы для печатных плат, кристаллы для SiP и IP-модули для SoC. Созданный список цепей, будет поступать на вход генератора макетов, разработанного в первой части программы. Таким образом будет создана сквозная автоматизированная платформа проектирования для печатных плат, SoC и SiP.

Spoiler

Рисунок 2. Схема применение искусственного интеллекта для решения задачи проектирования СБИС, по замыслу программы IDEA [5].

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

Spoiler

Рисунок 3. Концепция маршрута проектирования программы IDEA [5].

В программе POSH предлагается использовать практику разработки ПО с открытым кодом, в области разработки микропроцессорных систем. В документах DARPA говорится следующее. Появление экосистемы программного обеспечения с открытым исходным кодом позволило создать глубокую иерархию программного обеспечения со многими уровнями абстракции, что значительно повысило производительность в проектах разработки сложных программных систем. Модель абстрагирования программного обеспечения позволяет программисту сосредоточить свои усилия в одной конкретной области, игнорируя при этом большое количество деталей, которые в противном случае были бы слишком сложными для обработки. Чтобы создать устойчивую экосистему разработки аппаратуры с открытым исходным кодом, программа POSH создаст технологии, методы и стандарты для эффективной разработки SoC с открытым исходным кодом. Предполагается, что критически важным компонентом этих усилий станет разработка технологий проверки, обеспечивающих доверие к строительным блокам (IP блокам) аппаратного обеспечения с открытым исходным кодом.

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

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

Spoiler

Рисунок 4. Экосистема с открытым исходным кодом для разработки SoC по замыслу программы POSH [4].

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

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

Промежуточные результаты программ, представленные на ERI Summit 2019, подтверждают возможность достижения заявленной цели.

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

• Снижение трудоёмкости в 8-11 раз для аналоговых и цифровых интегральных схем.

• Сокращение трудоёмкости в 4.3-5.3 раза при переносе на технологию 16-нм GF, продемонстрированное на цифровых и цифро-аналоговых ASIC.

Однако существует ряд проблем:

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

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

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

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

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

• При разработке аппаратуры поднять уровень абстракции на котором человек описывает проектируемую систему. Все ниже лежащие уровни абстракции передать автоматическим средствам.

• Минимизировать участие человека в решении задачи проектирования, за счёт применения средств искусственного интеллекта.

• Создать условия для повторного использования качественных строительных блоков аппаратного обеспечения.

Парадигма проектирования остаётся прежней использование языков программирования для описания проектируемой аппаратуры.

Описанные программы опираются на базу существующих решений, готовые к использованию компоненты COTS, IP блоки, программные средства с открытым исходным кодом. Однако, опираясь только на готовые компоненты невозможно достичь высшей производительности или минимального энергопотребления. Разработка новых архитектур, максимально сложных SoC и SiP с использованием новых технологий производства, для этих задач остаётся всё та же методология проектирования, которая критикуется в программах DARPA.

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

В декабре 2019 года компания NVIDIA представила перспективную платформу для самоуправляемых автомашин и роботов [6]. Анонсированный процессор NVIDIA Orin появится не ранее 2022 год. Для обеспечения пятого уровня автономности самоуправляемого автомобиля, потребуется сочетать пару процессоров Orin и два не названных, перспективных, дискретных графических процессора NVIDIA [32]. Уровень быстродействия в этом случае составит до 2000 триллионов операций в секунду, при энергопотреблении до 750 Вт.

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

Другим примером могут служить современные программы создания суперкомпьютеров максимальной производительности, которые реализуют Евросоюз, США, Китай, Япония и другие страны. Эти программы, в частности, реализуемые DARPA и DOE, фокусируются на решении следующих задач [25]:

• Существенный рост производительности при умеренном энергопотреблении;

• Повышение надежности аппаратуры и программ;

• Рост продуктивности программирования.

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

Например, суперкомпьютер Neocortex, создаётся для задач классов DCIGN и RNN это более точное прогнозирование погоды, анализ геномов, поиск новых материалов и разработка новых лекарств. Предположительно, будет введено в эксплуатацию до конца 2020 года [37]. Он объединяет серверы Cerebras CS-1 и HPE SuperDome Flex в единую систему с общей памятью. Сервер Cerebras CS-1 основан на уникальном процессоре Cerebras. На изготовление одного процессора уходит целая 300-мм пластина [2].

Основой для роста сложности микропроцессорных систем, в ближайшем будущем, станет развитие технологии 3D TSV. Например, концепция, предложенная IBM [16], к настоящему моменту, изготовление микроканалов продемонстрировано в кремнии [22].

Spoiler

Рисунок 5. Концепция построения перспективных микропроцессорных систем предложенная IBM [16].

Краткая характеристика современной методологии, ключевые проблемы

К настоящему времени в проектировании сложных микропроцессорных систем сложилась практика, представленная на рисунке 6, в изложении Brucek Khailany (Director of research, ASIC & VLSI NVIDIA Corporation).

Spoiler

Рисунок 6. Использование языков программирования в проектировании СБИС [1].

В процессе проектирования используются различные языки программирования, как специализированные, в частности языки описания аппаратуры (HDL), так и языки высокого уровня общего назначения.

Создаваемое изделие описывается в виде программы на языке описания аппаратуры (HDL). Созданная программа, обычно, представляет собой модель уровня регистровых передач (RTL), которая должна быть преобразована в логическую схему посредством автоматического синтеза (Logic Synthesis). Далее созданную схему необходимо превратить в описание физического изделия. Для чего выполняется последовательность этапов проектирования, которую принято называть физическое проектирование (physical design).

Упрощённая схема маршрута проектирования СБИС, с выделением этапов физического проектирования, представлена на рис. 7.

Spoiler

Рисунок 7. Типовой маршрут проектирования с выделением этапов физического проектирования СБИС [23].

Здесь важно отметить, что инженерная задача разработки вычислительной системы (SiP) разделена на две задачи с разным понятийным аппаратом. Для логического проектирования - математический понятийный аппарат, а для физического проектирования - понятийный аппарат описывающий физические процессы.

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

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

Взаимосвязи понятий отрасли, в виде распространения задаваемых ограничений, на возможные варианты инженерных решений, показаны на рис. 8.

Spoiler

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

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

Трудоёмкость проектирования, например, для NVIDIA Xavier оценивается в 8000 человеко-лет [1].

По слова Jensen Huang, на создание NVIDIA V100 потребовалось несколько тысяч инженеров, ушло несколько лет, при примерной стоимости разработки в 3 миллиарда долларов [7].

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

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

Spoiler

Рисунок 9. Стоимость разработки СБИС в зависимости от их сложности [7].

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

Мышление человека в инженерной практике

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любая работа ума создаёт умственную нагрузку, которая постепенно утомляет нервную систему, что снижает концентрацию и повышает вероятность ошибки. Умственная нагрузка, при решении одной и той же задачи, может различаться в зависимости от условий в которых человек должен эту задачу решать. Например, слепая игра в шахматы (не глядя на доску) или решение ханойской головоломки в уме (без физического перемещения дисков) создают большую умственную нагрузку, чем те же задачи находящиеся в поле зрения [10, 12].

Мышление в процессе решения задачи проектирования представляет собой последовательность интеллектуальных действий.

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

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

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

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

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

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

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

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

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

Дополнительная умственная нагрузка определяется особенностями методологии и реализующих её инструментов (т.е. САПР и др.). Например, необходимость учитывать, в процессе проектирования, понятия отрасли, которые в методологии отсутствуют, создаёт дополнительную умственную нагрузку и повышает вероятность ошибок.

Связь между формой представления понятий и скоростью восприятия понятий (условий задачи), установлена экспериментально. Следствием этого стало введение терминов образный интерфейс, когнитивная графика, экологический интерфейс. Создание таких интерфейсов внедрено в инженерной практике, прежде всего в операторской работе по управлению сложными промышленными объектами [29].

В некоторых отраслях исторически сложилось и внедрено в САПР введение процесса решения в поле зрения, что упрощает восприятие понятий (т.е. процессов и взаимосвязей) и поиск решения.

В качестве примера можно привести отрасль авиастроения. Для примера рассмотрим, выполненный не профессионалом, проект тяжёлого конвертоплана созданный в САПР T-FLEX CAD 16 (см. рис. 10). Проект состоящий из более чем 60000 тел был создан одним инженером, исключительно на основе информации из открытых источников и собственного опыта проектирования. На исследование предметной области ушло около 2-х месяцев и ещё примерно 6 месяцев периодической работы на реальное проектирование [31].

Spoiler

Рисунок 10. Проект летательного аппарата в САПР T-FLEX CAD 16.

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

Описание решения ведётся в визуальной среде, где объекты прямо соответствуют понятиям в которых человек мыслит о задаче. Взаимодействие объектов также легко воспринимается и прямо соответствует физическим процессам отрасли. Промежуточные этапы описания и конечное решение доступны для многократного анализа на предмет улучшения и выявления ошибок. Используемые в проектировании САПР и другие программные средства позволяют наблюдать поведение проектируемых систем и физические процессы (см. рис. 11).

Spoiler

Рисунок 11. Визуализация обтекания модели самолёта в виртуальной аэродинамической трубе.

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

В проектировании СБИС точным решением является описание физической структуры изделия, которая будет создана в процессе изготовления СБИС.

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

Источники проблем методологии проектирования

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

Конфликт формы представления понятий

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

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

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

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

На практике установлено, что текст, далеко не всегда, лучшая форма представления понятий, в том числе алгоритмических. Примером могут служить медицинские алгоритмы. Практика показала, что их текстовое описание не лучший способ представления, потому, в настоящее время, используются схемы алгоритмов, в частности визуальный язык ДРАКОН [21].

Разрыв целостности маршрута и понятийного аппарата

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

Применительно к существующей технологии производства СБИС выделяют следующие проблемы логического синтеза [23]:

• Задержка на межсоединениях становится доминирующей, что требует совмещения этапов sizing/physical/logic synthesis. Логический синтез без учета реализации схемы в кремнии неэффективен.

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

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

Для решения этой проблемы, в программе IDEA, предлагается использовать, на этапе логического синтеза и физического проектирования СБИС, обученные модели искусственного интеллекта (см. рис. 2). При этом результаты должны контролироваться человеком (см. рис. 3).

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

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

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

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

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

Требования к личным навыкам

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

Spoiler

Рисунок 12. Описание двухвходового мультиплексора на языке SystemVerilog [13].

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

Работа с текстом с минимальной умственной нагрузкой требует развитых вербальных навыков, которые формируются далеко не у всех взрослых людей [33].

Для формирования развитых вербальных навыков (навыков работы с текстами), необходимо соответствующее обучение. Установлено, что такие навыки формируются у профессиональных программистов [17, 27]. Но далеко не у всех людей, прошедших профессиональное обучение по специальностям программная инженерия (software engineer) или прикладная математика.

Применяемая методология требует, чтобы разработчики микропроцессорных систем обладали навыками программистов. Фактически методология превращает разработку СБИС в программирование. Однако, микропроцессорная система является физическим объектом, создание которого требует существенно больших знаний, чем приобретают программисты в процессе обучения. В разработке сложных микропроцессорных систем должны принимать участие инженеры разной специализации, то есть люди с разными знаниями и навыками. И далеко не все из них будут обладать развитыми вербальными навыками. А значит, при работе с текстами, они будут неизбежно испытывать повышенную умственную нагрузку и допускать большое количество ошибок.

Вывод

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

Проблема и предлагаемое решение

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

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

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

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

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

В связи с этим, некоторые успехи в достижении поставленных в программах DARPA целей, не дают гарантии дальнейшего роста производительности проектирования на основе предлагаемой парадигмы. Прежде всего, применительно к микропроцессорным системам (SoC & SiP) предельных параметров.

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

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

Автор предлагаемого проекта, наблюдал на практике эффективность схемного проектирования при разработке микроархитектуры микропроцессора. В рамках проекта суперкомпьютера Ангара, под руководством Эйсымонта Л.К., автор участвовал в разработке микропроцессора с массовым параллелизмом, где применялся метод схемного проектирования. Разработка микроархитектуры выполнялась одним человеком, обладавшим большим опытом схемотехнического проектирования. Применение схемного проектирования показало существенно меньшее количество ошибок, допускаемых человеком, при разработке микроархитектуры и схемотехнической реализации функций блоков. При этом, описание уже готовых схем, на языке Verilog, приводило к появлению ошибок, отсутствовавших в схемном описании. Для сравнения, работая в INTEL Corp., автор участвовал в разработке микропроцессора Kevet (проект закрыт). В проектировании RTL модели микроархитектуры, относительно простого микропроцессора, участвовало 6 инженеров. Для верификации RTL кода, только на микроархитектурном уровне, было задействовано 20 человек.

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

Ранее упомянутый пример, проект тяжёлого конвертоплана выполненный в САПР T-FLEX CAD 16, интересен тем, что проектирование ведётся в визуальной среде, дающей явную связь между понятиями, в которых мыслит инженер, и объектами, составляющими проектируемую систему.

Другой пример из области ракетостроения. При создании космической системы Энергия-Буран, для повышения производительности программирования, были созданы проблемно-ориентированные языки, основанные на терминах, понятиях и форме представления алгоритмов управления и испытаний, используемых разработчиками корабля. Такой подход позволил повысить производительность программирования и надёжность программного обеспечения. В дальнейшем, на основе когнитивно-эргономического подхода, был создан графический язык ДРАКОН. Применение его для создание различных ракетно-космических систем доказало эффективность идей, положенных в его основу [14, 28, 39].

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

Литература

1. A modular digital VLSI flow for high-productivity SOC design. Brucek Khailany director of research, ASIC & VLSI NVIDIA CORPORATION. ERI Summit 2018.

2. Cerebras процессор для ИИ невероятных размеров и возможностей. Геннадий Детинич. 20.08.2019. https://3dnews.ru/992698 (дата обращения: 11.11.2020)

3. DARPA мечтает радикально упростить проектирование чипов. 04.07.2018 https://3dnews.ru/972103 (дата обращения 07.05.2019)

4. IDEA & POSH program updates. Andreas Olofsson. DARPA MTO program manager. ERI Summit 2019.

5. Intelligent Design of Electronic Assets (IDEA) & Posh Open Source Hardware (POSH) // Andreas Olofsson Program Manager, DARPA/MTO. Proposers Day Mountain View, CA. 9/22/17.

6. NVIDIA Introduces DRIVE AGX Orin Advanced, Software-Defined Platform for Autonomous Machines. Tuesday, December 17, 2019. https://nvidianews.nvidia.com/news/nvidia-introduces-drive-agx-orin-advanced-software-defined-platform-for-autonomous-machines (дата обращения: 11.11.2020)

7. Silicon Compilers - Version 2.0 // Andreas Olofsson Program Manager, DARPA/MTO. International Symposium on Physical Design. March 25-28, Monterey, CA. 2019.

8. Будылина С.М., Смирнов В.М. Физиология сенсорных систем и высшая нервная деятельность: Учеб. пособие для студ. высш. учеб, заведений. М. 2003.

9. Бухтев А. Методы и средства проектирования систем на кристалле. // Chip News 2003. -4.

10. Гигиена труда : учебник / под ред. Н. Ф. Измерова, В. Ф. Кириллова. -2-е изд., перераб. и доп. -М. : ГЭОТАР-Медиа, 2016.

11. Горбунов В., Елизаров Г., Эйсымонт Л. Экзафлопсные суперкомпьютеры: достижения и перспективы. Открытые системы. СУБД 2013. -07 http://www.osp.ru/os/2013/07/13037342/ (дата обращения 05.11.2013)

12. ГОСТ Р ИСО 10075-2011 Эргономические принципы обеспечения адекватности умственной нагрузки. Основные термины и определения.

13. Дональд Томас. Логическое проектирование и верификация систем на SystemVerilog / пер. с анг. А. А. Слинкина, А. С. Камкина, М. М. Чупилко; науч. ред. А. С. Камкин, М. М. Чупилко. М.: ДМК Пресс, 2019.

14. ДРАКОН [электронный ресурс]: Википедия. Свободная энциклопедия. https://ru.wikipedia.org/wiki/ДРАКОН (дата обращения: 11.11.2020)

15. Ильин Е. П. Дифференциальная психология профессиональной деятельности. СПб.: Питер, 2008. 16. Инновационные суперкомпьютерные технологии и проблемы создания отечественной перспективной элементной базы. / Л.К.Эйсымонт, В.С.Горбунов. Доклад на 5-м Московском суперкомпьютерном форуме. 21 октября 2014 года.

17. Исследование способности к усвоению искусственных языков у программистов. Орел Е. А. ОРГАНИЗАЦИОННАЯ ПСИХОЛОГИЯ. Т. 2. 2. 2012.

18. Как устроена универсальная разумная система? Анохин К.В. Наука о поведении: четыре главных вопроса Школа молодых ученых, 7-13 октября 2015. https://scorcher.ru/articles/images/3678/anokhin.pdf (дата обращения 08.09.2019)

19. Канышев В., Шагурин И. Применение языка SystemC и средств разработки на его основе для проектирования Систем на кристалле. // Chip News 2006. -9.

20. Когнитом: разум как физическая и математическая структура. К.В. Анохин. Семинар Социофизика. 27 сентября, 2016.

21. Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине. Николай Воронин. BBC NEWS Русская служба. 5 августа 2019. https://www.bbc.com/russian/features-48583773 (дата обращения: 11.11.2020)

22. Кремниевый радиатор с микроканалами с жидкостью в 100 раз лучше металлического. 01.03.2019 https://3dnews.ru/983605 (дата обращения: 05.05.2019)

23. Ложкин С.А., Марченко А.М. Математические вопросы синтеза интегральных схем. [электронный ресурс] http://mk.cs.msu.ru/index.php/Математические_модели_и_методы_синтеза_СБИС (дата обращения: 15.10.2013)

24. Марков И. Проектирование интегральных схем: от разбиения графов до временной оптимизации систем. Лекции на факультете ВМК МГУ. 2013.

25. На пути к экзафлопсному суперкомпьютеру: результаты, направления, тенденции. / Горбунов В.С., Эйсымонт Л.К. Доклад на третьем Московском суперкомпьютерном форуме 01.11.2012

26. Общая психология : учебник для вузов / В. В. Нуркова, Н. Б. Березанская. 3-е изд., перераб. и доп. М. : Издательство Юрайт, 2017.

27. Особенности интеллекта профессиональных программистов. Орел Е. А. BECTH. MOCK. УН-ТА. СЕР. 14. ПСИХОЛОГИЯ. 2007. 2.

28. Параджанов В. Д. Как улучшить работу ума: Алгоритмы без программистов это очень просто! М.: Дело, 2001.

29. Представление информации для поддержки когнитивной деятельности человека-оператора. Анохин А. Н. // Актуальные проблемы психологии труда, инженерной психологии и эргономики. Выпуск 6 / Под ред. А. А. Обознова, А. Л. Журавлева. М.: Издательство Институт психологии РАН, 2014.

30. Применение концепций инженерной психологии к профессиям, традиционно не считающимся операторскими. С.А. Дружилов // Электронный журнал Психологическая наука и образование 1 2011.

31. Проект тяжёлого конвертоплана в T-FLEX CAD 16 (более 60000 тел). T-FLEX CAD. 25.11.2019. https://3dtoday.ru/blogs/topsystems/proekt-tyazhelogo-konvertoplana-v-t-flex-cad-16-bolee-60000-tel (дата обращения: 11.11.2020)

32. Процессор NVIDIA Orin шагнёт за пределы 12-нм технологии с помощью Samsung. Алексей Разин. 19.12.2019. https://3dnews.ru/1000054 (дата обращения: 11.11.2020)

33. Психология мышления. Гурова Л.Л. М.: ПЕР СЭ, 2005.

34. Психология программирования: цели, проблемы, перспективы. Рожников В. А. ОБЩЕСТВО: СОЦИОЛОГИЯ, ПСИХОЛОГИЯ, ПЕДАГОГИКА 3 2014.

35. Стасевич К. Человеческий мозг похудел на 14 миллиардов нейронов. 01.03.2012 года. http://compulenta.computerra.ru/archive/neuroscience/664455/ (дата обращения: 15.10.20013)

36. Стрелков Ю.К. Инженерная и профессиональная психология. 2-е изд. - М.: Издательский центр Академия, 2005.

37. Суперкомпьютер Neocortex: 800 тыс. ядер Cerebras для ИИ. Юрий Поздеев. 09.06.2020. https://servernews.ru/1013005 (дата обращения: 11.11.2020)

38. Финский суперкомпьютер получит 200 тысяч ядер благодаря 7-нм CPU AMD EPYC Rome. 15.12.2018 https://servernews.ru/979696 (дата обращения: 07.06.2019)

39. Энергия Буран [электронный ресурс]: Википедия. Свободная энциклопедия. https://ru.wikipedia.org/wiki/Энергия__Буран (дата обращения: 11.11.2020)