Подсистема архивирования технологических параметров АСУ ТП. Проблемы и решения.
Общие определения
===================
Назначение подсистемы архивирования можно коротко обозначить как долговременное хранение истории изменения
параметров технологического процесса.
Архивный сервер - специально выделенная машина для хранения и архивов и выдачи отчётов по запросам.
Проблемы
========
Практически все АСУ ТП имеют в своём составе данную подсистему и почти у всех она сделана без должного понимания и должных
усилий. Это приводит к тому, что на объекте внедрения АСУ ТП архивам не доверяют, не рассматривают их как
достоверный инструмент для расследования аварий. Тому есть множество причин.
Типичные проекты содержат несколько десятков тысяч ТП (технологических параметров), изменяющихся лавинообразно со
скоростью до десятков изменений в секунду во время аварии. Авария может длиться несколько часов и нужно выдержать
такой поток, не потеряв более тысячной доли процента параметров. Более того, этот архив должен быть вскрываем
за разумное и прогнозируемое время. Никому не нужен архив, вскрытие которого длится более рабочей смены. Нужно
обеспеспечить как выполнение запроса на архив нескольких десятков параметров за время до полугода, так и
нескольких десятков тысяч параметров за срок до нескольких суток. Всё это от момента первого запроса до появления
отчёта должно выполняться не более двух часов. При этом не должна перепоняться память на современном оборудовании.
Также, архив должен быть устойчивым к сбоям оборудования, както, физического носителя и внезапного пропадания
питания. Также нужно отметить требование прогнозируемого размера архива, обычно требуется указать размер одной
записи. Зная типичный средний поток и максимальный поток во время аварии, должна иметься возможность расчитать
требования к дисковому пространсту в зависимости от требуемого срока хранения. Архив должен обладать свойством
тиражирования, получения неких слепков в определнном формате за определенный диапазон времени для последующего
расследования на удалении от объекта.
Многие АСУ ТП для снижения архивируемого потока вводят различные апертуры. В результате получается архив,
который никому, кроме разработчика, не понятен. Совершенно типичная ситуация. Возможность работы с апертурами
безусловно должна быть предусмотрена, но если архив без апертур не работает, грошь ему цена.
Почему не доверяют архивам. Потому что они обычно пропускают слишком много данных. Выше была указана некая цифра
0.001% потерь. Она довольно сложно достижима. Типичной ошибкой разработчиков АСУТП явлвется использование
стандартной файловой системы для хранения архивных файлов. Видимо, они не исследовали такой вопрос, как время
на запись на диск какого-то числа байтов. Действительно, за сколько времени на диск запишется, скажем, 20 байт ?
При исследовании простейшей программы записи на диск выясняется, что скорость записи весьма неравномерна. Периодически
появляются некие "выбросы", когда скорость записи замедляется на порядки. Это связано с периодическим сборосом
дисковых буферов, с действиями по расширению файла и пр. Эти вещи можно минимизировать различным настройками, но
полность избавиться от них невозможно. Ситуация усугубляется тем, что дисковые операции атомарны - пока имеет
место быть высокая дисковая активность, пользовательские программы получают очень мало квантов времени. Пропуск
данных катастрофический и никак в 0.001% не укладываются. На почти всех АСУТП это имеет место быть. Более того,
дисковое пространство не бесконечно, старую информацию нужно удалять. Удаление, к примеру, 100 гигабайтов данных
(не очень большое число) может занять минуты. Из-за дисковой активности в это время постема архивирования будет
практически выключена. Автоматическая процедура чистки может попасть как раз на аварийную ситуацию.
Типичной ошибкой при разработке подсистемы архивирования также является не должное внимание к такому параметру, как
время рождения ТП. До архивного сервера ТП может идти как десятки тактов, так и зарождаться мгновенно прямо на
архивном сервере. Типичной ошибкой является игнорирование данного вопроса. В результате причинно - следственная
связь в архиве получается нарушена и смотреть такой архив весьма затруднительно, если не сказать, невозможно.
Типичной и грубой ошибкой является использование под архив типовых баз данных. Таких, как MySQL и Berkeley DB.
Скорость как записи так и доступа для больших проектов соврешенно неприемлема. Количество избыточной информации
на диске не поддаётся никакому контролю.
Решения
=======
Нелинейная скорость записи, вызванная сбросами буферов, действиями по расширению файла и прочими особенностями
традиционных фаловых систем, практически не поддаётся контролю, а если и поддаётся, то решение получается не до
конца эффективным очень аппаратно зависимым. Решением данной проблемы явился отказ от стандартный файловой системы
и создание своей файловой системы - очень простой, даже примитивной по современным меркам. В качестве обычной
файловой системы общего назначения она
служить не может, но для хранения несколько тысяч архивных файлов подходит идеально. Отсутствует фрагментация,
понятие кластеров и таблиц размещения файлов. Минимальное количество перемещений головок даёт практически линейную
скорость записи, максимально приближенную к линейной скорости записи носителя. Файлы любой длины удалаются менее
чем за микросекунду. Все элементы 64-х разрядные, никаких проблем с размером на любых современных носителях нет.
Конструктивно это выполнено максимально аппаратно независимо. Пользователь АСУ ТП этих файлов не видит, данная
файловая система может быть расположена как на физическом носителе так и внутри обычного файла на ФС общего
назначения. Это позволяет переносить слепки архива на внешние носители и высылась для анализа вне объекта.
Для компенсации задержек прихода ТП на архивный сервер вводим буфер в оперативной памяти архивного сервера. Буфер
содержит все ТП за несколько десятков секунд. При заявленной скорости архивирования данный буфер может содержать до
нескольких миллионов ТП. И их надо рассортировывать и упорядочивать. Неиндексированный архив будет весьма сложно
прочитать в последствии. Не забываем от требованиях к скорости извлечения данных. Ни один из популярных методов
сортировки данных, включая метод быстрой сортировки, не даёт необходимую скорость сортировки на современном
оборудовании. Здесь применена некая вариация на метод линейной сортировки. Суть метода состоит в том, что каждому
значению сортируемого элементу можно сопоставить точку на некоей координатной прямой. Когда приходит ТП, делаем
"зарубку" на прямой в соответсвующем от начала координат месте. И в итоге получим естественным образом
отсортированный массив. Применённая двухпроходная модификация данного метода даёт возможность не просто ставить
зарубки, но и сохранять все элементы структуры ТП. Данный метод на порядок быстрее метода быстрой сортировки.
Недостатком метода является требовательность к памяти, зависящая от диапазона сортируемых элементов.
Например, для сортировки по 4-х байтному знаковому целому понадобится 4 гигабайта оперативной памяти как минимум.
Но мы загрубляем время рождения ТП до единиц миллисекунд, и ограничиваем размер буфера 30-ю секундами,
в результате чего укладываемся в рамки оснащения современного аппаратного обеспечения оперативной памятью.
Скорось современных жестких дисков высока, но зачастую не достаточна для записи лавинообразного аварийного потока.
Для компенсации введена отложенная запись с равномерным распредением ресурса.
Разработанный формат архива содержит контрольную информацию для контроля повреждения носителя а также индексные
значения. Индексирование позволяет раскрывать все ТП архив со скоростью архивирования и выше. Это позволяет
"проиграть" аварийную ситуацию на видеокадрах в реальном времени - видеть то, что видел оператор. Отличное
средство анализа. Аналоги мне не известны. Размер записи фиксирован, другой избыточной информации, за исключением
структур файловой системы, нет. Проблема прогнозирования размера архива решена.
Многие разработчики, "приученные" к каким-то АСУ ТП, всё же используют по привычке либо по причине наличия
каких-то наработок, различные апертуры. Это существенно снижает нагрузку на архивный сервер, но, как правило, выбор
апертуры делается на основании неоднозначных выкладок. В результате архив получается черезмерно загрублённым и,
как говорилось выше, никто, кроме самого разработчика, такой архив не понимает. Не говоря уже о том, что проигрывание
такого архива в реальном времени ничего не даёт. Для компенсации этого эффекта в определённые промежутки времени
в архив сбрасываются значения всех ТП вне зависимости от требований по апертуре. Это есть некий компромисс,
выработанный в условиях реальных внедрений и эксплуатации.
Нерешенные проблемы
===================
Остаётся нерешённой проблема доступа к данным без ущерба архивации. Дисковая операция - атомарна. Когда идет
мощный запрос к архивному серверу, без потерь данных не обходится. Нужно придумать какой-то диспетчер для
разпределения приоритетов на использования ресурса жёсткого диска.
Не очень хорошо решена проблема резервирования и восстановления повреждённых данных. На данный момент это
решение представлет из себя отдельную подсистему, собирающую данные с дублирующих друг друга отдельных серверов
и обединяющих эти данные воедино. Хотелось бы, что бы серверы как-то сами самовосстанавливались на основании
иформации от дубля.
Не решена проблема архивирования данных, не попадающих в буфер памяти на архивном сервере. Хоть этот буфер и
составляет 30 секунд, что, в приципе, более, чем достаточно, но в отдельных аварийных случаях возможно и более
высокое отставание. Эти данные надо хоть как-то сохранять и потом показывать.
