В чем же главная проблема? Почему принципы построения этих систем не могут быть использованы в ВВС РФ? А дело, наверное, в старой русской привычке – подражать всему заграничному. У них ведь там все четко. Контакт между производителями и эксплуатантами авиационной техники такой, как между двумя старыми школьными товарищами. Взаимопонимание – полное. Покупая, к примеру, самолет, эксплуатант получает в комплекте полный набор электронной документации, всевозможные программно-аппаратные решения по автоматизации управленческой деятельности. Сам же в ответ постоянно снабжает производителя данными о том, как самолет и его системы ведут себя в эксплуатации.

 

У нас же полная неразбериха с разработкой электронной документации и отсутствие единого подхода к созданию систем интегрированной логистической поддержки эксплуатации воздушных судов. В настоящее время в России активизирован и идет полным ходом процесс слепого копирования западных стандартов под эгидой ведущих организаций в области гармонизации стандартов «НИИСУ» и АНО «НИЦ CALS-технологии». Не имеет смысла в данной статье приводить весь тот огромный перечень стандартов, переработанных в угоду Западу.

Учитывая, что из всей совокупности стандартов международный стандарт АSD S1000D явился методологической платформой, на основе которой были переработаны российские ГОСТ 2.051-2006, 2.601-2006, 2.602-2006, рассмотрим только этот стандарт через призму возможности его применения в целях создания интерактивной электронной документации для государственной авиации. Согласно его требованиям, кодированию в различных вариантах подвержено большое количество информационных единиц. Так, код модуля данных имеет от 17 до 37 символов, информационный код – 3 символа, код раздела – от 6 до 9 символов, контрольный код иллюстрации – до 45 символов, код модуля публикации – 6 символов.

 

Целесообразно ли такое тотальное кодирование? Ответ на этот вопрос лежит на поверхности. Стандарт ASD S1000D базируется на расширяемом языке разметки XML, в котором для однозначной идентификации информационных единиц требуется отличительная информация или код. Поэтому все файлы модулей данных и иллюстрации должны иметь уникальные имена, равно как и информация, находящаяся внутри модуля данных. Между тем, как показывает опыт, тотальное кодирование не требуется никому и в особенности не требуется специалисту, эксплуатирующему авиационную технику. У него попросту вызывает недоумение, когда ему предлагается осуществить поиск информации по коду длиной до 37 символов, как и всплывающая подсказка над гиперссылкой, отображающая код модуля данных, на который может быть осуществлен переход.

 

На это могут жестко возразить – коды требуются для различных групп разработчиков различных изделий авиационной техники, работающих совместно над единым проектом. Но давайте посмотрим реальности в лицо и, опираясь на доминирующий по продажам на российском рынке программный продукт «TG Builder», обратим свое внимание не на кодирование, а на унифицированную структуру модуля данных.

 

Известно, что структура модуля данных определяется опубликованными на официальном сайте разработчика стандарта ASD S1000D XML-схемами S1000D, являющимися принципиальной основой для реализации требований стандарта ASD S1000D. На практике же используемый набор тегов в XML и SGML файлах программного продукта «TG Builder» коренным образом отличается от XML-схем S1000D, отсутствует деление на идентификацонно-статусную и содержательную части, не говоря уже об остальных элементах разметки модуля данных. В итоге модули данных строятся не в соответствии со спецификацией ASD S1000D, а в соответствии с возможностями по отображению информации конкретного программного обеспечения, а именно «TG Browser». В данном аспекте не только нет необходимости в соблюдении требований по кодированию информации, но и попросту теряется взаимосвязь между разработчиками, использующими неидентичные программные продукты.

 

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

 

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

 

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

 

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

 

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

 

Однако преимущества данного подхода становятся очевидными, если изначально пойти по пути web-технологий (первоначально стандарт ASD S1000D на это и был ориентирован) и использовать сеть Internet, хранить и актуализировать информацию базы данных на стороне разработчика, а также использовать Internet-браузер для получения и просмотра актуальных модулей данных. Но эта схема не приемлема для системы эксплуатации воздушных судов государственной авиации.

 

Огромная, с трудом решаемая в настоящее время проблема – это переносимость разработанной интерактивной электронной документации на операционные системы Министерства обороны. Какие-либо попытки перенести электронную документацию, разработанную при помощи «TG Builder», на операционную систему Министерства обороны потерпят неудачу. И причин здесь крайне много: от напрямую используемых функций Windows API до использования ActiveX компонентов сторонних производителей.

 

В то же время, с использованием ActiveX компонентов вырисовывается и другая проблема – необходимость приобретения вместе с «TG Builder» недешевого программного обеспечения стороннего производителя, как правило, зарубежного, требующего специальных проверок соответствующих органов.

 

Другим достаточно известным продуктом является программный продукт «Seamatica-ED». Как заявляют разработчики этого программного продукта, он способен создавать кроссплатформенную документацию, так как для ее просмотра используется только web-браузер. Такое технологическое решение весьма привлекательно. Однако, даже не вдаваясь в то, что web-технологии в военной среде имеют крайне ограниченное применение, кроссплатформенность имеет и свои крайне негативные последствия. Именно эти негативные последствия и оказывают сильное влияние на создаваемую электронную документацию, имеющую, в отличие от «TG Builder», весьма ограниченную и скудную функциональность. Соотношение возможностей «Seamatica-ED» с требованиями ASD S1000D показывает, что этот программный продукт удовлетворяет стандарту далеко не во всех аспектах. Более того, он не поддерживает даже набора основных типов модулей данных.

 

Вот еще несколько критикуемых моментов стандарта ASD S1000D. Интерфейс электронного документа, разработанного на его основе, не будет соответствовать современным концепциям построения интерфейсов, разработанным такими корпоративными гигантами, как Microsoft или Apple. Он будет соответствовать уровню развития программного обеспечения 1990-х годов, уровень которого сохранился и в современной 4-й версии ASD S1000D. По большому счету, требования стандарта распространяются только на описательную документацию, оставляя в тени такую важную документацию, как учетно-отчетную и нормативную. Более того, остается открытым вопрос о системе кодирования в таких документах, как формуляр воздушного судна, формуляр двигателя, паспорт и этикетка.

 

В тексте стандарта в числе его главных достоинств упоминается о снижении стоимости разработки технических публикаций. Но в реальности стоимость разработки одного модуля данных, содержащего только текст, в 15…20 раз выше стоимости того же текста, только набитого оператором в MS Word. Конечно же, в данном аспекте можно вспомнить и про тотальную систему кодирования информационных единиц.

 

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

 

И совсем непонятно, как же быть с уже переработанными в угоду ASD S1000D государственными стандартами? Взять, например, основополагающий для государственной авиации ГОСТ 18675-79, который в настоящее время переработан специалистами АНО «НИЦ CALS-технологии» и проходит стадию согласования под названием ГОСТ 18675-2011. Так вот, эта переработка серьезно противоречит ГОСТ 2.610-2006, разработанному специалистами этой же организации. Дело в том, что статьей 16.2.1 ГОСТ 2.610-2006 регламентируется, что требования к номенклатуре, составу информации, логической модели данных базы данных должны регламентироваться нормативными документами на изделия конкретных видов техники с учетом их специфики. Так ведь это как раз то концептуальное направление, которое необходимо для разработки интерактивной электронной документации, которую так давно ждут авиационные специалисты, эксплуатирующие воздушные суда государственной авиации.

 

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