код модуля данных s1000d
S1000D. Основные термины и сокращения
Спецификация S1000D описывает создание, структурирование и контроль технических публикаций, а также принципы публикаций в странично-ориентированном и электронном интерактивном форматах. В S1000D используется масса специализированных терминов, и в рамках этой статьи мы разберем основные из них.
Перечень необходимых модулей данных (DMRL — Data Module Requirement List) — документ со списком модулей, требующихся для проекта. Как инструмент для определения необходимых модулей, перечень может разрабатываться частями, например, партнерскими компаниями, или целиком. В российской системе стандартов аналогом Data Module Requirement List является план-проспект документации, определяющий начальный выбор разделов и их содержание.
Код модуля данных (DMC — Data Module Code) — буквенно-цифровая последовательность из 17-41 символов. Код определяет тип и применимость информации модуля данных, а также дает возможность вводить/извлекать модуль данных из БД.
Стандартная система нумерации (SNS — Standard Numbering System) — фрагмент кода модуля данных, используемый для определения составной части изделия. В российской системе стандартов похожий по смыслу термин («система нумерации и кодирования») используется в ГОСТ 2.601.
Информационный код (IC — Information code) — фрагмент кода модуля данных, определяющий тип информации, содержащейся в DM. Например, по стандарту S1000D модулю данных техобслуживания присваивается код 312.
Модуль данных (DM — Data Module) — самостоятельная информационная единица, которая идентифицируется кодом модуля данных. В DM содержатся данные, необходимые для идентификации и описания изделия, его компонентов, процессов технического обслуживания и эксплуатации, в том числе и вспомогательного оборудования. В составе модуля 2 части:
Модуль данных разрабатывается в форме, которая позволяет вводить и извлекать его из базы данных, пользуясь в качестве идентификатора кодом DM.
Контрольный номер информации (ICN — Information Control Number) — буквенно-цифровая последовательность, присваиваемая графическим и мультимедийным объектам, а также прочим данным с адресом информационного объекта в общей базе исходных данных (CSDB). ICN позволяет связывать иллюстративный материал, мультимедиа и другие данные с одним или несколькими DM. Спецификация S1000D включает в состав номера 10 элементов. По сути, структура кода ICN во многом сходна с DMC.
Активная точка (hotspot) — иллюстративная зона, предварительно определенная в файле CGM или в содержательной части DM в виде карты активных точек. Эта зона обеспечивает интерактивную связь элементов иллюстрации с содержанием модуля, а также другими информационными объектами в базе исходных данных.
В компании «Иторум» вы можете заказать разработку интерактивной электронной технической документации в соответствии со спецификацией S1000D — релевантный опыт в сочетании с высокой квалификацией инициативной команды специалистов обеспечит быстрый, точный и качественный результат. Оставьте заявку в форме обратной связи или позвоните по тел. 8495-120-80-55, мы будем рады проконсультировать и оказать помощь по всем вопросам технических публикаций.
Код модуля данных s1000d
В своих публикациях мы уделяли большое внимание архитектуре DITA, но хотелось бы отметить, что это не единственный полноценный стандарт для создания технической документации. Технический консультант и специалист по разработке структурированной документации Себастьен Клима рассказывает об основных преимуществах разных спецификаций.
Спецификация S1000D
S1000D – это спецификация для производства технической документации, связанной с эксплуатацией (ТОиР – Техническое обслуживание и ремонт), основанная на концепции модулей данных и хранящаяся в общей базе данных эксплуатационной документации (ОБДЭ). Эта спецификация полностью отвечает требованиям технического обслуживания для всех видов воздушных, наземных и водных механизмов, которые содержат большое число компонентов. Таким образом, спецификация S1000D позволяет организовывать информацию в модульной форме, повторно использовать модули данных, избегать дублирования информации, что подразумевает значительную экономию денежных и временных затрат при создании и управлении публикациями.
Преимущества спецификации S1000D:
Внедрение спецификации S1000D
Спецификация S1000D исторически используется разработчиками оборудования, связанными с европейскими оборонными, сухопутными, морскими и воздушными военными проектами в Европе, США и Австралии. Совсем недавно использование спецификации распространилось на области гражданской аэрокосмической и железнодорожной промышленности.
Таким образом, две основные из недавних программ гражданской авиации используют S1000D: A350 (Airbus) и Dreamliner B787 (Boeing). Спецификация S1000D в основном используется в эксплуатационной документации для авиационных транспортных отраслей, но также железнодорожной и морской (при поддержке специфических протоколов RailDex и ShipDex, которые персонализируют соответствующие S1000D этих секторов).
Первоначально, в 1980-е годы, эта спецификация была создана Европейской ассоциацией производителей аэрокосмического оборудования (AECMA), чтобы удовлетворить потребности аэрокосмической и оборонной промышленности в технических публикациях. Спецификация с тех пор развивалась и с 2005 года устанавливает стандарты для документации любого транспортного средства или оборудования, будь то гражданское или военное.
Внедрение спецификации S1000D может быть простым или сложным в зависимости от сложности требований к проекту, реализующих эту спецификацию.
Сегодня можно найти очень небольшое количество литературы по обучению, это в первую очередь связано с тем, что спецификация S1000D используется в военной области.
Спецификация доступна на английском языке. Также есть переводы на французский и немецкий языки.
Архитектура DITA
Существует ещё один стандарт на основе XML, посвящённый разработке, проектированию и публикации технической информации. Это DITA (Дарвиновская Архитектура Типизированной Информации).
Главные особенности DITA:
Если спецификация S1000D специализируется на эксплуатационной документации сложных систем, DITA оказывается гораздо более универсальной. Осуществлялись попытки взаимодействия, но имеющиеся инструменты, а также ограничения, накладываемые контрактами на основные программы, сделали S1000D основным выбором при документировании ТОиР.
DITA создана для документации технических систем и остается вне конкуренции для программной или аппаратной документации в области ИТ, о чем свидетельствует её происхождение (IBM) и ее основные спонсоры (Microsoft, Intel, Cisco, Oracle, SAP). Возможность специализации (чего нет в S1000D) позволяет ей осваивать другие направления, как например, обучение. Так, компания Dassault System использует для документирования систему автоматизированного проектирования CATIA (Систему прикладного трёхмерного автоматизированного проектирования).
К минусам DITA относится сравнительная сложность, хотя многие издатели на рынке создали программное обеспечение для упрощения использования DITA. Этот стандарт весьма распространён в англо-саксонских странах.
Стандарт ASD S1000D. Эффективные методики разработки технической документации. Бумажное прошлое или электронное настоящее?
Проблема смешанной «бумажно-электронной» технической документации стоит не первый год, и скорого решения, к сожалению, не предвидится. И дело не только в технологических и юридических аспектах, но и в психологическом пороге восприятия. Сложные и непонятные большинству технологии электронной цифровой подписи (ЭЦП) подсознательно не вызывают доверия у пользователей. Особенно на фоне громких разоблачений преступлений в области цифровых технологий. На сегодняшний день одновременное существование «бумажной» и «электронной» технической документации воспринимается как объективная реальность. Параллельная разработка и актуализация и той, и другой вызывают множество вопросов как об эффективности затрачиваемых средств, так и о скорости вносимых изменений. Именно последний параметр в современной быстро изменяющейся экономической конъюнктуре зачастую является ключевым конкурентным преимуществом – тот, кто сможет быстрее предложить имеющий значение для потребителя товар или услугу, выиграет борьбу за рынок. Можно ли обратить недостатки параллельного существования «бумажной» и «электронной» технической документации в преимущество? Как быстро внести изменения в огромное количество документации? Как сократить издержки и поднять качество создаваемых вами документов? На эти и другие вопросы мы постараемся ответить в статье. Стандарт ASD S1000D.
ЗАО «Си Проект», г. Санкт-Петербург
Что же такое «бумажные» и «электронные» документы? Чем они различаются и чем схожи?
Если с электронным документом все достаточно просто, существует ГОСТ 2.051, который задает определение: «Электронный документ – это документ, выполненный как структурированный набор данных, создаваемых программно-техническим средством», – то с «бумажным» документом такой определенности нет.
Воспользуемся понятием «бумажный конструкторский документ» из ГОСТ 2.001 2013, которое определяется следующим образом: «Документ, выполненный на бумажном или аналогичном по назначению носителе (кальке, микрофильмах, микрофишах и т. п.). Бумажный конструкторский документ выполняют с целью использования или обработки (понимания) преимущественно человеком. Установленные подписи в бумажном конструкторском документе выполняют собственноручно». Если обратиться к ГОСТ Р ИСО / МЭК 15910-2002, под бумажным документом следует понимать «часть документации, представляемую в печатном виде», а согласно ГОСТ Р 52292-2004, это «форма представления документа в аналоговой среде». Но если дополнительно учесть тот факт, что в современных условиях практически все документы изначально создаются как электронные, то это еще больше запутывает ситуацию.
Сложилось общепринятое мнение, что к бумажному или к электронному типу документ относит его представление. В печатном представлении – бумажный документ, на цифровом носителе информации – электронный документ.
Предварительно сформулированные требования к представлению документа конечному пользователю определяют тип документа – бумажный или электронный. Именно это отличие накладывает требования на методику разработки документа.
Для разработки бумажной документации, ориентированной на печатное представление, более всего применима давно известная и часто используемая разработчиками программного обеспечения технология «единого источника» (рис. 1).
Рис. 1. Технология «единого источника»
Часто меняющиеся требования, которые невозможно сформулировать заранее при формировании ТЗ, вынуждают разработчиков программного обеспечения многократно изменять спецификации, формуляры, описание программы и различные руководства. Многочисленные изменения увеличивают затраты, сроки поставки программного обеспечения заказчику, накладывают опечаток на качество получаемой программной документации.
Чтобы нивелировать эти отрицательные факторы, и была сформулирована технология «единого источника». Суть ее состоит в создании отдельных модулей неформатированного текста и применении специальных правил для компиляции из них документов с целью получения единообразно представленной документации (рис. 2).
Рис. 2. Использование текстовых модулей из единого источника
Для быстрого внесения изменений достаточно откорректировать текст в модуле или иллюстрацию, автоматически настроенные правила соберут весь пакет измененной документации в определенном согласно ГОСТ виде.
Технология «единого источника» не представляет собой раз и навсегда сложившегося набора инструментов для работы, это скорее набор рекомендуемых практик, под которые, исходя из конкретных требований, подбирается инструментарий. Примером реализации технологии «единого источника» может считаться такая связка: редактор текста (Oxygen XML Editor, XMLMind, Syntext Serna), инструмент сборки документа из исходного формата (DITA, DocBook), единый источник хранения информации (системы контроля версий SVN, GIT, TFS или различные СУБД). Также возможны реализации на основе комплексных инструментов, объединяющих все три указанных компонента, например Author-It, Madcap Flare (рис. 3).
Рис. 3. Пример интерфейса Madcap Flare
Интересным способом применения данной технологии является сквозная разработка программной или конструкторской документации. Такой подход позволяет, отталкиваясь непосредственно от требований ГОСТ, формировать ТЗ, программу и методику испытаний, описание программы, руководство оператора или системного администратора. Во всей этой линейке документов будут использоваться модули текста, начиная с пунктов требований ГОСТ, что позволяет не только сократить затраты на изменения, но и сделать процесс разработки документации более прозрачным, непротиворечивым и однозначно понимаемым. То есть мы всегда сможем сказать, откуда появился, например, конкретный пункт руководства оператора, какому пункту ТЗ он соответствует и с каким требованием ГОСТ соотносится.
Еще одним неоспоримым преимуществом является возможность создавать и применять к документам единые правила оформления. Эта функциональность помогает значительно сократить труд нормоконтролёра и разработчика документации. Единообразно оформленная документация позволяет сократить затраты на включение документации от контрагентов в общую документацию.
В случае если разрабатываемая документация ориентирована на представление в электронном и тем более в интерактивном виде, наиболее эффективным будет применение технологий стандарта ASD S1000D*. Стандарт ASD S1000D был рожден в авиационной промышленности, известной своими высокими требованиями к обеспечению безопасности. В настоящий момент S1000D успешно применяется в судостроении, атомной энергетике, тяжелой промышленности и космосе. Это отработанные и зрелые общемировые практики, основанные на лучшем опыте. Суть данного стандарта составляют несколько основных принципов:
— единая база данных для хранения информации;
— модульная система, когда информация хранится в виде модулей – минимальных самостоятельных единиц в технической публикации;
маленькие электронные документы составляются в большие (публикации, информационные наборы);
— идентификация объектов по уникальным кодам специальной структуры;
— повторное использование модулей, информация не дублируется;
— документация на конкретную конфигурацию изделия «собирается из кубиков».
Методология стандарта S1000D заключается в формировании отдельных модулей данных, которые могут содержать как текстовые, так и параметрические (технические характеристики, ЗИП, ГСМ, планирование ТО) или процессные (поиск и устранение неисправности, контроль знаний обслуживающего персонала) данные. Отдельно формируются различные иллюстративные материалы, аудиокомментарии и справочные данные. Все эти элементы собираются на основе структурированного документа и могут быть выгружены из базы данных путем процесса публикации для просмотра в виде интерактивного электронного технического руководства (ИЭТР) через стандартный браузер, установленный у конечного пользователя. Модульность, непротиворечивость, повторное использование информации дают значительный прирост в скорости прохождения изменений информации в электронном документе. Интерактивное представление улучшает восприятие и удобство пользователя.
Одним из инструментов реализации требований стандарта S1000D может являться редактор интерактивных электронных технических руководств Seamatica. В самой функционально наполненной редакции Seamatica Enterprise реализуется весь комплекс мероприятий разработки ИЭТР. Как единое хранилище информации Seamatica использует СУБД PostgreSQL, с помощью интерфейса редактора (рис. 4) данное хранилище модульно заполняется информацией, из которой публикуется ИЭТР.
Рис. 4. Интерфейс редактора ИЭТР Seamatica Enterprise
Логической основой для формирования структурированных данных является функционально сборочная структура (ФСС) – многоуровневая иерархическая структура элементов заказа, сгруппированных по их функциональному назначению (рис. 5).
Рис. 5. Функционально-сборочная структура
На функционально-сборочную структуру нанизываются различные модули данных (МД), которые могут быть описательными (текстовыми), параметрическими (ЗИП, ГСМ, процедуры ТО, планирование ТО и т. д.), процедурными (поиск и устранение неисправностей), а также различными видами иллюстраций (рис. 6).
Рис. 6. Создание и редактирование модулей данных
Содержимым описательного модуля данных чаще всего является фрагмент текста исходного документа, то есть документа, материалы которого включаются в ИЭТР (рис. 7).
Рис. 7. Редактор описательных модулей данных с текстом исходного документа
Разработанные в функционально-сборочной структуре описательные, параметрические и процедурные модули данных, а также импортированные иллюстрации, видеоролики, звуковые комментарии и 3D-модели собираются, структурируются и интегрируются с помощью взаимных гиперссылок на базе непосредственного документа ИЭТР 1–3 классов (рис. 8).
Рис. 8. Создание и редактирование документа ИЭТР 1–3 классов
Результатом публикации получившегося документа является ИЭТР в веб-представлении и готовый для просмотра в браузере (рис. 9).
Рис. 9. Опубликованный ИЭТР 3‑го класса отражает структуру, заданную в документе Seamatica Enterprise
Поразительно, что технологии, придуманные в разных отраслях промышленности, так сильно совпадают в общих концепциях и подходах. Если они так похожи, то почему бы это не использовать в благих целях? Что будет, если объединить технологию разработки «единого источника» для «бумажно»-ориентированного документа и S1000D для создания интерактивных электронных руководств?
Не секрет, что большинство интерактивной электронной документации разрабатывается на основе документов «бумажной» направленности. Эта предпосылка дает нам возможность на основе двух разных технологий, «единого источника» и S1000D, выстроить единый и прозрачный процесс разработки технической документации.
Начало процесса должно быть положено с внесения ГОСТ, касающихся разработки электронной документации (2.051, 2.601, 2.602, 5488) в виде отдельных текстовых моделей разработки и сборки основных «бумажных» документов по технологии единого источника с формированием связей от пунктов требований ГОСТ до руководства пользователя.
Текстовые модули интерактивных электронных технических руководств должны формироваться на основе модулей текстовой информации «бумажных» документов (рис. 10).
Рис. 10. Схема интеграции технологии в процесс разработки ИЭТР по требованиям стандарта S1000D
Оба типа документов используют для создания, хранения и редактирования единую базу данных.
Приведенная методика может значительно сократить время разработки технической документации, убрать разрыв между «бумажной» и интерактивной электронной документацией, увеличить скорость прохождения изменений по цепочке «технический писатель – разработчик интерактивной электронной документации – конечный пользователь», сократить затраты на нормоконтроль, повысить прозрачность документации, существенно поднять ее качество, облегчить взаимодействие с контрагентами.
Высокая скорость изменений и качество – современные конкурентные преимущество для любой компании. Обеспечить эти преимущества без быстрого внесения изменений в техническую документацию невозможно.
Приведенная методика – всего лишь один из инструментов, позволяющих добиться быстрой и качественной разработки электронной технической документации. Для решения всего комплекса проблем требуется организация дискуссионной площадки, которую мы попытаемся создать в следующем году. Следите за нашими анонсами на сайте www.seaproject.ru.
______________________________
* S1000D // ASD (Европейская ассоциация авиационно-космической и оборонной промышленности) : [сайт]. URL: www.asd-europe.org/s1000d (дата обращения: 20.12.2017).
Статья опубликована в журнале «ИСУП» № 6(72)_2017
S1000D поддерживается Руководящим комитетом S1000D, в который входят члены правления из ASD, Ассоциации аэрокосмической промышленности США (AIA) и Ассоциации воздушного транспорта (ATA), а также представители национальной промышленности и обороны из большинства стран, которые в настоящее время используют спецификация.
СОДЕРЖАНИЕ
Основные принципы
S1000D требует, чтобы информация создавалась в виде отдельных элементов данных, называемых модулями данных (DM), которые структурированы с помощью элементов XML и метаданных. Каждый DM является автономным и может использоваться везде, где требуется эта информация. Они организованы в иерархическую структуру XML с помощью кодирования модуля данных. Это позволяет обновлять отдельные элементы данных без обязательного изменения пути в структуре XML, который указывает на них. Таким образом, разделенные и классифицированные таким образом знания могут быть разделены между многими публикациями, и обновление элементов в базовом контролируемом источнике автоматически повлияет на обновление зависимых публикаций. Фактическая иерархия XML должна быть разработана специально для каждой отдельной области знаний.
Связанные спецификации
Доступность
История проблемы
| Проблема | Дата | Базовый язык | Поправки |
|---|---|---|---|
| 1.6 | 31 марта 1995 г. | SGML DTD | |
| 1,7 | 01 февраля 1998 г. | SGML DTD | |
| 1,8 | 31 янв.1999 г. | SGML DTD | 1.8.1 от 31 мая 2000 г. |
| 1.9 | 01 апреля 2001 г. | SGML / XML DTD | |
| 2.0 | 31 мая 2003 г. | SGML / XML DTD, схема XML | |
| 2.1 | 29 февраля 2004 г. | SGML / XML DTD, схема XML | |
| 2.2 | 01 мая 2005 г. | SGML / XML DTD, схема XML | 2.2.1 от 1 мая 2006 г. (только схема XML) |
| 2.3 | 28 февраля 2007 г. | SGML / XML DTD, схема XML | 2.3.1 от 01 февраля 2009 г. |
| 3.0 | 31 июля 2007 г. | SGML / XML DTD, схема XML | 3.0.1 от 01 февраля 2009 г. |
| 4.0 | 01 августа 2008 г. | Схема XML | 4.0.1 от 12 мая 2009 г. 4.0.2 от 09 октября 2013 г. |
| 4.1 | 31 декабря 2012 г. | Схема XML | 4.1.A от 31 октября 2014 г. 4.1.B от 30 июня 2017 г. 4.1.C от 12 мая 2020 г. |
| 4.2 | 31 декабря 2016 г. | Схема XML | 4.2.A от 31 мая 2019 г. (только спецификация; без изменений схемы) |
| 5.0 | 28 июн 2019 | Схема XML | 5.0.A от 01 ноября 2019 г. (только спецификация; без изменений схемы) |
Программные решения
S1000D не предоставляет и не одобряет какие-либо программные инструменты для создания или распространения контента в соответствии со стандартом.
Программное обеспечение для разработки
Существует множество вариантов создания и поддержки контента в соответствии со спецификацией S1000D. Они варьируются от использования текстового редактора или простых инструментов XML с модулями данных, вручную поддерживаемыми в файловой системе, до полного решения ILS, в котором информация о дизайне и обслуживании управляет техническими публикациями через собственные базы данных и инструменты разработки. S1000D всегда был агностиком в определении инструментов, вместо этого предлагая рекомендации по ожидаемой функциональности и позволяя поставщикам предлагать подходящие решения. Каждый проект индивидуален, поэтому каждое решение следует рассматривать и адаптировать к желаемым результатам.
Программа просмотра
Точно так же, как существует несколько CSDB и решений для разработки, существует множество средств просмотра и возможностей для настройки вывода в соответствии с проектом. S1000D предлагает подробные инструкции по представлению постраничного и электронного вывода, но в конечном итоге это решение проекта относительно того, как контент должен быть доставлен. На практическую применимость различных решений влияют многие факторы, такие как окружающая среда, аудитория, доступность технологий, безопасность и многое другое.