Отраслевой формат технической документации на устройства железнодорожной автоматики и телемеханики. Часть 1: Концепция создания

Автоматизация проектирования

УДК 004.896+656.25

Д. В. Седых,

Д. В. Зуев, канд. техн. наук

Кафедра «Автоматика и телемеханика на железных дорогах»,

Петербургский государственный университет путей сообщения Императора Александра I

М. А. Гордон

Институт «Гипротранссигналсвязь» - АО «Росжелдорпроект»

ОТРАСЛЕВОЙ ФОРМАТ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ НА УСТРОЙСТВА ЖЕЛЕЗНОДОРОЖНОЙ АВТОМАТИКИ И ТЕЛЕМЕХАНИКИ.

ЧАСТЬ 1: КОНЦЕПЦИЯ СОЗДАНИЯ

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

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

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

системы автоматизированного проектирования; автоматизированное рабочее место по ведению технической документации; электронный формат технической документации; отраслевой формат технической документации

Введение

В настоящее время все проектные организации перешли на проектирование в электронном виде, с помощью компьютерного программного обеспечения. В транспортной отрасли применяются средства автоматизированного проектирования [1-4]. В чем по существу отличие такого проектирования от проектирования на бумаге? К сожалению, часто программные средства CAD (computer-added design) используются только как инструмент рисования и выполняют с помощью мыши функции карандаша и линейки на компьютерном экране.

Процесс проектирования является комплексным и должен предусматривать единую модель данных для описания проектируемой системы, так как части проекта зависимы между собой. Только построение единой модели может дать возможность контроля за выполнением отдельных разделов и их увязки с другими разделами проекта. Единая модель представляет собой единое описание структуры данных, необходимой для описания устройств железнодорожной автоматики. Такой подход позволит не только повысить качество проектирования, но и ввести в него элементы автоматизированной экспертизы и проверки проектной документации [5, 6].

Разработанный в НТЦ-САПР ПГУПС «Отраслевой формат технической документации на устройства сигнализации, централизации и блокировки» (ОФ-ТД-СЦБ) [7, 8] предусматривает общую часть описания технической документации (ТД) и чертежа.

1 Создание единой информационной среды — основное назначение отраслевого формата

Назначение разработанного формата состоит в создании единой информационной среды для повышения эффективности процессов информационного обмена «Автоматизированной системы управления хозяйством сигнализации, централизации и блокировки второго поколения» (АСУ-Ш-2), «Автоматизированного рабочего места по ведению технической документации» (АРМ-ВТД) [9] через автоматизированные системы АС ОБД-ТД ЖАТ, различных систем автоматизированного проектирования (САПР), а также систем технического диагностирования и мониторинга, работающих с ТД на устройства СЦБ:

- при проектировании, ведении и использовании ТД на уровне проектных организаций, на дорожном и дистанционном уровнях управления хо-

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

- разработке систем автоматизации проектирования и ведения ТД;

- хранении и архивировании ТД в отраслевом банке данных;

- работе с документацией на устройства железнодорожной автоматики и телемеханики (ЖАТ) других информационных систем.

Структура интеграции с использованием отраслевого формата представлена на рис. 1.

Приложе-

ние

Приложе-

ние

Приложе-

ние

Ядро интеграции

Приложе-

ние

Приложе-

ние

Приложе-

ние

Рис. 1. Интеграция на основе отраслевого формата данных

2 Цели создания отраслевого формата

Основными целями создания единого формата являются:

- обеспечение информационного обмена в интегрированной информационной технологической системе хозяйства сигнализации, централизации и блокировки отдельных систем: АСУ-Ш-2, КЗ АРМ-ВТД, различных САПР проектных организаций;

- повышение качества взаимодействия автоматизированных систем хозяйства Ш между собой и другими автоматизированными системами;

- повышение качества проектирования, ведения и хранения ТД;

- представление ТД на устройства СЦБ на этапах ее создания (проектирования), ведения и сопровождения в виде, учитывающем требования всех автоматизированных систем хозяйства Ш;

- обеспечение единства представления ТД на устройства СЦБ в ОАО «РЖД»;

- обеспечение взаимодействия проектных организаций с дорогами и со службой сигнализации, централизации и блокировки на уровне безбумажной технологии [10-14];

- ускорение процессов информационного обмена на всех уровнях проектирования и ведения ТД [15, 16];

- повышение показателей качества функционирования и эксплуатации систем железнодорожной автоматики и телемеханики [17, 18].

3 Основные требования к отраслевому формату

Наличие ряда готовых информационных систем в отрасли означает целый ряд требований к решению по разработке формата данных, который должен решать вопрос взаимодействия таких систем. ОФ-ТД должен обеспечивать взаимный обмен данными ТД на устройства СЦБ, возможность их чтения и обработки в любых организациях, использующих АСУ-Ш-2, КАСПР, АРМ-ВТД, ГИС ЖАТ, и представлять собой единый формат их описания в электронном виде. Это должен быть отраслевой формат обмена технической документацией.

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

- каталог примитивов; формат примитивов; каталог элементов; формат элементов;

- каталог типов технических документов; формат технических документов.

- базу данных библиотек элементов, включающую базу данных примитивов;

- базы данных элементов для каждого типа документов.

Можно выделить некоторые общие требования исходя из целей разработки (рис. 2):

1. ОФ-ТД не должен быть привязан к конкретной операционной системе, программному пакету или среде программирования.

2. ОФ-ТД должен обеспечивать серверную обработку информации.

3. ОФ-ТД должен обеспечивать возможность обработки информации без использования специфических средств источника информации, применявшихся для его создания САПР, АРМ-ВТД и др.

4. ОФ-ТД должен быть согласован со всеми заинтересованными сторонами и утвержден заказчиком.

5. ОФ-ТД должен поддерживаться группой сопровождения, расширяться по заявкам разработчиков с разрешения заказчика при обязательном сохранении преемственности баз наработанной ТД, баз данных и систем автоматизации проектирования и ведения ТД всех уровней.

6. ОФ-ТД должен разрабатываться с учетом использования информации, содержащейся в базе элементов «Оборудование» с целью ее использования всеми АС. При разработке любых систем автоматизации проектирования и ведения ТД, использующих внутренние форматы представления данных, должны разрабатываться конверторы информации в отраслевой формат ОФ-ТД с целью обеспечения возможности их использования в электронном виде всеми участниками единой системы документооборота.

7. ОФ-ТД должен учитывать динамику развития информационных систем и САПР и легко адаптироваться к любым требованиям, поступающим от разработчиков этих систем.

8. ОФ-ТД должен обеспечивать компактность хранения данных. Обеспечение указанного требования влияет на такие важные показатели функционирования подсистем различных АС, как расходы внешней памяти; скорость доступа к данным; скорость обмена по компьютерным сетям; эффективность обеспечения защиты и целостности данных; удобство архивирования и др.

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

10. ОФ-ТД должен обеспечивать возможность агрегирования объектов. Под агрегированием понимается возможность создания сколь угодно сложных объектов из базовых и составных объектов.

11. ОФ-ТД должен обеспечивать прозрачность данных для доступа. Под прозрачностью данных понимается следующее. Поскольку любой объект должен иметь унифицированный заголовок, который содержит информацию как о типе данных, так и о его размере, внешняя программа, не имея информации о структуре «чужих данных», все-таки имеет данные об их размере и, не нарушая целостности, может их игнорировать. Таким образом, создание дополнительных свойств объектов и даже внедрение новых объектов в файл не должно приводить к разрушению его общей структуры. Поэтому приложения, создавшие этот файл первоначально, также могут использовать эту информацию или нет.

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

Г Расширяемость по требованию Л Компактность хранения

г ^ ОФ-ТД с

Стандарт отрасли V Централизованная поддержка J

Рис. 2. Главные требования к ОФ-ТД

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

4 Выбор формата представления данных для ОФ-ТД-СЦБ

Широкое распространение продукции компании AutoDesk на мировом рынке обеспечило популярность формату DXF/DWG. Многие мировые разработчики программного обеспечения способствовали преобразованию графических данных в этот формат. Однако, наряду с неоспоримыми достоинствами, данный формат обладает и рядом недостатков. Главным из них является то, что DXF является форматом примитивной графики и мало применим для хранения структурированных данных.

Современные приложения требуют более гибкого протокола представления данных, по сравнению с DXF/DWG, и механизмы, позволяющие определять структуру документа и описывать содержащие в нем элементы. Данным требованиям удовлетворяет язык расширенной разметки -XML [19].

Разработанный ОФ-ТД-СЦБ способен представить всю необходимую документацию на устройства ЖАТ. ОФ-ТД-СЦБ содержит в себе не только информацию об изображении чертежа (в универсальном формате векторной графики - Scalable Vector Graphics (SVG)), но и модель изображенного на ней элемента или схемы. При этом приложение может извлекать необходимую информацию по требованию (только графику, или только модель, или и то и другое). Чертеж в ОФ-ТД может быть прочитан не только специализированным приложением, но и обычным браузером. В настоящее время в АРМ-ПТД ОФ-ТД уже используется для обмена информацией между соответствующими модулями, а также для обмена данными с другими системами [20].

5 Технологии, применяемые в ОФ-ТД

Документ ОФ-ТД описывается с помощью расширяемого языка разметки (XML) версии 1.0. Для представления графической информации используется подмножество языка структурированной векторной графики SVG. В документе также используется технология каскадных таблиц стилей (Cascading Style Sheets - CSS). Для представления форматированного текста используются языки XHTML и RTF.

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

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

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

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

Пример:

<Здание>Пост ЭЦ</Здание>

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

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

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

<Здание Ордината=”40”>Пост ЭЦ</Здание>

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

1. Атрибуты обеспечивают самую необходимую проверку типа данных.

2. Атрибуты не требуют конечного дескриптора и поэтому занимают меньше места.

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

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

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

6. Элементы позволяют создавать вложенные структуры. Если необходимо описать структуру какой-либо позиции данных, то единственная возможность состоит в использовании элементов. Элементы являются наилучшим вариантом и в том случае, если потребуется описать структуру элемента данных на более позднем этапе.

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

8. Элементы могут включать пробельные символы.

9. В элементах легче представить символы кавычек.

10. Элементы являются более удобными для представления больших значений или двоичных компонентов.

11. Уникальные идентификаторы для элементов данных обычно помещаются в атрибуты.

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

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

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

6 Система координат документа

Система координат документа определяет способ хранения графической информации в ОФ-ТД. Пользовательские системы координат задаются средствами работы с документом ОФ-ТД и могут отличаться от системы координат документа.

Начало системы координат документа находится в левом верхнем углу листа. Ось координат X направлена вправо, ось Y - вниз.

Единицы измерения всех расстояний в документе, связанных с изображением, - миллиметры. Размерность явно не указывается.

Углы записываются в градусах. Там, где имеет значение направление отсчета угла, значения увеличиваются по часовой стрелке.

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

7 Пространства имен документа

Пространство имен XML - это определяемая с помощью идентификатора коллекция имен, используемых в XML-документах для обозначения типов элементов и именования атрибутов. Пространство имен состоит из двух частей: идентификатора пространства имен и префикса пространства имен. Идентификатор пространства имен является просто строкой для уникально-

го определения пространства имен. Для достижения уникальности идентификаторов пространства имен в качестве идентификаторов рекомендуется использовать web-адреса. Пространства имен являются идентичными, если идентификаторы пространства имен совпадают с точностью до символа. Префикс является коротким заменителем идентификатора внутри документа.

В любом XML-документе должно быть определено хотя бы одно пространство имен. Для данного документа определено несколько фиксированных пространств имен.

В данном документе для сокращения описания ссылок на пространства имен упоминаются только префиксы, но это не означает, что могут использоваться только данные префиксы.

В рамках проведенной работы были разработаны следующие составляющие ОФ-ТД-СЦБ, каждый из которых получил собственное пространство имен (см. таблицу).

Таким образом, мы рассмотрели основные компоненты ОФ-ТД-СЦБ.

Разработанные составляющие отраслевого формата

Пре- фикс Идентификатор Пояснение

bsl http://www.imsat.spb.ru/OFTD/ashapes. AutoShapesLibrary/v1.0 Пространство имен для графических элементов

e http://www.imsat.spb. ru/OFTD/editor/v1.0 Пространство имен для неграфических элементов

PP http://www.imsat.spb. ru/OFTD/PropertyPlace/v1.0 Пространство имен для описания общих данных объекта

svg http://www.w3.org/2000/svg Пространство имен для элементов формата SVG

SSP http://www.imsat.spb. ru/OFTD/SchematicStationPlan/v1.0 Пространство имен для описания элементов схематического плана станции

DSP http://www.imsat.spb. ru/OFTD/DoubleStringsStationPlan/v1.0 Пространство имен для описания элементов двухниточного плана станции

RC http://www.imsat.spb. ru/OFTD/TrackCircuit/v1.0 Пространство имен для описания элементов рельсовых цепей

TS http://www.imsat.spb. ru/OFTD/TrackSection/v1.0 Пространство имен для описания элементов секций

CP http://www.imsat.spb. ru/OFTD/CablePlan/v1.0 Пространство имен для описания элементов кабельных сетей

TVZ http://www.imsat.spb. ru/OFTD/TableVZ/v1.0 Пространство имен для описания элементов таблиц взаимозависимости

Окончание таблицы

Пре- фикс Идентификатор Пояснение

SC http://www.imsat.spb. ru/OFTD/SchematicCircuit/vl.O Пространство имен для описания элементов принципиальных схем

WL http://www.imsat.spb. ru/OFTD/WiringLayout/v1.0 Пространство имен для описания элементов монтажных схем

RR http://www.imsat.spb. ru/OFTD/RelayRoom/v1.0 Пространство имен для описания элементов плана размещения оборудования

DSPP http://www.imsat.spb. ru/OFTD/DoubleStringsSpanPlan/vl.O Пространство имен для описания элементов путевых планов перегонов

SPP http://www.imsat.spb. ru/OFTD/SchematicSpanPlan/v1.0 Пространство имен для описания элементов путевых планов перегонов

AU http://www.imsat.spb. ru/OFTD/DeviceOfControl/v1.0 Пространство имен для описания элементов аппаратов управления

Заключение

ОФ-ТД железнодорожной автоматики прошел утверждение и внедрен для применения на пространстве ОАО «РЖД». Формат используется целым рядом программных продуктов для описания устройств и представления ТД на устройства автоматики и телемеханики, а также применяется в модулях отраслевых САПР и системы документооборота ТД ОАО «РЖД» (КЗ АРМ-ВТД). Планируется развитие системы для автоматизации процедуры документооборота не только по принципиальным решениям ЖАТ, но и по схемам технического диагностирования и их непрерывного мониторинга [21-24].

Основной особенностью ОФ-ТД-СЦБ является то, что он содержит не только информацию об изображении чертежа (в универсальном формате векторной графики - Scalable Vector Graphics (SVG)), но и модель изображенного на ней элемента или схемы. При этом приложение может извлекать необходимую информацию по требованию (только графику, или только модель, или то и другое). Чертеж в ОФ-ТД может быть прочитан не только специализированным приложением, но и обычным браузером. Сегодня ОФ-ТД уже используется для обмена информацией как между различными программными системами, так и для обмена внутри отдельных программных продуктов.

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

Библиографический список

1. Тележенко Т. А. Применение методов моделирования в системах автоматизированного проектирования / Т. А. Тележенко // Известия Петербургского университета путей сообщения. - 2006. - № 2. - С. 66-72.

2. Тележенко Т. А. Автоматизированная система экспертизы схемных решений ЖАТ / Т. А. Тележенко // Автоматика, связь, информатика. - 2009. - № 5. - С. 24-26.

3. Денисов Б. П. Автоматизация проектирования систем железнодорожной автоматики и телемеханики на базе АРМ- ПТД версии 6 / Б. П. Денисов, Н. И. Рубинштейн, С. Н. Растегаев, Н. Ю. Воробей // Актуальные вопросы развития систем железнодорожной автоматики и телемеханики : сб. науч. тр. ; под ред. Вл. В. Сапожникова. - СПб. : Петербургский гос. ун-т путей сообщения, 2013. -С. 66-74.

4. Булавский П. Е. Формализация алгоритмического описания систем обеспечения жизненного цикла железнодорожной автоматики и телемеханики / П. Е. Бу-лавский, Д. С. Марков, В. Б. Соколов, Т. Ю. Константинова // Автоматика на транспорте. - 2015. - Т. 1. - № 4. - С. 418-432.

5. Горбачев А. М. Автоматизация анализа, экспертизы и сверки технической документации системы железнодорожной автоматики и телемеханики / А. М. Горбачев // Известия Петербургского университета путей сообщения. - 2012. - № 4. -С. 73-78.

6. Безродный Б. Ф. Автоматизация проверки проектов на основе АРМ-ТЕСТ / Б. Ф. Безродный, М. Н. Василенко, Б. П. Денисов, Д. В. Седых // Автоматика, связь, информатика. - 2008. - № 3. - С. 22-24.

7. Седых Д. В. Применение отраслевого формата технической документации на устройства железнодорожной автоматики и телемеханики для интеграции приложений / Д. В. Седых, С. А. Суханов // Известия Петербургского университета путей сообщения. - 2005. - № 3. - С. 74-79.

8. Балуев Н. Н. Проблемы внедрения отраслевого формата / Н. Н. Балуев, М. Н. Василенко, В. Г. Трохов, Д. В. Седых // Автоматика, связь, информатика. - 2010. -№ 3. - С. 2.

9. Василенко М. Н. Развитие электронного документооборота в хозяйстве АТ / М. Н. Василенко, В. Г. Трохов, Д. В. Зуев, Д. В. Седых // Автоматика связь, информатика. - 2015. - № 1. - С. 14-16.

10. Василенко М. Н. Согласование и утверждение технической документации с использованием электронной цифровой подписи / М. Н. Василенко, П. Е. Булавский, Б. П. Денисов, Д. А. Имануилов // Наука и техника транспорта. - 2010. -№ 1. - С. 18-23.

11. Булавский П. Е. Обобщенная формализованная схема ведения заказных спецификаций / П. Е. Булавский, Д. С. Марков, Д. Х. Баратов // Известия Петербургского университета путей сообщения. - 2010. - № 2. - С. 63-74.

12. Насонов Г. Ф. Автоматизированная система мониторинга проектирования, производства, строительства и проведения пусконаладочных работ по системам СЦБ / Г. Ф. Насонов, М. Н. Василенко, П. Е. Булавский // Транспорт Российской Федерации. - 2010. - № 3. - С. 46-49.

13. Булавский П. Е. Методы оптимизации при координации взаимодействия организаций, участвующих в заказах оборудования для систем СЦБ / П. Е. Булавский, Д. Х. Баратов, Д. В. Зуев // Вестник Ростовского государственного университета путей сообщения. - 2010. - № 2. - С. 68-73.

14. Добряков И. А. Анализ документооборота дистанции СЦБ на основе международных стандартов / И. А. Добряков, П. Е. Булавский, Д. С. Марков // Известия Петербургского университета путей сообщения. - 2015. - № 2. - С. 39-47.

15. Булавский П. Е. Метод оценки времени на выполнение процессов электронного документооборота технической документации / П. Е. Булавский, Д. С. Марков // Развитие элементной базы и совершенствование методов построения устройств железнодорожной автоматики и телемеханики : сб. науч. тр. ; под. ред. Вл. В. Сапожникова. - СПб. : ФГБОУ ВПО ПГУПС, 2014. -С. 64-69.

16. Булавский П. Е. Методика оценки временных характеристик процессов электронного документооборота технической документации / П. Е. Булавский, Д. С. Марков // Автоматика на транспорте. - 2016. - Т. 2. - № 1. - С. 81-94.

17. Седых Д. В. Учет работы приборов с помощью АРМ-УРП / Д. В. Седых // Автоматика, связь, информатика. - 2007. - № 3. - С. 7-8.

18. Шаманов В. И. Обобщенная математическая модель процесса эксплуатации систем автоматики и телемеханики / В. И. Шаманов // Автоматика на транспорте. - 2016. - Т. 2. - № 2. - С. 163-179.

19. Хантер Д. XML. Работа с XML / Д. Хантер, Дж. Рафтер, Д. Фаусетт, Э. ван дер Влист, Д. Айерс. - М. : Диалектика, 2009. - 1344 с.

20. Седых Д. В. Интеграционные решения на основе отраслевого формата технической документации / Д. В. Седых // Транспорт Урала. - 2016. - № 4. - С. 52-57.

21. Лыков А. А. Техническое диагностирование и мониторинг состояния устройств ЖАТ / А. А. Лыков, Д. В. Ефанов, С. В. Власенко // Транспорт Российской Федерации. - 2012. - № 5. - С. 67-72.

22. Ефанов Д. В. Некоторые аспекты развития систем функционального контроля устройств железнодорожной автоматики и телемеханики / Д. В. Ефанов // Транспорт Урала. - 2015. - № 1. - С. 35-40.

23. Ефанов Д. В. Становление и перспективы развития систем функционального контроля и мониторинга устройств железнодорожной автоматики и телемеханики / Д. В. Ефанов // Автоматика на транспорте. - 2016. - Т. 2. - № 1. -С.124-148.

24. Ефанов Д. В. Функциональный контроль и мониторинг устройств железнодорожной автоматики и телемеханики : монография / Д. В. Ефанов. - СПб. : ФГБОУ ВО ПГУПС, 2016. - 171 с.

Dmitry V. Sedykh,

Denis V. Zujev

«Automation and remote control on railways» department, Emperor Alexander I St. Petersburg state transport university

Mikhail A. Gordon

Institute «Giprotranssignalsvjaz» - AO «Roszheldorproekt»

Industry framework for technical documentation for railway automation and remote control devices.

Part 1: Concept of design

From year to year the number of information systems in automation and remote control facilities is growing. Currently, there are software solutions that allow to carry on all the main processes related to automation and remote control devices, ranging from design processes to system operation. But the methodology of the building of these systems does not take into account the requirements of data exchange between them. As an integration solution, the technical documentation industry framework was developed for automation and remote control devices.

This article, being the first in the series of articles, describes the concept of creation and the fundamental terms of technical documentation industry framework was developed for signaling, centralization and blocking devices. This framework was developed as a tool of data integration of different information systems of the industry.

The article describes the existing information systems and tasks, that produce the requirements for system data integration. It also considers the goals of creating the industry framework, as well as the basic requirements for the transportation technical documentation formats. The article provides the analysis of formats, used in the world market, and describes the main disadvantages of existing solutions. The article also reviews the features of DWG/DXF format by AutoDesk, as it is currently the most common framework for design and presentation of technical documentation data. Based on these cons, the requirements for a new framework, that can be used as an industry-based, have been formulated. Also the selection of a language to describe and of basic architectural components of this framework has been done.

The article describes the basic features of the developed framework for data presentation, as well as its structure. It provides the review of the basic entities, needed to understanding the descriptions of documents within the industry framework. The article also presents the entire list of developed components of industry data framework.

computer-assisted design systems; ARM-VTD; electronic form of technical documentation; technical documentation industry framework

References

1. Telezhenko T. A. (2006). Application of simulating methods within the CAD systems [Primeneniye metodov modelirovaniya v sistemakh avtomatizirovannogo proyektirovaniya]. Proceedings of Petersburg transport university [Izvestiya Peterburgskogo universiteta putej soobshcheniya], issue 2, pp. 66-72.

2. Telezhenko T.A. (2009). Automated test system of ZhAT circuits [Avtomatizirovannaya sistema ekspertizy skhemnykh resheniy ZhAT]. Automation, communication, information science [Avtomatika, svyaz’, informatika], issue 5, pp. 24-26.

3. Denisov B. P., Rubinstein N. I., Rastegaev S. N., Vorobey N. Yu. (2013). Design automation of railway automation and remote control systems on the basis of ARM-PTD, v. 6 [Avtomatizatsiya proyektirovaniya sistem zheleznodorozhnoy avtomatiki i telemekhaniki na baze ARM-PTD versii 6]. Topical issues of development of railway automation and remote control systems: collection of scientific papers [Aktual’nyye voprosy razvitiya sistem zheleznodorozhnoy avtomatiki i telemekhaniki, sbornik nauchnykh trudov]; under the editorship of Vl. V. Sapozhnikov. St. Petersburg, Peterburg state transport university [Peterburgskiy gosudarstvennyy universitet putey soobshcheniya], pp. 66-74.

4. Bulavsky P. E., Markov D. S., Sokolov V. B., Konstantinova T. Yu. (2015). Formalization of algorithmic description of life-cycle supporting systems of railway automation and remote control [Formalizatsiya algoritmicheskogo opisaniya sistem obespecheniya zhiznennogo tsikla zheleznodorozhnoy avtomatiki i telemekhaniki]. Transport automation [Avtomatika na transporte], vol. 1, issue 4, pp. 418-432.

5. Gorbachev A. M. (2012). Automation of analysis, testing and checking of technical documentation of railway automation and remote control system [Avtomatizatsiya analiza, ekspertizy i sverki tekhnicheskoy dokumentatsii sistemy zheleznodorozhnoy avtomatiki i telemekhaniki]. Proceedings of Petersburg transport university [Izvestiya Peterburgskogo universiteta putej soobshcheniya], issue 4, pp. 73-78.

6. Bezrodny B. F., Vasilenko M. N., Denisov B. P., Sedykh D. V. (2008). Automation of project checking using ARM-TEST software [Avtomatizatsiya proverki proyektov na osnove ARM-TEST]. Automation, communication, information science [Avtomatika, svyaz’, informatika], issue 3, pp. 22-24.

7. Sedykh D. V., Sukhanov S. A. (2005). Implementation of industry framework for technical documentation of railway automation and remote control devices for applications integration [Primeneniye otraslevogo formata tekhnicheskoy dokumentatsii na ustroystva zheleznodorozhnoy avtomatiki i telemekhaniki dlya integratsii prilozheniy]. Proceedings of Petersburg transport university [Izvestiya Peterburgskogo universiteta putej soobshcheniya], issue 3, pp. 74-79.

8. Baluev N. N., Vasilenko M. N., Trokhov V. G., Sedykh D. V. (2010). Problems of implementation the industry framework [Problemy vnedreniya otraslevogo formata]. Automation, communication, information science [Avtomatika, svyaz’, informatika], issue 3, p. 2.

9. Vasilenko M. N., Trokhov V. G., Zuev D. V., Sedykh D. V. (2015). Electronic document management development within AT facilities [Razvitiye elektronnogo dokumentooborota v khozyaystve AT]. Automation, communication, information science [Avtomatika, svyaz’, informatika], issue 1, pp. 14-16.

10. Vasilenko M. N., Bulavsky P. E., Denisov B. P., Imanuilov D.A. (2010). Harmonization and approval of technical documentation using digital signature [Soglasovaniye i utverzhdeniye tekhnicheskoy dokumentatsii s ispol’zovaniyem elektronnoy tsifrovoy podpisi]. Transport science and technology [Nauka i tekhnika transporta], issue 1, pp. 18-23.

11. Bulavsky P. E., Markov D. S., Baratov D. Kh. (2010). General formalized diagram of order specifications processing [Obobshchennaya formalizovannaya skhema vedeniya zakaznykh spetsifikatsiy]. Proceedings of Petersburg transport university [Izvestiya Peterburgskogo universiteta putej soobshcheniya], issue 2, pp. 63-74.

12. Nasonov G. F., Vasilenko M. N., Bulavsky P. E. (2010). Automated monitoring system of design, production, construction and commissioning of StsB systems [Avtomatizirovannaya sistema monitoringa proyektirovaniya, proizvodstva, stroitel’stva i provedeniya pusko-naladochnykh rabot po sistemam STSB]. Transport of the Russian Federation [Transport Rossiyskoy Federatsii], issue 3, pp. 46-49.

13. Bulavsky P. E., Baratov D. Kh., Zuev D. V. (2010). Optimization methods for coordination of organization of enterprises, that participates in the ordering of equipment for StsB systems [Metody optimizatsii pri koordinatsii vzaimodeystviya organizatsiy, uchastvuyushchikh v zakazakh oborudovaniya dlya sistem STSB Avtomatizirovannaya sistema monitoringa proyektirovaniya, proizvodstva, stroitel’stva i provedeniya pusko-naladochnykh rabot po sistemam STSB]. Bulletin of Rostov state transport university [Vestnik Rostovskogo gosudarstvennogo universiteta putey soobshcheniya], issue 2, pp. 68-73.

14. Dobryakov I. A., Bulavsky P. E., Markov D. S. (2015). Analysis of document management of StsB distance on the basis of international standards [Analiz dokumentooborota distantsii STSB na osnove mezhdunarodnykh standartov]. Proceedings of Petersburg transport university [Izvestiya Peterburgskogo universiteta putej soobshcheniya], issue 2, pp. 39-47.

15. Bulavsky P. E., Markov D. S. (2014). Method of time assessment for performance of the processes of electronic technical documentation management [Metod otsenki vremeni na vypolneniye protsessov elektronnogo dokumentooborota tekhnicheskoy dokumentatsii]. Development of elements base and improvement of building methods for railway automation and remote control devices [Razvitiye elementnoy bazy i sovershenstvovaniye metodov postroyeniya ustroystv zheleznodorozhnoy avtomatiki i telemekhaniki], collection of research papers; under the editorship of Vl. V. Sapozhnikov. St. Petersburg, FGBOU VPO PGUPS, pp. 64-69.

16. Bulavsky P. E., Markov D. S. (2016). Methodology of time characteristics assessment of the processes of electronic technical documentation management [Metodika otsenki vremennykh kharakteristik protsessov elektronnogo dokumentooborota tekhnicheskoy dokumentatsii]. Transport automation [Avtomatika na transporte], vol. 2, issue 1, pp. 81-94.

17. Sedykh D. V. (2007). Hardware performance recording using ARM-URP [Uchet raboty priborov s pomoshch’yu ARM-URP]. Automation, communication, information science [Avtomatika, svyaz’, informatika], issue 3, pp. 7-8.

18. Shamanov V. I. (2016). Generalized mathematical model of the process of automation and remote control system operation [Obobshchennaya matematicheskaya model’

protsessa ekspluatatsii sistem avtomatiki i telemekhaniki]. Transport automation [Avtomatika na transporte], vol. 2, issue 2, pp. 163-179.

19. Hunter D., Rafter J., Fawcett J., Van der Vlist E., Ayers D. (2009). XML. Beginning XML. Мoscow, Dialektika, 1344 p.

20. Sedykh D. V. (2016). Integration solutions, based on technical documentation industry framework [Integratsionnyye resheniya na osnove otraslevogo formata tekhnicheskoy dokumentatsii]. Ural Trasport [Transport Urala], issue 4, pp. 52-57.

21. Lykov A.A., Efanov D. V., Vlasenko S. V. (2012). Technical diagnosis and monitoring of ZhAT devices state [Tekhnicheskoye diagnostirovaniye i monitoring sostoyaniya ustroystv ZhAT]. Transport of the Russian Federation [Transport Rossiyskoy Federatsii], issue 5, pp. 67-72.

22. Efanov D. V. (2015). Some aspects of developing of concurrent error detection (CED) systems of railway automation and remote control devices [Nekotoryye aspekty razvitiya sistem funktsional’nogo kontrolya ustroystv zheleznodorozhnoy avtomatiki i telemekhaniki]. Ural Trasport [Transport Urala], issue 1, pp. 35-40.

23. Efanov D. V. (2016). Formation and future of development of concurrent error detection and monitoring systems of railway automation and remote control devices [Stanovleniye i perspektivy razvitiya sistem funktsional’nogo kontrolya i monitoringa ustroystv zheleznodorozhnoy avtomatiki i telemekhaniki]. Transport automation [Avtomatika na transporte], vol. 2, issue 1, pp. 124-148.

24. Efanov D. V. (2016). Operational management and monitoring of railway automation and remote control devices [Funktsional’nyy kontrol’ i monitoring ustroystv zheleznodorozhnoy avtomatiki i telemekhaniki]: monograph. St. Petersburg, Publishing house of Petersburg transport university [Izdatel’stvo Peterburgskogo universiteta putej soobshcheniya], 171 p.

Статья представлена к публикации членом редколлегии М. Н. Василенко Поступила в редакцию 14.08.2016, принята к публикации 14.10.2016

СЕДЫХ Дмитрий Владимирович - инженер кафедры «Автоматика и телемеханика на железных дорогах» Петербургского государственного университета путей сообщения Императора Александра I. e-mail: sedyhdmitriy@gmail.com

ЗУЕВ Денис Владимирович - руководитель НТЦ-САПР кафедры «Автоматика и телемеханика на железных дорогах» Петербургского государственного университета путей сообщения Императора Александра I.

e-mail: zuevdv@gmail.com

ГОРДОН Михаил Аркадьевич - главный специалист института «Гипротранс-сигналсвязь» - филиала АО «Росжелдорпроект». e-mail: gordon_ma@mail.ru

© Зуев Д. В., Седых Д. В., Гордон М. А., 2017