Введение
Цель работы в целом: разработка информационно-коммуникационной модели интегральной системы off-line обработки, хранения и распределенного анализа данных экспериментов, которые будут проводиться на нейтронных установках строящегося высокопоточного исследовательского реактора ПИК.
Цель третьего этапа: обобщение и оценка полученных результатов, а также разработка рекомендаций по использованию результатов проведённых НИР в реальном секторе экономики, а также в дальнейших исследованиях и разработках.
В ходе выполнения работ были подготовлены промежуточные отчёты:
а) первый этап «Выбор направления исследований» - № госрегистрации 02201250871;
б) второй этап «Теоретические и экспериментальные исследования поставленных перед НИР задач» - № госрегистрации 02201261270.
На третьем этапе была произведена оценка и обобщение результатов НИР, был обоснован выбор тех или иных решений и технологий, а также дана оценка эффективности полученных результатов в сравнении с современным научно-техническим уровнем. Были разработаны рекомендации по использованию результатов НИР в дальнейших исследованиях и разработках, в частности при планировании экспериментов на нейтронных установках реактора ПИК.
Все задачи третьего этапа были выполнены полностью. Есть все основания утверждать, что работа была выполнена на высоком уровне, не уступает существующим аналогам и может быть использована как базис для ОКР при разработке и внедрении реальной системы off-line обработки данных на нейтронных установках реактора ПИК.
1Обобщение и оценка полученных результатов 1.1Обобщение результатов исследований 1.1.1Интегральный характер разработанной модели
Важными свойствами разработанной в результате проведённых исследований модели являются интеграция нескольких ключевых сервисов, общий механизм аутентификации и авторизации, а также возможность доступа ко всем ключевым сервисам системы, кроме сервиса управления виртуальными организациями, из одного интерфейса.
Ключевыми сервисами модели являются:
а) Сервис хранения метаданных – реализует основную логику управления авторизацией пользователей, метаданными и файлами;
б) Сервис хранения файлов – предоставляет доступ к подключенным к нему файловым системам по стандартными протоколам передачи данных;
в) Сервис запуска заданий – позволяет запускать и контролировать выполнение пользовательских заданий обработки;
г) Сервис интерфейса пользователя – предоставляет возможность интерактивного просмотра и редактирования метаданных, чтения и записи файлов, а также запуска и контроля состояния заданий обработки;
д) Сервис управления виртуальными организациями – осуществляет регистрацию пользователей системы по цифровым сертификатам и позволяет объединять пользователей в группы по различным признакам (принадлежность к одному научному коллективу и т.п.).
Разработанная модель позволяет решать широкий спектр задач по хранению, организации и обработке научных данных, возникающих в процессе эксплуатации экспериментальных установок. Модель была разработана с учётом современных требований к интероперабельности, её компоненты, пользуясь стандартными протоколами и механизмами обеспечения безопасности, могут быть интегрированы с компонентами других Грид-систем, работающих или разрабатываемых в научных центрах по всему миру.
1.1.2Аутентификация пользователей и сервисов и архитектура безопасности модели
Возможность взаимной аутентификации (установления подлинности) пользователей и сервисов является основой архитектуры безопасности разработанной модели и базируется на инфраструктуре безопасности с открытым ключом (PKI). В PKI каждому пользователю и сервису выдаётся однозначно идентифицирующий его уникальный цифровой сертификат. Выдачей сертификатов занимается Удостоверяющий Центр (УЦ). При установлении защищённого сеанса связи, оба участника обмениваются цифровыми сертификатами и проверяют их достоверность по электронной подписи УЦ. Если проверка прошла успешно, участник сеанса может быть уверен, что информация, содержащаяся в сертификате другой стороны, достоверна.
В разработанной модели предполагается использование цифровых сертификатов формата X.509, являющегося стандартом в Интернет и Грид. Поддержка данных сертификатов присутствует во всех современных браузерах на всех доступных платформах и операционных системах. Каждый сертификат X.509 содержит символьную строку (DN – Distinguished Name или Subject), однозначно идентифицирующую его обладателя. Для персональных сертификатов данная строка содержит, в частности, имя и фамилию владельца, а для сертификатов сервисов – доменное имя узла. Строка DN используется как уникальный идентификатор пользователей и сервисов.
Сертификат X.509 может быть записан в файловые контейнеры различных форматов. В разработанной модели используются два наиболее распространённых формата контейнеров: PEM и PKCS12.
Сертификат в контейнере PEM представляет собой два файла: usercert.pem и userkey.pem для персонального сертификата или hostcert.pem и hostkey.pem для сертификата сервиса. Данный формат используется для хранения сертификатов пользователей и сервисов. Контейнер PKCS12 необходим для импорта персонального сертификата пользователя в браузер. Из одного формата контейнера в другой сертификат может быть перемещён стандартными средствами, например, программой openssl.
1.1.3Авторизация пользователей и групп
Предлагаемый механизм авторизации основан на ролевой модели (RBAC), где с каждым пользователем или группой пользователей ассоциируется роль, определяющая их права доступа к объектам данных и метаданных, т.е. набор действий, которые пользователь или группа пользователей могут совершать над тем или иным объектом.
Кортежи, состоящие из идентификаторов пользователей или групп пользователей и их ролей, объединяются в списки контроля доступа (ACL) и связываются с такими объектами как “Исследование” и “Набор данных”. Доступ к остальным объектам базы данных определяется соответствующим списком контроля доступа родительского объекта. Так, например, доступ к объекту “Образец” определяется списком контроля доступа соответствующего родительского объекта “Исследование”, а доступ к объекту “Файл данных“ – списком контроля доступа соответствующего родительского объекта “Набор данных”.
В системе определён следующий набор возможных ролей:
а) Владелец (Owner) – может выполнять любые операции над самим объектом и его дочерними объектами, а также модифицировать списки контроля доступа для них;
б) Изменение данных (Writer) – имеет те же права, что и Owner, но не может изменять списки контроля доступа;
в) Добавление данных (Appender) – может добавлять новые дочерние объекты, но не может модифицировать существующие объекты других пользователей;
г) Только чтение (Reader) – имеет права для чтения объекта и дочерних объектов, но не может их модифицировать.
В базе метаданных разделение прав доступа реализовано с использованием отдельной таблицы, в которой каждому имеющемуся в системе списку контроля доступа присваивается уникальный идентификатор. Таким образом, для связи объектов “Исследование” или “Набор данных” со списком контроля доступа они должны содержать ссылку на идентификатор этого списка. При запросе пользователя на выполнение каких-либо действий над объектами вначале проверяется роль данного пользователя в соответствующем списке контроля доступа и, в зависимости от результата, запрашиваемые действия выполняются или отвергаются. Особым случаем является список контроля доступа с идентификатором равным нулю: пользователи, входящие в него, считаются администраторами системы и наделяются полными привилегиями по изменению, добавлению и удалению любых объектов.
При создании корневого объекта “Исследование” должен быть указан пользователь или группа пользователей, которым будет назначена роль “Владелец”. При создании дочерних объектов “Набор данных” список контроля доступа родительского объекта “Исследование” копируется в список контроля доступа набора данных, при этом создающему объект пользователю присваивается роль владельца.
Владелец корневого объекта может модифицировать список контроля доступа, т.е. добавлять, изменять или удалять элементы списка, используя программный прикладной интерфейс (ППИ) сервиса хранения метаданных или возможности веб-интерфейса, однако при любой такой модификации система проверяет, чтобы для любого модифицируемого объекта всегда существовал хотя бы один пользователь с ролью “Владелец”.
1.1.4Использование вычислительных кластеров для обработки и анализа экспериментальных данных
В большинстве современных научных центров вычислительные ресурсы организованы в установки, называемые кластерами. Вычислительный кластер представляет собой множество отдельных вычислителей (компьютеров, серверов), объединённых телекоммуникационной сетью, централизованно управляемых и совместно используемых для решения научных задач.
В отличие от разрозненных компьютеров, ресурсы кластера могут быть эффективно использованы совместно, например, с использованием технологии параллельных вычислений MPI. При этом суммарная вычислительная мощность может значительно превышать достижимую вычислительную мощность одного компьютера.
Для запуска заданий на кластерах обычно используются системы пакетного управления заданиями, организующие очередь заданий и распределяющие вычислительные узлы между ними. К большинству распространённых пакетных систем управления заданиями может быть подключен универсальный интерфейс Грид, реализуемый сервисом запуска заданий CREAM.
Использование стандартного Грид-интерфейса позволяет использовать для обработки заданий кластеры практически произвольного размера и архитектуры. При возникновении необходимости решать более сложные и требовательные к ресурсам научные задачи, вычислительный ресурс кластера может быть легко расширен путём добавления новых узлов.
Дополнительным плюсом использования для обработки заданий кластеров со стандартным интерфейсом Грид является возможность участия в международных коллаборациях, производящих обработку данных, а также одновременное использование кластера для других научных нужд, что значительно повышает эффективность использования вычислительного ресурса.
1.1.5Сервис хранения метаданных
Системы управления данными экспериментов должны обеспечивать поддержку полного жизненного цикла этих данных от их создания, сохранения и обработки до публикаций, основанных на этих данных. Более того, такие системы должны учитывать и поддерживать логические связи между данными, порождаемые на различных фазах жизненного цикла исходных данных. Ключевым фактором при создании таких систем являются метаданные, которые являются средством описания различных фаз жизненного цикла экспериментальных данных и связанных с ними объектов, а также обеспечивают возможность поиска информации по различным критериям. Разработанная система хранения метаданных (СХМ) служит для решения перечисленных задач в области нейтронных исследований, проводимых на реакторе ПИК, и обладает следующими основными особенностями:
Полнота реализованной логической модели данных СХМ. Основные объекты, на базе которых была построена логическая модель данных, отражают основные базовые сущности предметной области нейтронных исследований. Логическая схема базы данных состоит из следующих основных абстрактных объектов:
а) Исследование (investigation) – центральный объект, содержащий информацию о конкретном исследовании.
б) Набор данных (dataset) - объект, который объединяет файлы, соответствующие определённому действию в рамках исследования. Это могут быть данные симуляции или других операций, предваряющих эксперимент, например калибровка, данные экспериментальных измерений или данные после обработки и анализа.
в) Файл данных (datafile) - описание файла данных, входящего в определённый набор данных.
г) Авторизация – объект, определяющий права доступа пользователей к конкретным данным. В текущей версии элементами данных, для которых определяются права доступа являются элементы двух типов: “Исследование” и “Набор данных”.
д) Образец (sample) - объект, содержащий информацию об образцах, используемых в исследовании. Различные наборы данных могут быть связаны с разными образцами.
е) Обработка данных (software_run) – объект, содержащий информацию о запуске определенного программного пакета для обработки данных, а также информацию о входных файлах и выходном наборе данных.
ж) Публикация (publication) - объект, содержащий информацию о публикации, выполненной по результатам исследования и связанной с конкретными наборами данных.
и) Ключевые слова (keywords) – ключевые слова, связанные с конкретным исследованием, которые могут быть использованы для поиска этого исследования в базе метаданных.
Каждый из таких объектов описывается фиксированным набором метаданных, а также имеется возможность создать дополнительный набор параметров, связанных с конкретным объектом.
Реализация связанных (цепочек) наборов метаданных. Связанные наборы метаданных появляются прежде всего в результате цепочки этапов сохранения и обработки экспериментальных данных. Конкретный этап обработки связан либо с первичными экспериментальными данными, либо с результатами предыдущих этапов обработки. Отсюда следует, что необходимо обеспечить возможность связать наборы метаданных, описывающие конкретные этапы, в единую цепочку, позволяющую пользователю проследить детали трансформации данных и историю получения конкретных результатов. Кроме того, конкретный объект публикация может быть включен в такую цепочку, ссылаясь на данные (и соответственно) исследование, на базе которых эта публикация основана. Для реализации такого рода цепочек в модель были включены абстрактные объекты DatasetMeta и PublicationMeta. DatasetMeta связывает файлы данных, которые являются входными для конкретного этапа обработки, с результирующим набором данных. PublicationMeta также связывает объект Publication с наборами данных, на базе которых эта публикация основана.
Прикладной программный интерфейс (ППИ) сервиса хранения метаданных. Сервис хранения метаданных реализует основную логику управления пользователями, метаданными и файлами. Данный сервис принимает команды от сервиса интерфейса пользователя или от клиента командной строки через сетевое соединение по протоколу HTTPS и возвращает ответ через то же соединение. Получив команду для работы с метаданными сервис выполняет её при условии, что пользователь имеет соответствующие права. В результате выполнения команды происходит транзакция с БД, возвращающая, изменяющая или добавляющая метаданные.
Входными параметрами программ ППИ являются имя команды и строка в формате JSON, определяющая структуру данных типа “справочник” или “хэш” с параметрами команды. Выходные данные также возвращаются в виде строки в формате JSON, определяющей хэш с возвращаемыми параметрами. Сервис хранения метаданных предоставляет достаточно широкий набор команд ППИ к СХМ. Эти команды можно разделить на следующие группы:
а) Команды для получения метаданных о конкретном объекте.
б) Команды для поиска объектов “Исследование” или “Набор данных” по различным критериям.
в) Команды модификации заданных объектов.
г) Команды добавления и удаления объектов.
С использованием этих команд был разработан веб-интерфейс для работы с СХМ, реализующий основные функции работы с метаданными, в том числе и навигацию по цепочке связанных метаданных.
Развитый механизм авторизации. Реализованный механизм авторизации основан на ролевой модели, где с каждым пользователем или группой пользователей ассоциируется роль, определяющая их права доступа к объектам данных и метаданных, т.е. набор действий, которые пользователь может совершать над тем или иным объектом. Кортежи, состоящие из идентификаторов пользователей или групп пользователей и их ролей, объединяются в списки контроля доступа и связываются с базовыми объектами “Исследование” или “Набор данных”. Доступ к остальным объектам базы данных определяется соответствующим списком контроля доступа родительского объекта. Кроме того, набор ролей соответствует общепринятому разделению прав доступа в рабочей группе исследователей: кто-то может только читать метаданные, описывающие конкретные исследования, кто-то может читать и обрабатывать данные с созданием новых результирующих наборов данных в СХД и т.п. Важным моментом здесь является возможность работы с группами пользователей как с обычным пользователем, что облегчает работу в больших научных коллаборациях.
1.1.6Сервис хранения файлов
Сервис хранения файлов предназначен для хранения файлов с данными и организации доступа к ним для чтения и записи. Сервис рассчитан на установку непосредственно на файловом сервере, имеющем достаточный объём дискового пространства.
Особенностью сервиса является механизм авторизации, основанный на уникальных идентификаторах файловых операций (токенах). Для записи или чтения файла клиент должен предоставить токен, полученный через сервис хранения метаданных. Такой подход позволяет избежать повторной авторизации пользователя (авторизация производится только сервисом хранения метаданных) и универсален для любых используемых протоколов передачи данных.
Файловый сервер с установленным сервисом хранения файлов должен иметь одну или несколько файловых систем, выделенных для хранения файлов данных. Файловые системы должны быть подключены к точкам монтирования виртуальной файловой системы Unix и описаны в конфигурации сервиса хранения файлов.
Например, если файловая система для хранения данных была смонтирована в точке /data, то в ней будут созданы два каталога: files и token, имеющие полные пути /data/files и /data/token соответственно.
Каталог files используется для постоянного хранения файлов, записанных на данный сервер. Этот каталог недоступен для чтения и записи непривилегированным пользователям, файлы из него не могут быть прочитаны или записаны через поддерживаемые сервисом протоколы передачи данных. Внутри данного каталога создаются подкаталоги с именами в формате ГГГГ-ММ-ДД, где ГГГГ – текущий год, ММ – месяц, а ДД – день месяца. Дополнительный уровень вложенности позволяет избежать перегрузки файловой системы (каталоги с очень большим числом файлов нежелательны) и позволяет в случае необходимости легко находить файлы, созданные в определённую дату.
Каталог token служит для временного хранения новых файлов, для которых получены токены на запись, в момент их передачи на сервер, а также содержит ссылки на файлы из каталога files, для которых получены токены на чтение. Данный каталог доступен для чтения и записи непривилегированному пользователю, от имени которого работают сервисы передачи данных, однако создание новых файлов непривилегированным пользователем в этом каталоге запрещено. Таким образом, доступ осуществляется только к файлам, которые были созданы в этом каталоге сервисом хранения файлов. Имена файлов в этом каталоге всегда соответствуют именам токенов, выданных клиентам.
Токены генерирует непосредственно сервис хранения файлов, при этом принимаются меры для того, чтобы гарантировать уникальность всех токенов в пределах одной файловой системы. Для создания имени токена используется нотация универсальных уникальных идентификаторов (UUID), позволяющая получать уникальные идентификаторы длиной 128 бит, что достаточно для предотвращения угадывания или подбора злоумышленником за приемлемое время.
1.1.7Сервис интерфейса пользователя
Сервис интерфейса пользователя предоставляет возможность интерактивного просмотра и редактирования метаданных, чтения и записи файлов, а также запуска и контроля состояния заданий обработки. Данный сервис рассчитан на работу с браузером и предоставляет пользователю графический веб-интерфейс.
Наличие веб-интерфейса для поиска и получения сохранённых данных является общепринятым для систем хранения данных в большинстве крупных научных центров. Разработанный в результате выполнения проекта веб-интерфейс обеспечивает выполнение основных требований, предъявляемых к подобным системам – обеспечение возможностей для поиска данных по различным критериям, определяемых прежде всего метаданными, связанными с сохранёнными файлами данных, а также наличие удобных средств чтения файлов из системы хранения файлов с использованием стандартных протоколов передачи данных.
Дополнительно при помощи разработанного веб-интерфейса можно также осуществлять пересылку файлов в систему хранения файлов с одновременным созданием метаданных, связанных с отдельными файлами или набором файлов. После передачи файлов в файловое хранилище пользователь, имеющий соответствующие привилегии, может отредактировать метаданные, используя простой, интуитивно понятный графический интерфейс.
Веб-интефейс предоставляет возможность двух вариантов поиска данных, используя метаданные объектов «Исследование» или «Набор данных» и связанных с ними метаданных. Каждый из вариантов поиска реализован в соответствующем разделе веб-сайта. Порядок работы по поиску, просмотру и модификации метаданных и файлов данных в целом совпадают, различаются начальные запросы поиска и представление дерева взаимосвязанных объектов базы метаданных, которое является результатом поиска.
В текущей версии веб-интерфейса реализована возможность поиска по таким критериям, как даты начала и окончания исследования, название исследования, установка, на которой проводился эксперимент, имя исследователя или экспериментатора, имя набора данных, дата создания набора данных. Набор критериев и возможности более детального поиска могут быть расширены в дальнейших версиях.
Кроме выбора значений метаданных поиск может проводиться либо по всем данным, к которым имеет доступ текущий пользователь, либо только по тем данным, которые он может не только просматривать, но и изменять. Режим поиска определяется группой переключателей в верхней части формы поиска: «Искать все данные» или «Искать только мои данные».
Результаты начального поиска представлены в виде иерархической структуры (дерева), каждый узел который представляет базовый объект «Исследование» или «Набор данных» соответственно. Используя графическое представление иерархической структуры, можно легко открыть и просмотреть метаданные, связанные как с базовыми объектами, так и с объектами, находящимися на нижних уровнях иерархии. Набор метаданных, связанных с выбранным узлом, отображается в табличном виде в правой части веб-страницы, как коллекция однородных объектов (Рисунок 1) или как набор метаданных для отдельного объекта в зависимости от выбранного узла.
И
Рисунок 1 Представление коллекции файлов для определённого набора данных
спользуя командные кнопки, наличие которых зависит от прав текущего пользователя по отношению к базовому объекту, можно перейти в режим редактирования метаданных либо добавить новый или скачать выбранный файл.
Таким образом, для конечного пользователя поиск и получение файлов данных сводится к работе с элементами графического интерфейса, скрывающего реализационную сложность модели метаданных и программных средств для передачи данных.
Доступ к файлам и метаданным определяется единой системой безопасности, основанной на цифровых сертификатах стандарта X.509 и ролевой модели авторизации.
Кроме графического веб-интерфейса для интерактивной работы с системой хранения данных разработан прикладной программный интерфейс (ППИ) для встраивания функций работы с метаданными и файлами в программное обеспечение измерительных станций и программ обработки и анализа данных. Собственно, при разработке веб-интерфейса также использовалась соответствующая программная библиотека и фактически он является примером использования разработанного ППИ.
Кроме функций работы с метаданными и файлами веб-интерфейс предоставляет возможность запуска и контроля выполнения заданий пользователя на вычислительном кластере с использованием Грид-технологий и использования при этом входных/выходных файлов, хранящихся в системе хранения файлов.
Для каждого пользователя на сервере, на котором установлен сервис интерфейса пользователя, в момент первого использования веб-интерфейса создаётся рабочая директория, предназначенная для временного хранения файлов, которые могут быть использованы для запуска заданий пользователя и получения информации о ходе их выполнения. Данная директория не предназначена для долговременного хранения файлов большого объёма, суммарный объём хранимых файлов ограничен настройками системы. Доступ к этой директории и работа с файлами возможны только через элементы графического веб-интерфейса.
Используя команды меню секции «Подготовка и контроль заданий», пользователь может выполнять следующие операции:
а) копировать файлы с локального компьютера пользователя в директорию, определённую для сохранения файлов данного пользователя на сервере;
б) удалять файлы из этой директории;
в) создавать вложенные поддиректории
г) загружать файлы из директории на сервере на локальный компьютер пользователя;
д) создавать/редактировать текстовые файлы на сервере;
е) получать/обновлять список заданий, запущенных пользователем через веб-интерфейс;
ж) проверять значение статуса для выбранных заданий;
и) прекращать выполнение (abort) выбранных заданий;
к) получать результаты (выходные файлов) на сервер интерфейса пользователя для выбранных заданий;
л) сохранять файлы с результатами выполнения задания на свой локальный компьютер;
м) удалять выбранные задания из списка заданий;
н) просматривать журнал выполнения задания.
Для запуска заданий используется программный модуль запуска задач (ПМЗЗ), который предоставляет прикладной программный интерфейс к сервису управления запуском заданий (СУЗЗ). ПМЗЗ предназначен для выполнения абстрактных команд, получаемых от графического интерфейса, путём трансляции их в одну или несколько команд интерфейса командной строки (ИКС) СУЗЗ. Графический веб-интерфейс взаимодействует с ПМЗЗ при помощи передачи ему абстрактных команд, набор которых универсален для любого используемого СУЗЗ Грид, и позволяет изменять версию или тип СУЗЗ незаметно для пользователя системы и реализации веб-интерфейса. Для поддержки нового типа СУЗЗ Грид не требуется изменений графического интерфейса пользователя, достаточно написать соответствующий модуль ПМЗЗ. В текущей версии в качестве СУЗЗ используется сервис CREAM, широко используемый в существующих Грид-системах.
Клиент-серверное взаимодействие осуществляется двусторонней передачей текстовых данных с использованием стандарта JSON, как эффективного и наиболее легко реализуемого как на уровне графического интерфейса в среде Javascript, так и на уровне СУЗЗ в среде Perl. При доступе к функциям ПМЗЗ клиент должен передать в текстовом виде имя функции, вызов которой он хочет осуществить, а также объект аргумента функции в нотации JSON. Результат выполнения функции будет возвращён в виде объекта результата в нотации JSON.
Для формирования и запуска заданий пользователя (приложений) используются графические проблемно-ориентированные веб-интерфейсы (ПОВИ). Разработаны обобщённый веб-интерфейс для запуска произвольного задания, который предполагает создание скрипта для запуска самим пользователем и требует знания команд ППИ и навыков программирования на командном языке bash, а также ряд ПОВИ для прикладных программных пакетов (McStas, FullProf, Radav), использующих заранее подготовленные шаблоны и графические элементы, позволяющие выбрать параметры для запуска.
Каждое приложение (или подключаемый модуль прикладной программы - плагин) представляет собой динамически подключаемый модуль, реализованный на языке программирования JavaScript и предназначен для расширения возможностей графического интерфейса по работе с конкретными прикладными программами.
В целом при разработке веб-интерфейса использовался модульный подход и учитывались объектные свойства языка программирования JavaScript, что позволяет достаточно легко выполнять модификацию и развитие веб-интерфейса в части добавления новых ПОВИ или новых критериев поиска метаданных.
1.1.8Поддержка унифицированного формата экспериментальных данных
Проблема сохранения информации о результатах экспериментов в некотором унифицированном виде, который может быть использован различными программами обработки результатов от различных разработчиков и производителей достаточно широко известна. Одним из наиболее перспективных направлений для введения единого формата файлов для сохранения экспериментальных данных в области нейтронных и мюонных исследований является использование формата NeXus [1].
Остановимся на тех преимуществах использования этого формата, которые могут быть использованы при создании систем хранения данных и которые реализованы в разработанной модели.
Для процессов передачи и сохранения файлов собственный формат файлов, вообще говоря, значения не имеет, существенным является только протокол передачи данных. Однако использование унифицированного формата может быть использовано при формировании метаданных, связанных с файлом или набором данных. Для этого в схеме базы метаданных разработанной модели предусмотрены специальные таблицы, которые предназначены для сохранения дополнительных метаданных (параметров) для других объектов базы метаданных (файл, набор данных, программа обработки, образец, исследование).
В интерактивном режиме значения этих параметров, наряду с остальными метаданными, могут быть введены при помощи графического веб-интерфейса. В неинтерактивном (программном) режиме для программ сбора или программ обработки и анализа данных, если результирующий файл (файлы) сохраняются в формате NeXus, может быть использован подход, позволяющий автоматизировать занесение необходимых параметров.
В зависимости от типа программы (в конфигурационном файле для программы системы сбора данных или в шаблоне для ПОВИ для программы обработки) указываются имена параметров, значения которых должны быть импортированы из файла, а также тип объекта, с которым связаны эти параметры. При записи файла (файлов) в систему хранения, используя программные библиотеки общего доступа для работы с файлами в формате NeXus, необходимые значения могут быть прочитаны из файла, сохранены в виде JSON объекта и затем записаны в базу метаданных, используя команды ППИ сервиса интерфейса пользователя.
Благодаря использованию унифицированного формата становится возможным использовать единый программный интерфейс для извлечения значений параметров, при котором пользователю необходимо только знать, как именно установлены ссылки на отдельные структуры данных в файле, т.е. фактически имя поля данных (параметра) и имя группы, а не выяснять, где именно (в каком месте файла) данные сохранены в файле.
Следует отметить, что вопрос введения и использования единого формата NeXus для сохранения экспериментальных данных в области нейтронных исследований – это вопрос хоть и ближайшего, но всё-таки будущего. В настоящее время набор программных средств для обработки и анализа данных, которые поддерживают этот формат, достаточно ограничен. Однако в планах развития разработчиков многих широко используемых программных пакетов (DAVE [2], LAMP [3], MATLAB [4], OpenGDA [5]) уже присутствует или планируется присутствует поддержка этого или сходного с ним формата HDF5 для следующих версий своих продуктов.
|
