Форум пользователей спецификации S1000D в Вене (S1000D User Forum 2013)

1 Немного общей информации

Материал данной статьи написан по итогам участия в форуме пользователей спецификации S1000D (S1000D User Forum), проходившем в Вене с 17 по 19 сентября 2013 года. В основе статьи лежит обзор и анализ докладов и результатов общения с участниками форума, разработчиками и представителями управляющих комитетов различных спецификаций S-серии.

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

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

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

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

Для справки: следующий форум будет проходить в США 23-25 июня 2014 г. в Сан Антонио.

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

2 Доклады форума. Акценты

2.1 Краткий обзор докладов

На форуме в первые два дня было представлено 39 докладов, посвященных спецификации S1000D и 13 докладов в специальный день (S-day), посвященный обзору всех стандартов S-серии.

Сами доклады можно найти на сайте Австрийской авиационной индустриальной группы (Austrian Aeronautics Industries Group).

Все доклады я бы разделил  на следующие группы:

  • доклады про софт, обеспечивающий решение частных или комплексных задач в рамках спецификаций S-серии;
  • доклады, посвященные разработке и использованию бизнес правил, в том числе в виде специальных модулей BREX (Business Rules Exchange). Вообще данной теме было уделено ОЧЕНЬ много внимания, как со стороны докладчиков, так и со стороны экспонентов, которые представляли соответствующие программные решения;
  • доклады о результатах использования спецификации S1000D в конкретных гражданских и военных проектах;
  • другие доклады, которые отражали решение некоторых частных вопросов в области разработки документации (защита информации, обмен данными, разработка графики и т.д.), ну или такие, которые вообще ничего не отражали (к сожалению, были и такие).

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

Мне, конечно, слабо верится, что в ближайшее время такой инструмент будет сильно востребован, т.к. существует достаточно большое количество различных приложений, которые уже содержат все необходимые шаблоны и настройки для разработки иллюстраций в соответствии с требованиями спецификации S1000D. Например, мой любимый пакет CorelDRAW Technical Suite X6.

2.2 Бизнес правила в документации и BREX

От иллюстраций я предлагаю перейти к очень интересному и важному вопросу, связанному с автоматизацией проверки документации на соответствие не только (и даже не столько) требованиям S1000D, но и требованиям конкретного проекта или заказчика.

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

Здесь потребуется немного общей информации о бизнес-правилах и модулях BREX.

Что же такое бизнес-правила? Для ответа на этот вопрос предлагаю обратиться к определению, которое приведено в S1000D (издание 4.1, глава 2.5).

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

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

Примеры бизнес-правил:

  • допустимый код модели изделия (MI) для данного проекта «1B» для машины, «E2» — для двигателя;
  • перечень кодов стандартной системы нумерации (SNS) вместе с техническими наименованиями и типами модулей данных приводиться в модуле данных, имеющем код DMC-YY-Y-YY-…;
  • правила применимости:
    • версия изделия должна иметь значение «Mk1» или «Mk9»;
    • серийный номер изделий может находиться в диапазоне с «001» по «999».

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

Для использования в процессе разработки или проверки документации бизнес-правила должны быть обобщены в виде модулей данных, которые имеют специальную структуру (схему) и называются «Модули данных BREX» (BREX DM).

Так почему же к бизнес-правилам на данном форуме столько интереса? Основная причина в том, что их применение доказало свою эффективность.

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

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

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

В качестве примера могу привести высказывание одного из докладчиков: «Когда нам нужно было проверить несколько тысяч МД и мы запустили проверку на соответствие бизнес правилам, то окончания процесса проверки мы дождаться не смогли, т.к. через месяц ее пришлось остановить…».

Конечно, выход из данной ситуации есть – это использование компилируемых языков (JAVA, или .NET), но это уже совсем другая история.

Думаю, что про бизнес-правила и их важность я написал достаточно. Давайте двинемся дальше.

2.3 Применение S1000D для железнодорожной техники (RailDEX)

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

Особенно интересен в этом плане совместный проект Bombardier, Alstom и SNCF (оператор железных дорог во Франции), направленный на адаптацию спецификации S1000D под нужды производителей и эксплуатантов железнодорожной техники. Данная адаптация получила название RailDEX (по аналогии с ShipDEX).

RailDEX, также как и ShipDEX, по сути, представляет собой набор бизнес правил, о которых я писал выше, учитывающих требования к разработке и передаче данных между заинтересованными компаниями одной отрасли (сегмента рынка и т.д.). Основное отличие между данными BRDD (Business Rule Design Document – документ, содержащий набор бизнес-правил) заключается в том, что существующий ShipDEX применим к спецификации S1000D версии 2.3, а разрабатываемый RailDEX, ориентируется на использовании спецификации S1000D версии 4.1.

Первая версия RailDEX ожидается в первом квартале 2014 года. Она будет включать наборы бизнес правил для наиболее востребованных типов модулей данных: описательный, каталог, процедурный и BREX.

По заявлениям разработчиков RailDEX основными целями данного документа являются:

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

Что сказать? Благое дело. Мое мнение – учитывая то, что в разработку RailDEX вовлечены крупнейшие игроки рынка железнодорожной техники, которые уже имеют опыт создания и использования документации в соответствии с S1000D, данный процесс обречен на успех.

Возможно и ОАО «РЖД», учитывая разномарочность техники, появление новых единиц подвижного состава, в том числе от зарубежных производителей, значительную продолжительность (и, соответственно, стоимость) жизненного цикла изделий, было бы неплохо обратить внимание на подобный подход, а может и присоединиться к инициативе Bombardier, Alstom и SNCF. Ну это так, к слову.

2.4 Классика жанра

В завершение данного раздела статьи, хотелось бы вернуться от RailDEX и ShipDEX к проектам зарубежных производителей авиационной техники — традиционным законодателям моды на форумах S1000D.

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

  • получение от всех субподрядчиков документации в соответствии с S1000D;
  • разработка необходимой документации силами Airbus;
  • размещение всех полученных от подрядчиков и созданных МД в CSDB (Common Soure Database – общая исходная база данных);
  • публикация документации из CSDB.

Общая схема описанного выше процесса представлена на иллюстрации.

Схема процесса разработки документации для Airbus A350

Схема процесса разработки документации для Airbus A350

Особенностями данного проекта, помимо использования множества репозиториев для различных объектов CSDB (модулей данных, графики, схем зонирования, предупреждений и предостережений и других элементов), является отсутствие в ИЭТР на новый самолет, как таковых, модулей публикаций. То есть, имея доступ к базе данных документации на А350, вы не увидите структуры документа в ее привычном понимании (например, структуры руководства по эксплуатации или каталога).

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

Пример доступа к необходимой информации через схему деления

Пример доступа к необходимой информации через схему деления

На мой взгляд, достаточно удобная схема доступа к документации, учитывая огромный объем информации CSDB. Например, только каталог на самолет содержит 8500 иллюстраций, отражающих информацию по 120 000 составным частям, а полный объем CSDB на A350 включает более 30 000 МД.

3 Развитие S-серии. Что уже регламентировано?

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

В частности на данный момент разработаны и разрабатываются следующие спецификации S-серии:

  • SX000i – международное руководство по использованию спецификаций S-серии;
  • S1000D – международная спецификация для технических публикаций, использующих общую базу данных (CSDB);
  • S2000M – международная спецификация для управления запасными частями и материалами (прим. автора – скорее всего «управление предметами поставки», в оригинальной версии используется термин «materiel management»);
  • S3000L – международная спецификация, регламентирующая вопросы анализа логистической поддержки;
  • S4000M – международная спецификация для разработки программ технического обслуживания;
  • S5000F – международная спецификация, регламентирующая вопросы обратной связи в процессе эксплуатации изделий;
  • S9000D – словарь спецификаций S-серии;
  • ASD-STE100 – упрощенный технический английский.

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

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

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

Ниже представлена схема процесса информационной поддержки жизненного цикла изделий, разработанная и представленная в 1993 году на одном из семинаров НАТО. Концепция одной из первых спецификаций S-серии — S1000D появилась еще раньше, — в начале 80 гг. прошлого века.

Схема процесса информационной поддержки жизненного цикла изделий, 1993 г.

Схема процесса информационной поддержки жизненного цикла изделий, 1993 г.

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

Современная схема процесса информационной поддержки жизненного цикла изделий

Современная схема процесса информационной поддержки жизненного цикла изделий

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

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

Как видно из схемы – центральную роль в процессах ИЛП играет анализ логистической поддержки (АЛП, в англ. аббревиатуре – LSA).

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

Учитывая взаимодействие и взаимовлияние процессов ИЛП, большое значение придается интеграции и обмену данными, используемыми на всех стадиях жизненного цикла изделий. Как пример здесь могу привести спецификацию S1003X, предназначенную для обеспечения передачи данных анализа логистической поддержки (АЛП) в техническую документацию.

Суть данной спецификации состоит в определении соответствия параметров и атрибутов результатов АЛП со схемой и атрибутами документации по S1000D. Дальнейшее развитие данной спецификации (новое обозначение – S1000X) обеспечит интеграцию с другими источниками и получателями данных (по сути, с результатами всех процессов, регламентированных в других спецификациях).

Перспективы применения S1000X

Перспективы применения S1000X

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

4 А что у нас?

Кто на лавочке сидел,
Кто на улицу глядел,
Толя пел, Борис молчал,
Николай ногой качал.

 

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

Давайте посмотрим, как дела обстоят у нас.

Хорошая новость – спецификация S1000D имеет официальный (лицензионный) перевод для версии 2.3, выпущенный в 2007 г. в виде документа АС1.1.S1000DR-2007. Ожидается появление перевода более новой версии S1000D в следующем году. Предположительно это будет перевод версии 4.0 или 4.1.

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

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

Для сохранения всех нюансов, изложенных в оригинальном издании спецификации на английском языке, при переводе ее на русский требуется потратить достаточно много времени и сил. В связи с этим неизбежно возникает проблема «временного лага» между выпуском новых версий спецификации на английском (например, 4.2 должна появиться уже в декабре 2013 г.) и их перевода на русском языке. Иногда это приводит к отсутствию некоторых версий спецификации на русском языке.

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

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

В России наибольшее распространение S1000D получила в авиационной промышленности в силу ее более тесной интеграции с мировыми бизнес-структурами и сложившимися традициями. Остальные наши отрасли еще далеки от ее применения.

На мой взгляд, основными проблемами распространения спецификации в России являются:

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

Думаю, что Вы сами сможете продолжить данный список.

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

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

К сожалению, проблема существует, но данную проблему нужно и можно решить.

Покупайте наших слонов!

Статьи по теме:

Об авторе Александр Воронцов