Среда общих данных как инструмент заказчика Текст научной статьи по специальности «Компьютерные и информационные науки»

Среда общих данных как инструмент заказчика

DOI: 10.17273/CADGIS.2019.2.2

Пискунов М.В., начальник отдела информатизации ООО «Автодор-Инжиниринг» (г. Москва)

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

Введение

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

Бесконечные потоки информации стекаются в неё отовсюду, на каждом этапе работы создаётся и используется огромное количество данных. Однако данных самих по себе при этом недостаточно: необходим дополнительный инструмент — основной регулятор всех процессов, способный управлять этим необъятным пото-

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

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

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

Анализируя вышесказанное, можно прийти к выводу, что в сфере строительства автомобильных дорог функции такого инструмента, объединяющего все элементы сложной системы воедино, выполняет заказчик. Именно он управляет всеми участниками процесса строительства и главным ресурсом — финансами. Именно он определяет основные направления инвестирования и формирует технические задания на проектирование, строительство и эксплуатацию участков автомобильных дорог, рассматривает и согласовывает различную документацию, производит проверку выполненных работ на предмет соответствия действующим нормам и правилам и производит их приёмку и оплату. Конкретные функциональные задачи решают уже другие участники процесса, такие как проектировщик, подрядчик, строительный контроль, авторский надзор и множество субподрядных организаций по всем направлениям. А роль некоего общего банка данных играет автоматизированная информационная система для организации дорожных работ. Компьютерная программа. Инструмент, с помощью которого все участники могут автоматизировать свои бизнес-процессы и взаимодействовать друг с другом в рамках единой информационной среды — среды общих данных (СОД) [1].

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

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

Ответ на такой вопрос кажется парадоксальным: почти ничего. Разве что стандартные системы электронного документооборота. Но как же такое возможно?

Неужели у заказчика отсутствуют функциональные задачи, которые необходимо автоматизировать? Неужели подход XX века по работе с бумажными документами и стандартными офисными программами полностью обеспечивает потребности заказчика при управлении проектами строительства автомобильных дорог в современных условиях? Да и как при помощи таких инструментов работать с информационными 3D-моделями, которые уже используются во всём мире и в сфере строительства автомобильных дорог начинают применяться и в нашей стране?

Вот тут мы подходим к главным ответам на эти вопросы.

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

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

Какой же существует выход из этой ситуации? Какие основные задачи стоят перед заказчиком на стадии строительства объекта, которые подлежат автоматизации, включая механизмы использования В1М-моделей? То есть каковы основные требования к такой системе или на что должна быть способна среда общих данных, которая нужна заказчику? Рассмотрим ниже задачи заказчика, которые требуется решить силами автоматизированной среды общих данных.

Требования к среде общих данных

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

2. Предоставление доступа к необходимой информации всем участни-

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

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

4. Автоматизация поступления информации в систему путём использования на рабочих органах дорожно-строительной техники ГЛОНАСС-датчиков, обеспечивающих автоматическое управление и контроль положения рабочего органа техники и одновременно передающих данные об объёмах выполненных работ в систему в режиме реального времени.

5. Автоматизация проверки, рассмотрения и согласования документов всеми участниками с использованием специализированного инструментария (автоматизированное сравнение чертежей, 3D-моделей, ведомостей, коллегиальное рассмотрение документов с использованием обычного и голосового чатов, акцептирование документов с использованием электронно-цифровой подписи (ЭЦП), поддержка штрихкодов и т.п.).

6. Автоматизация работы с 3D-BIM-моделью, обеспечивающая возможность привязки атрибутивных данных (проектной, рабочей и исполнительной документации, предписаний, отчётов, фото-и видеоматериалов, комментариев и т.п.) к каждому элементу 3D-модели с пометкой этого элемента (изменением его статуса).

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

на объекте строительства с привязкой их к ГЛОНАСС-координатам и 3D-модели, а также возможность автоматизированного формирования ежемесячного отчётов строительного контроля и авторского надзора.

8. Автоматизация приёмки и учёта выполненных работ с использованием современных средств контроля, в том числе с использованием беспилотных летательных аппаратов с ГЛОНАСС-оборудованием для лазерной и аэрофотосъёмки.

9. Возможность интеграции и автоматизированного обмена данными между системами финансового планирования заказчика в части предоставления исходных данных об объёмах и стоимости фактически выполненных работ вне зависимости от того, приняты они заказчиком или нет. Также СОД-система может являться одним из основных источников данных для так называемого «монитора руководителя» — системы, которая помогает руководителю принимать оптимальные управленческие решения на основе информации о реальной ситуации на объектах строительства.

10. Возможность интеграции и автоматизированного обмена данными между САПР и ГИС, а также системами подрядчика, который может использовать информацию СОД-системы для корректировки своих производственных задач, что, в свою очередь, важно для корректировки общего плана строительства и уточнения 4D-BIM-модели, увязанной с графиком производства работ подрядной организации.

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

Проанализируем преимущества и недостатки этих систем в применении к СОД, а также выясним, почему

использование их для выполнения СОД-задач не является оптимальным решением.

Плюсы и минусы СЭД, САПР и ГИС для решения задач среды общих данных

1. СЭД.

Плюсы: О

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

- Возможность согласования документов.

Минусы: О

- Отсутствие возможности работы с 3D- и 4D-BIM-моделями.

- Отсутствие возможности работы с данными ГЛОНАСС-оборудования.

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

2. САПР.

Плюсы: О

- Возможность работы с 3D-BIM-моделями.

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

- Возможность работы с данными ГЛОНАСС-оборудования.

Минусы: О

- Отсутствие возможности работы с 4D-BIM-моделями.

- Отсутствие возможности согласования документов.

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

3. ГИС.

Плюсы: О

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

- Возможность работы с данными ГЛОНАСС-оборудования.

Минусы: О

- Отсутствие возможности работы с 3D- и 4D-BIM-моделями (3D-ГИС-модель строится по другим принципам).

- Отсутствие возможности согласования документов.

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

Из этого нам становится понятно, что наиболее близкой по функционалу к требуемой заказчику СОД-системе является САПР. Почему же не доработать её и не использовать как полноценную СОД-систему?

Давайте разберём в этом плане недостатки САПР.

1. Избыточный функционал.

Система автоматизированного проектирования содержит функционал, необходимый для создания и редактирования чертежей, а также проведения расчётов как на проектной стадии, так и на стадии разработки рабочей документации, в том числе для построения цифровой 3D-модели автомобильной дороги. Но дело в том, что этот функционал совершенно не нужен заказчику! Эту работу выполняет для него проектировщик либо по отдельному договору, либо по договору субподряда с подрядчиком. Более того, у заказчика отсутствует необходимость проверки за проектировщиком его решений, расчётов и т.д., так как в соответствии с договором вся ответственность за некачественное проектирование возложена на проектировщика и подрядчика (в случае работы проектировщика по договору субподряда с подрядчиком). Задача заказчика состоит в проверке соответствия разработанной рабочей документации проектной документации, на которую имеется положительное заключение ФАУ «Главгосэкспертиза России». Но для этого как раз нужны инструменты по автоматизированному сравнению чертежей, 3D-моделей и ведомостей, а не инструменты для их создания и редактирования. И, самое главное, зачем заказчику переплачивать за этот избыточный САПР-функционал, если он ему не требуется в работе?

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

2. Громоздкость системы.

Теоретически можно создать единую информационную систему, которая объединила бы в себе САПР-, СОД- и ГИС-функционал. Некоего информационного монстра для работы на всех стадиях жизненного цикла автомобильной дороги.

Но такое решение также имеет ряд недостатков.

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

• Во-вторых, даже если финансирование найдётся, кто это всё будет потом покупать? Заказчику, строительному контролю, авторскому надзору не интересна САПР. Строителям не интересны САПР и ГИС. Проектировщикам не интересны ГИС и СОД-системы. Эксплуатации не нужны САПР и СОД. То есть теряется сам смысл такой разработки.

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

• В-третьих, как обеспечить информационную безопасность и саму целостность огромного массива данных? Такая система потребует гигантских серверных мощностей. А учитывая то, что возникновение ошибок в любой программе — это реальность, такой подход может привести к постоянному подвиса-нию всей системы из-за ошибок: то в САПР-блоке, то в СОД-блоке, то в ГИС-блоке системы. В результате чего абсолютно все участники процесса строительства автомобильной дороги будут лишены возможности нормально работать в системе до момента очередного восстановления её работоспособности.

Проблемы создания отдельного СОД-модуля

Что же является краеугольным камнем в создании отдельного СОД-модуля, программы, которая бы обеспечивала возможность автоматизации основных задач заказчика? Почему её до сих пор не существует? В чём же причина? Ответ — отсутствие полноценного открытого формата обмена данными, принятого всеми

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

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

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

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

ных систем различных разработчиков при условии сохранения возможности выполнения своих функциональных задач каждой из таких систем в полном объёме. Формат IFC не позволяет передавать достаточное количество атрибутивных данных, кроме того, текущая версия IFC больше подходит для выполнения задач промышленного и гражданского строительства, чем для задач дорожного строительства. XML-формат имеет очень широкие возможности, но его нужно приспосабливать именно под задачи дорожников, отдельно адаптируя под сферу работы с цифровой моделью местности, наподобие возможностей существующих форматов LandXML и LAS. Имеются проблемы потери данных и возникновения коллизий при экспорте/импорте существующих открытых форматов из-за того, что различные САПР разрабатываются на разных технологических платформах и имеют разные требования к обработке данных.

Все эти проблемы известны дорожникам, и определённая работа по стандартизации и унификации ведётся практически на всех уровнях. Предстоит разработка как документов, устанавливающих требования к созданию BIM-модели и работе с ней на стадиях проектирования и строительства, так и документов, устанавливающих требования к открытым форматам данных и различных классификаторов, определяющих единый подход к структурированию элементов автомобильной дороги, а также библиотек материалов, конструкций, технологий произвсдства и требований к качеству готовой продукции [2,3,4].

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

Впервые термин «среда общих данных» (СОД, англ. CDE — Common Data Environment) был введён в разработанном в Великобритании наиболее популярном стандарте в сфере информационного моделирования BS 1192:2007 [5,6]. Термин СОД быстро вошёл в лексикон всех систем, поддерживаю-

Среда общих данных (CDE)

Просмотр, проверка и утверждение

Передача всех версий проектных данных

Рис. 1. Структура областей среды общих данных

щих концепцию Building Information Modeling (BIM) — информационного моделирования зданий (рис. 1).

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

Потребности заказчика вышеуказанной концепцией не учитывались, а они существуют. Ещё раз перечислим основные из них.

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

2. Загрузка и использование в системе всех типов инженерно-технической документации, необходимой на стадии строительства объекта: проектной, рабочей и исполнительной документации, предписаний, отчётов, комментариев, фото- и видеоматериалов, проектов производства работ, проектов производства геодезических работ, схем, расчётов, ведомостей, смет, нормативной документации и т.п., с её привязкой к элементам BIM-модели и поддержкой версионно-сти файлов.

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

4. Автоматизация контроля и учёта объёмов выполненных работ с помощью ГЛОНАСС-оборудования, установленного на дорожно-стро-

ОБЩИЕ ДАННЫЕ

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

Область взаимодействия Заказчика

^ Одобрено Заказчиком ОПУБЛИКОВАННЫЕ ДАННЫЕ

Скоординированные (согласованные) и утверждённые выходные проектные данные, доступные всем участникам проекта (включая все внешние организации)

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

Заключение

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

№С-формата, но не стоит забывать, что возможности этого формата ограничены и в будущем это может превратиться в своего рода препятствие для дальнейшего развития В1М-технологий в России, в сфере дорожного строительства [3, 7].

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

После ввода объекта строительства в эксплуатацию мы получаем

в СОД-системе 3D-модель объекта, элементы которой соответствуют своим фактическим пространственным положениям с привязкой фактической атрибутивной информации об используемых материалах, технологиях и качестве готовых конструктивов. Эта цифровая модель и вся атрибутивная информация перегружается в ГИС и используется уже на стадии эксплуатации. При этом для того, чтобы не перегружать ГИС большим объёмом дублирующих данных, информация может храниться в ней ссылочно на СОД-архив.

Такой подход позволяет достичь следующих результатов.

1. Лишняя информация САПР (неутверждённые чертежи, наработки, расчёты и т.п.) не хранится в СОД-системе, так как не требуется на стадии строительства. Эта информация остаётся в САПР проектировщика и используется им при необходимости.

2. Большой объём информации ГИС может храниться в СОД-архиве и указываться ссылочно, в целях снижения нагрузки на ГИС.

3. Весь основной инструментарий по автоматизации рассмотрения и согласования документов, а также все версии файлов, история их рассмотрения и согласования содержатся в СОД-системе, которая контролируется и используется заказчиком на всех стадиях жизненного цикла автомобильной дороги.

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

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

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

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

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

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

То есть СОД-система в этом случае выполняет роль информационного каркаса всей системы управления организацией дорожных работ на всех этапах жизненного цикла автомобильной дороги, которая позволяет заказчику максимально автоматизировать производственные бизнес-процессы всех участников проектирования, строительства и эксплуатации автомобильных дорог в соответствии с российским национальным проектом «Цифровая экономика». ü

Литература:

1. Скворцов А.В., Бойков В.Н. Общая среда данных как ключевой элемент информационного моделирования автомобильных дорог // САПР и ГИС автомобильных дорог. 2015. № 2(5). С. 37-41. DOI: 10.17273/ CADGIS.2015.2.6

2. Скворцов А.В. Нормативно-техническое обеспечение BIM автомобильных дорог // САПР и ГИС автомобильных дорог. 2014. № 2(3). С. 22-32. DOI: 10.17273/ CADGIS.2014.2.4

3. Скворцов А.В. Модели данных BIM для инфраструктуры // САПР и ГИС автомобильных дорог. 2015. № 1(4). С. 16-23. DOI: 10.17273/CADGIS.2015.1.2

4. Сарычев Д.С., Скворцов А.В. Элементы моделей автомобильных дорог и уровни проработки как основа требований к информационным моделям // САПР

и ГИС автомобильных дорог. 2015. № 1(4). С. 30-36. DOI: 10.17273/CADGIS.2015.1.4

5. BS 1192:2007. Collaborative production of architectural, engineering and construction information — Code of practice. 2008. 38 p.

6. Скворцов А.В. Обзор международной нормативной базы в сфере BIM // САПР и ГИС автомобильных дорог. 2016. № 2(7). С. 4-48. DOI: 10.17273/CADGIS.2016.2.1

7. Скворцов А.В. Стандарты для обмена данными // Автомобильные дороги. 2015. № 2. С. 84-89.

Рис. 2. СОД-система,

используемая

в качестве

основного

хранилища

информации