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

== Аннотация ==
;Докладчик: {{Speaker|Сергей Карпеш}}
<blockquote>
Наряду с традиционными воздушными системами охлаждения все большее  распространение  получают  жидкостные. 
Жидкостное  охлаждение  более  эффективно  благодаря  большей  теплоемкости,  коэф. термопередачи и т.д.
Ещё одним плюсом является то, что жидкостные системы охлаждения гораздо компактнее традиционных воздушных кулеров и имеют меньшее энергопотребление. Однако, функционирование  погружной  системы  охлаждения  невозможно  без  допонительного потребления энергии: насосы, перекачивающие охлаждающую жидкость, вентиляторы драйкулера. Данный доклад посвящен процессу и особенностям разработки контроллеров для системы управления  погружным  охлаждением  высокопроизводительного  вычислительного комплекса.
</blockquote>

== Видео ==

{{vimeoembed|156812601|800|450}}
{{youtubelink|MxTskvJnJoc}}{{letscomment}}
{{oseduconf-2016-draft}}

== Слайды ==
[[File:Разработка аппаратного обеспечения для управления высокопроизводительным ВК с погружным охлаждением.pdf|left|page=-|256px]]

{{----}}

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

Их реализация требует алгоритм, учитывающий все особенности системы.

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

Для реализации программной части используются SCADA системы.
Это комплект ПО, предназначенный для разработки и обеспечения работы в реальном времени систем сбора, обработки и архивирования информации об объекте мониторинга.

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

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

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

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

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

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

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

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

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

Из их плюсов можно отметить:
* Возможность установки нескольких термометров на один «луч»;
* Калибровка изготовителем на заводе;
* Возможность установки на большем расстоянии от контроллера с минимальными потерями в точности измерений.

Для установки внутри бака были выбраны датчики на шине I2C в связке с мультиплексором. Основным их преимуществом является адресация. Структура блока с вычислительным оборудованием подразумевает на каждый узел луч с несколькими датчиками.
При использовании нескольких датчиков 1-Wire на одной шине необходимо обращаться по идентификатору, который для каждой микросхемы уникален.

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

Считывание данных с датчиков не является сложной задачей, в отличии от процесса общения между контроллером и OpenSCADA.
Модуль сбора данных запрашивает данные с контроллера по протоколу Modbus. Это открытый и подробно документированный протокол, основанный на архитектуре ведущий-ведомый. Данные передаются пакетами. Посылка содержит в себе идентификатор устройства, команду, данные, необходимые для выполнения команды, и контрольную сумму. Ответ содержит идентификатор ведомого устройства, команду, результат работы и контрольную сумму.

Обязательным  элементом  устройств  подобного  класса  является сторожевой таймер, при переполнении которого происходит перезагрузка микросхемы. Этот механизм позволяет автоматически восстановить работу устройства при зависании. Время срабатывания подбирается исходя из самой долгой операции при работе. Для контроллера самым долгим промежутком будет отправка даных. Размер пакета ограничен 252 байтами с данными. Плюс 4 байта служебной информации. На скорости 9600 бод они будут передаваться за ≈ 0.27 сек.

Во время работ над проектом написана библиотека для работы с Modbus RTU для микроконтроллеров AVR, поддерживающая все
основные функции чтения и записи.
В спецификации<ref>Спецификации   протокола   MODBUS   http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf</ref> их описано 8, но условно можно разделить на 3 типа: чтение, запись и множественная запись.
Различаются они только по типам данных, с которыми работают.
Библиотека основана на прерывании по приему байта.
Под этим подразумевается не только сохранение пакета с данными, но и мгновенная обработка запроса, после окончания его приема.
Такое решение позволяет ввести некоторую многозадачность при работе микроконтроллера и «заниматься своими делами» в основном цикле программы, но при этом не беспокоиться о том, что запрос может быть пропущен.

Объем памяти, занимаемый ядром библиотеки, составляет 20 байт.
Остальная память микроконтроллера доступна для хранения регистров.  Однако  необходимо  учитывать  тот  факт,  что  максимальная
длина пакета составляет 256 байт, которые должны быть доступны при получении запроса. На генерацию ответа выделение памяти не требуется, а контрольные суммы считаются по ходу передачи.
Использован табличный метод подсчета CRC, данные для которого хранятся во ﬂash памяти.

{{----}}
== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->

{{fblink|1697160467203634}}                                          
{{vklink|172}}                                          
<references/>





<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2021-08-31T18:11:56.515032|vimeo_comments=0|vimeo_plays=20|youtube_comments=0|youtube_plays=48}}