CC BY
102
№ 1 (49) 2014
В. М. Артюшенко, докт. техн. наук, профессор, зав. кафедрой Информационных технологий и управляющих систем Финансово-технологической академии, г. Королев, artuschenko@mail.ru
Б. А. Кучеров, аспирант Финансово-технологической академии, г. Королев, boris.ku4erov@gmail.com
организация информационного обмена между элементами наземного комплекса управления группировкой космических аппаратов
В статье проведен анализ особенностей информационного обмена между элементами наземного комплекса управления космическими аппаратами . Выявлены проблемные моменты как технического, так и организационного характера . Предложены варианты автоматизации информационного обмена, дано их описание и сравнительный анализ, рассмотрены вопросы их реализации Предложенные варианты были реализованы и апробированы в органе планирования . Полученные результаты показали, что использование предложенных вариантов информационного обмена позволяет значительно повысить оперативность управления группировкой космических аппаратов .
Ключевые слова: информационный обмен, база данных, XML, программное обеспечение, абонент, космический аппарат
введение
В настоящее время, согласно Федеральной космической программе России на 2006-2015 гг., идет бурное наращивание группировки космических аппаратов (КА). В связи с этим предъявляются совершенно новые требования к процессу их управления [1, 2].
Управление группировкой КА — очень сложный технический процесс. В нем задействовано большое количество элементов наземного комплекса управления космическими аппаратами, к которым относятся: центры управления полетом КА, командно-измерительные пункты, орган планирования, сектора главных конструкторов КА, баллистический центр, потребители целевой информации и т. д. [1, 2]. При управлении группировкой космических аппаратов неизбежно возникает необходимость взаимодействия между собой этих элементов. Следовательно, очень остро встает задача организации информационного обмена между ними.
особенности информационного обмена при управлении кА
Информация, подлежащая обмену, носит различный характер. Можно выделить две крупные категории. Первая — оперативная информация, вторая — информация, срок передачи которой жестко не установлен. Часть оперативной информации может передаваться в режиме, близком к режиму реального времени. Передача информации в таком режиме, так же как и передача информации с КА, является узкоспециализированной задачей, решаемой разработчиками КА и центров управления полетом, и выходит за рамки настоящей статьи.
Передаваемая информация включает исходные данные для работы целевой аппаратуры КА, заявки на использование приемопередающих средств, исходные данные для планирования работ КА, отчеты об управлении КА и т. д.
Например, потребители целевой информации могут направлять в центры управле-
№ 1 (49) 2014
ния полетом сведения, мотивирующие применение целевой аппаратуры КА (время и место проведения дистанционного зондирования Земли, сведения о необходимой ретрансляции информации и т. п.). Сектора главных конструкторов взаимодействуют с центром управления полетом в части обмена подробными сведениями о состоя-,в нии КА. Так, при возникновении нештатной ¡5 ситуации на космическом аппарате центр § управления полетом сообщает в сектор <§ главного конструктора информацию о воз-| никшей ситуации (данные о состоянии бор-| товой аппаратуры КА на основе телеметри-г| ческой информации, выдаваемые оператору * сообщения, и т. д.). Сектор главного конст-§ руктора запрашивает уточняющую инфор-Ц мацию, выдает рекомендации по выходу Ц из сложившейся ситуации и т. д. & Другим примером может служить рас-| пределение временного ресурса приемо-| передающих средств. Центр управления по-[I летом выдает в орган планирования заявку и на использование средств. Орган планиро-<5 вания передает в центр управления резуль-§ таты рассмотрения поданной заявки. В ор-§ ганизации, эксплуатирующие приемо-пе-
0 редающие средства, передаются выписки Ц из плана загрузки данных средств. Помимо | этого, осуществляется обмен сведениями Ц о ресурсных ограничениях по использова-§ нию средств и о приоритетности поданных | заявок. К ресурсным ограничениям относят-§ ся состояние средств, зоны радиовидимо-^ сти средствами КА и т. д. Приоритетность
1 заявок может характеризоваться работами, | проводимыми с КА, и состоянием КА.
Л
о
| Проблемы автоматизации
| информационного обмена
И
Л По мере увеличения количества КА воз-
Л растают объемы информации, передавае-
Л мой между элементами наземного комплекса управления. Автоматизация информаци-
<8 онного обмена позволяет повысить его опе-
5
| ративность и как следствие оперативность § управления группировкой КА в целом. Одна-
ко автоматизация информационного обмена затрудняется рядом технических и организационных причин.
К техническим причинам следует отнести разнородность используемых программных средств, жесткую политику безопасности компьютерных сетей абонентов и т. д. К организационным причинам — проблемы финансирования разработки программного обеспечения (ПО) обмена, нежелание отходить от устоявшейся технологии неавтоматизированного обмена (так как это требует трудовых, временных, финансовых и других затрат, в том числе переобучения персонала) и т. д. Даже при наличии разработанных программных средств обмена их внедрение бывает затруднено.
В настоящее время часто создаются новые структуры, с которыми другим абонентам необходимо вести информационный обмен. Но в проектной документации и техническом задании на создание аппаратно-программных средств абонентов информационное взаимодействие с новой структурой не предусмотрено, так как на момент разработки документации о структуре ничего не было известно. Это создает дополнительные проблемы.
Во-первых, неясен источник финансирования разработки программных средств обмена с вновь созданной структурой. Во-вторых, в случае если ПО уже разработано, то полноценная интеграция функции ведения обмена в ПО зачастую затруднена, а порой просто невозможна, так как обмен не был предусмотрен. Как результат — приходится создавать ПО обмена, которое не встраивается полностью в существующее решение и создает дополнительные трудности при работе персонала с этим ПО.
Программные средства автоматизации информационного обмена
Использование нескольких вариантов автоматизированного информационного обмена, описанных далее, позволяет решить часть вышеперечисленных проблем.
№ 1 (49) 2014
Предложенные варианты информационного обмена были реализованы и опробованы в органе планирования [1, 2]. Для этого было разработано специальное ПО, построенное по клиент-серверной двухуровневой архитектуре. В таком случае логика приложений распределена между клиентом и сервером, а максимально возможная часть бизнес-логики перенесена на сервер.
В качестве системы управления базами данных (СУБД) была выбрана СУБД Oracle. Клиентская часть ПО разработана в среде Embarcadero С++ Builder XE2 из состава Embarcadero RAD Studio XE2 с использованием Devart Oracle Data Access Components. Указанные компоненты используются для обращения клиентского ПО к базе данных (БД). Они обеспечивают подключение к БД как в режиме клиента через ПО Oracle Client, так и в прямом режиме по протоколу TCP/IP (Transmission Control Protocol / Internet Protocol). Использование прямого режима исключает необходимость установки на клиентский компьютер дополнительного ПО, обеспечивающего доступ к данным (такого как Oracle Client, ODBC-драйвер и т. п.).
обмен через программу-клиента
Первый вариант автоматизированного информационного обмена — обмен через программу-клиента, устанавливаемую на стороне одного из абонентов и обращающуюся в базу данных другого абонента. В этом случае один абонент выступает в качестве сервера, другой — в качестве клиента. Оператором абонента-клиента осуществляется ввод в программу сведений для передачи абоненту-серверу и их последующей записи в базу данных, а также просмотр на экранных формах и вывод на печать сведений, поступающих из БД абонента-сервера. Обращение программы к БД напрямую по протоколу TCP без использования дополнительных средств позволяет упростить ее установку.
К достоинствам такого варианта можно отнести простоту и оперативность органи-
зации информационного обмена (достаточ- Ц но установить специальное ПО на сущест- jL. вующий или новый компьютер абонента- ^ клиента), а также отсутствие необходимости доработки специального ПО абонента-клиен- ig та для реализации информационного обме- | на с абонентом-сервером [2, 3]. Достоинства Si данного варианта обмена особенно заметны ^ в тех случаях, когда один абонент взаимодей- со ствуют с несколькими однотипными абонентами, например, когда орган планирования взаимодействует с центрами управления полетом КА. К недостаткам относится отсутствие интеграции информационного обмена в работу специального ПО абонента-клиента. Это, в свою очередь, ведет к дополнительной нагрузке на оператора по вводу данных в специальное ПО абонента-клиента [2, 3].
обмен непосредственно между базами данных абонентов
Второй вариант автоматизированного информационного обмена — обмен непосредственно между базами данных двух абонентов (рис. 1) [2, 4].
Для обеспечения такого варианта информационного обмена необходимо в БД каждого абонента создать учетную запись для другого абонента, которому должны быть предоставлены необходимые права доступа к объектам БД.
Организация доступа из одной БД в другую зависит от используемых СУБД. В частности, крупные СУБД, такие как Oracle и Microsoft SQL Server, обеспечивают указанную возможность.
Рассмотрим реализацию описанного обращения на примере СУБД Oracle.
Обращение из БД Oracle к БД, работающей под управлением другой СУБД, может осуществляться посредством ODBC-драй-вера и гетерогенного сервиса СУБД Oracle (Oracle Heterogeneous Service). Для реализации такого варианта обращения следует:
1. Установить на сервер БД ODBC-драй-вер для СУБД абонента (если он отсутствует).
№ 1 (49) 2014
«Прозрачный» доступ к не-Oracle БД
dblink Oracle
Net
Oracle Heterogeneous Service ODBC
БД абонента (не-Oracle)
I
Ü
«о
I §
i s
'SS
s
0
1
I
s t
I
I
s e
0
1 §
1
is
I §
!
P Л
о
e
о
ï
0
и
1
I
I
I
dblink Oracle Net
БД абонента (Oracle)
БД абонента (Oracle)
Прямой доступ к Oracle БД
Рис. 1. Схема информационного обмена органа планирования с внешними абонентами непосредственно между базами данных
2. Создать системный источник данных ODBC для БД абонента, использующий установленный ранее ODBC-драйвер.
3. Выполнить настройку гетерогенного сервиса СУБД Oracle, позволяющего, как известно, подключаться к любым базам данных, поддерживающим интерфейсы ODBC или OLE DB.
4. Создать имя службы TNS (Transparent Network Substrate) для гетерогенной БД. Строка подключения TNS указывает ПО Oracle способ подключения к удаленной базе данных. В общем случае ПО обращается к конфигурационному файлу «tnsnames.ora».
5. Добавить гетерогенную БД в список сервисов процесса прослушивания СУБД Oracle. Процесс прослушивания обеспечивает физическое подключение к базе данных.
6. Создать связь базы данных (database link) — объект БД, описывающий, как подключиться к другому экземпляру БД из текущего.
Заметим, что если внешний абонент использует СУБД Oracle, то ODBC-драйвер не требуется. В таком случае достаточно выполнить п. 4-6 из вышеприведенного списка шагов. При обращении к объектам удаленной БД название созданной связи указывается в качестве постфикса имени объекта.
Рассмотрим реализацию передачи данных непосредственно между базами данных
абонентов подробнее. Можно выделить два подхода к решению этой задачи. Один подход предполагает только чтение информации из БД другого абонента. Чтение может осуществляться как по оповещению от абонента, предоставляющего данные для просмотра, так и по расписанию. Другой подход предполагает запись сведений в удаленную БД. Причем в этом случае все наборы данных обмена (таблицы или хранимые запросы, представления) могут находиться как в БД только одного из двух абонентов, так и в БД каждого абонента. Термин «набор данных» используется с целью подчеркнуть свободу выбора при реализации обмена каждым абонентом. При втором подходе обработка поступивших данных может осуществляться не только по оповещению или расписанию, но и по триггеру. Оба подхода имеют как свои достоинства, так и недостатки.
При первом подходе удаленному абоненту предоставляются права доступа только на чтение определенных наборов данных. Также при необходимости предоставляются права на вызов хранимых процедур для оповещения абонента о доступности новой информации для чтения. При втором подходе предоставляются права на вставку данных или на вызов хранимых процедур, которым данные передаются в качестве параметров.
36
№ 1 (49) 2014
Чтение данных из удаленной БД осуществляется внутри хранимых процедур, которые обрабатывают полученные данные и записывают их в таблицы БД получателя. Причем каждому типу сообщения соответствует отдельная хранимая процедура. Эти процедуры могут вызываться пишущей стороной из удаленной БД или запускаться по расписанию с помощью заданий (пакет DBMS_ SCHEDULER).
В СУБД Oracle чтение и изменение удаленного набора данных может быть выполнено обычными SQL-запросами с указанием имени связи базы данных (dblink) в качестве постфикса имени набора данных. Для вызова удаленных хранимых процедур может быть использован пакет DBMS_HS_ PASSTHROUGH также с указанием связи базы данных. С помощью указанного пакета удаленным процедурам могут быть переданы требуемые параметры.
В качестве наборов данных, в которые должна осуществляться запись данных удаленным абонентом, могут использоваться представления. В этом случае вставка данных в представление может быть реализована с помощью триггеров замещения операций манипулирования данными.
Заметим, что использование связи базы данных накладывает ряд ограничений. Среди них следует отметить отсутствие возможности подписки на изменение набора данных через механизм Oracle Change Notification.
К достоинствам такого варианта следует отнести возможность интеграции информационного обмена в работу специального ПО абонентов. К недостаткам — необходимость доработки специального ПО каждого абонента, которая обусловлена уникальностью БД каждого абонента-клиента, а унификация обмена между БД затруднительна по техническим и организационным причинам [2, 3].
обмен хт/-файлами
Третий вариант автоматизированного информационного обмена — передача xml-до-
кументов, которая осуществляется посред- Ц
ством файлового обмена через ^Р-сервер ^
или через стороннее ПО передачи файлов, ^ работающее с локальными директориями.
Обработка и формирование хт/-документов ^
происходит в БД. Запись файлов в обмен- |
ные директории и чтение файлов из таких ^
директорий осуществляется службами, ра- ^
ботающими на компьютере обмена [2]. Схе- со ма такого информационного обмена отражена на рис. 2.
варианты осуществления файлового обмена
При использовании ^Р-сервера на нем организуется иерархия директорий, обеспечивающая обмен файлами между всеми заинтересованными абонентами. Абонентам предоставляются только необходимые права доступа, т. е. абонент не может прочитать файл из директории другого абонента или записать файл в директорию, где он не является отправителем. Это позволяет исключить несанкционированные файловые операции на ^Р-сервере, повышая тем самым безопасность обмена. Исторически сложилось, что обмен между многими абонентами, созданными достаточно давно, осуществляется именно через FTP-директории. При этом обмен в большинстве случаев происходит текстовыми и двоичными файлами, а не хт/-файлами.
Стороннее ПО позволяет передавать абонентам файлы, записанные в локальные директории. При этом для каждой директории, из которой осуществляется отправка файлов, указывается получатель. После отправки файла он удаляется из локальной директории. Перед удалением стороннее ПО сверяет контрольные суммы исходного и полученного удаленным абонентом файлов.
При любом способе файлового обмена на стороне отправителя должно функционировать ПО, записывающее файлы в обменные директории, а на стороне получателя — ПО, принимающее файлы из обменных
№ 1 (49) 2014
Р Л
о
12
о £
0 £
1
I 1 I I
Сервер базы данных
формирование хт/-документа
исходные данные для хт/-докумнета
таблицы базы данных
сформированный хт/-документ
а
н
I
ш
Исходящие хт/-документы
выданный хт/-документ
йн
к ^ 8 ? * I
Журнал выдачи хт/-документов
////
Журнал приема хт/-документов
запись принятого хт/-документа в журнал приема
обработка хт/-документа
принятый
хт/-документ
служба выдачи хт/-документов
служба приема хт/-документов
Рис. 2. Схема информационного обмена хт/-файлами
директорий. ПО приема файлов опрашивает обменные директории и при обнаружении файла обрабатывает его, после чего удаляет из директории приема.
К достоинствам использования ^Р-сер-вера следует отнести использование стандартного протокола и отсутствие необходимости в установке специализированного ПО передачи файлов на компьютер обмена. К недостаткам — необходимость в допол-
нительном оборудовании для организации FTP-сервера.
К достоинствам использования стороннего ПО можно отнести большую защищенность передаваемых данных и отсутствие необходимости в дополнительном оборудовании. К недостаткам — зависимость стабильности работы обмена от стабильности работы стороннего ПО на компьютерах обмена всех абонентов.
38
№ 1 (49) 2014
Прием и передача хт/-документов
Программы приема и передачи файлов состоят из двух частей: служба приема файлов и пользовательский интерфейс.
Служба приема файлов осуществляет просмотр локальных и РТР-директорий, чтение файлов из них и передачу содержимого файлов в БД для последующей обработки. С помощью пользовательского интерфейса программы приема файлов осуществляется настройка директорий для приема файлов, а именно указываются директория приема, директория для записи принятых файлов (архив) и отправитель по умолчанию, если в полученном сообщении он не указан.
Для получения сведений от абонентов служба приема хт/-документов, работающая на компьютере, периодически опрашивает директории приема хт/-файлов (как локальные директории, так и директории на РТР-серверах). Был проведен анализ возможностей получения оповещений о файловых операциях в заданной директории средствами операционной системы с целью исключить опрос директорий по расписанию. Однако все найденные способы не гарантируют доставку оповещения о файловой операции. При осуществлении информационного обмена это недопустимо, так как может привести к исключению из обработки отдельных входящих документов, поэтому было принято решение опрашивать директории.
Заметим, что время задержки приема файла, обусловленное периодом опроса директорий, несущественно. Заметного увеличения загруженности компьютера при этом не наблюдается.
Обработка входных хт/-документов, полученных от абонентов, происходит следующим образом. При обнаружении хт/-файла в обменной директории служба приема передает его содержимое в качестве параметра в пакетную процедуру обработки входных документов. Там определяется тип входного документа и запускается соответствующая процедура обработки. Ею осуществляется
разбор документа, контроль корректности §. данных и запись данных в соответствующие JL. таблицы БД. После обработки файл переме- ^ щается из обменной директории в директорию принятых файлов (архив). Если в про- ig цессе обработки файла произошла ошибка, | то он перемещается в директории ошибоч- ^ ных файлов. В этом случае данные о воз- ^ никшей ошибке фиксируются в журнале со приема хт/-документов.
После передачи хт/-документа в БД формируется квитанция о его получении. Она представляет собой хт/-документ, который записывается в таблицу исходящих документов.
Служба выдачи хт/-документов, работающая на компьютере обмена, периодически опрашивает БД на наличие исходящих xm/-документов. При обнаружении исходящего хт/-документа служба осуществляет формирование хт/-файла, содержащего заданный хт/-документ, и запись его в локальную директорию компьютера или в директорию на FTP-сервере. После этого хт/-документ перемещается в БД из исходящих в отправленные хт/-документы.
В настоящее время реализован опрос таблицы службой, но в дальнейшем планируется ее модернизация. Предлагается использовать вместо опроса механизм Oracle Advanced Queuing для оповещения о наличии нового документа, готового к выгрузке.
Служба выдачи файлов осуществляет запись в локальные и FTP-директории файлов, содержимое которых сформировано в БД и готово к отправке. С помощью пользовательского интерфейса программы выдачи файлов осуществляется настройка директорий для записи сформированных хт/-доку-ментов. Для этого выбираются абонент и тип передаваемой информации и указывается директория, в которую следует записывать хт/-файлы.
Формирование хт/-документов для передачи абонентам происходит следующим образом. При наступлении события, по которому необходимо осуществлять передачу сведений внешнему абоненту, в БД форми-
№ 1 (49) 2014
руется текст хт/-документа. Запуск процедуры формирования выходных документов осуществляется из процесса, изменяющего исходные данные, с помощью триггера или хранимой процедуры. Для выполнения достаточно долгих действий запуск формирования хт/-документа осуществляется в задании, выполняемом однократно ,в в асинхронном режиме. Для создания зада-| ний используется PL/SQL-пакет DBMS_JOB g (PL/SQL — Procedural Language / Structured <s Query Language). Это позволяет избежать | увеличения времени выполнения основного | процесса ввиду ожидания завершения фор-g мирования выходных документов. * Для сформированного хт/-документа ука-§ зывается директория, в которую он должен Ц. быть в дальнейшем выгружен. Директория Ц определяется исходя из типа информации, 5- содержащейся в хт/-документе, и получателя | хт/-документа. Данный хт/-документ считает-| ся исходящим (ожидающим отправления). [I Перед реализацией обмена абоненты и разрабатывают и подписывают протокол <g информационного обмена. В нем указыва-Ц ются технические и программные средства, § используемые при обмене, а также состав
0 и структура передаваемой информации. Для Ц описания хт/-документов, которыми осуще-| ствляется обмен, используются соответст-! вующие хт/-схемы. Это позволяет сделать § протоколы информационного обмена более | понятными и формализованными.
§ При просмотре журнала приема и пере-g дачи хт/-документов через соответствующую
1 программу осуществляется их преобразова-! ние в HTML-страницу с помощью xslt-шаб-Л лона (xslt — extensible Stylesheet Language g Transformations). Преобразование осуществ-| ляется на стороне сервера с помощью функ-Ц ции XMLTransform, принимающей в качест-| ве параметров хт/-документ и xslt-шаблон
и возвращающей HTML-документ. Для отображения сформированного htm/-докумен-та в пользовательский интерфейс программ | встроен веб-браузер. Таким образом, польза зователь просматривает хт/-документ в по-§ нятном ему виде (например, табличном).
инфологическая модель для обеспечения обмена ^/-документами
Была спроектирована инфологическая модель в соответствии с нотацией IDEF1X, обеспечивающая хранение передаваемых и принимаемых хт/-документов (рис. 3).
На основании инфологической модели было выполнено даталогическое проектирование. Инфологическое и даталогическое проектирование выполнялось с помощью AllFusion ERwin Data Modeler версии 7.3. Для хранения хт/-документов в таблицах БД использовались поля типа XMLType. Для передачи хт/-документов в хранимые процедуры использовались параметры этого же типа. Кроме того, по каждому документу хранятся сведения, касающиеся его приема или передачи (времени и директории приема/передачи документа, компьютера, с которого был осуществлен прием/передача и т. д.).
Формирование и разбор хт/-документов в БД осуществляется с помощью хт/-функ-ций XMLForest, XMLParse и т. п. Данный вариант организации информационного обмена наиболее приоритетен. Его главными достоинствами являются унификация обмена между абонентами и возможность интеграции информационного обмена в работу специального ПО абонентов. К недостаткам следует отнести необходимость доработки специального ПО абонентов для реализации информационного обмена при организации обмена с абонентом нового типа, а также необходимость в средствах передачи xm/-документов, например FTP-сервера. Возможна комбинация данного варианта организации информационного обмена с предыдущим, т. е. передача хт/-документов через обменные таблицы БД [2, 3].
обмен ^/-документами посредством электронной почты
До недавнего времени трех указанных способов обмена было достаточно, но, как показала практика, возможны ситуации,
Отправленный ХЖ-документ
Статус в квитанции
Код отправленногоХЖ-документа
Название документа
Документ
Время отправки
Имя отправленного файла
Время приема квитанции о получении
документа
Время получения документа абонентом
Код статуса (РК)
Код директории выгрузки (РК)
Код статуса
Название
-
Информационный обмен Входящий ХЖ-документ
Исходящий ХЖ-документ
Код исходящего ХЖ-документа
Название документа Имя файла Документ Тип информации Время формирования Код директории выгрузки (РК)
Директория приема Код директории приема Имя компьютера Директория
Директория для архива Используется
Код входящего документа
Код директории приема (РК)
Время приема
Имя файла
Название
Документ
Отправитель
Время отправления
Примечание
Директория выгрузки
Абонент
Код абонента
Название абонента
Ъ-
Код директории выгрузки
Имя компьютера Тип информации Директория Используется Код абонента (РК)
□ С
РТР-директория приема Код директории приема (РК)4
Адрес РТР-сервера
Логин
Пароль
Локальная директория приема
■ ^
Код директории приема (РК)
Ошибка при обработке входящего документа Код ошибки при обработке_
РТР-директория выгрузки ^Код директории выгрузки (РК) ^
Адрес РТР-сервера Логин >Пароль
Локальная директория выгрузки Код директории выгрузки (РК)
Время приема Директория ошибки Имя файла Текст ошибки Документ
Код директории приема (РК)
Рис. 3. Инфологическая модель, обеспечивающая хранение передаваемых и принимаемыххт/-документов
В. М. Артюшенко, Б. А Кучеров
№ 1 (49) 2014
когда не удается наладить прямую связь между абонентами, что обусловлено в большей степени организационными, нежели техническими трудностями. Поэтому предлагается ввести новый способ обмена — обмен хт/-документами посредством электронной почты, что позволит, с одной стороны, автоматизировать обмен с абонентами, с ко-,в торыми отсутствует прямая связь, а с дру-S5 гой — интегрировать такой обмен в работу g специального ПО абонентов. Предполагает-<s ся, что у каждой из сторон будет функцио-| нировать программа, обращающаяся к элек-| тронной почте и при получении формализо-g ванного сообщения выполняющая его обра* ботку с последующей записью в БД. § Для идентификации писем автоматизи-Ц. рованного обмена возможно использование Ц формализованной темы письма. При этом 5- хт/-документ может являться текстом пись-| ма или вложением к письму. Другая про-§ грамма будет автоматически формировать Ц. такие формализованные письма и отправ-то лять их. Это позволит разгрузить операто-<g ров от рутинной работы по вводу входящих § сведений в БД. Также к достоинствам ука-§ занного варианта можно отнести унифика-
0 цию обмена, что в условиях наращивания Ц количества КА, и как следствие увеличения | числа абонентов, является весьма актуаль-! ной задачей [1, 2].
§ Работа с электронной почтой может быть | реализована как с клиентского компьютера, § так и непосредственно с сервера БД. Со-g временные СУБД предоставляют функцио-
1 нал для работы с электронной почтой. Так, ! в СУБД Oracle для реализации этого вариан-Л та обмена может быть использован PL/SQL-g пакет UTL_SMTP. С помощью средств СУБД | возможно реализовать как отправку писем Ц с вложенными хт/-файлами, так и их прием. Л Реализация работы с почтой на сервере БД Л предпочтительна.
Данный вариант информационного обме-| на базируется на обмене хт/-файлами. Это <? значит, что значительная часть специаль-| ного ПО является универсальной для обоих § способов информационного обмена. Раз-
личаться будут только модули, отвечающие за получение и выгрузку содержимого хт/-документа (в директории или электронную почту, соответственно), т. е. при наличии отлаженного обмена хт/-файлами возможно малыми затратами организовать обмен хт/-документами посредством электронной почты (и наоборот — при налаженном обмене по электронной почте организовать обмен хт/-файлами). Фактически службы приема и выдачи файлов заменяются процедурами работы с электронной почтой. Возможно также рассмотрение электронной почты как директории.
Заключение
Унификация автоматизированного информационного обмена с помощью предложенных вариантов его осуществления позволяет, помимо прочего, снизить затраты на подключение новых абонентов. Разработка протокола информационного обмена может быть выполнена на основе типового протокола с уточнением в нем сведений, касающихся координат абонентов для установления связи между ними. Затраты на разработку ПО обмена будут снижены, а в некоторых случаях могут отсутствовать — потребуются только затраты на внедрение уже разработанного ПО.
Таким образом, в статье осуществлен анализ особенностей информационного обмена между элементами наземного комплекса управления космическими аппаратами. Выявлены проблемные моменты как технического, так и организационного характера. Предложены варианты автоматизации обмена, дано их описание и сравнительный анализ. Рассмотрены реализации предложенных вариантов.
Было показано, что наиболее предпочтительным для автоматизации информационного обмена между элементами наземного комплекса управления космическими аппаратами в существующих условиях является вариант обмена хт/-документами (посредством файлового обмена или электронной
№ 1 (49) 2014
почты). В числе прочих достоинств упомянутый вариант в наибольшей степени позволяет унифицировать обмен. При разрешении организационных проблем и вопросов унификации вариант обмена непосредственно между базами данных абонентов наиболее предпочтителен. При невозможности разработки специального ПО одной из сторон или крайне сжатых сроках организации обмена возможна реализация обмена через программу-клиент.
Список литературы
1. Артюшенко В. М., Видов М. И. Анализ систем управления космическим летательным аппаратом // Информационные технологии. Радиоэлектроника. Телекоммуникации (^Т-2011): сб. ст. II Международной заочной научно-технической конференции. Тольятти: изд-во ПВГУС, 2011. С. 18-29.
2. Артюшенко В. М., Кучеров Б. А. Повышение оперативности бесконфликтного управления группировкой космических аппаратов в условиях ресурсных ограничений // Электротехнические
и информационные комплексы и системы. 2013. ¡1
¡к
Т. 9. № 3. С. 59-66. ^
Ьс
3. Артюшенко В. М., Кучеров Б. А. Повышение эф- ^
фективности оперативного управления груп- ^
2
пировкои космических аппаратов в услови- 5
и
ях ресурсных ограничений // Алгоритмические Э и программные средства в информационных ^ технологиях, радиоэлектронике и телекомму- ^ никациях: сб. ст. I Международной заочной на- со учно-технической конференции. Ч. 1. Тольятти: изд-во ПВГУС, 2013. С. 244-249.
4. Артюшенко В. М., Кучеров Б. А. Автоматизация информационного обмена при распределении средств управления космическими аппаратами // Фундаментальные и прикладные исследования, разработка и применение высоких технологий в промышленности и экономике: сб. ст. XVI международной научно-практической конференции. СПб.: изд-во Политехн. ун-та, 2013. С. 79-81.
5. Артюшенко В. М., Кучеров Б. А. Информатизация управления группировкой космических аппаратов // Прикладная инфрматика. 2013. № 6 (48). С. 6-14.
V. Artuschenko, Doctor of Engineering Science, Professor, Head of information technology and management systems department, Financial and Technological Academy (FTA), the city of Korolev, artuschenko@mail.ru
B. Kucherov, post-graduate student, Financial and Technological Academy (FTA), the city of Korolev, boris.ku4erov@gmail.com
Connecting the ground spacecraft constellation control units
In this article the analysis of features of information exchange between the elements of ground control complex for spacecraft constellation is carried out. Problem points both technical and organization character is revealed. The automation of information exchange options were suggested, their description and comparative analysis are given, as well as the issues of their implementation related. The information exchange options have been implemented in planning unit. Obtained results showed that usage of the information exchange options improve the spacecraft constellation control efficiency.
Keywords: information exchange, database, XML, software, subscriber, spacecraft.
