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

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

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

У нас же полная неразбериха с разработкой электронной документации и отсутствие единого подхода к созданию систем интегрированной логистической поддержки эксплуатации воздушных судов. В настоящее время в России активизирован и идет полным ходом процесс слепого копирования западных стандартов под эгидой ведущих организаций в области гармонизации стандартов «НИИСУ» и АНО «НИЦ 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 в двух редакциях – отдельно для государственной и гражданской авиации.

10 Комментариев для Давайте посмотрим реальности в лицо. Интерактивная электронная документация для государственной авиации должна начинаться с переработки вновь изданных стандартов

  1. Полностью поддерживаю авторов. От себя лишь добавлю, что по вновь переработанным ГОСТ невозможно разработать ИЭТР по-любому надо будет обращаться к ASD S1000D. Какой было смысл их переделывать, дали бы ссылку на ASD S1000D и все. Ах да выделенные деньги надо было освоить… Да и честно говоря у нас уже не ГОСТ-ы, а одна большая идеология от НИЦ CALS-технологий, и скрытая реклама TGBuilder и других криворуконаписанных сред.

  2. Полный бред.
    Авторы понятия не имеют о чем пишут.
    В S1000D, как и в описываемых программных продуктах, они «ни ухом ни рылом».
    Статья школьников, пытающихся написать диссертацию, после прочтения пары научно-популярных журналов.
    А с учетом того, что авторы сами пытаются «пропихивать» свое разрабатываемое программное обеспечение (но его особо никто не берет, и им обидно) все становится на свои места.

  3. Правильная и своевременная статья. Давно пора определить роль и место зарубежных стандартов в российской нормативной базе.

  4. Авторам 5+ Наконец-то появилась здравая критика спецификации S1000D. Завтра обязательно положу на стол своему начальнику, замучался объяснять ему, что не все в S1000D так хорошо как пишут.

  5. Те, кто считает что «не все так хорошо», альтернативу-то какую-то предлагают? Или опять все по принципу «Сам ничего дельного предложить не могу, но начинания других осуждаю»? Пока мировая промышленность вырабатывает общие подходы в области ИЛП и Россия худо-бедно подключилась к этому процессу, причем в наиболее перспективных и бурно развивающихся направлениях, обязательно найдутся старперы-консерваторы, которым все (для них) новое — чуждо. Когда эти радетели за «свой, уникальный, российский подход» хоть что-то полезного сделают, а не только будут языком молоть, вот и посмотрим на их творения.

    А статейка ляп на ляпе. Комментировать даже невозможно — комментариев больше чем текста статьи будет. Авторы показали полное незнание спецификации и «анализируемого» ими программного обеспечения.

  6. Очень грустно осознавать, что в XXI-вом веке в ВВС РФ нет ни интерактивной электронной документации, ни, тем более, системы ИЛП. С авторами полностью согласен. Нужно не «тупое» копирование, а анализ сильных и слабых сторон. Очень грамотно замечено, что нужны две версии стандарта.
    Западные технологии там, где есть наши секреты – по моему, даже звучит смешно.

  7. А вот благодаря таким авторам пока в ВВС очень мало чего есть. Так как «не в ВВС» (в авиакомпаниях, КБ, заводах) все сильно продвинулось вперед, есть понимание что это, как это, как использовать. И электронная документация есть (возьмите тех же Туполева, Сухого, Микояна, Миля и т.п.).

    Ведь затрагиваемая тема — ИЛП — это объединение процессов на стороне КБ, завода и эксплуатанта. Часть процессов, относящаяся к первым двум компонентам, содержит далеко не только техническую документацию, но и другие области ИЛП. И уже в том или ином виде это внедрено и применяется. И сама документация — это лишь следствие работ по другим областям. Те, кто документацию создают, прекрасно это понимают и используют преимущества интегрированного подхода.

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

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

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

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

    Никто, например, не хочет взять на себя удар и сказать ОКБ Сухого, что их документация на новые истребители, сделанная по S1000D, не подходит ВВС?

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

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

  8. Господин «Интересующийся» по-моему Вы просто не понимаете что такое государственная авиация и чем она отличается от гражданской. У меня к Вас пара вопросов. В полку на бетоне яйца морозили? Вы вообще служили в армии? Вы себе представляете, что такое режим и хоть немного знаете о руководящих документах по защите гос. тайны и т.д. в ВВС. Вы внимательно прочтите статью и о чем в ней пишут авторы.
    В настоящее время я занимаюсь разработкой электронной документации под инозаказчика, но в тоже время прослужил в авиационном полку 16 лет и очень хорошо понимаю о чем говорят авторы.
    Вам лично хочу сказать следующее, что если бы раньше всем не навязали по ФЦП идиотский TGBuilder, от которого все КБ плюются, то никто бы и не знал про этот S1000D. Не надо так утверждать, что все КБ делают по ASD, если не знаете то лучше не говорите.
    Честно говоря до глубины души обидно, что Вы так прозападно настроенный товарищ, наверно поэтому у Вас и коменты гнойно-оскорбительные. Скоро у нас в России по западным стандартам из школ и Вузов быдло тупое будет пачками выходить, а армию как уже только не пытаются переделать под западный стандарт, только вот что-то мало что получается.

    С уважением.

  9. Уважаемый «Интересующийся» в продолжение нашей с Вами беседы, если Вы конечно не потеряли интерес, у меня возник к вам интересный вопрос, на который меня натолкнул второй снизу абзац статьи. Раз в 2.610-м ГОСТ имеется пункт 16.2.1, то получается, что требования ГОСТ, например, 2.601-го и т.д., а также проект ГОСТ 18675-20ХХ (скачал последний проект с соответствующего сайта), и которые сейчас заточены под идеологию S1000D попросту какая-то фикция!

    Что я имею в виду. Например, терминология – ИЭТР, модуль данных, общая БД и т.д. Другой момент – кодирование информации (модуль данных, иллюстрации и т.д.) по S1000D.

    А теперь вопрос. Статья 16.2.1 ГОСТ 2.610 позволяет мне разработать и поставлять эксплуатационную электронную документацию, например, при использовании реляционной СУБД и других типов БД. Но извините, как терминология, так и кодирование и XML, да и попросту все, что касается S1000D, в наших ГОСТ, за исключение, наверное, оформительских моментов идет в одно место?!

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

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

    Во приехали… Что вы об этом всем думаете?

  10. Еще парочка интересных моментов.

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

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

    Честно говоря, начал укореняться во мнении, что наши ГОСТ это какой-то неудачный плагиат S1000D (те, кто переводили и переписывали, ничего нового не предложили). Хотелось бы мне услышать ваше мнение и мнение других специалистов по всем этим моментам.

Написать ответ

Выш Mail не будет опубликован


*


Рейтинг@Mail.ru Яндекс.Метрика