Импортозамещение шире, чем замена ПО

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

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

На текущий момент для обмена геологическими данными большое значение приобретает формат XML (eXtensible Markup Language) – расширяемый язык разметки, разработанный консорциумом W3C и ставший де-факто стандартом для представления структурированных данных в машиночитаемой форме [1]. В отличие от привычных для геолога форматов – текстовых документов (.doc, .pdf) или электронных таблиц (.xls) – XML не является «печатной» формой документа. Это язык, который описывает смысл и структуру данных, что делает их понятными не только человеку, но и любым информационным системам без потери смысла [2]. XML-схема (XSD) выполняет роль «паспорта» для такого файла: она описывает, какие данные должны присутствовать, в каком формате и с какими ограничениями. По сути, это машиночитаемый стандарт, который позволяет автоматически проверять корректность отчёта, выявлять пропущенные обязательные поля, контролировать допустимые диапазоны значений показателей и проверять согласованность данных [3].

Разрабатываемая в настоящее время Минстроем России XML-схема отчета о выполнении инженерных изысканий [4], опубликованная 9 апреля 2025, является именно таким «паспортом» отчета, который в скором времени будет принимать Главгосээкспертиза вместо традиционных документов в формате .pdf. Однако в схемах, которые уже приняты или только разрабатываются Минстроем и организациями экспертизы, названия всех сущностей даны на английском языке. Имена тегов, атрибутов, названия элементов – всё наследует англоязычную номенклатуру, что может быть критично для отрасли, где нормативная точность терминологии имеет большое значение.

Попытка «пересадить» терминологическую систему на английский язык неизбежно ведёт к упрощению, огрублению и потере нормативной точности. Например, классификационные признаки грунтов по ГОСТ 25100-2020 (крупнообломочные, песчаные, глинистые, степень влажности, число пластичности, показатель текучести) [5] не имеют прямых терминологических эквивалентов в международных классификациях и при переводе требуют либо описательных конструкций, либо использование транслитерации, что снижает однозначность восприятия.

Парадокс сложившейся ситуации заключается в том, что технические стандарты XML уже давно предоставляют полную возможность использовать родной язык в схемах данных, именах тегов и атрибутов. Спецификация допускает Unicode-символы в именах элементов, а язык описания схем XSD не накладывает ограничений на использование национальных алфавитов в именах типов, элементов и атрибутов [1]. Согласно синтаксису XML 1.0, имена могут содержать любые буквы из кодировки Unicode, что делает технически корректным применение кириллицы в тегах и атрибутах. Поэтому повсеместное использование латиницы и вариант считать английский язык единственно возможным, естественным и безальтернативным стандартом для ИТ-сферы можно оспорить. В области геологических и геофизических данных существуют примеры успешного использования национальных языков в форматах обмена: национальные геологические службы Китая, Германии и Франции активно применяют локализованные версии схем данных, адаптированные под собственную нормативную базу и традиции ведения геологической документации [6, 7].

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

• повышает точность и однозначность передачи данных за счёт использования терминологии, закреплённой в национальных стандартах (ГОСТ 25100-2020[5], СП 446.1325800.2019[8]);
• снижает риск ошибок интерпретации при передаче информации от исполнителя изысканий к экспертизе;
• сокращает языковой барьер для специалистов-геологов, не владеющих английским языком;
• создаёт основу для формирования национальной экосистемы машиночитаемых справочников и классификаторов инженерно-геологической информации;
• обеспечивает реальный, а не декларативный технологический суверенитет в области обмена инженерно-геологической информацией на всех этапах – от полевых работ до камеральной обработки и передачи в государственную экспертизу.

Язык схемы как часть инфраструктуры мышления

Язык, на котором написана цифровая модель геологической среды, – не просто техническая деталь. Это инструмент мышления, который формирует восприятие предметной области всеми участниками процесса: разработчиками XML-схем, инженерами-геологами, экспертами и проектировщиками. Смена языка в схеме данных меняет способ понимания геологической информации, а значит – и качество принимаемых решений.

Когда теги и атрибуты XML-схемы даны на английском языке, между реальным геологическим объектом (скважиной, полевым испытанием, лабораторным определением, выделенным ИГЭ,) и его цифровым описанием возникает переводческая прослойка. Эта прослойка работает как невидимый фильтр: инженер-геолог, формируя отчет, вынужден мысленно переводить привычные термины ГОСТ 25100-2020 [5] на английский (или транслит), а эксперт, читая этот XML-файл, должен выполнять обратный перевод, чтобы понять, какой именно показатель грунта записан в том или ином теге.

В узкоспециализированных областях, какой является инженерная геология, такая переводческая прослойка критична. Например, понятие «инженерно-геологический элемент» (ИГЭ) – это базовая единица геологического строения, повсеместно используемая в российских изысканиях [9]. В английском языке нет точного аналога: ближайшие варианты – soil layer, geological unit, engineering geological element – ни один не отражает всей полноты смысла, заложенного в нормативном определении. Или понятие «показатель текучести» для глинистых грунтов – это строго определённая величина, характеризующая консистенцию. Её англоязычный эквивалент liquidity index, принятый в международных классификациях (ASTM, BS) [10, 11], не совпадает ни по методике определения, ни по диапазонам значений, ни по классификационным границам. В результате при переводе теряется нормативная точность, а при обратном чтении возникает риск неверной интерпретации.

Родной язык в схеме делает цифровую модель геологической среды прозрачной для экспертов. Инженер-геолог видит в XML-файле теги «Скважина», «Инженерно-геологический_элемент», «Число_пластичности» и мгновенно понимает, о чём идёт речь. Ему не требуется мысленно выполнять обратный перевод, сверяться со словарём или вспоминать, что такое borehole и чем оно отличается от hole или well.

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

Технический фундамент: XML разрешает Unicode-имена

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

Стандарт XML 1.0, принятый консорциумом W3C в 1998 году и обновлённый в редакции 2000 года (Second Edition), прямо допускает использование символов Unicode в именах элементов и атрибутов [1]. Согласно синтаксическим правилам XML, имя элемента должно начинаться с буквы, знака подчёркивания (_) или двоеточия (:), а последующие символы могут включать буквы, цифры, дефисы, точки и некоторые другие знаки. При этом под «буквами» спецификация понимает и все буквы кириллицы [1]. Таким образом, тег <Скважина> является технически корректным ровно в той же степени, что и <Borehole> либо <Skvazhina>.

Практическая реализация этой возможности требует соблюдения двух условий.

Во-первых, корректной кодировки файла. Наиболее распространённой и рекомендуемой кодировкой для XML является UTF-8, которая полностью поддерживает все символы кириллицы. Подавляющее большинство современных текстовых редакторов, сред разработки и парсеров XML работают с UTF-8 без каких-либо ограничений. Допустимо также использование UTF-16 или других кодировок, поддерживающих Unicode, однако UTF-8 остаётся де-факто стандартом для обмена данными [12].

Во-вторых, соблюдения правил синтаксиса XML в части допустимых символов. Не все символы Unicode разрешены в именах – например, пробелы, знаки пунктуации, математические операторы и управляющие символы не допускаются. Однако все буквы кириллицы (А–Я, а–я, включая Ё/ё) относятся к категории «буквы» и могут быть использованы без ограничений. Русскоязычные названия могут содержать также цифры (кроме первой позиции), дефисы и подчёркивания. При этом разделение длинных названий рекомендуется выполнять символом подчёркивания или стилем «CamelCase»: <Инженерно_геологический_элемент> или <ИнженерноГеологическийЭлемент>. В разрабатываемых сегодня XML-схемах Минстроя России [4], а также схемах региональных экспертиз вместо этого используются англоязычные аналоги, что, создаёт риск потери нормативной точности при передаче данных.

В языке описания XML-схем (XSD) также отсутствуют ограничения на использование Unicode в именах типов, элементов и атрибутов. Спецификация XSD 1.1 опирается на правила именования XML 1.0 и не вводит дополнительных ограничений по набору символов [13]. Это означает, что разработчик XSD-схемы может свободно использовать кириллицу при определении типов, непосредственно соответствующих терминологии ГОСТ 25100-2020 [5].

Таким образом, переход на русскоязычные теги и атрибуты в XML-схемах для инженерно-геологических изысканий не требует изменения стандартов, разработки новых спецификаций или модификации существующих парсеров XML. Всё необходимое уже заложено в базовых спецификациях XML и XSD [1, 13]. Достаточно изменить подход к проектированию схем – перестать воспроизводить англоязычную номенклатуру по инерции и начать использовать терминологию, закреплённую в национальных стандартах ГОСТ 25100-2020 [5], СП 446.1325800.2019 [8] и ГОСТ 20522-2012 [9].

Нормативно-технические документы РФ как источники терминов для цифровой модели геологической среды

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

ГОСТ 25100-2020 [5] задаёт фундаментальную классификацию и терминологию грунтов. Документ устанавливает иерархическую систему: классы, подклассы, типы, виды и разновидности грунтов.

СП 446.1325800.2019 [8] определяет инженерно-геологический элемент (ИГЭ) как основную грунтовую единицу инженерно-геологической модели [8, п. 3.5]. Документ регламентирует набор свойств и параметров грунтов, подлежащих определению в ходе изысканий, а также устанавливает требования к методам полевых и лабораторных исследований. Именно этот документ поставляет термины для описания процесса изысканий: виды точек изысканий, методы опробования, способы испытаний, требования к документации.

ГОСТ 20522-2012 [9] устанавливает методы статистической обработки результатов определения характеристик грунтов. Используется для расчета нормативных и расчетных значений, к которым отсылает СП 446.1325800.2019 [8]. В XML-схеме его термины нужны для описания результатов обработки

СП 47.13330 [14] определяет основные положения всех инженерных изысканий для строительства и определяет состав отчета по инженерно-геологическим изысканиям.

Примеры тэгов, основанных на действующих нормативно-технических документах приведены ниже:

Преимущества нормативного подхода:

1. Однозначность интерпретации.
2. Юридическая чистота.
3. Сокращение языкового барьера.

Таким образом, использование терминологии из ГОСТ и СП [5, 8, 9, 14] в качестве источников для XML-схем данных инженерно-геологических изысканий является не просто логичным, а нормативно-обоснованным решением. Данный подход минимизирует риски разночтений при интеграции данных изысканий в общую цифровую модель объекта капитального строительства и создаёт основу для формирования национальной экосистемы машиночитаемых справочников и классификаторов инженерно-геологической информации.

Двухслойная идентификация: тег и код

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

Первый слой – человекочитаемый тег (русскоязычный) – это основной тег XML, написанный на русском языке с использованием терминологии из действующих нормативно-технических документов [5, 8, 9, 14]. Этот тег предназначен для человека (инженера-геолога, эксперта, разработчика), который читает XML-файл или проект XML-схемы. Технически русскоязычный тег должен удовлетворять правилам синтаксиса XML [1]: начинаться с буквы кириллицы или знака подчёркивания, не содержать пробелов (заменяются на подчёркивания), не содержать управляющих символов и знаков пунктуации, кроме дефиса и подчёркивания.

Второй слой: уникальный машинный код сущности (код_нси (нси – нормативно справочная информация) приведен в примере ниже), идентификатор, не зависящий от языка. Такой код может быть числовым или буквенно-цифровым (например, из классификаторов или отраслевых реестров нормативно-справочной информации). Этот слой предназначен для машинной обработки: автоматического сопоставления данных, поиска в базах данных, интеграции с внешними системами, не поддерживающими кириллицу. Машинный код обеспечивает высокоскоростную автоматизированную обработку машинами, базами данных и алгоритмами валидации, однозначную идентификацию сущности независимо от языка тега, возможность автоматического сопоставления данных при интеграции с внешними системами и совместимость с международными форматами, ожидающими числовые или буквенно-цифровые идентификаторы. Этот код остаётся абсолютно инвариантным (неизменным) при любых исправлениях орфографии, опечатках или точечных корректировках терминологии в нормативно-технической документации.

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

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

Публичный реестр справочно-нормативной информации и классификаторов как центральный элемент экосистемы

Остаётся вопрос, как организовать централизованное управление этой терминологией, чтобы все участники процесса – от изыскателей до разработчиков ПО – использовали единые, актуальные и легитимные наименования, коды и описания.

Предлагается вынести всю справочно-нормативную информацию в публичный реестр справочно-нормативной информации и классификаторов. Доступ к этому реестру должен осуществляться через единый программный интерфейс (API), что обеспечит автоматизированное взаимодействие с информационными системами. При таком подходе структура самого XML-документа остаётся максимально компактной и легковесной, освобождается от избыточных метаданных. Вместо того чтобы хранить внутри каждого отчёта полные описания терминов, ссылки на нормативы и другую техническую информацию, XML-файл будет содержать только два идентификатора: русскоязычный тег (для читаемости человеком) и числовой код (для машинной обработки). Всё остальное – нормативное определение, физический смысл, ассоциативные связи, история изменений – должно храниться централизованно в публичном реестре.

Через поисковый запрос к публичному реестру (доступному через API) информационная система или пользователь могут динамически получать исчерпывающий пакет метаданных для каждого термина:

1. Валидный транслит по ГОСТ 7.79-2000 (адаптированный под синтаксические ограничения XML-схем) – для обратной совместимости с устаревшими системами, не поддерживающими кириллицу.
2. Официальный перевод на иностранные языки (для международного взаимодействия) – позволяет экспортировать данные в форматы, требуемые зарубежными партнёрами или международными консорциумами. При этом языковой слой и правила трансляции могут формироваться абсолютно обособленно: как централизованно для всей отрасли или конкретного ведомства, так и точечно – под требования конкретных зарубежных сторон и контрагентов в рамках отдельных международных проектов.
3. Прямую ссылку на действующий нормативно-технический документ (ГОСТ, СП) с указанием конкретного пункта или таблицы – для обеспечения юридической обоснованность каждого термина.
4. Полное официальное определение термина и его физический, пространственный, технологический и другой смысл для исключения разночтения при интерпретации.
5. Ассоциативные связи: синонимы, родительские/дочерние классы и связанные параметры для автоматической проверки согласованности данных.
6. Историю изменений (версионирование) термина при обновлении стандартов для прослеживаемости данных и понимания, по какой версии нормативного документа формировался отчёт.
7. Короткий (сокращённый) тег.

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

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

Гибридный подход к открытым стандартам: IFC и XML

IFC (Industry Foundation Classes) является основным открытым форматом обмена информационными моделями в строительной отрасли. В Российской Федерации этот статус закреплён на нормативном уровне, в СП 333.1325800.2017 [15]. Согласно требованиям региональных экспертиз, например СПб ГАУ «ЦГЭ» [16], файлы информационных моделей результатов инженерных изысканий должны быть представлены в формате IFC. Формирование информационной модели в IFC становится обязательным требованием при передаче проектной документации в государственную экспертизу.

Полная русификация структуры самого стандарта IFC невозможна, т.к. имена классов, атрибутов и отношений в IFC жёстко зафиксированы в спецификации, разработанной международным консорциумом buildingSMART, и не могут быть изменены в национальной реализации без нарушения совместимости с другими ТИМ-системами.

Версия стандарта IFC (IFC 4.3), опубликованная buildingSMART International в 2022 году содержат необходимые геометрические и пространственные классы для описания геологических объектов. В спецификацию были добавлены специализированные сущности для геотехнических данных [17]: IfcBorehole – скважина геологическая/инженерно-геологическая, представляющая собой линейную геологическую или геотехническую модель, интерпретацию геологического разреза по данным бурения, IfcGeotechnicalStratum – геологический слой (стратиграфическая единица), моделируемый либо поверхностями (surface‑моделирование, без учёта внутреннего объёма), либо как набора объёмных ячеек (вокселей) в трёхмерной сетке (объемное voxel‑моделирование), IfcGeomodel – геологическая или геотехническая модель, агрегирующая все геологические элементы, IfcGeoslice – геологический разрез.

Версии программ для ТИМ и САПР до 2022 г. с IFC 4.3 не совместимы, поэтому для обмена геологическими данными необходимо использовать более ранние версии формата IFC, например, IFC 2×3, поддерживаемые большинством систем. При применении IFC 2×3 все инженерно-геологические сущности, для которых ещё не выделено специализированных классов, определяются через обобщённый класс IfcGeographicElement. Применение этого класса для геологических объектов технически реализуемо через механизм классификационной ассоциации: сущность IfcGeographicElement может быть дополнительно квалифицирована путём ссылки на внешний каталог признаков (feature catalog), где через атрибуты Catalog, Identity и ElementName задаётся принадлежность к конкретному типу инженерно-геологического объекта в соответствии с российскими нормативными документами.

Но наиболее оптимальный способ передачи результатов инженерно-геологических изысканий сочетанием двух обменных форматов – IFC и XML, котором геометрическая компонента моделей геологического строения передается в формате IFC, а сложная семантика, включающая количественные и качественные параметры геологического строения, описания методов получения данных, ссылки на нормативные документы – в XML-формате. Такое разделение позволяет использовать сильные стороны обеих технологий и в настоящее время разрабатывается в Московской государственной экспертизе.

Заключение

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

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

Техническая возможность использования кириллицы заложена в спецификациях XML 1.0 и XSD, поддерживающих Unicode с конца 1990-х годов. Отказ от русскоязычных тегов сегодня обусловлен не техническими ограничениями, а инерцией разработки. Переход на теги вида <инженерно-геологический_элемент>, <число_пластичности> или <статическое_зондирование> делает цифровые отчеты прозрачными для специалистов, исключает необходимость мысленного перевода терминов и обеспечивает юридическую чистоту данных, опирающуюся на действующие государственные стандарты.

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

В контексте интеграции с ТИМ-инфраструктурой оптимальным признается гибридный подход. Геометрическая компонента моделей должна передаваться в формате IFC, тогда как сложная семантика, количественные параметры грунтов и методы испытаний – в специализированных русскоязычных XML-схемах.

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

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