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

Д. В. Медведев, В. И. Пронин, А. А. Ислам // Человек. Общество. Инклюзия / Human. Society. Inclusion Том 14 (2023). № 4-2 / Volume 14 (2023). Issue 4-2

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

Среда общих данных (СОД) - это программно-технический комплекс для совместной работы всех участников проекта с информационными моделями на всех стадиях жизненного цикла. [1]

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

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

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

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

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

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

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

ГОСТ Р 57311-2016 «Моделирование информационное в строительстве. Требования к эксплуатационной документации объектов завершенного строительства» прямо указывает, что СОД должна обеспечивать возможность реализации упорядоченного безопасного хранения информации в составе ЭИМ в течение всего жизненного цикла актива. [2]

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

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

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

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

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

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

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

Доступ к СОД должен быть гарантирован в любом современном браузере, на любой мобильной/стационарной платформе. [3]

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

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

Как нельзя лучше для этого подходит организация СОД на базе кластера серверов, использование которого позволяет масштабировать системы быстро, выгодно и помогает обеспечить стабильную работу системы, независимо от нагрузки на нее. [4]

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

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

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

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

Очень хорошим решением в этом вопросе является, опять же, облачный сервис, web-интерфейс, встроенные просмотрщики документов и 3D-моделей.

Функционал СОД, при этом, не должен быть излишним - не все проектные процессы должны перейти в СОД. Часть из них относится к CAD-системам, к системам для работы со сметами, поставками и прочим. СОД покрывает только те рабочие процессы, которые завязаны на коллективное взаимодействие участников.

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

Ниже представлен список таких документов:

«Моделирование информационное в строительстве». Требования к эксплуатационной документации объектов завершенного строительства

«Система стандартов информационного моделирования зданий и сооружений»

«Информационная модель объекта капитального строительства»

«Организация и перевод в электронный вид информации о зданиях и объектах гражданского строительства, включая информационное моделирование зданий (Building Information Modeling, BIM) - Управление информацией с использованием информационного моделирования зданий» (Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) - Information management using building information modelling)

«Информационное моделирование в строительстве. Правила разработки планов проектов, реализуемых с применением технологии информационного моделирования»

«Информационное моделирование в строительстве. Правила описания компонентов информационной модели»

«Правила обмена между информационными моделями объектов и моделями, используемыми в программных комплексах»

«Информационное моделирование в строительстве. Правила формирования информационной модели объектов на различных стадиях жизненного цикла»

Отдельно отметим серию государственных стандартов ГОСТ Р 10.00.000 «Единая система информационного моделирования», которые готовятся к выпуску и уже имеют предварительные версии. Эту серию рассматривают как содержащую основополагающие требования к процессам информационного моделирования и к СОД в том числе. Ожидается, что все положения будут описаны именно в этих ГОСТах.

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

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

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

Есть ряд государственных структур, которые проверяют программные продукты на предмет их соответствия высоким требованиям: ФСТЭК России, Минцифры России, Минобороны России. В рамках них были созданы службы, которые проводят исследования продуктов и их тестирование. По их итогам продукты включаются в реестр российский программных продуктов и в перечни рекомендованных к импортозамещению.

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

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

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

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

Использование СОД должно приводить к стандартизации производственных процессов.

Методология, которая заложена в СОД, должна позволять создавать и применять регламенты работы внутри проекта, а также распределять «зоны» работы в системе.

Основы этой методологии заложены в серии международных стандартов ISO 16950. Сама методология является универсальной, что позволит объединять работу специалистов через различные системы, если системы поддерживают эту методологию.

Соответственно, предъявляя требования по стандартизации процессов к СОД, заказчик создает себе “задел на будущее”, обеспечивая возможность интеграции в другими информационными системами.

Это требование противостоит “индивидуальным” системам для организации СОД, в которых реализуется частный бизнес-процесс определенной компании. Такие системы трудно интегрировать в другими системами.

Среда общих данных, как система и как методология, пришла на смену сетевому диску. Главные недостатки организации хранения информации по проекту ОКС через сетевые диски заключается в отсутствии определенности информации. Это значит, что специалисты хорошо ориентируются в “своей” области диска, там где они сами размещали свои файлы. Однако, выходя за эту зону, им становится затруднительно определить где и что находится.

Определенность информации - объемное требование к СОД, которое включает в себя аспекты:

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

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

Также в СОД фиксируются все события, происходящие внутри между участниками проекта.

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

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

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

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

В более широком понимании СОД должна предоставлять специалистам инструменты для управления развитием проекта (система отчетности, согласования, задания и т.д.)

Пример организации потока информации представлен в самой методологии СОД.

Путь развития документа, согласно методологии СОД (см. рис. 2), позволяет работать, в итоге, только с актуальной информацией и быть уверенным, что она актуальна.

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

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

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

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

В самой СОД разрозненная информация превращается в информационные модели ОКС. [1]

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

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

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

В конечном итоге СОД должна иметь потенциал для интеграций с любой системой, в том числе государственными информационными системами. [5]

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

API (application programming interface) - это программный интерфейс, то есть описание способов взаимодействия одной компьютерной программы с другими. [6]

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

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

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

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

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

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

В статье рассмотрены требования, предъявляемые ко всем программным продуктам класса СОД.

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

Подробнее о процессе выбора СОД мы писали в статье «Организация процесса выбора среды общих данных для проектов объектов капитального строительства». [7] В ней явно показано как проводить этот процесс и на что стоит обратить внимание для успешного выбора инструмента для СОД.

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

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

Важно отметить, что необходимо стремиться удовлетворять этим требованиям к СОД, они универсальны и применимы для любых стран и любых проектов. Это объективные требования, сформированные на основе общемировой практики и на основе нормативных документов.

[1] Пронин, В. И. Трактовка понятий «технологии информационного моделирования» (ТИМ) и «среда общих данных» (СОД) / В. И. Пронин, Д. В. Медведев // Человек. Общество. Инклюзия. – 2023. – № 2(54). – С. 140-146. – EDN YXDIPD.

[2] ГОСТ Р 57311-2016 «Моделирование информационное в строительстве. Требования к эксплуатационной документации объектов завершенного строительства»

[3] Как сократить время при повторных проверках проектной документации, используя среду общих данных и инструмент сравнения чертежей / А.А. Ислам, В.И. Пронин, Д.В. Медведев, П.А. Остапенко. ООО «Ингипро». 2023 г. https://vk.com/@ingipro-kak-sokratit-vremya-pri-povtornyh-proverkah-proektnoi-dokume Дата обращения 26.11.2023 г.

[4] Интервью с техническим директором ООО«Ингипро», https://vk.com/@-144683089-7845 Дата обращения 26.11.2023 г.

[5] Медведев, Д. В. Уровни развития сред общих данных строительных проектов / Д. В. Медведев, В. И. Пронин // Экономика: вчера, сегодня, завтра. – 2023. – Т. 13, № 5-1. – С. 434-445. – DOI 10.34670/AR.2023.59.18.018. – EDN FVJNAG.

[6] API — Википедияhttps://ru.wikipedia.org/wiki/API#cite_note-1 Дата обращения 26.11.2023 г.

[7] Пронин, В. И. Организация процесса выбора среды общих данных для проектов объектов капитального строительства / В. И. Пронин // Экономика: вчера, сегодня, завтра. – 2023. – Т. 13, № 5-1. – С. 220-230. – DOI 10.34670/AR.2023.54.86.078. – EDN IMVWNL.

[8] Пункт 10.3 Градостроительного Кодекса РФ.

[9] СП 333.1325800.2020 «Информационное моделирование в строительстве. Правила формирования информационной модели объектов на различных стадиях жизненного цикла»

[10] ГОСТ Р 10.00.00.00−2023. «Единая система информационного моделирования. Основные положения»

[11] СП 471.1325800.2019. «Информационное моделирование в строительстве. Контроль качества производства строительных работ»

[12] ГОСТ Р 10.0.01-2018. «Система стандартов информационного моделирования зданий и сооружений. Термины и определения»

[13] ГОСТ Р 57311-2016. «Моделирование информационное в строительстве». Требования к эксплуатационной документации объектов завершенного строительства

[14] СП 404.1325800.2018. «Информационное моделирование в строительстве. Правила разработки планов проектов, реализуемых с применением технологии информационного моделирования»

[15] СП 328.1325800.2020. «Информационное моделирование в строительстве. Правила описания компонентов информационной модели»

[16] СП 331.1325800.2017. «Правила обмена между информационными моделями объектов и моделями, используемыми в программных комплексах»

Больше интересной информации в Telegram-канале «ИНГИПРО»

#bim #тим #cde #сод #строительство #проектирование #технологии #информационноемоделирование #средаобщихданных