ЭКНИС

Схема S-63

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

Статья подробно рассматривает схему защиты и распространения данных IHO и АСО ЦКИ ВМФ, установку базовых наборов ЭНК и автоматическую корректуру. Схемы защиты ЭНК частных коллекций могут отличаться от принятой в IHO и не рассматриваются в данной статье.

Содержание

- Схема распространения данных

- Сервер данных

- ОЕМ

- ЭКНС

- Альтернативная схема распространения данных

- Различия версий 1.1 и 1.2.1 стандарта S-63

- Проблема производителей ЭНК

- Проблема поставщиков ЭНК

- Проблема тех кто вне схемы

- Заключение

- Использованная литература

Схема распространения данных 

Схема распространения данных направлена на обеспечение защиты данных и прозрачности распространения электронных навигационных карт (ЭНК) и обновлений (корректуры) к ним.

Схема описана в изображении [1]. Документ содержит описание схемы и её элементов.

В общем виде схема распространения выглядит следующим образом

   Рисунок 1: Структура схемы распространения и защиты данных IHO S-63

Администратор схемы (Scheme Administrator, SA) может быть только один, выполняет аутентификацию участников схемы. Все серверы данных (Data Servers) и производители систем (OEM) должны подать заявку SA для участия в схеме и после одобрения получают уникальную информацию, предназначенную только для них.

Заявка подаётся после прохождения самотестирования в соответствии с изображением [2].

Клиенты данных (Data Clients) — это клиенты серверов данных и OEM — в нашем случае электронные картографические навигационные информационные системы (ЭКНИС), радиолокационные станции (РЛС) и иные системы отображения картографических данных.

Серверы данных предоставляют услуги поставки данных по доступным каналам связи.

OEM (производители оборудования) поставляет оборудование для расшифровки и отображения этих данных.

Рассмотрим, кратко, функции каждого элемента схемы.

Сервер данных

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

Сервер данных регистрируется в IHO (International Hydrographic Organization). Для регистрации в IHO сервер данных вырабатывает самоподписанный ключ (ssk), который отправляется в Администратору Схемы (АС). При регистрации серверу присваивается ID-сервера и отправляется сертификат, представляющий себя ssk, подписанный закрытой частью корневого сертификата АС.

ЭНК поступают в сервер данных от поставщиков (производителей) ЭНК.

Данные хранятся в сервере данных в зашифрованном виде. Шифрование данных происходит на основании пары случайно сгенерированных сервером 40-битных ключей (ECK1 и ECK2). Сервер данных должен обеспечивать уникальность действующих ключей шифрования в пределах всей базы данных ЭНК.

Базовая ячейка, с расширением 000 и все последующие обновления к ней с расширениями от 001 до 999 шифруются одной и той же парой ключей. Внешние файлы: текстовые, графические — не шифруются.

Ключ ECK1 имеет ограничения по сроку действия. Если получен зашифрованный набор срок действия ECK1 в котором истёк, то ячейка расшифровывается ECK2. На сервере выполняется сдвиг ключей: исключается из БД ЭНК ECK1, ЕСК2 становится ЕСК1 и ему присваивается дата окончания действия, вырабатывается новый ЕСК2. ЭНК, для которых был выполнен сдвиг ключей, шифруются под новую пару ЕСК.

АС регулярно, по мере обновления, рассылает всем серверам данных список OEM, содержащий M_KEY и M_ID всех ОЕМов. M_ID (идентификатор производителя) и M_KEY (ключ производителя — секретный ключ) — уникальная пара ключей, присваиваемая производителю администратором схемы.

При заказе ЭНК, сервер данных получает от Клиента Лицензию Пользователя (User Permit). User Permit представляет собой зашифрованный HW_ID с помощью M_KEY. На сервере данных выполняется проверка User Permit и расшифровка: по последним 4 символам лицензии (M_ID) в из БД ОЕМ находится M_KEY.

 

Рисунок 2: Структура User Permit

С его помощью из лицензии извлекается HW_ID, с помощью которого, в свою очередь зашифровываются лицензии ячеек (Cell Permit).

Сервер данных отгружает два типа наборов:

• базовый набор (BASE) — представляет из себя набор ЭНК, корректур к ЭНК и внешних файлов, выпущенных на дату формирования базового набора;
• набор обновления (UPDATE) — набор ЭНК, корректур и связанных с ними внешних файлов на момент формирования корректурного набора. Содержит изменения к набору BASE. С точки зрения данных это разница между данными на момент времени Т1 и данными на момент времени Т2.

Включенные в набор данные формируются в структуру ENC_ROOT [1].

Рисунок 3: Структура набора ЭНК

Для каждой ячейки набора формируется индивидуальный Cell Permit. Корректура с этой ячейке шифруется тем же ключом, что и базовая.

Рисунок 4: Структура Cell Permit

Отдельный Cell Permit является лицензией на ячейку, для которой он сформирован. Сформированные Cell Permit записываются в файл PERMIT.TXT.

Рисунок 5: Структура записи Cell Permit в PERMIT.TXT

Запись содержит:

• Cell Permit;
• Тип подписки — одноразовая отгрузка или подписка, номер издания ЭНК, ID сервера данных. То есть при установке у конечного пользователя всегда будет виден источник получения данных;
• Номер издания — номер издания ЭНК;
• ID сервера — идентификатор сервера данных, присвоенный серверу АС;
• Комментарий — необязательное поле.

Cell Permit, на стороне конечного пользователя дописывается в конец БД лицензий. При этом приложение пользователя не перезаписывает новые лицензии, а дописывает их в конец БД.

Файл PRODUCTS.TXT выпускается сервером данных и поставляется в каждом выпуске (базовом или корректурном). Есть 2 типа PRODUCTS.TXT:

• частичный (PARTIAL) — поставляется с базовым набором ЭНК и содержит сведения только об ЭНК, входящих в данную поставку;
• полный (FULL) — поставляется с корректурным набором и содержит сведения о всех продуктах (ЭНК), поставляемых сервером данных на момент отгрузки.

Сведения, содержащиеся в файле PRODUCTS.TXT, содержат полную информацию о ячейке ЭНК и её текущем статусе.

Файл STATUS.LST — файл для проверки актуальности судовой коллекции ЭНК. ДОЛЖЕН выпускаться через регулярные интервалы времени.

Файл SERIAL.ENC — файл содержит идентификационные данные и сведения об обновлении:

• ID сервера данных, зарегистрированный АС;
• номер недели выпуска;
• дата выпуска;
• тип диска (базовый или обновление);
• версия формата;
• номер обменного набора.
  

ОЕМ

ОЕМ, для регистрации в IHO, должен поддержать в своём ПО не только сам процесс чтения шифрованных ЭНК, но и всю схему в целом, в части касающейся ОЕМ:

• разработать приложение для чтения и отображения ЭНК (ЭКНИС, СОЭНКИ, ЭКС, Радар — далее ЭКНС);
• разработать и внедрить в ПО схему защиты (с использованием программного или аппаратного ключей);
• разработать и организовать ПО для генерации, хранения, учёта HW_ID, генерации User Permit. Обычно такое ПО интегрированное со схемой защиты ПО ОЕМа;
• обеспечить хранение и защиту от компрометации полученную от IHO пару ключей M_D и M_KEY.

После заключения лицензионного договора с IHO и получения M_D и M_KEY, ОЕМ включается в схему распространения IHO.

Конечный пользователь, в рамках действующей схемы, предоставив распространителю ЭНК (серверу данных) свой User Permit, может получить требуемые ему карты, установить их (расшифровать) и пользоваться по своему усмотрению.

Очень важный момент: конечный пользователь приобретает неисключительные права на ЭНК.

Конечный пользователь получает User Permit вместе с ЭКНС. User Permit является неотъемлемой частью ЭКНС и соответствует аппаратному ключу. Обычно, на аппаратном ключе, в закрытой области, записывается HW_ID, а User Permit представляет собой зашифрованный HW_ID и хранится в приложении ЭКНС в открытом виде. Для исключения ошибок при переписывании или передаче голосом, ОЕМ реализуют в своих приложениях экспорт User Permit в внешний файл.

В статье использованы скриншоты ПО ЭКНИС «АРКТИКА», производства ООО «ССГ НАВИГАЦИЯ», в качестве картографической основы использованы ЭНК из тестового набора S-64 [2]

Рисунок 6: Пример отображения User Permit в приложении ЭКНИС

Формфактор аппаратного ключа очень похож на обыкновенную флэшку или карту памяти SD/microSD. Случались инциденты, когда конечный пользователь пытался ключ отформатировать, использовать для хранения данных и т. д. Попытки «посмотреть что там» обычно не приводят к какому-либо результату, потому что на аппаратном ключе отсутствует файловая система. Все ОЕМы рекомендуют обеспечить надёжное хранение ключей и исключения их утраты.

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

Но возникает следующая проблема — при замене ключа меняется и HW_ID. В этом случае придётся перезаказывать и переустанавливать всю коллекцию ЭНК. Выпускать клон ключа, особенно при утрате исходного, может привести к появлению в схеме двух ЭКНИС с одинаковыми User Permit.

ЭКНС

ЭКНС является конечным звеном схемы распространения и защиты.

Во время работы с ЭНК могут возникать различные коллизии с данными. При обработке ЭНК ЭКНС должно вырабатывать ряд ошибок и предупреждений, в случае их возникновения — SSE(2)[1]. Конечный пользователь обязан знать их, а так же знать как их обрабатывать. Считается хорошей практикой публиковать SSE и алгоритм действий пользователя по каждому SSE, в руководстве пользователя.

[2] Префикс кода ошибки, принятый в Схеме S-63

При получении набора данных выполняется установка Cell Permit. Как было написано ранее, Cell Permit дописываются в конец БД ключей приложения. Если конечный пользователь будет устанавливать Cell Permit с каждым получением корректурных наборов, на одни и те же карты, мы получим огромное количество одинаковых Cell Permit. Если количество повторений одинаковых ключей в БД превышает 5, то ЭКНС говорит о том что карты не могут быть расшифрованы. В этом случае стоит, безусловно, прочитать Руководство пользователя, но достаточно просто удалить все Cell Permit из ЭКНС, и установить их из последнего полученного набора.

Фактически, Cell Permit нужны только для установки ЭНК в ЭКНС. При установке ЭНК компилируются в системные ЭНК (СЭНК). СЭНК это внутренний формат хранения ЭНК, который реализуют ОЕМы, для обеспечения быстрого доступа к данным, оптимизации скорости работы и т. д. ОЕМ применяет к СЭНК свою внутреннюю схему защиты данных. Но, в любом случае, для дальнейшей работы с ЭНК в ЭКНС Cell Permit не нужны. Тем более, что все Cell Permit хранятся у пользователя на дисках с ранее поступившими данными.

Далее следует этап установки ЭНК:

• проверка подлинности подписей;
• расшифровка ЭНК;
• компиляция СЭНК.

Каждая ячейка или файл корректуры подписывается сервером данных. Подпись формируется по определённому алгоритму [1] и проверяется с помощью корневого сертификата АС х.509. Если сертификат не установлен и подписи проверить невозможно ЭКНС вырабатывает SSE07. Следует установить сертификат IHO.CRT, поставляемый вместе с набором данных или скачать его с сайта IHO.

При работе с ЭНК нужно иметь ввиду следующее:

• цифровые подписи ячеек могут быть повреждены в процессе передачи, записи на носитель, формировании на сервере данных;
• ячейки могут быть повреждены — причины те же;
• ячейки могу содержать критические ошибки, которые по тем или иным причинам были отгружены пользователю (причины мы не рассматриваем);
• сертификат АС имеет ограниченный срок годности — и может устареть. Отслеживание актуальности сертификата АС обязанность конечного пользователя;
• лицензии на ячейки могут устареть;
• на сервере данных может быть выполнен сдвиг ЕСК;
• переход российских производителей ЭКНС с ОС Windows на ОС Linux так же ставит новые вызовы: ОС Linux гарантированно поддерживает, кроме собственных файловых систем, файловую систему FAT32. То есть установку ЭНК рекомендуется выполнять с носителя, отформатированного или в FAT32 или в ext4. Другие файловые системы, поддерживаемые Windows, являются частными (проприетарными), и данные под ОС Linux могут или не читаться совсем, или читаться с искажениями.

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

Есть несколько важных моментов, связанных с использованием ЭНК в ЭКНС, которые воспринимаются конечным пользователем как недостаток или ошибку:

А. ограниченный срок использования ЭНК;

Б. ограниченный срок использования неоткорректированных ЭНК;

В. ограниченный срок применения ручной корректуры.

Ограниченный срок использования ЭНК

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

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

ЭКНС отслеживает сроки окончания действия лицензий на каждую ячейку и заблаговременно оповещает конечного пользователя (за 30 дней и менее): SSE 20 – Subscription service will expire in less than 30 days. Please contact your data supplier to renew the subscription licence [1]. То есть, правильно написанное ПО ЭКНС, исключает ситуацию, когда пользователь «вдруг» остался без карт вообще. Принято считать, что 30 дней достаточный срок, для захода в порт и продления лицензии (срока подписки).

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

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

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

Ограниченный срок использования неоткорректированных ЭНК

В стандартах [1, 8] установлен срок, в течение которого ЭНК может использоваться для навигационных целей. В течение 4 календарных недель ячейка ЭНК может использоваться для навигационных целей без корректуры, то есть считается актуальной. Однако по истечение этого срока, при отображении неактуальной ячейки на экране, ЭКНС должны вырабатывать постоянное уведомление SSE 27 — ENC<cell name> is not up to date. A New Edition, Re-issue or Update for this cell is missing and therefore MUST NOT be used for Primary NAVIGATION [1].

Рисунок 7: Предупреждение SSE27 в ЭКНИС

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

Если ячейки не корректировать, то ЭНК будут отображаться до истечения срока подписки с предупреждением SSE27. Во всех отчётах по состоянию коллекции такие ячейки будут помечены как неоткорректированные (not-up-to-date).

Ограниченный срок применения ручной корректуры

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

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

Ручная корректура наносится пользователем на ЭНК и имеет статус официальной. Ручная корректура отображается по правилам S52 или в нотации INT1 (в зависимости от настроек отображения ЭНК в ЭКНС).

Рисунок 8: Создание объекта ручной корректуры на ЭНК

Ручная корректура подсвечивается специальным символом SY(CHCRID01) [9].

Рисунок 9: Объект ручной корректуры

Пользователь, в дальнейшем, может просматривать свойства объекта ручной корректуры в свойствах объекта.

Рисунок 10: Свойства объекта ручной корректуры

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

Для исключения дублирования объектов, а так же ситуации, при которой пользователь забыл, не успел, пропустил ручную корректуру, стандартом [1, 3, 7, 8], предусмотрен механизм удаления ручной корректуры ЭНК через 3 месяца с момента её нанесения. Исключение составляет корректура с назначенной датой начала действия — в этом случае срок удаления отсчитывается с момента даты начала действия объекта.

Таким образом, при длительном отсутствии автоматической корректуры, ручная корректура ЭНК по ИМ, может служить временным решением проблемы актуализации ЭНК, так как ЭКНС должна автоматически удалить объекты ручной корректуры, невзирая на наличие или отсутствие автоматической корректуры.

Тесты по удалению объектов корректуры есть описаны в [2, 4] и обязательны для всех ЭКНС, соответствующих старым, так и новым требованиям стандартов [8].

Исключение составляют системы, где ЭНК являются подложкой, и не используются для навигационных целей, а так же ЭКНС в которых используются ЭНК частных коллекций, правила распространения которых устанавливает производитель карт. Следует иметь ввиду, что в соответствии с [10] в ЭКНС должны использоваться только государственные ЭНК (ГЭНК).

Альтернативная схема распространения данных

Стандарт [1] допускает возможность существования альтернативных схем защиты и распространения данных.

Такой схемой является схема УНиО МО РФ — АСО ЦКИ ВМФ. В этой схеме администратором является УНиО МО РФ. Схема базируется на первой версии стандарта [3].

Следует учитывать, что современные ЭКНС, соответствующие [1, 2], должны отслеживать и уведомлять пользователя об установке иных сертификатов, а так же данных не проверяемых в рамках схемы IHO (SSE 26 - This ENC is not authenticated by the IHO acting as the Scheme Administrator) [1, 2]. При переходе на ЭНК, полученные из АСО ЦКИ ВМФ, в зоне постоянной индикации на экране, будет отображаться предупреждение SSE26.

Для включения в схему АСО ЦКИ ВМФ, ОЕМ проходит процедуры и выполняет требования, аналогичные требованиям IHO [4].

ОЕМ обязан поддерживать обработку данных, сформированных в соответствии с [3], до особого уведомления. То есть современные ЭКНС поддерживают работу с данными сформированными в соответствии с версией 1.1 стандарта и 1.2.1 (текущей) [1].

При отгрузке ПО формируются два User Permit. Пользователь должен разделять их и понимать назначение. 

Рисунок 11: Хранение User Permit IHO и АСО ЦКИ ВМФ в ЭКС "Лоция ВВП"

Отправка User Permit схемы IHO в АСО ЦКИ ВМФ приведёт к отказу отгрузки ЭНК, так как такие M_KEY/M_ID в схеме не зарегистрированы, и наоборот. При заказе ЭНК следует быть внимательными. Кроме того, нужно иметь ввиду, что для схемы АСО ЦКИ ВМФ действует другой корневой сертификат — UNIO.CRT.

ЭКНС должен отображать и обрабатывать ЭНК, полученные из различных схем распространения ЭНК на экране одновременно.

Различия версий 1.1 и 1.2.1 стандарта S-63

1. Совместимость и структура

• S63 1.1 – первая версия стандарта, выпущенная в 2004 году.
• S63 1.2.0 – обновлённая версия (2014), включает исправления и улучшения.
• S63 1.2.1 – обновлённая версия (2020), включает исправления и улучшения.

2. Поддержка новых алгоритмов шифрования

• S63 1.0 использует AES-128 (устаревший вариант).
• S63 1.2.1 поддерживает AES-256, что повышает безопасность.

3. Формат Permits (файлов лицензий)

• В S63 1.0 файлы лицензий (*.permit) имеют ограниченные возможности.
• В S63 1.2.1 улучшена структура файлов лицензий, добавлена поддержка более сложных схем лицензирования.

4. Поддержка новых версий S-57/S-100

• S63 1.0 ориентирован на S-57.
• S63 1.2.1 частично учитывает будущие обновления (например, стандарт S-100).

5. Улучшенное управление ключами

• В S63 1.2.1 усовершенствованы механизмы генерации и распространения ключей.

6. Обратная совместимость

• S63 1.2.1 обратно совместим с S63 1.0, но не наоборот.

Совершенствование распространения ключей, как пример, может реализовать следующий способ распространения: распространяется полная коллекция ЭНК сервера данных. То есть у каждого пользователя на руках будут все карты. А вот лицензии (Cell Permit) у каждого пользователя будут индивидуальные. В этом случае ЭКНС будет устанавливать из всей коллекции только те ячейки на которые установлены лицензии. При необходимости оперативно добавить ЭНК в коллекцию пользователю достаточно будет получить дополнительные лицензии, без скачивания базовых ЭНК, и корректуры на новые ЭНК с момента выпуска базового набора.

Аналогичным способом можно распространять корректуру — алгоритм обработки точно такой же, как и для базовых ЭНК.

Проблема производителей ЭНК

ЭНК могут быть официальными и неофициальными.

С точки зрения IHO к официальным относятся ЭНК, выпущенные IHO Member States: УНиО МО РФ — код RU (420) и ФГУП «Гидрографическое предприятие» - код R1 (425) [5].

ЭНК, выпущенные Other States и Other Organizations/Entities, считаются неофициальными. К ним относится ФАМРТ (Федеральное агентство морского и речного транспорта (Росморречфлот)), с кодом 8R (42018). При этом, согласно статьи 10¹ [6] «Создание и обновление государственных навигационных карт осуществляются федеральными органами исполнительной власти, определенными Правительством Российской Федерации».

Статьи 3.14.36 — 3.14.38 [7] устанавливают требование к статусу ЭНК с кодом 8R. ЭНК с кодом 8R должны отображаться как официальные. Это требование распространяется только на суда, осуществляющие плавание под надзором Российского Классификационного общества (РКО — бывший Российский Речной Регистр). То есть при загрузке ГЭНК с кодом 8R в ЭКНИС, возможна ситуация, когда ЭНК ВВП будут отмечены как неофициальные ЭНК.

Проблема поставщиков ЭНК

Один конечный пользователь может получать ЭНК от разных источников данных (серверов данных). При этом поставщики ЭНК могут иметь одинаковые коллекции ЭНК.

Коллекция ЭНК, полученная от СД№1, не может быть откорректирована корректурой на те же ячейки, но полученной от СД№2.

Это относится только к шифрованным ЭНК.

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

Проблема тех кто вне схемы

Ключом для входа в Схему является User Permit.

Таким образом, установленные на ведомственных катерах и судах, картплоттеры иностранного производства, так называемый Light Marine (RayMarine, Simrad, Furuno, Standard Horizon, Garmin и т.д.), работают с картами частных форматов и не поддерживают работу с ЭНК формата S-57. Соответственно в них реализуется собственная, коммерческая схема защиты данных.

В таких системах отсутствует, за ненадобностью, User Permit. Зачастую частные ЭНК поставляются на картах памяти SD, где ключом является сам носитель. Такой подход экономит время и не требует от пользователя специальных знаний и навыков по установке карт.

Как следствие для таких систем не могут быть отгружены ЭНК из АСО ЦКИ ВМФ. П. 5 2) статьи 10¹ [6] устанавливает право безвозмездного использования ГЭНК органами государственной власти и органами местного самоуправления.

Для корректуры ЭНК в картплоттерах требуется покупка новых, актуальных карт у поставщика данных или оборудования, что, в текущей политической ситуации, является серьёзной проблемой.

Практически все владельцы частных коллекций ЭНК, поддержали санкции в отношении Российской Федерации. Для исключения контрабанды данных, производители физически исключили карты на Российские воды из своих коллекций. То есть карты купить можно (если найти способ оплаты), но карт на воды России в них отсутствуют.

Существуют предложения, якобы новых карт от Navionics, NavNet, C-MAP. Но, на самом деле, это старые, выпущенные до 2022 года наборы ЭНК со взломанной защитой.

Вообще получается интересный парадокс: ведомства, имеющие право на безвозмездное использование ГЭНК, начиная с 2009 года, покупают ЭНК частных коллекций иностранных производителей, созданных на основе тех самых ГЭНК, которыми пользователь может пользоваться бесплатно.]

Заключение

Статья не охватывает значительную часть вопросов, возникающих в процессе закупки, установки и эксплуатации на ЭКНС.

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

Зачастую, компании, занимающейся постройкой плавсредств для госструктур, закупают, или ЭКНС гражданского назначения, с User Permit схемы IHO (почему-то считается что аналогичная система с User Permit АСО ЦКИ ВМФ стоит в несколько раз дороже), или картплоттеры класса Light Marine иностранного производства.

Далее следует этап попыток установки, на картплоттеры, ЭНК из АСО ЦКИ ВМФ. Этот этап начинается не на заводе-производителе, а в конкретной организации, для которой плавсредство было построено.

Фраза «… читать и отображать ЭНК формата S57/3 зашифрованных в кодах АСО ЦКИ ВМФ...» или отсутствует в техническом задании (ТЗ), или игнорируется как несущественная. Причём игнорируется не только на уровне исполнителей заказа, но и на уровне представителей военной приёмки.

Как представители судостроительной области, так и военной приёмки не знают о том что, согласно [6] госструктуры имеют право использования ГЭНК на безвозмездной основе.

Возникает ситуация, когда значительная часть ЭКНС, установленных на плавсредствах госструктур, отрезана от актуальной навигационной информации. Эта значительная часть ЭКНС не может быть модернизирована до работы с ЭНК из АСО ЦКИ ВМФ, особенно картплоттеры любительского класса.

Как быть с этими системами — вопрос открытый и болезненный, но не менее болезненный вопрос обеспечения навигационной безопасности плавания.

Финансовый вопрос не менее важен: как следствие таких поставок, организации, имеющие право безвозмездного использования ГЭНК, вынуждены платить деньги иностранным поставщикам данных для закупки частных ЭНК и корректуры к ним.

Несмотря на достаточно сложную схему распространения данных [1, 3], её полная реализация и следование требованиям, позволят корректно использовать и управлять бортовой коллекцией ЭНК, отслеживать актуальность ячеек, источники поступления ЭНК и корректуры к ним, а так же минимизировать вероятность компрометации данных и их утечки. Если же к требованиям [8] добавить расширенные требования по документированию обстоятельств плавания из [7], то это расширит возможности послепоходового анализа, а так же анализировать деятельность органов снабжения ЭНК.

Так же, следует иметь ввиду, что картографические сервера, особенно бортовые, это больше чем «шифровалка», а элемент [1, 3], призванный обеспечить не расшифровуку ЭНК, а управление коллекцией или коллекциями ЭНК систем использующих карты на борту судна/корабля. И основная задача такого сервера — постоянный мониторинг коллекции, формирование запросов на корректуру или обновление коллекции. И, как следует из написанного в начале статьи, на борту достаточно иметь одну коллекцию карт, а отслеживать лицензии (Cell Permit) различных потребителей ЭНК.

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

Использованная литература:

1. IHO Publication S-63 IHO DATA PROTECTION SCHEME Edition 1.2.1 – March 2020. MONACO

2. IHO Publication S-64 Instruction Manual for the Use of IHO Test Datasets in ECDIS Edition 3.0(.3) – December 2020. MONACO

3. IHO S-63 Data Protection Scheme. Edition 1.1. 2004. MONACO

4. TEST DATA IMPLEMENTATION GUIDE (Part of Appendix 1 of S-63 Edition 1.0) Edition 1.1 - July 2004. MONACO.

5. List of Data Producer Codes (This document was generated on : 16 April 2025) Date of last change to S-62 : 28 March 2025. MONACO

6. Федеральный закон от 14.02.2009 г. № 22-ФЗ «О навигационной деятельности» (В редакции федеральных законов от 02.04.2014 № 60-ФЗ, от 13.07.2015 № 216-ФЗ, от 17.02.2023 № 35-ФЗ, от 22.07.2024 № 196-ФЗ).

7. ПРАВИЛА КЛАССИФИКАЦИИ И ПОСТРОЙКИ СУДОВ (ПКПС). Часть VIII. Москва 2019.

8. IEC 61174 Edition 4.0 2015-08 Maritime navigation and radiocommunication equipment and systems – Electronic chart display and information system (ECDIS) – Operational and performance requirements, methods of testing and required test results.

9. S-52 Annex A: IHO ECDIS Presentation Library Edition 4.0(.3) – October 2014 (With Clarifications up to December 2020) Addendum to Part I: S-52 ENC Symbol Catalogue. Paper based description of symbols for use on ECDIS.

10. Федеральный закон от 14.02.2009 г. № 22-ФЗ «О навигационной деятельности» (В редакции федеральных законов от 02.04.2014 № 60-ФЗ, от 13.07.2015 № 216-ФЗ, от 17.02.2023 № 35-ФЗ, от 22.07.2024 № 196-ФЗ).

А.В. Гайдай

(ООО «ССГ НАВИГАЦИЯ»)